There was a time, you needed to enable port forwarding if you were planning to make a service publicly available for the internet. Isn't that great? Using the concept of port forwarding, you can now watch your video surveillance cameras, residing on your local home network, from everywhere in the world using a simple username and password. Boom 💥!
Hell no, and the worst thing is, some people and even companies still live in that time 👵. Here is the goods news, and by the way it's not only applicable for video surveillance, there is an alternative. Welcome WebRTC!
WebRTC has landed
Using the concept of WebRTC you can now access your cameras from anywhere in the world, just like you would do, using port forwarding. However the cool thing is that you don't need to do port forwarding.
Haha, let's get a bit serious now. So really, WebRTC is great, it's a collection of already developed, mature protocols, brought together under a single umbrella. So in the end, the concept is new, but the building blocks such as RTP, RTCP, SDP, ICE, etc are not. The beauty is that thanks to this we can build production ready WebRTC applications, backed up with a well and verbose documented backlog of books, videos, etc.
Wait a minute, what are those acronyms? RTP, ICE,..
Although WebRTC is great, it comes with a steep learning curve, but really steep. There is much to learn, and a lot of those building blocks deserves its own expertise or at least a packed book. So before you can really master WebRTC, its good to start with a high-level overview.
My 2 cents: a good starting point for WebRTC, is this public available book from Sean Dubois (https://webrtcforthecurious.com). This books, is still in development, but the first chapters already give you a good overview of what to expect from WebRTC and how it interconnects with the different modules.
So how can WebRTC help me exposing IP cameras?
We at Kerberos.io are relying heavily on WebRTC when it comes to P2P streaming. At one side we have a IP camera in a company network, on the other hand we have a user requesting the IP camera stream, for example from a cellular network, on his mobile phone.
If you think about this, port forwarding is so easy. You just port forward it once, and you are ready. If you think this is great, you are really, but really missing the clue.
Port forwarding requires you, or a network administrator in your company to fiddle with the network settings, firewall and other networking rocket science. Still port forwarding can be a solution, for personal usage, or if you only have a single network to manage, but if you want to develop solutions which needs to be network agnostic, good luck.
Really you don't want to open that door, if you plan to develop a surveillance solution, or a IoT application, which you plan to roll out inside different networks, use WebRTC.
WebRTC how does it work?
Thanks to the concept of signalling and ICE (Interactive Connectivity Establishment), WebRTC can establish the best possible P2P connection between the camera and the user behind the mobile phone.
First things first, let's take a step backward, ICE, means that it will try to establish a connection using different and available routes.
To make ICE a little bit more visual you should consider it as the routes to get to work or school. You could go to school or work using the bicycle, the train or car. Depending on the transport mechanism you would use, you will probably take a different route. When driving a car, you will take the highway, using a bike you probably will take some cool shortcuts, etc. So no magic, this is how ICE works, it calculates and discover the different routes to get from point A to point B.
Now to make it more concrete, and more relevant to WebRTC, consider this. Imagine you don't want to know the best route to work or school, you want to know the best route to visit a friend. Well, this is a bit more complex as the person, you are going to visit can be at different locations (dynamic). Your friend could be at home, at school or at a, well I don't believe there are much other places then those during COVID times.
It could be that depending on the location of your friend it might be easier to take the bus, or even your bike. So taking the car is not always the best option. So if you got this, you now know how ICE works. For both peers, it will discover all available transports mechanisms, and on top of that it will determine the best available transport. In ICE they do not call it transports but ICE candidates, and on top of that determining the best available transports is what they call ICE Gathering and ICE Pairing (selection).
What are those ICE candidates?
I don't want to get too detailed, but you have a couple of Candidate Types, and they are very well documented on the internet. You have HOST candidates, SRFLEX candidates, RELAY candidates. Read more about what they do here. https://webrtcforthecurious.com/docs/03-connecting/#candidate-gathering
So again, how does WebRTC help me exposing my video surveillance cameras?
Ok, finally we are at the purpose of this article. In the world of video surveillance, you typically have a VMS running in the form of a NVR or kind of agent. The VMS is hosted inside the same network of where your IP cameras are running. Agents are typically more intelligent and flexible than a simple NVR, therefore we will focus on the Kerberos.io agent, and show you why agents are superior towards NVRs.
Kerberos.io comes into two flavours Kerberos Open Source and Kerberos Enterprise. Both flavours come in the form of an agent, and depending on the use case you should consider Kerberos Open Source for personal usage, and Kerberos Enterprise for scaled, high available, resilient surveillance deployments. Kerberos Open Source runs on hardware such as Raspberry Pi's, Orange Pi, Jetson, or an ordinary Ubuntu VM in the form of a Docker container. On the other hand Kerberos Enterprise runs in a Kubernetes cluster. Read more about it on the documentation website.
Focusing on Kerberos Enterprise, we now integrated WebRTC inside the core. Thanks to the awesome Pion project, anyone with some Golang skills can develop his own P2P project. Definitely check out there Github repo and example.
So Kerberos Enterprise agents are running in a Kubernetes cluster. Thanks to this you can easily scale your video surveillance landscape horizontally. You can simply add more resources, and Kubernetes will handle/load balance your agents.
These so called Kerberos agents provide you different functionalities such as motion based or continuous recording, region of interest, time of interest, central storage using Kerberos Storage or Kerberos Cloud, on demand storage, and last but not least live streaming in low resolution and high resolution (WebRTC).
Every agent in your Kubernetes cluster, will use WebRTC (Pion) to forward its stream to the peer's/client's web browser. Yeah cool, Web browser, no plugins required. That is how we roll with WebRTC.
Information, such as SDP's and ICE candidates are signalled through MQTT from one to the other. Once the candidates are signalled, WebRTC will determine the best candidate pair and if necessary use a TURN server (relay candidates) to proxy the media stream (camera stream) to the client's browser. This is how it looks like.
Once hitting the start stream button, the web app will signal an offer (over websockets/mqtt) to the Kerberos agent. Once the agent receives the offer it will respond using an answer, and send it back.
At the same time, when negotiation started, ICE candidates are being gathered and signalled from one to the other. When all candidates are gathered, Pion/WebRTC, will select the best ICE candidate pair to stream the data. This happens when the status, connected shows up. As you can see this all happens in a couple of milliseconds.
This is so cool, WebRTC and ICE, will help us establishing the best connection possible. Either being it with HOST (in the same local network), STUN or if not possible TURN, to send over our camera stream.
You could just send over the original camera stream to the browser of the WebRTC user, but do you want to send over 4K streams to a mobile phone, or even a Desktop browser? And do you want to watch multiple 4K streams at the same time? There might exist situations where you would like that to happen, but in most cases such as poor network bandwidth you don't want that.
At Kerberos we believe you want to record full resolution, but livestream a fraction of the original stream (although it's possible to stream the original quality if you want). Within Kerberos Enterprise we ship a transcoding feature. Once a peer is connected through WebRTC, the Kerberos Agent will transcode and scale the camera feed to a lower resolution and send it over the clients browser. This makes sure less bandwidth is used, and it is more reliable to view a livestream.
WebRTC allows us to stream on-demand, but also allows to transcode on demand, Only when users are requesting the stream, some CPU is used for transcoding, and WebRTC is used to pump over the stream to the clients web browser.