Bug 18485 - Change DTMF API to be on PeerConnection
Change DTMF API to be on PeerConnection
Status: RESOLVED FIXED
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API
unspecified
PC Linux
: P2 normal
: ---
Assigned To: Web RTC Working Group
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-03 23:57 UTC by Harald Alvestrand
Modified: 2013-06-13 07:39 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Alvestrand 2012-08-03 23:57:56 UTC
Implementing the proposed DTMF API has turned out to be surprisingly complex compared to the importance of the feature; the typing requirements for MediaStream seem to be heavily complicated by it.

Tommy Widenflycht has suggested instead that we define calls to make available:

pc.canSendDTMF(MediaStreamTrack)
pc.sendDTMF(MediaStreamTrack, tones, duration)

This has no impact on the definition of MediaStream and allows implementation of sendDTMF without touching anything but PeerConnection.
Comment 1 Harald Alvestrand 2012-08-08 09:50:21 UTC
based on discussion on the list, there seems to be 3 alternate descriptions of what sendDTMF actually does.

I outline them below as text that can be inserted into the description.

A) 
1) If the track argument to sendDTMF is not an audio track connected to this PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been negotiated, throw a <IllegalParameter> exception.
2) Send the tones using RFC 4733 signalling.

B)
1) If the track argument to sendDTMF is not an audio track connected to this PeerConnection, throw an <illegalParameter> exception.
2) If sendDTMF is connected to an outgoing SSRC where use of RFC 4377 is negotiated, send the tones using RFC 4377 and return.
3) Insert the corresponding tones into the media stream as if they were coming from the media source.

C)
1) If sendDTMF is connected to an outgoing SSRC on this PeerConnection where use of RFC 4377 is negotiated, send the tones using RFC 4377 and return.
2) Insert the corresponding tones into the media stream as if they were coming from the media source.

The difference between B) and C) is that B) insists on using the right PC to generate tones.
Comment 2 Stefan Hakansson LK 2012-08-08 10:23:07 UTC
(In reply to comment #1)

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.



> based on discussion on the list, there seems to be 3 alternate descriptions of
> what sendDTMF actually does.
> 
> I outline them below as text that can be inserted into the description.
> 
> A) 
> 1) If the track argument to sendDTMF is not an audio track connected to this
> PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been
> negotiated, throw a <IllegalParameter> exception.
> 2) Send the tones using RFC 4733 signalling.
> 
> B)
> 1) If the track argument to sendDTMF is not an audio track connected to this
> PeerConnection, throw an <illegalParameter> exception.
> 2) If sendDTMF is connected to an outgoing SSRC where use of RFC 4377 is
> negotiated, send the tones using RFC 4377 and return.
> 3) Insert the corresponding tones into the media stream as if they were coming
> from the media source.
> 
> C)
> 1) If sendDTMF is connected to an outgoing SSRC on this PeerConnection where
> use of RFC 4377 is negotiated, send the tones using RFC 4377 and return.
> 2) Insert the corresponding tones into the media stream as if they were coming
> from the media source.
> 
> The difference between B) and C) is that B) insists on using the right PC to
> generate tones.
Comment 3 Stefan Hakansson LK 2012-08-08 15:16:10 UTC
(In reply to comment #1)
> based on discussion on the list, there seems to be 3 alternate descriptions of
> what sendDTMF actually does.
> 
> I outline them below as text that can be inserted into the description.
> 
> A) 
> 1) If the track argument to sendDTMF is not an audio track connected to this
> PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been
> negotiated, throw a <IllegalParameter> exception.

Minor note: should not an <NotSupported> exception be thrown? At least if RFC4733 has not been negotiated. Not sure <IllegalParameter> is an allowed exception, at least it is not listed here: http://www.w3.org/TR/domcore/#domexception

> 2) Send the tones using RFC 4733 signalling.
> 
> B)
> 1) If the track argument to sendDTMF is not an audio track connected to this
> PeerConnection, throw an <illegalParameter> exception.
> 2) If sendDTMF is connected to an outgoing SSRC where use of RFC 4377 is
> negotiated, send the tones using RFC 4377 and return.
> 3) Insert the corresponding tones into the media stream as if they were coming
> from the media source.
> 
> C)
> 1) If sendDTMF is connected to an outgoing SSRC on this PeerConnection where
> use of RFC 4377 is negotiated, send the tones using RFC 4377 and return.
> 2) Insert the corresponding tones into the media stream as if they were coming
> from the media source.
> 
> The difference between B) and C) is that B) insists on using the right PC to
> generate tones.
Comment 4 Cullen Jennings 2012-08-13 14:52:28 UTC
There is active list discussion on this. I think everyone agrees the current spec is not good and needs a change but not clear yet exactly how to fix this.
Comment 5 Harald Alvestrand 2012-08-15 08:38:15 UTC
Based on further discussion, a need has been identified to play back tones in synchronity with the DTMF signals going out. This functionality removes the need for the ability to play out tones on local streams only, since it solves the use case that was intended for. The interface should then become:

pc.canSendDTMF(MediaStreamTrack)
pc.sendDTMF(MediaStreamTrack outTrack, tones, duration, optional MediaStreamTrack localTrack)

with the handling rule being:

1) If the outTrack argument to sendDTMF is not an audio track connected to this
PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been
negotiated, throw a <ArgumentError?> exception.
2) Simultaneously do the following:
- Send the tones using RFC 4733 signalling on the outTrack
- If the localTrack is specified, play out an appropriate audio feedback signal using this track, making sure that sound from localTrack does not feed back into outTrack.
Comment 6 Harald Alvestrand 2012-10-17 08:38:30 UTC
The previous suggestion, with a track on which feedback would be given, gave some pushback - what the feedback should be, whether a track is the appropriate form of feedback, and so on.

New suggestion (still not valid IDL):

pc.canSendDTMF(MediaStreamTrack)
pc.sendDTMF(MediaStreamTrack outTrack, tones, duration, optional callback)

with the handling rule being

1) If the outTrack argument to sendDTMF is not an audio track connected to this
PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been
negotiated, throw a <ArgumentError?> exception.
2) Simultaneously do the following:
- Send the tones using RFC 4733 signalling on the outTrack
- Every time a tone starts and stops, call the callback with either the character of the tone being played or an empty string argument.

Then people can do whatever they like with the feedback tone.

Is this simple enough to let us close this issue?
Comment 7 Harald Alvestrand 2012-10-17 09:44:49 UTC
On review of previous comments ... the error thrown should be <NotSupported>, according to Stefan's comment.
Comment 8 Harald Alvestrand 2013-06-13 07:39:26 UTC
Closed as fixed. API is in the spec, and is implemented in Chrome.