Hi,
I am requesting a clarification on the generation of the Via header branch
parameter for a stateless proxy when sending an ACK in response to a non-2xx
final response.
RFC3261 section 16.6, point 8, defines the procedures for the branch
parameter generation but it is unclear it this applies specifically to
stateful proxies or applies to both stateful and stateless proxies.
Section 16.11 defines the procedures for Stateless Proxy, but references
Section 16.6, with some exceptions as stated, but some of this is not
crystal clear to which section 16.6 points match up with the section 16.11
exceptions. If one was to merge section 16.6 and 16.11, applying the
exceptions noted in section 16.11, how would the text read in terms of the
requirements? Without going to this extreme maybe someone has some insight?
The main question is the generation of the branch parameter by a stateless
proxy for the non-2xx ACK. Must it be unique or the same? I inserted the
pertinent RFC3261 statements with a comment:
A stateless proxy MUST follow the request processing steps described
in Section 16.6 with the following exceptions:
o The requirement for unique branch IDs across space and time
applies to stateless proxies as well. However, a stateless
proxy cannot simply use a random number generator to compute
the first component of the branch ID, as described in Section
16.6 bullet 8. This is because retransmissions of a request
need to have the same value, and a stateless proxy cannot tell
a retransmission from the original request. Therefore, the
component of the branch parameter that makes it unique MUST be
the same each time a retransmitted request is forwarded. Thus
for a stateless proxy, the branch parameter MUST be computed as
a combinatoric function of message parameters which are
invariant on retransmission.
The stateless proxy MAY use any technique it likes to guarantee
uniqueness of its branch IDs across transactions. However, the
following procedure is RECOMMENDED. The proxy examines the
branch ID in the topmost Via header field of the received
request. If it begins with the magic cookie, the first
component of the branch ID of the outgoing request is computed
as a hash of the received branch ID. Otherwise, the first
component of the branch ID is computed as a hash of the topmost
Via, the tag in the To header field, the tag in the From header
field, the Call-ID header field, the CSeq number (but not
method), and the Request-URI from the received request. One of
these fields will always vary across two different
transactions.
[CC] - I am interpreting the above to mean that the same rule applies for
ACK for both non-2xx final responses and 200 OK (section 16.6 with section
16.11 exceptions). In the case where the magic cookie is present in the
received topmost Via header branch parameter, the stateless proxy uses this
information in computing its branch-id that it inserts, the same as it would
do in handling the initial INVITE. The branch parameter value it sends in
the topmost Via header for the INVITE and ACK must be identical.
Does anyone see anything incorrect?
My understanding is that a SIP UAS or stateful proxy receiving the ACK must
be able to correlate the ACK message to the non-2xx response to eliminate
retransmissions, and prevent loops.
Below: b1, b2, ... - Branch parameter
t1 - To: tag
SIP UAC Stateless Stateful SIP
UAS
Proxy Proxy
|--INV(b1)------------->|--INV(b1,b2)---------->| |
|<-100(b1)--------------| |--INV(b1,b2,b3)------->|
| |<-100(b1,b2)-----------| |
| | |<-100(b1,b2,b3)--------|
| | | |
| | |<-18x(b1,b2,b3,t1)-----|
|<-18x(b1,t1)-----------|<-18x(b1,b2,t1)--------| |
| | | |
|--CANCEL(b1)---------->|--CANCEL(b1,b2)------->| |
|<-200(b1)--------------|<-200(b1,b2)-----------| |
| | |--CANCEL(b1,b2,b3)---->|
| | |<-200(b1,b2,b3)--------|
| | |<-487(b1,b2,b3,t1)-----|
| | |--ACK(b3,t1)---------->|
|<-487(b1,t1)-----------|<-487(b1,b2,t1)--------| |
|--ACK(b1,t1)---------->|--ACK(b1,bx*,t1)------>| |
| | | |
Some questions have been raised as to the generation of the bx* branch
parameter. Should it be the same as previously sent for the INVITE
transaction or not?
Thanks in advance!
Chuck Chaney
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
