この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
清水です。先日AWS Elemental MediaConnectでこれまでのSRT listenerモードに加えてSRT caller modeをサポートするアップデートがありました。
このアップデートを確認した際、SRTプロトコルのListener/Callerについて理解しておらず（なんとなく2つのモードがある、ぐらいの認識でした）、アップデート内容やそのメリットなどを把握するのに時間がかかってしまいました。上記エントリをまとめる際に把握できたListenerとCallerの違いなどを本エントリではまとめておきたいと思います。（なお、SRTプロトコルにはもう一つRendezvous（ランデブー）モードというものもありますが、本エントリでは触れていません。）
ポイントとしてはListenerがいわゆるサーバに該当して、IPアドレスやドメインなど接続先となる情報をもちます。Callerはいわゆるクライアントに該当しListenerのIPアドレスに接続します。Callerは接続元ですね。Listener側では接続するまではIPアドレスなどCallerの情報はわからなくてもかまいません。また映像伝送の向き（どちらからどちらへ）はListenerとCallerの役割に関係ありません。
MediaConnectの設定項目から確認してみる
まずはMediaConnectでのSRTプロトコル利用の際の設定項目などからListenerとCallerの違いをおさえてみます。マネジメントコンソールの画面から確認を進めていますが、必要に応じてUser Guideも参照しましょう。
- Creating a transport stream flow that uses a standard source - AWS Elemental MediaConnect
- Adding standard outputs to a flow - AWS Elemental MediaConnect
SRT Caller mode
まずは先日アップデートのあった、MediaConnectのSRT Caller modeを設定する際に必要な情報です。
Source作成画面では以下のように、「Source listener address」ならびに「Source listener port」の入力を求められます。特に「Source listener address」に注目しましょう。SRTの接続先を指定する、というぐあいですね。IPアドレスもしくはドメイン名で指定が可能です。
Outputsのほうも確認してみます。こちらは「Destination address」の入力を求められます。こちらもやはりSRTの接続先となる情報で、IPアドレスもしくはドメイン名が指定できます。
SRT Caller modeでは接続先（対になるSRT Listener）情報を指定する必要がある、というところがポイントです。
SRT Listener mode
もう一方のSRT Listener modeについても確認してみましょう。MediaConnectではSRT Caller modeよりも先にListener modeをサポートしていました。
Sourceの作成では、設定項目として「Allowlist CIDR block」を指定します。これは接続先ではなく、接続を許可する接続元のIPアドレス群となります。
OBS StudioなどStreaming SoftwareからSRTで映像を打ち上げるときは、このSRT Listener modeのSource作成後に払い出されるInbound Ip addressを宛先にします。
SRT Listener modeのOutputについても確認してみましょう。こちらも作成時に接続先の具体的な情報は不要です。CIDR Allow listで接続を許可する接続元IPアドレス群のみ指定するというかたちですね。
SRT Listener modeは接続先となるため、リソース作成時にCaller modeのときのような接続先の情報は不要です。また具体的な接続元の情報も必須ではありません。（CIDR形式で接続元IPアドレス軍を指定することは可能です。）リソース作成後に提供されるIPアドレスが、接続元（対になるSRT Caller）から接続される際の宛先となります。
MediaConnectのListenerとCallerのまとめ
MediaConnectの設定項目でSRTプロトコルのListenerとCallerの違いをまとめてみると、Callerは接続する側（接続元）となるためリソース作成の際に接続先のListenerの情報（IPアドレスやドメイン名）を指定する必要があります。
Listenerは接続される側となるため、設定の際に具体的な接続元の情報は不要です。設定後にIPアドレスが払い出されますので、Caller側はこのIPアドレスに接続します。
なお、MediaConnectでは入力となるSource、出力のOutputの双方でSRT listenerならびにSRT callerに対応しています。この点からもListenerとCallerが映像伝送の向きに関係しなていないことがわかるかと思います。
動画配信プラットフォームの例で考えてみる
MediaConnectの設定項目ベースで確認してきましたが、別例として一般的な動画配信プラットフォームの場合にSRTプロトコルのListener/Callerがどう対応するのかを確認してみましょう。
「一般的な動画配信プラットフォーム」については、YouTube LiveやFacebook Liveなどのほか、Amazon Interactive Video Service (IVS)やAWS Elemental MediaLiveなどAWSサービス群で構築したシステムなどなどをイメージしてみてください。ここでは、SRTでの映像の打ち上げならびに配信に対応しているCloudflare Streamを例にしてみます。
- Cloudflare StreamでSRTプロトコルを使ったライブストリームをやってみた | DevelopersIO
- Cloudflare StreamでSRT/RTMPSを使った低遅延ライブストリーミング再生のサポートが発表されました！ | DevelopersIO
動画配信プラットフォームを使って動画配信する際には、2つの動画（映像）のやり取りが発生しています。映像を動画配信プラットフォームにアップロードするファーストマイル（Ingest）、動画配信プラットフォームから視聴者に映像を届けるラストマイル（Egress）です。2つの用語の詳細については下記エントリも参考にしてください。
Cloudflare StreamでSRTを使ったライブストリーミングを行う際には、以下のようにファーストマイルでStreaming Software側からsrt://live.cloudflare.com:778に映像をアップロードします。またラストマイルでは再生プレイヤーがこちらもsrt://live.cloudflare.com:778にアクセスして動画を視聴します。
このCloudflare Streamを使った構成（一般的な動画配信プラットフォームの例）では、ファーストマイルではStreaming Software側がSRT Caller、Cloudflare Stream（動画配信プラットフォーム）側がSRT Listenerとなります。Listener側が払い出す接続先（live.cloudflare.com）に対して、接続元となるStreaming Softwareで宛先を指定して接続する、というかたちですね。ここでは映像はCallerからListenerに送られます。
ラストマイルではCloudflare Stream（動画配信プラットフォーム）側がこちらもSRT Listener、再生Player側がSRT Callerとなります。やはりListener側で払い出している接続先（live.cloudflare.com）に対して、再生PlayerがURLを指定して接続するかたちです。ただしこのラストマイルではファーストマイルと違い、映像はListenerからCallerに送られています。
この「動画配信プラットフォーム側がどちらもListenerである」という構成、HTTPのサーバ、クライアントの関係と比べてみるとわかりやすいかなと思います。画配信におけるファーストマイル、ラストマイルもHTTPに置き換えることもできますよね。ファーストマイルではHTTP PUTで動画をアップロードし、ラストマイルではHTTP GETで動画をダウンロード（ストリーミング）するかたちです。（プロトコルとしてHTTPとSRTを比べればTCPかUDPかの違いなどなど多くありますが、いったんここではそれはおいておき構成や接続する側・される側といった観点で比較します。）
HTTPサーバに該当するのが動画配信プラットフォームになります、つまりListenerがサーバの役割をしているわけです。またファーストマイル、ラストマイル双方で、HTTPのクライアントとなっているのはCallerの役割をしているStreaming Softwareや再生Playerです。これらは接続元でサーバ（接続先）の情報をあらかじめ知っている必要がある、という点もHTTPとSRTの場合で同じですね。
Caller側はプライベートサブネットでも動作する
SRTではListenerが接続される側、Callerが接続する側で映像伝送の向きは関係ないこと、またHTTPと比べてListenerがサーバ、Callerがクライアントとなることを確認してきました。
SRTについてはその特徴の1つに、FirewallやNATがある環境下でも映像伝送が行える、というものがあります。この点についてもHTTPのサーバ・クライアントの関係と類似していることを比べてみるとわかりやすいのかなと思います。
SRTではCallerとなっているStreaming Softwareや再生Playerですが、自らがパブリックIPアドレス（グローバルIPアドレス）を用いて通信しない、プライベートIPアドレスしか持たない、という環境であることがほとんどであるかと思います。（先ほどの図でもルータのよう機材の配下にデバイスがあることをイメージしてみました。）インターネット（先ほどの例でいうListenerとなるCloudflare Stream）と通信するには、パブリックIPアドレスを有しているルータ側でNATして通信を行います。
この構成、より具体的にするためにAWS環境で考えてみましょう。VPC内のプライベートサブネットにStreaming Softwareや再生Playerがあり、パブリックサブネットに配置されているNAT Gatewayを介してインターネット接続している構成と考えることができます。（このNAT Gateway経由でインターネット通信可能なサブネットを本エントリで「プライベートサブネット」と称することとします。）
まずHTTP（HTTPS含む）の例で考えてみます。Security GroupやNACLが適切に設定してあれば、特別な設定をしなくてもプライベートサブネット内からHTTPサーバに対してHTTPクライアントは問題なく通信が行えます。同様にSRTの場合でも、プライベートサブネットにあるSRT Caller（プライベートIPアドレスしか持たない）はプライベートサブネット内からSRT Listenerに対してNAT Gatewayを経由して問題なく通信が行える、ということになります。
対して、Listener側は接続先となるのでパブリックなIPアドレスでの利用（Listener自体がパブリックIPアドレスを持つ環境での利用）が前提になるかと考えます。（パブリックなIPアドレスを持たない、共有しているような環境下でもListenerとして動作するかもしれませんが、何かしらの工夫は必要になるかと思います。）
RTMP pushとpullについても確認してみる
先日のアップデートでSRT Callerの確認をした際、以下のAWS Elemental LiveのSRT入力のの記事についても閲覧していました。この記事ではRTMP pull endpointとの比較についての記載があります。
そういえば、AWS Elemental MediaLiveにはInputでRTMP pushのほかRTMP pullも選択することができましたね。MediaLiveのInput設定画面を確認しながら、RTMPのpushとpullについても確認してみましょう。
RTMP push
まずはRTMP pushです。Input typeでRTMP (push)を選択します。Input destinationsではApplication nameとApplication instanceの項目を入力します。Inputリソース作成後は、これら2つの項目はEndpointのパスに使われるかたちですね。
Inputリソース作成後、Endpointが払い出されました。IPアドレスに接続するかたちです。RTMP pushは接続先となり、SRT Listenerと同様となることがわかります。
RTMP pull
続いてRTMP pullです。Input typeでRTMP (pull)を選択します。Input sourceとしてはURLを指定するかたちです。ユーザガイドにも記載があるとおりRTMP EndpointのURLを設定することとなります。（Setting up an RTMP pull source - AWS Elemental MediaLive）RTMP pullではこのURLに接続して映像を引き出すかたちですね。接続する側なのでSRT Callerと同様と言えます。
RTMPのpushとpullのまとめ
RTMP pushがSRT Listenerと同じく接続される側のモード、RTMP pullはSRT Callerと同じく接続する側となります。一般的にはRTMP pushが動画配信プラットフォームに映像を打ち上げる方式、RTMP pullが動画配信プラットフォームから動画配信を再生するときに使う形式となることが多いかと思います。しかし動画配信プラットフォームの映像入力（例えばMediaLive Input）にRTMP pullが使われることもありますね。
まとめ
SRTプロトコルのListenerとCallerの違いについて、AWS Elemental MediaConnectの設定項目やCloudflare StreamでのSRTを使ったライブストリーミングを例に確認してみました。接続する側がCaller、接続される側がListenerで映像伝送の向きは関係ありません。接続するCaller側はプライベートサブネットのような、NATを介してListenerと接続するような環境下でも特別な設定なく動作します。
7
