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

Justin Uberti <juberti@google.com> Tue, 15 November 2011 06:49 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637DE11E8094 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 22:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.926
X-Spam-Level:
X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b88cGDKL+M-O for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 22:49:53 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AF21F8B15 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 22:49:53 -0800 (PST)
Received: by iaeo4 with SMTP id o4so10461348iae.31 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 22:49:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=6aeIqh7eBXpi+EuomA0XuCecMmGkXXXVRvMq5xUhsA4=; b=msORGQPTBhzW+yKQbTLfI3965pUL+KqdS6ETMWQV8YM58fHNVQ4jdMZU1O+IckBnkS yN1TUouI+EqDSBF3VT/Q==
Received: by 10.50.169.97 with SMTP id ad1mr26938694igc.35.1321339793269; Mon, 14 Nov 2011 22:49:53 -0800 (PST)
Received: by 10.50.169.97 with SMTP id ad1mr26938683igc.35.1321339793098; Mon, 14 Nov 2011 22:49:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 22:49:32 -0800 (PST)
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
Content-Type: multipart/alternative; boundary="e89a8f2359a9fec8b104b1c0644d"
X-System-Of-Record: true
Cc: rtcweb@ietf.org
Subject: [rtcweb] The DTMF API [Was: Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2011 06:49:54 -0000

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"