要約

  • RTSPでは、成功したSETUPがサーバー側の制御コンテキストを作り、Session識別子を返した。SDPの記述やTCP接続の存在だけでは、その状態は生まれない。
  • セッションは制御接続を替えて存続できたが、識別子だけで正しいURI、メソッドの状態、認証、到達可能なメディア経路を代用することはできなかった。
  • サーバーが状態を保持し、有効な存続信号を受け取る間だけセッションは続いた。TEARDOWN、タイムアウト、終端処理の後には、同じ値を送っても454 Session Not Foundになり得た。

ソケットを「視聴の記憶」にしない

ストリーミング制御には、最初から二つの時間があった。PLAYやPAUSEを運ぶ要求は短く、TCP接続も切れ得る。一方、選んだ映像、音声の配送先、再生位置、まとめて操作するトラックという文脈は、その一回の要求より長く生きる。1998年のRFC 2326は、このずれを「RTSP connectionという概念はない」と表現した。サーバーが持つセッションは識別子で示され、TCPのようなトランスポート接続から独立していた。

これはTCPを不要にしたという意味ではない。命令と応答には経路が要り、メディアを制御チャネルへ多重化する場合もある。切り離したのは因果関係である。あるソケットが閉じたからといって、サーバーが準備済みの配送状態を直ちに捨てたことにはならない。逆に、ソケットが開いているからといって、有効なセッションが存在する証拠にもならない。

この区別により、クライアントはSETUPとPLAYの後で接続を閉じ、必要になった時に別の接続からPAUSEを送れる。NATの状態切れや一時的な経路障害でTCPが失われても、制御対象まで自動的に失わせない余地ができた。

SDPは設計図であり、予約の受領書ではなかった

クライアントはしばしば、制御を始める前にプレゼンテーションの記述を得る。RFC 4566のSDPは、メディア種別、形式、アドレスなどを表現する書式である。プロトコルを実行するものでも、トランスポートを予約するものでもない。

SDPにもsessionという語が現れるため、境界は見失われやすい。説明文に音声と映像が列挙され、制御URIが書かれていても、特定の利用者向けにポート、バッファー、配送方式が確保されたとは限らない。説明は「何が提供され得るか」を述べる。受け入れ済みの操作状態はまだ別に必要だった。

RTSPではSETUPがその境界を越えた。クライアントは対象メディアと受信可能なTransport候補を示し、サーバーは受け入れ可能な方式を選び、必要なパラメーターを保存して応答した。2016年にRTSP 2.0を定めたRFC 7826は、これをRTSP session contextの作成として明記する。成功応答のSessionヘッダーは、サーバーが実際に保持した文脈への参照だった。

もう一つのアドレスは、資源でなく記憶を指した

メディアURIは操作される対象を示す。Session識別子は、同じ対象について複数作られ得る配送文脈を見分ける。RTSP 1.0は最低8オクテットのランダムで不透明な値を求めた。RTSP 2.0は8文字から128文字とし、暗号学的にランダムな生成と、およそ128ビットのエントロピーを推奨した。その根拠として参照されたRFC 4086は、予測可能な乱数がセキュリティ用途の値を弱くする理由を扱っている。

しかし、推測しにくさは権限ではない。RFC 7826は、クライアント、サーバー、信頼されるプロキシの間で値を秘匿しなければ、Session識別子だけでは乗っ取りを防げないと警告する。文字列は保存されたレコードを探す鍵にはなるが、利用者がその映像を見る資格、契約が有効か、いまの命令が許可されるかは答えない。

認証は別の仕組みで処理された。たとえばRFC 7616のDigest認証は、チャレンジ、資格情報、nonce、リプレイ対策を備える。同じ要求にSessionと認証応答が共存するのは重複ではない。前者は「どの保存状態か」、後者は「どの要求者を、どの保護領域で受け入れるか」を問う。

識別子を知っていても、正しいURIが必要だった

