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] をサポートするために行われます。