1. はじめに

リアルタイム輸送プロトコル (RTP) [1] は、データ転送プロトコルと関連する制御プロトコル (RTCP) の 2 つのコンポーネントで構成されています。歴史的に、RTP と RTCP は別々の UDP ポートで実行されてきました。ネットワークアドレスポート翻訳 (NAPT) [14] の使用が増えるにつれて、複数の NAT バインディングを維持することはコストがかかる可能性があるため、これが問題になっています。また、RTP トラフィックを許可するために複数のポートを開く必要があるため、ファイアウォールの管理も複雑になります。このメモは、単一のメディアタイプの RTP および RTCP フローを単一のポートで実行して NAT トラバーサルを容易にし、ファイアウォール管理を簡素化する方法について議論し、そのような多重化がいつ適切であるかを検討します。単一のポートへの複数のタイプのメディア (例: オーディオとビデオ) の多重化は、ここでは考慮されません ([1] のセクション 5.2 を参照)。

このメモは次のように構成されています。セクション 2 では、別々のポートの使用に至った設計上の選択について議論し、現在のネットワーク環境におけるそれらの選択の適用可能性についてコメントします。セクション 3 では用語について、セクション 4 では多重化されたパケットを区別する方法について議論します。次に、RTP と RTCP をいつどのように多重化すべきか、および多重化されたセッションをシグナリングする方法をセクション 5 で指定します。帯域幅とサービス品質 (QoS) の問題についてはセクション 6 で議論します。最後に、セクション 7 のセキュリティの考慮事項とセクション 8 の IANA の考慮事項で締めくくります。

このメモは、[1] のセクション 11 を更新します。

2. 背景

RTP セッションは、データパケットと定期的な制御 (RTCP) パケットで構成されます。RTCP パケットは「データパケットと同じ配信メカニズム」を使用することが想定されており、「基礎となるプロトコルは、たとえば UDP で別々のポート番号を使用して、データと制御パケットの多重化を提供しなければならない (MUST)」[1]。多重化が RTP 内で提供されるのではなく、基礎となるトランスポートプロトコルに委ねられたのは、次の理由によります。

単純さ: RTP と RTCP の逆多重化をトランスポート層に移動することで、RTP 実装はデータパケットと制御パケットの分離に関与する必要がなくなるため、実装が簡素化されます。これにより、データプレーンと制御プレーンを明確に分離した、非常に自然な方法で実装を構成できます。
効率性: 統合層処理 [15] の原則に従い、スタックの複数の層に分割される (例: UDP ポート、次にパケットタイプによる) よりも、単一の場所 (例: UDP ポートによる) で逆多重化が行われる方が、実装の効率が高くなります。
サードパーティモニターを有効にするため: ユニキャスト Voice-over-IP が常に考慮されてきましたが、RTP は緩やかに結合されたマルチキャスト会議 [16] や、非常に大規模なマルチキャストストリーミングメディアアプリケーション (いわゆるトリプルプレイ IP テレビ (IPTV) サービスなど) もサポートするように設計されています。したがって、RTP の設計では、データパケットとは別の IP マルチキャストグループおよび UDP ポートを使用して RTCP パケットをマルチキャストできます。これにより、セッションの参加者が受信品質のフィードバックを得ることができるだけでなく、データパケットにアクセスすることなく受信品質を聞き取るサードパーティモニターの導入も可能になります。これは、プライバシーを損なうことなく、マルチキャストセッションの管理性を提供することを目的としていました。

これらの設計上の選択は、RTP の多くの用途には適切ですが、場合によっては問題となります。IP マルチキャストを使用しない RTP 導入は多く、ネットワークアドレス変換 (NAT) の使用が増えるにつれて、トランスポート層での多重化の単純さは、複数の NAT ピンホールを開くために複雑なシグナリングを必要とするため、不利益になっています。このような環境では、別々の UDP ポートを使用して RTP と RTCP を逆多重化する代わりに、単一の UDP ポートのみを使用し、アプリケーション内で逆多重化を行う代替案を提供することが望ましいです。

