- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 29 Nov 2011 09:48:11 +0100
- 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