[SR-Users] about syn_branch

[Jiri Kuthan]

On 3/7/11 9:50 AM, Juha Heinanen wrote:
> we noticed that if sr 3.1 config does not contain
>
> syn_branch=0
>
> then acks to 200 oks that are t_relayed by sr, contain branch=0
> param in topmost via.
>
> in kamailio 1.5, via branch param has proper value even when tm param
> syn_branch is not set.

What is "proper value"?
(Some frequently think that downstream entities must be able to rely
on branch(Via)==branch(ACK), which is not granted since without RR-ing
the ACK can take a shorter path resulting in a very different ACK.)

>
> a couple of questions:
>
> 1) according to core cookbook, syn_branch core param only affects
> stateless forwarding.  in my config, all acks are t_relayed, i.e.,
> syn_branch param should not have any effect, but is does.  how is that
> possible?  is there a bug in core cookbook?

In fact, ACK is forwarded statelessly  even when INVITE is processed
using TM. A loose definition of "stateful" is "message you hold for
future retransmissions". You don't retransmit ACKs and therefore you
don't store them in SR. All of this confusion comes from ACK being
a very special kind of request -- like INVITE it has same Cseq,
unlike INVITE it may have a different  forwarding path, Via stack,
topmost branch,  to-tags... it is a confusing protocol design.
It should have been  better a cleanly separated SUB-NOT-like
transaction pair, than a merged INV-180-200-ACK hack.




>
> 2) should t_relaying of acks to 200 oks use proper (i.e.. non 0)

Not sure what "proper" would be, as the branch parameter doesn't
play any role for matching messages neither downstream nor
at SR. We can make it "look better" but I'm wondering if it would
improve something.

> via
> branch param even when syn_branch is not set to any value in config?
> if not why?  if yes, will branch=0 be used only when ack to 200 ok does
> not match any invite transaction?

Is there something which doesn't work "as is"?


-jiri