7 Mar
2011
7 Mar
'11
10:50 a.m.
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
7 Mar
7 Mar
12:17 p.m.
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
11:40 a.m.
Jiri Kuthan writes:
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
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.
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. 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.
12:36 p.m.
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.
and matching of ack fails.
so instead of doing full md5
calculation, it would make sense to use rfc3261 compliant constant
rather than 0.
Agreed, that would probably serve the purpose well.
-jiri
5012
days inactive
5012
days old
3 comments
2 participants
participants (2)
-
Jiri Kuthan -
Juha Heinanen