"If, on the other hand, you decide to implement RFC3262, then you must implement it all. Including the bit about not necessarily getting an SDP in the 200 if you received one reliably earlier."
The implication here being, if you implement a newer SIP specification (3262) you are no longer fully compliant with an earlier spec (3261). That's my understanding of a loss of backward compatibility. What's worth noting is that 3261 defines "core SIP functionality". Interesting that an "extension functionality spec" 3262, does not just propose additional functionality, it suggests that behaviour advised/suggested/whatever in the core draft may be modified. It's not really a big issue to us, just an observation of the SIP specification process. Matt -----Original Message----- From: Michael Procter [mailto:[EMAIL PROTECTED] Sent: 21 February 2006 09:27 To: Matthew Gardiner; Paul Kyzivat; Stephen Paterson Cc: [email protected] Subject: RE: [Sip-implementors] Where in the specs? Matthew Gardiner wrote: > I think this interpretation of RFC3262 breaks backward > compatibility with > RFC3261. > > That is, an implementation coded according to RFC3261 refuses > a call setup > when there is no SDP in the 200. RFC3262 comes along and this > behaviour is > now "incorrect". I had assumed that newer SIP specifications > augmented, > rather than modified, existing ones. I disagree. If you implement only RFC3261, then you will not see a 200 without SDP. To quote the extract someone else already quoted: RFC 3261 13.2.1 2nd bullet If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. Since you have implemented RFC3261 alone (specifically not RFC3262), then you cannot advertise support for reliable provisionals (Supported: 100rel) and so will not receive them. Therefore, the answer MUST be in the 200 response. If, on the other hand, you decide to implement RFC3262, then you must implement it all. Including the bit about not necessarily getting an SDP in the 200 if you received one reliably earlier. Paul Kyzivat was right when he wrote: # This is no accident. The language is as it is in 3261 precisely to # anticipate the reliable provisional mechanism. # The language is fine tuned to still permit the answer in the 200 in this # case to provide backward compatibility. Regards, Michael Procter _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
