Thanks benny, - It helps to know I'm not the only one. See my comments. -----Original Message----- From: Benny Prijono [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 25, 2006 10:50 AM To: Chaney, Charles Cc: [email protected] Subject: Re: [Sip-implementors] non-2xx final response ACK branch parametergeneration for statel ess proxy
Hi Charles, there are some RFC 3261 open bug reports related to your questions: http://bugs.sipit.net/show_bug.cgi?id=680 http://bugs.sipit.net/show_bug.cgi?id=755 http://bugs.sipit.net/show_bug.cgi?id=659 The comments in the bug report suggest that stateless proxy should just copy the branch value from the topmost Via, whatever the value is. More over, in 2xx response case, the ACK's branch parameter must be different than the branch parameter of the 2xx response, whereas for non-2xx response it must be the same. So how would a stateless proxy distinguish between ACK for 2xx and ACK for non-2xx response? I don't think it's possible, cmiiw. [CC] - If the SIP UAC and proxies are RFC3261 compliant, is it really necessary to know the difference? Per the RFC statements and the inclusion of the magic cookie, the branch parameter inserted by the proxy is re-computed (maybe this is a simple copy?) based on the branch parameter that's received. It's up to the SIP UAC or preceeding stateful proxy to follow the RFC3261 branch parameter uniqueness in generating its branch parameter. Definitely an rfc2543 element would introduce complexities! So it sounds like the branch copying solution is the only solution, although I'm not sure how this would affect the loop detection by stateless proxies. Maybe stateless proxies can't do loop detection? [CC] - I too doubt that the stateless proxy can do loop detection, so they are simply forwarding to the next hop where maybe there is some loop detection possible. -benny Chaney, Charles wrote: > 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
