Websocket Protocol

The protocol specification is only relevant as background information or if you want to make your own Nabto WebRTC Signaling protocol implementation, e.g. for a currently unsupported target platform or app framework. For most applications, the standard implementations provided by Nabto through the available SDKs are sufficient - see the Applications guide.

After a successful HTTP connect request, a Websocket connection is created to the Signaling service using the URL from the HTTP response. Once opened, messages are exchanged as per the protocol specification below.

The protocol is split into four layers, here listed in OSI model order with the highest layer on top (note that the the layers are documented from the bottom up):

• WebRTC Signaling layer
• Signing layer
• Reliability layer
• Routing layer

The Routing layer is used to route messages between the device and the client. This is the only layer the Nabto WebRTC Signaling service implements. The remaining layers are purely between the device (camera) and the client. This means only the Routing layer is technically required for using the Signaling service.

The purpose of this protocol is to enable clients to establish a WebRTC connection to devices in a secure manner. Any user specific communication should be done on the resulting WebRTC connection after establishment. For this reason, Nabto expects these layers to be sufficient for all use cases without modification.

Clients can reconnect to the websocket server if they encounter an error or a close event. They shall use exponential backoff between reconnect attempts. After 7 failed attempts (1s, 2s, 4s, 8s, 16s, 32s, 64s), a client should give up trying to reconnect to the service.

A device can also reconnect to the websocket service. Each time it reconnects it needs to get a refreshed URL from the HTTPS service.

If the HTTPS service returns 429 with a Retry-After header, the number of seconds in the Retry-After value shall be honored if the client wants to retry the request.