Hadriel, Are those applications necessarily on the INFO path? KPML doesn't require the applications to be on the INFO path.
I believe plenty of SIP devices only support RFC 2833, not INFO, and those that do support INFO are likely to do so in different ways, because it is not standardised. So how can the application provider be sure, even with INFO, that there will be devices to support it? John > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 03 October 2007 20:06 > To: 'Francois Audet'; 'Dean Willis'; 'Brian Stucker' > Cc: [email protected]; 'Adam Roach'; 'Mary Barnes' > 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 > _______________________________________________ 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
