Comments inline. Cheers, Gilad
> -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 12, 2007 3:14 PM > To: Rafferty, James; Gilad Shaham; Steve Langstaff; Spencer Dawkins; > Robert Sparks; Jonathan Rosenberg > Cc: [email protected] > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > Hi, > > >I like the idea of being clear where SIP INFO belongs > >(arguably only for use with SIP-T) and then having a BCP > >which identifies common places where SIP INFO is being used > >today, and then references the preferred practice (typically > >not using SIP INFO) or work in progress (for example, the > >mediactrl work) which will result in new practices. > > > >The problem from a manufacturer's standpoint is that > >customers have existing products (for example, gateways) that > >use SIP INFO for DTMF passage and they insist on having > >compatibility with these bad practices built into other > >products, thus perpetuating the cycle of bad practice. > >A BCP might at least point the preferred way out of this mess. > > Normally, when we produce BCP type of documents, it's because there is a > problem out there (people implement specs in different, uninteroperable, > ways etc). > > 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. 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. > > 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
