In my opinion, content-type is not good enough. What would one do if it is Multipart-Mixed? We are talking about something general, right? What if the same content type is to be used for 2 different info usages?
Christer asked if there are real life problems with using INFO for DTMF, I think it's one of the problems today with INFO in general. I'm sure it can be solved (e.g., the old draft Dean sent), but it still requires change in the spec. Returning to the question, "why not do INFO for DTMF?". Let's assume there are good solutions to all the problems one can find with INFO for DTMF then: 1. It might be different than existing implementations therefore implementors that already have it will still need to change their implementation. 2. It might simply provide a subset/same functionality KPML provides. Regards, Gilad > -----Original Message----- > From: Diego B [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 12, 2007 8:46 PM > To: Gilad Shaham > Cc: Christer Holmberg (JO/LMF); [email protected]; Rafferty, James; Steve > Langstaff > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > > Inline > > Gilad Shaham wrote: > > Hi, > > > > Here is another major problem with INFO - there is no header that states > > the purpose of INFO. > > > If the conte-type is correct, the payload is a DTMF digit. No needs for > a special header. > > The event header in subscriptions helps identify an event package. > > Therefore an implementation can easily detect if this event package is > > supported or not. > You can state in the Accept header that you support the content-type for > the DTMF paylod ( application/dtmf or application/dtmf-relay ) > > With INFO it is much harder to detect the purpose of > > this INFO message. Currently AFAIK the content-type in INFO implicitly > > denotes this. > > > > > So, why is harder ? > > If you are aiming towards a solution that keeps INFO for more usages, I > > would say that we need to resolve this issue first. > > > > > I do not see any issue here > > I also think it would be a burden on implementors to do both KPML and > > INFO. Wouldn't it be easier for the implementors that did INFO to switch > > to KPML instead of the entire industry doing both? > > > > > INFO is very easy to implement. So I dont't see any problem to keep the > INFO implementation > until KPML is adopted. Or maybe keep both. > > Gilad > > > > > Diego B > >> -----Original Message----- > >> From: Christer Holmberg (JO/LMF) > >> > > [mailto:[EMAIL PROTECTED] > > > >> Sent: Tuesday, June 12, 2007 3:56 PM > >> To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins; > >> Robert Sparks; Jonathan Rosenberg > >> Cc: [email protected] > >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >> > >> > >> Hi, > >> > >> > >>>> Are we aware of real-life problems with using INFO for DTMF (or > >>>> > >> whatever > >> > >>>> else it's used for)? People have been doing it for a while (if we > >>>> > >> wanted > >> > >>>> to restrict something, it should have been done years ago...), it's > >>>> fairly simple to implement - and it seems to work. > >>>> > >>> Do we need DTMF via INFO for some kind of functionality KPML (or RFC > >>> 2833) does not provide? I'm not aware of such a case. > >>> > >> Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no > >> matter if you use INFO or something else) is when you send them to an > >> entity which does not have media access. > >> > >> > >>> One description of a problem with INFO can be found in this > >>> > > historical > > > >>> chat: > >>> http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html > >>> > >>> The explanation from the expired draft is as follows: > >>> > >>> Under this proposal, a User Agent MUST NOT send signaled > >>> digits or telephone-events using the INFO method if the event > >>> was ever represented as a tone (as media). Only signals > >>> originated as pure signaling MAY generate an INFO method. > >>> Failure to heed this requirement will result in > >>> double-detection of digits/events. > >>> > >>> If INFO is used incorrectly by a pair of PSTN gateways (for > >>> example), the source gateway may detect a digit, send an INFO > >>> request which is lost, and retransmit that request. The > >>> target gateway would send the original in-band tone to the > >>> PSTN when the audio media arrives, later when the INFO > >>> arrives, the target gateway would render the same tone again. > >>> It is quite likely that the INFO will arrive after the media > >>> tone has been played (especially if multiple intermediaries > >>> are involved); the same digit would be played out again and > >>> this will frequently cause systems in the PSTN to detect the > >>> same digit signaled twice. > >>> > >> You can always mess up if you use things incorrectly. I don't think > >> > > that > > > >> is INFO specific. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >>> > >>> > >>> > >>>> The only problem is that much of the INFO usages are not defined > >>>> > > in > > > >>>> RFCs, but that's not always the fault of the implementors... > >>>> > >>> I think the implementors knew this was not standard or at > >>> most in very early draft mode when they implemented it. > >>> > >>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > > > > > > _______________________________________________ > > 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
