Vijay K. Gurbani wrote:
There is absolutely no need.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.
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.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).
There were none that anyone mentioned.3) Is it feasible for applications to have dual SIP Stacks? (Both 2543 and 3261)?
Yes; although, once again, the utility of support PGP which was probably absent in most rfc2543 implementations is dubious at best.
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.