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

Where to attach a DTMF API

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 29 Nov 2011 09:48:11 +0100
Message-ID: <4ED49C4B.2000106@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
(In role of contributor):

On the rtcweb mail list a DTMF API has been proposed 
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg02887.html).


sendDTMF(in DOMString tones, in optional long duration)

ex:
sendDTMF("1")  // plays tone 1 for 50 ms
sendDTMF("2", 200)  // plays tone 2 for 200 ms
sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for 200 ms

I don't have enough of insight in DTMF to comment on the options in the 
sendDTMF method, but I have a comment on what object the method should 
be available on:

I the mail referenced, sendDTMF is a method on MediaStreamTrack. I think 
the method should apply on PeerConnection because my understanding is 
that the idea is to generate RTP-packets according to RFC4733, not to 
insert tones in the audio. This means that "sendDTMF" has really no 
meaning outside a PeerConnection.

I understand that this means that there are some other things that has 
to be met:
* There must be an audio MediaStreamTrack in at least one of the 
localStream's (that the DTMF RTP packets can share SSRC with)
* If there are several outgoing audio RTP streams (having different 
SSRC's), it must be possible to understand (control?) which SSRC that 
will be reused by DTMF.

My very simple proposal for this would be that the DTMF RTP packets will 
share SSRC with the first audio track of the first MediaStream that has 
at least one audio track. If there is no such MediaStream in 
localStream's, then "sendDTMF" will fail.

I realize that this will be a bit cumbersome to use for the application 
developer, but my counter argument would be: webrtc is primarily for 
browser-to-browser (I even think the charter says so), and should be 
simple to use for this case, but could be allowed to be cumbersome to 
use for other cases. Of course the complexity can be hidden by a library.

(If we instead do adopt a model where DTMF is in fact represented by 
tones - but for a connection transported according to RFC4733 - then it 
would make sense to attach sendDTFM to a MediaStream or MediaStreamTrack 
object)

My $0.05
Stefan
Received on Tuesday, 29 November 2011 08:48:44 UTC

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