Inconsistencies in description of RTCDTMFToneChangeEvent.tone

[a2sheppy]

The descriptions of the tone attribute on the RTCDTMFToneChangeEvent interface vary throughout the document.

In some places, it's described as indicating that the previous tone has finished playing:

• https://w3c.github.io/webrtc-pc/#dom-rtcdtmftonechangeeventinit-tone
• https://w3c.github.io/webrtc-pc/#event-RTCDTMFSender-tonechange

Here, it's described as indicating that all tones have finished playing and that toneBuffer is empty:

• https://w3c.github.io/webrtc-pc/#dom-rtcdtmftonechangeevent-tone

(a) Which is correct?

(b) The doc needs to be revised to reflect that everywhere.

[aboba]

Looking at the definition of insertDTMF, it would appear that the tonechange event is fired when the toneBuffer is empty.

[a2sheppy]

That’s what I gather as well. The text for the event’s description needs to be updated to match everywhere.

…

On Feb 6, 2017, at 2:37 PM, Bernard Aboba ***@***.***> wrote: Looking at the definition of insertDTMF, it would appear that the tonechange event is fired when the toneBuffer is empty. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1014 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABkL32M1q_oPdLgWBn-Fpx-dcK9ksnELks5rZ3Z_gaJpZM4L4jIP>.

[alvestrand]

The intent of the toneChange event was that it would fire whenever the tone changed - that is, at the end of each tone, including the one that makes the tone buffer empty.
This would be used to do things like move the highlight on a virtual dialpad if you want a visual indication that the tones are playing, or syntesize a "beep" that the user can listen to (there's no automatic feedback to the user that tones are playing).

I think this is consistent with the current description - it always says "indicates the tone that has just begun playing" or equivalent, and listing "empty string" as a special case indicating end of buffer.

If it was fired only when the tone buffer was empty, there would be no use for the "tone" argument.

[alvestrand]

There is an inconsistency that makes it look as if the event fires with an empty string argument at the end of a tone and the beginning of the inter-tone gap, even when the toneBuffer is not empty; I think this is inconsistent and should be removed.

I agree with Bernard's fix for this case.

[a2sheppy]

Certainly. The only question I had was whether it fired only at the end of the buffer, or if it fired for each individual tone, after it finished playing; This would let you know when the inter-tone gap began.

…

On Feb 7, 2017, at 3:35 AM, Harald Alvestrand ***@***.***> wrote: If it was fired only when the tone buffer was empty, there would be no use for the "tone" argument.