要約

  • RTPのシーケンス番号は送信されたパケットの順番を示し、タイムスタンプは形式固有のサンプリング時計または再生時計上の位置を示す。どちらも絶対的な送信時刻の証明ではない。
  • 複数のストリームを合わせるときは、RTCP Sender ReportがRTPカウンターとNTP形式の参照値を同じ瞬間で対応付ける。同期の根拠は裸の数値ではなく、その対応関係にある。

RFC 3550がいう32ビットのタイムスタンプは、パケット内の先頭オクテットがサンプリングされた時点を表す。周期的に生成されるメディアなら、送信時にシステム時計を読むのではなく、名目上のサンプリング時計から値を得る。「timestamp」という名前だけを見て送信日時と読むと、最初の一歩で意味を取り違える。

RTPはHenning Schulzrinne、Stephen Casner、Ron Frederick、Van Jacobsonの共同著作である。1996年のRFC 1889を、2003年のRFC 3550が置き換えた。USC Information Sciences Instituteは、CasnerがRTPの開発と標準化を率いたと記録している。本稿が彼を軸にする理由はそこにあり、四人とワーキンググループの成果を単独発明へ縮めるものではない。

送った順番と、内容が属する時点

16ビットのシーケンス番号は、RTPデータパケットを一個送るたびに一つ増える。受信側は欠落の検出や送信順の復元に使える。初期値はランダムなので、通話全体を一から数える伝票ではない。ある送信元の一つのシーケンス空間における位置である。

タイムスタンプは別の時計に従う。その周波数はペイロード形式ごとに決まる。固定レート音声で160サンプル分のブロックを読めば、値は160進む。そのブロックが無音として送信されなくても同じである。ネットワークにパケットがない時間にも、メディアの連続性は進んでいる。

映像では、一つのフレームが複数パケットにまたがる。シーケンス番号は連続しても、全パケットのタイムスタンプが等しいことがある。逆に、符号化方式によってはサンプリング順と送信順が異なり、シーケンス番号が単調に増える一方で、隣接パケットのタイムスタンプは単調にならない。

したがって、同じ値は重複パケットの証拠ではなく、値の後退はネットワークでの並べ替えの証拠でもない。同一フレームの分割や符号化順序という説明が残る。観測装置が二つの軸を一列に潰したとき、正常なメディア構造が障害に見える。

タイムスタンプの初期値もランダムである。差を秒へ直すにはクロックレートが要る。どの流れの値か判断するにはSSRCが要る。別の流れと同じ時間軸に置くには、さらに対応情報が要る。32ビットの整数だけを保存しても、後から三つの条件は戻せない。

音声と映像は、数値を見比べてもそろわない

同じ瞬間に収録した音声と映像でも、RTPタイムスタンプは似ていない。レートが違い、ランダムな初期オフセットも独立している。RFC 3550は、異なるメディアの値を直接比較しても同期には使えないと明記する。

これは欠落ではなく、データパスを身軽にする境界である。一つのストリーム内なら、メディア時計で再生順を作り、到着間隔との違いからジッターを測れる。全データパケットに絶対日時を持たせたり、すべての送信機にNTPの稼働を要求したりする必要はない。

ストリームをそろえる場面でRTCPが登場する。Sender Reportは、同じ瞬間に対応するNTP形式の参照タイムスタンプとRTPタイムスタンプを並べる。この一組が、ローカルなメディアカウンターを参照時計へ写す関係を定義する。音声と映像はそれぞれの写像を通して共通時計上に置かれる。

その組は全パケットには入らない。RTCPで低い頻度で送られ、受信側は既知のレートから間を補う。報告内のRTP値は、隣のデータパケットの値と一致しないのが普通だ。報告が指す参照時点に合わせて計算されるからである。近接パケットとの完全一致を検証条件にすれば、正しい対応を捨ててしまう。

NTP形式であることもUTCの保証ではない。RFC 3550は、絶対時刻を持たないシステムが稼働時間のような共通の相対時計を使うことを認め、時刻も経過時間も分からない送信側にはゼロも認める。ビット配置は表現を決めるが、時計の由来や精度までは証明しない。

RFC 7273は後に、RTCP SRのNTP/RTP組が写像を定義すると整理した。複数ソースの同時再生には、参照タイムスタンプ同士が同期している必要がある。Sender Reportは相関の受領証であって、参照時計を正確にする装置ではない。

連続した声を細い回線で運んだ経験

Casnerの時間設計は、抽象的なメタデータ論から始まったわけではない。ISIの記録によれば、彼はARPANET上のパケット音声に取り組み、連続した音を圧縮し、限られた帯域に合わせて分割し、受信側で再構成した。その後はパケット映像、MBONE、RTPの開発と標準化へ進んだ。ISIの追悼記事は、その系譜をNetwork Voice ProtocolとPacket Video Protocolへつないでいる。

だからRTPの情報は節度がある。資源予約もサービス品質も保証しない。ネットワークは遅延し、落とし、到着順を変え得る。その中でアプリケーションが連続したメディアを戻せるよう、ペイロード、送信元、順序、メディア時間、配送報告を分けて渡す。

2003年の改訂も、ワイヤ上のパケット形式は変えなかった。RFC 3550が最大の変更とするのは、多数参加時にRTCP送信が過剰にならないようタイマー算法を改善した点である。データフィールドの意味を広げず、制御証拠の流量を調整した。

保存すべきなのは時刻ではなく時刻域

有効な観測記録には、RTPタイムスタンプだけでなく、SSRC、ペイロード形式、クロックレート、シーケンス番号、取得時刻、前後の有効なRTP/NTP対応が要る。参照値が相対時間またはゼロなら、その状態も残す。

そうすれば、シーケンスの穴は損失候補、カウンターの不連続は再起動・形式変更・再生ジャンプの候補、Sender Reportの長い空白は写像の不確かさとして扱える。共通参照へ写した後で音声と映像の差が拡大して初めて、クロックドリフトを疑う根拠ができる。

文脈を捨てた監視は、全値を90,000で割り、サンプリング順で送信順を並べ、独立したオフセットを引き算し、相対NTP値をUTCとして表示する。どれも数字は出るが、RFCが与えた証拠ではない。

Casnerの仕事から残る原則は明快だ。便利そうな一つの列に全時間を背負わせない。各時計の領域を保存し、領域をまたぐ主張には、明示された写像を添える。

情報源