Jonathan Rosenberg wrote:
Vijay K. Gurbani wrote:2) I was also wondering about the theoretical possibility of backward compatibility? Any provisions in the protocol for an implementation to detect and manage this issue?The SIP protocol number is still "SIP/2.0"; not "SIP/2.1". You could
glean some information from the presence or absence of the Via magic
cookie, but you should not depend on it for anything.
>
There is absolutely no need.An rfc3261 stack compliant stack will be 100% backward compatible with a rfc2543 stack? I can just get the two stacks to interwork without any issues at all? All the rfc2543 gear already deployed will work smoothly with a new stack? Hope this is true... Makes life simple for us.
rfc3261 is sufficiently backwards compatible with rfc2543. There is no need to detect versions or anything. Any backwards compatibility functions are built into specific features of rfc3261 that needed to support backwards compatibility. If you just implement rfc3261 you will be backwards compatible.
There is no versioning of the protocol. Things like the via cookie are meant to deal with backwards compatibility for THAT SPECIFIC FEATURE. It is possible to encounter an implementation that supports the contact cookie, but is still a strict router. Using the contact cookie to imply support for all of 3261 is a mistake. The lr parameter deals with the record-routing changes, and the contact cookie, with the via header changes.
I was earlier thinking of using this branch-tag to check which rfc the remote stack was complying with. Was not clear with all the scenarios though.The problem, as I outline above, is we are not trying to strictly version the protocol, but provide interoperability and backwards compatibility on a feature-by-feature basis. So, via cookie tells you nothing except that the via branch ID is sufficiently unique to be used as a transaction ID.There was a thread a while ago on why depending on the magic cookie for operations is not a good idea -- I don't have a reference to it (if someone else on the list does, feel free to post it). One of the reason you cannot depend on the magic cookie is that it only tells you something about the upstream UA and nothing about the downstream server (assuming you are a proxy).
I think I'll currently stick to rfc3261 and hope for the best. Will deal with 2543 as and when issues arise...As above, it is my opinion that rfc3261 sufficiently deals with rfc2543 for any feature you are going to find in use from rfc2543.4) Does it make sense now to still deal with 2543?Sure. There is deployed gear that is rfc2543 compliant. 3Com's Ethernet SIP phones for example are still used in many installations (they work great) and are rfc2543 compliant only.