W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2011

Re: DTMF again

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 15 Dec 2011 03:20:33 -0500
Message-ID: <4EE9ADD1.2030200@jesup.org>
To: public-webrtc@w3.org
On 12/15/2011 3:04 AM, Timothy B. Terriberry wrote:
>> telephone-event). Harald had suggested that the DTMF API only be present
>> on a stream if that stream supports DTMF, but I'd like to get more
>> feedback from others (especially folks with WebIDL experience) on that
>> approach.
> The question raised on the call was whether or not this is something
> that can change during the lifetime of a MediaStream. I had a chat about
> this with Boris Zbarsky. He says it's relatively hard to do something
> like this for us because of the way our DOM bindings for ECMAScript
> work, unless the object is actually a special kind of object (e.g.,
> MediaStreamWithDTMF), and that while APIs appearing might be marginally
> acceptable, APIs disappearing is pretty bad form.
> As far as I understand O/A, the remote side can revise its offer or
> answer to add or remove support for a DTMF codec at any time (though I
> would not typically expect it to do so), so this seems like a problem.

Well, on a revised offer and answer, if there's an incompatibility you 
could in theory remove the old track, and add a new one with different 
APIs.  This might cause glitches or other artifacts which might not 
otherwise be needed.

While quite rare, I'd say that addition/removal of DTMF after a call 
starts is not quite impossible.  The primary case might be an initial 
stream of "early media" (eg ringback) with no DTMF, and then when 
connected to the actual destination DTMF may be enabled.  There's 
probably an even less common case for removal.

That said - I'd rather avoid jumping through hoops to handle 
addition/removal of the interface.  Also, nothing says DTMF as an 
alternate packet encoding (2833/etc) has to be accepted in order to send 
DTMF - if it isn't, then the tones can be sent in-band.  (And hope that 
a codec that can handle them is selected.)  So I'd suggest having the 
API there always.  It sends 2833/etc if possible, and if not it *MAY* 
send the tones as in-band audio (I wouldn't require it).

Randell Jesup
Received on Thursday, 15 December 2011 08:25:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC