[SR-Users] Wrong onreply_route is called after serial forking

[Alex Hermann]

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