> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 30, 2007 2:13 PM > To: Adam Roach > Cc: Hadriel Kaplan; sip List; Dean Willis > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > The obvious first case to consider is DTMF. The problem of course is > that we already have two standard methods for transfering DTMF > (telephone-events in RTP, and KPML subscriptions.) So standardizing use > of INFO for this would mean standardizing a *different* way than KPML. > And most likely it would be different than the non-standard way(s?) of > using INFO for DTMF in the wild. Is that going to do anybody any good, > or just give people more heartburn? Perhaps we should either bless what > is being used or else continue to treat it with benign neglect.
My vote would be to re-use the most common one, which I think is the application/dtmf-relay one. If for no other reason than to make it as easy as possible, for as many non-standard implementations as possible, to implement the negotiation and follow a standard. KPML is orthogonal to info-dtmf. It has its own use cases, if people want to use it. The sticky part in my mind has always been what to do if both info-dtmf were negotiated and 2833/4733 was offered/answered. Or even what to do with in-audio tones. I *think* the answer is info-dtmf should trump 2833 - i.e., if you negotiated info-dtmf only do that, for a variety of reasons; but with delayed SDP offers that would mean you'd always end up using info-dtmf when you could have done 2833 instead. And I can see the argument for "do both", and that's what kpml did except it has the suppression/<pre> concept, but I assumed that was due to pattern matching being inconsistent with in-band event sending one-at-a-time. But I still think info-dtmf trumping would be right, because the tones will get to the far end if they should. -hadriel _______________________________________________ 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
