11 Oct
2012
11 Oct
'12
8:26 a.m.
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?
--
Greetings,
Alex Hermann
11 Oct
11 Oct
9:09 a.m.
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?
-- juha
9:35 a.m.
On Thursday 11 October 2012, Juha Heinanen wrote:
Alex Hermann writes:
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
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? 
9:49 a.m.
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(a)speakup.nl> wrote:
On Thursday 11 October 2012, Juha Heinanen wrote:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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?
10:48 a.m.
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
10:58 a.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:19 a.m.
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:
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?
4:57 p.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
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?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4265
days inactive
4265
days old
7 comments
5 participants
participants (5)
-
Alex Hermann -
Carlos Ruiz Díaz -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion