RTCDtmfSender Sync #215

Closed
aboba opened this Issue Jun 18, 2015 · 2 comments

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Jun 18, 2015

The latest WebRTC 1.0 API specification (see http://w3c.github.io/webrtc-pc/archives/20150611/webrtc.html#rtcdtmfsender) provides a revised Peer-to-peer DTMF API in Section 7 which extends the RTCRtpSender interface. This issue was filed to track differences between the WebRTC 1.0 RTCDtmfSender and the ORTC API RTCDtmfSender.

@aboba aboba added the 1.0 label Jun 18, 2015
@aboba
Contributor
aboba commented Jun 20, 2015

Looking over the text, the major difference between WebRTC 1.0 and ORTC API is that WebRTC 1.0 contains the following text describing insertDTMF in Section 7.2.2:

7.2.2 Methods

insertDTMF
An RTCDTMFSender object's insertDTMF() method is used to send DTMF tones.

The tones parameter is treated as a series of characters. The characters 0 through 9, A through D, #, and * generate the associated DTMF tones. The characters a to d are equivalent to A to D. The character ',' indicates a delay of 2 seconds before processing the next character in the tones parameter. All other characters must be considered unrecognized.

The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 ms or less than 40 ms. The default duration is 100 ms for each tone.

The interToneGap parameter indicates the gap between tones. It must be at least 30 ms. The default value is 70 ms.

The browser may increase the duration and interToneGap times to cause the times that DTMF start and stop to align with the boundaries of RTP packets but it must not increase either of them by more than the duration of a single RTP audio packet.

ISSUE
How are invalid values handled?

When the insertDTMF() method is invoked, the user agent must run the following steps:

Set the object's toneBuffer attribute to the value of the first argument, the duration attribute to the value of the second argument, and the interToneGap attribute to the value of the third argument.
If toneBuffer contains any unrecognized characters, throw an InvalidCharacterError exception and abort these steps.
If toneBuffer is an empty string, return.
If the value of the duration attribute is less than 40, set it to 40. If, on the other hand, the value is greater than 6000, set it to 6000.
If the value of the interToneGap attribute is less than 30, set it to 30.
If a Playout task is scheduled to be run; abort these steps; otherwise queue a task that runs the following steps (Playout task):
If toneBuffer is an empty string, fire an event named tonechange with an empty string at the RTCDTMFSender object and abort these steps.
Remove the first character from toneBuffer and let that character be tone.
Start playout of tone for duration ms on the associated RTP media stream, using the appropriate codec.
Queue a task to be executed in duration + interToneGap ms from now that runs the steps labelled Playout task.
Fire an event named tonechange with a string consisting of tone at the RTCDTMFSender object.
Calling insertDTMF() with an empty tones parameter can be used to cancel all tones queued to play after the currently playing tone.

@aboba
Contributor
aboba commented Jun 20, 2015

Minor differences include the default duration (100 ms in WebRTC 1.0, 70 ms in ORTC API), and the spelling of the object (RTCDTMFSender in WebRTC 1.0, RTCDtmfSender in ORTC).

@robin-raymond robin-raymond pushed a commit that referenced this issue Jun 22, 2015
Robin Raymond Addressed Philipp Hancke's review comments, as noted in: Issue #198
Added the "failed" state to RTCIceTransportState, as noted in: Issue #199
Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue #200
Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in: Issue #207
Updated the description of RTCIceGatherer.close() and the "closed" state, as noted in: Issue #208
Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue #214
Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue #215
Clarified state transitions due to consent failure, as noted in: Issue #216
Added a reference to [FEC], as noted in: Issue #217
894b08b
@aboba aboba closed this Jun 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment