7 Jul
2009
7 Jul
'09
10: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.
7 Jul
7 Jul
11:06 p.m.
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(a)7x.1x.1x3.1x0
CSeq: 15498 ACK
Max-Forwards: 16
Content-Length: 0
Thanks in advance.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:16 p.m.
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
8 Jul
8 Jul
9:27 a.m.
Frank Durda IV píše v Út 07. 07. 2009 v 16:16 -0500:
Michal Matyska wrote:
At the top to the configutation part. It isn't valid route command.
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.
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
5428
days inactive
5429
days old
3 comments
2 participants
participants (2)
-
Frank Durda IV -
Michal Matyska