iOS — Controlling the bandwidth for WebRTC calls

Yogish
trialnerrortech
Published in
4 min readFeb 19, 2018

I have been working on WebRTC from last couple of months to implement Video & Audio calling feature for the iOS app that I am currently working on.

Recently, our team planned of adding a low data mode feature. Yeah, just like the low data mode feature we have on WhatsApp.

The purpose of the low data mode was to reduce the amount of data that will be used while making the calls.

Whenever a user enables a low data mode, we had to two things

  • We had to control (reduce) the bandwidth that’ll be used by the WebRTC while making calls.
  • We had to reduce the quality of our video so that the video can be streamed with the reduced bandwidth.

Before starting to work on this feature, I went and did some research to check whether are there any solutions which are already implemented for the problem we’re trying to solve. That’s when I stumbled upon the below article.

This post is inspired from the above mentioned article, you can go there and give it a read. It’s a great article.

I have taken the solution provided in the above article and have reproduced it in Swift for iOS. Let’s take a look at how we can control the bandwidth & reduce the video quality of the calls to support the bandwidth.

Reducing the Video Quality of the calls

We can reduce the video quality of the call by reducing the frame rate of the video source (camera) used for the making the calls, as shown below.

Reducing the video quality of calls using media constraints while creating video source.

Understanding the SDP & modifications needed for controlling the bandwidth

The webrtchacks article points out that we can control the bandwidth used by WebRTC during the calls by modifying the SDP. So let’s understand what SDP is before modifying it to control the bandwidth.

If you’ve worked with WebRTC, you’d have definitely come across SDP. WebRTC uses SDP for negotiating the capabilities between the parties (Dialler & Receiver) to establish the call.

An SDP session description consists of a number of lines of text of the form:

<type>=<value>

Where <type> MUST be exactly one case-significant character & <value> is structured text whose format depends on <type>. You can read more about SDP from the spec: RFC 4566 SDP: Session Description Protocol.

TLDR; The above mentioned RFC says that types in SDP will be ordered. Since we are interested in controlling the bandwidth, we are concerned only with the part of SDP which provides media description. The media description part of the SDP have their type ordered as follows: m, i, c, b, k, a.

According to the RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth, we can set the bandwidth using the b line , with b=AS:XXX where the XXX is the bandwidth we want to set. The AS part means it’s “Application Specific Maximum” which means it’s limiting the total bandwidth. Also from RFC we can see that we need to specify the bandwidth value in kilobits per second.

So based on the RFC, to set the bandwidth our code should do the followind

  • Skip the lines in SDP until we find m=audio or m=video line
  • Skip i and c lines
  • If we there’s a b line, modify it
  • If we don’t have a b line after i and c line, add a new b line

As we now know, what we need to do with the SDP to control the bandwidth lets see how we can do that in code.

Controlling the bandwidth utilised by WebRTC using SDP

Whenever we make an offer or an answer we will get session description (SDP) and we will set this description to local description.

Now, to control the bandwidth we need to modify the description (SDP) after we receive the SDP while we create an answer or an offer and before setting it as local description as shown below.

And that’s it!! Now, we will be able to control the bandwidth used by WebRTC while making the calls if the user has low data mode enabled.

As I mentioned earlier, this post is inspired from the webrtchacks article. Please go and read that article it’s a great read and I highly recommend it.

I hope this article helped you 😄.

Further Readings

--

--

Yogish
trialnerrortech

iOS Developer, Web api developer @work. #GOT fan, vivid reader!