Documentation

Video Streaming with WebRTC and RTSP

The Nabto Edge platform supports two different approaches to video streaming: WebRTC and RTSP tunnelling.

As outlined in the WebRTC introduction, WebRTC is our recommended approach to video streaming: It performs much better for live video and natively supports web browsers on all platforms just as well as dedicated iOS and Android apps. For some projects, the RTSP tunnelling based approach is still the best (or only) option. This guide will help you decide which approach to take and point you to specific demos and examples.

Quick links to hands-on demos and examples:

WebRTC vs Tunnelled RTSP

WebRTC is a modern protocol designed for high performance in video scenarios. While initially intended for browser-to-browser communication, it works really well also for viewing a video feed from e.g. a camera or DVR in a browser or mobile app: The design for very low latency is a great benefit in live surveillance cameras and the feed is less sensitive to network issues due to being UDP based. It all works with standard player components, e.g. available in all modern browsers and as open source components for use in mobile apps. That is, no proprietary low level video integration is necessary.

The WebRTC components provided by Nabto for use on the embedded system (e.g. camera / DVR / NVR) require a toolchain that supports modern C++ (at least C++17). While available for most reasonably modern platforms, some older and/or limited platforms lack this. For these, the tunnelled RTSP approach can be used instead. Moreover, Nabto Edge WebRTC requires a larger total footprint on the camera - both in terms of memory usage and executable size.

A lighter implementation is in the roadmap that will allow WebRTC to be used on more resource constrained devices. Please contact us for more information in this regard.

When to use WebRTC for Video Streaming

If you have a modern target system with a C++17 toolchain available and if resources are not too limited on the target, you should use WebRTC. Also, if you have a requirement to view a video feed in a plain web browser, WebRTC is your only practically feasible option.

The exact resource requirements on the camera depend on your specific system configuration and video quality. So it is recommended to try a quick prototype through the examples and evaluate the feasibility.

Using WebRTC with Decentral Access Control (no “cloud” user account needed)

If using Nabto Edge WebRTC in a mobile app, you can follow the discovery and connect guides exactly as shown in the Concepts and Best Practices section: Clients establish a standard Nabto Edge connection to the target device (camera). The IAM module in the target device authenticates clients according to the paired public key fingerprint and authorizes operations according to the mapped IAM role (decentral access control). The established Nabto Edge connection is then used for WebRTC signaling.

In this way you do not need a central user identity and user/device management service, ie your users will not have to create an account with you. This is often desirable for simplicity - the user just starts the camera, pairs it with your app and starts viewing the live stream. In addition to the simple user experience, it also simplifies OEM scenarios with no central user/device management portal that needs rebranding.

The WebRTC example apps for iOS and Android currently do not demonstrate the decentral access control paradigm - they only demonstrate the centralized OAuth based access control approach as described below. Instead, you can see examples of using decentralized access control in the other examples apps ie the thermostat app (available for iOS and Android) and the RTSP video streaming app (available for iOS and Android). You will then use the user/device pairing flow as-is and combine this with the actual WebRTC viewer from the WebRTC example apps. It is in the roadmap to add a self-contained WebRTC example app that uses decentral access control. Contact Nabto Support if you need this before it is publicly available.

Using WebRTC with Central Access Control

If using Nabto Edge WebRTC in a browser based application, the process is quite different: You do not have a local private key so the decentral pairing described for native apps is not possible. Instead, you typically use token based access control: A central OAuth service issues a token (JWT) that is used to access the camera.

It is of course also possible to use OAuth based access control in a native app. This is the typical approach if you have a centralized user/device management solution, perhaps already used in a browser based WebRTC application. We provide full example apps for iOS and Android that shows how to integrate with an example OAuth service (AWS Cognito).

With a centralized solution like this, you are also able to retrieve the centrally managed set of user/device pairings - so if logging in through a browser or in different mobile apps, you will see the same set of paired devices. With decentral access control, each client device would have to pair individually with each device. Having this centralized set of paired devices is a great user experience benefit that often is considered outweighing the added complexity and friction of having to sign up for a central account. This is also demonstrated in the iOS and Android WebRTC example apps.

When to use Tunnelled RTSP

If a feasibility study concludes that your target (camera/DVR/NVR) platform is too resource constrained to use Nabto Edge WebRTC, you can instead choose to stream video using Nabto Edge TCP Tunnels.

You can use any RTSP video player in the client. It is pointed towards the Nabto Edge TCP Tunnel endpoint within the client application. Under the hood, this connects securely to a Nabto Edge TCP Tunnel endpoint on the target which in turn connects to an RTSP service on the camera:

In the RTSP video scenario, the “existing TCP server application” is the RTSP server running on the camera (or gateway or DVR/NVR). The “existing client TCP application” is an RTSP video player component like VLC or FFmpeg.

The player is simply pointed towards the TCP proxy server running inside Nabto Edge Client SDK, e.g. rtsp://127.0.0.1:51743/live/0 and the remote feed is shown - through a secure connection.

It is extremely simple to integrate Nabto Edge TCP Tunnels in your existing RTSP based video player application; you can typically get a proof-of-concept integration running with just a few lines of code. See the RTSP client guide.

Note that if you have an RTSP server available on the camera, you can still use the Nabto Edge WebRTC integration and get all the benefits: We provide a bridge application on the camera that consumes an RTSP feed and serves data to the WebRTC client.