Indeed, onreply_route, like the other tm specific routing blocks, is property of the transaction. No tm routing block is specific per branch, this was the behaviour from the beginning, branch index PV is supposed to give indication about what branch is executed.
Setting/resetting a tm routing block can be done at any time, the last value is taken in consideration always when processing some event related to that transaction.
Cheers, Daniel
On 10/11/12 5:19 PM, Klaus Darilion wrote:
Seems like the reply route is a property of the transaction, and not of each respective branch. I wouldn't call it "bug" at the moment, but would call it a "limitation".
I second Juha's command - as soon as a branch is canceled I do not care about any following responses and it may be useful to drop them (to not interact with some logic waiting for responses on the new branch) - but different users have different scenarios ;-)
regards Klaus
On 11.10.2012 14:26, Alex Hermann wrote:
Hello,
i noticed thet in serial forking, replies to earlier branches arriving after sending out a new branch use the onreply_route of the later branch instead of the onreply_route set before sending the earlier branch....
How to reproduce:
set onreply_route to A
relay 1st branch
1st branch times out, internal 408 is created
tm send CANCEL to 1st branch
in failure route, onreply_route is set to B
relay 2nd branch
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.
How would i fix this?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users