An Introduction to WebRTC Signaling

There is something you need to know about me. When I get excited about something, I tend to get really excited. Case in point is WebRTC. I’ve seen a lot of amazing ideas, inventions, and products in the field of communications, but the notion of turning a web browser into a full featured multimedia communications device is truly revolutionary.

So, with this, my fourth blog about WebRTC in a relatively short period of time, I hope to shed a little more light on this thing that has truly captured my attention.

Let’s get started.

In case you didn’t catch this from my previous blog articles, WebRTC does not define a signaling protocol. This is not because the developers were lazy or simply forgot that you need to signal another device before you can send media to it. Signaling was left out of WebRTC for some very good reasons.

  1. Different applications may require/prefer different protocols. The WebRTC working group did not want to lock it down to something that may turn out to be inadequate for all its uses.
  2. WebRTC runs in a web browser and support for signaling would require that web pages would need to be stateful. This becomes problematic if signaling is lost each time a page is reloaded.

Since signaling is required for call setup, WebRTC solutions must include a signaling server of some type. Again, WebRTC itself doesn’t care how that sever implements signaling, but it must exist somewhere in the network.

However, it isn’t exactly a signaling free-for-all. WebRTC requires that that server understands Session Description Protocol (SDP). That’s right, the same protocol that SIP uses for its media connections.

Don’t think that this means that WebRTC servers automatically use SIP for signaling. SDP is a protocol unto itself and can be used by any signaling protocol to define, advertise, and in some regards, negotiate multimedia capabilities between peers.

At the same time, don’t think that WebRTC can’t use SIP for signaling. All the client cares about is that it can send SDP to something and that something signals the far-end. The client doesn’t give a hoot about what happens in the middle as long as the far-end client receives SDP and sends SDP back.


If you have any questions about what SDP is and how it works its magic, please see my article Understanding Session Description Protocol (SDP)


Note that there is discussion to replace SDP with JavaScript Object Notation (JSON), but for now, SDP is the one and only choice.

Step by Step

The mechanism to create a session between two parties (let’s use Andrew and Linda) is described in the specification JavaScript Session Establishment Protocol (JSEP), but that document is lengthy and somewhat involved. Here is a straightforward explanation that will provide you with enough information to be dangerous.

  1. Andrew creates an offer that contains his local SDP.
  2. Andrew attaches that offer to something known as an RTCPeerConnection object.
  3. Andrew sends his offer to the signaling server using WebSocket. WebSocket is a protocol that provides a full-duplex communications channel over a network connection. WebRTC standardized on WebSocket as the way to send information from a web browser to the signaling server and vice versa.
  4. Linda receives Andrew’s offer using WebSocket.
  5. Linda creates an answer containing her local SDP.
  6. Linda attaches her answer, along with Andrew’s offer, to her own RTCPeerConnection object.
  7. Linda returns her answer to the signaling server using WebSocket.
  8. Andrew receives Linda’s offer using WebSocket.

I am saving explanations of ICE, STUN, and TURN for a future article, but with this simple flow, the users have shared their SDP and understand who is capable of what.

Keeping it Simple

This should be enough for now to convey the following points.

  • WebRTC does not define signaling.
  • WebRTC uses SDP to define the media characteristics of a call.
  • A signaling server sits between two clients..
  • Clients use WebSocket to communicate to a signaling server and vice versa.

Good enough?  Great!  Stay tuned for future articles on my latest passion.  I still have a lot more to say on this exciting subject.

Advertisement

11 comments

  1. Really appreciate your simplified explanation of complex and novel technology.

  2. Thanks, Andrew. I understand it better when I am forced to write it down. 🙂

  3. Really appreciate.

  4. WebRTC is definitely the hot pick and been reading about this from quite some time but none has explained it better than you !!..Can WebRTC be deemed as a threat to IMS ?

  5. Andrew receives Linda’s offer or answer using WebSocket?

    1. All information comes via WebSocket in this example.

  6. Sushant Haware · · Reply

    Sir, I really appreciate and heavily taken aback with the perfection with which you pen down so complex things. This has sparked an interest for me in WebRTC and i am surely going to follow all your next blogs on this technology.
    Also i would like to thank you making separate blogs on SIP headers. Those are life saver in many situations

  7. S Srivas · · Reply

    So simple, Thank you Andrew.

  8. Superb Sir, that helps a alot.

  9. Jhonatan Piffer Siqueira · · Reply

    Thank you Andrew you help me a lot to understand this.

    1. Happy to be of assistance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: