A short educational talk by Tsahi Levent‑Levi explaining how to choose a signaling protocol for WebRTC services. The speaker distinguishes transport (HTTPS/WebSocket in browsers) from signaling (application logic like registration, auth, dialing), surveys options—SIP, XMPP, MQTT, Matrix, WHIP, and proprietary protocols—and gives pragmatic guidance when to use each (e.g., SIP for existing SIP infrastructures, WHIP for camera/streaming ingest, Matrix for decentralized/government use, MQTT when already used). The talk finishes with a recommendation to choose the protocol that matches your existing stack and use gateways when necessary.
Chapters
Hi, I'm Takhi Levent Levi, founder of Bloggicme and WebRTC courses. I'm here to break down real time communications so you don't have to. This time I want to show you which signaling protocols to choose for your WebRTC service. Before you start, just reminding you, you can go to webrtccourse.com there are free courses there for WebRTC basics and the Code Lab and also paid courses for advanced WebRTC users. Check it out. Before we talk about WebRTC signaling, let's understand the difference between transport and signaling. When we talk about transport, what we get is a protocol that connects a client to a server from one side to another. It can be unidirectional, bidirectional. It can offer different types of capabilities, but the focus and the intent is generic. How do I connect from one device to another? When we talk about signaling, we add logic into that. We've got an application logic that needs to be solved. For example, how do I register to a system? How do I authenticate and authorize myself as a user? How do I dial out or talk to someone else? How do I send him messages? This is done through a signaling protocol. Transport usually deals from one point to the next and signaling is usually end to end. It can go through different signaling through different transport hubs. To get where we're looking at, let's look here. For example, if we talk about WebRTC and protocols, there are different transport protocols that we can use. UDP, TCP and TLS are protocols that we cannot use directly in WebRTC, at least not in the browser because web browsers don't give us access to to these protocols directly. What we can use is HTTPs and the secure WebSocket. So the transports that we're going to use in WebRTC are going to be HTTPs and WebSockets. We can use UDP, TCP, NTLs if we're building our own application that is native without a browser. Now for the signaling part, I've selected these ones. Sip, xmpp, mqtt, Matrix and Propriety protocols. Whatever it is that you want. We're going to go and review these alongside another protocol called wip. Let's start with sip. SIP as a protocol is a very popular protocol used for voiceover IP. It has been with us for over 25 years now, since the 90s. As such, it runs on UDP, TCP and TLS. What we see here is that for WebRTC C Prawns over WebSocket, this was added later in order to support running SIP inside Web browsers. With WebRTC, we can use SIP for our own application as its signaling. And we're going to do that if what we want to do is to connect to a large SIP infrastructure network. So if you have an application that already uses SIP, go ahead and use SIP over WebSocket for WebRTC. But I wouldn't recommend using SIP if you don't have SIP inside your application at all. And if this is the first time you're going to use it. Now, if you need support for pstn, which is telephony or sip, but that's marginal to your application, use some other signaling protocol for your application and then use a gateway to connect towards sip. Up next is xmpp. XMPP is another very old protocol that we have which is focused and targeted on messaging. Many of the applications out there that use messaging, the old guard at least uses XMPP as their main protocol. Use it if your application needs a lot of messaging inside it, like chat messages, and if you know and are comfortable with using xmpp. Otherwise I would refrain from using xmpp. This one caught me off guard. You can actually use MQTT for your WebRTC application as signaling. MQTT is a protocol that is used and was used for IoT Internet of things, you know, to connect sensors to the Internet and try to control them and get pull the telemetry from them. But it seems that there are companies that are using MQTT for the WebRTC applications. I wouldn't have reminded this one, but I am, because there is one large service that uses it already and that's Facebook Messenger. Any Facebook messenger can do that to a billion users. That can be your signaling as well. When would I use it? Well, probably if I know MQTT or already have that in my application. Otherwise I would likely skip it. Why? Because I like the proprietary approach which we will see later on. Another interesting approach is to use metrics for your signaling protocol. Metrics is an open standard that offers a decentralized messaging architecture. It is today used a lot by governments where governance is very important. And the ability to connect large groups of people to different organizations in very specific rules makes a lot of sense. If you're looking to take metrics, then you're either in that domain or you need the whole of it. If what you need is only a bit of messaging or video calling, then don't take metrics. If you need everything, then go and pick up metrics. As your solution for signaling. Then there's wip. This is a protocol that is built and designed for your rtc. It allows you to connect a camera or a video source or an audio source to a web server and it decouples the client from the server because now the signaling is going to be known and that's wip. When are we going to use wip? When what you're trying to do is to connect the camera outside to a system. So we are going to use it on surveillance cameras or in different types of application that do live streaming. For example, if I want to connect obs, the open source application that many streamers use into my service, I would use WHIP for that. For example, I might use WIP only at a small piece of my application, or not everywhere. But it's quite useful when you look at it that way. Last and not least is using a proprietary protocol. This is going to be the most common approach that I see in most applications. What happens there? I pick and choose whatever I want. Usually I would take WebSocket as my transport protocol and then define the messages that I need for my signaling. What users do I have, how do they communicate, are there rooms, what is the authentication mechanism? All of these things I need to answer for myself and then build that specific solution on my own. If you're using media servers SFUs, for example, they come with their own signaling protocol. You can use that proprietary solution with the SFU that you've selected, or you can replace that with something else like your own proprietary solution or some other signaling protocol that we've seen before. If you want to look and understand how to build such signaling protocols, then the WebRTC CodeLab is actually for you. So check it out. If you have WebRTC service and it is failing on you, performance is not good, the connectivity is not there. Here's any books that I've written, go download it and it will give you three simple steps for fixing that. Sip, XMPP mqtt WEEP matrix Proprietary protocols. Whatever it is that you're going to choose, make sure you choose wisely. You can follow me on blogecme.com see you there.
