- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 09 Aug 2012 09:09:15 +0200
- To: public-webrtc@w3.org
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:09:43 UTC