Device Streams

Several SBN Media services share one design: they attach a media source - a camera, a call, a file - to SBN Media and relay its stream to whoever opens it. These are the *device-stream* services. Because they are built on the same foundation, they share their configuration and most of their behaviour. This page covers what they have in common; each service's own page covers only what is specific to it.

The device-stream services include:

1. Camera Stream (rtsp) - IP cameras over RTSP
2. SIP Media (sipmedia) - the audio of SIP calls
3. File Stream (file) - local video clips and audio prompts

Others exist for recorded playback and mixed audio. They all behave as described below.

How a device stream works

1. On demand, by URL. There is no fixed list of devices. A stream is created when something opens a URL - for example rtsp://... for a camera or sipmedia://... for a call - and the scheme at the front of the URL decides which service handles it.
2. Load-balanced across instances. The same services run on every host, so a new stream is handed to one instance, shared round-robin across the cluster. Running more instances carries more streams.
3. Related streams stay together. The several streams of a single call (its two-way audio, a mix, and so on) are kept on the same instance so the audio stays local and latency stays low. This is a preference: if that instance is gone, the stream is created elsewhere.
4. A per-instance limit. Each instance accepts streams up to a limit and then stops accepting, so further streams are routed to another instance.
5. Self-healing. If the message bus reconnects after an interruption, idle streams are closed so they are rebuilt cleanly the next time they are opened.

Common configuration

All device-stream services read the devicestream settings below. View the defaults with ./sbn-media config eject and set host overrides in sbn-media.local.yaml.

After changing these settings in sbn-media.local.yaml, apply them with ./sbn-media config reload.

Capacity and scaling

Each instance accepts streams up to its limit - devicestream.maxStreams.<type> for that source type if set, otherwise devicestream.defaultMaxStreams (1000). At the limit the instance stops accepting, so new streams go to another instance. To carry more streams, run more instances; the watchdog can keep a set number running across the cluster (watchdog.system).

The configured limit is an upper bound, not a target. The practical number one instance carries is lower and depends on the host's CPU and network, and on the nature of the streams - for example a camera's resolution and bitrate, or whether call audio is passed through or transcoded.

FAQ

Which services are device streams?

Camera Stream, SIP Media, and File Stream are the ones documented here; others handle recorded playback and mixed audio. They all share the devicestream configuration and the behaviour on this page.

Can I set a different limit for cameras and calls?

Yes. Use devicestream.maxStreams with a key per source type - for example rtsp for cameras and sipmedia for calls - to cap each independently. Types without an entry fall back to devicestream.defaultMaxStreams.

A stream did not recover after the system restarted.

When the message bus reconnects, idle streams are closed on purpose so they rebuild cleanly when next opened. If a stream stays down, check the source (camera, trunk) and the network path to it, and the retry settings (streamTimeout, retryDelay).

Related pages

1. SBN Media Overview (SBN-Media/overview)
2. Camera Stream (SBN-Media/Devices/camerastream)
3. SIP Media (SBN-Media/Telephony/sip-media)
4. File Stream (SBN-Media/Devices/filestream)
5. Watchdog (SBN-Media/Platform/watchdog)