[要約] RFC 5124は、RTCPベースのフィードバックに対する拡張セキュアRTPプロファイル（RTP/SAVPF）に関する規格です。その目的は、セキュアなリアルタイムトランスポート制御プロトコル（RTCP）フィードバックを提供することです。
Network Working Group J. Ott
Request for Comments: 5124 Helsinki University of Technology
Category: Standards Track E. Carrara
KTH
February 2008
Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）の拡張セキュアRTPプロファイル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback.
セキュアリアルタイム通信用のRTPプロファイル（SAVP）およびレシーバーから送信者にタイムリーなフィードバックを提供する別のプロファイル（AVPF）は、それぞれRFC 3711およびRFC 4585で定義されています。このメモは、両方のプロファイルの組み合わせを指定して、セキュアなRTP通信をフィードバックで有効にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Terminology ................................................4
2. SAVPF Rules .....................................................4
2.1. Packet Formats .............................................5
2.2. Extensions .................................................5
2.3. Implications from Combining AVPF and SAVP ..................6
3. SDP Definitions .................................................6
3.1. Profile Definition .........................................6
3.2. Attribute Definitions ......................................6
3.3. Profile Negotiation ........................................6
3.3.1. Offer/Answer-Based Negotiation of Session
Descriptions ........................................7
3.3.2. RTSP-Based Negotiation of Session Descriptions ......8
3.3.3. Announcing Session Descriptions .....................9
3.3.4. Describing Alternative Session Profiles .............9
3.4. Examples ..................................................10
4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities ............13
5. Security Considerations ........................................14
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
The Real-time Transport Protocol, the associated RTP Control Protocol (RTP/RTCP, RFC 3550) [1], and the profile for audiovisual communications with minimal control (RFC 3551) [2] define mechanisms for transmitting time-based media across an IP network. RTP provides means to preserve timing and detect packet losses, among other things, and RTP payload formats provide for proper framing of (continuous) media in a packet-based environment. RTCP enables receivers to provide feedback on reception quality and allows all members of an RTP session to learn about each other.
リアルタイムトランスポートプロトコル、関連するRTP制御プロトコル（RTP/RTCP、RFC 3550）[1]、および最小制御を伴う視聴覚通信のプロファイル（RFC 3551）[2]は、時間ベースのメディアを送信するためのメカニズムを定義します。IPネットワーク。RTPは、タイミングを保存し、パケット損失などを検出する手段を提供し、RTPペイロード形式は、パケットベースの環境での（連続）メディアの適切なフレーミングを提供します。RTCPを使用すると、受信者は受信品質に関するフィードバックを提供し、RTPセッションのすべてのメンバーがお互いについて学習できるようにします。
The RTP specification provides only rudimentary support for encrypting RTP and RTCP packets. Secure RTP (RFC 3711) [4] defines an RTP profile ("SAVP") for secure RTP media sessions, defining methods for proper RTP and RTCP packet encryption, integrity, and replay protection. The initial negotiation of SRTP and its security parameters needs to be done out-of-band, e.g., using the Session Description Protocol (SDP, RFC 4566) [6] together with extensions for conveying keying material (RFC 4567 [7], RFC 4568 [8]).
RTP仕様は、RTPおよびRTCPパケットを暗号化するための初歩的なサポートのみを提供します。Secure RTP（RFC 3711）[4]は、安全なRTPメディアセッションのRTPプロファイル（「SAVP」）を定義し、適切なRTPおよびRTCPパケット暗号化、整合性、およびリプレイ保護の方法を定義します。SRTPとそのセキュリティパラメーターの最初の交渉は、たとえば、セッション説明プロトコル（SDP、RFC 4566）[6]を使用して、キーイング材料を伝えるための拡張（RFC 4567 [7]、RFCを使用して、帯域外で行う必要があります。4568 [8]）。
The RTP specification also provides limited support for timely feedback from receivers to senders, typically by means of reception statistics reporting in somewhat regular intervals depending on the group size, the average RTCP packet size, and the available RTCP bandwidth. The extended RTP profile for RTCP-based feedback ("AVPF") (RFC 4585, [3]) allows session participants statistically to provide immediate feedback while maintaining the average RTCP data rate for all senders. As for SAVP, the use of AVPF and its parameters needs to be negotiated out-of-band by means of SDP (RFC 4566, [6]) and the extensions defined in RFC 4585 [3].
RTP仕様は、グループサイズ、平均RTCPパケットサイズ、利用可能なRTCP帯域幅に応じて、ある程度の通常の間隔でレポート統計をレポートするレシーバーから送信者へのタイムリーなフィードバックに対する限られたサポートも提供します。RTCPベースのフィードバック（ "AVPF"）（RFC 4585、[3]）の拡張RTPプロファイルにより、すべての送信者の平均RTCPデータレートを維持しながら、セッション参加者が統計的に即時フィードバックを提供できます。SAVPに関しては、AVPFの使用とそのパラメーターの使用は、SDP（RFC 4566、[6]）およびRFC 4585 [3]で定義されている拡張によって帯域外にネゴシエートする必要があります。
Both SRTP and AVPF are RTP profiles and need to be negotiated. This implies that either one or the other may be used, but both profiles cannot be negotiated for the same RTP session (using one SDP session level description). However, using secure communications and timely feedback together is desirable. Therefore, this document specifies a new RTP profile ("SAVPF") that combines the features of SAVP and AVPF.
SRTPとAVPFの両方はRTPプロファイルであり、交渉する必要があります。これは、どちらか一方が使用される可能性があることを意味しますが、同じRTPセッションで両方のプロファイルを交渉できないことを意味します（1つのSDPセッションレベルの説明を使用）。ただし、安全な通信とタイムリーなフィードバックを一緒に使用することが望ましいです。したがって、このドキュメントは、SAVPとAVPFの機能を組み合わせた新しいRTPプロファイル（「SAVPF」）を指定します。
As SAVP and AVPF are largely orthogonal, the combination of both is mostly straightforward. No sophisticated algorithms need to be specified in this document. Instead, reference is made to both existing profiles and only the implications of their combination and possible deviations from rules of the existing profiles are described as is the negotiation process.
SAVPとAVPFは主に直交するため、両方の組み合わせはほとんど簡単です。このドキュメントでは、洗練されたアルゴリズムを指定する必要はありません。代わりに、既存のプロファイルの両方に参照が行われ、それらの組み合わせの意味と既存のプロファイルのルールからの逸脱の可能性のみが、交渉プロセスと同様に説明されます。
The definitions of RFC 3550 [1], RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] apply.
RFC 3550 [1]、RFC 3551 [2]、RFC 4585 [3]、およびRFC 3711 [4]の定義が適用されます。
The following definitions are specifically used in this document:
次の定義は、このドキュメントで特別に使用されています。
RTP session: An association among a set of participants communicating with RTP as defined in RFC 3550 [1].
RTPセッション：RFC 3550 [1]で定義されているRTPと通信する一連の参加者間の関連。
(SDP) media description: This term refers to the specification given in a single m= line in an SDP message. An SDP media description may define only one RTP session.
（SDP）メディアの説明：この用語は、SDPメッセージの単一のm =行で指定された仕様を指します。SDPメディアの説明は、1つのRTPセッションのみを定義できます。
Media session: A media session refers to a collection of SDP media descriptions that are semantically grouped to represent alternatives of the same communications means. Out of such a group, one will be negotiated or chosen for a communication relationship and the corresponding RTP session will be instantiated. If no common session parameters suitable for the involved endpoints can be found, the media session will be rejected. In the simplest case, a media session is equivalent to an SDP media description and equivalent to an RTP session.
メディアセッション：メディアセッションとは、同じ通信平均の代替案を表すために意味的にグループ化されたSDPメディアの説明のコレクションを指します。そのようなグループのうち、1つはコミュニケーション関係のために交渉または選択され、対応するRTPセッションがインスタンス化されます。関係するエンドポイントに適した一般的なセッションパラメーターが見つからない場合、メディアセッションは拒否されます。最も簡単な場合、メディアセッションはSDPメディアの説明に相当し、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 [5].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [5]に記載されているように解釈される。
SAVP is defined as an intermediate layer between RTP (following the regular RTP profile AVP) and the transport layer (usually UDP). This yields a two-layer hierarchy within the Real-time Transport Protocol. In SAVPF, the upper (AVP) layer is replaced by the extended RTP profile for feedback (AVPF).
SAVPは、RTP（通常のRTPプロファイルAVPに続く）と輸送層（通常はUDP）の間の中間層として定義されます。これにより、リアルタイムトランスポートプロトコル内で2層階層が得られます。SAVPFでは、アッパー（AVP）層がフィードバックのために拡張RTPプロファイルに置き換えられます（AVPF）。
AVPF modifies timing rules for transmitting RTCP packets and adds extra RTCP packet formats specific to feedback. These functions are independent of whether or not RTCP packets are subsequently encrypted and/or integrity protected. The functioning of the AVPF layer remains unchanged in SAVPF.
AVPFは、RTCPパケットを送信するためのタイミングルールを変更し、フィードバックに固有の追加のRTCPパケット形式を追加します。これらの関数は、RTCPパケットがその後暗号化されているか、整合性が保護されているかどうかに依存しません。AVPFレイヤーの機能は、SAVPFでは変更されていません。
The AVPF profile derives from RFC 3550 [1] the (optional) use of the encryption prefix for RTCP. The encryption prefix MUST NOT be used within the SAVPF profile (it is not used in SAVP, as it is only applicable to the encryption method specified in [1]).
AVPFプロファイルは、RFC 3550 [1] RTCPの暗号化プレフィックスの（オプションの）使用から派生しています。暗号化プレフィックスは、avpfプロファイル内で使用してはなりません（[1]で指定されている暗号化方法にのみ適用できるため、SAVPでは使用されません）。
The SAVP part uses extra fields added to the end of RTP and RTCP packets and executes cryptographic transforms on (some of) the RTP/RTCP packet contents. This behavior remains unchanged in SAVPF. The average RTCP packet size calculation done by the AVPF layer for timing purposes MUST take into account the fields added by the SAVP layer.
SAVPパーツは、RTPパケットとRTCPパケットの最後に追加された追加フィールドを使用し、RTP/RTCPパケットコンテンツで（一部の）暗号化変換を実行します。この動作は、SAVPFでは変わらないままです。タイミング目的でAVPFレイヤーによって行われた平均RTCPパケットサイズ計算は、SAVPレイヤーによって追加されたフィールドを考慮する必要があります。
The SRTP part becomes active only when the RTP or RTCP was scheduled by the "higher" AVPF layer or received from the transport protocol, irrespective of its timing and contents.
SRTP部品は、RTPまたはRTCPが「より高い」AVPFレイヤーによってスケジュールされた場合、またはそのタイミングや内容に関係なく輸送プロトコルから受信した場合にのみアクティブになります。
AVPF defines extra packet formats to provide feedback information. Those extra packet formats defined in RFC 4585 [3] (and further ones defined elsewhere for use with AVPF) MAY be used with SAVPF.
AVPFは、フィードバック情報を提供するための追加のパケット形式を定義します。RFC 4585 [3]で定義されているこれらの追加のパケット形式（およびAVPFで使用するために他の場所で定義されているもの）は、SAVPFで使用できます。
SAVP defines a modified packet format for SRTP and SRTCP packets that essentially consists of the RTP/RTCP packet formats plus some trailing protocol fields for security purposes. For SAVPF, all RTCP packets MUST be encapsulated as defined in Section 3.4 of RFC 3711 [4].
SAVPは、RTP/RTCPパケット形式とセキュリティ目的でいくつかの後続プロトコルフィールドで構成されるSRTPおよびSRTCPパケットの変更されたパケット形式を定義します。SAVPFの場合、すべてのRTCPパケットは、RFC 3711 [4]のセクション3.4で定義されているようにカプセル化する必要があります。
Extensions to AVPF RTCP feedback packets defined elsewhere MAY be used with the SAVPF profile provided that those extensions are in conformance with the extension rules of RFC 4585 [3].
他の場所で定義されているAVPF RTCPフィードバックパケットへの拡張は、それらの拡張機能がRFC 4585の拡張ルールに準拠している場合、SAVPFプロファイルで使用できます[3]。
Additional extensions (e.g., transforms) defined for SAVP following the rules of Section 6 of RFC 3711 [4] MAY also be used with the SAVPF profile. The overhead per RTCP packet depends on the extensions and transforms chosen. New extensions and transforms added in the future MAY introduce yet unknown further per-packet overhead.
RFC 3711 [4]のセクション6のルールに従ってSAVPに対して定義された追加の拡張機能（たとえば、変換）は、SAVPFプロファイルでも使用できます。RTCPパケットごとのオーバーヘッドは、選択された拡張機能と変換に依存します。将来追加された新しい拡張機能と変換は、パケットごとのオーバーヘッドをさらに未知のものに導入する可能性があります。
Finally, further extensions specifically to SAVPF MAY be defined elsewhere.
最後に、SAVPFに特に拡張が他の場所で定義される場合があります。
The AVPF profile aims at -- statistically -- allowing receivers to provide timely feedback to senders. The frequency at which receivers are, on average, allowed to send feedback information depends on the RTCP bandwidth, the group size, and the average size of an RTCP packet. SRTCP (see Section 3.4 of RFC 3711 [4]) adds extra fields (some of which are of configurable length) at the end of each RTCP packet that are probably at least some 10 to 20 bytes in size (14 bytes as default). Note that extensions and transforms defined in the future, as well as the configuration of each field length, MAY add greater overhead. By using SRTP, the average size of an RTCP packet will increase and thus reduce the frequency at which (timely) feedback can be provided. Application designers need to be aware of this, and take precautions so that the RTCP bandwidth shares are maintained. This MUST be done by adjusting the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP packets.
AVPFプロファイルは、統計的に - レシーバーが送信者にタイムリーなフィードバックを提供できるようにすることを目指しています。受信機が平均してフィードバック情報を送信できる頻度は、RTCP帯域幅、グループサイズ、およびRTCPパケットの平均サイズに依存します。SRTCP（RFC 3711 [4]のセクション3.4を参照）は、各RTCPパケットの最後に追加のフィールド（一部は構成可能な長さです）を追加します。将来定義されている拡張と変換、ならびに各フィールドの長さの構成は、より大きなオーバーヘッドを追加する可能性があることに注意してください。SRTPを使用することにより、RTCPパケットの平均サイズが増加し、（タイムリーな）フィードバックを提供できる頻度を減らします。アプリケーション設計者は、これを認識し、RTCP帯域幅の株式が維持されるように予防策を講じる必要があります。これは、SRTCPパケットのサイズを反映してRTCP変数「AVG_RTCP_SIZE」を調整することで行う必要があります。
The AV profiles defined in RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] are referred to as "AVP", "AVPF", and "SAVP", respectively, in the context of, e.g., the Session Description Protocol (SDP) [3]. The combined profile specified in this document is referred to as "SAVPF".
RFC 3551 [2]、RFC 4585 [3]、およびRFC 3711 [4]で定義されたAVプロファイルは、それぞれ「AVP」、「AVPF」、および「SAVP」と呼ばれます。セッション説明プロトコル（SDP）[3]。このドキュメントで指定されている組み合わせプロファイルは、「avpf」と呼ばれます。
SDP attributes for negotiating SAVP sessions are defined in RFC 4567 [7] and RFC 4568 [8]. Those attributes MAY also be used with SAVPF. The rules defined in [7] and [8] apply.
SAVPセッションの交渉のためのSDP属性は、RFC 4567 [7]およびRFC 4568 [8]で定義されています。これらの属性は、SAVPFで使用することもできます。[7]および[8]で定義されているルールが適用されます。
SDP attributes for negotiating AVPF sessions are defined in RFC 4585 [3]. Those attributes MAY also be used with SAVPF. The rules defined in [3] apply.
AVPFセッションの交渉のためのSDP属性は、RFC 4585 [3]で定義されています。これらの属性は、SAVPFで使用することもできます。[3]で定義されているルールが適用されます。
Session descriptions for RTP sessions may be conveyed using protocols dedicated for multimedia communications such as the SDP offer/answer model (RFC 3264, [9]) used with the Session Initiation Protocol (SIP) [15], the Real Time Streaming Protocol (RTSP) [10], or the Session Announcement Protocol (SAP) [11], but may also be distributed using email, NetNews, web pages, etc.
RTPセッションのセッションの説明は、セッション開始プロトコル（SIP）[15]で使用されるSDPオファー/回答モデル（RFC 3264、[9]）などのマルチメディア通信専用のプロトコルを使用して伝えられます。）[10]、またはセッションアナウンスプロトコル（SAP）[11]。
The offer/answer model allows the resulting session parameters to be negotiated using the SDP attributes defined in RFC 4567 [7] and RFC 4568 [8]. In the following subsection, the negotiation process is described in terms of the offer/answer model.
Afterwards, the cases that do not use the offer/answer model are addressed: RTSP-specific negotiation support is provided by RFC 4567 [7] as discussed in Section 3.3.2, and support for SAP announcements (with no negotiation at all) is addressed in Section 3.3.3.
その後、オファー/回答モデルを使用しないケースに対処されます。RTSP固有の交渉サポートは、セクション3.3.2で説明したRFC 4567 [7]によって提供され、SAPアナウンスメントのサポート（まったく交渉なし）です。セクション3.3.3で対処されています。
Negotiations (e.g., of RTP profiles, codecs, transport addresses, etc.) are carried out on a per-media session basis (e.g., per m= line in SDP). If negotiating one media session fails, others MAY still succeed.
交渉（たとえば、RTPプロファイル、コーデック、輸送アドレスなど）は、メディアごとのセッションベース（SDPのM =ラインあたりなど）で実行されます。1つのメディアセッションの交渉が失敗した場合、他のメディアセッションがまだ成功する可能性があります。
Different RTP profiles MAY be used in different media sessions. For negotiation of a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see Section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session and allow the answerer to choose one of the profiles.
さまざまなRTPプロファイルをさまざまなメディアセッションで使用できます。メディアの説明の交渉のために、4つのプロファイルAVP、AVPF、SAVP、およびSAVPFは相互に排他的です。ただし、SAVPおよびSAVPFエンティティは単一のRTPセッションで混合される場合があることに注意してください（セクション4を参照）。また、オファー/回答メカニズムを使用して、同じメディアセッションの代替品を提供し、回答者がプロファイルのいずれかを選択できるようにすることができます。
Provided that a mechanism for offering alternative security profiles becomes available (as is presently under development [14]), an offerer that is capable of supporting more than one of these profiles for a certain media session SHOULD always offer all alternatives acceptable in a certain situation. The alternatives SHOULD be listed in order of preference and the offerer SHOULD prefer secure profiles over non-secure ones. The offer SHOULD NOT include both a secure alternative (SAVP and SAVPF) and an insecure alternative (e.g., AVP and AVPF) in the same offer as this may enable bidding down and other attacks. Therefore, if both secure and non-secure RTP profiles are offered (e.g., for best-effort SRTP [14]), the negotiation signaling MUST be protected appropriately to avoid such attacks.
ただし、代替セキュリティプロファイルを提供するメカニズムが利用可能になり（現在開発中である[14]）、特定のメディアセッションでこれらのプロファイルの複数をサポートできるオファーは、特定の状況で受け入れられるすべての代替品を常に提供する必要があります。代替案は好みの順にリストする必要があり、オファーは安全なプロファイルよりも安全なプロファイルを好む必要があります。オファーには、安全な代替（SAVPおよびSAVPF）と、これと同じオファーに不安定な代替案（AVPやAVPFなど）の両方を、入札やその他の攻撃を可能にする可能性があることを含めるべきではありません。したがって、安全なRTPプロファイルと非安全なRTPプロファイルの両方が提供されている場合（たとえば、ベストエフォルトSRTP [14]）、そのような攻撃を回避するために交渉シグナルは適切に保護されなければなりません。
If an offer contains multiple alternative profiles, the answerer SHOULD prefer a secure profile (if supported) over non-secure ones. Among the secure or insecure profiles, the answerer SHOULD select the first acceptable alternative to respect the preference of the offerer.
オファーに複数の代替プロファイルが含まれている場合、回答者は、安全なプロファイルよりも安全なプロファイル（サポートされている場合）を好む必要があります。安全なプロファイルまたは安全なプロファイルの中で、応答者は、提供者の好みを尊重するために、最初の許容可能な代替手段を選択する必要があります。
If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected.
オファーのメディアの説明がSAVPFを使用し、ASWNERがSAVPFをサポートしていない場合、メディアセッションを拒否する必要があります。
If a media description in an offer does not use SAVPF but the answerer wants to use SAVPF, the answerer MUST reject the media session. The answerer MAY provide a counter-offer with a media description indicating SAVPF in a subsequently initiated offer/answer exchange.
オファー内のメディアの説明がavpfを使用しないが、nessurerがaspfを使用したい場合、newnersはメディアセッションを拒否する必要があります。回答者は、その後開始されたオファー/回答の交換でSAVPFを示すメディアの説明を含むカウンターオファーを提供する場合があります。
RTSP [10] does not support the offer/answer model. However, RTSP supports exchanging media session parameters (including profile and address information) by means of the Transport header. SDP-based key management as defined in RFC 4567 [7] adds an RTSP header (KeyMgmt) to support conveying a key management protocol (including keying material).
RTSP [10]は、オファー/回答モデルをサポートしていません。ただし、RTSPは、輸送ヘッダーによるメディアセッションパラメーター（プロファイルとアドレス情報を含む）の交換をサポートしています。RFC 4567 [7]で定義されているSDPベースのキー管理は、RTSPヘッダー（KeyMGMT）を追加して、キー管理プロトコル（キーイング素材を含む）の運搬をサポートします。
The RTSP Transport header MAY be used to determine the profile for the media session. Conceptually, the rules defined in Section 3.3.1 apply accordingly. Detailed operation is as follows: An SDP description (e.g., retrieved from the RTSP server by means of DESCRIBE) contains the description of the media streams of the particular RTSP resource.
RTSPトランスポートヘッダーを使用して、メディアセッションのプロファイルを決定できます。概念的には、セクション3.3.1で定義されているルールがそれに応じて適用されます。詳細な操作は次のとおりです。SDPの説明（例：描写されたRTSPサーバーから取得）には、特定のRTSPリソースのメディアストリームの説明が含まれています。
The RTSP client MUST select exactly one of the profiles per media stream it wants to receive. It MUST do so in the SETUP request. The RTSP client MUST indicate the chosen RTP profile by indicating the profile and the full server transport address (IP address and port number) in the Transport header included in the SETUP request. The RTSP server's response to the client's SETUP message MUST confirm this profile selection or refuse the SETUP request (the latter of which it should not do after offering the profiles in the first place).
RTSPクライアントは、受信したいメディアストリームごとのプロファイルの1つを正確に選択する必要があります。セットアップリクエストでそうする必要があります。RTSPクライアントは、セットアップリクエストに含まれるトランスポートヘッダーのプロファイルと完全なサーバートランスポートアドレス（IPアドレスとポート番号）を示すことにより、選択したRTPプロファイルを示す必要があります。クライアントのセットアップメッセージに対するRTSPサーバーの応答は、このプロファイルの選択を確認するか、セットアップリクエストを拒否する必要があります（後者は、そもそもプロファイルを提供した後に行うべきではありません）。
Note: To change any of the profiles in use, the client needs to tear down this media stream (and possibly the whole RTSP session) using the TEARDOWN method and re-establish it using SETUP. This may change as soon as media updating (similar to a SIP UPDATE or re-INVITE) becomes specified.
注：使用中のプロファイルのいずれかを変更するには、クライアントはこのメディアストリーム（および場合によってはRTSPセッション全体）を取り壊し、セットアップを使用して再確立する必要があります。これは、メディアの更新が（SIPの更新または再インバイトと同様に）指定されるとすぐに変更される可能性があります。
When using the SDP key management [7], the KeyMgmt header MUST be included in the appropriate RTSP messages if a secure profile is chosen. If different secure profiles are offered in the SDP description (e.g., SAVP and SAVPF) and different keying material is provided for these, after choosing one profile in the SETUP message, only the KeyMgmt header for the chosen one MUST be provided. The rules for matching KeyMgmt headers to media streams according to RFC 4567 [7] apply.
SDPキー管理[7]を使用する場合、安全なプロファイルが選択されている場合は、KeyMGMTヘッダーを適切なRTSPメッセージに含める必要があります。SDPの説明（savpやaspfなど）で異なるセキュアプロファイルが提供され、セットアップメッセージで1つのプロファイルを選択した後、選択したキーメットヘッダーのみが提供される必要がある場合、さまざまなキーイング材料が提供されている場合。RFC 4567 [7]に従って、KeyMGMTヘッダーをメディアストリームに一致させるためのルールが適用されます。
Protocols that do not allow negotiating session descriptions interactively (e.g., SAP [11], descriptions posted on a web page or sent by mail) pose the responsibility for adequate access to the media sessions on the initiator of a session.
セッションの説明をインタラクティブに交渉することを許可しないプロトコル（例：SAP [11]、Webページに投稿された説明、またはメールで送信される説明）は、セッションの開始者のメディアセッションへの適切なアクセスの責任をもたらします。
The initiator SHOULD provide alternative session descriptions for multiple RTP profiles as far as acceptable to the application and the purpose of the session. If security is desired, SAVP may be offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD NOT be announced unless other security means not relying on SRTP are employed.
イニシエーターは、アプリケーションとセッションの目的に受け入れられる限り、複数のRTPプロファイルの代替セッションの説明を提供する必要があります。セキュリティが必要な場合、SAVPはSAVPFの代替として提供される場合がありますが、SRTPに依存していない他のセキュリティが採用されていない限り、AVPまたはAVPFセッションは発表されないでください。
The SDP attributes defined in RFC 4567 [7] and RFC 4568 [8] may also be used for the security parameter distribution of announced session descriptions.
RFC 4567 [7]およびRFC 4568 [8]で定義されているSDP属性は、発表されたセッション説明のセキュリティパラメーター分布にも使用できます。
The security scheme description defined in RFC 4568 [8] requires a secure communications channel to prevent third parties from eavesdropping on the keying parameters and manipulation. Therefore, SAP security (as defined in RFC 2974 [11]), S/MIME [12], HTTPS [13], or other suitable mechanisms SHOULD be used for distributing or accessing these session descriptions.
RFC 4568 [8]で定義されているセキュリティスキームの説明では、第三者がキーキーパラメーターと操作を盗聴するのを防ぐための安全な通信チャネルが必要です。したがって、SAPセキュリティ（RFC 2974 [11]で定義されている）、S/MIME [12]、HTTPS [13]、またはその他の適切なメカニズムは、これらのセッションの説明の配布またはアクセスに使用する必要があります。
SAVP and SAVPF entities MAY be mixed in the same RTP session (see also Section 4) and so MAY AVP and AVPF entities. Other combinations -- i.e., between secure and insecure profiles -- in the same RTP session are incompatible and MUST NOT be used together.
SAVPおよびSAVPFエンティティは、同じRTPセッションで混合される場合があります（セクション4も参照）、AVPおよびAVPFエンティティも同様です。同じRTPセッションでの他の組み合わせ、つまり安全なプロファイルと安全なプロファイルの間では互換性がなく、一緒に使用してはなりません。
If negotiation between the involved peers is possible (as with the offer/answer model per Section 3.3.1 or RTSP per Section 3.3.2), alternative (secure and non-secure) profiles MAY be specified by one entity (e.g., the offerer) and a choice of one profile MUST be made by the other. If no such negotiation is possible (e.g., with SAP as per Section 3.3.3), incompatible profiles MUST NOT be specified as alternatives.
関係するピア間の交渉が可能である場合（セクション3.3.1またはセクション3.3.2ごとのRTSPごとのオファー/回答モデルと同様）、代替（セキュアおよび非セキュア）プロファイルは、1つのエンティティによって指定される場合があります（例：提供者は）そして、1つのプロファイルの選択を他のプロファイルによって選択する必要があります。そのような交渉が不可能な場合（例：セクション3.3.3に従ってSAPを使用）、互換性のないプロファイルを代替として指定する必要はありません。
The negotiation of alternative profiles is for further study.
代替プロファイルの交渉は、さらなる研究のためのものです。
RTP profiles MAY be mixed arbitrarily across different RTP sessions.
RTPプロファイルは、さまざまなRTPセッションで任意に混合される場合があります。
This section includes examples for the use of SDP to negotiate the use of secure and non-secure profiles. Depending on what keying mechanism is being used and how it parameterized, the SDP messages typically require integrity protection and, for some mechanisms, will also need confidentiality protection. For example, one could say integrity protection is required for the a=fingerprint of Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], and confidentiality is required for RFC 4568 [8] (Security Descriptions) a=crypto.
このセクションには、SDPを使用して、安全なプロファイルと非セキュアプロファイルの使用を交渉するための例が含まれています。キーイングメカニズムが使用されているものとパラメーター化方法に応じて、SDPメッセージは通常、完全性保護を必要とし、一部のメカニズムにも機密保護が必要です。たとえば、データグラムトランスポートレイヤーセキュリティのa =指紋 - セキュアリアルタイムトランスポートプロトコル（DTLS-SRTP）[16]には整合性保護が必要であり、RFC 4568 [8]（セキュリティ記述）には機密性が必要であると言えます。a =暗号。
Example 1: The following session description indicates a secure session made up from audio and dual tone multi-frequency (DTMF) for point-to-point communication in which the DTMF stream uses Generic NACKs. The key management protocol indicated is MIKEY. This session description (the offer) could be contained in a SIP INVITE or 200 OK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits. The corresponding answer may be carried in a 200 OK or an ACK. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7].
例1：次のセッションの説明では、DTMFストリームが一般的なNACKを使用するポイントツーポイント通信のオーディオおよびデュアルトーン多周波（DTMF）から構成される安全なセッションを示します。示されている主要な管理プロトコルはMikeyです。このセッションの説明（オファー）は、SIPの招待状または200 OKメッセージに含めることができ、その送信者が送信するDTMFストリームのフィードバックを受け取ることができ、喜んで受け取ることを望んでいることを示します。対応する回答は、200 OKまたはACKで伝えることができます。セキュリティプロトコルのパラメーターは、RFC 4567で定義されているSDP拡張機能で説明されているように交渉されます[7]。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
Example 2: This example shows the same feedback parameters as example 1 but uses the secure descriptions syntax [8]. Note that the key part of the a=crypto attribute is not protected against eavesdropping and thus the session description needs to be exchanged over a secure communication channel.
例2：この例は、例1と同じフィードバックパラメーターを示していますが、安全な説明構文[8]を使用しています。a = crypto属性の重要な部分は盗聴から保護されていないため、セッションの説明を安全な通信チャネルで交換する必要があることに注意してください。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
:32
Example 3: This example is replicated from example 1 above, but shows the interaction between the offerer and the answerer in an offer/answer exchange, again using MIKEY to negotiate the keying material:
例3：この例は上記の例1から再現されていますが、オファー/回答の交換で提供者と回答者の間の相互作用を示しています。
Offer:
オファー：
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
Answer:
答え：
v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
Example 4: This example shows the exchange for video streaming controlled via RTSP. A client acquires a media description from a server using DESCRIBE and obtains a static SDP description without any keying parameters, but the media description shows that both secure and non-secure media sessions using (S)AVPF are available. A mechanism that allows explicit identification of these alternatives (i.e., secure and non-secure sessions) in the session description is presently being defined [14]. The client then issues a SETUP request and indicates its choice by including the respective profile in the Transport parameter. Furthermore, the client includes a KeyMgmt header to convey its security parameters, which is matched by a corresponding KeyMgmt header from the server in the response. Only a single media session is chosen so that the aggregate RTSP URI is sufficient for identification.
例4：この例は、RTSPを介して制御されるビデオストリーミングの交換を示しています。クライアントは、キーキーパラメーターなしでdestrible describthと静的SDP説明を使用してサーバーからメディアの説明を取得しますが、メディアの説明は、（S）AVPFを使用した安全なメディアセッションと非セキュアなメディアセッションの両方が利用可能であることを示しています。セッションの説明におけるこれらの代替物（すなわち、安全なセッションおよび非セキュアセッション）の明示的な識別を可能にするメカニズムは現在定義されています[14]。次に、クライアントはセットアップリクエストを発行し、トランスポートパラメーターにそれぞれのプロファイルを含めることにより、選択を示します。さらに、クライアントには、応答中のサーバーからの対応するKeyMGMTヘッダーと一致するセキュリティパラメーターを伝えるためのKeyMGMTヘッダーが含まれています。集約RTSP URIで識別に十分であるように、単一のメディアセッションのみが選択されます。
RTSP DESCRIBE request-response pair (optional):
RTSPは、リクエスト応答ペア（オプション）を説明しています。
DESCRIBE rtsp://movies.example.org/example RTSP/2.0 CSeq: 314 Accept: application/sdp
rtsp：//movies.example.org/example rtsp/2.0 cseq：314 Accept：application/sdpを説明する
200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316
v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
+-Alternative one-----------------+
|m=video 49170 RTP/SAVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
+-Alternative two-----------------+
|m=video 49172 RTP/AVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
RTSP SETUP request-response pair
RTSPセットアップリクエスト応答ペア
SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."
200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE
Example 5: The following session description indicates a multicast audio/video session (using PCMU for audio and either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7], used at the session level. Such a description may have been conveyed using the Session Announcement Protocol (SAP).
例5：次のセッションの説明では、マルチキャストオーディオ/ビデオセッション（PCMUをオーディオとH.261またはH.263のいずれかを使用して）を示しています。ビデオソースは、コーデックとH.263の参照画像選択の両方の一般的なNACKを受け入れます。セキュリティプロトコルのパラメーターは、セッションレベルで使用されたRFC 4567 [7]で定義されたSDP拡張機能で説明されているように交渉されます。このような説明は、セッションアナウンスプロトコル（SAP）を使用して伝えられている可能性があります。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
The SAVPF profile defined in this document is a combination of the SAVP profile [4] and the AVPF profile [3] (which in turn is an extension of the RTP profile as defined in RFC 3551 [2]).
このドキュメントで定義されているSAVPFプロファイルは、SAVPプロファイル[4]とAVPFプロファイル[3]（RFC 3551 [2]で定義されているRTPプロファイルの拡張）の組み合わせです。
SAVP and SAVPF use SRTP [4] to achieve security. AVP and AVPF use plain RTP [1] and hence do not provide security (unless external security mechanisms are applied as discussed in Section 9.1 of RFC 3550 [1]). SRTP and RTP are not meant to interoperate; the respective protocol entities are not supposed to be part of the same RTP session. Hence, AVP and AVPF on one side and SAVP and SAVPF on the other MUST NOT be mixed.
SAVPとSAVPFはSRTP [4]を使用してセキュリティを実現します。AVPおよびAVPFは、プレーンRTP [1]を使用するため、セキュリティを提供しません（RFC 3550 [1]のセクション9.1で説明されているように外部セキュリティメカニズムが適用されない限り）。SRTPとRTPは相互運用することを意図していません。それぞれのプロトコルエンティティは、同じRTPセッションの一部であるとは想定されていません。したがって、片側にAVPとAVPF、もう一方のSAVPとSAVPFを混合してはなりません。
RTP entities using the SAVP and the SAVPF profiles MAY be mixed in a single RTP session. The interworking considerations defined in Section 5 of RFC 4585 [3] apply.
SAVPとSAVPFプロファイルを使用するRTPエンティティは、単一のRTPセッションで混合される場合があります。RFC 4585 [3]のセクション5で定義されているインターワーキングの考慮事項が適用されます。
The SAVPF profile inherits its security properties from the SAVP profile; therefore, it is subject to the security considerations discussed in RFC 3711 [4]. When compared to SAVP, the SAVPF profile does not add or take away any security services.
SAVPFプロファイルは、SAVPプロファイルからセキュリティプロパティを継承します。したがって、RFC 3711 [4]で説明されているセキュリティ上の考慮事項の対象となります。SAVPと比較すると、SAVPFプロファイルはセキュリティサービスを追加または奪いません。
There is a desire to support security for media streams and, at the same time, for backward compatibility with non-SAVP(F) nodes.
メディアストリームのセキュリティをサポートし、同時に、非SAVP（f）ノードとの逆方向の互換性のために、セキュリティをサポートしたいという願望があります。
Application designers should be aware that security SHOULD NOT be traded for interoperability. If information is to be distributed to closed groups (i.e., confidentially protected), it is RECOMMENDED not to offer alternatives for a media session other than SAVP and SAVPF as described in Sections 3.3 and 3.4, unless other security mechanisms will be used, e.g., the ones described in Section 9.1 of RFC 3550 [1]. Similarly, if integrity protection is considered important, it is RECOMMENDED not to offer the alternatives other than SAVP and SAVPF, unless other mechanisms are known to be in place that can guarantee it, e.g., lower-layer mechanisms as described in Section 9 of RFC 3550 [1].
アプリケーション設計者は、セキュリティを相互運用性と交換すべきではないことに注意する必要があります。情報を閉じたグループに配布する場合（つまり、機密保護）、セクション3.3および3.4で説明されているように、SAVPおよびSAVPF以外のメディアセッションの代替案を提供しないことをお勧めします。RFC 3550のセクション9.1で説明されているもの[1]。同様に、整合性保護が重要であると考えられている場合、RFCのセクション9で説明されているように、それを保証できる他のメカニズムが存在することが知られていない限り、SAVPおよびSAVPF以外の代替案を提供しないことをお勧めします。3550 [1]。
Offering secure and insecure profiles simultaneously may open to bidding down attacks. Therefore, such a mix of profile offer SHOULD NOT be made.
安全で不安定なプロファイルを同時に提供すると、攻撃の入札に開かれる場合があります。したがって、このようなプロファイルオファーの組み合わせは作成されるべきではありません。
Note that the rules for sharing master keys apply as described in RFC 3711 [4] (e.g., Section 9.1). In particular, the same rules for avoiding the two-time pad (keystream reuse) apply: a master key MUST NOT be shared among different RTP sessions unless the SSRCs used are unique across all the RTP streams of the RTP sessions that share the same master key.
マスターキーを共有するためのルールは、RFC 3711 [4]に記載されているように適用されることに注意してください（例：セクション9.1）。特に、2回のパッド（キーストリームの再利用）を回避するための同じルールが適用されます。マスターキーは、同じマスターを共有するRTPセッションのすべてのRTPストリームにわたってユニークでない限り、異なるRTPセッション間で共有してはなりません。鍵。
When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) (previously stored and used keys MUST NOT be used again), or the session MUST be terminated.
2^48 SRTPパケットまたは2^31 SRTCPパケットが同じキー（以前に発生した場合）で固定されている場合、新しいマスターキーを提供するためにキー管理を呼び出す必要があります（以前に保存され、使用済みのキーを再度使用しないでください）、またはセッションを終了する必要があります。
Different media sessions may use a mix of different profiles, particularly including a secure profile and an insecure profile. However, mixing secure and insecure media sessions may reveal information to third parties and thus the decision to do so MUST be in line with a local security policy. For example, the local policy MUST specify whether it is acceptable to have, e.g., the audio stream not secured and the related video secured.
さまざまなメディアセッションでは、特に安全なプロファイルや安全でないプロファイルなど、さまざまなプロファイルの組み合わせを使用する場合があります。ただし、安全で安全なメディアセッションを混ぜると、第三者に情報が明らかになる可能性があるため、その決定は地域のセキュリティポリシーに沿っている必要があります。たとえば、ローカルポリシーは、たとえばオーディオストリームが保護されておらず、関連するビデオが保護されていることが許容できるかどうかを指定する必要があります。
The security considerations in RFC 4585 [3] are valid, too. Note in particular, applying the SAVPF profile implies mandatory integrity protection on RTCP. While this solves the problem of false packets from members not belonging to the group, it does not solve the issues related to a malicious member acting improperly.
RFC 4585 [3]のセキュリティ上の考慮事項も有効です。特に、SAVPFプロファイルを適用することは、RTCPに対する必須の整合性保護を意味します。これは、グループに属していないメンバーからの誤ったパケットの問題を解決しますが、不適切に行動する悪意のあるメンバーに関連する問題を解決しません。
The following contact information shall be used for all registrations included here:
次の連絡先情報は、ここに含まれるすべての登録に使用するものとします。
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-451-2460
The secure RTP feedback profile, as a combination of Secure RTP and the feedback profile, has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/SAVPF".
安全なRTPとフィードバックプロファイルの組み合わせとしての安全なRTPフィードバックプロファイルは、セッション説明プロトコル（具体的には "Proto"）： "rtp/savpf"に登録されています。
SDP Protocol ("proto"):
SDPプロトコル（ "Proto"）：
Name: RTP/SAVPF Long form: Secure RTP Profile with RTCP-based Feedback Type of name: proto Type of attribute: Media level only Purpose: RFC 5124 Reference: RFC 5124
名前：RTP/SAVPF LONG FORM：RTCPベースのフィードバックを使用したセキュアRTPプロファイルタイプの名前：Proto Type of Attribute：Mediaレベルのみ目的：RFC 5124リファレンス：RFC 5124
All the SDP attributes defined for RTP/SAVP and RTP/AVPF are valid for RTP/SAVPF, too.
RTP/SAVPおよびRTP/AVPFで定義されているすべてのSDP属性は、RTP/SAVPFに対しても有効です。
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. The authors would like to thank Magnus Westerlund, Colin Perkins, and Cullen Jennings for their comments.
このドキュメントは、IETFのオーディオビジュアルトランスポート（AVT）ワーキンググループの製品です。著者は、マグナス・ウェスターランド、コリン・パーキンス、カレン・ジェニングスのコメントに感謝したいと思います。
[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] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[2] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[3] 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.
[3] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、2006年7月。
[4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[4] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[6] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[7] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[7] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC 4567、7月2006年。
[8] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[8] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ説明」、RFC 4568、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] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[10] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11]
[12] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[12] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[14] Andreasen, F., "SDP Capability Negotiation", Work in Progress, December 2007.
[14] Andreasen、F。、「SDP能力交渉」、2007年12月、進行中の作業。
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[15] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[16] McGrew, D. and Rescorla, E., "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, November 2007.
[16] McGrew、D。and Rescorla、E。、「データグラム輸送層セキュリティ（DTLS）拡張機能を確立するためのキーを確立するためのキーを確立する」、2007年11月、作業進行中。
Authors' Addresses
著者のアドレス
Joerg Ott Helsinki University of Technology Otakaari 5A FI-02150 Espoo Finland
Joerg Ott Helsinki工科大学Otakaari 5A FI-02150 Espoo Finland
EMail: jo@comnet.tkk.fi
Phone: +358-9-451-2460
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
エリザベッタ・カララ・ロイヤル・インスティテュート・オブ・テクノロジー・ストックホルム・スウェーデン
EMail: carrara@kth.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。