Subject: [Sip] SIP backward compatibility issue

From: Prakash R <[email-masked]>
Date: Mon, 23 Dec 2002 17:59:08 +0530

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)?

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?

3) Is it feasible for applications to have dual SIP Stacks? (Both 2543 
and 3261)?

4) Does it make sense now to still deal with 2543?

Thanks in advance.

Regards,
-- 
Prakash R
Senior Program Manager, Internet Telephony Group
=====================================================================
C-DOT (Centre for Development of Telematics)
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
email: [email-masked], [email-masked]
Phone: +91-80-2263399, +91-80-2383951, Fax: +91-80-2263256
=====================================================================

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Dec 2002 10:29:41 -0600

> stack? If not RFC2543, then what about the various drafts (draft 5, 

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).

> 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 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Dec 2002 17:49:33 -0500

Vijay K. Gurbani wrote:

> cookie, but you should not depend on it for anything. 

There is absolutely no need.

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.

  There was a
> the upstream UA and nothing about the downstream server (assuming you

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.

> absent in most rfc2543 implementations is dubious at best.

There were none that anyone mentioned.

To me, "dual-stack" is non-sensical. rfc3261 provides backwards 
compatibility where needed.

> (they work great) and are rfc2543 compliant only.

As above, it is my opinion that rfc3261 sufficiently deals with rfc2543 
for any feature you are going to find in use from rfc2543.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Steve Levy <[email-masked]>
Date: Tue, 24 Dec 2002 11:32:49 -0500

><snip>
>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.
<snip>

broadening the discussion to rfc 3264 (offer/answer), isn't there a 
potential for backward compatibility issues with rfc 2543 implementations 
wrt early media ?

thx,
steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Dec 2002 11:46:54 -0500

Early media was not specified in rfc2543. It did say that you should be 
prepared to receive media before receiving the answer, which is still 
the case for 3264. Another issue was that people used to put SDP in 
non-reliable 1xx responses, and then put the same thing in 2xx. That 
case is explicitly allowed for in 3261, so it should interoperate as well.

Perhaps you could identify the specific problem you are concerned about?

-Jonathan R.

Steve Levy wrote:
>> support backwards compatibility. If you just implement rfc3261 you 
>> will be backwards compatible.
> 
> <snip>
> 
> potential for backward compatibility issues with rfc 2543 
> implementations wrt early media ?
> 
> thx,
> steve
>

---

From: Steve Levy <[email-masked]>
Date: Tue, 24 Dec 2002 12:45:49 -0500

At 11:46 AM 12/24/2002 -0500, Jonathan Rosenberg wrote:
>prepared to receive media before receiving the answer, which is still the 
>case for 3264. Another issue was that people used to put SDP in 
>non-reliable 1xx responses, and then put the same thing in 2xx. That case 
>is explicitly allowed for in 3261, so it should interoperate as well.
>

my concern was SDP in a 18x followed by another 18x/2xx with different SDP. 
Wouldnt the SDP in the subsequent 18x/2xx be treated differently by 3264 
compliant UAs as opposed to earlier 2543 compliant UAs ?

thx,
steve

---

From: Prakash R <[email-masked]>
Date: Fri, 27 Dec 2002 18:38:24 +0530

Jonathan Rosenberg wrote:
>>> compatibility? Any provisions in the protocol for an implementation 
>>> to detect and manage this issue?
>>

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.

> nothing except that the via branch ID is sufficiently unique to be used 

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.

BTW, When will the protocol version be incremented? What sort of changes 
will necessitate a protocol version upgrade? I wasn't tracking the 
mailing list when the version got upgraded to 2.0.

> for any feature you are going to find in use from rfc2543.

I think I'll currently stick to rfc3261 and hope for the best. Will deal 
with 2543 as and when issues arise...

Regards,

---

From: "Adam Roach" <[email-masked]>
Date: Sat, 28 Dec 2002 00:42:03 -0600

"Prakash R" <[email-masked]> wrote in message
news:[email-masked]...

> with a new stack? Hope this is true... Makes life simple for us.

Yes, that was a design goal for RFC3261. That said, there are "holes" in
RFC2543 -- places in which the protocol was underspecified. Interop tests
and operational experience have revealed these holes; all the ones that we
have discovered to date have been fixed in RFC3261. So, there are ways to
implement an RFC2543 stack that won't work in general (even with other
RFC2543 stacks). There is obviously no magic fix for these problems.

> remote stack was complying with. Was not clear with all the scenarios

Don't do that. Don't even try. You still encounter a huge number of stacks
that use the branch parameter but don't do 100% of RFC3261.

> will necessitate a protocol version upgrade?

From a practical perspective, I expect that such a change will be made only
if enhancements to the protocol cannot be added in a way that is backwards
compatible.

For a parallel, see the rather major enhancements that occured between
HTTP/1.0 and HTTP/1.1. If an overhaul of SIP of that magnitude is ever
attempted, there might be a minor version increment. However, given the
sheer volume of protocol spec at this point, it is quite unlikely (IMHO)
that such an undertaking will ever be attempted. Further, because of the
foresight of adding the "Require" and "Proxy-Require" mechanisms, it is
additionally unlikely that such a change will ever even be desirable.

A major version change, which is even less likely, would probably represent
completely scrapping the protocol and starting from scratch.

(As a footnote: like SIP, HTTP has had multiple RFCs that describe one
protocol version: RFC2068 and RFC2616 both describe HTTP/1.1 -- so we're not
doing anything particularly unprecedented or even unusual in doing the
same).

> I wasn't tracking the

It was almost 9 years ago.

SIP/1.0 was one of the proposals for a session invitation protocol when the
MMUSIC working group first started on that task back in early 1996. It was
very terse and SDP-like. SCIP/1.0 was a proposal that was offered at the
same time. Almost immediately, they were merged together into one protocol,
dubbed "SIP/2.0". To my knowledge, neither of the original protocols ever
escaped research facilities.

> with 2543 as and when issues arise...

You shouldn't have to. If you do encounter any such problems, please post
about them to the list so we can register a bug and fix it in the next
release.

/a

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 29 Dec 2002 09:35:11 -0800

On Tuesday, December 24, 2002, at 09:45 AM, Steve Levy wrote:

>> Early media was not specified in rfc2543. It did say that you should 
>> be prepared to receive media before receiving the answer, which is 
>> still the case for 3264. Another issue was that people used to put 
>> SDP in non-reliable 1xx responses, and then put the same thing in 
>> 2xx. That case is explicitly allowed for in 3261, so it should 
>> interoperate as well.
>>
> my concern was SDP in a 18x followed by another 18x/2xx with different 
> SDP. Wouldnt the SDP in the subsequent 18x/2xx be treated differently 
> by 3264 compliant UAs as opposed to earlier 2543 compliant UAs ?

Because offers and answers need to be sent reliably, you can't put an 
answer in a non-reliable 18x and an offer in a 2xx.  This is spelled 
out in 3261 section 13 as quoted below...

> 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. That same exact answer MAY also be placed in any 
> provisional responses sent prior to the answer. The UAC MUST treat the 
> first session description it receives as the answer, and MUST ignore 
> any session descriptions in subsequent responses to the initial > INVITE.

thanks,
-rohan

> thx,
> steve
>
>
>
>> -Jonathan R.
>>
>> Steve Levy wrote:
>>>
>>>> <snip>
>>>> 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.
>>> <snip>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 16:53:50 -0500

A few additional notes inline.

> RFC2543 stacks). There is obviously no magic fix for these problems.

There are also some never-implemented or never-used features of rfc2543 
that were dropped, including PGP and absolute time in register 
expirations. Since these were never used outside of a lab, you shouldn't 
see them in real life.

> that use the branch parameter but don't do 100% of RFC3261.

Right. I also tried to explain this.

> if enhancements to the protocol cannot be added in a way that is backwards

You mean, never?

We have no plans to ever rev the version. It makes no sense. Instead, we 
  have looked at each feature, one at a time, and addressed backwards 
compatibility for it using mechanisms appropriate for that feature. That 
means that implementations can support grades of behavior (a very common 
case) rather than lumping everyting into a version number, which would 
effectively require dual-stacks. With our approach, there are no dual 
stacks.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 16:56:45 -0500

Rohan Mahy wrote:
> answer in a non-reliable 18x and an offer in a 2xx.  This is spelled out 
> in 3261 section 13 as quoted below...

All of this supposed "rfc2543 behavior" was never documented in rfc2543, 
and is rather one of several interpretations people have made about the 
spec. Even supposedly "rfc2543-compliant" UAs probably wont interwork 
for features like this.

-Jonathan R.