I can confirm this behavior.
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.
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.
Regards.
Carlos.
On Thu, Oct 11, 2012 at 10:35 AM, Alex Hermann
<alex@speakup.nl> wrote:
On Thursday 11 October 2012, Juha Heinanen wrote:
> Alex Hermann writes:
> > 1) set onreply_route to A
> > 2) relay 1st branch
> > 3) 1st branch times out, internal 408 is created
> > 4) tm send CANCEL to 1st branch
> >
> > 5) in failure route, onreply_route is set to B
> > 6) relay 2nd branch
> > 7) 1st branch responds with 487, and goes into reply_route B instead of A
> >
> > I think each branch should take the reply_route which was set before it
> > got relayed and not pick up later changes meant for other branches.
>
> if first branch already timed out, shouldn't reply in step(7) go to
> garbage pin instead?
No, let me explain it a bit more.
At step 2a) a provisional response is received.
The proxy is configured with a maximum ringtime (fr_inv_timeout). If that
expires, an internal 408 is generated and failure_route is entered (which will
launch branch 2.
At (almost) the same time the proxy sends a CANCEL to abort branch 1. The uas
at the receiving end of branch 1 will however still respond to the INVITE (as
it should), hence the 487 from step 7.
I need to do specific processing when branch 1 receives a reply, and do that
in onreply_route A. Unfortunately, the reply never reaches that code.
(In reality, branch 1 is not just 1 branch, but consists of multiple parallel
branches, all receiving a reply on the cancelled INVITE. Most of them arrive
before the 2nd branch is relayed, those are handled correctly by onreply_route
A, but replies that come in later are incorrectly handled by onreply_route B)
--
Greetings,
Alex Hermann