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:
- 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.
- 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