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
