[sr-dev] [ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers

Alex Hermann alex at speakup.nl
Thu Sep 24 13:02:20 CEST 2009


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 at 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 at 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 at A' as set in previous branch route.

6) Kamailio routes to A2





Scenario 2 (host is down):

1) I set ruri to 1234 at 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 at 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.



More information about the sr-dev mailing list