29 Apr
2010
29 Apr
'10
12:06 a.m.
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(a)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
<ibc(a)aliax.net>
29 Apr
29 Apr
12:47 a.m.
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(a)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,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales(a)sippysoft.com
Skype: SippySoft
6:28 a.m.
On 04/28/2010 07:03 PM, Iñaki Baz Castillo wrote:
2010/4/29 Iñaki Baz Castillo<ibc(a)aliax.net>et>:
Not to worry, he has already exacted his revenge by eating your branch
GUID cookie. He says it was delicious.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
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). 
9:18 a.m.
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(a)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
9:26 a.m.
2010/4/29 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
12:30 p.m.
Klaus Darilion wrote:
I don't think it's intentional.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales(a)sippysoft.com
Skype: SippySoft
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. 
6:03 p.m.
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev <sobomax(a)sippysoft.com> wrote:
Klaus Darilion wrote:
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
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.
10:20 p.m.
Jan Janak wrote:
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev
<sobomax(a)sippysoft.com> wrote:
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,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales(a)sippysoft.com
Skype: SippySoft
Klaus Darilion wrote:
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. 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.
30 Apr
30 Apr
2:31 a.m.
Maxim Sobolev wrote:
Jan Janak wrote:
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
On Thu, Apr 29, 2010 at 6:30 AM, Maxim Sobolev
<sobomax(a)sippysoft.com>
wrote:
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. Klaus Darilion wrote:
There was a thread discussing this a long time ago, see:
http://lists.iptel.org/pipermail/serusers/2005-April/018559.html
Hope that helps. > 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.
5109
days inactive
5111
days old
9 comments
5 participants
participants (5)
-
Alex Balashov -
Iñaki Baz Castillo -
Jan Janak -
Klaus Darilion -
Maxim Sobolev