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
