[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] SIP backward compatibility issue

A few additional notes inline.

Adam Roach wrote:

"Prakash R" <rprakash@cdotb.ernet.in> wrote in message
3E0C50C8.4060302@cdotb.ernet.in">news:3E0C50C8.4060302@cdotb.ernet.in...



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.


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



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.



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.

Right. I also tried to explain this.




BTW, When will the protocol version be incremented? What sort of changes
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.
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.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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