メインコンテンツまでスキップ

5. 単一ポート上での RTP と RTCP の多重化

単一のポートで RTP と RTCP を多重化する手順は、セッションがユニキャストセッションかマルチキャストセッションかによって異なります。マルチキャストセッションの場合、手順はエニーソースマルチキャスト (ASM) またはソース固有マルチキャスト (SSM) のどちらを使用するかによっても異なります。

5.1. ユニキャストセッション​

セッションで使用される RTP ペイロードタイプがセクション 4 のルールに従って選択され、多重化が事前にシグナリングされている場合に限り、ユニキャストセッションの NAT トラバーサルを容易にするために単一の UDP ポート上で RTP パケットと RTCP パケットを多重化することは許容されます。以下のセクションでは、オファー/アンサーモデルを使用したセッション開始プロトコル (SIP) を使用して、このような多重化されたセッションをシグナリングする方法を説明します。

5.1.1. SDP シグナリング​

オファー/アンサーモデル [9] に従って RTP セッションをネゴシエートするためにセッション記述プロトコル (SDP) [8] が使用される場合、"a=rtcp-mux" 属性 (セクション 8 を参照) は RTP と RTCP を単一のポートに多重化したいという要望を示します。最初の SDP オファーは、単一のポート上での RTP と RTCP の多重化を要求するために、メディアレベルでこの属性を含まなければなりません (MUST)。例：

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

このオファーは、iLBC コーディングを使用し RTP/AVP プロファイルを使用するユニキャスト Voice-over-IP セッションを表します。アンサー側は、IPv6 アドレス 2001:DB8::211:24ff:fea3:7a2e のポート 49170 に RTP と RTCP の両方を送信するように要求されます。

アンサー側が RTP と RTCP を単一のポートに多重化したい場合は、アンサーにメディアレベルの "a=rtcp-mux" 属性を含まなければなりません (MUST)。アンサーで使用される RTP ペイロードタイプは、セクション 4 のルールに準拠していなければなりません (MUST)。

アンサーに "a=rtcp-mux" 属性が含まれていない場合、オファー側は単一のポート上で RTP パケットと RTCP パケットを多重化してはなりません (MUST NOT)。代わりに、通常のポート選択ルールに従って割り当てられたポート (ポートペア、または "a=rtcp:" 属性 [10] も含まれている場合はシグナリングされたポート) で RTCP を送受信する必要があります。これは、"a=rtcp-mux" 属性を解釈できないピアと通信する場合に発生します。

SDP が宣言的な方法で使用される場合、"a=rtcp-mux" 属性の存在は、送信者が同じポートで RTP と RTCP を多重化することを示します。受信者は RTP ポートで RTCP パケットを受信する準備ができていなければならず (MUST)、RTCP 帯域幅を含めてリソース予約を行う必要があります。

5.1.2. SIP フォーキングとの相互作用​

フォーキングプロキシを介して SIP を使用する場合、1 つの INVITE リクエストに対して複数の 200 (OK) レスポンスが返される可能性があります。その INVITE で RTP と RTCP の多重化がオファーされている場合、アンサー側の中には多重化された RTP と RTCP をサポートするものもあれば、サポートしないものもあることに注意することが重要です。このため、多重化をサポートする呼び出しのブランチが別の RTP および RTCP ポートを使用するように再ネゴシエートされない限り、オファー側は RTP ポートと通常の RTCP ポートの両方で RTCP をリッスンし、両方のポートで RTCP を送信する必要があります。

5.1.3. ICE との相互作用​

ネットワークアドレス変換 (NAT) デバイスまたはその他のミドルボックスが存在する環境で RTP セッションを確立するために、対話型接続確立 (ICE) [19] 手法を使用することが一般的です。RTP と RTCP が別々のポートで送信される場合、RTP メディアストリームは ICE において 2 つのコンポーネント (RTP 用と RTCP 用) で構成され、各コンポーネントに対して接続チェックが実行されます。RTP と RTCP が同じポートに多重化される場合、これらの接続チェックの一部を回避でき、ICE のオーバーヘッドを削減できます。

ICE と、多重化された RTP および RTCP の両方を使用したい場合、最初のオファーには RTP と RTCP の多重化が望ましいことを示す "a=rtcp-mux" 属性を含まなければならず (MUST)、さらに RTP と RTCP 両方の "a=candidate:" 行と、アンサー側が RTP と RTCP の多重化をサポートしていない場合の RTCP 用フォールバックポートを示す "a=rtcp:" 行を含まなければなりません (MUST)。これは、RTP と RTCP の多重化を希望する各メディアに対して行われなければなりません (MUST)。

アンサー側が単一のポート上で RTP と RTCP を多重化したい場合は、多重化を使用したい各メディアに対して、"a=rtcp-mux" 属性と、RTP ポートに対応する単一の "a=candidate:" 行 (つまり、RTCP 用の候補はない) を含むアンサーを生成しなければなりません (MUST)。その後、アンサー側は、オファーに RTP 用の候補が 1 つしか含まれていなかったかのように、そのメディアの接続チェックを実行します。アンサー側が単一のポート上で RTP と RTCP を多重化することを望まない場合は、アンサーに "a=rtcp-mux" 属性を含めてはならず (MUST NOT)、通常の方法ですべてのオファーされた候補に対して接続チェックを実行しなければなりません (MUST)。

