WebRTC SDP Codec Priority Reordering and Subseting

 Highlights

 Impact on my application

 Standardization status

 Details

 

 Highlights

In a previous post we reviewed topics discussed at the W3C interim meeting held on September 9 to 10th. In this post we provide further details on WebRTC SDP codec priority reordering and subseting.

W3C decided to allow an API mechanism to get the list of negotiated codecs and reorder codec priority or even remove codecs from the list. Functionality is introduced both for RTCRtpSenders and RTCRtpReceivers.  The details are being worked out.

 

 Impact on my application

Gives control over what codec will actually be used in a communication.

 

 Standardization status

This new feature is now in the most recent editors’ draft of the specification so it will be part of WebRTC 1.0.

 

 Details

One of the most requested controls on a Peer Connection is to be able to choose the codec that is being used without having to edit SDP.

Once an SDP offer/answer has been completed and a connection created, the new functionality enables applications to change the priority of codecs or even remove codecs from the list. Doing this will not cause renegotiation of SDP but rather impact what codec the browser will send. For example, if both peers listed G.711 and Opus, in that order, the browsers would start using G.711. Using the API, the application on one peer may change the priority order and put Opus first; this in turn will cause the browser of that peer to switch from G.711 to Opus.

It is important to note that the browser may switch at any time among the codecs negotiated (present on SDP list of both peers), based on its own algorithms and reasons (congestion for example). According to the standard, once codecs are agreed (negotiated), peers must be ready to receive media in any of the agreed codec formats without further signaling.

In order to completely avoid usage of a codec initially negotiated in SDP the application needs to actually remove it from the codec list (subseting the codec list in SDP). This is also a new functionality introduced as part of these APIs.

Note that this is reordering that occurs *after* the original offer/answer negotiation, so it cannot be used as a way to introduce new codecs not present in the original offer and answer.  However, it is still quite useful to be able to select from among the mutually-negotiated codecs.

The effect of the reordering only lasts until the next negotiation, so if a renegotiation occurs this process needs to be repeated to keep the new preference ordering if it is different from what was negotiated in SDP.

 

API details

There is now a codecs attribute in the RTCRtpParameters object returned from the RTCRtpSender.getParameters() method.  By removing codecs and/or changing the order of the codecs in the attribute’s value and then calling RTCRtpSender.setParameters(), the active codec will be changed to the first in the revised list.

Here is a code snippet to demonstrate how this is done:

var params = sender.getParameters();
for (var i = 0; i < params.codecs.length; i++) {
// If opus exists in the list, put it at the top making it the preferred audio codec
 if (params.codecs[i].mimeType == "audio/opus") {
params.codecs.unshift(params.codecs.splice(i, 1));
break;
            }
}
sender.setParameters(params);