4 Sep
2009
4 Sep
'09
6:03 p.m.
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=282234…
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=282234…
4 Sep
4 Sep
9:06 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
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
24 Sep
24 Sep
11:28 a.m.
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
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.
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. 
11:38 a.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
not sure I got this one. Headers and r-uri on updated on a branch route
are visible on that branch only.
SourceForge.net writes:
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.
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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* http://www.asipto.com/
12:18 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
On Sep 24, 2009 at 10:38, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 24.09.2009 10:28 Uhr, Alex wrote:
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#r…
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 Friday 04 September 2009, Juha Heinanen wrote:
not sure I got this one. Headers and r-uri on updated on a branch route
are visible on that branch only.
SourceForge.net writes:
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.
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.
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.
12:27 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
On 24.09.2009 11:18 Uhr, Andrei Pelinescu-Onciul wrote:
On Sep 24, 2009 at 10:38, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
good to know. Another goodie then of SR/K 3.0.
Cheers,
Daniel
On 24.09.2009 10:28 Uhr, Alex wrote:
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#r…
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).
On Friday 04 September 2009, Juha Heinanen
wrote:
not sure I got this one. Headers and r-uri on updated on a branch route
are visible on that branch only.
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.
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.
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
--
Daniel-Constantin Mierla
* http://www.asipto.com/
2:06 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
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.
2:28 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
On Sep 24, 2009 at 13:06, Alex Hermann <alex(a)speakup.nl> wrote:
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.
Yes.
Andrei
On Thursday 24 September 2009, Andrei Pelinescu-Onciul
wrote:
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.
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?
2:02 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
On Thursday 24 September 2009, you wrote:
But is is only calling branch_route for a branch if a
response was received,
not if there was a timeout.
There is no failure route
involved.
On 24.09.2009 10:28 Uhr, Alex wrote:
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.
On Friday 04 September 2009, Juha Heinanen
wrote:
not sure I got this one. Headers and r-uri on updated on a branch route
are visible on that branch only. SourceForge.net writes:
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. 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. 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.
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. 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.
2 Oct
2 Oct
6:46 p.m.
New subject: [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
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.
--
Greetings,
Alex Hermann
5530
days inactive
5558
days old
9 comments
6 participants
participants (6)
-
Alex -
Alex Hermann
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com -
SourceForge.net