このメモは、RTP ペイロードタイプと RTCP パケットタイプ値によって区別される、単一の UDP ポート上で RTP と RTCP パケットを多重化することにより、そのような代替案を提供します。これにより、NAT トラバーサルの簡素化と引き換えに、RTP 実装に若干の追加作業が発生します。

3. 用語

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [2] の記述に従って解釈されるものとします。

4. 判別可能な RTP および RTCP パケット

RTP パケットと RTCP パケットが単一のポートに多重化される場合、RTCP パケットタイプフィールドは、パケット内の RTP マーカー (M) ビットと RTP ペイロードタイプ (PT) の組み合わせと同じ位置を占めます。このフィールドは、次の 2 つの制限が遵守されている場合に、RTP パケットと RTCP パケットを区別するために使用できます。1) 使用される RTP ペイロードタイプ値が、使用される RTCP パケットタイプと異なっていること。2) 各 RTP ペイロードタイプ (PT) について、PT+128 が使用される RTCP パケットタイプと異なっていること。最初の制約は、RTP ペイロードタイプと RTCP パケットタイプの間の直接的な衝突を回避します。2 番目の制約は、マーカービットが設定された RTP データパケットと RTCP パケットの間の衝突を回避します。

RTP パケットタイプと RTCP パケットタイプの間の次の衝突が知られています。

RTP ペイロードタイプ 64-65 は、元の "RTP Payload Format for H.261 Video Streams" [3] ([17] によって廃止) で定義された (廃止された) RTCP FIR および NACK パケットと衝突します。
RTP ペイロードタイプ 72-76 は、RTP 仕様 [1] で定義された RTCP SR、RR、SDES、BYE、および APP パケットと衝突します。
RTP ペイロードタイプ 77-78 は、RTP/AVPF プロファイル [4] で定義された RTCP RTPFB および PSFB パケットと衝突します。
RTP ペイロードタイプ 79 は、RTCP 拡張レポート (XR) [5] パケットと衝突します。
RTP ペイロードタイプ 80 は、"RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6] で定義された受信者サマリー情報 (RSI) パケットと衝突します。

新しい RTCP パケットタイプは将来登録される可能性があり、RTP と RTCP を単一のポートに多重化する際に利用可能な RTP ペイロードタイプをさらに減らすことになります。この多重化を可能にするために、将来の RTCP パケットタイプの割り当ては、まず 209-223 の範囲の現在の割り当ての後に行われ、次に 194-199 の範囲で行われるべきであり (SHOULD)、その結果、64-95 の範囲の RTP ペイロードタイプのみがブロックされるようになります。1-191 および 224-254 の範囲の RTCP パケットタイプは、他の値が使い果たされた場合にのみ使用されるべきです (SHOULD)。

これらの制約を踏まえ、RTP ペイロードタイプ値の選択には RTP/AVP プロファイル [7] のガイドラインに従うことが推奨されます (RECOMMENDED)。ただし、64-95 の範囲のペイロードタイプ値を使用してはならない (MUST NOT) という追加の制限があります。具体的には、動的な RTP ペイロードタイプは、可能な限り 96-127 の範囲から選択されるべきです (SHOULD)。それだけでは不十分な場合は 64 未満の値を使用してもよいですが (MAY)、その場合は [7] によって静的に割り当てられていないペイロードタイプ番号を最初に使用することが推奨されます (RECOMMENDED)。

注: [1] のセクション 6.1 では、すべての RTCP パケットは送信者レポート (SR) または受信者レポート (RR) パケットで始まる複合パケットとして送信されなければならない (MUST) と規定されているため、RTP と RTCP を多重化する際に 72 と 73 以外の RTP ペイロードタイプが禁止されている理由を疑問に思うかもしれません。これは、特定の状況で非複合 RTCP パケットの使用を許可する [18] をサポートするために行われます。