Changes to RTCRtpSender Impact WebRTC DTMF APIs

 Highlights

 Impact on my application

 Standardization status

 Details

 

 Highlights

Last week we talked about changes that add more control over video parameters. This post continues to touch changes in RTCRtpSender related to WebRTC DTMF APIs as part of on-going changes for enhanced media control.

As mentioned in one of our earlier posts, the object for inserting DTMF to an audio track has until now been created using the method RTCPeerConnection.createDTMFSender(). Because the RTCRtpSender object is created automatically as soon as the track is being sent over a Peer Connection, the DTMF API has now moved to be part of this object.

 Impact on my application

This is an API change that would impact anyone dealing with DTMF in his application.

 Standardization status

The DTMF change is in the most recent Editors’ Draft of the WebRTC Specification.

 Details

Adding DTMF to an audio track originally required the use of RTCPeerConnection.createDTMFSender(), a helper method that let the browser know to allow (negotiate for) DTMF on a particular track sent over a particular Peer Connection.  The result of calling that method was a new RTCDTMFSender object with the following properties:

  • canInsertDTMF:  readonly attribute indicating whether the track is ready to accept DTMF tones
  • insertDTMF(tonestring, [duration, [interToneGap]]):  plays the given DTMF tones, optionally changing duration and interToneGap
  • ontonechange:  can be set to an event handler that will be executed whenever a tone is played out
  • toneBuffer:  readonly attribute containing the tones remaining to be played out
  • duration:  readonly attribute indicating the current tone duration
  • interToneGap:  readonly attribute indicating the current gap between tones.

Because there is now an RTCRtpSender object that exists as soon as a track starts being sent over a Peer Connection, the DTMF API has moved there.  Specifically, the RTCPeerConnection.addTrack() method returns an RTCRtpSender, whose ‘dtmf’ property exists when the track can accept DTMF tones.  The RTCRtpSender.dtmf object has the following properties:

  • insertDTMF(tonestring, [duration, [interToneGap]]):  plays the given DTMF tones, optionally changing duration and interToneGap
  • ontonechange:  can be set to a handler that will be executed whenever a tone is played out.
  • toneBuffer:  readonly attribute containing the tones remaining to be played out
  • duration:  readonly attribute indicating the current tone duration
  • interToneGap:  readonly attribute indicating the current gap between tones.

As you can see, the only difference in the DTMF API is the removal of the canInsertDTMF attribute, since the presence or absence of the RTCRtpSender.dtmf object takes its place.