RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction.

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip