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

Re: DTMF again

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 15 Dec 2011 15:41:29 +0100
Message-ID: <4EEA0719.2020109@ericsson.com>
To: public-webrtc@w3.org
On 12/15/2011 09:20 AM, Randell Jesup wrote:
> 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).

I support this view! I would like to add that it becomes quite messy to 
say if an AudioMediaStreamTrack supports dtmf or not: what if the track 
is attached to two PeerConnection objects; one of them connects to a 
DTMF capable GW, the other not. You can't say if this track supports 
DTMF or not. So it is best to have the API there always.

(This was one of the reasons why I originally proposed that DTFM should 
be a method on PeerConnection - but we've moved away from that now)
Received on Thursday, 15 December 2011 15:29:53 UTC

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