WebRTC standard work highlights from W3C Sapporo Japan and IETF 94 Yokohama Japan meetings

 Highlights

 Impact on my application

 Standardization status

 Details

 

 Highlights

In the last few weeks there were 2 important meetings in Japan. First was the W3C meeting at the end of October and then there was the IETF 94 meeting early November. In this post we want to list some of the items discussed.

It is important to note a few things:

  • Discussions are getting more into the edge cases – this means that the core of the standard is pretty much finalized; hence, edge cases are now being addressed
  • Lower level controls are increasingly making their way into the API – this requires better understanding of those layers of the protocols. The bright side of this is that most of these controls are not mandatory to be used by developers but are available for those that want better control

 

 Impact on my application

Some of these items are revisions or enhancements of previous decisions, and they may make it into actual deployment fairly rapidly.

 

 Standardization status

The status varies by item. Most of these have gone into the various specifications, but some are still being tweaked.

 

 Details

W3C

RtpTransceivers

Many details around RtpTransceivers and how they interact with addTrack, removeTrack, and rollback upon receipt of remote answer.

Rollback – After sending an offer one can send media. If the SDP answer removed some of the media offered, the offering side might need to do a rollback in his state and m-lines.

 

Codec selection *before* offer/answer

Earlier we discussed how to reorder and remove codecs after SDP was negotiated; this is about doing so before offer/answer begins.

 

IP address leakage (again)

This item has being discussed several times. It boils down now to only revealing the host candidate of the default route for privacy reasons.

 

Simulcast, RIDs (RTP source stream ID), and ScaleResolutionDownBy

A new identifier is added to SDP that will give the ability to negotiate simulcast flows using the same payload type for all of the encodings.

 

Confirmed that outstanding Promises fail on PC close

Asynchronous methods return Promises. If the Promise is still pending – hasn’t been resolved (meaning completed) or rejected yet – and the Peer Connection was closed then all pending Promises will be rejected (meaning failed).

 

New API for getting default ICE servers

Allows the application to get the ICE servers (STUN/TURN) the browser knows about by default. This is good for enterprise environments where these might be set by IT.

 

setParameters to become asynchronous

As the title says, this will change the method to be asynchronous. Required because it sometimes takes time for this method to complete.

 

New “Media Capture in Workers” spec

Workers are for separate JS threads. This specification defines how media capture can be used in this way.

 

Progress on Media Capture from DOM elements and Screen Capture

We have published information about this before. There was progress on this topic, and we will send further updates about it.

 

IETF

Support for non-mux RTCP no longer required

Before today one could decide whether to support multiplexing of RTP and RTCP on the same port; this is no longer an option. Since support for non multiplexing is not mandatory anymore, an application not supporting RTCP multiplexing will suffer from interoperability issues.

 

RIDs – for simulcast, allow using the same payload type for all encodings

Mentioned above with regards to W3C APIs but naturally this also impacts SDP.

 

More discussion on choosing candidate early

Everyone wants to get media flowing as early as possible to avoid connection delay. The question is how to pick the best candidate to use first?

 

“Passive aggressive nomination” will improve DTLS startup

Aggressive nomination of ICE pairs is when media is sent before a candidate pair is nominated. Applications are now discouraging from using this method, but if the remote application does use it towards your application it should passively accept it.

 

ECDSA now MTI along with existing RSA

This has to do with the algorithm for creating the DTLS keys (the cipher suite to use). ECDSA is now mandatory along with RSA..