RFC5124 日本語訳

Network Working Group                                             J. Ott
Request for Comments: 5124             Helsinki University of Technology
Category: Standards Track                                     E. Carrara
                                                                     KTH
                                                           February 2008

コメントを求めるワーキンググループJ.オットの要求をネットワークでつないでください: 5124年の技術カテゴリのヘルシンキ大学: 標準化過程E.カラーラKTH2008年2月

                    Extended Secure RTP Profile for
 Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)

拡張安全なRTPはリアルタイムの輸送制御プロトコルのために(RTCP)ベースのフィードバックの輪郭を描きます。(RTP/SAVPF)

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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)はRFC3711とRFC4585でそれぞれ定義されます。 このメモは、フィードバックとの安全なRTPコミュニケーションを可能にするために両方のプロフィールの組み合わせを指定します。

Ott & Carrara               Standards Track                     [Page 1]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[1ページ]。

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

1. 序論…3 1.1. 定義…4 1.2. 用語…4 2. SAVPFは統治します…4 2.1. パケット形式…5 2.2. 拡大…5 2.3. AVPFとSAVPを結合するのからの含意…6 3. SDP定義…6 3.1. 定義の輪郭を描いてください…6 3.2. 定義を結果と考えてください…6 3.3. 交渉の輪郭を描いてください…6 3.3.1. セッション記述の答え申し出/ベースの交渉…7 3.3.2. セッション記述のRTSPベースの交渉…8 3.3.3. セッション記述を発表します…9 3.3.4. 代替のセッションプロフィールについて説明します…9 3.4. 例…10 4. 実体はAVP、SAVP、AVPF、およびSAVPFを織り込みます。13 5. セキュリティ問題…14 6. IANA問題…15 7. 承認…15 8. 参照…15 8.1. 標準の参照…15 8.2. 有益な参照…16

Ott & Carrara               Standards Track                     [Page 2]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[2ページ]。

1.  Introduction

1. 序論

   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.

