Hi, nathelper generates a keepalice request with branch=0:
OPTIONS sip:9.9.9.9:12345 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5060;branch=0 From: sip:nat_keepalive@mydomain.org;tag=b240e8a7 To: sip:9.9.9.9:12345 Call-ID: 786219c2-7c0b783-2d@1.2.3.4 CSeq: 1 OPTIONS Content-Length: 0
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Iñaki Baz Castillo wrote:
Hi, nathelper generates a keepalice request with branch=0:
OPTIONS sip:9.9.9.9:12345 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5060;branch=0 From: sip:nat_keepalive@mydomain.org;tag=b240e8a7 To: sip:9.9.9.9:12345 Call-ID: 786219c2-7c0b783-2d@1.2.3.4 CSeq: 1 OPTIONS Content-Length: 0
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Looks like a bug to me.
Regards,
2010/4/29 Iñaki Baz Castillo ibc@aliax.net:
Hi, nathelper generates a keepalice request with branch=0:
Let's imagine I said "keepalive" rather than "keepalice" (if not, bob would get angry with us).
On 04/28/2010 07:03 PM, Iñaki Baz Castillo wrote:
2010/4/29 Iñaki Baz Castilloibc@aliax.net:
Hi, nathelper generates a keepalice request with branch=0:
Let's imagine I said "keepalive" rather than "keepalice" (if not, bob would get angry with us).
Not to worry, he has already exacted his revenge by eating your branch GUID cookie. He says it was delicious.
Am 29.04.2010 00:06, schrieb Iñaki Baz Castillo:
Hi, nathelper generates a keepalice request with branch=0:
OPTIONS sip:9.9.9.9:12345 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5060;branch=0 From: sip:nat_keepalive@mydomain.org;tag=b240e8a7 To: sip:9.9.9.9:12345 Call-ID: 786219c2-7c0b783-2d@1.2.3.4 CSeq: 1 OPTIONS Content-Length: 0
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
regards klaus
2010/4/29 Klaus Darilion klaus.mailinglists@pernau.at:
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
For this it could be greater to include any custom param into Via header or using a specific (but still SIP/2.0 complian) branch value (somethign as z9hG4bKABCDEFGHIJK). Using "0" value means that some UAS could ignore them if they are not RFC 2543 compliant.
Klaus Darilion wrote:
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
I don't think it's intentional.
Regards,
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev sobomax@sippysoft.com wrote:
Klaus Darilion wrote:
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
I don't think it's intentional.
There was a thread discussing this a long time ago, see:
http://lists.iptel.org/pipermail/serusers/2005-April/018559.html
Hope that helps.
-Jan
Jan Janak wrote:
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev sobomax@sippysoft.com wrote:
Klaus Darilion wrote:
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
I don't think it's intentional.
There was a thread discussing this a long time ago, see:
http://lists.iptel.org/pipermail/serusers/2005-April/018559.html
Hope that helps.
It doesn't look like the same issue at all. The thread is about branch in ACK being different from branch in 200 OK, while this one is about branch in OPTIONS that the proxy generates to keep NAT binding alive.
Regards,
Maxim Sobolev wrote:
Jan Janak wrote:
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev sobomax@sippysoft.com wrote:
Klaus Darilion wrote:
Why not to use a SIP/2.0 compliant branch (z9hG4bK...)? any reason?
Maybe this is the method to detect keep-alive replies and absorb them before they enter dialplan processing.
I don't think it's intentional.
There was a thread discussing this a long time ago, see:
http://lists.iptel.org/pipermail/serusers/2005-April/018559.html
Hope that helps.
It doesn't look like the same issue at all. The thread is about branch in ACK being different from branch in 200 OK, while this one is about branch in OPTIONS that the proxy generates to keep NAT binding alive.
Maybe it is related as the ACK is generated by the proxy itself and the OPTIONS too.
Anyway, I think branch=0 is not a clean solution, but RFC 3261 (17.2.3) defines that clients must support old transaction matching schema too.
regards klaus
-
Alex Balashov -
Iñaki Baz Castillo -
Jan Janak -
Klaus Darilion -
Maxim Sobolev