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@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:
Hello everyone,
I was wondering whether anyone knew what was going on with the
following
bug: http://developer.berlios.de/bugs/?func=detailbug&bug_id=2925&group_i...
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/