I can confirm this behavior. <div><br></div><div>I had a similar scenario when 2 or more branches were setup. First branch timed out, while second branch was being processed a reply from first branch arrived and handled improperly by a routing logic which was configured for the second branch. </div>
<div><br></div><div>I isolated each response from the different branches by parsing the branch ID that Kamailio adds to the via header after processing the request. Through this mean, I managed to handle correctly each reply from different branches no matter when the response was received.</div>
<div><br></div><div>Regards.</div><div><br></div><div>Carlos.</div><div><br><div class="gmail_quote">On Thu, Oct 11, 2012 at 10:35 AM, Alex Hermann <span dir="ltr"><<a href="mailto:alex@speakup.nl" target="_blank">alex@speakup.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday 11 October 2012, Juha Heinanen wrote:<br>
> Alex Hermann writes:<br>
> > 1) set onreply_route to A<br>
> > 2) relay 1st branch<br>
> > 3) 1st branch times out, internal 408 is created<br>
> > 4) tm send CANCEL to 1st branch<br>
> ><br>
> > 5) in failure route, onreply_route is set to B<br>
> > 6) relay 2nd branch<br>
> > 7) 1st branch responds with 487, and goes into reply_route B instead of A<br>
> ><br>
> > I think each branch should take the reply_route which was set before it<br>
> > got relayed and not pick up later changes meant for other branches.<br>
><br>
> if first branch already timed out, shouldn't reply in step(7) go to<br>
> garbage pin instead?<br>
<br>
</div>No, let me explain it a bit more.<br>
<br>
At step 2a) a provisional response is received.<br>
<br>
The proxy is configured with a maximum ringtime (fr_inv_timeout). If that<br>
expires, an internal 408 is generated and failure_route is entered (which will<br>
launch branch 2.<br>
<br>
At (almost) the same time the proxy sends a CANCEL to abort branch 1. The uas<br>
at the receiving end of branch 1 will however still respond to the INVITE (as<br>
it should), hence the 487 from step 7.<br>
<br>
I need to do specific processing when branch 1 receives a reply, and do that<br>
in onreply_route A. Unfortunately, the reply never reaches that code.<br>
<br>
<br>
(In reality, branch 1 is not just 1 branch, but consists of multiple parallel<br>
branches, all receiving a reply on the cancelled INVITE. Most of them arrive<br>
before the 2nd branch is relayed, those are handled correctly by onreply_route<br>
A, but replies that come in later are incorrectly handled by onreply_route B)<br>
<span class="HOEnZb"><font color="#888888">--<br>
Greetings,<br>
<br>
Alex Hermann<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br></div>