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