SRT playback protection¶

SRT is often used for distributing television signals over the Internet to partners. The stream made available online requires playback protection, including the task of revoking permission from just one client.

In the simplest case, you can use the passphrase mechanism built into SRT, but it does not allow for issuing different data to different clients, so you can disconnect one while leaving the others connected. Therefore, many alternative solutions propose issuing a unique port and its own passphrase for each partner, while Flussonic Media Server allows for the use of a standard authorization token and client validation through an authorization backend.

Passing authorization token in SRT¶

Unlike other protocols, SRT has a significantly different mechanism for transferring metadata to the server, so implementations can vary between clients. We will show an example for ffmpeg.

Configure test example¶

Let's start with a test configuration of Flussonic with an artificial source and one authorization backend that allows a predefined token.

auth_backend srt_play {
    allow token test1;
}

stream srt-check {
    input fake://fake;
    on_play auth://srt_play;
    srt_play {
        port 10300;
    }
}

How does protection works?¶

ffmpeg -v debug -i "srt://127.0.0.1:10300"
...
[AVFormatContext @ 0x15a606eb0] Opening 'srt://127.0.0.1:10300' for reading
[srt @ 0x6000031ef300] No default whitelist set
16:44:12.996228/!W:SRT.cn: @512971494: processConnectResponse: rejecting per reception of a rejection HS response: ERROR:PEER
16:44:12.996505/!W:SRT.cn: @512971494: processAsyncConnectRequest: REJECT reported from HS processing: Peer rejected connection - not processing further
[srt @ 0x6000031ef300] Connection to srt://127.0.0.1:10300 failed: Input/output error
[in#0 @ 0x6000023ecb00] Error opening input: Input/output error
Error opening input file srt://127.0.0.1:10300.
Error opening input files: Input/output error

Unfortunately, SRT does not provide error codes and statuses; there is no mechanism to inform the client that the stream is fine, it's just not being allowed access. Thus, the client behavior demonstrated above, in the case of enabled protection, is not a problem but the only possible behavior.

How to pass token?¶

ffmpeg -i 'srt://127.0.0.1:10300?streamid=#!::u=test1'
...
Input #0, mpegts, from 'srt://127.0.0.1:10300?streamid=#!::u=test1':
  Duration: N/A, start: 55414.651911, bitrate: N/A
  Program 1 
  Stream #0:0[0xd3]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 90k tbn
  Stream #0:1[0xdd](eng): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 30 kb/s

In the example above, there are two subtleties: correctly forming the streamid and correctly escaping it so that no system along the path begins to interpret special characters like # and !.

The format #!::u=test1 follows the standard by Haivision; we simply adhere to it, and Flussonic looks for the standard authorization token in the u field.

In this example, test1 is precisely the token that is specified in the test configuration as allowed. In your case, it could be anything else.