20 Apr
2005
20 Apr
'05
9 a.m.
I received questions for more detailed explanation, so here it is:
branch value serves as transaction id, which (among others) differentiates
retransmission of the same request from new requests. From
RFC3261's standpoint, ACK for a 200 (as opposed to a [3-6]xx ACK)
is a separate transaction, i.e., a different branch value is
adequate.
In case people do keep asking: it is really so, and receivers
MUST be able to deal with ACK branch different from branch
in INVITE. Let's think of a proxy that does not record-route
and introduced branch 1234 to "its" Via. ACK coming later
directly to UAS includes UAC's branch which is different from
proxy's branch. It may or may not be the same as UAC's INVITE
branch but it is different from what UAS sees.
-jiri
At 12:44 AM 4/20/2005, Darryl H. Thomas wrote:
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Tuesday, April 19, 2005 2:23 PM
To: Darryl H. Thomas; serusers(a)lists.iptel.org
Subject: Re: [Serusers] Bug # 2925
The bug report is invalid, ignore it. branch=0 in ACK to a 200
is perfectly valid according to RFC3261. Your termination provider
must be using a buggy devices.
-jiri
At 07:04 PM 4/19/2005, Darryl H. Thomas wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
Hello everyone,
I was wondering whether anyone knew what was going on with the
following
80
For those not wanting to follow the links, this is a bug submitted by
someone back in December wherein ser puts 'branch=0' in the Via header
it
creates for an ACK to a 200 OK Invite response.
I haven't seen any activity related to this, and it's affecting
interoperability with one of our termination providers.
0.9.0 users, have you seen the same problem??
Cheers,
Darryl
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/