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 実装に若干の追加作業が発生します。