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

Re: Where to attach a DTMF API

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Nov 2011 20:59:26 +0100
Message-ID: <4ED5399E.6020106@alvestrand.no>
To: public-webrtc@w3.org
On 11/29/2011 10:41 AM, Neil Stratford wrote:
> On 29/11/2011 08:48, Stefan Håkansson LK wrote:
>> 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.
> It is important that it is possible to send DTMF without any request 
> for microphone access if the call is purely to an informational IVR 
> where the caller is never expected to speak, but still needs to 
> navigate that IVR. Similarly there are cases where DTMF may be 
> required but the call is video only, with no audio component.
>
> How should we handle these cases? Can we create a null audio track 
> using the current API?
>
In Santa Clara, Chris Rogers suggested extending the Audio API with 
objects that create audio streams. It would seem simple to define such 
an object that generates silence.

Unlike Stefan, I think the API makes most sense if it's an API on a 
MediaStreamTrack object. If it is an API on a PeerConnection, it would 
have to be something like PeerConnection.DTMF(StreamID, TrackID, 
"12345"), which seems somewhat bizarre. It could easily be defined to 
generate failure if the other end of the MediaStreamTrack is not a 
playout into a PeerConnection.

We haven't seen a requirement for receiving DTMFs yet. (A few wishes, 
but not a requrement.)
So the DTMF API can be sender-side only.
Received on Tuesday, 29 November 2011 20:00:02 UTC

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