- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 29 Nov 2011 20:59:26 +0100
- 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