Hi, >Here is another major problem with INFO - there is no header >that states the purpose of INFO. >The event header in subscriptions helps identify an event package. >Therefore an implementation can easily detect if this event >package is supported or not. With INFO it is much harder to >detect the purpose of this INFO message. Currently AFAIK the >content-type in INFO implicitly denotes this.
If I send a DTMF digit, the purpose is to send a DTMF digit :) >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 am just trying to figure out what the problem really is. Regards, Christer >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? > > -----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
