W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

Re: [Bug 18485] Change DTMF API to be on PeerConnection

From: Randell Jesup <randell-ietf@jesup.org>
Date: Wed, 08 Aug 2012 10:00:56 -0400
Message-ID: <50227118.1070401@jesup.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 August 2012 14:03:28 GMT