Skip to content

Авторизация проигрывания по SRT

SRT часто применяется для раздачи телевизионного сигнала через интернет партнерам. Выставленный в интернет поток требует защиты проигрывания, включая задачу отзыва разрешения лишь одному клиенту.

В самом простом случае можно воспользоваться встроенным в SRT механизмом passphrase, но он не позволяет выдать разным клиентам разные данные, чтобы можно было одного отключить, остальных оставить. Поэтому многие альтернативные решения предлагают для каждого партнера выдать свой порт и на нём свой passphrase, а Flussonic Media Server позволяет использовать стандартный авторизационный токен и валидировать клиентов через авторизационный бекенд

Передача авторизационного токена в SRT

В отличие от других протоколов, SRT имеет сильно отличающийся механизм передачи метаданных на сервер, поэтому между клиентам реализация может разниться. Мы покажем пример для ffmpeg

Настройка тестового примера

Начнем с тестовой конфигурации флюссоника с искуственным источником и одним авторизационным бекендом, разрешающим заранее известный токен.

auth_backend srt_play {
    allow token test1;
}

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

Как срабатывает защита?

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

К сожалению, в SRT не предусмотрены коды и статусы ошибок, нет механизма сообщить клиенту, что поток в порядке, просто его не пускают. Т.е. демонстрируемое выше поведение клиента в случае с включенной защитой является не проблемой, а единственно возможным поведением.

Как передать токен?

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

В примере выше есть две тонкости: правильно сформировать streamid и правильно экранировать его, чтобы никакая система по пути не начала интерпретировать спец-символы типа # и !

Формат #!::u=test1 является стандартом от Haivision, мы ему просто следуем и в поле u флюссоник как раз ищет стандартный авторизационный токен.

В этом примере test1  — это как раз тот токен, который указан в тестовой конфигурации, как разрешенный. В вашем случае может быть что угодно другое.