Hi, >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?
The application you're currently using should know what to do with it. >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. What real-life problems are there with using INFO for DTMF? Regards, Christer > > -----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
