If people did KPML without all the complexity (i.e., please report all digits one-by-one instead of complex pattern matching), then it would fix (1).
I do agree that the arguments against INFO are often biased and flawed. I'd much rather we just say: if you need out of band, use KPML because it's the standard, instead of dreaming up weird self-serving reasons why INFO is the root of all evils. So again, the status quo is we have a standard for out-of-band (KPML) which is not broken (albeit a bit complicated). If somebody thinks it needs to be optimized for performance or whatever, let them propose it. I don't really have an opinion. Anyways, I'm not pulling out of this as I have nothing new to contribute. > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 03, 2007 12:06 > To: Audet, Francois (SC100:3055); 'Dean Willis'; Stucker, > Brian (RICH1:AR00) > Cc: [email protected]; 'Adam Roach'; Barnes, Mary (RICH2:AR00) > Subject: RE: [Sip] INFO > > The problem I think for DTMF is there are (1) applications > that need DTMF that are not in the media path, and (2) there > is equipment out there that only does INFO for dtmf. For > (2), I'm cool with assuming 2833 will be the future. I don't > work for those companies, but I assume they'll move that way > and get their customers to upgrade. > > For (1), 2833 is not a solution. Currently KPML is the only > IETF-standardized solution for that, yet INFO is the clear > defacto standard most people use. My concern with assuming > KPML will be adopted is there is little incentive for most > devices to do so. The app server vendor who needs > signaling-based dtmf has an incentive, but they need the UA's > to support it, and I don't see that happening. Instead, INFO > is simpler, and many already do it to support the legacy > devices due to problem (2) above. But I was thinking someone > else would say the same, but apparently not. So maybe I'm > off base on this one. Nothing to see here. Move along. > > I don't actually care *that much*. I was more annoyed by the > "info is bad" > draft because it seemed flawed and biased to me, and if > anyone wanted to propose Info for something in the future, > the draft would be a needless block to that. > > -hadriel > > > -----Original Message----- > > From: Francois Audet [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 02, 2007 5:50 PM > > To: Dean Willis; Brian Stucker > > Cc: [email protected]; Adam Roach; Mary Barnes > > Subject: RE: [Sip] INFO > > > > I'm still completely baffled by why are we having this thread. > > > > INFO is used by ISUP tunnelling. It's there, we can leave > it alone. As > > far as I know, nobody is trying to improve it. Legacy stuff. No RFC > > required here. > > > > DTMF transport is a null issue since the last remaining > laggars that > > didn't support RFC 2833 now support it. So it is going away and I > > really can't imagine that anybody would bring a draft to > resurect it. > > No RFC required here. > > > > IETF is certainly not going to come up with new INFO > usages. Everytime > > somebody shows up with an INFO idea, he's promptly turned away. > > > > So, what is the "problem" that we are trying to solve? Why are we > > wasting time on this? > > > > Can't we just declare victory and move on? > > > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, October 02, 2007 09:47 > > > To: Stucker, Brian (RICH1:AR00) > > > Cc: [email protected]; Adam Roach; Barnes, Mary (RICH2:AR00) > > > Subject: Re: [Sip] INFO > > > > > > > > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > > > > > > > > > > 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? > > > > > > > > > > This raises the argument that SIP-T should be revisited to more > > > clearly negotiate support for the material being > tunneled, including > > > the context in which it is being tunneled. My UA might, > for example, > > > know how to render an ISUP message using a pretty-printer. That > > > doesn't mean it knows how to do SIP-T for gateways. > > > > > > So, SIP-T is broken and likely to give surprising results. > > > That is not a hearty argument for endorsing the technique > of SIP-T > > > for other functions. > > > > > > > > > > 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. > > > > > > But assume the UA DOES recognize the MIME type. How does it know > > > what to do with it? Is content-disposition adequate? > > > > > > If it were, why would we have the higher-level > negotiation of event > > > contexts? > > > > > > -- > > > 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 > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ 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
