[要約] RFC 5761は、RTPデータと制御パケットを単一のポートで多重化するための仕様です。目的は、RTPとRTCPの通信を効率的に行うために、複数のパケットを同じポートで処理する方法を提供することです。
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5761 University of Glasgow
Updates: 3550, 3551 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2010
Multiplexing RTP Data and Control Packets on a Single Port
単一のポートでのRTPデータと制御パケットの多重化
Abstract
概要
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions.
このメモは、単一のUDPポートでRTPデータパケットとRTP制御プロトコル（RTCP）パケットを多重化するときに発生する問題について説明します。RFC 3550とRFC 3551を更新して、そのような多重化が適切ではなく適切ではないことを説明し、セッション説明プロトコル（SDP）を使用してマルチプレックスセッションを信号する方法を説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5761.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5761で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Background ......................................................3
3. Terminology .....................................................4
4. Distinguishable RTP and RTCP Packets ............................4
5. Multiplexing RTP and RTCP on a Single Port ......................6
5.1. Unicast Sessions ...........................................6
5.1.1. SDP Signalling ......................................6
5.1.2. Interactions with SIP Forking .......................7
5.1.3. Interactions with ICE ...............................7
5.1.4. Interactions with Header Compression ................8
5.2. Any Source Multicast Sessions ..............................9
5.3. Source-Specific Multicast Sessions .........................9
6. Multiplexing, Bandwidth, and Quality of Service ................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
The Real-time Transport Protocol (RTP) [1] comprises two components: a data transfer protocol and an associated control protocol (RTCP). Historically, RTP and RTCP have been run on separate UDP ports. With increased use of Network Address Port Translation (NAPT) [14], this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports must be opened to allow RTP traffic. This memo discusses how the RTP and RTCP flows for a single media type can be run on a single port, to ease NAT traversal and simplify firewall administration, and considers when such multiplexing is appropriate. The multiplexing of several types of media (e.g., audio and video) onto a single port is not considered here (but see Section 5.2 of [1]).
リアルタイムトランスポートプロトコル（RTP）[1]は、データ転送プロトコルと関連する制御プロトコル（RTCP）の2つのコンポーネントで構成されています。歴史的に、RTPとRTCPは別々のUDPポートで実行されてきました。ネットワークアドレスポート翻訳（NAPT）[14]の使用が増加すると、複数のNATバインディングを維持することにコストがかかる可能性があるため、これは問題になりました。また、RTPトラフィックを許可するために複数のポートを開く必要があるため、ファイアウォール管理も複雑にします。このメモでは、単一のメディアタイプのRTPとRTCPの流れを単一のポートで実行する方法について説明し、NATトラバーサルを緩和し、ファイアウォールの管理を簡素化し、そのような多重化が適切である場合を検討します。ここでは、いくつかのタイプのメディア（オーディオやビデオなど）を単一のポートにマルチプレックスすることは考慮されません（ただし、[1]のセクション5.2を参照）。
This memo is structured as follows: in Section 2 we discuss the design choices that led to the use of separate ports and comment on the applicability of those choices to current network environments. We discuss terminology in Section 3 and how to distinguish multiplexed packets in Section 4; we then specify when and how RTP and RTCP should be multiplexed, and how to signal multiplexed sessions, in Section 5. Quality of service and bandwidth issues are discussed in Section 6. We conclude with security considerations in Section 7 and IANA considerations in Section 8.
このメモは次のように構成されています。セクション2では、個別のポートの使用につながった設計の選択肢について説明し、現在のネットワーク環境へのこれらの選択の適用性についてコメントします。セクション3の用語と、セクション4の多重化されたパケットを区別する方法について説明します。次に、セクション5で、RTPとRTCPをマルチプレックス化する方法と方法、および多重化セッションをマルチプレックスする方法を指定します。セクション6でサービスの質と帯域幅の問題について説明します。。
This memo updates Section 11 of [1].
このメモは、[1]のセクション11を更新します。
An RTP session comprises data packets and periodic control (RTCP) packets. RTCP packets are assumed to use "the same distribution mechanism as the data packets", and the "underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP" [1]. Multiplexing was deferred to the underlying transport protocol, rather than being provided within RTP, for the following reasons:
RTPセッションは、データパケットと周期制御（RTCP）パケットで構成されています。RTCPパケットは「データパケットと同じ分布メカニズム」を使用すると想定されており、「基礎となるプロトコルは、UDPで個別のポート番号を使用するなど、データと制御パケットの多重化を提供する必要があります」[1]。次の理由により、多重化はRTP内で提供されるのではなく、基礎となる輸送プロトコルに延期されました。
1. Simplicity: an RTP implementation is simplified by moving the RTP and RTCP demultiplexing to the transport layer, since it need not concern itself with the separation of data and control packets. This allows the implementation to be structured in a very natural fashion, with a clean separation of data and control planes.
1. シンプルさ：RTPの実装は、データと制御パケットの分離に関係する必要がないため、RTPとRTCPの脱臼を輸送層に移動することにより簡素化されます。これにより、データとコントロールプレーンのきれいな分離により、実装を非常に自然に構成できます。
2. Efficiency: following the principle of integrated layer processing [15], an implementation will be more efficient when demultiplexing happens in a single place (e.g., according to UDP port) than when split across multiple layers of the stack (e.g., according to UDP port and then according to packet type).
2. 効率：統合レイヤー処理の原則[15]に従って、スタックの複数のレイヤーに分割される場合よりも、単一の場所で非gultiplexingが発生する場合（例：UDPポートによる）実装がより効率的になります（例えば、UDPポートに従って、そして、パケットタイプに従って）。
3. To enable third-party monitors: while unicast voice-over-IP has always been considered, RTP was also designed to support loosely coupled multicast conferences [16] and very large-scale multicast streaming media applications (such as the so-called triple-play IP television (IPTV) service). Accordingly, the design of RTP allows the RTCP packets to be multicast using a separate IP multicast group and UDP port to the data packets. This not only allows participants in a session to get reception-quality feedback but also enables deployment of third-party monitors, which listen to reception quality without access to the data packets. This was intended to provide manageability of multicast sessions, without compromising privacy.
3. サードパーティのモニターを有効にするには：ユニキャストのボイスオーバーIPは常に考慮されていますが、RTPは、ゆるい結合マルチキャスト会議[16]および非常に大規模なマルチキャストストリーミングメディアアプリケーション（いわゆるトリプルトリプルなどをサポートするように設計されています。IPテレビ（IPTV）サービスを再生します）。したがって、RTPの設計により、RTCPパケットは、別のIPマルチキャストグループとUDPポートをデータパケットに使用してマルチキャストにすることができます。これにより、セッションの参加者が受信品質のフィードバックを得ることができるだけでなく、データパケットにアクセスせずに受信品質を聴くサードパーティモニターの展開を可能にします。これは、プライバシーを損なうことなく、マルチキャストセッションの管理可能性を提供することを目的としています。
While these design choices are appropriate for many uses of RTP, they are problematic in some cases. There are many RTP deployments that don't use IP multicast, and with the increased use of Network Address Translation (NAT) the simplicity of multiplexing at the transport layer has become a liability, since it requires complex signalling to open multiple NAT pinholes. In environments such as these, it is desirable to provide an alternative to demultiplexing RTP and RTCP using separate UDP ports, instead using only a single UDP port and demultiplexing within the application.
これらの設計の選択は、RTPの多くの用途に適していますが、場合によっては問題があります。IPマルチキャストを使用しない多くのRTP展開があり、ネットワークアドレス変換（NAT）の使用の増加により、輸送層での多重化の単純さは、複数のNATピンホールを開くために複雑なシグナリングが必要なため、責任になりました。これらのような環境では、個別のUDPポートを使用してRTPとRTCPを非難する代わりに、単一のUDPポートのみを使用してアプリケーション内で非難することが望ましいです。
This memo provides such an alternative by multiplexing RTP and RTCP packets on a single UDP port, distinguished by the RTP payload type and RTCP packet type values. This pushes some additional work onto the RTP implementation, in exchange for simplified NAT traversal.
このメモは、RTPペイロードタイプとRTCPパケットタイプの値で区別される単一のUDPポートでRTPおよびRTCPパケットをマルチプレックスすることにより、このような代替案を提供します。これにより、単純化されたNATトラバーサルと引き換えに、RTP実装にいくつかの追加作業がプッシュされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
When RTP and RTCP packets are multiplexed onto a single port, the RTCP packet type field occupies the same position in the packet as the combination of the RTP marker (M) bit and the RTP payload type (PT). This field can be used to distinguish RTP and RTCP packets when two restrictions are observed: 1) the RTP payload type values used are distinct from the RTCP packet types used; and 2) for each RTP payload type (PT), PT+128 is distinct from the RTCP packet types used. The first constraint precludes a direct conflict between RTP payload type and RTCP packet type; the second constraint precludes a conflict between an RTP data packet with the marker bit set and an RTCP packet.
RTPとRTCPパケットが単一のポートに多重化されると、RTCPパケットタイプのフィールドは、RTPマーカー（M）ビットとRTPペイロードタイプ（PT）の組み合わせと同じ位置をパケットで占めます。このフィールドは、2つの制限が観察された場合、RTPとRTCPパケットを区別するために使用できます。1）使用されるRTPペイロードタイプの値は、使用されるRTCPパケットタイプとは異なります。2）各RTPペイロードタイプ（PT）について、PT 128は使用されるRTCPパケットタイプとは異なります。最初の制約は、RTPペイロードタイプとRTCPパケットタイプの間の直接的な競合を排除します。2番目の制約は、マーカービットセットとRTCPパケットを使用したRTPデータパケットとの競合を排除します。
The following conflicts between RTP and RTCP packet types are known:
RTPとRTCPのパケットタイプの間の以下の競合が知られています。
o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and NACK packets defined in the original "RTP Payload Format for H.261 Video Streams" [3] (which was obsoleted by [17]).
o RTPペイロードタイプ64-65（廃止）RTCP FIRおよびNACKパケットとの競合は、H.261ビデオストリームのRTPペイロード形式」[3]（[17]によって廃止された）で定義されています。
o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE, and APP packets defined in the RTP specification [1].
o RTPペイロードタイプ72-76 RTCS仕様[1]で定義されているRTCP SR、RR、SDES、BYE、およびAPPパケットとの競合。
o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB packets defined in the RTP/AVPF profile [4].
o RTPペイロードタイプ77-78 RTP/AVPFプロファイルで定義されたRTCP RTPFBおよびPSFBパケットとの競合[4]。
o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] packets.
o RTPペイロードタイプ79 RTCP拡張レポート（XR）[5]パケットとの競合。
o RTP payload type 80 conflicts with Receiver Summary Information (RSI) packets defined in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6].
o RTPペイロードタイプ80レシーバーサマリー情報（RSI）パケットと競合する「ユニキャストフィードバックを使用した単一ソースマルチキャストセッションのRTCP拡張機能」[6]で定義されています。
New RTCP packet types may be registered in the future and will further reduce the RTP payload types that are available when multiplexing RTP and RTCP onto a single port. To allow this multiplexing, future RTCP packet type assignments SHOULD be made after the current assignments in the range 209-223, then in the range 194-199, so that only the RTP payload types in the range 64-95 are blocked. RTCP packet types in the ranges 1-191 and 224-254 SHOULD only be used when other values have been exhausted.
新しいRTCPパケットタイプは将来登録される可能性があり、RTPとRTCPを単一のポートに多重化するときに使用できるRTPペイロードタイプをさらに削減します。この多重化を可能にするために、将来のRTCPパケットタイプの割り当ては、209-223の範囲の現在の割り当ての後、194〜199の範囲で行う必要があります。そのため、64〜95の範囲のRTPペイロードタイプのみがブロックされます。範囲のRTCPパケットタイプ1-191および224-254は、他の値が使い果たされた場合にのみ使用する必要があります。
Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first.
これらの制約を考えると、RTP/AVPプロファイル[7]のガイドラインに従って、RTPペイロードタイプの値を選択することをお勧めします。具体的には、可能な限り96〜127の範囲で動的なRTPペイロードタイプを選択する必要があります。64未満の値は、それが不十分な場合に使用できます。その場合、[7]によって静的に割り当てられないペイロードタイプ番号を最初に使用することをお勧めします。
Note: Since Section 6.1 of [1] specifies that all RTCP packets MUST be sent as compound packets beginning with a Sender Report (SR) or a Receiver Report (RR) packet, one might wonder why RTP payload types other than 72 and 73 are prohibited when multiplexing RTP and RTCP. This is done to support [18], which allows the use of non-compound RTCP packets in some circumstances.
注：[1]のセクション6.1は、すべてのRTCPパケットを送信者レポート（SR）またはレシーバーレポート（RR）パケットから始まる複合パケットとして送信する必要があることを指定しているため、なぜ72および73以外のRTPペイロードタイプがあるのか疑問に思うかもしれません。RTPとRTCPを多重化する場合、禁止されています。これは[18]をサポートするために行われます。これにより、状況によっては、コンパウンド以外のRTCPパケットを使用できます。
The procedures for multiplexing RTP and RTCP on a single port depend on whether the session is a unicast session or a multicast session. For multicast sessions, the procedures also depend on whether Any Source Multicast (ASM) or Source-Specific Multicast (SSM) is to be used.
単一のポートでRTPとRTCPを多重化する手順は、セッションがユニキャストセッションかマルチキャストセッションかによって異なります。マルチキャストセッションの場合、手順は、ソースマルチキャスト（ASM）またはソース固有のマルチキャスト（SSM）を使用するかどうかにも依存します。
It is acceptable to multiplex RTP and RTCP packets on a single UDP port to ease NAT traversal for unicast sessions, provided the RTP payload types used in the session are chosen according to the rules in Section 4, and provided that multiplexing is signalled in advance. The following sections describe how such multiplexed sessions can be signalled using the Session Initiation Protocol (SIP) with the offer/ answer model.
セッションで使用されているRTPペイロードタイプがセクション4のルールに従って選択され、マルチプレックスが事前に合図されている場合、ユニキャストセッションのNATトラバーサルを容易にするために、単一のUDPポートでMultiplex RTPおよびRTCPパケットを使用することは許容できます。次のセクションでは、このような多重化されたセッションを、オファー/回答モデルを使用してセッション開始プロトコル（SIP）を使用してどのように信号を送信できるかについて説明します。
When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=rtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example:
セッション説明プロトコル（SDP）[8]がオファー/回答モデル[9]に続くRTPセッションをネゴシエーションするために使用される場合、「a = rtcp-mux」属性（セクション8を参照）は、RTPとRTCPをマルチプレックスしたいという要望を示しています。単一のポート。最初のSDPオファーには、この属性をメディアレベルに含める必要があります。これは、単一のポートでRTPとRTCPの多重化を要求する必要があります。例えば：
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
This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
このオファーは、ILBCコーディングを備えたRTP/AVPプロファイルを使用したユニキャスト音声オーバーIPセッションを示します。回答者は、IPv6アドレス2001：DB8 :: 211：24FF：FEA3：7A2EでRTPとRTCPの両方をポート49170に送信するように要求されます。
If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=rtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4.
回答者がRTPとRTCPを単一のポートにマルチプレックスしたい場合は、Answerにメディアレベルの「A = RTCP-Mux」属性を含める必要があります。回答で使用されるRTPペイロードタイプは、セクション4のルールに準拠する必要があります。
If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute.
答えに「a = rtcp-mux」属性が含まれていない場合、オファーは単一のポートにRTPとRTCPパケットをマルチプレックスしてはなりません。代わりに、通常のポート選択ルールに従って割り当てられたポートでRTCPを送信および受信する必要があります（「A = RTCP：」属性[10]も含まれている場合、ポートペアまたは信号ポートのいずれか）。これは、「a = rtcp-mux」属性を理解していないピアと話すときに発生します。
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth.
SDPが宣言的な方法で使用される場合、「a = rtcp-mux」属性の存在は、送信者が同じポートでRTPとRTCPをマルチプレックスすることを信号します。RTPポートでRTCPパケットを受信するために受信機を準備する必要があり、RTCP帯域幅を含むリソース予約を行う必要があります。
When using SIP with a forking proxy, it is possible that an INVITE request may result in multiple 200 (OK) responses. If RTP and RTCP multiplexing is offered in that INVITE, it is important to be aware that some answerers may support multiplexed RTP and RTCP, some not. This will require the offerer to listen for RTCP on both the RTP port and the usual RTCP port, and to send RTCP on both ports, unless branches of the call that support multiplexing are re-negotiated to use separate RTP and RTCP ports.
フォーキングプロキシでSIPを使用する場合、招待リクエストが複数の200（OK）応答をもたらす可能性があります。RTPとRTCPの多重化がその招待状で提供されている場合、一部の回答者が多重化されたRTPとRTCPをサポートする可能性があることに注意することが重要です。これにより、オファーは、RTPポートと通常のRTCPポートの両方でRTCPをリッスンし、サポートマルチプレックスの分岐が個別のRTPポートとRTCPポートを使用するように再交渉されない限り、両方のポートでRTCPを送信する必要があります。
It is common to use the Interactive Connectivity Establishment (ICE) [19] methodology to establish RTP sessions in the presence of Network Address Translation (NAT) devices or other middleboxes. If RTP and RTCP are sent on separate ports, the RTP media stream comprises two components in ICE (one for RTP and one for RTCP), with connectivity checks being performed for each component. If RTP and RTCP are to be multiplexed on the same port some of these connectivity checks can be avoided, reducing the overhead of ICE.
Interactive Connectivity Indecivity Indetivity（ICE）[19]方法論を使用して、ネットワークアドレス変換（NAT）デバイスまたはその他のミドルボックスの存在下でRTPセッションを確立することが一般的です。RTPとRTCPが別々のポートで送信される場合、RTPメディアストリームは、各コンポーネントに対して接続チェックが実行され、ICEの2つのコンポーネント（RTP用とRTCP用）で構成されます。RTPとRTCPを同じポートで多重化する場合、これらの接続チェックの一部を回避して、氷のオーバーヘッドを減らします。
If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired.
ICEと多重化されたRTPとRTCPの両方を使用することが望ましい場合、初期オファーには「A = RTCP-MUX」属性が含まれている必要があります。RTPとRTCPの多重化が望まれ、「A =候補：」の両方のRTPの行が含まれている必要があります。RTCPと「A = RTCP：」ラインは、回答者がRTPおよびRTCPマルチプレックスをサポートしていない場合のRTCPのフォールバックポートを示しています。これは、RTPとRTCPの多重化が必要な各メディアに対して行う必要があります。
If the answerer wishes to multiplex RTP and RTCP on a single port, it MUST generate an answer containing an "a=rtcp-mux" attribute and a single "a=candidate:" line corresponding to the RTP port (i.e., there is no candidate for RTCP) for each media where it is desired to use RTP and RTCP multiplexing. The answerer then performs connectivity checks for that media as if the offer had contained only a single candidate for RTP. If the answerer does not want to multiplex RTP and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" attribute in its answer and MUST perform connectivity checks for all offered candidates in the usual manner.
回答者が単一のポートでRTPとRTCPをマルチプレックスしたい場合、「a = rtcp-mux」属性と単一の "a =候補：" rtpポートに対応する回線を含む回答を生成する必要があります（つまり、RTCPの候補）RTPおよびRTCPマルチプレックスを使用することが望まれる各メディアについて。回答者は、オファーにRTPの候補者が1つしか含まれていないかのように、そのメディアの接続チェックを実行します。回答者が単一のポートでRTPとRTCPをマルチプレックスしたくない場合、回答に「A = RTCP-Mux」属性を含めてはならず、通常の方法で提供されるすべての候補者の接続チェックを実行する必要があります。
On receipt of the answer, the offerer looks for the presence of the "a=rtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=rtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=rtcp:" attribute).
回答を受け取ると、オファーは、多重化が提供された各メディアの「a = rtcp-mux」行の存在を探します。これが存在する場合、接続性チェックは、1つの候補（RTP用）のみが提供され、セッションが確立されると多重化が使用されるかのように進みます。「a = rtcp-mux」行が存在しない場合、セッションはRTP候補とRTCP候補の両方を使用して接続チェックで進み、最終的には別々のポートでRTPとRTCPで確立されます（「A = RTCPで知られるように」：" 属性）。
Multiplexing RTP and RTCP packets onto a single port may negatively impact header compression schemes, for example, Compressed RTP (CRTP) [20] and RObust Header Compression (ROHC) [21] [22]. Header compression exploits patterns of change in the RTP headers of consecutive packets to send an indication that the packet changed in the expected way, rather than sending the complete header each time. This can lead to significant bandwidth savings if flows have uniform behaviour.
RTPおよびRTCPパケットを単一のポートに多重化すると、ヘッダー圧縮スキームがマイナスに影響する可能性があります。たとえば、圧縮RTP（CRTP）[20]および堅牢なヘッダー圧縮（ROHC）[21] [22]。ヘッダー圧縮は、毎回完全なヘッダーを送信するのではなく、パケットが予想された方法で変化したことを示すために、連続パケットのRTPヘッダーの変化のパターンを悪用します。これは、フローが均一な挙動を持つ場合、大幅な帯域幅の節約につながる可能性があります。
The presence of RTCP packets multiplexed with RTP data packets can disrupt the patterns of change between headers and has the potential to significantly reduce header compression efficiency. The extent of this disruption depends on the header compression algorithm used and on the way flows are classified. A well-designed classifier should be able to separate RTP and RTCP multiplexed on the same port into different compression contexts, using the payload type field, such that the effect on the compression ratio is small. A classifier that assigns compression contexts based only on the IP addresses and UDP ports will not perform well. It is expected that implementations of header compression will need to be updated to efficiently support RTP and RTCP multiplexed on the same port.
RTPデータパケットで多重化されたRTCPパケットの存在は、ヘッダー間の変化のパターンを破壊する可能性があり、ヘッダー圧縮効率を大幅に低下させる可能性があります。この破壊の程度は、使用されるヘッダー圧縮アルゴリズムと流れの方法に依存します。適切に設計された分類器は、同じポートで多重化されたRTPとRTCPを異なる圧縮コンテキストに分離し、ペイロードタイプフィールドを使用して、圧縮率への影響が小さくなるようにすることができるはずです。IPアドレスとUDPポートのみに基づいて圧縮コンテキストを割り当てる分類器は、うまく機能しません。ヘッダー圧縮の実装を更新して、同じポートでRTPとRTCPが多重化されたRTCPを効率的にサポートする必要があると予想されます。
This effect of multiplexing RTP and RTCP on header compression may be especially significant in those environments, such as some wireless telephony systems, that rely on the efficiency of header compression to match the media to a limited-capacity channel. The implications of multiplexing RTP and RTCP should be carefully considered before use in such environments.
ヘッダー圧縮に対するRTPとRTCPの多重化のこの効果は、メディアを限られた容量チャネルに一致させるヘッダー圧縮の効率に依存する、一部のワイヤレステレフォニーシステムなどの環境で特に重要な場合があります。多重化RTPとRTCPの意味は、そのような環境で使用する前に慎重に考慮する必要があります。
The problem of NAT traversal is less severe for Any Source Multicast (ASM) RTP sessions than for unicast RTP sessions, and the benefit of using separate ports for RTP and RTCP is greater due to the ability to support third-party RTCP-only monitors. Accordingly, RTP and RTCP packets SHOULD NOT be multiplexed onto a single port when using ASM RTP sessions and SHOULD instead use separate ports and multicast groups.
NATトラバーサルの問題は、ユニキャストRTPセッションよりもソースマルチキャスト（ASM）RTPセッションではあまり深刻ではなく、RTPとRTCPに個別のポートを使用する利点は、サードパーティのRTCPのみのモニターをサポートする能力により大きくなります。したがって、ASM RTPセッションを使用する場合、RTPおよびRTCPパケットを単一のポートに多重化しないでください。代わりに、個別のポートとマルチキャストグループを使用する必要があります。
RTP sessions running over Source-Specific Multicast (SSM) send RTCP packets from the source to receivers via the multicast channel, but use a separate unicast feedback mechanism [6] to send RTCP from the receivers back to the source, with the source either reflecting the RTCP packets to the group or sending aggregate summary reports.
ソース固有のマルチキャスト（SSM）を介して実行されているRTPセッションは、マルチキャストチャネルを介してRTCPパケットをソースから受信機に送信しますが、別のユニキャストフィードバックメカニズム[6]を使用してRTCPをレシーバーからソースに送信し、ソースを反映してソースを反映して送信します。RTCPパケットはグループにパケットをかけるか、集約概要レポートを送信します。
Following the terminology of [6], we identify three RTP/RTCP flows in an SSM session:
[6]の用語に続いて、SSMセッションで3つのRTP/RTCPフローを特定します。
1. RTP and RTCP flows between media sender and distribution source. In many scenarios, the media sender and distribution source are co-located, so multiplexing is not a concern. If the media sender and distribution source are connected by a unicast connection, the rules in Section 5.1 of this memo apply to that connection. If the media sender and distribution source are connected by an Any Source Multicast connection, the rules in Section 5.2 apply to that connection. If the media sender and distribution source are connected by a Source-Specific Multicast connection, the RTP and RTCP packets MAY be multiplexed on a single port, provided this is signalled (using "a=rtcp-mux" if using SDP).
1. RTPとRTCPは、メディア送信者と配布源の間に流れます。多くのシナリオでは、メディアの送信者と配布ソースが共同で配置されているため、多重化は懸念事項ではありません。メディア送信者と配布ソースがユニキャスト接続によって接続されている場合、このメモのセクション5.1のルールがその接続に適用されます。メディアの送信者と配布ソースが任意のソースマルチキャスト接続によって接続されている場合、セクション5.2のルールがその接続に適用されます。メディアの送信者と配布ソースがソース固有のマルチキャスト接続によって接続されている場合、これがシグナル（SDPを使用する場合は「a = rtcp-mux」を使用）を使用すると、RTPおよびRTCPパケットが単一のポートで多重化される場合があります。
2. RTP and RTCP sent from the distribution source to the receivers. The distribution source MAY multiplex RTP and RTCP onto a single port to ease NAT traversal issues on the forward SSM path, although doing so may hinder third-party monitoring devices if the session uses the simple feedback model. When using SDP, the multiplexing SHOULD be signalled using the "a=rtcp-mux" attribute.
2. RTPとRTCPは、配布源から受信機に送信されました。分布ソースは、RTPとRTCPを単一のポートにマルチプレックスして、フォワードSSMパスのNATトラバーサルの問題を容易にする場合がありますが、セッションが単純なフィードバックモデルを使用する場合、サードパーティの監視デバイスを妨げる可能性があります。SDPを使用する場合、「a = rtcp-mux」属性を使用してマルチプレックスを信号する必要があります。
3. RTCP sent from receivers to distribution source. This is an RTCP-only path, so multiplexing is not a concern.
3. RTCPは、受信機から配布源に送信されます。これはRTCPのみのパスであるため、多重化は懸念事項ではありません。
Multiplexing RTP and RTCP packets on a single port in an SSM session has the potential for interactions with header compression described in Section 5.1.4.
SSMセッションの単一ポートでのRTPおよびRTCPパケットの多重化は、セクション5.1.4で説明されているヘッダー圧縮と相互作用する可能性があります。
Multiplexing RTP and RTCP has implications on the use of the Quality of Service (QoS) mechanism that handles flow that are determined by a three or five tuple (protocol, port, and address for source and/or destination). In these cases, the RTCP flow will be merged with the RTP flow when multiplexing them together. Thus, the RTCP bandwidth requirement needs to be considered when doing QoS reservations for the combined RTP and RTCP flow. However, from an RTCP perspective it is beneficial to receive the same treatment of RTCP packets as for RTP as it provides more accurate statistics for the measurements performed by RTCP.
多重化RTPとRTCPは、3つまたは5つのタプル（ソースおよび/または宛先のアドレス）によって決定されるフローを処理するサービス品質（QOS）メカニズムの使用に影響を及ぼします。これらの場合、RTCPフローは、それらをマルチプレックスするときにRTPフローとマージされます。したがって、RTCP帯域幅の要件を、RTPとRTCPの組み合わせのフローのQoS予約を行うときに考慮する必要があります。ただし、RTCPの観点からは、RTPが実行した測定に対してより正確な統計を提供するため、RTPパケットの同じ処理をRTPパケットの処理を受けることが有益です。
The bandwidth required for a multiplexed stream comprises the session bandwidth of the RTP stream plus the bandwidth used by RTCP. In the usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" (or "b=TIAS:" [11]) line, and the RTCP traffic is limited to 5% of this value. Any QoS reservation SHOULD therefore be made for 105% of the "b=AS:" value. If a non-standard RTCP bandwidth fraction is used, signalled by the SDP "b=RR:" and/or "b=RS:" lines [12], then any QoS reservation SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS and RR values from the SDP answer.
多重化されたストリームに必要な帯域幅は、RTPストリームのセッション帯域幅とRTCPが使用する帯域幅を含むことを含みます。通常の場合、RTPセッションの帯域幅は、SDP "b = as："（または "b = tias：" [11]）ラインでシグナル付けされ、RTCPトラフィックはこの値の5％に制限されています。したがって、QoS予約は、「b = as：」値の105％に対して行う必要があります。SDP "B = rr："および/または "b = rs：" lines [12]で標準以外のRTCP帯域幅画分を使用している場合、QOS予約は帯域幅を等しい帯域幅に対して（rs rrに等しい帯域幅に対して作成する必要があります。）、SDP回答からRSおよびRR値を取得します。
The usage of multiplexing RTP and RTCP is not believed to introduce any new security considerations. Known major issues are the integrity and authentication of the signalling used to set up the multiplexing as well as the integrity, authentication, and confidentiality of the actual RTP and RTCP traffic. The security considerations in the RTP specification [1] and any applicable RTP profile (e.g., [7]) and payload format(s) apply.
多重化RTPとRTCPの使用は、新しいセキュリティ上の考慮事項を導入するとは考えられていません。既知の主要な問題は、実際のRTPおよびRTCPトラフィックのマルチプレックス、認証、および機密性だけでなく、マルチプレックスを設定するために使用されるシグナルの整合性と認証です。RTP仕様[1]および該当するRTPプロファイル（[7]など）およびペイロード形式のセキュリティに関する考慮事項が適用されます。
If the Secure Real-time Transport Protocol (SRTP) [13] is to be used in conjunction with multiplexed RTP and RTCP, then multiplexing MUST be done below the SRTP layer. The sender generates SRTP and SRTCP packets in the usual manner, based on their separate cryptographic contexts, and multiplexes them onto a single port immediately before transmission. At the receiver, the cryptographic context is derived from the synchronization source (SSRC), destination network address, and destination transport port number in the usual manner, augmented using the RTP payload type and RTCP packet type to demultiplex SRTP and SRTCP according to the rules in Section 4 of this memo. After the SRTP and SRTCP packets have been demultiplexed, cryptographic processing happens in the usual manner.
安全なリアルタイムトランスポートプロトコル（SRTP）[13]を多重化されたRTPおよびRTCPと組み合わせて使用する場合、多重化をSRTPレイヤーの下に実行する必要があります。送信者は、個別の暗号化コンテキストに基づいて、通常の方法でSRTPおよびSRTCPパケットを生成し、伝送の直前に単一のポートにマルチプレックスします。受信機では、暗号化コンテキストは、通常の方法で同期ソース（SSRC）、宛先ネットワークアドレス、および宛先輸送ポート番号から導き出され、RTPペイロードタイプとRTCPパケットタイプを使用して、ルールに従ってDemultiPlex SRTPおよびSRTCPに拡張されます。このメモのセクション4で。SRTPおよびSRTCPパケットが非複数のパケットが再誘導された後、暗号化処理が通常の方法で行われます。
Following the guidelines in [8], the IANA has registered one new SDP attribute:
[8]のガイドラインに従って、IANAは1つの新しいSDP属性を登録しています。
o Contact name/email: authors of RFC 5761
o 連絡先名/電子メール：RFC 5761の著者
o Attribute name: rtcp-mux
o 属性名：rtcp-mux
o Long-form attribute name: RTP and RTCP multiplexed on one port
o ロングフォーム属性名：1つのポートで多重化されたRTPとRTCP
o Type of attribute: media level
o 属性のタイプ：メディアレベル
o Subject to charset: no
o charsetの対象：いいえ
This attribute is used to signal that RTP and RTCP traffic should be multiplexed on a single port (see Section 5 of this memo). It is a property attribute, which does not take a value.
この属性は、RTPおよびRTCPトラフィックを単一のポートで多重化する必要があることを示すために使用されます（このメモのセクション5を参照）。これはプロパティ属性であり、値を取得しません。
The rules for assignment of RTP RTCP Control Packet Types in the RTP Parameters registry are updated as follows. When assigning RTP RTCP Control Packet types, IANA is requested to assign unused values from the range 200-223 where possible. If that range is fully occupied, values from the range 194-199 may be used, and then values from the ranges 1-191 and 224-254. This improves header validity checking of RTCP packets compared to RTP packets or other unrelated packets. The values 0 and 255 are avoided for improved validity checking relative to random packets since all-zeros and all-ones are common values.
RTPパラメーターレジストリにおけるRTP RTCP制御パケットタイプの割り当てのルールは、次のように更新されます。RTP RTCPコントロールパケットタイプを割り当てるとき、IANAは、可能であれば範囲200-223から未使用の値を割り当てるように要求されます。その範囲が完全に占有されている場合、194〜199の範囲からの値を使用し、次に範囲1〜191および224-254の値を使用できます。これにより、RTPパケットまたはその他の無関係なパケットと比較して、RTCPパケットのヘッダー有効性チェックが改善されます。すべてのゼロとオールオンが一般的な値であるため、ランダムパケットに比べて改善された有効性チェックの値0と255は回避されます。
We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, Dave Singer, Kevin Johns, and David Black for their comments on this memo. This work was supported in part by the UK Engineering and Physical Sciences Research Council.
スティーブ・キャスナー、ジョーグ・オット、クリスター・ホルムバーグ、グンナー・ヘルストロム、ランデル・ジェサップ、ハドリエル・カプラン、ハディー・デ・デシネニ、ステファン・ウェンガー、ジョナサン・ローゼンバーグ、ロニ均一、インゲマー・ヨハンソン、デイブ・シンガー、ケビン・ジョンズ、そしてデイビッド・ブラックのコメントに感謝します。このメモ。この作業は、英国の工学および物理科学研究評議会によって部分的にサポートされていました。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[3] Turletti、T。、「H.261ビデオストリームのRTPペイロード形式」、RFC 2032、1996年10月。
[4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[4] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、2006年7月。
[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[5] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[6] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[6] Ott、J.、Chesterfield、J。、およびE. Schooler、「RTPコントロールプロトコル（RTCP）ユニキャストフィードバックを備えたシングルソースマルチキャストセッションの拡張」、RFC 5760、2010年2月。
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[10] Huitema、C。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[11] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[11] Westerlund、M。、「セッション説明プロトコル（SDP）の輸送独立帯域幅修飾子」、RFC 3890、2004年9月。
[12] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[12] Casner、S。、「RTPコントロールプロトコル（RTCP）帯域幅のセッション説明プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[14] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM 1990, September 1990.
[15] Clark、D。およびD. Tennenhouse、「新世代のプロトコルに対する建築上の考慮事項」、ACM Sigcomm 1990の議事録、1990年9月。
[16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM SIGCOMM Computer Communication Review, Volume 22, Number 3, July 1992.
[16] Casner、S。and S. Deering、「First IETF Internet AudioCast」、ACM Sigcomm Computer Communication Review、Volume 22、Number 3、1992年7月。
[17] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[17] イベント、R。、「H.261ビデオストリームのRTPペイロード形式」、RFC 4587、2006年8月。
[18] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[18] Johansson、I。およびM. Westerlund、「低サイズのリアルタイム輸送制御プロトコル（RTCP）のサポート：機会と結果」、RFC 5506、2009年4月。
[19] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[19] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：Network Address Translator（NAT）Traversal for Offer/Answer Protocolsのプロトコル」、RFC 5245、2010年4月。
[20] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[20] Casner、S。およびV. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[21] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[21] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-E。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Z。、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "Robust Header圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[22] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[22] Sandlund、K.、Pelletier、G。、およびL-e。Jonsson、「The Robust Header Compression（ROHC）フレームワーク」、RFC 5795、2010年3月。
Authors' Addresses
著者のアドレス
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
コリンパーキンスグラスゴー大学コンピューティング科学科
EMail: csp@csperkins.org
Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden
マグナスウェスターランドエリクソンファロガタン6ストックホルムSE-164 80スウェーデン
EMail: magnus.westerlund@ericsson.com