W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

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

From: Alexey Aylarov <alexey@zingaya.com>
Date: Thu, 09 Aug 2012 11:50:40 +0400
Message-ID: <5gcgut1b59b6j68t8smqq3og.1344498640429@email.android.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:32 UTC