Subject: [Sip] Ruminations on the SIP extension model

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jul 2007 13:49:53 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Jul 2007 13:57:40 -0500

On 7/25/07 1:49 PM, Dean Willis wrote:
> 3265, instead adding new SIP methods like SUBSCRIBE-KPML and NOTIFY-KPML.

No, not really.

In pursuing such a model, you're effectively arguing that INVITE should 
be split into INVITE-AUDIO, INVITE-VIDEO, INVITE-AUDIO-VIDEO, etc. Why 
didn't we? Because pretty much all the SIP protocol semantics are 
identical regardless of what kind of INVITE session you're setting up.

Identically, just about all of the SIP protocol semantics are identical 
for SUBSCRIBE and NOTIFY, _regardless_ of the event package being used.

/a

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 26 Jul 2007 01:47:20 -0500

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Jul 2007 08:59:59 -0500

On Jul 25, 2007, at 1:57 PM, Adam Roach wrote:

>> 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.
>
> No, not really.
>
> In pursuing such a model, you're effectively arguing that INVITE  
> should be split into INVITE-AUDIO, INVITE-VIDEO, INVITE-AUDIO- 
> VIDEO, etc. Why didn't we? Because pretty much all the SIP protocol  
> semantics are identical regardless of what kind of INVITE session  
> you're setting up.
>
> Identically, just about all of the SIP protocol semantics are  
> identical for SUBSCRIBE and NOTIFY, _regardless_ of the event  
> package being used.

Well, personally I'm in the "reuseable primitives" camp, and I  
believe you are too (as 3265 is a shining example of this approach).  
But other people have very different beliefs.

Note that at least one person suggested at the mic during the  
discussion of Eric's draft that each different thing that is likely  
to be done with INFO should instead be done with a different new  
method "per thing".

Note also that one of the main contributors prior to RFC 2543 broke  
with the community over the BYE method, as he (IIRC) believed that  
the way to end a session was to stop sending media.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Jul 2007 09:00:20 -0500

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. 

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 26 Jul 2007 11:17:05 -0400

> But other people have very different beliefs.

I think everyone would be for reusable primitives.  The concern I have,
though, is that the problem with the currently defined primitive for dtmf is
it is the wrong type for the dtmf feature.  A second concern is that the
defined primitive is far too heavy for the problem being addressed.  So my
marketing gut tells me that market forces will continue to work against it.
 
> the way to end a session was to stop sending media.

Funny.  I was thinking it should be a re-Invite with an expires=0 and sdp
media ports of 0.
;)

-hadriel

---

From: "Steve Langstaff" <[email-masked]>
Date: Thu, 26 Jul 2007 08:23:00 -0700

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 26 July 2007 16:17
> To: 'Dean Willis'; 'Adam Roach'
> Cc: 'IETF SIP List'
> > with the community over the BYE method, as he (IIRC) 
> believed that the 
> > way to end a session was to stop sending media.
> 
> Funny.  I was thinking it should be a re-Invite with an 
> expires=0 and sdp media ports of 0.
> ;)
> 
> -hadriel

Nonsense. The initial INVITE should cause an implicit subscription for a
bye event notification. But I guess we have to use the "legacy" BYE
method :)

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Jul 2007 10:26:04 -0500

If any of this shows up at a SIPit, you owe me beer. And asprin.

RjS

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Jul 2007 10:27:20 -0500

On 7/26/07 8:59 AM, Dean Willis wrote:
> Well, personally I'm in the "reuseable primitives" camp, and I believe 
> you are too (as 3265 is a shining example of this approach). But other 
> people have very different beliefs.

Actually, if I knew then what I knew now, I'd probably have proposed 
doing things completely differently. I have come to believe that a far 
cleaner approach would have been to use INVITE to set up a stream of 
state change notifications -- it would have prevented this "multiple 
usages in a dialog" mess; it would have prevented the bizarre forking 
SUBSCRIBE problem; it would have made unsolicited NOTIFYs impossible... 
the whole setup would have been much cleaner.

And, as we all know by now, every time you send an unsolicited NOTIFY, 
the terrorists win.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Jul 2007 15:10:35 -0400

Dean Willis wrote:
> 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.

I would argue that SIP *is* an application protocol - supporting 
'multimedia communications'. Its implementation takes many forms - 
softphones, hardphones, gateways, and so on, but still it is all about 
multimedia communications.

Consequently, the notion of an additional layer *above* SIP, something 
beyond the UI, something that has behaviors that are fundamentally 
different (and NOT compatible) with other applications that might reside 
above SIP, is foreign to the design of SIP, and something that is 
dangerous. It is this thinking that will lead us to highly segmented 
uses of SIP, none of which are well defined or interoperable. Very 
reminiscent of the 'service ID' discussions in sipping, in fact.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com