On Oct 10, 2007, at 10:37 AM, Francois Audet wrote:
Ignorning the reason why people are using INFO is not going
to make things better either...
I think most people are aware of KPML etc - we don't need to
tell them that.
I seriously don't think people are using INFO because they think it's
better than KPML.
I think peopled use to use INFO because (a) they implemented it before
RFC 2833, and (b) because it was difficult for them to implement
RFC 2833 when it got implemented and (c) KPML didn't exist at that
time.
I believe at this point, this is an imaginary issue.
Well, let's imagine we aren't talking about DTMF.
If I were cobbling together a SIP app that needed to exchange blobs
alongside an extant dialog, I'd have to say I'd be tempted to use
INFO despite all the caveats. It's a heck of a lot easier than
implementing a new event package, and much less overhead too.
Now, wouldn't it be just as easy to invent a new SIP method to
transport my blob? It might be. That depends on my stack and on any
confounded SBCs in the loop. In both cases, it's probably easier to
just slap a new media type into an INFO.
This gets back to my question of "What is the proper SIP extension
model?" Do we do new methods or new payloads for existing methods? Or
something else?
Classic SIP says "new method, same dialog". INFO says "new payload,
INFO method, same dialog". SUB/NOT says "new payload, new SUBSCRIBE
dialog, method". Purist SIP says "Make the blob into media, reinvite
for the new media". SIMPLE says "Carry the blob in an MSRP session,
reinvite for MSRP".
We've got too many potato peelers and a lot of nervous cats here,
folks. How do we choose our tool?
--
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
