← View all posts
February 22, 2017

DTMF available in Firefox 52

Contributed by dminor@mozilla.com,

Firefox 52 now supports DTMF. Try it out now in webrtc samples! This means you no longer need workarounds to accomplish this.

The spec JavaScript API we’ve implemented is newer and different from what is in Chrome at the moment. Therefore, we recommend using adapter.js until Chrome updates their API. That way, you only deal with one API that works on all browsers.

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);

you now write:

    sender = pc.getSenders().find(sender => sender.track == audioTrack);

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.

Signaling side

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)