Kirill, I did read this section which explicitly talks about branch ID: "..so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this specification.."
Ofcourse, this may be used as (an indirect) means to distinguish between the two versions. Sounds strange though that the SIP/Version was not used for a SIP entity to explicitly say that it is RFC3261 compliant...probably there were some reasons for doing so (like many old entities doing strict check for 2.0 instead of greater than or equal to 2.0)...may have been discussed on the mailing lists much earlier. Thanks, Satya > -----Original Message----- > From: Kirill Bolshakov [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 04, 2002 4:50 PM > To: Yadavalli, Satyamurthy > Cc: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] sip version > > > Satya, > > Please see RFC3261 section 8.1.1.7 (covering Via header). It > states that: > > ******************************** > When the UAC creates a request, it MUST insert a Via into that > request. The protocol name and protocol version in the > header field > MUST be SIP and 2.0, respectively. The Via header field value MUST > contain a branch parameter. This parameter is used to identify the > transaction created by that request. This parameter is > used by both > the client and the server. > > The branch parameter value MUST be unique across space and time for > all requests sent by the UA. The exceptions to this rule > are CANCEL > and ACK for non-2xx responses. As discussed below, a > CANCEL request > will have the same value of the branch parameter as the request it > cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx > response will also have the same branch ID as the INVITE whose > response it acknowledges. > > The uniqueness property of the branch ID parameter, to > facilitate > its use as a transaction ID, was not part of RFC 2543. > > The branch ID inserted by an element compliant with this > specification MUST always begin with the characters > "z9hG4bK". These > 7 characters are used as a magic cookie (7 is deemed sufficient to > ensure that an older RFC 2543 implementation would not pick such a > value), so that servers receiving the request can > determine that the > branch ID was constructed in the fashion described by this > specification (that is, globally unique). Beyond this requirement, > the precise format of the branch token is implementation-defined. > > ******************************** > > Thus, the server is able to distinguish between older and > newer clients. > > Regards, > Kirill > > --- > Kirill Bolshakov > SoftJoys Labs > [EMAIL PROTECTED] > > Yadavalli, Satyamurthy wrote: > > Am I missing something here? > > > > I thought the RFC3261 SHOULD have assigned a different SIP > version number... > > that's what a version number is meant for! > > > > - Satya > > > > > >>-----Original Message----- > >>From: Yadavalli, Satyamurthy [mailto:[EMAIL PROTECTED]] > >>Sent: Thursday, August 15, 2002 12:18 PM > >>To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > >>Subject: [Sip-implementors] sip version > >> > >> > >>The new SIP RFC-3261 specifies the SIP protocol version to be > >>used as SIP/2.0. So was it with the obsoleted RFC 2543. > >>How do SIP entities distinguish between these implementations? > >> > >>Thanks, > >>Satya > >>_______________________________________________ > >>Sip-implementors mailing list > >>[EMAIL PROTECTED] > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
