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@7x.1x.1x3.1x0 CSeq: 15498 ACK Max-Forwards: 16 Content-Length: 0
Thanks in advance.
Use syn_branch=0 in your ser.cfg. This will put RFC compliant branch ids into positive ACKs in exchange of few CPU cycles wated to calculate the id instead of using tm transaction id :-)
Michal
Frank Durda IV píše v Út 07. 07. 2009 v 15:22 -0500:
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@7x.1x.1x3.1x0 CSeq: 15498 ACK Max-Forwards: 16 Content-Length: 0
Thanks in advance.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Michal Matyska wrote:
Use syn_branch=0 in your ser.cfg. This will put RFC compliant branch ids into positive ACKs in exchange of few CPU cycles wated to calculate the id instead of using tm transaction id :-)
Michal
I'll try that when I can have a maintenance window to stick that in and restart SER. In what area does it go? Up at the top or in a function/route?
As it stands, do you have any idea why only some ACKs have branch=0 results and the others have a reasonable looking Branch=n value?
The "branch=0" also doesn't seem to ever show up in PRACKs or any other SIP message either. Just some ACKs.
Frank
Frank Durda IV píše v Út 07. 07. 2009 v 16:16 -0500:
Michal Matyska wrote:
Use syn_branch=0 in your ser.cfg. This will put RFC compliant branch ids into positive ACKs in exchange of few CPU cycles wated to calculate the id instead of using tm transaction id :-)
Michal
I'll try that when I can have a maintenance window to stick that in and restart SER. In what area does it go? Up at the top or in a function/route?
At the top to the configutation part. It isn't valid route command.
As it stands, do you have any idea why only some ACKs have branch=0 results and the others have a reasonable looking Branch=n value?
The "branch=0" also doesn't seem to ever show up in PRACKs or any other SIP message either. Just some ACKs.
Yes, ACKs are (even with tm module used) relayed statelessly, so there is no transaction looked while processing them.
By some ACKs having branch 0 and some valid id - is it so that ACK for 2xx replies have branch 0 and ACKs for 3xx/4xx/5xx/6xx have correct id? This is how I would expect to be, but if you see 2xx ACKs some with branch 0 and some with correct value, then hard to say... I'd need to see more examples to check if there could be any pattern found for that behaviour.
Michal
-
Frank Durda IV -
Michal Matyska