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:
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.
How would i fix this?
Alex Hermann writes:
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.
if first branch already timed out, shouldn't reply in step(7) go to garbage pin instead?
-- juha
On Thursday 11 October 2012, Juha Heinanen wrote:
Alex Hermann writes:
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.
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)
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:
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.
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
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
On Thursday 11 October 2012, Carlos Ruiz Díaz wrote:
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.
I thougth of something similar. Using a common onreply_route and $T_branch_idx (but watch out for the "bug" i reported in another email) or setting branch flags depending on the needed handling. But this kind of defeats the purpose of having the possibility to set different onreply_routes (and makes for very messy onreply_routes).
I think $T_branch_idx is only available on branch_route, and besides, it contains the current branch ID being processed so it wouldn't be useful from replies outside the current branch.
Regards.
Carlos.
On Thu, Oct 11, 2012 at 11:48 AM, Alex Hermann alex@speakup.nl wrote:
On Thursday 11 October 2012, Carlos Ruiz Díaz wrote:
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.
I thougth of something similar. Using a common onreply_route and $T_branch_idx (but watch out for the "bug" i reported in another email) or setting branch flags depending on the needed handling. But this kind of defeats the purpose of having the possibility to set different onreply_routes (and makes for very messy onreply_routes).
-- Greetings,
Alex Hermann
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
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?
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
-
Alex Hermann -
Carlos Ruiz Díaz -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion