- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Wed, 08 Aug 2012 10:00:56 -0400
- To: public-webrtc@w3.org
On 8/8/2012 8:43 AM, Stefan Hakansson LK wrote: > On 08/08/2012 12:52 PM, Harald Alvestrand wrote: >> [Continuing discussion on list] >> >> I updated the bug in order to solicit views from the WG - would you >> prefer A, B or C? >>> As for alternatives B and C, I think that the tones should not be >>> inserted in >>> the same MediaStream as the outgoing DTMF. The tones are to be used >>> for local >>> feedback, and you would not like to play the other outgoing audio >>> locally. >>> >>> I think we should go for alternative A initially. >> My thought was that if an app wants ringback of the tones, he does: >> >> incomingStream = pc.remoteStreams[0].audioTracks[0] >> outgoingStream = pc.remoteStreams[0].audioTracks[0] > Guess it should read > outgoingStream = pc.localStreams[0].audioTracks[0] >> >> pc.sendDTMF(outgoingStream, "12345") >> pc.sendDTMF(incomingStream, "12345") >> >> the two should then play out at ~ the same time. >> >> I don't want to force there to be always ringback present - that's app >> dependent. Agree. > I agree, and this makes sense. Personally I don't have a strong opinion, > we could go for A (the web author wanting local feedback could easily > accomplish that with a audio element and some files with tones), B or C. This causes problems for speakerphone situations: in many/most implementations (including those based on the webrtc.org code), <audio>/<video> elements not part of the core webrtc logic may not be fed into the echo canceller. This means the tone would echo uncontrolled into the microphone and to the far end, but distorted and out of phase with local generation of DTMF (or for IVR systems, possibly cause confusion, though probably not). > We could even consider an alternative D: > > pc.canSendDTMF(MediaStreamTrack) > pc.sendDTMF(MediaStreamTrack, tones, duration, optional MediaStreamTrack) > > where tones are inserted in the audio of the second (optional) > MediaStreamTrack supplied. Personally, I'd have SendDTMF() operate on a MediaStreamTrack, and be an event. This would mean that if you have a MediaStreamTrack connected to two PeerConnections (quite possible), the event would be cloned and bubble up to both PeerConnections, which would then send DTMF (if possible). I'd have PlayDTMF() operate on a track in remote or localstream via PeerConnection, and it would insert tones. However, this doesn't mean you have to change things; it could be the app's responsibility to call pc.SendDTMF when a DTMF event arrives on the MediaStream, instead of that being an automatic-but-overridable behavior. My general preference is to provide default actions for these sorts of things, though, so simple apps can be simple. And the distinction between SendDTMF and PlayDTMF is basically that PlayDTMF only inserts tones, so it's not strictly necessary unless you think the app needs the ability to NOT send RFC 4733 even if it was negotiated. -- Randell Jesup randell-ietf@jesup.org
Received on Wednesday, 8 August 2012 14:03:28 UTC