Pl. see inline .. >-----Original Message----- >From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 31, 2007 12:06 AM >To: Paul Kyzivat (pkyzivat); Adam Roach >Cc: sip List; Dean Willis >Subject: RE: [Sip] INFO: A recap, sense of consensus and a >proposal fordirection. > > > >> -----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. I think KPML is more suitable for things like dial-plan match etc. and not for OOB dtmf signaling.
> >The sticky part in my mind has always been what to do if both >info-dtmf were negotiated and 2833/4733 was offered/answered. A UA can have configured preferences, if more than one mechanism is offered. So if it is configured for both info-dtmf and 2833/4733, based on preference it can choose one or the other and provide that in answer response. I am not sure why would some implementation choose info-dtmf over 2833/4733 mechanism. >Or even what to do with in-audio tones. Based on negotiated mechanism, it can ignore the other mechanism. So if info-dtmf is the negotiated mechanism and for a pstn gw, it can instruct the DSP to drop in-band dtmf packets. Thanks. >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 > _______________________________________________ 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
