[Users] Problem with ACK's (branch=0)

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Sep 27 13:13:59 CEST 2005

Hi everybody,

just to bring some light into the "branch=0" issue.

1) If a request is statelessly forwarded and syn_branch is disabled (0 
value), the branch will get the "0" value - that's done for 
speed/efficiency reasons. If syn_branch is enabled, for the statelessly 
requests will got into branch same value as they were statefully 
forwarded - the branch building mechanism is the same, but the request 
is stelessly forwarded. This is more expensive (as processing) but is 
more RFC compliant and more save in case of reboot - it ensure 
transaction consistency even if you have a reboot in the middle of the 

2) 200 OK ACKs are end-2-end statelessly forwarded (as RFC says). So, if 
you call t_relay for an ACK, this is what will happen:
    a) no syn_branch -> TM will match the ACK with the INVITE 
transaction and will use the branch from there. If no transaction was 
matched, the ACK will get a branch=0;
    b) with syn_branch -> TM will still match the ACK with the INVITE 
transaction, but disregarding the result, the ACK branch will be 
re-calculated as for the INVITE.
Note that internally, TM forward the ACK in a stateless way!

So, what happens in your case (if syn_branch is disabled):
    1) either you use stateless fwd for request -> all request will have 
    2) either use stateful fwd and you receive and ACK that does not 
match the INVITE transaction (due bogus headers), and by default, TM 
tries to fwd it statelessly -> branch=0.

hope that this helps a bit.
The patch you mention is actually void (no changes), it's just a 
recomandation to use syn_branch.


Tavis P wrote:

> A patch was just released that pertains to this issue
> http://bugs.sip-router.org/browse/SER-44?page=history
> Rodrigo P. Telles wrote:
>> Hash: SHA1
>> Hi,
>> I posted the same issue in serusers list and nobody answers too.
>> Seems that you are right!
>> Bad for us.
>> regards.
>> - --
>> ============================================
>> Rodrigo P. Telles <telles at devel.it>
>> TI Manager
>> Devel-IT - http://www.devel.it
>> ============================================
>> reticent wrote:
>>> I was one of the initial reporters of this "bug"
>>> In my case the issue was the use of Strict routing in the ACK or BYE
>>> message that somehow wasn't caught by the "loose_route()" statement. 
>>> The UAC sends the messages with a URI of the SER proxy.
>>> I didn't get a very good reception to my request, i the feeling i got
>>> was that it was passed off an as not important or uninteresting.  In my
>>> case i resolved the issue by upgrading the UAC that was sending the
>>> ACK/BYE.
>>> I've seen at least 5-6 people report this, with the varying responses
>>> (mostly that there was no issue, when it looked to me that there 
>>> was). I hope someone who understands the necessary specifications 
>>> and also SER
>>> would look into this and quash the issue once and for all (even if just
>>> to diffinitively identify it)
>>> I would be interested in spending some time to try and get to the 
>>> bottom
>>> of the issue, i will dig up the data from previous emails this 
>>> afternoon
>>> and see if i can assist.
>>> Rodrigo P. Telles wrote:
>>> Bogdan,
>>> Fistrly, thanks for your answer!
>>> Reading some old posts about 'branch=0' I found some one saying that
>>> it happend
>>> because SER forward statelessly, but I'm using "t_relay()" and I
>>> suppose it's a
>>> statefull function, does'n it?
>>> I saw this question many times in serusers maillist but no one 
>>> answer it!
>>> According with RFC3261 'branch=0' is not a valid branch ID (I know I
>>> can use
>>> syn_branch=0)!
>>> Best regards.
>>> -- 
>>> ============================================
>>> Rodrigo P. Telles <telles at devel.it>
>>> Diretor de Tecnologia
>>> Devel-IT - http://www.devel.it
>>> ============================================
>>> Bogdan-Andrei Iancu wrote:
>>>>>> Hi Rodrigo,
>>>>>> as I see in that email, the problem is actually a broken ACK which
>>>>>> doesn't match the INVITE transaction and statelessly loops on the 
>>>>>> proxy
>>>>>> - when statelessly fwded, the ACK gets branch=0 param in VIA.
>>>>>> so, what is your problem? - the actually presents of branch=0 or 
>>>>>> why it
>>>>>> gets there?
>>>>>> regards,
>>>>>> bogdan
>>>>>> Rodrigo P. Telles wrote:
>>>>>> Hi folks,
>>>>>> I've been experiencing some troubles with ACK's with branch=0.
>>>>>> I found a thread about it but I didn't find a 'solution' folowing 
>>>>>> the
>>>>>> thread.
>>>>>> http://mail.iptel.org/pipermail/serdev/2005-April/004296.html
>>>>>> Can some one point me to the correct answer for that question?
>>>>>> Thanks in advance.
>>>>>> -- 
>>>>>> ============================================
>>>>>> Rodrigo P. Telles <telles at devel.it>
>>>>>> TI Manager
>>>>>> Devel-IT - http://www.devel.it
>>>>>> ============================================
> ____________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users

More information about the Users mailing list