Bugs item #2822344, was opened at 2009-07-16 11:06 Message generated for change (Comment added) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: ver 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Branch route has wrong ruri or missing headers
Initial Comment: The scenario: In branch route, I rewrite the ruri and add an additional header. When the destination fails and DNS-based failover takes place, the branch route is called again. For this second branch, the ruri is not the same as the ruri at t_relay time. Also the extra header is missing.
So this bug could be either:
- The ruri and rest of variables/packet for each branch should be the same as the ruri at t_relay time or - The header added in the first branch route should also be present for the second branch (in the case of DNS-based failover)
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
Before t_relay:
$rU = "*1234567890" t_relay("0x03");
my branch route: xlog("L_NOTICE", "Branch: <$ru> via <$du>\n"); if (is_method("INVITE") and $(rU{s.substr,0,3}) == "*12") { strip(3); append_hf("X-Test: 12\r\n"); }
The log:
Jul 15 09:14:38 Branch: sip:*1234567890@test.domain;transport=udp via <<null>> Jul 15 09:14:38 Reply Status: 503 Service Unavailable Jul 15 09:14:38 Branch: sip:234567890@test.domain;transport=udp via <<null>> Jul 15 09:14:38 Reply Status: 100 Trying
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-09-04 17:03
Message: And when there is no response at all from th destination, resulting in a local generated 408, the behaviour is even different. Then branch route isn't called at all, but the packet headed for the failover host is different from the original as it misses any headers added in the branch route.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344...
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
-- juha
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route is only for that branch. Unfortunately both statements are not fulfilled by Kamailio.
If you add a header for a specific destination domain, you'd probably want it to be sent to every ip if there are multiple ip's in the domains SRV records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as branch route is called again for the next IP. Keep in mind you don't get the RURI you set before t_relay(), but the RURI set in the previous branch route.
In case there is a timeout, you're lost. No branch route is called, and the header is missing.
Unfortunately the above is a very common scenario: LCR. When every carrier requires a specific RURI format, require some additional headers and that the carriers are reachable over SRV records.
A quick workaround would be that on DNS based failover in case of a timeout, branch route is called again. I tried to find in the source the place where the decision is made whether or not to call branch route on DNS failover, but got lost.
Alex.
On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route is only for that branch. Unfortunately both statements are not fulfilled by Kamailio.
not sure I got this one. Headers and r-uri on updated on a branch route are visible on that branch only.
If you add a header for a specific destination domain, you'd probably want it to be sent to every ip if there are multiple ip's in the domains SRV records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as branch route is called again for the next IP. Keep in mind you don't get the RURI you set before t_relay(), but the RURI set in the previous branch route.
DNS failover is pretty much hidden to script writer, and each step creates a new branch. Also remember that this is serial forking, so a branch from a branch, not parallel, branches from initial invite.
In case there is a timeout, you're lost. No branch route is called, and the header is missing.
Failure route is processing the initial message. Hopefully lot of such limitations will be removed in kamailio 3.0 with the new function msg_apply_changes() from textops where the script writer can apply changes, therefore make new headers permanent before creating the transaction and going into the forking logic.
Cheers, Daniel
Unfortunately the above is a very common scenario: LCR. When every carrier requires a specific RURI format, require some additional headers and that the carriers are reachable over SRV records.
A quick workaround would be that on DNS based failover in case of a timeout, branch route is called again. I tried to find in the source the place where the decision is made whether or not to call branch route on DNS failover, but got lost.
Alex.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Sep 24, 2009 at 10:38, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route is only for that branch. Unfortunately both statements are not fulfilled by Kamailio.
not sure I got this one. Headers and r-uri on updated on a branch route are visible on that branch only.
If you add a header for a specific destination domain, you'd probably want it to be sent to every ip if there are multiple ip's in the domains SRV records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as branch route is called again for the next IP. Keep in mind you don't get the RURI you set before t_relay(), but the RURI set in the previous branch route.
DNS failover is pretty much hidden to script writer, and each step creates a new branch. Also remember that this is serial forking, so a branch from a branch, not parallel, branches from initial invite.
In case there is a timeout, you're lost. No branch route is called, and the header is missing.
Failure route is processing the initial message. Hopefully lot of such limitations will be removed in kamailio 3.0 with the new function msg_apply_changes() from textops where the script writer can apply changes, therefore make new headers permanent before creating the transaction and going into the forking logic.
I don't think it would be needed in this case. By default sip-router tm uses exactly what was sent on the last branch when doing dns failover. See http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#re...
So this should solve the header added in a branch route and not preserved on dns failover and you don't have to add anything to the script (provided you use sip-router or kamailio 3.0).
One thing to note though, is that branch route is not called when doing dns failover, if reparse_on_dns_failover is set to 1.
Andrei
On 24.09.2009 11:18 Uhr, Andrei Pelinescu-Onciul wrote:
On Sep 24, 2009 at 10:38, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route is only for that branch. Unfortunately both statements are not fulfilled by Kamailio.
not sure I got this one. Headers and r-uri on updated on a branch route are visible on that branch only.
If you add a header for a specific destination domain, you'd probably want it to be sent to every ip if there are multiple ip's in the domains SRV records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as branch route is called again for the next IP. Keep in mind you don't get the RURI you set before t_relay(), but the RURI set in the previous branch route.
DNS failover is pretty much hidden to script writer, and each step creates a new branch. Also remember that this is serial forking, so a branch from a branch, not parallel, branches from initial invite.
In case there is a timeout, you're lost. No branch route is called, and the header is missing.
Failure route is processing the initial message. Hopefully lot of such limitations will be removed in kamailio 3.0 with the new function msg_apply_changes() from textops where the script writer can apply changes, therefore make new headers permanent before creating the transaction and going into the forking logic.
I don't think it would be needed in this case. By default sip-router tm uses exactly what was sent on the last branch when doing dns failover. See http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#re...
So this should solve the header added in a branch route and not preserved on dns failover and you don't have to add anything to the script (provided you use sip-router or kamailio 3.0).
good to know. Another goodie then of SR/K 3.0.
Cheers, Daniel
One thing to note though, is that branch route is not called when doing dns failover, if reparse_on_dns_failover is set to 1.
Andrei
On Thursday 24 September 2009, Andrei Pelinescu-Onciul wrote:
By default sip-router tm uses exactly what was sent on the last branch when doing dns failover. See http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html #reparse_on_dns_failover
The documented limitations make this seem like a hack. Why not make sure it works all the time?
So this should solve the header added in a branch route and not preserved on dns failover and you don't have to add anything to the script (provided you use sip-router or kamailio 3.0).
Well, it's a bit early to use that in production, isn't it?
One thing to note though, is that branch route is not called when doing dns failover, if reparse_on_dns_failover is set to 1.
If set to 0, will it call branch route for every DNS-based branch? Even if it is the result of an internally generate 408?
Alex.
On Sep 24, 2009 at 13:06, Alex Hermann alex@speakup.nl wrote:
On Thursday 24 September 2009, Andrei Pelinescu-Onciul wrote:
By default sip-router tm uses exactly what was sent on the last branch when doing dns failover. See http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html #reparse_on_dns_failover
The documented limitations make this seem like a hack. Why not make sure it works all the time?
We gladly accept patches :-) The case when it wouldn't work is a corner case (how many of you use mhomed=1 in the cfg?) and even in that case is unlikely that it would cause problem (I could of course come with a scenario where it will cause problems, but the likelihood of encountering it is quite low IMHO). Making it work in all the cases would also add a bigger performance hit.
So this should solve the header added in a branch route and not preserved on dns failover and you don't have to add anything to the script (provided you use sip-router or kamailio 3.0).
Well, it's a bit early to use that in production, isn't it?
Yes, using it now directly in production would be risky. This code in tm comes from ser 2.1 where it was tested (and is used in production). k 3.0 and sip-router as a whole, did see quite little testing until now, but hopefully they will see much more in the next month.
One thing to note though, is that branch route is not called when doing dns failover, if reparse_on_dns_failover is set to 1.
If set to 0, will it call branch route for every DNS-based branch? Even if it is the result of an internally generate 408?
Yes.
Andrei
On Thursday 24 September 2009, you wrote:
On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route is only for that branch. Unfortunately both statements are not fulfilled by Kamailio.
not sure I got this one. Headers and r-uri on updated on a branch route are visible on that branch only.
Except when DNS failover is taking place. The second (and later) call to branch route (for the same t_relay() call) have the ruri as changed in the previous branch route.
If you add a header for a specific destination domain, you'd probably want it to be sent to every ip if there are multiple ip's in the domains SRV records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as branch route is called again for the next IP. Keep in mind you don't get the RURI you set before t_relay(), but the RURI set in the previous branch route.
DNS failover is pretty much hidden to script writer, and each step creates a new branch.
But is is only calling branch_route for a branch if a response was received, not if there was a timeout.
Also remember that this is serial forking, so a branch from a branch, not parallel, branches from initial invite.
Well, then why isn't the header added although the changed ruri pertains?
In case there is a timeout, you're lost. No branch route is called, and the header is missing.
Failure route is processing the initial message.
There is no failure route involved.
Hopefully lot of such limitations will be removed in kamailio 3.0 with the new function msg_apply_changes() from textops where the script writer can apply changes, therefore make new headers permanent before creating the transaction and going into the forking logic.
I don't want to make the headers permanent, they are per branch only.
I seem to have failed to explain the issue, so I try again. Note that the primary issue is that the behavior for DNS based failover is different for a received 503 and a timeout.
There is a destination domain (A), each destination domain has 2 IP's via DNS SRV (A1, A2).
Scenario 1 (host is up and responds with 503):
1) I set ruri to 1234@A and call t_relay with branch route armed
2) In branch route, I add a header for domain A and rewrite the ruri to 001234@A
3) Kamailio routes to A1. A1 fails with 503
4) Kamailio does DNS failover and DOES enter branch route again for domain A
5) In branch route I re-add the header for domain A. Note that the ruri is '001234@A' as set in previous branch route.
6) Kamailio routes to A2
Scenario 2 (host is down):
1) I set ruri to 1234@A and call t_relay with branch route armed
2) In branch route, I add a header for domain A and rewrite the ruri to 001234@A
3) Kamailio routes to A1. A1 does not respond. Internal 408 is generated.
4) Kamailio does DNS failover but DOES NOT enter branch route, but routes directly to A2. There is no way to add the correct header to the request. (note the difference to step 4 in the previous scenario)
Scenario 1 works, even though I personally think it is strange that the ruri in the 2nd branch route is not identical to the ruri at t_relay() time. Even if the forking is sequentially, all branched are derived form a single t_relay() call, and the expected ruri is the one from t_relay() time.
Scenario 2 breaks. It should enter branch route (or send out identical message by itself). From a usability standpoint, I would prefer that the behavior is identical for received 503 or internal 408. And as every failover creates a new branch, I think branch_route should be called everytime.
A quick workaround would be that on DNS based failover in case of a timeout, branch route is called again. I tried to find in the source the place where the decision is made whether or not to call branch route on DNS failover, but got lost.
Any idea where this decision is made?
Alex.
On Thursday 24 September 2009, Alex Hermann wrote:
Scenario 2 breaks. It should enter branch route (or send out identical message by itself). From a usability standpoint, I would prefer that the behavior is identical for received 503 or internal 408. And as every failover creates a new branch, I think branch_route should be called everytime.
A quick workaround would be that on DNS based failover in case of a timeout, branch route is called again. I tried to find in the source the place where the decision is made whether or not to call branch route on DNS failover, but got lost.
A workaround seems to be to call t_on_branch() again in the branch_route itself.
-
Alex -
Alex Hermann
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com -
SourceForge.net