PLAY、PAUSE、TEARDOWNなどはSession値を添えて、既存の文脈に到達できた。それでも要求URIは消えなかった。音声と映像を共通の時間軸で動かすaggregate sessionでは、複数トラックが一つの識別子に属し得る。全体をPLAYする操作は、個別トラックのURIではなく適切なaggregate control URIへ送らなければならない。

URIはプロキシのルーティング、対象資源、ログの範囲を示す。Sessionはサーバー内部のレコードを見つける。現在の状態でそのメソッドが妥当か、どの範囲へ作用するかはさらに別の判断である。RTSPが「セッションがない」「現在の状態ではメソッドが使えない」「aggregate操作の範囲が違う」を異なる失敗として扱ったのは、便利な検索キーに全ての意味を背負わせないためだった。

既存セッションへ別のメディアを加えるSETUPが失敗した時も、RTSP 2.0は元のセッションとTransport状態を、失敗要求がなかったかのように保つよう求めた。部分的な要求が、すでに合意済みの制御面を黙って書き換えることを防いだのである。

一つの接続に複数セッション、一つのセッションに複数接続

RTSP 2.0のサーバーは、持続的TCP接続と一時的接続の両方を扱う。一つの持続接続が複数セッションの命令を運べるため、ソケットをセッションの身元とはみなせない。反対に、一つのセッションは順番に異なる接続を使える。ただし同じ時点では、そのセッションについて一つの接続だけを使い、サーバー発の要求をどこへ送るかを曖昧にしない。

この規則はセッションを再びTCPへ縛るものではない。現在利用する制御通路を選ぶだけである。接続の存続、制御文脈の存続、メディア配送の成否という三つの状態は、それぞれ観測しなければならない。

特にUDPでRTPを送る場合、制御が有効でもメディア候補へ到達できるとは限らない。RFC 7825がRTSP制御下のメディアにICEを適用したのは、NATやファイアウォールを越える実際の経路確認が別途必要だったからだ。Sessionは「どの状態を操作するか」を示すが、「パケットが通るか」を証明しない。

記憶を残すには存続信号が要った

サーバーは放棄された状態を無期限に持てない。Session応答では、次の要求や許容される活動まで待つtimeoutを通知でき、指定がなければ既定値は60秒だった。RTSP 2.0ではtimeoutは応答専用で、成立したセッションの途中で長さを変えられない。

その文脈を参照するRTSP要求は存続の証拠になり得た。純粋なkeep-aliveには、空のSET_PARAMETERが推奨された。RTPを用いる構成ではRTCPも役割を持つ。RFC 3550のsender reportやreceiver reportは、送信源や受信状況について統計的な情報を伝える。RFC 7826は、適切な送信源とネットワークtupleに結びついた報告を、クライアント側がまだ存在する証拠として扱えるようにした。

それでもRTCPは視聴証明ではない。報告は間欠的で損失し得る。フレームが復号されたこと、利用者が見ていたこと、課金権限が続くこと、PLAYが業務上完了したことまでは示さない。存続信号はサーバー状態を保持する理由であり、メディア体験の領収書ではなかった。

値が残っていても、指す状態は消える

正常終了ではTEARDOWNを使う。aggregateの範囲なら、まとめた配送を停止して文脈を破棄できる。許された個別メディアのTEARDOWNは一部だけを外し、最後の要素がなくなればセッションも終わる。サーバーはtimeout、REDIRECTに伴う終了、回復不能な障害でも状態を消し得る。

この境界を越えた後、古い識別子を正確に再送しても復活はしない。454 Session Not Foundは、Sessionが欠けている、無効である、または時間切れである場合を扱う。クライアントの記憶に同じ文字列が残ることと、サーバーに生きたレコードがあることは別の事実だった。

RTSPの教訓は、識別子がセッションを内包しない点にある。それはサーバーが取り消せる状態への参照である。TCP接続、値の所持、URI、認証、メディア到達性、存続信号はいずれも証拠を加えるが、互いを代用できない。