> Well, let's imagine we aren't talking about DTMF. Good.
> 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? Maybe what is needed is a description of which of these mechanism is appropriate for what class of extension? And is there a case where one of the non-INFO is not appropriate? _______________________________________________ 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
