SRT, RTMP, WebRTC and RTSP publish control framework overview

For the past few years, mobile devices were showing significant improvements for video creation capabilities hence the popularity of video live streaming solutions - from mobile broadcasting applications to complex all-in-one solutions. If you create a streaming solution yourself, you need to be able to control the publication process for the protocol which you choose to work with, e.g. for RTSP or RTMP.

SRT, RTSP, RTMP and WebRTC WHIP incoming streams were supported in Nimble Streamer for a while already among other protocols. Nimble supports SRT, RTSP, RTMP and WebRTC streaming authentication server-wise as well as for specific applications. So if a customer needed to separate publishing permissions between his users, he needed to create separate application for each individual publisher. But when you broadcast from mobile devices, you probably will need some better way to make sure each publisher has separate permission to publish.

Our customers have been using WMSAuth Paywall functionality to secure the outgoing streaming for a long time. Now to secure the incoming streams, we introduce the Publish control framework which allows performing multi-level authorization.

So now Nimble Streamer allows controlling the publication for RTSP, RTMP and SRT in Listen mode receiver both when establishing connection time and during the streaming process. It has various options so let's see what we have, step by step.

The following scenarios authentication are available.

"Zero option" is if you don't need any protection for incoming streams, then you can just specify only port number for RTMP and RTSP, and define SRT listener. Any publishers can push any streams to your server through the specified port so we do not recommend it. WebRTC requires authentication though.

1. Use publishing credentials

The first scenario is to create a separate application in Nimble Streamer settings for each user with unique username and password to get authorized streams from different authorized users. This mechanism is unsuitable for the large number of users and does not allow to block users during streaming process because the authorization takes place only at the time of connection of the user.

2. Use per-stream publish signature.

In order to allow multiple users to publish streams to the media server and to have the flexibility to control streams, you need to use our Publish control framework.

At this step we add a publish signature, which is based on the following parameters:

• user identifier (ID);
• stream name;
• password which was specified in application;
• publisher IP address (this one is optional).

You need to specify an application in WMSPanel control UI to operate the incoming streams. Publishing users will be grouped in. The application name should be the same as specified on step 2. The password which is used in this signature should be specified in the publish control application settings via the UI.

To publish to Nimble Streamer, the publisher will use the URL like this:

rtsp://192.168.5.5:554/live/stream?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=

For RTMP this will be

rtmp://192.168.5.5:1935/live?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=/stream

For SRT receiver in Listen mode you will define streamid as shown in the following example, read Setting SRT user and password authentication with SRT PASSet article for setup details of proper streamid.

ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=/live/srtstream?publishsign=aWQ9SURfMSZzaWduPVQ3SzVlMkMySlRxRExmSTdybVdibVE9PSZpcD0xMjcuMC4wLjE="

For WebRTC the WHIP signaling URL will be

https://your_host/live/whip?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=

Here, a publishsign is the signature for incoming stream.

When the user is going to publish RTSP or RTMP stream, the media server will check publish signature and if this signature does not match the calculated signature, then the user stream will not pass. At this step the publish control is very similar to the hotlinking protection.

Notice that you may skip the signature in case you handle your authorization in some other way. The "Signature-free mode" is defined to make this way during app publish control setup, see detailed documentation for more on that.

3. Use connection handler to manage connection process.

To get full control for the incoming streams, you need to create a handler application and specify its URL in the control UI.

The handler is an HTTP application which is able to process POST requests and return the response according to the business logic of the customer. If you don't specify the handler URL then Publish control framework will not try to call the handler. This is done to allow debugging the signature-checking mechanism.
Besides handler URL, you can set up the grouping interval for the incoming streams. The handler is called with some timeout to aggregate several requests in one. This allows avoiding the resources waste in case of frequent calls.

Publish control passes the client publisher IP, ID and stream to the handler. As a response to the request, the handler must return the status and Nimble Streamer acts accordingly to allow or deny the connection, based on the status received from the handler.

4. Use publication controller during streaming

With publish control framework you can manipulate SRT, RTSP and RTMP streams not only at connection time, but also during the streaming process as well when the user is already connected and streaming. To perform this, each streaming session is assigned with its own key. You can create publish controller app which can request Nimble with any frequency to identify which users still publish their streams.
If you need to stop certain streaming session then your controller calls Nimble, specifies the session ID and this stream will be blocked immediately.


Using publish control framework you can implement any level of incoming streams security from basic level authorization to advanced business logic solution.

If you need to change the incoming streams' content parameters, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.

Next step is the setup

The next article describes step-by-step publish control set up with examples of source code, requests and responses.




Also check playback authorization feature set which allows controlling playback connections via external handler similar to what is used in publish control.

Related documentation

RTSP streaming via Nimble Streamer, RTMP feature set in Nimble, Nimble Streamer paywall feature set, Larix Broadcaster, SRT Publisher Assistance Security Set, WebRTC support in Nimble