[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"
- [rtcweb] The DTMF API [Was: Traffic should be enc… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Randell Jesup
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Hadriel Kaplan
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Hadriel Kaplan
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Jonathan Lennox
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Randell Jesup
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Matthew Kaufman
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Eric Rescorla
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Roman Shpount
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Roman Shpount
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Michael Thornburgh
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Roman Shpount
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Justin Uberti
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Neil Stratford
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Hadriel Kaplan
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Randell Jesup
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Randell Jesup
- [rtcweb] DTMF usecase before DTMF API [was RE: Th… Ravindran, Parthasarathi
- Re: [rtcweb] DTMF usecase before DTMF API [was RE… Harald Alvestrand
- Re: [rtcweb] DTMF usecase before DTMF API [was RE… Hadriel Kaplan
- Re: [rtcweb] DTMF usecase before DTMF API [was RE… Hadriel Kaplan
- Re: [rtcweb] DTMF usecase before DTMF API [was RE… Wolfgang Beck
- [rtcweb] Support DTMF "codec" or expose DTMF in s… Harald Alvestrand
- Re: [rtcweb] DTMF usecase before DTMF API [was RE… Matthew Kaufman
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Matthew Kaufman
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Iñaki Baz Castillo
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Matthew Kaufman
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Saúl Ibarra Corretgé
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Iñaki Baz Castillo
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Matthew Kaufman
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Matthew Kaufman
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Iñaki Baz Castillo
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Hadriel Kaplan
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Justin Uberti
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Iñaki Baz Castillo
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Roman Shpount
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Justin Uberti
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Roman Shpount
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Mary Barnes
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Roman Shpount
- Re: [rtcweb] Support DTMF "codec" or expose DTMF … Christer Holmberg
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Tim Panton
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Randell Jesup
- Re: [rtcweb] The DTMF API [Was: Traffic should be… Roman Shpount