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.
安全なリアルタイム通信および送信者に受信機からのタイムリーなフィードバックを提供するために別のプロファイル（AVPF）のためのRTPプロファイル（SAVP）は、それぞれ、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パケットを暗号化するための唯一の初歩的なサポートを提供します。セキュアRTP（RFC 3711）[4]適切なRTPとRTCPパケットの暗号化、完全性、および再生保護のための方法を定義する、セキュアRTPメディアセッションのRTPプロファイル（「SAVP」）を定義します。一緒に鍵材料を搬送するための拡張子を持つ初期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ベースのフィードバックのための拡張RTPプロファイル（「AVPF」）（RFC 4585には、[3]）すべての送信者の平均RTCPデータレートを維持しながら、セッション参加者が、統計的に即時のフィードバックを提供することを可能にします。 SAVPとしては、AVPFとそのパラメータの使用は、[3] SDP（RFC 4566 [6]）とRFC 4585で定義された拡張によってアウトオブバンドネゴシエートする必要があります。
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プロファイルであり、交渉される必要があります。これは、1つまたは他のいずれかが使用されてもよいが、両方のプロファイルは、（1つのSDPセッションレベル記述を使用して）同じRTPセッションのために交渉することができないことを意味します。しかし、一緒に安全な通信とタイムリーなフィードバックを使用することが望ましいです。したがって、この文書は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で定義されているRTPと通信参加者の集合のうち、関連[1]。
(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メディア記述は、唯一の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メディア記述の集合を指します。そのような基のうち、一つがネゴシエートされるか、通信関係のために選択されると、対応する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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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プロファイルAVP以下）RTPとの間の中間層とトランスポート層（通常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 RTCPの暗号プレフィックスの[1]（オプション）の使用に由来します。暗号化プレフィックスはSAVPFプロファイル（それは[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パケットのための変更されたパケット・フォーマットを定義します。 RFC 3711のセクション3.4 [4]で定義されるようSAVPFため、すべてのRTCPパケットがカプセル化されなければなりません。
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フィードバックパケットに拡張はSAVPFプロファイルと共に使用することができるこれらの拡張子は、[3] RFC 4585の拡張ルールに準拠していることを条件とします。
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のセクション6の規則に従ってSAVPに対して定義された追加の拡張（例えば、変換）[4]また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（[4] RFC 3711のセクション3.4を参照）は、おそらくサイズが少なくとも約10〜20バイト（デフォルトとして14バイト）は、各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に定義されたAVプロファイル3551 [2]、RFC 4585 [3]、及びRFC 3711 [4] "AVP" と呼ばれ、例えば、 "AVPF" との関連でそれぞれ "SAVP"、、、、セッション記述プロトコル（SDP）[3]。この文書で指定された組み合わせプロファイルは、「SAVPF」と呼ばれています。
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.
SDPは、SAVPセッションを交渉するための属性は、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.
SDPは、AVPFセッションを交渉するための属性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セッションのセッション記述は、SDPオファー/アンサーモデルなどのマルチメディア通信のための専用プロトコルを用いて搬送することができる（RFC 3264 [9]）セッション開始プロトコル（SIP）[15]、リアルタイムストリーミングプロトコル（RTSPと共に使用）[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.
オファー/アンサーモデルが得られたセッションパラメータがRFC 4567で定義されたSDP属性を使用してネゴシエートすることが可能になる[7]とRFC 4568 [8]。以下のサブセクションでは、交渉プロセスは、オファー/アンサーモデルの観点から説明されます。
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固有の交渉のサポートはRFC 4567で提供される[7]（全く交渉で）3.3.2項、および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あたり=行）ごとのメディアセッションに基づいて行われます。交渉つのメディアセッションが失敗した場合、他の人はまだ成功する可能性があります。
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プロファイルが提供されている場合（例えば、ベストエフォート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.
オファーは複数の代替のプロファイルが含まれている場合（サポートされている場合）、回答は、セキュリティで保護されていないものより安全なプロファイルを好むべきです。セキュアなまたは非セキュアプロファイルのうち、回答は、提供者の嗜好を尊重するために第1の許容される代替物を選択すべきです。
If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected.
提供中のメディア記述がSAVPFを使用し、回答が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.
提供中のメディア記述がSAVPFを使用しませんが、回答はSAVPFを使用したい場合は、アンサー側は、メディアセッションを拒絶しなければなりません。回答は、その後に開始オファー/アンサー交換で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は、トランスポート・ヘッダによって（プロファイルおよびアドレス情報を含む）は、メディアセッションパラメータを交換することをサポート。 SDPベースの鍵管理RFC 4567で定義されるように[7]（キーイング材料を含む）、鍵管理プロトコルを搬送するサポートするために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で定義されたルールは、それに応じて適用されます。次のように詳細な動作は、（例えば、DESCRIBEによってRTSPサーバから取得）SDP記述特定の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クライアントは、まさにそれが受信したいメディアストリームごとにプロファイルのいずれかを選択する必要があります。これは、SETUP要求中で行う必要があります。 RTSPクライアントは、SETUP要求に含まれるトランスポートヘッダ内のプロファイルと完全なサーバトランスポートアドレス（IPアドレス及びポート番号）を示すことにより、選択されたRTPプロファイルを示さなければなりません。クライアントのSETUPメッセージにRTSPサーバの応答は、このプロファイルの選択を確認またはSETUP要求（それが最初の場所でプロファイルを提供した後に行うべきではありませんそのうち後者を）拒否しなければなりません。
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.
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メッセージに含まれなければなりません。異なるセキュアプロファイルが（例えば、SAVP及びSAVPF）SDP記述で提供され、異なる鍵材料は、SETUPメッセージ内の1つのプロファイルを選択した後、これらのために提供される場合、選択されたいずれかの唯一KeyMgmtヘッダが提供されなければなりません。 RFC 4567によれば、メディアストリームにKeyMgmtヘッダをマッチングするための規則は、[7]適用します。
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]、説明はウェブページに掲載またはメールで送られた）は、セッションのイニシエータのメディアセッションへの適切なアクセスのための責任を提起します。
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で定義されたSDP属性[7]及びRFC 4568 [8]も発表セッション記述のセキュリティパラメータ分布のために使用することができます。
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セッション中に混合することができるので、MAY AVPとAVPF実体（セクション4を参照）。他の組合せ - すなわち、安全かつセキュアでないプロファイル間 - 同じ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つのプロファイルの選択は、他で行われなければなりません。そのような交渉が可能に（例えば、SAPとの3.3.3あたりなど）がない場合、互換性のないプロファイルは、代替案として指定することはできません。
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メッセージは通常、完全性保護を必要とし、いくつかのメカニズムのために、また、機密保護が必要になります。例えば、1は、完全性保護は、データグラムトランスポート層セキュリティのA =指紋のために必要であると言うことができる - [16]リアルタイムトランスポートプロトコル（DTLS-SRTP）を確保し、機密性は、RFC 4568のために必要とされる[8]（セキュリティ記述） =暗号。
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に含まれることができるINVITEまたは200 OKメッセージは、その送信者がすることができる、それが送信するDTMFストリームに対するフィードバックを受信する意思があることを示すために。対応する答えはOK 200または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...
V = 0 0 = 3203093520 3203093520 IN IP4 host.example.com S =メディアフィードバックTに= 0、C = IN IP4 host.example.com M =オーディオ49170 RTP / SAVPF 0 96 = rtpmapアリス：0 PCMU / 8000 = rtpmap：96電話-イベント/ 8000 =のfmtp：96 0-16 = RTCP-FB：96 NACK A =キーMGMT：マイキー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 =暗号属性の重要な部分は、盗聴から保護されていないので、セッション記述は、安全な通信チャネルを介して交換される必要があることに留意されたいです。
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
V = 0 0 = 3203093520 3203093520 IN IP4 host.example.com S =メディアフィードバックTに= 0、C = IN IP4 host.example.com M =オーディオ49170 RTP / SAVPF 0 96 = rtpmapアリス：0 PCMU / 8000 = rtpmap：96電話イベント/ 8000 =のfmtp：96 0-16 = RTCP-FB：96のNACK A =暗号：AES_CM_128_HMAC_SHA1_32インライン：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から複製されるが、再び鍵材料をネゴシエートするMIKEYを使用して、オファー/アンサー交換に申出と回答との間の相互作用を示します。
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
マイキーuiSDF9sdhs727ghsd / dhsoKkdOokdo7eWsnDSJD ...メートル=オーディオ49170：IP4 host.example.com S =メディアとフィードバックさt = 0 0 C IN = IP4 host.example.com A =キー、MGMT、V IN = 0 0 =アリス3203093520 3203093520 RTP / SAVPF 0 96 = rtpmap：0 PCMU / 8000 = rtpmap：96電話イベント/ 8000 =のfmtp：96 0-16 = 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
IP4 host.another.example.com S =メディア、V IN = 0 0 =アリス3203093521 3203093521フィードバックさt = 0 0 C IN = IP4 host.another.example.com A =キー-MGMTと：マイキーushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD ...メートル=オーディオ53012 RTP / SAVPF 0 96 = rtpmap：0 PCMU / 8000 = rtpmap：96電話イベント/ 8000 =のfmtp：96 0-16 = 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
例4：この例では、RTSPを介して制御されたビデオストリーミング用の交換を示しています。クライアントは、DESCRIBE使用してサーバからメディア記述を取得し、任意のキーイングパラメータを指定せずに静的SDP記述を取得するが、メディア記述は、（S）AVPFを使用して、セキュア及び非セキュア両方のメディアセッションが利用可能であることを示しています。セッション記述におけるこれらの選択肢（すなわち、セキュア及び非セキュア・セッション）の明示的な識別を可能にする機構は、現在定義されている[14]。次に、クライアントは、SETUP要求を発行します
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.
交通パラメータの各プロファイルを含むことによって、その選択肢を示しています。さらに、クライアントは、応答してサーバから対応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を説明します。RTSP / 2.0のCSeq //movies.example.org/example：314は受け入れ：アプリケーション/ SDPを
200 OK CSeq: 314 Date: 25 Nov 2005 22:09:35 GMT Content-Type: application/sdp Content-Length: 316
200のOKのCSeq：314日付：2005年11月25日22時09分35秒GMTのコンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：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要求と応答のペア
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..."
SETUPのRTSP：RTSP //movies.example.org/example / 2.0のCSeq：315トランスポート：RTP / SAVPF、ユニキャスト、dest_addrは= "53012" / "：53013" KeyMgmt：=マイキーPROT; URL = "RTSP：// movies.example.org/example ";データ= "uiSDF9sdhs727ghsd / dhsoKkdOokdo7eWsnD ..."
200 OK CSeq: 315 Date: 25 Nov 2005 22:09:36 GMT Session: 4711
200 OKのCSeq：315日付：2005年11月25日午後09時09分36秒GMTセッション：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：以下のセッション記述は、コーデックとH.263のための参照ピクチャ選択の両方のための汎用NACKを受け入れるビデオソースと（オーディオおよびH.261またはH.263 +のいずれかにPCMUを使用して）マルチキャストオーディオ/ビデオ・セッションを示します。セキュリティプロトコルのパラメータは、RFC 4567で定義されたSDP拡張により記載されたように、[7]ネゴシエートセッションレベルで使用されています。そのような記述は、セッションアナウンスメントプロトコル（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
フィードバックTとV = 0 0 =アリス3203093520 3203093520 IN IP4がhost.example.com S =マルチキャストビデオは= 3203130148 3203137348 =キー-MGMT：IP4 INマイキーuiSDF9sdhs7494ghsd / dhsoKkdOokdo7eWsnDSJD ... M =オーディオ49170 RTP / SAVP 0のC = 224.2.1.183 = rtpmap：0 PCMU / 8000メートル=ビデオ51372 IP4 224.2.1.184 = rtpmap IN RTP / SAVPF 98〜99のC =：98 H263-1998 / 90000 = rtpmap：99 H261 / 90000 =の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で定義されるように順番にRTPプロファイルの拡張である[2]）。
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は、セキュリティを実現するために、[4] SRTPを使用します。 AVPとAVPFプレーンRTPを使用する[1]（外部セキュリティメカニズムが適用されない限り、RFC 3550のセクション9.1で議論するように、[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のセクション5で定義されたインターワーキング考慮[3]適用します。
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回のパッド（キーストリームの再利用）を回避するため、同じ規則が適用されます使用SSRCsは同じマスターを共有する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パケットが（前に起こる方）同じキーで固定されている場合、鍵管理は、（以前に保存され、使用されるキーを再度使用してはいけません新しいマスターキー（S）を提供するために呼び出さなければなりません）、またはセッションが終了しなければなりません。
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
連絡先：イェルクオットメール：jo@acm.org電話：+ 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 / SAVPF」：安全なRTPフィードバックプロファイルは、セキュアRTPフィードバックプロファイルの組み合わせとして、セッション記述プロトコル（具体的にはタイプ「プロト」）のために登録されています。
SDP Protocol ("proto"):
SDPプロトコル（ "なぜ"）：
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ロング形式：属性のプロトタイプ：メディアレベルのみ目的：RFC 5124参考：名前のRTCPベースのフィードバックタイプとのセキュアなRTPプロファイル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.、フレデリック、R.、およびV.ヤコブソン、 "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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、「リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル-Basedフィードバック（RTP / AVPF） 」、RFC 4585、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.、マグリュー、D.、Naslund、M.、カララ、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[6]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[8] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[8]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[10] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[12] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[12] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[14] Andreasen, F., "SDP Capability Negotiation", Work in Progress, December 2007.
[14]アンドレア、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]マグリュー、D.とレスコラ、E.、「データグラムトランスポート層セキュリティ（DTLS）拡張セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するために」、進歩、2007年11月に作業。
Authors' Addresses
著者のアドレス
Joerg Ott Helsinki University of Technology Otakaari 5A FI-02150 Espoo Finland
イェルク・オットヘルシンキ工科大学のOtakaari 5A、FI-02150エスポーフィンランド
EMail: jo@comnet.tkk.fi Phone: +358-9-451-2460
メールアドレス：jo@comnet.tkk.fi電話：+ 358-9-451-2460
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
技術ストックホルムスウェーデンのエリザベッタ・カッラーラ王立協会
EMail: carrara@kth.se
メールアドレス：carrara@kth.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。