Dean, I think you're looking at this all wrong. I believe your "camps" below don't reflect what's really going on.
Most people who develop using SIP do not have a full understanding of how it really works, nor do they have time to figure it out. They have a stack that gives them some APIs of varying granularity that they must use to create the feature they need to make their deadlines. Some get it right, some get overwhelmed by the complexity of the protocol and make a mistake, others don't care as long as their test plans execute successfully. Generally speaking the philosophy they employ "the path of least (or near-least) resistance". INFO for carrying user-stimulus/DTMF is a great example of this. I can pretty much tell you what happened to get us to where we are today. Designer A: I need to carry some DTMF digits from the client to my voicemail server so I can enter my password. I don't want to mess with RTP because that's harder to do, so I'll do it in SIP since it's easier to code for me. All I need is a quickie in-band message to the gateway to tell it to play some tone and I'll let the gateway guy who has to deal with RTP and codecs anyhow figure it out from there. I'll use INFO since it's handy. Nobody has defined this that I know of (or I have to work with some legacy device) so I'll create my own message body type and just throw it in there. If someone doesn't understand it they'll just drop it. All of the devices I have to test with for this feature (today) have agreed to support this mechanism so I'm golden. Besides, now it's in SIP so I can have my proxy do things with the digits in the future if I want. Designer B: I need to carry some DTMF digits from the client to my voicemail server so I can enter my password. I already have code that handles voice packets, so rather than try to mess with all of that crazy SIP stuff, I'll just jam something into the RTP stream to tell the other end to play DTMF tone X. I'll use RFC-2833. If someone doesn't understand it they'll just drop it. Nobody needs to route off of these digits, so there's no risk in not carrying this in SIP. All of the devices I have to test with for this feature (today) have agreed to support this mechanism so I'm golden. Repeat designer A 2-4 times in semi-parallel, and throw a designer B in there and you have what we have today for DTMF. Contrast this with RFC-3265. Not only did it describe a general mechanism, but it clearly lays out a way forward for new applications that is simple and understandable to the average reader. The mechanism is widely supported in SIP stack APIs. Designer A will use it because it's already there and they can figure it out (although what goes into the message bodies may still vary somewhat). Designer B will use it too because their device probably has an easier to use API these days to make it happen. It's the path of least resistance and it's a good mechanism, so we win. You don't see INVITE-AUDIO or SUBSCRIBE-KPML because it's counter-intuitive and more difficult to implement. INFO is easy to understand, it's sitting there in their stack API, and they don't have to do too much to make it work. You put bits in one end and they pop out the other end, no muss, no fuss. Metaphorically speaking, applications are nouns, not verbs. Protocols only need to contain a very rudimentary set of verbs to facilitate transporting all the rest of the 'parts of speech' so to speak (HTTP is another great example of this at work). The real problem is that if we tell people what not to do (ala INFO) without giving them an easy way of doing it correctly, then they're very likely to ignore the advice given to them. Again, this is where I think 3265 got it right. Regards, Brian > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 25, 2007 1:50 PM > To: IETF SIP List > Subject: [Sip] Ruminations on the SIP extension model > > There is a deep philosophical divide about how the SIP > protocol should be formed and extended. One branch of this > debate holds that SIP's role is as a transport protocol with > a very few primitives and application logic handled at the > data level. In this model, new applications can generally be > built without changing the protocol or its syntax. The second > branch holds that the SIP protocol itself should be > intimately tied to the application, with new functionality > represented as new message types. Yet another branch of the > debate holds that SIP is only for setting up and tearing down > "sessions", and that information outside of that needed to > set up or tear down a "session" is rightfully part of the > "session" and not in the domain of the SIP protocol itself. > > Let's consider the user-stimulus over-SIP question (which is > all mixed up with the emulating-DTMF-for-telephony question). > > The "reusable primitive" camp might define a way to use an > extensible mechanism (like SIP Events or a new INFO > negotiation) and define user- stimulus delivery using a MIME > object and use the extensible mechanism's negotiation feature > to figure out whether a peer supports the usage (note that > this is what we did with KPML). > > The "extend SIP" camp might define a new SIP non-invite > method type (maybe a method called "USERSTIM") that would > carry a fixed payload and be negotiated using basic SIP > feature negotiation mechanism (the "Allow" and "Supported" > header field). One might note that once we have a few hundred > SIP method types that these header fields are going to get > relatively large. > > The "it's just a session" camp might define a "user stimulus > session", describe it using SDP, and use INVITE to establish > a session over which user-stimulus information would be transmitted. > > There has been a certain lack of clarity about the this > extension model in SIP's past, resulting in some extensions > that re-use a single SIP method (Event packages, INFO) and > others that add new SIP methods (MESSAGE) and others that > establish sessions (MSRP chat, Real- time text). It could be > argued that this has made for a more complex protocol suite > than might have occurred had any single methodology been > followed exclusively. > > > It seems to me that we have a quandary -- if we accept the > "Add a new method type for each application" model, then we > should deprecate RFC 3265, instead adding new SIP methods > like SUBSCRIBE-KPML and NOTIFY- KPML. If we accept the "SIP > as transport" model, then we have to ask if we need a way to > negotiate application context for transported data within an > INVITE-bounded dialog (like INFO "packages"). If we accept > the "it's just a session" model then everything we've done > with event packages, INFO, MESSAGE, and so needs to be > replaced with a proper session-based mechanism (presence > sessions, ISUP sessions, messaging sessions, and so on). > > Or we could do nothing, accept that we have a rather muddled > protocol, and just try and give guidance on when to use each > extension modality. > > Specifically, as the ongoing body-type-context debate has > pointed out, while we can say what body types we support, we > don't currently have a good way for a describe what a message > containing a body of a specific type is likely to mean in the > current context, and the jury is out as to whether we have > reliable means of deducing a context. > > We do have RFC 4485, which seems to me to do a fair job of > guiding us on new header fields but doesn't say enough about > body types (and doesn't even begin to discuss the > body-type-context question beyond a vague mention of > Content-Disposition), and which provides little useful > guidance on when to use new methods vs. when to use events. > > What do we want to do here? Is there a way to get a clear > position, or are we going to be debating bodies vs. header > fields vs. method- types forever? > > -- > 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 > _______________________________________________ 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