アンサーを受信すると、オファー側は多重化がオファーされた各メディアに対して "a=rtcp-mux" 行の有無を確認します。これが存在する場合、接続チェックは 1 つの候補 (RTP 用) のみがオファーされたかのように進行し、セッションが確立されると多重化が使用されます。"a=rtcp-mux" 行が存在しない場合、セッションは RTP と RTCP の両方の候補を使用して接続チェックを続行し、最終的に ("a=rtcp:" 属性でシグナリングされるように) 別々のポートで RTP と RTCP を使用するセッションが確立されます。

5.1.4. ヘッダー圧縮との相互作用​

RTP パケットと RTCP パケットを単一のポートに多重化すると、圧縮 RTP (CRTP) [20] や堅牢なヘッダー圧縮 (ROHC) [21] [22] などのヘッダー圧縮スキームに悪影響を与える可能性があります。ヘッダー圧縮は、連続するパケットの RTP ヘッダーの変化のパターンを利用して、毎回完全なヘッダーを送信するのではなく、パケットが期待通りの方法で変化したという表示を送信します。フローが一定の動作をする場合、これにより大幅な帯域幅の節約が可能になります。

RTP データパケットと多重化された RTCP パケットが存在すると、ヘッダー間の変化のパターンが乱され、ヘッダー圧縮の効率が大幅に低下する可能性があります。この混乱の程度は、使用されるヘッダー圧縮アルゴリズムとフローの分類方法に依存します。適切に設計された分類器は、ペイロードタイプフィールドを使用して、同じポートに多重化された RTP と RTCP を異なる圧縮コンテキストに分離できる必要があり、その結果、圧縮率への影響は小さくなります。IP アドレスと UDP ポートのみに基づいて圧縮コンテキストを割り当てる分類器は、うまく機能しません。同じポートに多重化された RTP と RTCP を効率的にサポートするために、ヘッダー圧縮の実装を更新する必要があると予想されます。

この RTP と RTCP の多重化によるヘッダー圧縮への影響は、メディアを容量制限のあるチャネルに適合させるためにヘッダー圧縮の効率に依存している一部のワイヤレス電話システムなどの環境において特に重要になる可能性があります。このような環境で使用する前に、RTP と RTCP の多重化の影響を慎重に検討する必要があります。

5.2. エニーソースマルチキャストセッション​

NAT トラバーサルの問題は、ユニキャスト RTP セッションよりもエニーソースマルチキャスト (ASM) RTP セッションの方が深刻ではなく、サードパーティの RTCP 専用モニターをサポートできるため、RTP と RTCP に別々のポートを使用するメリットの方が大きいです。したがって、ASM RTP セッションを使用する場合、RTP パケットと RTCP パケットを単一のポートに多重化すべきではなく (SHOULD NOT)、代わりに別々のポートとマルチキャストグループを使用すべきです (SHOULD)。

5.3. ソース固有マルチキャストセッション​

ソース固有マルチキャスト (SSM) 上で実行される RTP セッションは、マルチキャストチャネルを介してソースから受信者に RTCP パケットを送信しますが、受信者からソースに RTCP を返送するために別のユニキャストフィードバックメカニズム [6] を使用します。ソースは RTCP パケットをグループに転送するか、集約されたサマリーレポートを送信します。

[6] の用語に従い、SSM セッションにおける 3 つの RTP/RTCP フローを識別します。

  1. メディア送信者と配信ソース間の RTP および RTCP フロー。多くのシナリオでは、メディア送信者と配信ソースは同じ場所に配置されているため、多重化は問題になりません。メディア送信者と配信ソースがユニキャスト接続で接続されている場合、その接続にはこのメモのセクション 5.1 のルールが適用されます。メディア送信者と配信ソースがエニーソースマルチキャスト接続で接続されている場合、その接続にはセクション 5.2 のルールが適用されます。メディア送信者と配信ソースがソース固有マルチキャスト接続で接続されている場合、これが (SDP を使用している場合は "a=rtcp-mux" を使用して) シグナリングされていれば、RTP パケットと RTCP パケットを単一のポートに多重化してもよいです (MAY)。

  2. 配信ソースから受信者に送信される RTP および RTCP。配信ソースは、フォワード SSM パス上の NAT トラバーサルの問題を軽減するために RTP と RTCP を単一のポートに多重化してもよいが (MAY)、セッションが単純なフィードバックモデルを使用している場合、そうすることはサードパーティの見守りデバイスを妨げる可能性があります。SDP を使用する場合、多重化は "a=rtcp-mux" 属性を使用してシグナリングされるべきです (SHOULD)。

  3. 受信者から配信ソースに送信される RTCP。これは RTCP のみのパスであるため、多重化は問題になりません。

SSM セッションにおいて RTP パケットと RTCP パケットを単一のポートに多重化することは、セクション 5.1.4 で説明したヘッダー圧縮との相互作用の可能性があります。

に最終更新