To top it off, the designers you describe might have actually
read RFC 2976 which states the following "example uses" for
INFO:
- Carrying DTMF digits generated during a SIP session.
> -----Original Message-----
> From: Stucker, Brian (RICH1:AR00)
> Sent: Wednesday, July 25, 2007 23:47
> To: Dean Willis; IETF SIP List
> Subject: RE: [Sip] Ruminations on the SIP extension model
>
> 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
>
_______________________________________________
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
