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
