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

The DTMF API [Was: Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)]

From: Justin Uberti <juberti@google.com>
Date: Tue, 15 Nov 2011 01:49:32 -0500
Message-ID: <CAOJ7v-18cNX8xussOPXSEoFxAARu8WriL8XgxPVUXBrWhz=FFg@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>, public-webrtc@w3.org
Cc: rtcweb@ietf.org
On Mon, Nov 14, 2011 at 10:58 AM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 11/14/2011 10:47 AM, Neil Stratford wrote:
>
>> On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <randell-ietf@jesup.orgwrote:
>>    Note my other email I just sent - DTMF has a property not shared by
>>    the data streams - media synchronization.  I won't repeat all the
>>    arguments here, but there actually is a reason for delivering it in
>>    a media channel, totally regardless of legacy.  For a greenfield
>>    design, one *might* implement it as a separate media stream (m=
>>    line), but even there I'm not sure I would mandate it be separated.
>>
>>
>> How can we achieve the media synchronization in WebRTC? In a traditional
>> RTC endpoint the DTMF comes from the same source as the media, in many
>> cases it's actually taken from the media itself. However in WebRTC the
>> only way to trigger a DTMF event is through an asynchronous Javascript
>> function call, which is not synchonized to the media. Do we assume that
>> the function call happens 'at about the right time' and take that as the
>> current timestamp to use?
>>
>
> That speaks to the API needing tweaking - the JS app generally knows
> *when* (in realtime) the event occurred; it should pass that info in with
> the command to send it so the synchronized data can be correctly generated
> (along with the other timing info - duration or ongoing until told to
> stop).  ("When" could also include a special case for "now", defined as the
> current media clock position when the function call is processed.)


One simple option would be to say that the DTMF event occurs when the API
is called. If you need to generate DTMF tones in the future, you can pass
in a full dialstring, or use JS timers. Granted, this will sacrifice some
precision, but given that most DTMF is entered via manual button presses, I
don't see this as an issue.

This needs to be scoped on a per-track basis, since it needs to be sent
with a specific SSRC.

So I would propose an API of the form

[Local]MediaStreamTrack.sendDTMF(in DOMString tones)  // e.g. "1" or "123"
Received on Tuesday, 15 November 2011 06:50:21 UTC

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