Updates from Latest W3C Working Draft 03 August 2016

 Highlights

 Impact on my application

 Standardization status

 Details

 

 Highlights

W3C released a new WebRTC Working Draft of WebRTC1.0 spec. In the change log of the document there is a list of changes since May 2016 (and previous releases). Out of these, we selected 4 items to cover in this post:

  • Clarify MIME (media/sub-) type
  • Clarify effect of RTCRtpReceiver.track.stop()
  • Clarify when setDirection() acts
  • stop() causes negotiation needed to be set

 

 Impact on my application

These changes are all cleanup clarifications related to the large number of new low-level controls accessible via RTCRtpSender, RTCRtpReceiver, and RTCRtpTransceiver.  If you are using these new features you should be prepared for the changes below to make their way into implementations.

 

 Standardization status

All of these changes are in the standard today.

 

 Details

MIME type for Codecs

This change clarified that codecs are selected (e.g., with RTCRtpSender.setParameters()) using the full MIME type and subtype.  For example, H.263 is requested as ‘video/H263’.

RTCRtpReceiver.track.stop()

A track can be sourced locally (local camera or microphone) or remotely (from a Peer Connection).  In the past the specification has been purposely vague as to what changes on the downstream end of a Peer Connection would affect the Peer Connection itself.  The recent change clarified that stopping a remotely-sourced track only affects that track.  Any other tracks sourced from the same Peer Connection (i.e., cloned tracks at the downstream end) are unaffected, as are receiver reports for the RTCRtpReceiver object.  Calling stop on the track does not automatically call stop on the associated RTCRtpReceiver object.

When setDirection() takes effect

RTCRtpTransceiver.setDirection() is the new recommended way to change the direction of the underlying SDP stream.  What was just clarified is that calls to setDirection() do not take effect immediately, but rather cause future calls to createOffer() and createAnswer() to mark the corresponding media description as sendrecv, sendonly, recvonly, or inactive.

RTCRtpTransceiver.stop()

In addition to immediately stopping the sender and receiver associated with the transceiver, the specification now makes clear that the negotiationneeded flag is set as well so the remote transceiver will get updated.