7 Jul
2009
7 Jul
'09
11:22 p.m.
A telco equipment vendor has pointed out that when
an ACK message pass via our SER servers, a Via: header
is added which is normal, but frequently the branch value
in that Via: header is "0". As in:
Via: SIP/2.0/UDP 10.133.90.x;branch=0
This violates RFC 3261 for being zero and for not being
"unique across time and space". (8.1.1.7, page 38).
This is showing up in over 50% of the ACK messages
being passed through in just one direction.
When not equal to zero, the value is like this:
Via: SIP/2.0/UDP 10.133.90.x;branch=z9hG4bK095a.b27ac307.0
We don't see branch=0 appearing in any other SIP
message type, just ACKs.
Is anybody else seeing this and perhaps have a fix?
The telco equipment vendor doesn't think it is confusing
their equipment, but as it is out spec they want
to eliminate it as a source of trouble.
The calls are originating in a variety of types
of equipment including Acme, Sonus, Asterisk, etc.
This is the Via: added by SER, any already present
when we got the call are non-zero and look fine.
We are running ser-2.0.0-rc1.
A sample:
ACK sip:6x0x9x0x0x;npdi=yes;rn=6x0x6x9x7x@10.133.0.x:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1x3.9x.1x;branch=0
Via: SIP/2.0/UDP 7x.1x.1x3.1x0:5060;branch=z9hG4bK02Bd8a36ba5a45d76d6
From: <sip:Restricted@7x.1x.1x3.1x0>;tag=gK020a4ae7
To: <sip:6103900202@2x8.3x.2x1.7x>;tag=000a0285+1+11540020+75d5539b
Call-ID: 2097284613_75974428(a)7x.1x.1x3.1x0
CSeq: 15498 ACK
Max-Forwards: 16
Content-Length: 0
Thanks in advance.