On Oct 12, 2007, at 12:02 PM, Brian Stucker wrote:
That's back to the question of "Is SIP an application
protocol or a transport protocol"?
Should the SIP-layer software be aware of and coupled to the
state of the application that's using SIP?
If so, then the proper design model is to build a new SIP
request method for every new piece of application functionality.
You forgot about supported.
Well, it's entirely possible that Supported and Accept will get
damned big. I'd still like to have a query-for-specific or "opt in"
model rather than a blanket "here's everything I can possibly deal
with" model for declaration of extensions. RFC 3265 meets that
requirement.
So for example, DTMF: Using this model of SIP extension, we
might define a new "DTMF" method. It would look just like
DTMF-over-INFO, except the name of the method would be DTMF.
It clearly resolves the INFO-context question, because now we
KNOW we're getting dialog- related DTMF over it, and we know
what to do with it. We know what we can transport in
DTMF-requests, because the RFC that defines the DTMF
extension method will also define exactly what payload format to use.
INVITE
Supported: foo
Allow: INFO
Accept: application/foo
But the MIME people aren't going to let you register a new MIME type
for "foo" that is specific to each application semantic that might
possibly use "foo".
200 OK
Supported: foo
Allow: INFO
Accept: application/foo
...
INFO
Content-Type: application/foo
[DTMF]
Where is this broken?
Broken in its usage of MIME.
Let's say we have something (not DTMF) that needs to transport jpg
images that are used as soft-key overlays. To do what you're
suggesting, we'd need a new MIME-type registration that says "This is
just like jpeg, except that it is only useful for keypad overlays".
The MIME folks would birth kittens.
This too is a clean solution to the problem, although it
embodies a different design philosophy than the same-dialog NOTIFY.
This leads back to my question: What is the right extension
modality for SIP? Until we have an answer here, we're going
to keep going back and forth on this. MAKE A DECISION, PEOPLE!
You can't feasibly make a clean one. There will always be SDP vs.
non-SDP extension modalities.
Yeah, that's true.
But maybe we narrow it down to SDP vs non-SDP instead of SDP vs SIP
method vs MIME type vs event-package vs MSRP vs whatever.
--
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
