> -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 27, 2007 11:05 AM > To: Barnes, Mary (RICH2:AR00) > Cc: [email protected] > Subject: Re: [Sip] INFO > > On 9/27/07 10:22 AM, Mary Barnes wrote: > > And, here's another very old one: > > > > > http://quimby.gnus.org/internet-drafts/draft-choudhuri-sip-info-digit- > > 00 > > .txt > > > > Aha! Thanks. I conflated "using application/dtmf" with > "transporting DTMF in info", which is a somewhat broader > category. My read is that Hadriel and Brian were promoting a > specific solution (application/dtmf), which may well not be the case.
No. It is not the case. Sorry, I didn't realize you were thinking I was promoting a specific INFO solution. I'm trying to figure out where the harm is being done here (read on) by sending them. > > So, plodding down that path (and going through the old > arguments regarding DTMF in INFO), I am reminded that Jiri > had a draft proposing DTMF in INFO using MGCP; and Bert > Culpepper mentions this same approach in a later draft. Don't forget Rohan mentioned a similar approach in a draft some time ago http://www.softarmor.com/wgdb/docs/draft-mahy-sipping-signaled-digits-00 .txt > > But, going back to the discussion at hand: Brian and Hadriel > seem to be specifically promoting carrying "appliction/dtmf" > in INFO. Since I can only guess at their motiviations, I'll > leave it to them to indicate whether an > "application/vnd.nortelnetworks.digits" or "message/mgcp" > approach would make them happy. Well, now that you bring up application/vnd.nortelnetworks.digits, it really should have been application/com.nortelnetworks.digits (that's bugged me for years)... We do 2833 as well, so I'm not arguing for the sake of our own ancient MIME type (nor endorsing it either). Let me be the very first to say that the existance of a draft, no matter how old, does not make something a good idea. However, just because something isn't popular doesn't make it wrong or harmful either. If people wish to deprecate something purely for asthetic reasons, I simply do not support such an argument. I believe the deprecation of all uses of INFO OTHER than SIP-T is exactly for this reason. Why? Because we're allowing SIP-T. Ask yourself this question: if you are the terminator of a SIP-T call, what are your requirements as part of RFC-3372? Here they are for quick reference: "Terminator requirements: standard SIP processing, interpretation of encapsulated ISUP (for gateways only), support for multipart MIME, graceful handling of unknown MIME content (for non-gateways only)." Further (also from the RFC): "In case of an IP termination ..., the SIP UAS that receives SIP messages with encapsulated ISUP typically disregards the ISUP message. This does introduce a general requirement, however, that devices like SIP phones handle multipart MIME messages and unknown MIME types gracefully (this is a baseline SIP requirement, but also a place where vendors have been known to make shortcuts)." So if we're allowing SIP-T, which builds off of a baseline SIP requirement that if you get a MIME type or method (INFO) that you don't understand, that you gracefully handle this: send a 415/488 or send a 405, respectively, then why are we disallowing other uses of INFO that do not introduce ANY requirements beyond those of SIP-T which we are allowing? Here's another question for the readers: let's say Eric's draft becomes an RFC as written for sake of argument. What happens when a UA that does not support SIP-T gets a call from an ISUP gateway and gets an INFO with encapsulated ISUP in the message body? How does this processing differ from an endpoint getting encapsulated DTMF in a format it may not understand? It doesn't differ because it can't: the UA cannot differentiate between two different MIME types when it does not recognize either of them. I don't want a negotiation mechanism for INFO because I don't see a need for one. It's already there: 405, 415, and 488. If you don't support my MIME type, then my functionality is broken, not yours (unless you put my MIME type in your accept header). That's true of every MIME type in SIP other than SDP as part of an INVITE transaction as near as I can tell. If 405, 415, 488, allow, and accept are broken then let's fix that. Heck, the biggest usage (by volume) I see of INFO is for long-call audits where it carries absolutely no message body at all. How is this worse than sending an OPTIONS (which is allowed)? If someone can clearly address this argument and show how harm is being done and that RFC-3261 is not adequate to address this situation I'll shut up about deprecating INFO because then I think we'll have done three things: identified the real root cause of the problem, identified a problem in the baseline specification that needs to be fixed, and written a set of guidelines that others can clearly see why they shouldn't use INFO beyond the reason that sending something to someone else that they may not understand is bad, which would be a much shorter draft and not limited to INFO at all. Regards, Brian _______________________________________________ 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
