Nabto WebRTC Platform Overview
Interactive Demo
See Nabto WebRTC streaming live from a real camera. Our public demo on www.nabto.com shows low-latency video delivered directly to your browser. Already saw the demo on our main site? This page shows how it works under the hood with code, architecture and integration options.
Watch Live Demo Run your own demo
Background
Nabto WebRTC is a platform engineered specifically for secure, low-latency video streaming between IoT cameras and client applications. The platform is vendor agnostic with open source SDKs that are simple to integrate: It works with any chipset and target platform, you just need a toolchain and access to the camera.
Nabto WebRTC addresses challenges that general-purpose WebRTC solutions often fail to meet, such as operating on constrained hardware, handling intermittent connectivity and complying with strict security requirements common in IoT environments.
The WebRTC standard was originally designed for browser-based video conferencing, where low latency is essential. This makes it inherently well-suited for live video streaming from cameras, where users expect the video feed to reflect exactly what is happening in front of the camera right now, not what happened a few seconds ago.
Nabto WebRTC builds on this foundation with a signaling protocol tailored for headless devices, requiring no user interface or manual intervention to establish connections. All SDKs are open source, making integration simple, transparent and auditable, an essential requirement for many IoT projects where control over the full software stack is needed.
Also see our general WebRTC intro.
Working example with minimal code
If you’re already familiar with WebRTC concepts, the examples below show what using Nabto WebRTC looks like in practice. If you are not already familiar with WebRTC in general, feel free to skip ahead.
Minimal code to securely establish a video stream in a client application:
import { createSignalingClient } from "https://cdn.skypack.dev/@nabto/webrtc-signaling-client";
import {
createClientMessageTransport,
ClientMessageTransportSecurityMode,
PerfectNegotiation,
SignalingEventHandler,
} from "https://cdn.skypack.dev/@nabto/webrtc-signaling-util";
const productId = "wp-39wu7tex";
const deviceId = "wd-3xtqp3hy4xxy3av3";
const sharedSecret = "59470b3f8e331d9975da366d8dc0dcf743ef6a1154a4f779932740b4d14be3ab";
function connect() {
const signalingClient = createSignalingClient({
productId: productId,
deviceId: deviceId,
});
const messageTransport = createClientMessageTransport(signalingClient, {
securityMode: ClientMessageTransportSecurityMode.SHARED_SECRET,
sharedSecret: sharedSecret,
});
messageTransport.on("setupdone", async (iceServers) => {
const pc = new RTCPeerConnection({ iceServers: iceServers });
new PerfectNegotiation(pc, messageTransport);
new SignalingEventHandler(pc, signalingClient);
pc.addEventListener("track", (event) => {
const videoElement = document.getElementById("videoview");
videoElement.srcObject = event.streams[0];
});
});
signalingClient.start();
}
$(document).ready(function () {
connect();
});
The above snippet shows just the most basic Nabto WebRTC SDK interaction for a JavaScript client application and omits e.g. error handling. For more details, see the application development guide and a full example in github. Also see the more complete platform specific client examples for iOS, Android and JavaScript.
On the device (camera) side, you can use the Nabto WebRTC basis apps to bridge between the video source on the camera and WebRTC:
$ webrtc_device_rtsp -d ${deviceId} -p ${productId} -k key.pem --secret ${sharedSecret} \
--rtsp-url rtsp://127.0.0.1:8554/video
You can extend the open source basis apps as needed or develop your own using the open source SDKs.
PLATFORM OFFERINGS
The Nabto WebRTC platform consists of two core offerings: Signaling and ICE. These can be used independently or together depending on your deployment needs.
In a typical scenario, the client initiates a secure connection through Nabto’s signaling service. The camera device, likely behind a firewall, responds when available. WebRTC ICE/STUN/TURN services handle NAT traversal and video data flows directly between endpoints:
Nabto WebRTC Signaling
The WebRTC standard does not specify how metadata is exchanged to establish a connection, just what should be exchanged. Implementing a mechanism for exchanging this information to establish a WebRTC connection is denoted signaling.
A key offering in Nabto WebRTC is a full signaling solution, Nabto WebRTC Signaling: It comes complete with a managed signaling service and a robust and secure protocol with implementations for all popular client platforms (iOS, Android and browsers) as well as a C++ version for camera integration. The signaling protocol is open for custom implementation if needed.
Nabto WebRTC Signaling is designed specifically for the asymmetric scenario when streaming from a video camera, ie where the client initiates a connection towards a passive camera that must be ready for accepting incoming connections. The camera can be offline when connecting, the caller will then be notified so it can resume when available.
Read more about Nabto WebRTC signaling.
Nabto WebRTC ICE (STUN and TURN Services)
In addition to signaling, any WebRTC solution needs a STUN server to facilitate establishing a direct P2P connection. Also, TURN servers are needed for the scenarios where a P2P connection is not possible, e.g. in case of carrier-grade NATs or restrictive firewalls. Nabto WebRTC includes managed STUN and TURN servers through Nabto WebRTC ICE: Global deployment with high performance and a low traffic cost.
Nabto WebRTC ICE is optional; you can combine Nabto WebRTC Signaling with your own ICE (TURN/STUN) services.
Security
Nabto WebRTC supplements the built-in end-to-end encryption of the WebRTC standard by securing the signaling layer and enforcing authentication and access control. All signaling communication is protected using TLS.
Only authenticated devices (cameras) with valid key pairs can connect to the signaling service. This ensures that clients only interact with legitimate devices.
Access control can be centralized or decentralized. In both cases, the Nabto SDK handles all cryptographic operations, simplifying implementation.
With central authorization, clients present signed access tokens verified by the signaling service before connections are allowed.
With shared-secret authentication, devices perform access control locally by verifying HMAC signatures from clients, independent of the signaling service.