[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] SIP backward compatibility issue
Prakash R wrote:
1) Assuming we have an application built using SIP stack developed to
comply with RFC 3261, does it have to interwork with RFC 2543 compliant
stack? If not RFC2543, then what about the various drafts (draft 5,
draft 6, ..., draft 9)?
A rfc3261 compliant SIP entity will be compliant with most of rfc2543
anyway. There are some parts of the protocol that were ambiguous to
begin with in rfc2543 -- Record-Route handling to construct Route
headers is a good example. As such, these were not uniformly
implemented anyway. So, rfc3261 took some liberty in specifying these
in a more uniform and unambiguous manner than did rfc2543. Even then,
in the case of R-R, backward compatibility has not been forsaken; a
rfc3261 SIP proxy, for instance, can still inter-operate with rfc2543
UAs which will not understand the loose-route extension. Another
example of possible non-compatibility include security (i.e.
deprecation of PGP and use of S/MIME). But again, these features were
not uniformly (or widely) implemented by rfc2543 implementors anyway.
Regarding compatibility with drafts, no. You do not have to be
compliant with intermediate drafts -- they are good for 6 months anyway.
You can, of course, index your implementation to these drafts and
thus progress along the same curve as the protocol matures. Compliance
only makes sense for an rfc, not an intermediate draft (see rfc2026).
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 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).
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.
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.
Regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip