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.
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?
2) should t_relaying of acks to 200 oks use proper (i.e.. non 0) 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?
-- juha
On 3/7/11 9:50 AM, Juha Heinanen wrote:
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.)
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.
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.
Is there something which doesn't work "as is"?
-jiri
Jiri Kuthan writes:
What is "proper value"?
jiri,
according to rfc3261 section 20.42:
For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie “z9hG4bK”, as discussed in Section 8.1.1.
it is sad if sr is not BY DEFAULT rfc3261 compliant.
then perhaps it would be a good idea to mention this in core cookbook.
see above. we have seen rfc3261 sip user agents that don't understand branch=0 value and matching of ack fails. so instead of doing full md5 calculation, it would make sense to use rfc3261 compliant constant rather than 0.
-- juha
On 3/7/11 10:40 AM, Juha Heinanen wrote:
see above. we have seen rfc3261 sip user agents that don't understand branch=0 value
That's probably good enough argument, as some newer implementations may give up on RFC2543 backwards compatibility and complaing about lack of branch.
Agreed, that would probably serve the purpose well.
-jiri
-
Jiri Kuthan -
Juha Heinanen