Re: [Bug 18485] Change DTMF API to be on PeerConnection

I agree with Harald, we are discussing the control surface

Harald Alvestrand <harald@alvestrand.no> wrote:

>On 08/09/2012 01:40 AM, Martin Thomson wrote:
>> On 8 August 2012 14:26, Justin Uberti<juberti@google.com>  wrote:
>>> Option D seems like a good way to get what we need without spending too much
>>> effort on this legacy use case.
>> The problem with all of these - D included - is that DTMF is not
>> prearranged at the point that the track is added to the
>> PeerConnection, so either all streams have DTMF negotiated or none do.
>>   The former ensures that some negotiations will fail (or remove DTMF),
>> but will ensure that the DTMF is available everywhere it can be.  The
>> latter forces applications to add DTMF themselves, probably by SDP
>> bashing.
>I don't see that logic - either the browser implementation supports DTMF 
>injection, or it doesn't.
>If it does support it, the only benefit of not offering it in its SDP 
>description seems to be that you save one a=rtpmap line.
>
>If it does not support it, no amount of SDP bashing is going to insert 
>that capability into the browser. Injecting tones using tone generators 
>won't cause RFC 4733 DTMF packets to appear on the wire.
>
>My usual litany: Remember that this is a control surface for an 
>underlying implementation. It is not a manipulation of a "physical" 
>stream of data.
>
>                 Harald
>
>

Received on Thursday, 9 August 2012 07:52:59 UTC