DTMF available in Firefox 52
Firefox 52 now supports DTMF. Try it out now in webrtc samples! This means you no longer need workarounds to accomplish this.
In the new API, the
dtmf sender already exists, so you don’t create it. It hangs off of the RTCRtpSender associated with a track. So instead of writing the following Chrome-only code:
dtmf = pc.createDTMFSender(audioTrack); dtmf.insertDTMF("112233");
you now write:
sender = pc.getSenders().find(sender => sender.track == audioTrack); sender.dtmf.insertDTMF("112233");
The latter is the most browser-compatible way to obtain the sender right now. You can also get the sender as the return value of
pc.addTrack(), but only Firefox supports tracks at the moment.
On the signaling side, it is more straightforward. An offer indicating support for DTMF contains an additional payload type on the audio line with a corresponding rtpmap for “telephone-event”. If Firefox generates the offer, the DTMF payload type is typically 101, whereas Chrome usually uses 126. If the answer supports DTMF, the DTMF payload type will be included with the other audio codecs in the m= line for audio.
The base DTMF RFC (RFC 4733) allows for sending DTMF events for each of the digits (0-9), ‘*’ (asterisk), ‘#’ (hash or pound), letters A-D, plus a few other special events that all come from the legacy POTS (Plain Old Telephone Service) days. However, the WebRTC spec (RFC 7874) says events 0-15 (digits 0-9, A-D, ‘*’, and ‘#’) are required and nothing else is allowed. All that to say, you may or may not see an fmtp line that specifies that events 0-15 are supported. Either way, 0-15 are supported.
Given that the main use of DTMF is to call into “legacy” systems, we haven’t been able to test it extensively. We’ve tested against WebRTC samples and written some unit tests, but we could use some help with testing it against real systems. Please try it out and file a bug if you hit any problems!
(Thanks to Jan-Ivar and Michael for significant contributions this post)