It's a good question. You are asking what happens if SIPS is used but somehow terminate on an interface that does not support SIPS.
In the best case, it will reject it properly because it will inspects the scheme, does't recognize it, and sends 416. That's ok. Another case is where the last proxy used the last hop exception because it was not compliant to this RFC. That's the case where we say that there is not much real existing deployment of this. Presumably, that proxy is mucking around to make it work (changing contacts or whatever), as we discussed earlier. This may be a theoretical problem more than a real one. I think we all agree on that. The case I think you are asking about is if the request goes to the UAS but the UAS somehow doesn't parse properly the scheme and accepts it. I think this is fairly likely actually. The question is do we need to solve this problem by adding an option-tag? This is a problem of buggy implementation of RFC 3261. Or are we happy with the originator of the request figuring it out and tearing down the session? I'm now tempted to change opinion again and argue that it is not worth it to try to solve buggy RFC 3261 implementations with an option-tag (maybe they'll be buggy on the option-tag too). The UAC should be able to detect that (looking at Contact and From for example) and clear the session. > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 10:59 > To: Alan Johnston > Cc: Audet, Francois (SC100:3055); Cullen Jennings; Peterson, > Jon; [email protected]; Keith Drage > Subject: Interaction of SIPS with old implementations that > weren't really using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt) > > Alan Johnston wrote: > > Also, since there are no deployments of sips, there is no > backwards > > compatibility issue. > > Ok, here's a silly question for you. > > Given, there are no big deployments of SIPS that we've heard of. > > However, many of the implementations we've been made aware of > support SIPS, or can at least be configured to react > differently to SIPS requests (whether that implies supporting > SIPS is debatable). > > If we have a deployment of the "new and improved" SIPS, the > traffic it produces is likely to hit some of those old > implementations that we don't currently consider "deployed" for SIPS. > > What happens? Do things break? Or are we confident that those > older implementations of SIPS are all configured "off"? > > -- > Dean > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