レアル-時間Transportプロトコル、関連RTP Controlプロトコル(RTP/RTCP、RFC3550)[1]、および最小量のコントロール(RFC3551)[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(RFC3711)[4]は安全なRTPメディアセッションのためのRTPプロフィール("SAVP")を定義します、適切なRTP、RTCPパケット暗号化、保全、および反復操作による保護のためのメソッドを定義して。 SRTPの初期の交渉とそのセキュリティパラメタは、バンドの外でする必要があります、例えば、運びに拡大と共にSession記述プロトコル(SDP、RFC4566)[6]を使用すると材料が合わせられて。(RFC4567[7](RFC4568[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") (RFC4585、[3])はすべての送付者のために平均したRTCPデータ信号速度を維持している間、即座のフィードバックを提供するために統計的にセッション関係者を許容します。 SAVPに関して、AVPFの使用とそのパラメタは、SDPによってバンドの外で交渉される必要があります。(RFC4566、[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が主に直交しているので、両方の組み合わせはほとんど簡単です。 どんな高度なアルゴリズムも、本書では指定される必要がありません。 代わりに、既存のプロフィールと彼らの組み合わせの含意だけの両方を参照します、そして、交渉プロセスのように既存のプロフィールの規則からの可能な逸脱について説明します。

Ott & Carrara               Standards Track                     [Page 3]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[3ページ]。

1.1.  Definitions

1.1. 定義

   The definitions of RFC 3550 [1], RFC 3551 [2], RFC 4585 [3], and RFC
   3711 [4] apply.

RFC3550[1]、RFC3551[2]、RFC4585[3]、およびRFC3711[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セッション: RFC3550[1]で定義されるように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メッセージの1m=系列で与えられた仕様を示します。 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セッションに同等です。

1.2.  Terminology

1.2. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?

2.  SAVPF Rules

2. SAVPF規則

   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)の間の中間層と定義されます。 これはレアル-時間Transportプロトコルの中で2層の階層構造をもたらします。 SAVPFでは、上側の(AVP)層をフィードバック(AVPF)のための拡張RTPプロフィールに取り替えます。

   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で変わりがありません。

Ott & Carrara               Standards Track                     [Page 4]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[4ページ]。

   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プロフィールがRFC3550に[1] 暗号化接頭語のRTCPの(任意)の使用に由来しています。 SAVPFプロフィールの中に暗号化接頭語を使用してはいけません。(それはSAVPで使用されません、それが単に[1])で指定された暗号化メソッドに適切であるときに。

   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.

RTPかRTCPを「より高い」AVPF層で予定していたか、またはトランスポート・プロトコルから受け取ったときだけ、SRTP部分はアクティブになります、そのタイミングとコンテンツの如何にかかわらず。

2.1.  Packet Formats

2.1. パケット・フォーマット

   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は、フィードバック情報を提供するために付加的なパケット・フォーマットを定義します。 RFC4585[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はセキュリティ目的のためにSRTPとSRTCPパケットのためのRTP/RTCPパケット・フォーマットといくつかの引きずっているプロトコル分野から本質的には成る変更されたパケット・フォーマットを定義します。 SAVPF、RFC3711[4]のセクション3.4で定義されるようにパケットをカプセルに入れらなければならないすべてのRTCPのために。

2.2.  Extensions

2.2. 拡大

   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].

それらの拡大が順応RFC4585[3]の拡大規則で中であれば、ほかの場所で定義されたAVPF RTCPフィードバックパケットへの拡張子はSAVPFプロフィールと共に使用されるかもしれません。

   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.

また、RFC3711[4]のセクション6の規則に従って、SAVPのために定義された追加拡張子(例えば、変形する)はSAVPFプロフィールと共に使用されるかもしれません。 RTCPパケットあたりのオーバーヘッドは選ばれた拡大と変換によります。 将来加えられた新しい拡大と変換はさらにパケットあたりのまだ未知のオーバーヘッドを導入するかもしれません。

   Finally, further extensions specifically to SAVPF MAY be defined
   elsewhere.

最終的にさらなる拡大、特にSAVPF MAYと、ほかの場所で定義されてください。

Ott & Carrara               Standards Track                     [Page 5]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[5ページ]。

2.3.  Implications from Combining AVPF and SAVP

2.3. AVPFとSAVPを結合するのからの含意

   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、(RFC3711[4])のセクション3.4がサイズ(デフォルトとしての14バイト)でそれぞれのRTCPパケットの端のたぶん少なくとも10〜20バイトいくつかである付加的な分野(それの或るものは構成可能な長さのものである)を加えるのを確実にしてください。 将来それぞれのフィールド長の構成と同様に定義された拡大と変換が、よりすばらしいオーバーヘッドを加えるかもしれないことに注意してください。 SRTPを使用することによって、RTCPパケットの平均のサイズは、(タイムリー)のフィードバックを提供できる頻度を増強して、その結果、減少させるでしょう。 アプリケーション設計者がこれを意識しているのが必要であり、予防策を講するので、RTCP帯域幅シェアは維持されます。 SRTCPパケットのサイズを反映するようにRTCPの可変「avg_rtcp_サイズ」を調整することによって、これをしなければなりません。

3.  SDP Definitions

3. SDP定義

3.1.  Profile Definition

3.1. プロフィール定義

   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".

RFC3551[2]、RFC4585[3]、およびRFC3711[4]で定義されたAVプロフィールが文脈にそれぞれ"AVP"、"AVPF"、および"SAVP"と呼ばれる、例えば、セッション記述プロトコル(SDP)[3]。 本書では指定された結合したプロフィールは"SAVPF"と呼ばれます。

3.2.  Attribute Definitions

3.2. 属性定義

   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属性はRFC4567[7]とRFC4568[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属性はRFC4585[3]で定義されます。 また、それらの属性はSAVPFと共に使用されるかもしれません。 [3]で定義された規則は適用されます。

3.3.  Profile Negotiation

3.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申し出/答えモデルなどのマルチメディア通信のために捧げられたプロトコルを使用することで伝えられるかもしれません。(RFC3264、また、分配された使用であるかもしれないのを除いて、Session Initiationプロトコル(SIP)[15]、レアルTime Streamingプロトコル(RTSP)[10]、またはSession Announcementプロトコル(SAP)[11]と共に使用される[9])はメールされます、ネットニュース、ウェブページ、など

Ott & Carrara               Standards Track                     [Page 6]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[6ページ]。

   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.

申し出/答えモデルは、結果として起こるセッションパラメタが交渉されるのをRFC4567[7]とRFC4568[8]で定義されたSDP属性を使用することで許容します。 以下の小区分では、交渉プロセスは申し出/答えモデルで説明されます。

   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.

その後、申し出/答えモデルを使用しないケースは扱われます: セクション3.3.2で議論するRFC4567[7]でRTSP特有の交渉サポートを提供します、そして、セクション3.3.3でSAP発表(全く交渉のない)のサポートを扱います。

3.3.1.  Offer/Answer-Based Negotiation of Session Descriptions

3.3.1. セッション記述の答え申し出/ベースの交渉

   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プロフィール、コーデック、輸送アドレスなどの)が1メディアあたり1個のセッションベース(例えば、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を見てください)。 また、申し出/答えメカニズムは、同じメディアセッションのために代替手段を申し出て、answererがプロフィールの1つを選ぶのを許容するのに使用されるかもしれません。

   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])、できる申出人の下でSHOULDがいつもある状況で許容できるすべての選択肢を提供するあるメディアセッションのためにこれらのプロフィールの1つ以上をサポートするのにおいてそのままです。 代替手段SHOULDは好みの順にリストアップされていて、プロフィールを固定します申出人SHOULDが、好む。非安全なものの上で。 これが入札している下であるのと他の攻撃を可能にするとき、申し出SHOULD NOTは安全な代替手段(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.

申し出が複数の代替のプロフィールを含んでいるなら、answerer SHOULDは非安全なものより安全なプロフィール(サポートされるなら)を好みます。 安全であるか不安定なプロフィールの中では、answerer SHOULDは、申出人の好みを尊敬するために最初の受け入れられる代案を選択します。

   If a media description in an offer uses SAVPF and the answerer does
   not support SAVPF, the media session MUST be rejected.

申し出におけるメディア記述がSAVPFを使用して、answererがSAVPFをサポートしないなら、メディアセッションを拒絶しなければなりません。

Ott & Carrara               Standards Track                     [Page 7]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[7ページ]。

   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を使用しませんが、answererがSAVPFを使用したいと思うなら、answererはメディアセッションを拒絶しなければなりません。 answererは次に開始している申し出/答え交換でSAVPFを示すメディア記述を買申込みに提供するかもしれません。

3.3.2.  RTSP-Based Negotiation of Session Descriptions

3.3.2. セッション記述のRTSPベースの交渉

   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は、Transportヘッダーによって交換がメディアセッションパラメタ(プロフィールとアドレス情報を含んでいる)であるとサポートします。 RFC4567[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 Transportヘッダーは、メディアセッションのためのプロフィールを決定するのに使用されるかもしれません。 概念的に、セクション3.3.1で定義された規則はそれに従って、適用されます。 詳細な操作は以下の通りです: SDP記述(例えば、RTSPサーバから、DESCRIBEによって、検索される)は特定の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つを選択しなければなりません。 それはSETUP要求でそうしなければなりません。 RTSPクライアントは、SETUP要求にTransportヘッダーの輸送アドレス(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.

以下に注意してください。 使用中のプロフィールのどれかを変えるために、クライアントは、TEARDOWNメソッドを使用することでこのメディアストリーム(そして、ことによると全体のRTSPセッション)を取りこわして、SETUPを使用することでそれを復職させる必要があります。 メディアアップデート(SIP UPDATEか再INVITEと同様の)が指定されるようになるとすぐに、これは変化するかもしれません。

   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]を使用するとき、安全なプロフィールが選ばれているなら、適切なRTSPメッセージにKeyMgmtヘッダーを含まなければなりません。 SDP記述(例えば、SAVPとSAVPF)で異なった安全なプロフィールを提供して、異なった合わせることの材料をこれらに提供するなら、SETUPメッセージの1個のプロフィールを選んだ後に、選ばれたもののためのKeyMgmtヘッダーだけを提供しなければなりません。 RFC4567[7]によると、KeyMgmtヘッダーをメディアストリームに合わせるための規則は適用されます。

Ott & Carrara               Standards Track                     [Page 8]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[8ページ]。

3.3.3.  Announcing Session Descriptions

3.3.3. セッション記述を発表します。

   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.

創始者SHOULDはアプリケーションに許容できるのと同じくらい遠いプロフィールとセッションの目的を複数のRTPのための代替のセッション記述に提供します。 セキュリティを望んでいるなら、代替手段としてSAVPF but AVPかAVPFセッションSHOULD NOTにSAVPを提供するかもしれません。他のセキュリティが、使われたSRTPを当てにすることを意味しない場合、発表してください。

   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.

また、RFC4567[7]とRFC4568[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.

RFC4568[8]で定義されたセキュリティ体系記述は、第三者が安全なコミュニケーションチャンネルによって合わせるパラメタと操作を立ち聞きできないのを必要とします。 したがって、SAPセキュリティ、(分配に中古の、または、アクセスしているこれらがセッション記述であったならRFC2974[11])、S/MIME[12]、HTTPS[13]、または他の適当なメカニズムSHOULDで定義されるように。

3.3.4.  Describing Alternative Session Profiles

3.3.4. 代替のセッションプロフィールについて説明します。

   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を見る)、そのように、MAY 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セッションの向こう側に任意に混ぜられるかもしれません。

Ott & Carrara               Standards Track                     [Page 9]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[9ページ]。

3.4.  Examples

3.4. 例

   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の使用が安全で非安全なプロフィールの使用を交渉するように、このセクションは例を含んでいます。 どんな合わせるメカニズムによるかが、使用されて、どうparameterizedしたかということであり、SDPメッセージは、保全保護を通常必要として、また、いくつかのメカニズムに秘密性保護を必要とするでしょう。 例えば、人は、保全保護がデータグラムTransport Layer Securityのa=指紋に必要であると言うことができました--レアル-時間Transportプロトコル(DTLS-SRTP)が[16]であると機密保護してください。そうすれば、秘密性がRFC4568[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ストリームがGeneric NACKsを使用する二地点間コミュニケーションのためにオーディオの、そして、二元的なトーン多重周波数(DTMF)を作ったのを示します。 示されたかぎ管理プロトコルはマイキーです。 SIP INVITEか送付者が、それが伝えるDTMFストリームにおいてできて反響を調べても構わないと思っているのを示す200OKメッセージにこのセッション記述(申し出)を含むことができました。 対応する答えは200OKかACKで運ばれるかもしれません。 セキュリティプロトコルのためのパラメタはRFC4567[7]で定義されたSDP拡張子で説明されるように交渉されます。

      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 o=alice3203093520 3203093520IN IP4 host.example.com sがオーディオの49170 0 0c=IN IP4 host.example.comフィードバックt=m=RTP/SAVPFと共にメディアと等しい、0、96a=rtpmap、: 0 PCMU/8000a=rtpmap: 96 電話イベント/8000a=fmtp: 96 0-16a=rtcp-fb: 96 nack aは主要な管理と等しいです: 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=暗号属性の主要な部分が盗聴に対して保護されないで、その結果、セッション記述が、安全な通信チャネルの上と交換される必要に注意してください。

      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

v=0 o=alice3203093520 3203093520IN IP4 host.example.com sがオーディオの49170 0 0c=IN IP4 host.example.comフィードバックt=m=RTP/SAVPFと共にメディアと等しい、0、96a=rtpmap、: 0PCMU/8000

Ott & Carrara               Standards Track                    [Page 10]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[10ページ]。

      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

a=rtpmap: 96電話イベント/8000a=fmtp: 96 0-16a=rtcp-fb: 96nack 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から上に模写されますが、申出人とanswererとの相互作用を示しています、合わせることの材料を交渉するのに再びマイキーを使用して:

      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

v=0 o=alice3203093520 3203093520IN IP4 host.example.com sは主要なIN IP4 host.example.comフィードバックt=0 0c=a=管理でメディアと等しいです: mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD…mがオーディオの49170RTP/SAVPFと等しい、0、96a=rtpmap、: 0PCMU/8000a=rtpmap: 96電話イベント/8000a=fmtp: 96 0-16a=rtcp-fb: 96nack

      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

v=0 o=alice3203093521 3203093521IN IP4 host.another.example.com sは主要なIN IP4 host.another.example.comフィードバックt=0 0c=a=管理でメディアと等しいです: mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD…mがオーディオの53012RTP/SAVPFと等しい、0、96a=rtpmap、: 0PCMU/8000a=rtpmap: 96電話イベント/8000a=fmtp: 96 0-16a=rtcp-fb: 96nack

   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要求を出します。

Ott & Carrara               Standards Track                    [Page 11]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[11ページ]。

   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.

そして、Transportパラメタにそれぞれのプロフィールを含んでいることによって、選択を示します。 その上、クライアントは、セキュリティパラメタを伝えるためにKeyMgmtヘッダーを入れます(対応するKeyMgmtヘッダーによって応答におけるサーバから合われています)。 ただ一つのメディアセッションが選ばれているので、集合RTSP URIは識別だけに十分です。

      RTSP DESCRIBE request-response pair (optional):

RTSP DESCRIBE要求応答組(任意の):

      DESCRIBE rtsp://movies.example.org/example RTSP/2.0
      CSeq: 314
      Accept: application/sdp

DESCRIBE rtsp://movies.example.org/例のRTSP/2.0CSeq: 314 受け入れます: アプリケーション/sdp

      200 OK
      CSeq: 314
      Date: 25 Nov 2005 22:09:35 GMT
      Content-Type: application/sdp
      Content-Length: 316

200 CSeqを承認してください: 314 日付: 2005年11月25日のグリニッジ標準時22時9分35秒のコンテントタイプ: sdp Contentアプリケーション/長さ: 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                |
     +---------------------------------+

v=0 o=alice3203093520 3203093520IN IP4 movies.example.com sは0 0c=IN IP4 0.0.0.0+代替手段フィードバックt=1でメディアと等しいです。-----------------+ |mはビデオ49170RTP/SAVPF96と等しいです。| |a=rtpmap: 96H263-2000/90000| |a=rtcp-fb: 96nack| +---------------------------------+ +代替手段2-----------------+ |mはビデオ49172RTP/AVPF96と等しいです。| |a=rtpmap: 96H263-2000/90000| |a=rtcp-fb: 96nack| +---------------------------------+

      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://movies.example.org/例のRTSP/2.0CSeq: 315 輸送: 「RTP/SAVPF; ユニキャスト; dest_addrは」 : 53012インチ/と等しい」: 53013インチKeyMgmt: prot=mikey; urlは「rtsp://movies.example.org/例」と等しいです。 データは"uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD"と等しいです…

      200 OK
      CSeq: 315
      Date: 25 Nov 2005 22:09:36 GMT
      Session: 4711

200 CSeqを承認してください: 315 日付: 2005年11月25日のグリニッジ標準時22時9分36秒のセッション: 4711

Ott & Carrara               Standards Track                    [Page 12]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[12ページ]。

      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

輸送: 「RTP/SAVPF; ユニキャスト; dest_addrは」 : 53012インチ/と等しい」: 53013インチ src_addrが等しい、「192.0、.2、.15:60000、」 /、「192.0 .2 .15:60001 」 KeyMgmt: prot=mikey; urlは「rtsp://movies.example.org/例」と等しいです。 データは"ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD"と等しいです… 範囲を受け入れます: 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のためのコーデックとReference Picture Selectionの両方のためにGeneric NACKsを受け入れるビデオソースとのマルチキャストオーディオ/ビデオセッション(オーディオとH.261かH.263+のどちらかにPCMUを使用する)を示します。 セキュリティプロトコルのためのパラメタはRFC4567[7]で定義されたSDP拡張子で説明されるように交渉されます、セッションレベルでは、使用されています。 そのような記述は、Session Announcementプロトコル(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 o=alice3203093520 3203093520IN IP4 host.example.com s=マルチキャストビデオは=キー管理あたり3203130148 3203137348と等しいです: mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD…mがオーディオの49170RTP/SAVPと等しい、0、c、=IN IP4 224.2.1.183a=rtpmap: 0PCMU/8000mがビデオ51372RTP/SAVPFと等しい、98 99、c、=IN IP4 224.2.1.184a=rtpmap: 98H263-1998/90000 a=rtpmap: 99H261/90000 a=rtcp-fb: *nack a=rtcp-fb: 98nack rpsi

4.  Interworking of AVP, SAVP, AVPF, and SAVPF Entities

4. AVP、SAVP、AVPF、およびSAVPF実体を織り込むこと

   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]の組み合わせです。(順番に、RTPプロフィールの拡大がRFC3551[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は、安定を得るのにSRTP[4]を使用します。 AVPとAVPFは明瞭なRTP[1]を使用して、したがって、セキュリティを提供しません。(対外安全保障メカニズムがRFC3550[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を使用するRTP実体とSAVPFプロフィールはただ一つのRTPセッションのときに複雑であるかもしれません。 RFC4585[3]のセクション5で定義された織り込む問題は適用されます。

Ott & Carrara               Standards Track                    [Page 13]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[13ページ]。

5.  Security Considerations

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プロフィールからセキュリティの特性を引き継ぎます。 したがって、それはRFC3711[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].

アプリケーション設計者はセキュリティSHOULD NOTが相互運用性のために取り引きされるのを意識しているべきです。 情報が封鎖グループ(すなわち、秘密に保護される)に分配されることであるなら、それはSAVPとSAVPF以外のメディアセッションのためにセクション3.3と3.4で説明されるように代替手段を提供しないRECOMMENDEDです、他のセキュリティー対策が使用されないなら、例えばRFC3550[1]のセクション9.1で説明されたもの。 保全保護が重要であると考えられるなら、同様に、それがSAVPとSAVPF以外の代替手段を提供しないRECOMMENDEDである、他のメカニズムが適所にあるのが知られない場合、それはそれを保証できます、例えばRFC3550[1]のセクション9で説明される下層メカニズム。

   Offering secure and insecure profiles simultaneously may open to
   bidding down attacks.  Therefore, such a mix of profile offer SHOULD
   NOT be made.

同時に安全で不安定なプロフィールを提供するのは攻撃の下側に入札するのに開くかもしれません。 したがって、プロフィールのそのようなミックスはSHOULD NOTを提供します。作られています。

   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.

マスターキーを共有するための規則がRFC3711[4](例えば、セクション9.1)で説明されるように適用されることに注意してください。 特に、二度のパッド(keystream再利用)を避けるための同じ規則は適用されます: 使用される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パケットを安全にしたとき(どれが以前起こっても)、新しいマスターキーを提供するためにかぎ管理が召集しなければなりませんか(再び以前、格納されて、中古のキーを使用してはいけません)、またはセッションを終えなければなりません。

   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.

異なったメディアセッションは特に安全なプロフィールと不安定なプロフィールを含む異なったプロフィールのミックスを使用するかもしれません。 しかしながら、混合の安全で不安定なメディアセッションは第三者に情報を明らかにするかもしれません、そして、その結果、ローカルの安全保障政策に沿ってそうするという決定があるに違いありません。 例えば、ローカルの方針は、それが持つのにおいて許容できるかどうか指定しなければなりません、と例えば、オーディオストリームが安全にしないで、関連するビデオは安全にしました。

Ott & Carrara               Standards Track                    [Page 14]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[14ページ]。

   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.

また、RFC4585[3]のセキュリティ問題は有効です。 SAVPFプロフィールを適用すると特に、義務的な保全保護がRTCPで含意されることに注意してください。 これがメンバーからの偽のパケットがグループのものないという問題を解決している間、それは不適切に行動している悪意があるメンバーと関係がある問題を解決しません。

6.  IANA Considerations

6. IANA問題

   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 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".

Secure RTPの組み合わせとしての安全なRTPフィードバックプロフィールとフィードバックプロフィールはSession記述プロトコルのために登録されました(明確にタイプ"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は形成します: 名前のRTCPベースのFeedback Typeと共にRTP Profileを固定してください: 属性のproto Type: メディアはPurposeだけを平らにします: RFC5124参照: RFC5124

   All the SDP attributes defined for RTP/SAVP and RTP/AVPF are valid
   for RTP/SAVPF, too.

RTP/SAVPFにも、RTP/SAVPとRTP/AVPFのために定義されたすべてのSDP属性が有効です。

7.  Acknowledgements

7. 承認

   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のAudio視覚のTransport(AVT)作業部会の製品です。 作者は彼らのコメントについてマグヌスWesterlund、コリン・パーキンス、およびCullenジョニングスに感謝したがっています。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。

Ott & Carrara               Standards Track                    [Page 15]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[15ページ]。

   [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.、バーマイスター、C.、およびJ.レイは「リアルタイムの輸送制御プロトコル(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.

2004年の[4]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。

   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [6]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

[6] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、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.、ジーター、M.、Norrman、K.、およびE.カラーラ、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。

   [8]  Andreasen, F., Baugher, M., and D. Wing, "Session Description
        Protocol (SDP) Security Descriptions for Media Streams", RFC
        4568, July 2006.

Andreasen、F.、Baugher、M.、およびD.が翼をつけさせる[8]、「メディアの流れのためのセッション記述プロトコル(SDP)セキュリティ記述」、RFC4568(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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

   [10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

1998年4月の[10]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。

8.2.  Informative References

8.2. 有益な参照

   [11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
        Protocol", RFC 2974, October 2000.

[11] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、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は仕様を通信する」RFC3851、7月2004日

   [13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[13] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。

   [14] Andreasen, F., "SDP Capability Negotiation", Work in Progress,
        December 2007.

[14] F.、「SDP能力交渉」というAndreasenは進歩、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

Ott & Carrara               Standards Track                    [Page 16]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[16ページ]。

   [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] E.、「安全なリアルタイムのトランスポート・プロトコル(SRTP)のためにキーを設立するデータグラムトランスポート層セキュリティ(DTLS)拡大」というマグリュー、D.、およびレスコラは進行中(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

Elisabettaカラーラの王立の工科大学ストックホルムスウェーデン

   EMail: carrara@kth.se

メール: carrara@kth.se

Ott & Carrara               Standards Track                    [Page 17]

RFC 5124                                                   February 2008

オットとカラーラ規格は2008年2月にRFC5124を追跡します[17ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Ott & Carrara               Standards Track                    [Page 18]

オットとカラーラ標準化過程[18ページ]