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
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）パケットのときに発生する問題について説明します。このような多重化であり、適切ではない、それはセッション記述プロトコル（SDP）が多重セッションを通知するために使用することができる方法を説明したときに説明するためにRFC 3550及びRFC 3551を更新します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]).
データ転送プロトコルと関連する制御プロトコル（RTCP）：リアルタイムトランスポートプロトコル（RTP）[1]は二つの成分を含みます。歴史的に、RTPとRTCPは、別々のUDPポート上で実行されています。ネットワークの使用の増加と、これは高価であることができる複数のNATバインディングを維持するため、問題となっているポート変換（NAPT）[14]、アドレス。複数のポートは、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節では、多重化パケットを区別するためで専門用語を議論します。私たちは、その後、RTPとRTCPは、多重化されなければならないとき、どのように指定し、どのように我々は、第8章のセクション7におけるセキュリティの考慮事項とIANAの考慮事項と結論サービスと帯域幅の問題の質は、第6節で議論されている5節では、多重化されたセッションを通知します。
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]逆多重化は、単一の場所で発生した場合、実装がより効率的であろう（例えば、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ポートと逆多重化を使用して、別々のUDPポートを使用して、RTPとRTCPを逆多重化する代替手段を提供することが望ましいです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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およびRTCPパケットは、単一のポートに多重化されている場合、RTCPパケットタイプフィールドは、RTPマーカ（M）ビットの組み合わせとRTPペイロードタイプ（PT）のようなパケット内の同じ位置を占めます。 2つの制限が観察される場合、このフィールドは、RTP及びRTCPパケットを区別するために使用することができる：1）を用いるRTPペイロードタイプ値が使用されるRTCPパケットタイプは区別されます。 2）それぞれについて
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ペイロードタイプ（PT）、PT + 128が使用されるRTCPパケットタイプは区別されます。第1の制約は、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]).
元の「H.261ビデオストリームのためのRTPペイロードフォーマット」で定義されている（廃止）RTCP FIR及びNACKパケットでO RTPペイロードタイプ64-65競合[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].
RTP仕様で定義されたRTCP SR、RR、SDES、BYE、およびAPPパケットとO RTPペイロードタイプ72-76競合[1]。
o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB packets defined in the RTP/AVPF profile [4].
RTP / AVPFプロファイルに定義されたRTCP RTPFB及びPSFBパケットでO RTPペイロードタイプ77-78競合[4]。
o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] packets.
RTCP拡張レポート（XR）とO RTPペイロードタイプ79競合[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ペイロードタイプ「ユニキャストフィードバックを有する単一ソースマルチキャストセッションのためにRTCP拡張機能」で定義されている受信機の概要情報（RSI）パケット80の競合[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ペイロードタイプを削減します。範囲64から95までの唯一のRTPペイロードタイプがブロックされるように、この多重化を可能にするために、将来のRTCPパケットタイプの割り当ては、その後範囲194-199において、範囲209から223で現在の割り当ての後に行われるべきです。他の値がなくなってきたときの範囲1から191と224から254でRTCPパケットタイプにのみ使用してください。
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]の範囲64から95でペイロードタイプ値を使用してはいけないことに追加の制限付きRTPペイロードタイプの値の選択のため。具体的には、ダイナミックRTPペイロードタイプは、範囲96から127まで可能に選択されるべきです。それが不足している場合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.
注意：の6.1節は、[1]すべてのRTCPパケットを送信レポート（SR）または受信レポート（RR）パケットで始まる化合物パケットとして送らなければならないことを指定しているので、1は72と73以外のRTPペイロードタイプがある理由を不思議に思うかもしれません禁止されたときに多重化RTPとRTCP。これは、いくつかの状況において、非複合RTCPパケットの使用を可能にする[18]、サポートするために行われます。
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.
それはユニキャストセッションのNATトラバーサルを容易にするため、単一のUDPポートでRTPとRTCPパケットを多重化することが許容され、第4の規則に従って選択されたセッションで使用されるRTPペイロードタイプを提供し、その多重化が事前に通知されました。次のセクションでは、このような多重セッションがオファー/アンサーモデルとのセッション開始プロトコル（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]オファー/アンサーモデル以下のRTPセッションをネゴシエートするために使用される場合、[9]、「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セッションを示しています。 DB8 :: 211：24ff：fea3：7a2e回答は、IPv6アドレス2001のポート49170にRTPとRTCPの両方を送信するために要求されます。
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を多重化することを希望する場合は、メディアレベルの回答では、「= 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パケットを多重化してはなりません。その代わりに、それは通常のポート選択ルール（「A = RTCP：」属性[10]にも含まれているポートのペア、またはシグナリングポートのいずれかの場合）に応じて割り当てられたポート上RTCPを送信し、受信しなければなりません。 「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を使用する場合、INVITE要求は、複数の200（OK）応答をもたらす可能性があります。 RTPとRTCPの多重化がそのINVITEで提供されている場合、いくつかの回答者は、多重化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.
ネットワークアドレス変換（NAT）デバイスまたは他のミドルボックスの存在下で、RTPセッションを確立するためにインタラクティブ接続確立（ICE）[19]の方法論を使用するのが一般的です。 RTPとRTCPは、別のポートで送信される場合、RTPメディアストリームは、接続性チェックは、各コンポーネントに対して実行された状態で、ICE内の2つの成分（RTPとRTCPのための1つに対して1つ）を含みます。 RTPとRTCPは、同じポート上で多重化されるようにしている場合は、これらの接続性チェックの一部は、ICEのオーバーヘッドを削減、回避することができます。
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の両方を使用することが望まれる場合は、最初のオファーは、RTPとRTCPの多重化を示すために、「A = RTCP-MUX」属性を含まなければならないことが望まれると、「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とRTCPを多重化することを希望する場合は、「A = RTCP-MUX」属性とシングル「A =候補：」含む答を生成しなければならないラインがRTPポートに対応する（つまり、何もありません使用することが望まれる各メディアのRTCPの候補）
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の多重化。オファーはRTPのための単一の候補が含まれていたかのように回答者は、そのメディアの接続性チェックを行います。回答は単一のポートで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」ラインの存在を探します。これが存在する場合（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の多重化をサポートするように更新する必要があることが予想されます。
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セッションは、ソースのいずれかの反射で、[6]のソースに戻すレシーバからRTCPを送信するマルチキャストチャネルを介して受信機にソースからRTCPパケットを送信するが、別個のユニキャストフィードバック機構を使用しますRTCPパケットグループまたは集計サマリーレポートを送信します。
Following the terminology of [6], we identify three RTP/RTCP flows in an SSM session:
[6]の用語に続いて、我々は3 RTP / RTCPは、SSMセッションでフローを識別します：
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節の規則は、その接続に適用されます。メディア送付者と配信元がソース固有マルチキャスト接続によって接続されている場合、RTPおよびRTCPパケットは、これは（SDPを使用する場合、「A = RTCP-MUX」を使用して）シグナリングされる設けられ、単一ポート上で多重化されてもよいです。
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は、受信機に配信元から送られてきました。配信元は、セッションは、単純なフィードバックモデルを使用している場合はそうすることが、サードパーティ製の監視装置を妨げるかもしれないが、前方SSMパス上にNATトラバーサルの問題を緩和するために、単一のポートにRTPとRTCPを多重化することができます。 SDPを使用する場合、多重化「とは、A = RTCP-MUX」属性を使用してシグナリングされるべきです。
3. RTCP sent from receivers to distribution source. This is an RTCP-only path, so multiplexing is not a concern.
前記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の観点からRTCPによって実行される測定のために、より正確な統計情報を提供するようにRTP用としてRTCPパケットの同じ処置を受けることが有益です。
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％のためになされるべきです。非標準的なRTCP帯域幅画分が使用される場合、SDPによって「B = RR：」をシグナリングおよび/または「B = RS：」行[12]、その後、任意のQoS予約は、（AS + 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]）とペイロード形式（S）を適用します。
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）、宛先ネットワークアドレス、及び宛先のトランスポートポート番号から導出され、ルールに従ってSRTPとSRTCPを分離するためにRTPペイロードタイプ及びRTCPパケットタイプを使用して増補このメモのセクション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
RTCP-MUX：O属性名
o Long-form attribute name: RTP and RTCP multiplexed on one port
Oロング・フォームの属性名：RTPとRTCP 1つのポート上で多重化
o Type of attribute: media level
属性のO型：メディアレベル
o Subject to charset: no
文字セットにO件名：なし
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.
この属性は、（このメモのセクション5を参照）、RTPおよびRTCPトラフィックが単一のポートに多重化されなければならないことを通知するために使用されます。それは値をとらないproperty属性、です。
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.
私たちは、上の彼らのコメントのためにスティーブCasner、イェルク・オット、クリステルHolmbergの、グンナー・ヘルストローム、ランデルジェサップ、Hadrielカプラン、Harikishan Desineni、ステファン・ベンゲル監督、ジョナサン・ローゼンバーグ、ロニでも、インゲマル・ヨハンソン、デイブ・シンガー、ケビン・ジョーンズ、デビッド・ブラック感謝したいですこのメモ。この作品は、英国工学・物理科学研究評議会によって部分的にサポートされていました。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、「リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル-Basedフィードバック（RTP / AVPF） 」、RFC 4585、2006年7月。
[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[5]フリードマン、T.、カセレス、R.、およびA.クラーク、 "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]オット、J.、チェスターフィールド、J.、およびE.学生、 "ユニキャストフィードバック付き単一ソースマルチキャストセッションのために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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[10]のHuitema、C.、RFC 3605、2003年10月 "セッション記述プロトコル（SDP）でのリアルタイム制御プロトコル（RTCP）属性"。
[11] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[11]ウェスター、M.、RFC 3890 "セッション記述プロトコル（SDP）のための交通独立した帯域幅修飾子"、2004年9月。
[12] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[12] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、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.、マグリュー、D.、Naslund、M.、カララ、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]クラーク、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.とS.デアリング、 "まずIETFインターネットオーディオキャスト"、ACM SIGCOMMコンピュータコミュニケーションレビュー、22巻、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]ヨハンソン、I.およびM.ウェスター、「縮小リアルタイムトランスポート制御プロトコル（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]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、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.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（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.、ペルティエ、G.、およびL-E。ヨンソン、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、RFC 5795、2010年3月。
Authors' Addresses
著者のアドレス
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
コンピューティング科学グラスゴーG12 8QQ英国のグラスゴー学部のコリンパーキンス大学
EMail: csp@csperkins.org
メールアドレス：csp@csperkins.org
Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden
マグヌスウェスターエリクソンFärögatan6ストックホルムSE-164 80スウェーデン
EMail: magnus.westerlund@ericsson.com
メールアドレス：magnus.westerlund@ericsson.com