Charles, The basic requirements are the following:
- stateless proxy must generate same unique branch parameter for a retransmitted INVITE - stateless proxy must generate same unique branch parameter for an ACK to a non-2xx response to INVITE The ACK for a 2xx response will ~not~ have the same branch parameter as the corresponding INVITE. Since a stateless proxy uses the topmost branch parameter as the basis for its hash, the branch will be the same iff the original sender of the ACK made it the same (i.e. he sent it as an ACK to non-2xx) The matching branch for ACK to non-2xx is needed by the next transaction stateful hop(proxy or endpoint) to match it with the servertransaction of the original INVITE. The matching ST then transitions from the COMPLETED to the CONFIRMED state (see section 17.2.1), and response retransmissions stop. Since for 2xx responses the ST is terminated immediately, there is no need for the ACK to have the same branch; it will match with the dialog instead (i.e. from-tag, to-tag and call-id). A non-2xx final response means that the dialog is gone, so only the branch is left as basis for matching. Hope this clarifies, Jeroen ----- Original Message ----- From: "Chaney, Charles" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, January 25, 2006 2:23 PM Subject: [Sip-implementors] non-2xx final response ACK branch parametergeneration for statel ess proxy > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
