[要約] RFC 5939は、SDPの能力交渉に関するプロトコルであり、SDPメッセージの拡張と交換を可能にする。目的は、セッションの参加者間でのメディア機能の交渉と互換性の確保を容易にすることである。
Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5939 Cisco Systems
Category: Standards Track September 2010
ISSN: 2070-1721
Session Description Protocol (SDP) Capability Negotiation
セッション説明プロトコル（SDP）機能交渉
Abstract
概要
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.
セッション説明プロトコル（SDP）は、セッションの発表、セッションの招待状、およびその他の形式のマルチメディアセッション開始の目的でマルチメディアセッションを説明することを目的としています。SDPは、機能の兆候または能力交渉を提供することを意図していませんでした。しかし、長年にわたり、SDPは広範な採用を見てきました。その結果、特にRFC 3264で定義されたオファー/回答モデルの形で、これらの限定的なサポートを提供するために徐々に拡張されました。SDPは1つを交渉する方法を定義しません。または、より多くの代替輸送プロトコル（RTPプロファイルなど）または属性。これにより、RTCPベースのフィードバックを使用してSecure RTPやRTPなどの新しいRTPプロファイルを展開すること、さまざまなセキュリティキーイングメカニズムの使用などを展開することが困難になります。
The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.
このドキュメントの目的は、SDPを能力交渉パラメーターと関連するオファー/回答手順を拡張して、これらのパラメーターを逆方向に互換性のある方法で使用することにより、これらの欠点に対処することです。
The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents.
このドキュメントは、一般的なSDP機能交渉フレームワークを定義しています。また、属性と輸送プロトコルを機能として提供し、フレームワークを使用して交渉する方法を指定します。他のタイプの機能（メディアタイプやメディア形式など）の拡張は、他のドキュメントで提供される場合があります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5939.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5939で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................7
3. SDP Capability Negotiation Solution .............................7
3.1. SDP Capability Negotiation Model ...........................7
3.2. Solution Overview .........................................10
3.3. Version and Extension Indication Attributes ...............14
3.4. Capability Attributes .....................................17
3.5. Configuration Attributes ..................................22
3.6. Offer/Answer Model Extensions .............................32
3.7. Interactions with ICE .....................................45
3.8. Interactions with SIP Option Tags .........................47
3.9. Processing Media before Answer ............................48
3.10. Indicating Bandwidth Usage ...............................49
3.11. Dealing with Large Number of Potential Configurations ....50
3.12. SDP Capability Negotiation and Intermediaries ............51
3.13. Considerations for Specific Attribute Capabilities .......52
3.14. Relationship to RFC 3407 .................................54
4. Examples .......................................................54
4.1. Multiple Transport Protocols ..............................54
4.2. DTLS-SRTP or SRTP with Media-Level Security Descriptions...58
4.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level
Security Descriptions .....................................61
4.4. SRTP with Session-Level MIKEY and Media-Level Security
Descriptions as Alternatives ..............................66
5. Security Considerations ........................................69
6. IANA Considerations ............................................72
6.1. New SDP Attributes ........................................72
6.2. New SDP Capability Negotiation Option Tag Registry ........73
6.3. New SDP Capability Negotiation Potential
Configuration Parameter Registry ..........................74
7. Acknowledgments ................................................74
8. References .....................................................75
8.1. Normative References ......................................75
8.2. Informative References ....................................75
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. An SDP session description contains one or more media stream descriptions with information such as IP address and port, type of media stream (e.g., audio or video), transport protocol (possibly including profile information, e.g., RTP/AVP or RTP/SAVP), media formats (e.g., codecs), and various other session and media stream parameters that define the session.
セッション説明プロトコル（SDP）は、セッションの発表、セッションの招待状、およびその他の形式のマルチメディアセッション開始の目的でマルチメディアセッションを説明することを目的としています。SDPセッションの説明には、IPアドレスやポート、メディアストリームの種類（オーディオまたはビデオなど）、トランスポートプロトコルなどの情報を含む1つ以上のメディアストリーム説明が含まれています（おそらくプロファイル情報など、RTP/AVPまたはRTP/SAVPなど）、メディア形式（コード科）、およびセッションを定義する他のさまざまなセッションおよびメディアストリームパラメーター。
Simply providing media stream descriptions is sufficient for session announcements for a broadcast application, where the media stream parameters are fixed for all participants. When a participant wants to join the session, he obtains the session announcement and uses the media descriptions provided, e.g., joins a multicast group and receives media packets in the encoding format specified. If the media stream description is not supported by the participant, he is unable to receive the media.
メディアストリームの説明を提供するだけでは、すべての参加者にメディアストリームパラメーターが修正されているブロードキャストアプリケーションのセッションアナウンスに十分です。参加者がセッションに参加したい場合、セッションの発表を取得し、提供されたメディアの説明を使用します。たとえば、マルチキャストグループに参加し、指定されたエンコード形式のメディアパケットを受け取ります。メディアストリームの説明が参加者によってサポートされていない場合、彼はメディアを受け取ることができません。
Such restrictions are not generally acceptable to multimedia session invitations, where two or more entities attempt to establish a media session, that uses a set of media stream parameters acceptable to all participants. First of all, each entity must inform the other of its receive address, and secondly, the entities need to agree on the media stream parameters to use for the session, e.g., transport protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the offer/answer model, whereby an offerer constructs an offer SDP session description that lists the media streams, codecs, and other SDP parameters that the offerer is willing to use. This offer session description is sent to the answerer, which chooses from among the media streams, codecs and other session description parameters provided, and generates an answer session description with his parameters, based on that choice. The answer session description is sent back to the offerer thereby completing the session negotiation and enabling the establishment of the negotiated media streams.
このような制限は、2つ以上のエンティティがすべての参加者に受け入れられるメディアストリームパラメーターのセットを使用するメディアセッションの確立を試みるマルチメディアセッションの招待状には一般に受け入れられません。まず、各エンティティは他のエンティティに受信アドレスを通知する必要があります。第二に、エンティティはセッションに使用するメディアストリームパラメーター、たとえば輸送プロトコルやコーデックに同意する必要があります。これを解決するために、RFC 3264 [RFC3264]はオファー/回答モデルを定義しました。このオファーセッションの説明は、メディアストリーム、コーデック、および提供されたその他のセッションの説明パラメーターの中から選択され、その選択に基づいて彼のパラメーターで回答セッションの説明を生成します。回答セッションの説明は提供者に送り返され、それによりセッションの交渉を完了し、交渉されたメディアストリームの確立を可能にします。
Taking a step back, we can make a distinction between the capabilities supported by each participant, the way in which those capabilities can be supported, and the parameters that can actually be used for the session. More generally, we can say that we have the following:
一歩後退すると、各参加者がサポートする機能、それらの機能をサポートできる方法、およびセッションに実際に使用できるパラメーターを区別できます。より一般的には、次のことがあると言えます。
o A set of capabilities for the session and its associated media stream components, supported by each side. The capability indications by themselves do not imply a commitment to use the capabilities in the session.
o セッションとそれに関連するメディアストリームコンポーネントの一連の機能は、各側でサポートされています。能力の兆候自体は、セッションで機能を使用するというコミットメントを意味するものではありません。
Capabilities can, for example, be that the "RTP/SAVP" profile is supported, that the "PCMU" (Pulse Code Modulation mu-law) codec is supported, or that the "crypto" attribute is supported with a particular value.
たとえば、「RTP/SAVP」プロファイルがサポートされていること、「PCMU」（Pulse Code Mu-Law）コーデックがサポートされていること、または「暗号」属性が特定の値でサポートされていることがサポートされていることがあります。
o A set of potential configurations indicating which combinations of those capabilities can be used for the session and its associated media stream components. Potential configurations are not ready for use. Instead, they provide an alternative that may be used, subject to further negotiation.
o セッションとそれに関連するメディアストリームコンポーネントに使用できるこれらの機能の組み合わせを示す潜在的な構成のセット。潜在的な構成は使用できません。代わりに、彼らはさらなる交渉の対象となる、使用される可能性のある代替手段を提供します。
A potential configuration can, for example, indicate that the "PCMU" codec and the "RTP/SAVP" transport protocol are not only supported (i.e., listed as capabilities), but they are offered for potential use in the session.
たとえば、潜在的な構成は、「PCMU」コーデックと「RTP/SAVP」トランスポートプロトコルがサポートされている（つまり、機能としてリストされている）だけでなく、セッションでの潜在的な使用のために提供されていることを示しています。
o An actual configuration for the session and its associated media stream components, that specifies which combinations of session parameters and media stream components can be used currently and with what parameters. Use of an actual configuration does not require any further negotiation.
o セッションとそれに関連するメディアストリームコンポーネントの実際の構成。セッションパラメーターとメディアストリームコンポーネントの組み合わせを現在、どのパラメーターで使用できるかを指定します。実際の構成を使用しても、それ以上の交渉は必要ありません。
An actual configuration can, for example, be that the "PCMU" codec and the "RTP/SAVP" transport protocol are offered for use currently.
たとえば、実際の構成は、「PCMU」コーデックと「RTP/SAVP」トランスポートプロトコルが現在使用するために提供されていることです。
o A negotiation process that takes the set of actual and potential configurations (combinations of capabilities) as input and provides the negotiated actual configurations as output.
o 実際の構成と潜在的な構成のセット（機能の組み合わせ）を入力として取得し、交渉された実際の構成を出力として提供するネゴシエーションプロセス。
SDP by itself was designed to provide only one of these, namely listing of the actual configurations; however, over the years, use of SDP has been extended beyond its original scope. Of particular importance are the session negotiation semantics that were defined by the offer/answer model in RFC 3264. In this model, both the offer and the answer contain actual configurations; separate capabilities and potential configurations are not supported.
SDP自体は、これらのいずれか、つまり実際の構成のリストのみを提供するように設計されています。ただし、長年にわたって、SDPの使用は元の範囲を超えて拡張されてきました。特に重要なのは、RFC 3264のオファー/回答モデルによって定義されたセッション交渉セマンティクスです。このモデルでは、オファーと回答の両方に実際の構成が含まれています。個別の機能と潜在的な構成はサポートされていません。
Other relevant extensions have been defined as well. RFC 3407 [RFC3407] defined simple capability declarations, which extends SDP with a simple and limited set of capability descriptions. Grouping of media lines, which defines how media lines in SDP can have other semantics than the traditional "simultaneous media streams" semantics, was defined in RFC 5888 [RFC5888], etc.
他の関連する拡張機能も定義されています。RFC 3407 [RFC3407]は、シンプルで限られた機能の説明でSDPを拡張する単純な機能宣言を定義しました。SDPのメディアラインが従来の「同時メディアストリーム」セマンティクス以外のセマンティクスを持つ方法を定義するメディアラインのグループ化は、RFC 5888 [RFC5888]などで定義されていました。
Each of these extensions was designed to solve a specific limitation of SDP. Since SDP had already been stretched beyond its original intent, a more comprehensive capability declaration and negotiation process was intentionally not defined. Instead, work on a "next generation" of a protocol to provide session description and capability negotiation was initiated [SDPng]. SDPng defined a comprehensive capability negotiation framework and protocol that was not bound by existing SDP constraints. SDPng was not designed to be backwards compatible with existing SDP and hence required both sides to support it, with a graceful fallback to legacy operation when needed. This, combined with lack of ubiquitous multipart MIME support in the protocols that would carry SDP or SDPng, made it challenging to migrate towards SDPng. In practice, SDPng has not gained traction and, as of the time of publication of this document, work on SDPng has stopped. Existing real-time multimedia communication protocols such as SIP, Real Time Streaming Protocol (RTSP), Megaco, and Media Gateway Control Protocol (MGCP) continue to use SDP. However, SDP does not address an increasingly important problem: the ability to negotiate one or more alternative transport protocols (e.g., RTP profiles) and associated parameters (e.g., SDP attributes). This makes it difficult to deploy new RTP profiles such as Secure RTP (SRTP) [RFC3711], RTP with RTCP-based feedback [RFC4585], etc. The problem is exacerbated by the fact that RTP profiles are defined independently. When a new profile is defined and N other profiles already exist, there is a potential need for defining N additional profiles, since profiles cannot be combined automatically. For example, in order to support the plain and Secure RTP version of RTP with and without RTCP-based feedback, four separate profiles (and hence profile definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF [RFC5124]. In addition to the pressing profile negotiation problem, other important real-life limitations have been found as well. Keying material and other parameters, for example, need to be negotiated with some of the transport protocols, but not others. Similarly, some media formats and types of media streams need to negotiate a variety of different parameters.
これらの各拡張機能は、SDPの特定の制限を解決するように設計されています。SDPはすでに当初の意図を超えて伸びていたため、より包括的な能力宣言と交渉プロセスは意図的に定義されていませんでした。代わりに、プロトコルの「次世代」に取り組んで、セッションの説明と能力交渉が開始されました[SDPNG]。SDPNGは、既存のSDP制約に拘束されていない包括的な能力交渉フレームワークとプロトコルを定義しました。SDPNGは、既存のSDPとの逆方向に互換性があるように設計されていなかったため、必要に応じてレガシー操作への優雅なフォールバックを使用して、両側にそれをサポートする必要がありました。これは、SDPまたはSDPNGを搭載するプロトコルでのユビキタスマルチパートMIMEサポートの欠如と組み合わされて、SDPNGに移行するのが難しくなりました。実際には、SDPNGは牽引力を獲得しておらず、このドキュメントの公開時点で、SDPNGでの作業が停止しました。SIP、リアルタイムストリーミングプロトコル（RTSP）、メガコ、メディアゲートウェイ制御プロトコル（MGCP）などの既存のリアルタイムマルチメディア通信プロトコルは、SDPを使用し続けています。ただし、SDPはますます重要な問題に対処しません。1つ以上の代替輸送プロトコル（RTPプロファイルなど）と関連するパラメーター（SDP属性など）を交渉する能力です。これにより、Secure RTP（SRTP）[RFC3711]、RTCPベースのフィードバック[RFC4585]などのRTPなどの新しいRTPプロファイルを展開することが困難になります。問題は、RTPプロファイルが独立して定義されているという事実によって悪化します。新しいプロファイルが定義され、他のプロファイルが既に存在する場合、プロファイルを自動的に組み合わせることができないため、N追加プロファイルを定義する潜在的な必要性があります。たとえば、RTCPベースのフィードバックを伴うまたは使用せずにRTPのプレーンで安全なRTPバージョンをサポートするために、4つの個別のプロファイル（およびプロファイル定義）が必要です。RTP/AVP [RFC3551]、RTP/SAVP [RFC3711]、RTP/AVPF [RFC4585]、およびRTP/SAVPF [RFC5124]。迫りつつあるプロファイル交渉の問題に加えて、他の重要な現実の制限も同様に発見されています。たとえば、キーイング素材やその他のパラメーターは、一部の輸送プロトコルと交渉する必要がありますが、他の輸送プロトコルと交渉する必要があります。同様に、一部のメディア形式やメディアストリームの種類は、さまざまなパラメーターを交渉する必要があります。
The purpose of this document is to define a mechanism that enables SDP to provide limited support for indicating capabilities and their associated potential configurations, and negotiate the use of those potential configurations as actual configurations. It is not the intent to provide a full-fledged capability indication and negotiation mechanism along the lines of SDPng or ITU-T H.245. Instead, the focus is on addressing a set of well-known real-life limitations. More specifically, the solution provided in this document provides a general SDP Capability Negotiation framework that is backwards compatible with existing SDP. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and formats) may be provided in other documents.
このドキュメントの目的は、SDPが機能とそれに関連する潜在的な構成を示すための限定的なサポートを提供できるメカニズムを定義し、それらの潜在的な構成の使用を実際の構成として交渉することです。SDPNGまたはITU-T H.245のラインに沿って、本格的な機能の表示と交渉メカニズムを提供することは意図ではありません。代わりに、有名な現実の制限のセットに対処することに焦点が当てられています。より具体的には、このドキュメントで提供されるソリューションは、既存のSDPと互換性のある一般的なSDP機能交渉フレームワークを提供します。また、属性を機能として提供し、フレームワークを使用して交渉する属性と輸送プロトコルを提供する方法を具体的に定義します。他のタイプの機能（メディアタイプや形式など）の拡張機能は、他のドキュメントで提供される場合があります。
As mentioned above, SDP is used by several protocols, and hence the mechanism should be usable by all of these. One particularly important protocol for this problem is the Session Initiation Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] (which is not specific to SIP) to negotiate sessions and hence the mechanism defined here provides the offer/answer procedures to use for the capability negotiation framework.
上記のように、SDPはいくつかのプロトコルで使用されているため、メカニズムはこれらすべてで使用できるはずです。この問題の特に重要なプロトコルの1つは、セッション開始プロトコル（SIP）[RFC3261]です。SIPは、オファー/回答モデル[RFC3264]（SIPに固有のものではない）を使用してセッションを交渉するため、ここで定義されているメカニズムは、機能交渉フレームワークに使用するオファー/回答手順を提供します。
The rest of the document is structured as follows. In Section 3, we present the SDP Capability Negotiation solution, which consists of new SDP attributes and associated offer/answer procedures. In Section 4, we provide examples illustrating its use. In Section 5, we provide the security considerations.
ドキュメントの残りの部分は次のように構成されています。セクション3では、新しいSDP属性と関連するオファー/回答手順で構成されるSDP機能交渉ソリューションを提示します。セクション4では、その使用を示す例を示します。セクション5では、セキュリティ上の考慮事項を提供します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In this section, we first present the conceptual model behind the SDP Capability Negotiation framework followed by an overview of the SDP Capability Negotiation solution. We then define new SDP attributes for the solution and provide its associated updated offer/answer procedures.
このセクションでは、最初にSDP機能交渉フレームワークの背後にある概念モデルを、続いてSDP機能交渉ソリューションの概要を示します。次に、ソリューションの新しいSDP属性を定義し、関連する更新されたオファー/回答手順を提供します。
Our model uses the concepts of
私たちのモデルはの概念を使用しています
o Capabilities
o 機能
o Potential Configurations
o 潜在的な構成
o Actual Configurations
o 実際の構成
o Negotiation Process
o 交渉プロセス
as defined in Section 1. Conceptually, we want to offer not just the actual configuration SDP session description (which is done with the offer/answer model defined in [RFC3264]), but the actual configuration SDP session description as well as one or more alternative SDP session descriptions, i.e., potential configurations. The answerer must choose either the actual configuration or one of the potential configurations, and generate an answer SDP session description based on that. The offerer may need to perform processing on the answer, which depends on the offer that was chosen (actual or potential configuration). The answerer therefore informs the offerer which configuration the answerer chose. The process can be viewed *conceptually* as follows:
セクション1で定義されているように、概念的には、実際の構成SDPセッションの説明（[RFC3264]で定義されているオファー/回答モデルで行われる）だけでなく、実際の構成SDPセッションの説明と1つ以上も提供するだけでなく、1つ以上を提供する必要があります。代替SDPセッションの説明、つまり潜在的な構成。回答者は、実際の構成または潜在的な構成のいずれかを選択し、それに基づいて回答SDPセッションの説明を生成する必要があります。オファーは、選択されたオファー（実際の構成または潜在的な構成）に依存する回答で処理を実行する必要がある場合があります。したがって、回答者は、応募者にどのような構成を選択したかを通知します。プロセスは、次のように *概念的に *見ることができます。
Offerer Answerer
======= ========
1) Generate offer with actual configuration and alternative potential configurations 2) Send offer with all configurations
1) 実際の構成と代替の潜在的な構成を備えたオファーを生成する2）すべての構成でオファーを送信する
+------------+
| SDP o1 |
| (actual |
| config |
| |-+ Offer
+------------+ | -----> 3) Process offered configurations
| SDP o2 | in order of preference indicated
| (potential | 4) Generate answer based on chosen
| config 1) |-+ configuration (e.g., o2), and
+------------+ | inform offerer which one was
| SDP o3 | chosen
| (potential |
| config 2) |-+
+------------+ |
| SDP ... |
: :
+------------+
| SDP a1 |
Answer | (actual |
<----- | config,o2)|
| |
5) Process answer based on +------------+
the configuration that was
chosen (o2), as indicated in
the answer
The above illustrates the conceptual model: the actual solution uses a single SDP session description, which contains the actual configuration (as with existing SDP session descriptions and the offer/answer model defined in [RFC3264]) and several new attributes and associated procedures, that encode the capabilities and potential configurations. A more accurate depiction of the actual offer SDP session description is therefore as follows:
上記は概念モデルを示しています。実際のソリューションは、実際の構成（既存のSDPセッションの説明と[RFC3264]で定義されているオファー/回答モデルと同様に）といくつかの新しい属性と関連手順を含む単一のSDPセッション説明を使用します。機能と潜在的な構成をエンコードします。したがって、実際のオファーSDPセッションの説明のより正確な描写は次のとおりです。
+--------------------+
| SDP o1 |
| (actual |
| config |
| |
| +-------------+ |
| | capability 1| |
| | capability 2| |
| | ... | |
| +-------------+ | Offer
| | ----->
| +-------------+ |
| | potential | |
| | config 1 | |
| | potential | |
| | config 2 | |
| | ... | |
| +-------------+ |
| |
+--------------------+
The above structure is used for two reasons:
上記の構造は、2つの理由で使用されます。
o Backwards compatibility: As noted above, support for multipart MIME is not ubiquitous. By encoding both capabilities and potential configurations in SDP attributes, we can represent everything in a single SDP session description thereby avoiding any multipart MIME support issues. Furthermore, since unknown SDP attributes are ignored by the SDP recipient, we ensure that entities that do not support the framework simply perform the regular RFC 3264 offer/answer procedures. This provides us with seamless backwards compatibility.
o 後方互換性：上記のように、マルチパートMIMEのサポートは遍在していません。SDP属性の機能と潜在的な構成の両方をエンコードすることにより、単一のSDPセッションの説明ですべてを表すことができ、それによりマルチパートMIMEサポートの問題を回避できます。さらに、未知のSDP属性はSDP受信者によって無視されるため、フレームワークをサポートしていないエンティティが通常のRFC 3264オファー/回答手順を実行するだけであることを確認します。これにより、シームレスな後方互換性が提供されます。
o Message size efficiency: When we have multiple media streams, each of which may potentially use two or more different transport protocols with a variety of different associated parameters, the number of potential configurations can be large. If each possible alternative is represented as a complete SDP session description in an offer, we can easily end up with large messages. By providing a more compact encoding, we get more efficient message sizes.
o メッセージサイズの効率：複数のメディアストリームがある場合、それぞれがさまざまな関連するパラメーターを備えた2つ以上の異なるトランスポートプロトコルを使用する可能性がある場合、潜在的な構成の数は大きくなる可能性があります。可能な各代替案がオファーの完全なSDPセッションの説明として表されている場合、大きなメッセージが簡単に終わる可能性があります。よりコンパクトなエンコードを提供することにより、より効率的なメッセージサイズを取得します。
In the next section, we describe the exact structure and specific SDP parameters used to represent this.
次のセクションでは、これを表すために使用される正確な構造と特定のSDPパラメーターについて説明します。
The solution consists of the following:
解決策は次のもので構成されています。
o Two new SDP attributes to support extensions to the framework itself as follows:
o 次のように、フレームワーク自体への拡張をサポートする2つの新しいSDP属性：
o A new attribute ("a=csup") that lists the supported base (optionally) and any supported extension options to the framework.
o サポートされているベース（オプション）とサポートされている拡張オプションをフレームワークにリストする新しい属性（ "a = csup"）。
o A new attribute ("a=creq") that lists the extensions to the framework that are required to be supported by the entity receiving the SDP session description in order to do capability negotiation.
o 能力交渉を行うためにSDPセッションの説明を受信するエンティティによってサポートされる必要があるフレームワークの拡張をリストする新しい属性（ "a = creq"）。
o Two new SDP attributes used to express capabilities as follows (additional attributes can be defined as extensions):
o 次のように機能を表現するために使用される2つの新しいSDP属性（追加の属性は拡張機能として定義できます）：
o A new attribute ("a=acap") that defines how to list an attribute name and its associated value (if any) as a capability.
o 属性名とその関連する値（ある場合）を能力としてリストする方法を定義する新しい属性（ "a = acap"）。
o A new attribute ("a=tcap") that defines how to list transport protocols (e.g., "RTP/AVP") as capabilities.
o トランスポートプロトコル（「RTP/AVP」など）を機能としてリストする方法を定義する新しい属性（ "A = TCAP"）。
o Two new SDP attributes to negotiate configurations as follows:
o 次のように構成を交渉するための2つの新しいSDP属性：
o A new attribute ("a=pcfg") that lists potential configurations supported. This is done by reference to the capabilities from the SDP session description in question. Extension capabilities can be defined and referenced in the potential configurations. Alternative potential configurations have an explicit ordering associated with them. Also, potential configurations are by default preferred over the actual configuration included in the "m=" line and its associated parameters.
o サポートされている潜在的な構成をリストする新しい属性（ "a = pcfg"）。これは、問題のSDPセッションの説明からの機能を参照することによって行われます。拡張機能は、潜在的な構成で定義および参照できます。代替の潜在的な構成には、それらに関連する明示的な順序があります。また、潜在的な構成は、「m =」行およびそれに関連するパラメーターに含まれる実際の構成よりもデフォルトで推奨されます。
This preference order was chosen to provide maximum backwards compatibility for the capability negotiation framework and the possible values offered for a session. For example, an entity that wants to establish a Secure RTP media stream but is willing to accept a plain RTP media stream (assumed to be the least common denominator for most endpoints), can offer plain RTP in the actual configuration and use the capability negotiation extensions to indicate the preference for Secure RTP. Entities that do not support the capability negotiation extensions or Secure RTP will then default to plain RTP.
この優先順序は、機能交渉フレームワークとセッションに提供される可能な値に最大の後方互換性を提供するために選択されました。たとえば、安全なRTPメディアストリームを確立したいが、プレーンRTPメディアストリーム（ほとんどのエンドポイントで最も一般的な分母であると想定される）を受け入れることをいとわないエンティティは、実際の構成でプレーンRTPを提供し、機能交渉を使用できます。安全なRTPの好みを示す拡張機能。機能交渉拡張またはセキュアRTPをサポートしていないエンティティは、デフォルトでプレーンRTPになります。
o A new attribute ("a=acfg") to be used in an answer SDP session description. The attribute identifies a potential configuration from an offer SDP session description that was used as an actual configuration to form the answer SDP session description. Extension capabilities can be included as well.
o 回答SDPセッションの説明で使用される新しい属性（ "a = acfg"）。属性は、回答SDPセッションの説明を形成するための実際の構成として使用されたオファーSDPセッションの説明から潜在的な構成を識別します。拡張機能も含めることができます。
o Extensions to the offer/answer model that allow for capabilities and potential configurations to be included in an offer. Capabilities can be provided at the session level and the media level. Potential configurations can be included only at the media level, where they constitute alternative offers that may be accepted by the answerer instead of the actual configuration(s) included in the "m=" line(s) and associated parameters. The mechanisms defined in this document enable potential configurations to change the transport protocol, add new attributes, as well as remove all existing attributes from the actual configuration. The answerer indicates which (if any) of the potential configurations it used to form the answer by including the actual configuration attribute ("a=acfg") in the answer. Capabilities may be included in answers as well, where they can aid in guiding a subsequent new offer.
o オファーに含まれる機能と潜在的な構成を可能にするオファー/回答モデルへの拡張。セッションレベルとメディアレベルで機能を提供できます。潜在的な構成は、メディアレベルでのみ含めることができ、「m =」行および関連するパラメーターに含まれる実際の構成の代わりに、回答者が受け入れる可能性のある代替オファーを構成することができます。このドキュメントで定義されているメカニズムにより、潜在的な構成がトランスポートプロトコルを変更し、新しい属性を追加し、実際の構成からすべての既存の属性を削除できます。回答者は、回答に実際の構成属性（ "a = acfg"）を含めることにより、回答を形成するために使用した潜在的な構成の（もしあれば）を示します。能力も回答に含まれる場合があり、その後の新しいオファーを導くのに役立ちます。
The mechanism is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
メカニズムは、以下の申し出/回答の交換によって説明されています。ここでは、アリスはボブに申し出を送ります。
Alice Bob
アリスボブ
| (1) Offer (SRTP and RTP) |
|--------------------------------->|
| |
| (2) Answer (SRTP) |
|<---------------------------------|
| |
| (3) Offer (SRTP) |
|--------------------------------->|
| |
| (4) Answer (SRTP) |
|<---------------------------------|
| |
Alice's offer includes RTP and SRTP as alternatives, where RTP is the default (actual configuration), but SRTP is the preferred one (potential configuration):
Aliceのオファーには、代替品としてRTPとSRTPが含まれています。ここで、RTPはデフォルト（実際の構成）ですが、SRTPは優先されるもの（潜在的な構成）です。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
a=pcfg:1 t=1 a=1
The "m=" line indicates that Alice is offering to use plain RTP with PCMU or G.729. The capabilities are provided by the "a=tcap" and "a=acap" attributes. The transport capability attribute ("a=tcap") indicates that Secure RTP under the AVP profile ("RTP/SAVP") is supported with an associated transport capability handle of 1. The "acap" attribute provides an attribute capability with a handle of 1. The attribute capability is a "crypto" attribute, which provides the keying material for SRTP using SDP security descriptions [RFC4568]. The "a=pcfg" attribute provides the potential configuration included in the offer by reference to the capability parameters. One alternative is provided; it has a configuration number of 1 and it consists of transport protocol capability 1 (i.e., the RTP/SAVP profile -- Secure RTP), and the attribute capability 1 (i.e., the "crypto" attribute provided). Potential configurations are preferred over the actual configuration included in the offer SDP session description, and hence Alice is expressing a preference for using Secure RTP.
「M =」行は、AliceがPCMUまたはG.729でプレーンRTPを使用することを申し出ていることを示しています。機能は、「a = tcap」および「a = acap」属性によって提供されます。トランスポート機能属性（ "a = tcap"）は、AVPプロファイル（ "rtp/savp"）の下のセキュアRTPが1の関連するトランスポート機能ハンドルでサポートされていることを示します。「acap」属性は、1.属性機能は「crypto」属性であり、SDPセキュリティ記述[RFC4568]を使用してSRTPのキーイング材料を提供します。「A = PCFG」属性は、機能パラメーターを参照することにより、オファーに含まれる潜在的な構成を提供します。1つの選択肢が提供されます。構成番号は1で、トランスポートプロトコル機能1（つまり、RTP/SAVPプロファイル - セキュアRTP）と属性機能1（つまり、「暗号」属性が提供される「暗号」属性）で構成されています。オファーSDPセッションの説明に含まれる実際の構成よりも潜在的な構成が推奨されるため、アリスは安全なRTPを使用することを好むことを表明しています。
Bob receives the SDP session description offer from Alice. Bob supports SRTP and the SDP Capability Negotiation framework, and hence he accepts the (preferred) potential configuration for Secure RTP provided by Alice and generates the following answer SDP session description:
ボブは、アリスからSDPセッションの説明オファーを受け取ります。BobはSRTPとSDP機能交渉のフレームワークをサポートしているため、Aliceが提供する安全なRTPの（好ましい）潜在的な構成を受け入れ、次の回答SDPセッションの説明を生成します。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
a=acfg:1 t=1 a=1
Bob includes the "a=acfg" attribute in the answer to inform Alice that he based his answer on an offer using potential configuration 1 with transport protocol capability 1 and attribute capability 1 from the offer SDP session description (i.e., the RTP/SAVP profile using the keying material provided). Bob also includes his keying material in a "crypto" attribute. If Bob supported one or more extensions to the Capability Negotiation framework, he would have included option tags for those in the answer as well (in an "a=csup" attribute).
ボブには、回答に「a = acfg」属性を含めて、アリスに、オファーSDPセッションの説明（すなわち、RTP/SAVPプロファイルからの輸送プロトコル機能1および属性機能1を使用して、潜在的な構成1を使用して答えに答えを基づいていることを知らせることを知らせます。提供されるキーイング材料を使用します）。ボブには、「暗号」属性にキーイング素材も含まれています。Bobが機能交渉フレームワークの1つ以上の拡張機能をサポートした場合、彼は回答のそれらのオプションタグも含めていたでしょう（「a = csup」属性）。
When Alice receives Bob's answer, session negotiation has completed; however, Alice nevertheless generates a new offer using the negotiated configuration as the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the SDP Capability Negotiation framework, and hence may not understand the negotiation that just took place.
アリスがボブの回答を受け取ると、セッションの交渉が完了しました。ただし、それでもアリスは、実際の構成としてネゴシエートされた構成を使用して新しいオファーを生成します。これは、アリスとボブの間に存在するが、SDP能力交渉のフレームワークをサポートしていない可能性のある仲介者を支援するために純粋に行われます。
Alice's updated offer includes only SRTP, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Aliceの更新されたオファーにはSRTPのみが含まれており、SDP機能交渉フレームワークを使用していません（アリスは、必要に応じて機能を含めることもできます）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
The "m=" line now indicates that Alice is offering to use Secure RTP with PCMU or G.729. The "crypto" attribute, which provides the SRTP keying material, is included with the same value again.
「M =」行は、AliceがPCMUまたはG.729で安全なRTPを使用することを申し出ていることを示しています。SRTPキーイン素材を提供する「Crypto」属性は、同じ値に再び含まれています。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
ボブは、アリスからSDPセッションの説明オファーを受け取り、それを受け入れ、アリスへの回答を生成します。
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
Bob includes the same "crypto" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
ボブには以前と同じ「暗号」属性が含まれており、セッションは変更なしで進行します。ボブは彼の答えに能力を含めていませんでしたが、彼が望んでいれば彼はそうすることができたでしょう。
Note that in this particular example, the answerer supported the capability negotiation extensions defined here. Had he not, he would simply have ignored the new attributes and accepted the (actual configuration) offer to use normal RTP. In that case, the following answer would have been generated instead:
この特定の例では、回答者はここで定義されている機能交渉拡張機能をサポートしていたことに注意してください。彼がそうでなければ、彼は単に新しい属性を無視し、通常のRTPを使用する（実際の構成）申し出を受け入れたでしょう。その場合、代わりに次の答えが生成されていたでしょう。
v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 m=audio 54568 RTP/AVP 0 18
V = 0 O = -24351 621814 IN IP4 192.0.2.2 S = C = IN IP4 192.0.2.2 T = 0 0 M = Audio 54568 RTP/AVP 0 18
In this section, we present the new attributes associated with indicating the SDP Capability Negotiation extensions supported and required.
このセクションでは、サポートされ、必要なSDP機能交渉拡張機能を示すことに関連付けられた新しい属性を提示します。
The SDP Capability Negotiation solution allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Option tags MUST be registered with IANA per the procedures defined in Section 6.2.
SDP機能交渉ソリューションにより、機能交渉拡張機能を定義できます。そのような各拡張機能に関連付けられているのは、問題の拡張機能を識別するオプションタグです。オプションタグは、セクション6.2で定義されている手順に従ってIANAに登録する必要があります。
The Supported Capability Negotiation Extensions attribute ("a=csup") contains a comma-separated list of option tags identifying the SDP Capability Negotiation extensions supported by the entity that generated the SDP session description. The attribute can be provided at the session level and the media level, and it is defined as follows:
サポートされている機能交渉拡張属性（ "a = csup"）には、SDPセッションの説明を生成したエンティティによってサポートされているSDP機能交渉拡張機能を識別するオプションタグのコンマ分離リストが含まれています。属性は、セッションレベルとメディアレベルで提供でき、次のように定義されます。
a=csup: <option-tag-list>
RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. The "csup" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
RFC 4566、セクション9は、SDP属性のABNF [RFC5234]を提供します。「CSUP」属性は、RFC 4566 "属性の生成に準拠しており、ATT値は次のように定義されています。
att-value = option-tag-list
option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566]
A special base option tag with a value of "cap-v0" is defined for the basic SDP Capability Negotiation framework defined in this document. Entities can use this option tag with the "a=csup" attribute to indicate support for the SDP Capability Negotiation framework specified in this document. Please note that white space is not allowed in this rule.
「CAP-V0」の値を持つ特別なベースオプションタグは、このドキュメントで定義されている基本的なSDP機能交渉フレームワークに対して定義されています。エンティティは、このオプションタグを「A = CSUP」属性で使用して、このドキュメントで指定されたSDP機能交渉フレームワークのサポートを示すことができます。この規則では、空白は許可されていないことに注意してください。
The following examples illustrate use of the "a=csup" attribute with the "cap-v0" option tag and two hypothetical option tags, "foo" and "bar" (note the lack of white space):
次の例は、「a = csup」属性の「cap-v0」オプションタグと2つの仮想オプションタグ、「foo」と「bar」（ホワイトスペースの欠如に注意）を備えた使用を示しています。
a=csup:cap-v0
A = CSUP：CAP-V0
a=csup:foo
a = csup：foo
a=csup:bar
a = csup：bar
a=csup:cap-v0,foo,bar
a = csup：cap-v0、foo、bar
The "a=csup" attribute can be provided at the session and the media level. When provided at the session level, it applies to the entire SDP session description. When provided at the media level, it applies only to the media description in question (option tags provided at the session level apply as well). There MUST NOT be more than one "a=csup" attribute at the session level and one at the media level (one per media description in the latter case).
「a = csup」属性は、セッションとメディアレベルで提供できます。セッションレベルで提供されると、SDPセッションの説明全体に適用されます。メディアレベルで提供される場合、問題のメディアの説明にのみ適用されます（セッションレベルで提供されるオプションタグも適用されます）。セッションレベルで1つ以上の「a = csup」属性とメディアレベルに1つ以上の属性がある必要があります（後者の場合はメディアの説明ごとに1つ）。
Whenever an entity that supports one or more extensions to the SDP Capability Negotiation framework generates an SDP session description, it SHOULD include the "a=csup" attribute with the option tags for the extensions it supports at the session and/or media level, unless those option tags are already provided in one or more "a=creq" attribute (see Section 3.3.2) at the relevant levels. Inclusion of the base option tag is OPTIONAL; support for the base framework can be inferred from presence of the "a=pcfg" attribute defined in Section 3.5.1.
SDP機能ネゴシエーションフレームワークの1つ以上の拡張機能をサポートするエンティティがSDPセッションの説明を生成する場合はいつでも、セッションおよび/またはメディアレベルでサポートする拡張機能のオプションタグに「a = csup」属性を含める必要があります。これらのオプションタグは、関連レベルの1つ以上の「a = creq」属性（セクション3.3.2を参照）で既に提供されています。ベースオプションタグを含めることはオプションです。ベースフレームワークのサポートは、セクション3.5.1で定義されている「A = PCFG」属性の存在から推測できます。
Use of the base option tag may still be useful in some scenarios, e.g., when using SIP OPTIONS [RFC3261] or generating an answer to an offer that did not use the SDP Capability Negotiation framework.
ベースオプションタグの使用は、SIPオプション[RFC3261]を使用する場合、またはSDP機能交渉フレームワークを使用していないオファーへの回答を生成する場合、一部のシナリオでは依然として役立ちます。
The Required Capability Negotiation Extensions attribute ("a=creq") contains a comma-separated list of option tags (see Section 3.3.1) specifying the SDP Capability Negotiation extensions that MUST be supported by the entity receiving the SDP session description, in order for that entity to properly process the SDP Capability Negotiation attributes and associated procedures. There is no need to include the base option tag ("cap-v0") with the "creq" attribute, since any entity that supports the "creq" attribute in the first place also supports the base option tag. Still, it is permissible to do so.
必要な機能交渉拡張属性（ "a = creq"）には、SDPセッションの説明を受信するエンティティがサポートする必要があるSDP機能交渉拡張機能を指定するオプションタグのコンマ分離リスト（セクション3.3.1を参照）が含まれています。そのエンティティがSDP機能のネゴシエーション属性と関連する手順を適切に処理するため。「CREQ」属性にベースオプションタグ（ "CAP-V0"）を含める必要はありません。これは、最初に「CREQ」属性をサポートするエンティティもベースオプションタグをサポートするためです。それでも、そうすることは許されます。
Such functionality may be important if a future version of the Capability Negotiation framework were not backwards compatible.
このような機能は、将来のバージョンの機能交渉フレームワークが後方互換性がなかった場合に重要です。
The attribute can be provided at the session level and the media level, and it is defined as follows:
属性は、セッションレベルとメディアレベルで提供でき、次のように定義されます。
a=creq: <option-tag-list>
The "creq" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
「CREQ」属性は、RFC 4566 "属性の生成に準拠しています。ATT値は次のように定義されています。
att-value = option-tag-list
The following examples illustrate use of the "a=creq" attribute with the "cap-v0" base option tag and two hypothetical option tags, "foo" and "bar" (note the lack of white space):
次の例は、「a = creq」属性の「cap-v0」ベースオプションタグと2つの仮想オプションタグ「foo」と「bar」（ホワイトスペースの欠如に注意）を備えた使用を示しています。
a=creq:cap-v0
a=creq:foo
a=creq:bar
A = CREQ：バー
a=creq:cap-v0,foo,bar
A = CREQ：CAP-V0、FOO、BAR
The "a=creq" attribute can be provided at the session and the media level. When provided at the session level, it applies to the entire SDP session description. When provided at the media level, it applies only to the media description in question (required option tags provided at the session level apply as well). There MUST NOT be more than one "a=creq" attribute at the session level and one "a=creq" attribute at the media level (one per media description in the latter case).
「A = CREQ」属性は、セッションとメディアレベルで提供できます。セッションレベルで提供されると、SDPセッションの説明全体に適用されます。メディアレベルで提供される場合、問題のメディアの説明（セッションレベルで提供される必要なオプションタグも適用されます）にのみ適用されます。セッションレベルに複数の「a = creq」属性、メディアレベルに1つの「a = creq」属性があることはありません（後者の場合はメディアの説明ごとに1つ）。
When an entity generates an SDP session description and it requires the recipient of that SDP session description to support one or more SDP Capability Negotiation extensions (except for the base) at the session or media level in order to properly process the SDP Capability Negotiation, the "a=creq" attribute MUST be included with option tags that identify the required extensions at the session and/or media level. If support for an extension is needed only in one or more specific potential configurations, the potential configuration provides a way to indicate that instead (see Section 3.5.1). Support for the basic negotiation framework is implied by the presence of an "a=pcfg" attribute (see Section 3.5.1) and hence it is not required to include the "a=creq" attribute with the base option tag ("cap-v0").
エンティティがSDPセッションの説明を生成し、SDPセッションの説明の受信者がセッションまたはメディアレベルで1つまたは複数のSDP機能交渉拡張機能（ベースを除く）をサポートする場合、SDP機能の交渉を適切に処理するために、「A = CREQ」属性は、セッションおよび/またはメディアレベルで必要な拡張機能を識別するオプションタグに含める必要があります。拡張機能のサポートが1つ以上の特定の潜在的な構成でのみ必要な場合、潜在的な構成は、代わりにそれを示す方法を提供します（セクション3.5.1を参照）。基本的な交渉フレームワークのサポートは、「a = pcfg」属性（セクション3.5.1を参照）の存在によって暗示されるため、ベースオプションタグ（ "cap--に「a = creq」属性を含める必要はありません。V0 "）。
A recipient that receives an SDP session description and does not support one or more of the required extensions listed in a "creq" attribute MUST NOT perform the SDP Capability Negotiation defined in this document; instead the recipient MUST proceed as if the SDP Capability Negotiation attributes were not included in the first place, i.e., the capability negotiation attributes are ignored. In that case, if the SDP session description recipient is an SDP answerer [RFC3264], the recipient SHOULD include a "csup" attribute in the resulting SDP session description answer listing the SDP Capability Negotiation extensions it actually supports.
SDPセッションの説明を受信し、「CREQ」属性にリストされている必要な拡張機能の1つ以上をサポートしていない受信者は、このドキュメントで定義されているSDP機能交渉を実行してはなりません。代わりに、受信者は、SDP機能交渉属性がそもそも含まれていないかのように進める必要があります。つまり、機能交渉属性は無視されます。その場合、SDPセッションの説明受信者がSDP回答者[RFC3264]である場合、受信者は、結果のSDPセッション説明に「CSUP」属性を含める必要があります。回答
This ensures that introduction of the SDP Capability Negotiation mechanism by itself does not lead to session failures
これにより、SDP能力交渉メカニズム自体がセッションの障害につながらないことが保証されます。
For non-supported extensions provided at the session level, this implies that SDP Capability Negotiation MUST NOT be performed at all. For non-supported extensions at the media level, this implies that SDP Capability Negotiation MUST NOT be performed for the media stream in question.
セッションレベルで提供されるサポートされていない拡張機能の場合、これは、SDP機能の交渉をまったく実行してはならないことを意味します。メディアレベルでサポートされていない拡張機能の場合、これは、問題のメディアストリームに対してSDP機能交渉を実行してはならないことを意味します。
An entity that does not support the SDP Capability Negotiation framework at all, will ignore these attributes (as well as the other SDP Capability Negotiation attributes) and not perform any SDP Capability Negotiation in the first place.
SDP能力交渉フレームワークをまったくサポートしていないエンティティは、これらの属性（および他のSDP機能交渉属性）を無視し、そもそもSDP機能交渉を実行しません。
In this section, we present the new attributes associated with indicating the capabilities for use by the SDP Capability Negotiation.
このセクションでは、SDP機能交渉が使用する機能を示すことに関連する新しい属性を提示します。
Attributes and their associated values can be expressed as capabilities by use of a new attribute capability attribute ("a=acap"), which is defined as follows:
属性とそれに関連する値は、次のように定義されている新しい属性機能属性（ "a = acap"）を使用することにより、機能として表現できます。
a=acap: <att-cap-num> <att-par>
where <att-cap-num> is an integer between 1 and 2^31-1 (both included) used to number the attribute capability and <att-par> is an attribute ("a=") in its "<attribute>" or "<attribute>:<value>" form, i.e., excluding the "a=" part (see [RFC4566]). The attribute can be provided at the session level and the media level.
ここで、<ATT-CAP-NUM>は1〜2^31-1（両方を含む）の間の整数です。"または" <属性>：<value> "フォーム、つまり、「a =」パートを除外します（[rfc4566]を参照）。属性は、セッションレベルとメディアレベルで提供できます。
The "acap" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
「ACAP」属性は、RFC 4566 "属性の生成に準拠しており、ATT値は次のように定義されています。
att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in [RFC4566]
Note that white space is not permitted before the att-cap-num.
ATT-CAP-Numの前には、空白は許可されていないことに注意してください。
When the attribute capability contains a session-level attribute, that "acap" attribute can only be provided at the session level. Conversely, media-level attributes can be provided in attribute capabilities at either the media level or session level. The base SDP Capability Negotiation framework however only defines procedures for use of media-level attribute capabilities at the media level. Implementations that conform only to the base framework MUST NOT generate media-level attribute capabilities at the session level; however, extensions may change this (see, e.g., [SDPMedCap] for one such extension) and hence all implementations MUST still be prepared to receive such capabilities (see Section 3.6.2 for processing rules).
属性機能にセッションレベルの属性が含まれている場合、その「ACAP」属性はセッションレベルでのみ提供できます。逆に、メディアレベルのレベルまたはセッションレベルのいずれかで、メディアレベルの属性を属性機能で提供できます。ただし、ベースSDP機能交渉フレームワークは、メディアレベルでメディアレベルの属性機能を使用する手順のみを定義します。ベースフレームワークのみに準拠する実装は、セッションレベルでメディアレベルの属性機能を生成してはなりません。ただし、拡張機能はこれを変更する可能性があります（そのような拡張機能の1つについては、[SDPMedCap]を参照）。したがって、すべての実装は、そのような機能を受信するために準備する必要があります（処理ルールについてはセクション3.6.2を参照）。
Each occurrence of the "acap" attribute in the entire session description MUST use a different value of <att-cap-num>. Consecutive numbering of the <att-cap-num> values is not required.
セッション全体の「ACAP」属性の各発生は、<ATT-CAP-NUM>の異なる値を使用する必要があります。<att-cap-num>値の連続番号は必要ありません。
There is a need to be able to reference both session-level and media-level attributes in potential configurations at the media level, and this provides for a simple solution to avoiding overlap between the references (handles) to each attribute capability.
メディアレベルでの潜在的な構成でセッションレベルとメディアレベルの両方の属性を参照できる必要があります。これにより、各属性機能への参照（ハンドル）間のオーバーラップを回避するための簡単なソリューションが提供されます。
The <att-cap-num> values provided are independent of similar <cap-num> values provided for other types of capabilities, i.e., they form a separate name-space for attribute capabilities.
提供される<ATT-CAP-NUM>値は、他のタイプの機能に提供される同様の<cap-num>値に依存しません。つまり、属性機能に個別の名前空間を形成します。
The following examples illustrate use of the "acap" attribute:
次の例は、「ACAP」属性の使用を示しています。
a=acap:1 ptime:20
a=acap:2 ptime:30
a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO SrzKTAv9zV
a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62 Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO SrzKTAv9zV
a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
The first two attribute capabilities provide attribute values for the ptime attribute. The third provides SRTP parameters by using Multimedia Internet KEYing (MIKEY) [RFC3830] with the "key-mgmt" attribute [RFC4567]. The fourth provides SRTP parameters by use of security descriptions with the "crypto" attribute [RFC4568]. Note that the line-wrapping and new-lines in example three and four are provided for formatting reasons only -- they are not permitted in actual SDP session descriptions.
最初の2つの属性機能は、PTIME属性の属性値を提供します。3番目は、「Key-MGMT」属性[RFC4567]を使用して、マルチメディアインターネットキーイング（Mikey）[RFC3830]を使用してSRTPパラメーターを提供します。4番目は、「crypto」属性[RFC4568]でセキュリティ記述を使用することにより、SRTPパラメーターを提供します。例3と4のラインラップとニューラインは、フォーマットの理由のみで提供されていることに注意してください。実際のSDPセッションの説明では許可されていません。
Readers familiar with RFC 3407 may notice the similarity between the RFC 3407 "cpar" attribute and the above. There are however a couple of important differences, notably that the "acap" attribute contains a handle that enables referencing it and it furthermore supports only attributes (the "cpar" attribute defined in RFC 3407 supports bandwidth information as well). The "acap" attribute also is not automatically associated with any particular capabilities. See Section 3.14 for the relationship to RFC 3407.
RFC 3407に精通している読者は、RFC 3407 "CPAR"属性と上記の類似性に気付くかもしれません。ただし、いくつかの重要な違いがあります。特に、「ACAP」属性にはそれを参照できるハンドルが含まれており、さらに属性のみをサポートしています（RFC 3407で定義されている「CPAR」属性も帯域幅情報をサポートします）。「ACAP」属性も、特定の機能に自動的に関連付けられていません。RFC 3407との関係については、セクション3.14を参照してください。
Attribute capabilities MUST NOT embed any capability negotiation parameters. This restriction applies to all the capability negotiation parameters defined in this document ("csup", "creq", "acap", "tcap", "pcfg", and "acfg") as well as any capability negotiation extensions defined. The following examples are thus invalid attribute capabilities and MUST NOT be used:
属性機能は、機能交渉パラメーターを埋め込んではなりません。この制限は、このドキュメントで定義されているすべての機能交渉パラメーター（「CSUP」、「CREQ」、「ACAP」、「TCAP」、「PCFG」、および「ACFG」）に適用されます。したがって、次の例は無効な属性機能であり、使用しないでください。
a=acap:1 acap:2 foo:a ;Not allowed to embed "acap"
a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg"
The reason for this restriction is to avoid overly complex processing rules resulting from the expansion of such capabilities into potential configurations (see Section 3.6.2 for further details).
この制限の理由は、そのような機能を潜在的な構成に拡張したことに起因する過度に複雑な処理ルールを回避するためです（詳細については、セクション3.6.2を参照）。
Transport protocols can be expressed as capabilities by use of a new Transport Protocol Capability attribute ("a=tcap") defined as follows:
輸送プロトコルは、次のように定義された新しいトランスポートプロトコル機能属性（ "a = tcap"）を使用することにより、機能として表現できます。
a=tcap: <trpr-cap-num> <proto-list>
where <trpr-cap-num> is an integer between 1 and 2^31-1 (both included) used to number the transport address capability for later reference, and <proto-list> is one or more <proto>, separated by white space, as defined in the SDP "m=" line. The attribute can be provided at the session level and the media level.
<trpr-cap-num>は、後の参照のために輸送アドレス機能を番号にするために使用される1〜2^31-1（両方を含む）の間の整数であり、<proto-list>は1つ以上の<proto>であり、SDP "m =" lineで定義されている空白。属性は、セッションレベルとメディアレベルで提供できます。
The "tcap" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
「TCAP」属性は、RFC 4566 "属性の生成に準拠しており、ATT値は次のように定義されています。
att-value = trpr-cap-num 1*WSP proto-list
trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ;defined in [RFC4566]
Note that white space is not permitted before the trpr-cap-num.
TRPR-CAP-Numの前には、空白は許可されていないことに注意してください。
The "tcap" attribute can be provided at the session level and the media level. There MUST NOT be more than one "a=tcap" attribute at the session level and one at the media level (one per media description in the latter case). Each occurrence of the "tcap" attribute in the entire session description MUST use a different value of <trpr-cap-num>. When multiple <proto> values are provided, the first one is associated with the value <trpr-cap-num>, the second one with the value one higher, etc. There MUST NOT be any capability number overlap between different "tcap" attributes in the entire SDP session description. The <trpr-cap-num> values provided are independent of similar <cap-num> values provided for other capability attributes, i.e., they form a separate name-space for transport protocol capabilities. Consecutive numbering of the <trpr-cap-num> values in different "tcap" attributes is not required.
「TCAP」属性は、セッションレベルとメディアレベルで提供できます。セッションレベルで1つ以上の「a = tcap」属性とメディアレベルに1つ以上の属性がある必要があります（後者の場合はメディアの説明ごとに1つ）。セッション全体の「TCAP」属性の各発生は、<TRPR-CAP-NUM>の異なる値を使用する必要があります。複数の<proto>値が提供される場合、最初の値は値<trpr-cap-num>に関連付けられ、2番目の値は値が1つ高いなどです。SDPセッションの説明全体。提供される<TRPR-CAP-NUM>値は、他の機能属性に提供される同様の<cap-num>値に依存しません。つまり、輸送プロトコル機能のために個別の名前空間を形成します。異なる「TCAP」属性の<TRPR-CAP-NUM>値の連続番号は必要ありません。
Below, we provide examples of the "a=tcap" attribute:
以下に、「a = tcap」属性の例を示します。
a=tcap:1 RTP/AVP
A = TCAP：1 RTP/AVP
a=tcap:2 RTP/AVPF
A = TCAP：2 RTP/AVPF
a=tcap:3 RTP/SAVP RTP/SAVPF
a = tcap：3 rtp/savp rtp/savpf
a=tcap:5 UDP/TLS/RTP/SAVP
A = TCAP：5 UDP/TLS/RTP/SAVP
The first one provides a capability for the "RTP/AVP" profile defined in [RFC3551] and the second one provides a capability for the RTP with RTCP-based feedback profile defined in [RFC4585]. The third one provides capabilities for the "RTP/SAVP" (transport capability number 3) and "RTP/SAVPF" profiles (transport protocol capability number 4). The last one provides capabilities for "UDP/TLS/RTP/SAVP", i.e., DTLS-SRTP [RFC5764] (transport capability number 5).
最初のものは[RFC3551]で定義された「RTP/AVP」プロファイルの機能を提供し、2番目のプロファイルは[RFC4585]で定義されたRTCPベースのフィードバックプロファイルを備えたRTPの機能を提供します。3番目は、「RTP/SAVP」（輸送機能番号3）および「RTP/SAVPF」プロファイル（輸送プロトコル機能番号4）の機能を提供します。最後のものは、「UDP/TLS/RTP/SAVP」、つまりDTLS-SRTP [RFC5764]（輸送能力番号5）の機能を提供します。
The "tcap" attribute by itself can only specify transport protocols as defined by <proto> in [RFC4566]; however, full specification of a media stream requires further qualification of the transport protocol by one or more media format descriptions, which themselves often depend on the transport protocol. As an example, [RFC3551] defines the "RTP/AVP" transport for use with audio and video codecs (media formats), whereas [RFC4145] defines the "TCP" transport, which, for example, may be used to negotiate T.38 fax ("image/t38"), etc. In a non-SDP context, some media formats could be viewed as transports themselves (e.g., T.38); however, in the context of SDP and SDP Capability Negotiation, they are not. If capability negotiation is required for such media formats, they MUST all either be valid under the transport protocol indicated in the "m=" line included for the media stream description, or a suitable extension must be used, e.g., SDP Media Capabilities [SDPMedCap].
「TCAP」属性自体は、[RFC4566]の<proto>で定義されているように、輸送プロトコルのみを指定できます。ただし、メディアストリームの完全な仕様には、1つ以上のメディア形式の説明によるトランスポートプロトコルのさらなる資格が必要であり、それ自体が輸送プロトコルに依存することがよくあります。例として、[RFC3551]は、オーディオおよびビデオコーデック（メディア形式）で使用する「RTP/AVP」トランスポートを定義しますが、[RFC4145]は「TCP」トランスポートを定義します。38 Fax（ "Image/T38"）など。非SDPコンテキストでは、一部のメディア形式は輸送自体と見なすことができます（例：T.38）。ただし、SDPおよびSDP機能の交渉のコンテキストでは、そうではありません。このようなメディア形式に機能交渉が必要な場合、それらはすべて、メディアストリームの説明に含まれる「m =」行に示されているトランスポートプロトコルで有効でなければなりません。]。
The ability to use a particular transport protocol is inherently implied by including it in the "m=" line, regardless of whether or not it is provided in a "tcap" attribute. However, if a potential configuration needs to reference that transport protocol as a capability, the transport protocol MUST be included explicitly in a "tcap" attribute.
特定の輸送プロトコルを使用する機能は、「TCAP」属性に提供されるかどうかに関係なく、「M =」行に含めることにより、本質的に暗示されます。ただし、潜在的な構成でその輸送プロトコルを機能として参照する必要がある場合、トランスポートプロトコルは「TCAP」属性に明示的に含める必要があります。
This may seem redundant (and indeed it is from the offerer's point of view), however it is done to protect against intermediaries (e.g., middleboxes) that may modify "m=" lines while passing unknown attributes through. If an implicit transport capability were used instead (e.g., a reserved transport capability number could be used to refer to the transport protocol in the "m=" line), and an intermediary were to modify the transport protocol in the "m=" line (e.g., to translate between plain RTP and Secure RTP), then the potential configuration referencing that implicit transport capability may no longer be correct. With explicit capabilities, we avoid this pitfall; however, the potential configuration preference (see Section 3.5.1) may not reflect that of the intermediary (which some may view as a feature).
これは冗長に見えるかもしれません（実際、それは提供者の観点からです）が、不明な属性を通過しながら「m =」行を変更する可能性のある仲介者（例：ミドルボックス）から保護するために行われます。代わりに暗黙の輸送能力が使用された場合（たとえば、予約された輸送能力数を使用して「m =」行の輸送プロトコルを参照することができます）。（たとえば、プレーンRTPとセキュアRTPの間で翻訳するため）、暗黙の輸送能力がもはや正しくない可能性があることを参照する潜在的な構成。明示的な機能により、この落とし穴を避けます。ただし、潜在的な構成の好み（セクション3.5.1を参照）は、仲介者の潜在的な優先度を反映していない場合があります（一部は機能と見なす場合があります）。
Note that a transport protocol capability may be provided, irrespective of whether or not it is referenced in a potential configuration (just like any other capability).
潜在的な構成で参照されるかどうかに関係なく、トランスポートプロトコル機能を提供できることに注意してください（他の機能と同様）。
The SDP Capability Negotiation framework allows for new types of capabilities to be defined as extensions and used with the general capability negotiation framework. The syntax and semantics of such new capability attributes are not defined here; however, in order to be used with potential configurations, they SHOULD allow for a numeric handle to be associated with each capability. This handle can be used as a reference within the potential and actual configuration attributes (see Sections 3.5.1 and 3.5.2). The definition of such extension capability attributes MUST also state whether they can be applied at the session level, media level, or both. Note that extensions can have option tags defined for them, and option tags MUST be registered with the IANA in accordance with the procedures specified in Section 6.2.
SDP機能交渉フレームワークにより、新しいタイプの機能を拡張として定義し、一般的な機能交渉フレームワークで使用できます。このような新しい機能属性の構文とセマンティクスは、ここでは定義されていません。ただし、潜在的な構成で使用するには、数値ハンドルが各機能に関連付けられるようにする必要があります。このハンドルは、ポテンシャルおよび実際の構成属性内の参照として使用できます（セクション3.5.1および3.5.2を参照）。このような拡張機能属性の定義は、セッションレベル、メディアレベル、またはその両方で適用できるかどうかを述べる必要があります。拡張機能にはオプションタグが定義されていることに注意してください。また、セクション6.2で指定された手順に従って、オプションタグはIANAに登録する必要があります。
Extension capabilities SHOULD NOT embed any capability negotiation parameters. This applies to all the capability negotiation parameters defined in this document as well as any extensions defined. The reason for this restriction is to avoid overly complex processing rules resulting from the expansion of such capabilities into potential configurations (see Section 3.6.2 for further details). If an extension does not follow the above "SHOULD NOT" recommendation, the extension MUST provide a careful analysis of why such behavior is both necessary and safe.
拡張機能は、機能交渉パラメーターを埋め込むべきではありません。これは、このドキュメントで定義されているすべての機能交渉パラメーターと、定義された拡張機能に適用されます。この制限の理由は、そのような機能を潜在的な構成に拡張したことに起因する過度に複雑な処理ルールを回避するためです（詳細については、セクション3.6.2を参照）。拡張機能が上記の「すべきではない」推奨に従わない場合、拡張機能は、そのような動作が必要かつ安全である理由を慎重に分析する必要があります。
Potential configurations can be expressed by use of a new Potential Configuration Attribute ("a=pcfg") defined as follows:
潜在的な構成は、次のように定義された新しい潜在的な構成属性（ "a = pcfg"）を使用することで表現できます。
a=pcfg: <config-number> [<pot-cfg-list>]
where <config-number> is an integer between 1 and 2^31-1 (both included). The attribute can be provided only at the media level.
ここで、<confignumber>は1〜2^31-1の間の整数です（両方が含まれています）。属性は、メディアレベルでのみ提供できます。
The "pcfg" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
「PCFG」属性は、RFC 4566 "属性の生成に準拠しており、ATT値は次のように定義されています。
att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*10(DIGIT) ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list /
transport-protocol-config-list /
extension-config-list
The missing productions are defined below. Note that white space is not permitted before the config-number.
欠落しているプロダクションを以下に定義します。設定番号の前に空白は許可されていないことに注意してください。
The potential configuration attribute can be provided only at the media level and there can be multiple instances of it within a given media description. The attribute includes a configuration number, which is an integer between 1 and 2^31-1 (both included). The configuration number MUST be unique within the media description (i.e., it has only media-level scope). The configuration number also indicates the relative preference of potential configurations; lower numbers are preferred over higher numbers. Consecutive numbering of the configuration numbers in different "pcfg" attributes in a media description is not required.
潜在的な構成属性は、メディアレベルでのみ提供でき、特定のメディアの説明内に複数のインスタンスがある場合があります。属性には、1〜2^31-1（両方が含まれている）の間の整数である構成番号が含まれています。構成番号は、メディアの説明内で一意でなければなりません（つまり、メディアレベルの範囲のみがあります）。構成番号は、潜在的な構成の相対的な選好も示します。より高い数値よりも低い数値が好まれます。メディアの説明内の異なる「PCFG」属性の構成番号の連続番号は必要ありません。
A potential configuration list is normally provided after the configuration number. When the potential configuration list is omitted, the potential configuration equals the actual configuration. The potential configuration list contains one or more of attribute, transport, and extension configuration lists. A potential configuration may for example include attribute capabilities and transport capabilities, transport capabilities only, or some other combination of capabilities. If transport capabilities are not included in a potential configuration, the default transport for that media stream is used.
通常、構成番号の後に潜在的な構成リストが提供されます。潜在的な構成リストが省略されている場合、潜在的な構成は実際の構成に等しくなります。潜在的な構成リストには、1つ以上の属性、トランスポート、および拡張構成リストが含まれています。たとえば、潜在的な構成には、属性機能と輸送機能、輸送機能のみ、またはその他の機能の組み合わせが含まれます。輸送機能が潜在的な構成に含まれていない場合、そのメディアストリームのデフォルトのトランスポートが使用されます。
The potential configuration lists generally reference one or more capabilities (extension configuration lists MAY use a different format). Those capabilities are (conceptually) used to construct a new internal version of the SDP session description by use of purely syntactic add and (possibly) delete operations on the original SDP session description (actual configuration). This provides an alternative potential configuration SDP session description that can be used by conventional SDP and offer/answer procedures if selected.
潜在的な構成リストは、通常、1つ以上の機能を参照します（拡張機能リストは異なる形式を使用する場合があります）。これらの機能は、元のSDPセッションの説明（実際の構成）で純粋に構文の追加および（おそらく）削除操作を使用して、SDPセッションの説明の新しい内部バージョンを構築するために（概念的に）使用されます。これにより、従来のSDPで使用できる代替の潜在的な構成SDPセッションの説明が提供され、選択された場合は提供/回答手順が提供されます。
This document defines attribute configuration lists and transport protocol configuration lists. Each of these MUST NOT be present more than once in a particular potential configuration attribute. Attribute capabilities referenced by the attribute configuration list (if included) are added to the actual configuration, whereas a transport capability referenced by the transport protocol configuration list (if included) replaces the default transport protocol from the actual configuration. Extension configuration lists can be included as well. There can be more than one extension configuration list; however, each particular extension MUST NOT be present more than once in a given "a=pcfg" attribute. Together, the various configuration lists define a potential configuration.
このドキュメントは、属性構成リストと輸送プロトコル構成リストを定義します。これらのそれぞれは、特定の潜在的な構成属性に複数回存在してはなりません。属性構成リスト（含まれる場合）で参照される属性機能は実際の構成に追加されますが、トランスポートプロトコル構成リスト（含まれる場合）で参照されるトランスポート機能は、実際の構成からデフォルトのトランスポートプロトコルを置き換えます。拡張設定リストも含めることができます。複数の拡張機能構成リストがあります。ただし、特定の拡張機能は、特定の「A = PCFG」属性に複数回存在してはなりません。一緒に、さまざまな構成リストが潜在的な構成を定義します。
There can be multiple potential configurations in a media description. Each of these indicates not only a willingness, but in fact a desire to use the potential configuration.
メディアの説明には、複数の潜在的な構成があります。これらのそれぞれは、意欲だけでなく、実際には潜在的な構成を使用したいという欲求を示しています。
The example SDP session description below contains two potential configurations:
以下のSDPセッションの説明の例には、2つの潜在的な構成が含まれています。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
Potential configuration 1 contains a transport protocol configuration list that references transport capability 1 ("RTP/SAVP") and an attribute configuration list that references attribute capability 1 ("a=crypto:..."). Potential configuration 2 contains a transport protocol configuration list that references transport capability 2 ("RTP/SAVPF") and an attribute configuration list that references attribute capability 1 ("a=crypto:...").
潜在的な構成1には、トランスポート機能1（ "RTP/SAVP"）を参照するトランスポートプロトコル構成リストと、属性機能1（ "a = crypto：..."）を参照する属性構成リストが含まれています。潜在的な構成2には、トランスポート機能2（ "rtp/savpf"）を参照するトランスポートプロトコル構成リストと、属性機能1（ "a = crypto：..."）を参照する属性構成リストが含まれています。
Attribute capabilities are used in a potential configuration by use of the attribute-config-list parameter, which is defined by the following ABNF:
属性機能は、次のABNFで定義される属性-Config-Listパラメーターを使用することにより、潜在的な構成で使用されます。
attribute-config-list = "a=" delete-attributes
attribute-config-list =/ "a=" [delete-attributes ":"]
mo-att-cap-list *(BAR mo-att-cap-list)
delete-attributes = DELETE ( "m" ; media attributes
/ "s" ; session attributes
/ "ms" ) ; media and session attributes
mo-att-cap-list = mandatory-optional-att-cap-list / mandatory-att-cap-list / optional-att-cap-list
mo-att-cap-list = bentoration-optional-att-cap-list / sencatory-att-ast-cap-list / optional-att-capリスト
mandatory-optional-att-cap-list = mandatory-att-cap-list "," optional-att-cap-list mandatory-att-cap-list = att-cap-list optional-att-cap-list = "[" att-cap-list "]"
必須-optional-att-cap-list = benant-att-cap-list "、" optional-att-ast-atig-list angtorationtoration-rist = att-cap-list optional-att-cap-list = "[[「att-caplist」] "
att-cap-list = att-cap-num *("," att-cap-num)
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
BAR = "|"
DELETE = "-"
Note that white space is not permitted within the attribute-config-list rule.
Attribute-Config-Listルール内では、空白は許可されていないことに注意してください。
Each attribute configuration list can optionally begin with instructions for how to handle attributes that are part of the actual configuration SDP session description (i.e., the "a=" lines present in the original SDP session description). By default, such attributes will remain as part of the potential configuration in question. However, if delete-attributes indicates "-m", then all attribute lines within the media description in question will be deleted in the resulting potential configuration SDP session description (i.e., all "a=" lines under the "m=" line in question). If delete-attributes indicates "-s", then all attribute lines at the session level will be deleted (i.e., all "a=" lines before the first "m=" line). If delete-attributes indicates "-ms", then all attribute lines within this media description ("m=" line) and all attribute lines at the session level will be deleted.
各属性構成リストは、実際の構成SDPセッションの説明の一部である属性（つまり、元のSDPセッションの説明に存在する「a =」行）の属性を処理する方法の手順からオプションで開始できます。デフォルトでは、そのような属性は、問題の潜在的な構成の一部として残ります。ただし、Delete-Attributesが「-M」を示している場合、問題のメディア説明内のすべての属性行は、結果の潜在的な構成SDPセッションの説明で削除されます（つまり、「M =」行のすべての「a =」行はすべての「a =」行です。質問）。Delete-Attributesが「-s」を示す場合、セッションレベルのすべての属性行が削除されます（つまり、最初の「m = "行の前のすべての「a =」行）が削除されます。削除aTtributesが「-ms」を示している場合、このメディアの説明（ "m ="行）内のすべての属性行とセッションレベルのすべての属性行が削除されます。
The attribute capability list comes next (if included). It contains one or more alternative lists of attribute capabilities. The alternative attribute capability lists are separated by a vertical bar ("|"), and each list contains one or more attribute capabilities separated by commas (","). The attribute capabilities are either mandatory or optional. Mandatory attribute capabilities MUST be supported in order to use the potential configuration, whereas optional attribute capabilities MAY be supported in order to use the potential configuration.
属性機能リストが次にあります（含まれる場合）。属性機能の1つ以上の代替リストが含まれています。代替属性機能リストは、垂直バー（ "|"）で区切られており、各リストにはコンマ（ "、"）で区切られた1つ以上の属性機能が含まれています。属性機能は、必須またはオプションのいずれかです。潜在的な構成を使用するために必須属性機能をサポートする必要がありますが、潜在的な構成を使用するためにオプションの属性機能をサポートすることができます。
Within each attribute capability list, all the mandatory attribute capabilities (if any) are listed first, and all the optional attribute capabilities (if any) are listed last. The optional attribute capabilities are contained within a pair of square brackets ("[" and "]"). Each attribute capability is merely an attribute capability number (att-cap-num) that identifies a particular attribute capability by referring to attribute capability numbers defined above and hence MUST be between 1 and 2^31-1 (both included). The following example illustrates the above:
各属性機能リスト内で、すべての必須属性機能（存在する場合）が最初にリストされ、すべてのオプションの属性機能（存在する場合）が最後にリストされます。オプションの属性機能は、正方形の括弧（ "["および "]）のペア内に含まれています。各属性機能は、上記の属性機能番号を参照することにより特定の属性機能を識別する属性機能番号（att-cap-num）にすぎないため、1〜2^31-1（両方を含む）でなければなりません。次の例は、上記を示しています。
a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]
where
ただし
o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list
o "a = -m：1,2、[3,4] | 1,7、[5]」は属性構成リストです
o "-m" indicates to delete all attributes from the media description of the actual configuration
o 「-m」は、実際の構成のメディアの説明からすべての属性を削除することを示します
o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. The two lists are alternatives, since they are separated by a vertical bar above
o 「1,2、[3,4]」および「1,7、[5]」はどちらも属性機能リストです。2つのリストは、上の垂直バーで区切られているため、代替案です。
o "1", "2", and "7" are mandatory attribute capabilities
o 「1」、「2」、および「7」は必須属性機能です
o "3", "4", and "5" are optional attribute capabilities
o 「3」、「4」、および「5」はオプションの属性機能です
Note that in the example above, we have a single handle ("1") for the potential configuration(s), but there are actually two different potential configurations (separated by a vertical bar). This is done for message size efficiency reasons, which is especially important when we add other types of capabilities to the potential configuration. If there is a need to provide a unique handle for each, then separate "a=pcfg" attributes with different handles MUST be used instead.
上記の例では、潜在的な構成用の単一のハンドル（ "1"）があるが、実際には2つの異なる潜在的な構成（垂直バーで区切られている）があることに注意してください。これは、メッセージサイズの効率的な理由で行われます。これは、潜在的な構成に他のタイプの機能を追加するときに特に重要です。それぞれに一意のハンドルを提供する必要がある場合は、代わりに異なるハンドルを持つ「A = PCFG」属性を分離する必要があります。
Each referenced attribute capability in the potential configuration will result in the corresponding attribute name and its associated value (contained inside the attribute capability) being added to the resulting potential configuration SDP session description.
潜在的な構成で参照される各属性機能により、対応する属性名とその関連する値（属性機能内に含まれる）が、結果の潜在的な構成SDPセッションの説明に追加されます。
Alternative attribute capability lists are separated by a vertical bar ("|"), the scope of which extends to the next alternative (i.e., "," has higher precedence than "|"). The alternatives are ordered by preference with the most preferred listed first. In order for a recipient of the SDP session description (e.g., an answerer receiving this in an offer) to use this potential configuration, exactly one of the alternative lists MUST be selected in its entirety. This requires that all mandatory attribute capabilities referenced by the potential configuration are supported with the attribute values provided.
代替属性機能リストは、垂直バー（ "|"）で区切られており、その範囲は次の代替にまで及びます（つまり、 "、"は「|」よりも優先されます）。代替案は、最初に最も優先される最も優先されるものと好みによって順序付けられます。SDPセッションの説明（例：これをオファーで受信する回答者）の受信者がこの潜在的な構成を使用するには、代替リストの1つを完全に選択する必要があります。これには、潜在的な構成によって参照されるすべての必須属性機能が、提供された属性値でサポートされることが必要です。
Transport protocol configuration lists are included in a potential configuration by use of the transport-protocol-config-list parameter, which is defined by the following ABNF:
トランスポートプロトコルの構成リストは、次のABNFで定義されているTransport-Protocol-Config-Listパラメーターを使用することにより、潜在的な構成に含まれています。
transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234]
Note that white space is not permitted within this rule.
この規則内では、空白は許可されていないことに注意してください。
The trpr-cap-num refers to transport protocol capability numbers defined above and hence MUST be between 1 and 2^31-1 (both included). Alternative transport protocol capabilities are separated by a vertical bar ("|"). The alternatives are ordered by preference with the most preferred listed first. If there are no transport protocol capabilities included in a potential configuration at the media level, the transport protocol information from the associated "m=" line MUST be used. In order for a recipient of the SDP session description (e.g., an answerer receiving this in an offer) to use this potential configuration, exactly one of the alternatives MUST be selected. This requires that the transport protocol in question is supported.
TRPR-CAP-NUMは、上記で定義されたプロトコル機能の数値を輸送することを指し、したがって1〜2^31-1（両方が含まれる）でなければなりません。代替輸送プロトコル機能は、垂直バー（ "|"）で区切られています。代替案は、最初に最も優先される最も優先されるものと好みによって順序付けられます。メディアレベルの潜在的な構成に輸送プロトコル機能が含まれていない場合、関連する「M =」行からの輸送プロトコル情報を使用する必要があります。SDPセッションの説明（例：これをオファーで受信する回答者）の受信者がこの潜在的な構成を使用するには、選択肢の1つを選択する必要があります。これには、問題の輸送プロトコルがサポートされる必要があります。
In the presence of intermediaries (the existence of which may not be known), care should be taken with assuming that the transport protocol in the "m=" line will not be modified by an intermediary. Use of an explicit transport protocol capability will guard against capability negotiation implications of that.
仲介者（その存在は知られていないかもしれない）の存在下では、「M =」行の輸送プロトコルが仲介者によって変更されないと仮定することに注意する必要があります。明示的な輸送プロトコル機能を使用すると、その能力交渉の意味合いが守られます。
Extension capabilities can be included in a potential configuration as well by use of extension configuration lists. Extension configuration lists MUST adhere to the following ABNF:
拡張機能は、拡張設定リストを使用することにより、潜在的な構成に含めることができます。拡張構成リストは、次のABNFに準拠する必要があります。
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC5234]
Note that white space is not permitted within this rule.
この規則内では、空白は許可されていないことに注意してください。
The ext-cap-name refers to the name of the extension capability and the ext-cap-list is here merely defined as a sequence of visible characters. The actual extension supported MUST refine both of these further. For extension capabilities that merely need to be referenced by a capability number, it is RECOMMENDED to follow a structure similar to what has been specified above. Unsupported or unknown potential extension configuration lists in a potential configuration attribute MUST be ignored, unless they are prefixed with the plus ("+") sign, which indicates that the extension is mandatory and MUST be supported in order to use that potential configuration.
ext-cap-nameは、拡張機能の名前を指し、ext-capリストはここでは、目に見える文字のシーケンスとして定義されています。サポートされている実際の拡張機能は、これらの両方をさらに改良する必要があります。単に機能番号で参照する必要がある拡張機能については、上記で指定されたものと同様の構造に従うことをお勧めします。潜在的な構成属性のサポートされていないまたは未知の潜在的な拡張構成リストは、Plus（ ""）サインが付いていない限り無視する必要があります。
The "creq" attribute and its associated rules can be used to ensure that required extensions are supported in the first place.
「CREQ」属性とその関連するルールを使用して、最初に必要な拡張機能がサポートされるようにすることができます。
Extension configuration lists define new potential configuration parameters and hence they MUST be registered with IANA per the procedures defined in Section 6.3.
拡張設定リストは、新しい潜在的な構成パラメーターを定義するため、セクション6.3で定義されている手順に従ってIANAに登録する必要があります。
Potential configuration attributes can be provided only at the media level; however, it is possible to reference capabilities provided at either the session or media level. There are certain semantic rules and restrictions associated with this: A (media-level) potential configuration attribute in a given media description MUST NOT reference a media-level capability provided in a different media description; doing so invalidates that potential configuration (note that a potential configuration attribute can contain more than one potential configuration by use of alternatives). A potential configuration attribute can however reference a session-level capability. The semantics of doing so depends on the type of capability. In the case of transport protocol capabilities, it has no particular implication. In the case of attribute capabilities, however, it does. More specifically, the attribute name and value (provided within that attribute capability) will be considered part of the resulting SDP for that particular configuration at the *session* level. In other words, it will be as-if that attribute was provided with that value at the session level in the first place. As a result, the base SDP Capability Negotiation framework REQUIRES that potential configurations do not reference any session-level attribute capabilities that contain media-level attributes (since that would place a media-level attribute at the session level). Extensions may modify this behavior, as long as it is fully backwards compatible with the base specification.
潜在的な構成属性は、メディアレベルでのみ提供できます。ただし、セッションレベルまたはメディアレベルで提供される機能を参照することは可能です。これに関連する特定のセマンティックルールと制限があります。特定のメディアの説明内の（メディアレベルの）潜在的な構成属性は、別のメディアの説明で提供されるメディアレベルの機能を参照してはなりません。そうすることで、潜在的な構成が無効になります（潜在的な構成属性には、代替案を使用することで複数の潜在的な構成を含めることができることに注意してください）。ただし、潜在的な構成属性は、セッションレベルの機能を参照できます。そうするという意味論は、機能のタイプに依存します。輸送プロトコル機能の場合、それは特に意味がありません。ただし、属性機能の場合、そうです。より具体的には、属性名と値（その属性機能内で提供）は、 *セッション *レベルでその特定の構成のSDPの一部と見なされます。言い換えれば、そもそもセッションレベルで属性がその値を提供された場合、それはas-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-as-asです。その結果、ベースSDP機能交渉フレームワークでは、潜在的な構成がメディアレベルの属性を含むセッションレベルの属性機能を参照しないことを必要とします（セッションレベルにメディアレベルの属性を配置するため）。拡張機能は、ベース仕様と完全に逆方向に互換性がある限り、この動作を変更する場合があります。
Individual media streams perform capability negotiation individually, and hence it is possible that one media stream (where the attribute was part of a potential configuration) chose a configuration without a session-level attribute that was chosen by another media stream. The session-level attribute however remains "active" and applies to the entire resulting potential configuration SDP session description. In theory, this is problematic if one or more session-level attributes either conflicts with or potentially interacts with another session-level or media-level attribute in an undefined manner. In practice, such examples seem to be rare (at least with the SDP attributes that had been defined at time of publication of this document).
個々のメディアストリームは、個別に機能交渉を実行するため、1つのメディアストリーム（属性が潜在的な構成の一部であった）が、別のメディアストリームによって選択されたセッションレベルの属性のない構成を選択する可能性があります。ただし、セッションレベルの属性は「アクティブ」のままであり、結果として生じる潜在的な構成SDPセッションの説明全体に適用されます。理論的には、これは、1つまたは複数のセッションレベルの属性が、競合するか、潜在的に別のセッションレベルまたはメディアレベルの属性と潜在的に対話しない場合に問題があります。実際には、そのような例はまれであるように見えます（少なくとも、このドキュメントの公開時に定義されていたSDP属性の場合）。
A related set of problems can occur if we need coordination between session-level attributes from multiple media streams in order for a particular functionality to work. The grouping framework [RFC5888] is an example of this. If we use the SDP Capability Negotiation framework to select a session-level group attribute (provided as an attribute capability), and we require two media descriptions to do this consistently, we could have a problem. The Forward Error Correction (FEC) grouping semantics [RFC4756] is one example where this in theory could cause problems, however in practice, it is unclear that there is a significant problem with the grouping semantics that had been defined at time of publication of this document.
特定の機能が機能するためには、複数のメディアストリームからのセッションレベルの属性間の調整が必要な場合、関連する一連の問題が発生する可能性があります。グループ化フレームワーク[RFC5888]は、この例です。SDP機能ネゴシエーションフレームワークを使用してセッションレベルのグループ属性（属性機能として提供）を選択し、これを一貫して行うには2つのメディアの説明が必要な場合は、問題が発生する可能性があります。フォワードエラー補正（FEC）セマンティクスのグループ化[RFC4756]は、理論的に問題を引き起こす可能性がある1つの例ですが、実際には、この出版時に定義されていたグループ化セマンティクスに重要な問題があることは不明です。資料。
Resolving the above issues in general requires inter-media stream constraints and synchronized potential configuration processing; this would add considerable complexity to the overall solution. In practice, with the SDP attributes defined at time of publication of this document, it does not seem to be a significant problem, and hence the base SDP Capability Negotiation solution does not provide a solution to this issue. Instead, it is RECOMMENDED that use of session-level attributes in a potential configuration is avoided when possible, and when not, that such use is examined closely for any potential interaction issues. If interaction is possible, the entity generating the SDP session description SHOULD NOT assume that well-defined operation will occur at the receiving entity. This implies that mechanisms that might have such interactions cannot be used in security critical contexts.
一般に上記の問題を解決するには、メディア間ストリームの制約と同期された潜在的な構成処理が必要です。これにより、全体的なソリューションにかなりの複雑さが加わります。実際には、このドキュメントの公開時に定義されたSDP属性により、それは重大な問題ではないようであるため、基本SDP能力交渉ソリューションはこの問題の解決策を提供しません。代わりに、潜在的な構成でのセッションレベルの属性の使用は可能な場合は回避されることをお勧めします。相互作用が可能な場合、SDPセッションの説明を生成するエンティティは、受信エンティティで明確に定義された操作が発生すると仮定してはなりません。これは、そのような相互作用を持つ可能性のあるメカニズムをセキュリティクリティカルコンテキストで使用できないことを意味します。
The session-level operation of extension capabilities is undefined. Consequently, each new session-level extension capability defined MUST specify the implication of making it part of a configuration at the media level.
拡張機能のセッションレベルの操作は未定義です。したがって、定義された新しいセッションレベルの拡張機能それぞれは、メディアレベルで構成の一部にすることの意味を指定する必要があります。
Below, we provide an example of the "a=pcfg" attribute in a complete media description in order to properly indicate the supporting attributes:
以下に、サポート属性を適切に示すために、完全なメディアの説明に「A = PCFG」属性の例を示します。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVPF 0 18
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
a=pcfg:1 t=4|3 a=1
a=pcfg:8 t=1|2
We have two potential configuration attributes listed here. The first one (and most preferred, since its configuration number is "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP (specified by the transport protocol capability numbers 4 and 3) can be supported with attribute capability 1 (the "crypto" attribute); RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) is listed first in the preferred potential configuration. Note that although we have a single potential configuration attribute and associated handle, we have two potential configurations.
ここにリストされている2つの潜在的な構成属性があります。最初のもの（およびその構成番号は「1」であるため、最も好まれます）は、プロファイルRTP/SAVPFまたはRTP/SAVPのいずれか（トランスポートプロトコル機能番号4および3で指定）を属性機能1（「crypto」属性）;RTP/SAVPFは、その機能数（4）が優先電位構成に最初にリストされているため、RTP/SAVPよりも優先されます。単一の潜在的な構成属性と関連するハンドルがありますが、2つの潜在的な構成があることに注意してください。
The second potential configuration attribute indicates that the RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the preferred one. This non-secure RTP alternative is the less preferred one since its configuration number is "8". Again, note that we have two potential configurations here and hence a total of four potential configurations in the SDP session description above.
2番目の潜在的な構成属性は、RTP/AVPFまたはRTP/AVPプロファイルを使用できることを示し、RTP/AVPFが優先されるものです。この非セキュアRTPの代替品は、構成番号が「8」であるため、あまり好まれていません。繰り返しますが、ここには2つの潜在的な構成があるため、上記のSDPセッションの説明に合計4つの潜在的な構成があることに注意してください。
The actual configuration attribute identifies which of the potential configurations from an offer SDP session description was selected and used as the actual configuration to generate an answer SDP session description. This is done by including the configuration number and the configuration lists (if any) from the offer that were selected and used by the answerer in his offer/answer procedure as follows:
実際の構成属性は、オファーSDPセッションの説明からの潜在的な構成のどれが選択され、実際の構成として使用され、回答SDPセッションの説明を生成します。これは、以下のように、「構成番号と構成リスト（もしあれば）（もしあれば）（もしあれば）（存在する場合）（存在する場合）は、回答者が彼のオファー/回答手順で使用したものから含めることによって行われます。
o A selected attribute configuration MUST include the delete-attributes and the known and supported parameters from the selected alternative mo-att-cap-list (i.e., containing all mandatory and all known and supported optional capability numbers from the potential configuration). If delete-attributes were not included in the potential configuration, they will of course not be present here either.
o 選択された属性構成には、選択した代替MO-ATT-CAPリストからの削除アトリビュートと既知およびサポートされたパラメーターを含める必要があります（つまり、潜在的な構成からすべての必須およびサポートされているオプションの機能番号をすべて含む）。削除アトリビュートが潜在的な構成に含まれていない場合、もちろんここにも存在しません。
o A selected transport protocol configuration MUST include the selected transport protocol capability number.
o 選択した輸送プロトコル構成には、選択したトランスポートプロトコル機能番号を含める必要があります。
o A selected potential extension configuration MUST include the selected extension configuration parameters as specified for that particular extension.
o 選択された潜在的な拡張構成には、その特定の拡張子に指定された選択した拡張機能パラメーターを含める必要があります。
o When a configuration list contains alternatives (separated by "|"), the selected configuration only MUST be provided.
o 構成リストに代替（「|」で区切られた）が含まれている場合、選択した構成のみを提供する必要があります。
Note that the selected configuration number and all selected capability numbers used in the actual configuration attribute refer to those from the offer: not the answer.
選択した構成番号と実際の構成属性で使用されるすべての選択された機能番号は、オファーからのものを参照していることに注意してください。回答ではありません。
The answer may for example include capabilities as well to inform the offerer of the answerers capabilities above and beyond the negotiated configuration. The actual configuration attribute does not refer to any of those answer capabilities though.
回答には、たとえば、交渉済みの構成を超えた以上の回答者機能を提供者に通知する機能も含まれている場合があります。ただし、実際の構成属性は、これらの回答機能のいずれを参照していません。
The Actual Configuration Attribute ("a=acfg") is defined as follows:
実際の構成属性（ "a = acfg"）は次のように定義されます。
a=acfg: <config-number> [<sel-cfg-list>]
where <config-number> is an integer between 1 and 2^31-1 (both included) that refers to the selected potential configuration. The attribute can be provided only at the media level.
ここで、<confignumber>は、選択した潜在的な構成を指す1〜2^31-1（両方を含む）の間の整数です。属性は、メディアレベルでのみ提供できます。
The "acfg" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
「ACFG」属性は、RFC 4566 "属性の生成に準拠しており、ATT値は次のように定義されています。
att-value = config-number [1*WSP sel-cfg-list]
;config-number defined in Section 3.5.1.
sel-cfg-list = sel-cfg *(1*WSP sel-cfg)
sel-cfg = sel-attribute-config /
sel-transport-protocol-config /
sel-extension-config
sel-attribute-config = "a=" [delete-attributes ":"] mo-att-cap-list ; defined in Section 3.5.1.
sel-attribute-config = "a =" [delete-attributes "："] mo-att-cap-list;セクション3.5.1で定義されています。
sel-transport-protocol-config = "t=" trpr-cap-num ; defined in Section 3.5.1.
SEL-TRANSPORT-PROTOCOL-CONFIG = "T =" TRPR-CAP-NUM;セクション3.5.1で定義されています。
sel-extension-config = ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1.
sel-Extension-config = ext-cap-name "=" 1*vChar;セクション3.5.1で定義されています。
Note that white space is not permitted before the config-number.
設定番号の前に空白は許可されていないことに注意してください。
The actual configuration ("a=acfg") attribute can be provided only at the media level. There MUST NOT be more than one occurrence of an actual configuration attribute within a given media description.
実際の構成（ "a = acfg"）属性は、メディアレベルでのみ提供できます。特定のメディアの説明内に、実際の構成属性の発生が1つ以上ない必要があります。
Below, we provide an example of the "a=acfg" attribute (building on the previous example with the potential configuration attribute):
以下に、「a = acfg」属性（潜在的な構成属性を備えた前の例に基づいて構築）の例を示します。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVPF 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=4 a=1
It indicates that the answerer used an offer consisting of potential configuration number 1 with transport protocol capability 4 from the offer (RTP/SAVPF) and attribute capability 1 (the "crypto" attribute). The answerer includes his own "crypto" attribute as well.
これは、応答者がオファー（RTP/SAVPF）および属性機能1（「暗号」属性）からの輸送プロトコル機能4を備えた潜在的な構成番号1で構成されるオファーを使用したことを示しています。回答者には、彼自身の「暗号」属性も含まれています。
In this section, we define extensions to the offer/answer model defined in [RFC3264] to allow for potential configurations to be included in an offer, where they constitute alternative offers that may be accepted by the answerer instead of the actual configuration(s) included in the "m=" line(s).
このセクションでは、[RFC3264]で定義されたオファー/回答モデルへの拡張機能を定義して、潜在的な構成をオファーに含めることができます。「m =」行に含まれています。
The procedures defined in the following subsections apply to both unicast and multicast streams.
次のサブセクションで定義されている手順は、ユニキャストストリームとマルチキャストストリームの両方に適用されます。
An offerer that wants to use the SDP Capability Negotiation defined in this document MUST include the following in the offer:
このドキュメントで定義されているSDP機能交渉を使用したい提供者は、オファーに以下を含める必要があります。
o Zero or more attribute capability attributes. There MUST be an attribute capability attribute ("a=acap") as defined in Section 3.4.1 for each attribute name and associated value (if any) that needs to be indicated as a capability in the offer. Attribute capabilities may be included irrespective of whether or not they are referenced by a potential configuration.
o ゼロ以上の属性機能属性。オファーの機能として示される必要がある各属性名と関連する値（存在する場合）について、セクション3.4.1で定義されている属性機能属性（ "a = acap"）が必要です。属性機能は、潜在的な構成によって参照されるかどうかに関係なく含まれる場合があります。
Session-level attributes and associated values MUST be provided in attribute capabilities only at the session level, whereas media-level attributes and associated values can be provided in attribute capabilities at either the media level or session level. Attributes that are allowed at either the session or media level can be provided in attribute capabilities at either level.
セッションレベルの属性と関連する値は、セッションレベルでのみ属性機能で提供する必要がありますが、メディアレベルの属性と関連する値は、メディアレベルまたはセッションレベルのいずれかで属性機能で提供できます。セッションレベルまたはメディアレベルで許可される属性は、いずれかのレベルで属性機能で提供できます。
o Zero or more transport protocol capability attributes. There MUST be transport protocol capabilities as defined in Section 3.4.2 with values for each transport protocol that needs to be indicated as a capability in the offer.
o ゼロ以上の輸送プロトコル機能属性。セクション3.4.2で定義されている輸送プロトコル機能は、オファーの機能として示される必要がある各輸送プロトコルの値を含む必要があります。
Transport protocol capabilities may be included irrespective of whether or not they are referenced by a potential configuration. Transport protocols that apply to multiple media descriptions SHOULD be provided as transport protocol capabilities at the session level whereas transport protocols that apply only to a specific media description ("m=" line), SHOULD be provided as transport protocol capabilities within that particular media description. In either case, there MUST NOT be more than a single "a=tcap" attribute at the session level and a single "a=tcap" attribute in each media description.
輸送プロトコル機能は、潜在的な構成によって参照されるかどうかに関係なく含まれる場合があります。複数のメディアの説明に適用されるトランスポートプロトコルは、セッションレベルでの輸送プロトコル機能として提供する必要がありますが、特定のメディアの説明（ "m =" line）にのみ適用される輸送プロトコルは、その特定のメディアの説明内の輸送プロトコル機能として提供する必要があります。。どちらの場合でも、セッションレベルに単一の「a = tcap」属性と、各メディアの説明に単一の「a = tcap」属性があることはないはずです。
o Zero or more extension capability attributes. There MUST be one or more extension capability attributes (as outlined in Section 3.4.3) for each extension capability that is referenced by a potential configuration. Extension capability attributes that are not referenced by a potential configuration can be provided as well.
o ゼロ以上の拡張機能属性。潜在的な構成によって参照される各拡張機能に、1つ以上の拡張機能属性（セクション3.4.3で概説されている）が必要です。潜在的な構成によって参照されていない拡張機能属性も提供できます。
o Zero or more potential configuration attributes. There MUST be one or more potential configuration attributes ("a=pcfg"), as defined in Section 3.5.1, in each media description where alternative potential configurations are to be negotiated. Each potential configuration attribute MUST adhere to the rules provided in Section 3.5.1 and the additional rules provided below.
o ゼロ以上の潜在的な構成属性。セクション3.5.1で定義されているように、1つ以上の潜在的な構成属性（ "a = pcfg"）が必要です。各潜在的な構成属性は、セクション3.5.1で提供されているルールと、以下に示す追加のルールに準拠する必要があります。
If the offerer requires support for one or more extensions (besides the base protocol defined here), then the offerer MUST include one or more "a=creq" attributes as follows:
オファーが1つ以上の拡張機能をサポートする必要がある場合（ここで定義されているベースプロトコル以外）、オファーは次のように1つ以上の「a = creq」属性を含める必要があります。
o If support for one or more capability negotiation extensions is required for the entire session description, then option tags for those extensions MUST be included in a single session-level "creq" attribute.
o セッションの説明全体に1つ以上の機能交渉拡張機能のサポートが必要な場合は、それらの拡張機能のオプションタグを単一のセッションレベルの「CREQ」属性に含める必要があります。
o For each media description that requires support for one or more capability negotiation extensions not listed at the session level, a single "creq" attribute containing all the required extensions for that media description MUST be included within the media description (in accordance with Section 3.3.2).
o セッションレベルにリストされていない1つ以上の機能交渉拡張機能をサポートする必要がある各メディアの説明について、そのメディアの説明に必要なすべての拡張機能を含む単一の「CREQ」属性は、メディアの説明に含める必要があります（セクション3.3に従って。2）。
Note that extensions that only need to be supported by a particular potential configuration can use the "mandatory" extension prefix ("+") within the potential configuration (see Section 3.5.1).
特定の潜在的な構成によってのみサポートする必要がある拡張機能は、潜在的な構成内で「必須」拡張プレフィックス（ ""）を使用できることに注意してください（セクション3.5.1を参照）。
The offerer SHOULD furthermore include the following:
提供者にはさらに、以下を含める必要があります。
o A supported capability negotiation extension attribute ("a=csup") at the session level and/or media level as defined in Section 3.3.2 for each capability negotiation extension supported by the offerer and not included in a corresponding "a=creq" attribute (i.e., at the session level or in the same media description). Option tags provided in a "a=csup" attribute at the session level indicate extensions supported for the entire session description, whereas option tags provided in a "a=csup" attribute in a media description indicate extensions supported for only that particular media description.
o セッションレベルおよび/またはメディアレベルでのサポートされている機能交渉拡張属性（ "a = csup"）は、オファー担当者によってサポートされ、対応する「a = creq」属性に含まれていない各能力交渉拡張拡張機能のセクション3.3.2で定義されています。（つまり、セッションレベルまたは同じメディアの説明）。セッションレベルの「a = csup」属性で提供されるオプションタグは、セッションの説明全体でサポートされている拡張機能を示しますが、メディアの説明の「a = csup」属性で提供されるオプションタグは、その特定のメディアの説明のみでサポートされている拡張機能を示します。
Capabilities provided in an offer merely indicate what the offerer is capable of doing. They do not constitute a commitment or even an indication to use them. In contrast, each potential configuration constitutes an alternative offer that the offerer would like to use. The potential configurations MUST be used by the answerer to negotiate and establish the session.
オファーで提供される機能は、オファーができることを単に示しているだけです。それらは、それらを使用するというコミットメントや兆候でさえありません。対照的に、各潜在的な構成は、オファーが使用したい代替オファーを構成します。潜在的な構成は、セッションをネゴシエートして確立するために、Answererが使用する必要があります。
The offerer MUST include one or more potential configuration attributes ("a=pcfg") in each media description where the offerer wants to provide alternative offers (in the form of potential configurations). Each potential configuration attribute in a given media description MUST contain a unique configuration number and zero, one or more potential configuration lists, as described in Section 3.5.1. Each potential configuration list MUST refer to capabilities that are provided at the session level or within that particular media description; otherwise, the potential configuration is considered invalid. The base SDP Capability Negotiation framework REQUIRES that potential configurations not reference any session-level attribute capabilities that contain media-level-only attributes; however, extensions may modify this behavior, as long as it is fully backwards compatible with the base specification. Furthermore, it is RECOMMENDED that potential configurations avoid use of session-level capabilities whenever possible; refer to Section 3.5.1.
オファーは、各メディアの説明に、1つ以上の潜在的な構成属性（ "a = pcfg"）を含める必要があります。特定のメディアの説明の各潜在的な構成属性には、セクション3.5.1で説明されているように、一意の構成番号とゼロ、1つ以上の潜在的な構成リストを含める必要があります。各潜在的な構成リストは、セッションレベルまたはその特定のメディアの説明内で提供される機能を参照する必要があります。それ以外の場合、潜在的な構成は無効と見なされます。ベースSDP機能交渉フレームワークでは、メディアレベルのみの属性を含むセッションレベルの属性機能を参照しない潜在的な構成が必要です。ただし、拡張機能は、ベース仕様と完全に逆方向に互換性がある限り、この動作を変更する場合があります。さらに、潜在的な構成は、可能な限りセッションレベルの機能の使用を避けることをお勧めします。セクション3.5.1を参照してください。
The current actual configuration is included in the "m=" line (as defined by [RFC3264]) and any associated parameters for the media description (e.g., attribute ("a=") and bandwidth ("b=") lines). Note that the actual configuration is by default the least-preferred configuration, and hence the answerer will seek to negotiate use of one of the potential configurations instead. If the offerer wishes a different preference for the actual configuration, the offerer MUST include a corresponding potential configuration with the relevant configuration number (which indicates the relative preference between potential configurations); this corresponding potential configuration should simply duplicate the actual configuration.
現在の実際の構成は、「m =」行（[rfc3264]で定義されている）と、メディアの説明（例：属性（ "a ="）および帯域幅（ "b ="）行）に関連するパラメーターに含まれています。実際の構成は、デフォルトでは最小限の構成であるため、newnerserは代わりに潜在的な構成の1つの使用を交渉しようとすることに注意してください。オファーが実際の構成に対して異なる選好を希望する場合、オファーは、関連する構成番号（潜在的な構成間の相対的な優先度を示す対応する潜在的な構成を含める必要があります。この対応する潜在的な構成は、実際の構成を単純に複製する必要があります。
This can either be done implicitly (by not referencing any capabilities), or explicitly (by providing and using capabilities for the transport protocol and all the attributes that are part of the actual configuration). The latter may help detect intermediaries that modify the actual configuration but are not SDP Capability Negotiation aware.
これは、暗黙的に（任意の機能を参照しないことで）、または明示的に（トランスポートプロトコルと実際の構成の一部であるすべての属性に機能を提供および使用することにより）実行できます。後者は、実際の構成を変更するが、SDP機能交渉ではない仲介者の検出に役立つ場合があります。
Per [RFC3264], once the offerer generates the offer, he must be prepared to receive incoming media in accordance with that offer. That rule applies here as well, but only for the actual configurations provided in the offer: Media received by the offerer according to one of the potential configurations MAY be discarded, until the offerer receives an answer indicating what the actual selected configuration is. Once that answer is received, incoming media MUST be processed in accordance with the actual selected configuration indicated and the answer received (provided the offer/answer exchange completed successfully).
[RFC3264]に従って、オファーがオファーを生成したら、そのオファーに従って入ってくるメディアを受け取る準備をしなければなりません。このルールもここに適用されますが、オファーで提供される実際の構成に対してのみです。潜在的な構成のいずれかに従って提供者が受け取ったメディアは、実際に選択された構成が何であるかを示す回答を受信するまで、廃棄される場合があります。その回答を受け取ったら、指定されたメディアは、示された実際の選択された構成と受け取った回答に従って処理する必要があります（オファー/回答の交換が正常に完了した場合）。
The above rule assumes that the offerer can determine whether incoming media adheres to the actual configuration offered or one of the potential configurations instead; this may not always be the case. If the offerer wants to ensure he does not play out any garbage, the offerer SHOULD discard all media received before the answer SDP session description is received. Conversely, if the offerer wants to avoid clipping, he SHOULD attempt to play any incoming media as soon as it is received (at the risk of playing out garbage). In either case, please note that this document does not place any requirements on the offerer to process and play media before answer. For further details, please refer to Section 3.9.
上記のルールは、提供者が、着信メディアが提供された実際の構成または代わりに潜在的な構成のいずれかを順守するかどうかを判断できることを前提としています。これが常にそうであるとは限りません。オファーがゴミをプレイしないようにしたい場合、SDPセッションの説明が受信される前に、提供者は受け取ったすべてのメディアを破棄する必要があります。逆に、オファーがクリッピングを避けたい場合、受信したらすぐに入ってくるメディアをプレイしようとする必要があります（ゴミを出すリスクがあります）。どちらの場合でも、このドキュメントでは、回答の前にメディアを処理および再生するために、提供者に要件を掲載していないことに注意してください。詳細については、セクション3.9を参照してください。
When receiving an offer, the answerer MUST check for the presence of a required capability negotiation extension attribute ("a=creq") provided at the session level. If one is found, then capability negotiation MUST be performed. If none is found, then the answerer MUST check each offered media description for the presence of a required capability negotiation extension attribute ("a=creq") and one or more potential configuration attributes ("a=pcfg"). Capability negotiation MUST be performed for each media description where either of those is present in accordance with the procedures described below.
オファーを受け取るとき、回答者は、セッションレベルで提供される必要な機能交渉拡張属性（ "a = creq"）の存在を確認する必要があります。見つかった場合、能力交渉を実行する必要があります。何も見つかっていない場合、回答者は、必要な機能交渉拡張属性（ "a = creq"）と1つ以上の潜在的な構成属性（ "a = pcfg"）の存在について、提供される各メディアの説明を確認する必要があります。能力交渉は、以下で説明する手順に従っていずれかが存在するメディアの説明ごとに実行する必要があります。
The answerer MUST first ensure that it supports any required capability negotiation extensions:
応答者は、最初に必要な機能交渉拡張をサポートすることを保証する必要があります。
o If a session-level "creq" attribute is provided, and it contains an option tag that the answerer does not support, then the answerer MUST NOT use any of the potential configuration attributes provided for any of the media descriptions. Instead, the normal offer/answer procedures MUST continue as per [RFC3264]. Furthermore, the answerer MUST include a session-level supported capability negotiation extensions attribute ("a=csup") with option tags for the capability negotiation extensions supported by the answerer.
o セッションレベルの「CREQ」属性が提供され、回答者がサポートしていないオプションタグが含まれている場合、回答者はメディアの説明に提供される潜在的な構成属性を使用してはなりません。代わりに、[RFC3264]に従って、通常のオファー/回答手順を継続する必要があります。さらに、回答者には、回答者がサポートする機能ネゴシエーション拡張機能のオプションタグを備えたセッションレベルのサポートされた機能ネゴシエーション拡張属性（ "a = csup"）を含める必要があります。
o If a media-level "creq" attribute is provided, and it contains an option tag that the answerer does not support, then the answerer MUST NOT use any of the potential configuration attributes provided for that particular media description. Instead, the offer/answer procedures for that media description MUST continue as per [RFC3264] (SDP Capability Negotiation is still performed for other media descriptions in the SDP session description). Furthermore, the answerer MUST include a supported capability negotiation extensions attribute ("a=csup") in that media description with option tags for the capability negotiation extensions supported by the answerer for that media description.
o メディアレベルの「CREQ」属性が提供され、回答者がサポートしていないオプションタグが含まれている場合、Answererはその特定のメディアの説明に提供される潜在的な構成属性を使用してはなりません。代わりに、そのメディアの説明のオファー/回答手順は、[RFC3264]に従って継続する必要があります（SDPセッションの説明で他のメディアの説明に対してSDP機能交渉はまだ実行されます）。さらに、回答者には、そのメディアの説明のために回答者によってサポートされている機能交渉拡張機能のオプションタグを使用して、そのメディアの説明にサポートされている機能ネゴシエーション拡張属性（ "a = csup"）を含める必要があります。
Assuming all required capability negotiation extensions are supported, the answerer now proceeds as follows.
必要なすべての機能交渉がサポートされていると仮定すると、回答者は次のように進行します。
For each media description where capability negotiation is to be performed (i.e., all required capability negotiation extensions are supported and at least one valid potential configuration attribute is present), the answerer MUST perform capability negotiation by using the most preferred potential configuration that is valid to the answerer, subject to any local policies. A potential configuration is valid to the answerer if:
機能交渉を実行する各メディアの説明について（つまり、必要なすべての機能交渉拡張機能がサポートされ、少なくとも1つの有効な潜在的な構成属性が存在する）。回答者は、ローカルポリシーの対象となります。潜在的な構成は、次の場合の回答者にとって有効です。
1. It is in accordance with the syntax and semantics provided in Section 3.5.1.
1. セクション3.5.1で提供されている構文とセマンティクスに従っています。
2. It contains a configuration number that is unique within that media description.
2. そのメディアの説明内で一意の構成番号が含まれています。
3. All attribute capabilities referenced by the potential configuration are valid themselves (as defined in Section 3.4.1) and each of them is provided either at the session level or within this particular media description.
3. 潜在的な構成によって参照されるすべての属性機能は、それ自体が有効であり（セクション3.4.1で定義されています）、それぞれがセッションレベルまたはこの特定のメディアの説明内で提供されます。
For session-level attribute capabilities referenced, the attributes contained inside them MUST NOT be media-level-only attributes. Note that the answerer can only determine this for attributes supported by the answerer. If an attribute is not supported, it will simply be ignored by the answerer and hence will not trigger an "invalid" potential configuration.
参照されるセッションレベルの属性機能の場合、その中に含まれる属性は、メディアレベルのみの属性であってはなりません。Answererは、Answererによってサポートされている属性に対してのみこれを決定できることに注意してください。属性がサポートされていない場合、それは単に回答者によって無視されるため、「無効な」潜在的な構成をトリガーしません。
4. All transport protocol capabilities referenced by the potential configuration are valid themselves (as defined in Section 3.4.2) and each of them is furthermore provided either at the session level or within this particular media description.
4. 潜在的な構成によって参照されるすべての輸送プロトコル機能は、それ自体が有効であり（セクション3.4.2で定義されています）、それぞれがセッションレベルまたはこの特定のメディアの説明内で提供されます。
5. All extension capabilities referenced by the potential configuration and supported by the answerer are valid themselves (as defined by that particular extension) and each of them are furthermore provided either at the session level or within this particular media description. Unknown or unsupported extension capabilities MUST be ignored, unless they are prefixed with the plus ("+") sign, which indicates that the extension MUST be supported in order to use that potential configuration. If the extension is not supported, that potential configuration is not valid to the answerer.
5. 潜在的な構成によって参照され、回答者によってサポートされるすべての拡張機能は、それ自体が有効であり（その特定の拡張機能で定義されています）、それぞれがセッションレベルまたはこの特定のメディアの説明内で提供されます。不明またはサポートされていない拡張機能は、その潜在的な構成を使用するために拡張機能をサポートする必要があることを示すPlus（ ""）サインが付いている場合を除き、無視する必要があります。拡張機能がサポートされていない場合、その潜在的な構成は回答者にとって有効ではありません。
The most preferred valid potential configuration in a media description is the valid potential configuration with the lowest configuration number. The answerer MUST now process the offer for that media stream based on the most preferred valid potential configuration. Conceptually, this entails the answerer constructing an (internal) offer as follows. First, all capability negotiation parameters from the offer SDP session description are removed, thereby yielding an offer SDP session description with the actual configuration as if SDP Capability Negotiation was not done in the first place. Secondly, this actual configuration SDP session description is modified as follows for each media stream offered, based on the capability negotiation parameters included originally:
メディアの説明で最も好ましい有効な潜在的な構成は、最低の構成番号を持つ有効な潜在的な構成です。回答者は、最も優先される有効な潜在的な構成に基づいて、そのメディアストリームのオファーを処理する必要があります。概念的には、これには次のように（内部）オファーを構築する回答者が必要です。まず、オファーSDPセッションの説明からのすべての機能交渉パラメーターが削除され、それにより、SDP機能交渉がそもそも行われていないかのように、実際の構成でオファーSDPセッションの説明が得られます。第二に、この実際の構成SDPセッションの説明は、元々含まれる機能交渉パラメーターに基づいて、提供される各メディアストリームについて次のように変更されます。
o If a transport protocol capability is included in the potential configuration, then it replaces the transport protocol provided in the "m=" line for that media description.
o トランスポートプロトコル機能が潜在的な構成に含まれている場合、そのメディアの説明の「m =」行で提供されるトランスポートプロトコルを置き換えます。
o If attribute capabilities are present with a delete-attributes session indication ("-s") or media and session indication ("-ms"), then all session-level attributes from the actual configuration SDP session description MUST be deleted in the resulting potential configuration SDP session description in accordance with the procedures in Section 3.5.1. If attribute capabilities are present with a delete-attributes media indication ("-m") or media and session indication ("-ms"), then all attributes from the actual configuration SDP session description inside this media description MUST be deleted.
o 属性機能に削除アトリブスセッション表示（ "-s"）またはメディアおよびセッション表示（ "-ms"）が存在する場合、実際の構成からのすべてのセッションレベルの属性は、結果のポテンシャルで削除する必要があります。構成SDPセッションの説明セクション3.5.1の手順に従って。属性機能が削除アトリブメディア表示（ "-m"）またはメディアおよびセッション表示（ "-ms"）に存在する場合、このメディアの説明内の実際の構成SDPセッションの説明からのすべての属性を削除する必要があります。
o If a session-level attribute capability is included, the attribute (and its associated value, if any) contained in it MUST be added to the resulting SDP session description. All such added session-level attributes MUST be listed before the session-level attributes that were initially present in the SDP session description. Furthermore, the added session-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1).
o セッションレベルの属性機能が含まれている場合、その中に含まれる属性（およびその関連する値）を、結果のSDPセッションの説明に追加する必要があります。このような追加のセッションレベルの属性はすべて、SDPセッションの説明に最初に存在していたセッションレベルの属性の前にリストする必要があります。さらに、追加のセッションレベルの属性を、潜在的な構成で提供された順序で追加する必要があります（セクション3.5.1も参照）。
This allows for attributes with implicit preference ordering to be added in the desired order; the "crypto" attribute [RFC4568] is one such example.
これにより、暗黙的な優先順序を持つ属性を希望の順序で追加できます。「Crypto」属性[RFC4568]はそのような例の1つです。
o If a media-level attribute capability is included, then the attribute (and its associated value, if any) MUST be added to the resulting SDP session description within the media description in question. All such added media-level attributes MUST be listed before the media-level attributes that were initially present in the media description in question. Furthermore, the added media-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1).
o メディアレベルの属性機能が含まれている場合、属性（および関連する値があれば）を、問題のメディア説明内の結果のSDPセッションの説明に追加する必要があります。このような追加されたメディアレベルの属性はすべて、問題のメディアの説明に最初に存在していたメディアレベルの属性の前にリストする必要があります。さらに、追加されたメディアレベルの属性は、潜在的な構成で提供された順序で追加する必要があります（セクション3.5.1も参照）。
o If a supported extension capability is included, then it MUST be processed in accordance with the rules provided for that particular extension capability.
o サポートされている拡張機能が含まれている場合、その特定の拡張機能に提供されるルールに従って処理する必要があります。
The above steps MUST be performed exactly once per potential configuration, i.e., there MUST NOT be any recursive processing of any additional capability negotiation parameters that may (illegally) have been nested inside capabilities themselves.
上記の手順は、潜在的な構成ごとに正確に1回実行する必要があります。つまり、（違法に）能力自体にネストされている可能性のある追加の機能交渉パラメーターの再帰処理が必要です。
As an example of this, consider the (illegal) attribute capability
この例として、（違法な）属性機能を考慮してください
a=acap:1 acap:2 foo:a
The resulting potential configuration SDP session description will, after the above processing has been done, contain the attribute capability
結果の潜在的な構成SDPセッションの説明は、上記の処理が行われた後、属性機能が含まれます
a=acap:2 foo:a
However, since we do not perform any recursive processing of capability negotiation parameters, this second attribute capability parameter will not be processed by the offer/answer procedure. Instead, it will simply appear as a (useless) attribute in the SDP session description that will be ignored by further processing.
ただし、機能交渉パラメーターの再帰処理を実行しないため、この2番目の属性機能パラメーターは、オファー/回答手順によって処理されません。代わりに、SDPセッションの説明に（役に立たない）属性として単に表示されます。これは、さらに処理することで無視されます。
Note that a transport protocol from the potential configuration replaces the transport protocol in the actual configuration, but an attribute capability from the potential configuration is simply added to the actual configuration. In some cases, this can result in having one or more meaningless attributes in the resulting potential configuration SDP session description, or worse, ambiguous or potentially even illegal attributes. Use of delete-attributes for the session- and/or media-level attributes MUST be done to avoid such scenarios. Nevertheless, it is RECOMMENDED that implementations ignore meaningless attributes that may result from potential configurations.
潜在的な構成からのトランスポートプロトコルは、実際の構成のトランスポートプロトコルを置き換えますが、潜在的な構成からの属性機能は実際の構成に追加されることに注意してください。場合によっては、結果として生じる潜在的な構成SDPセッションの説明に1つ以上の意味のない属性を持つことになる可能性があります。このようなシナリオを避けるために、セッションおよび/またはメディアレベルの属性に削除することを使用する必要があります。それにもかかわらず、実装は潜在的な構成から生じる可能性のある意味のない属性を無視することをお勧めします。
For example, if the actual configuration was using Secure RTP and included an "a=crypto" attribute for the SRTP keying material, then use of a potential configuration that uses plain RTP would make the "crypto" attribute meaningless. The answerer may or may not ignore such a meaningless attribute. The offerer can here ensure correct operation by using delete-attributes to remove the "crypto" attribute (but will then need to provide attribute capabilities to reconstruct the SDP session description with the necessary attributes deleted, e.g., rtpmaps).
たとえば、実際の構成がSecure RTPを使用しており、SRTPキーイング材料の「A = Crypto」属性を含めていた場合、Plain RTPを使用する潜在的な構成を使用すると、「Crypto」属性が無意味になります。応答者は、そのような意味のない属性を無視する場合と無視しない場合があります。ここでは、「delete-aTtributesを使用して「crypto」属性を削除することにより、ここで正しい操作を保証できます（ただし、削除された必要な属性、たとえばrtpmapsを使用してSDPセッションの説明を再構築するための属性機能を提供する必要があります）。
Also note, that while it is permissible to include media-level attribute capabilities at the session level, the base SDP Capability Negotiation framework defined here does not define any procedures for use of them, i.e., the answerer effectively ignores them.
また、セッションレベルにメディアレベルの属性機能を含めることは許可されていますが、ここで定義されているベースSDP機能交渉フレームワークは、それらの使用手順を定義しないこと、つまり、回答者が効果的に無視することには定義されていないことに注意してください。
Please refer to Section 3.6.2.1 for examples of how the answerer may conceptually "see" the resulting offered alternative potential configurations.
応答者が、結果として提供される代替潜在的な構成を概念的に「見る」方法の例については、セクション3.6.2.1を参照してください。
The answerer MUST check that he supports all mandatory attribute capabilities from the potential configuration (if any), the transport protocol capability (if any) from the potential configuration, and all mandatory extension capabilities from the potential configuration (if any). If he does not, the answerer MUST proceed to the second most preferred valid potential configuration for the media description, etc.
回答者は、潜在的な構成（もしあれば）からすべての必須属性機能、潜在的な構成からのトランスポートプロトコル機能（もしあれば）、および潜在的な構成からのすべての必須拡張機能（存在する場合）をサポートすることを確認する必要があります。彼がそうしない場合、答い人はメディアの説明などで2番目に優先される有効な潜在的な構成に進む必要があります。
o In the case of attribute capabilities, support implies that the attribute name contained in the capability is supported and it can (and will) be negotiated successfully in the offer/answer exchange with the value provided. This does not necessarily imply that the value provided is supported in its entirety. For example, the "a=fmtp" parameter is often provided with one or more values in a list, where the offerer and answerer negotiate use of some subset of the values provided. Other attributes may include mandatory and optional parts to their values; support for the mandatory part is all that is required here.
o 属性機能の場合、サポートは、機能に含まれる属性名がサポートされており、提供された値とオファー/回答交換で正常に交渉できることを意味します。これは、提供された値が完全にサポートされていることを必ずしも意味するものではありません。たとえば、「a = fmtp」パラメーターには、多くの場合、リスト内の1つ以上の値が提供され、提供者と回答者が提供された値のサブセットの使用を交渉します。その他の属性には、その価値に対する必須およびオプションのパーツが含まれる場合があります。必須部分のサポートは、ここで必要なすべてです。
A side effect of the above rule is that whenever an "fmtp" or "rtpmap" parameter is provided as a mandatory attribute capability, the corresponding media format (codec) must be supported and use of it negotiated successfully. If this is not the offerer's intent, the corresponding attribute capabilities must be listed as optional instead.
上記のルールの副作用は、「FMTP」または「RTPMAP」パラメーターが必須属性機能として提供される場合、対応するメディア形式（CODEC）をサポートし、ITの使用を正常に使用する必要があることです。これがオファーの意図ではない場合、対応する属性機能は代わりにオプションとしてリストする必要があります。
o In the case of transport protocol capabilities, support implies that the transport protocol contained in the capability is supported and the transport protocol can (and will) be negotiated successfully in the offer/answer exchange.
o 輸送プロトコル機能の場合、サポートは、機能に含まれる輸送プロトコルがサポートされ、輸送プロトコルがオファー/回答の交換で正常に交渉できることを意味します。
o In the case of extension capabilities, the extension MUST define the rules for when the extension capability is considered supported and those rules MUST be satisfied.
o 拡張機能の場合、拡張機能は、拡張機能がサポートされていると見なされ、それらのルールを満たす必要がある場合のルールを定義する必要があります。
If the answerer has exhausted all potential configurations for the media description, without finding a valid one that is also supported, then the answerer MUST process the offered media stream based on the actual configuration plus any session-level attributes added by a valid and supported potential configuration from another media description in the offered SDP session description.
回答者がメディアの説明のすべての潜在的な構成を使い果たした場合、またサポートされている有効なものを見つけることなく、回答者は、実際の構成に基づいて提供されるメディアストリームと、有効でサポートされているポテンシャルによって追加されたセッションレベルの属性に基づいて処理する必要があります。提供されるSDPセッションの説明の別のメディアの説明からの構成。
The above process describes potential configuration selection as a per-media-stream process. Inter-media stream coordination of selected potential configurations however is required in some cases. First of all, session-level attributes added by a potential configuration for one media description MUST NOT cause any problems for potential configurations selected by other media descriptions in the offer SDP session description. If the session-level attributes are mandatory, then those session-level attributes MUST furthermore be supported by the session as a whole (i.e., all the media descriptions if relevant). As mentioned earlier, this adds additional complexity to the overall processing and hence it is RECOMMENDED not to use session-level attribute capabilities in potential configurations, unless absolutely necessary.
上記のプロセスでは、潜在的な構成選択がメディアスリーストリームプロセスとして説明されています。ただし、選択された潜在的な構成のメディア間ストリーム調整が必要な場合には必要です。まず、1つのメディアの説明に潜在的な構成によって追加されたセッションレベルの属性は、オファーSDPセッションの説明で他のメディアの説明によって選択された潜在的な構成に問題を引き起こしてはなりません。セッションレベルの属性が必須である場合、これらのセッションレベルの属性は、さらにセッション全体によってサポートされる必要があります（つまり、関連する場合はすべてのメディアの説明）。前述のように、これは全体的な処理に追加の複雑さを追加するため、絶対に必要な場合を除き、潜在的な構成でセッションレベルの属性機能を使用しないことをお勧めします。
Once the answerer has selected a valid and supported offered potential configuration for all of the media streams (or has fallen back to the actual configuration plus any added session attributes), the answerer MUST generate a valid virtual answer SDP session description based on the selected potential configuration SDP session description, as "seen" by the answerer using normal offer/answer rules (see Section 3.6.2.1 for examples). The actual answer SDP session description is formed from the virtual answer SDP session description as follows: if the answerer selected one of the potential configurations in a media description, the answerer MUST include an actual configuration attribute ("a=acfg") within that media description. The "a=acfg" attribute MUST identify the configuration number for the selected potential configuration as well as the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included. Only the known and supported parameters will be included. Unknown or unsupported parameters MUST NOT be included in the actual configuration attribute. In the case of attribute capabilities, only the known and supported capabilities are included; unknown or unsupported attribute capabilities MUST NOT be included.
Answererが有効でサポートされている提供された提供された潜在的な構成をすべてのメディアストリームに選択したら（または実際の構成と追加のセッション属性に戻る）、回答者は選択されたポテンシャルに基づいて有効な仮想回答SDPセッション説明を生成する必要があります。構成SDPセッションの説明。通常のオファー/回答ルールを使用して、回答者によって「見られる」ようです（例についてはセクション3.6.2.1を参照）。実際の回答SDPセッションの説明は、仮想回答SDPセッションの説明から次のように形成されます。応答者がメディアの説明で潜在的な構成のいずれかを選択した場合、回答者にはそのメディア内に実際の構成属性（ "a = acfg"）を含める必要があります説明。「A = ACFG」属性は、選択した潜在的な構成の構成番号と、その潜在的な構成から使用された実際のパラメーターを識別する必要があります。潜在的な構成に代替案が含まれている場合、選択した代替案のみを含める必要があります。既知のパラメーターとサポートされたパラメーターのみが含まれます。不明またはサポートされていないパラメーターを実際の構成属性に含めてはなりません。属性機能の場合、既知およびサポートされた機能のみが含まれています。不明またはサポートされていない属性機能を含めてはなりません。
If the answerer supports one or more capability negotiation extensions that were not included in a required capability negotiation extensions attribute in the offer, then the answerer SHOULD furthermore include a supported capability negotiation attribute ("a=csup") at the session level with option tags for the extensions supported across media streams. Also, if the answerer supports one or more capability negotiation extensions for only particular media descriptions, then a supported capability negotiation attribute with those option tags SHOULD be included within each relevant media description. The required capability negotiation attribute ("a=creq") MUST NOT be used in an answer.
Answererがオファーの必要な機能交渉拡張属性に含まれていない1つ以上の機能交渉拡張機能をサポートしている場合、Answererには、オプションタグ付きのセッションレベルでサポートされた機能交渉属性（「A = CSUP」）をサポートする必要があります。メディアストリーム全体でサポートされる拡張機能の場合。また、Answererが特定のメディアの説明のみに対して1つ以上の機能交渉拡張機能をサポートする場合、それらのオプションタグを使用したサポートされている機能交渉属性を、関連する各メディアの説明に含める必要があります。必要な機能交渉属性（ "a = creq"）は、回答で使用してはなりません。
The offerer's originally provided actual configuration is contained in the offer media description's "m=" line (and associated parameters). The answerer MAY send media to the offerer in accordance with that actual configuration as soon as it receives the offer; however, it MUST NOT send media based on that actual configuration if it selects an alternative potential configuration. If the answerer selects one of the potential configurations, then the answerer MAY immediately start to send media to the offerer in accordance with the selected potential configuration; however, the offerer MAY discard such media or play out garbage until the offerer receives the answer. Please refer to Section 3.9. for additional considerations and possible alternative solutions outside the base SDP Capability Negotiation framework.
提供者は当初、実際の構成を提供しています。オファーメディアの説明の「m =」行（および関連するパラメーター）に含まれています。応答者は、オファーを受け取ったらすぐに、その実際の構成に従ってメディアをオファーに送信する場合があります。ただし、代替の潜在的な構成を選択した場合、その実際の構成に基づいてメディアを送信してはなりません。Answererが潜在的な構成の1つを選択した場合、Answererは、選択した潜在的な構成に従って、すぐにオファーにメディアを送信し始めることがあります。ただし、オファーは、そのようなメディアを廃棄したり、オファーが答えを受け取るまでゴミを弾くことがあります。セクション3.9を参照してください。ベースSDP機能交渉フレームワークの外側の追加の考慮事項と可能な代替ソリューション。
If the answerer selected a potential configuration instead of the actual configuration, then it is RECOMMENDED that the answerer send back an answer SDP session description as soon as possible. This minimizes the risk of having media discarded or played out as garbage by the offerer. In the case of SIP [RFC3261] without any extensions, this implies that if the offer was received in an INVITE message, then the answer SDP session description should be provided in the first non-100 provisional response sent back (per RFC 3261, the answer would need to be repeated in the 200 response as well, unless a relevant extension such as [RFC3262] is being used).
回答者が実際の構成の代わりに潜在的な構成を選択した場合、Answererが回答SDPセッションの説明をできるだけ早く送信することをお勧めします。これにより、メディアが提供者によるゴミとして廃棄または展開されるリスクが最小限に抑えられます。拡張機能のないSIP [RFC3261]の場合、これは、オファーが招待メッセージで受信された場合、回答SDPセッションの説明を最初の非100暫定応答（RFC 3261、[RFC3262]などの関連する拡張機能が使用されていない限り、回答も200応答で繰り返す必要があります）。
The following examples illustrate how the answerer may conceptually "see" a potential configuration. Consider the following offered SDP session description:
以下の例は、Answererが潜在的な構成を概念的に「見る」方法を示しています。以下の提供されるSDPセッションの説明を検討してください。
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVP RTP/AVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 t=1 a=1|3
This particular SDP session description offers an audio stream and a video stream, each of which can either use plain RTP (actual configuration) or Secure RTP (potential configuration). Furthermore, two different keying mechanisms are offered, namely session-level Key Management Extensions using MIKEY (attribute capability 1) and media-level SDP security descriptions (attribute capabilities 2 and 3). There are several potential configurations here, however, below we show the one the answerer "sees" when using potential configuration 1 for both audio and video, and furthermore using attribute capability 1 (MIKEY) for both (we have removed all the capability negotiation attributes for clarity):
この特定のSDPセッションの説明は、オーディオストリームとビデオストリームを提供します。それぞれがプレーンRTP（実際の構成）またはセキュアRTP（潜在的な構成）を使用できます。さらに、Mikey（属性機能1）とメディアレベルのSDPセキュリティ説明（属性機能2および3）を使用したセッションレベルのキー管理拡張機能、つまり2つの異なるキーイングメカニズムが提供されます。ここにはいくつかの潜在的な構成がありますが、以下に、オーディオとビデオの両方に潜在的な構成1を使用するときに回答者が「表示する」ものを示し、さらに両方に属性機能1（Mikey）を使用します（すべての機能交渉属性を削除しました明確にするために）：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
Note that the transport protocol in the media descriptions indicate use of Secure RTP.
メディアの説明の輸送プロトコルは、安全なRTPの使用を示していることに注意してください。
Below, we show the offer the answerer "sees" when using potential configuration 1 for both audio and video and furthermore using attribute capability 2 and 3, respectively, (SDP security descriptions) for the audio and video stream -- note the order in which the resulting attributes are provided:
以下に、オーディオとビデオの両方に潜在的な構成1を使用し、さらに属性機能2と3を使用して、オーディオとビデオストリームの属性機能2と3を使用する場合、応募者は「See Shees」を示します。結果の属性が提供されます：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
Again, note that the transport protocol in the media descriptions indicate use of Secure RTP.
繰り返しますが、メディアの説明の輸送プロトコルは、安全なRTPの使用を示していることに注意してください。
And finally, we show the offer the answerer "sees" when using potential configuration 1 with attribute capability 1 (MIKEY) for the audio stream, and potential configuration 1 with attribute capability 3 (SDP security descriptions) for the video stream:
そして最後に、オーディオストリームに属性機能1（Mikey）を備えた潜在的な構成1を使用するときに「shies shees」のオファーを示し、ビデオストリームの属性機能3（SDPセキュリティ記述）を備えた潜在的な構成1を示します。
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
When the offerer attempted to use SDP Capability Negotiation in the offer, the offerer MUST examine the answer for actual use of SDP Capability Negotiation.
オファーがオファーでSDP機能交渉を使用しようとしたとき、オファーはSDP機能交渉の実際の使用の答えを調べなければなりません。
For each media description where the offerer included a potential configuration attribute ("a=pcfg"), the offerer MUST first examine that media description for the presence of a valid actual configuration attribute ("a=acfg"). An actual configuration attribute is valid if:
オファーが潜在的な構成属性（ "a = pcfg"）を含む各メディアの説明について、オファーは最初に有効な実際の構成属性（ "a = acfg"）の存在についてそのメディアの説明を調べる必要があります。実際の構成属性は、次の場合に有効です。
o it refers to a potential configuration that was present in the corresponding offer, and
o 対応するオファーに存在する潜在的な構成を指し、
o it contains the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included. Note that the answer will include only parameters and attribute capabilities that are known and supported by the answerer, as described in Section 3.6.2.
o その潜在的な構成から使用された実際のパラメーターが含まれています。潜在的な構成に代替案が含まれている場合、選択した代替案のみを含める必要があります。回答には、セクション3.6.2で説明されているように、回答者によって既知およびサポートされているパラメーターと属性機能のみが含まれることに注意してください。
If a valid actual configuration attribute is not present in a media description, then the offerer MUST process the answer SDP session description for that media stream per the normal offer/answer rules defined in [RFC3264]. However, if a valid one is found, the offerer MUST instead process the answer as follows:
有効な実際の構成属性がメディアの説明に存在しない場合、オファーは[RFC3264]で定義されている通常のオファー/回答ルールごとに、そのメディアストリームの回答SDPセッションの説明を処理する必要があります。ただし、有効なものが見つかった場合、提供者は代わりに次のように答えを処理する必要があります。
o The actual configuration attribute specifies which of the potential configurations was used by the answerer to generate the answer for this media stream. This includes all the supported attribute capabilities and the transport capabilities referenced by the potential configuration selected, where the attribute capabilities have any associated delete-attributes included. Extension capabilities supported by the answerer are included as well.
o 実際の構成属性は、このメディアストリームの回答を生成するために、回答者によって使用された潜在的な構成のどれを指定します。これには、すべてのサポートされている属性機能と、選択された潜在的な構成によって参照されるトランスポート機能が含まれます。回答者によってサポートされる拡張機能も含まれています。
o The offerer MUST now process the answer in accordance with the rules in [RFC3264], except that it must be done as if the offer consisted of the selected potential configuration instead of the original actual configuration, including any transport protocol changes in the media ("m=") line(s), attributes added and deleted by the potential configuration at the media and session level, and any extensions used. If this derived answer is not a valid answer to the potential configuration offer selected by the answerer, the offerer MUST instead continue further processing as it would have for a regular offer/answer exchange, where the answer received does not adhere to the rules of [RFC3264].
o オファーは、[RFC3264]のルールに従って答えを処理する必要があります。ただし、オファーは、メディアの輸送プロトコルの変更を含む、元の実際の構成の代わりに選択された潜在的な構成で構成されているかのように行う必要があります（」m = "）行、属性、メディアレベルとセッションレベルでの潜在的な構成によって追加および削除された属性、および使用される拡張機能。この導出された回答が、回答者によって選択された潜在的な構成オファーに対する有効な回答ではない場合、提供者は代わりに、受け取った回答が[[）のルールを順守しない通常のオファー/回答交換のためにさらに処理を続ける必要があります。RFC3264]。
If the offer/answer exchange was successful, and if the answerer selected one of the potential configurations from the offer as the actual configuration, and the selected potential configuration differs from the actual configuration in the offer (the "m=", "a=", etc., lines), then the offerer SHOULD initiate another offer/answer exchange. This second offer/answer exchange will not modify the session in any way; however, it will help intermediaries (e.g., middleboxes), which look at the SDP session description but do not support the capability negotiation extensions, understand the details of the media stream(s) that were actually negotiated. This new offer MUST contain the selected potential configuration as the actual configuration, i.e., with the actual configuration used in the "m=" line and any other relevant attributes, bandwidth parameters, etc.
オファー/回答の交換が成功し、応答者が実際の構成としてオファーから潜在的な構成の1つを選択し、選択された潜在的な構成がオファーの実際の構成とは異なる場合（ "m ="、 "a =「など、行）、その後、オファーは別のオファー/回答交換を開始する必要があります。この2番目のオファー/回答交換は、セッションを決して変更しません。ただし、SDPセッションの説明を調べるが、機能交渉の拡張をサポートせず、実際に交渉されたメディアストリームの詳細を理解する仲介者（例：ミドルボックス）が役立ちます。この新しいオファーには、選択した潜在的な構成が実際の構成として、つまり「m =」行およびその他の関連属性、帯域幅パラメーターなどで使用される実際の構成を含む必要があります。
Note that, per normal offer/answer rules, the second offer/answer exchange still needs to update the version number in the "o=" line (<sess-version> in [RFC4566]). Attribute lines carrying keying material SHOULD repeat the keys from the previous offer, unless re-keying is necessary, e.g., due to a previously forked SIP INVITE request. Please refer to Section 3.12 for additional considerations related to intermediaries.
通常のオファー/回答ルールごとに、2番目のオファー/回答交換は、[rfc4566]の「o =」行（<sess-version>）のバージョン番号を更新する必要があることに注意してください。キーイング素材を運ぶ属性ラインは、以前にフォークされたSIP招待リクエストのために、再キーイングが必要な場合を除き、以前のオファーからキーを繰り返す必要があります。仲介者に関連する追加の考慮事項については、セクション3.12を参照してください。
Capabilities and potential configurations may be included in subsequent offers as defined in [RFC3264], Section 8. The procedure for doing so is similar to that described above with the answer including an indication of the actual selected configuration used by the answerer.
[RFC3264]、セクション8で定義されている後続のオファーには、セクション8に含まれる機能と潜在的な構成を含めることができます。これを行うための手順は、回答者が使用する実際の選択された構成の兆候を含む回答と類似しています。
If the answer indicates use of a potential configuration from the offer, then the guidelines provided in Section 3.6.3 for doing a second offer/answer exchange using that potential configuration as the actual configuration apply.
回答がオファーからの潜在的な構成の使用を示している場合、実際の構成が適用されるときにその潜在的な構成を使用して2番目のオファー/回答交換を行うためにセクション3.6.3で提供されるガイドライン。
Interactive Connectivity Establishment (ICE) [RFC5245] provides a mechanism for verifying connectivity between two endpoints by sending Session Traversal Utilities for NAT (STUN) messages directly between the media endpoints. The basic ICE specification [RFC5245] is only defined to support UDP-based connectivity; however, it allows for extensions to support other transport protocols, such as TCP, which is being specified in [ICETCP]. ICE defines a new "a=candidate" attribute, which, among other things, indicates the possible transport protocol(s) to use and then associates a priority with each of them. The most preferred transport protocol that *successfully* verifies connectivity will end up being used.
Interactive Connectivity Indecivity（ICE）[RFC5245]は、メディアエンドポイント間でNAT（STUN）メッセージのセッショントラバーサルユーティリティを直接送信することにより、2つのエンドポイント間の接続を検証するメカニズムを提供します。基本的な氷の仕様[RFC5245]は、UDPベースの接続性をサポートするためにのみ定義されます。ただし、[ICETCP]で指定されているTCPなど、他の輸送プロトコルをサポートする拡張機能が可能になります。ICEは、新しい「a =候補」属性を定義します。これは、とりわけ、使用する可能性のある輸送プロトコルを使用し、それぞれの優先順位を関連付けます。接続性を検証する *成功した最も優先される輸送プロトコルが使用されることになります。
When using ICE, it is thus possible that the transport protocol that will be used differs from what is specified in the "m=" line. Since both ICE and SDP Capability Negotiation may specify alternative transport protocols, there is a potentially unintended interaction when using these together.
したがって、氷を使用する場合、使用される輸送プロトコルは、「m =」行で指定されているものとは異なります。ICEとSDPの能力交渉の両方が代替輸送プロトコルを指定する可能性があるため、これらを一緒に使用すると、意図しない潜在的な相互作用があります。
We provide the following guidelines for addressing that.
それに対処するための次のガイドラインを提供します。
There are two basic scenarios to consider:
考慮すべき2つの基本的なシナリオがあります。
1) A particular media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS), and the intent is simply to use the one that works (in the preference order specified).
1) 特定のメディアストリームは、異なるトランスポートプロトコル（UDP、TCP、またはTCP/TLSなど）を介して実行でき、意図は単に機能するもの（指定された優先順序で）を使用することです。
2) A particular media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS) and the intent is to have the negotiation process decide which one to use (e.g., T.38 over TCP or UDP).
2) 特定のメディアストリームは、異なるトランスポートプロトコル（UDP、TCP、またはTCP/TLSなど）を介して実行でき、交渉プロセスに使用するもの（TCPまたはUDPを介したT.38など）を決定することが意図されています。
In scenario 1, there should be ICE "a=candidate" attributes for UDP, TCP, etc., but otherwise nothing special in the potential configuration attributes to indicate the desire to use different transport protocols (e.g., UDP, or TCP). The ICE procedures essentially cover the capability negotiation required (by having the answerer select something it supports and then use of trial and error connectivity checks).
シナリオ1には、UDP、TCPなどのICE「A =候補」属性があるはずですが、そうでなければ、異なる輸送プロトコル（UDPまたはTCPなど）を使用したいという欲求を示す潜在的な構成属性に特別なものはありません。ICEの手順は、基本的に必要な機能交渉をカバーしています（回答者にサポートするものを選択することにより、試行錯誤接続のチェックを使用します）。
Scenario 2 does not require a need to support or use ICE. Instead, we simply use transport protocol capabilities and potential configuration attributes to indicate the desired outcome.
シナリオ2では、ICEをサポートまたは使用する必要はありません。代わりに、輸送プロトコル機能と潜在的な構成属性を使用して、目的の結果を示すだけです。
The scenarios may be combined, e.g., by offering potential configuration alternatives where some of them can support only one transport protocol (e.g., UDP), whereas others can support multiple transport protocols (e.g., UDP or TCP). In that case, there is a need for tight control over the ICE candidates that will be used for a particular configuration, yet the actual configuration may want to use all of the ICE candidates. In that case, the ICE candidate attributes can be defined as attribute capabilities and the relevant ones should then be included in the proper potential configurations (for example, candidate attributes for UDP only for potential configurations that are restricted to UDP, whereas there could be candidate attributes for UDP, TCP, and TCP/TLS for potential configurations that can use all three). Furthermore, use of the delete-attributes in a potential configuration can be used to ensure that ICE will not end up using a transport protocol that is not desired for a particular configuration.
シナリオは、たとえば、一部のシナリオが1つの輸送プロトコル（UDPなど）のみをサポートできる潜在的な構成の代替品を提供することで組み合わせることができますが、他のシナリオは複数の輸送プロトコル（UDPまたはTCPなど）をサポートできます。その場合、特定の構成に使用される氷の候補者を厳密に制御する必要がありますが、実際の構成はすべてのICE候補を使用することを望んでいる場合があります。その場合、ICE候補の属性は属性機能として定義でき、関連する属性を適切な潜在的な構成に含める必要があります（たとえば、UDPに制限されている潜在的な構成に対してのみUDPの候補属性がありますが、候補は存在する可能性があります。3つすべてを使用できる潜在的な構成のUDP、TCP、およびTCP/TLSの属性）。さらに、潜在的な構成での削除アトリブの使用を使用して、特定の構成に対して望ましくない輸送プロトコルをICEが使用しないようにするために使用できます。
SDP Capability Negotiation recommends use of a second offer/answer exchange when the negotiated actual configuration was one of the potential configurations from the offer (see Section 3.6.3). Similarly, ICE requires use of a second offer/answer exchange if the chosen candidate is not the same as the one in the m/c-line from the offer. When ICE and capability negotiation are used at the same time, the two secondary offer/answer exchanges SHOULD be combined to a single one.
SDP機能交渉では、ネゴシエートされた実際の構成がオファーからの潜在的な構成の1つである場合、2番目のオファー/回答交換の使用を推奨しています（セクション3.6.3を参照）。同様に、ICEでは、選択した候補者がオファーのM/C-Lineの候補者と同じではない場合、2回目のオファー/回答交換の使用が必要です。ICEと能力の交渉が同時に使用される場合、2つの二次オファー/回答交換を1つに組み合わせる必要があります。
SIP [RFC3261] allows for SIP extensions to define a SIP option tag that identifies the SIP extension. Support for one or more such extensions can be indicated by use of the SIP Supported header, and required support for one or more such extensions can be indicated by use of the SIP Require header. The "a=csup" and "a=creq" attributes defined by the SDP Capability Negotiation framework are similar, except that support for these two attributes by themselves cannot be guaranteed (since they are specified as extensions to the SDP specification [RFC4566] itself).
SIP [RFC3261]を使用すると、SIP拡張機能がSIP拡張子を識別するSIPオプションタグを定義することができます。1つ以上のそのような拡張機能のサポートは、SIPサポートヘッダーの使用によって示され、1つ以上のそのような拡張機能の必要なサポートは、SIP必要なヘッダーを使用することで示すことができます。SDP機能交渉フレームワークによって定義された「a = csup」および「a = creq」属性は類似していますが、これら2つの属性のサポート自体が保証できないことを除いて（それらはSDP仕様[RFC4566]自体への拡張として指定されているためです。）。
SIP extensions with associated option tags can introduce enhancements to not only SIP, but also SDP. This is for example the case for SIP preconditions defined in [RFC3312]. When using SDP Capability Negotiation, some potential configurations may include certain SDP extensions, whereas others may not. Since the purpose of the SDP Capability Negotiation is to negotiate a session based on the features supported by both sides, use of the SIP Require header for such extensions may not produce the desired result. For example, if one potential configuration requires SIP preconditions support, another does not, and the answerer does not support preconditions, then use of the SIP Require header for preconditions would result in a session failure, in spite of the fact that a valid and supported potential configuration was included in the offer.
関連するオプションタグを備えたSIP拡張機能は、SIPだけでなくSDPにも拡張機能を導入できます。これは、たとえば、[RFC3312]で定義されているSIP前処理の場合です。SDP機能交渉を使用する場合、一部の潜在的な構成には特定のSDP拡張機能が含まれる場合がありますが、他の潜在的な構成には含まれない場合があります。SDP機能交渉の目的は、双方がサポートする機能に基づいてセッションをネゴシエートすることであるため、SIPを使用すると、そのような拡張機能にヘッダーが必要になる場合は、目的の結果が生成されない場合があります。たとえば、1つの潜在的な構成がSIPの前提条件をサポートする必要がある場合、別の潜在的な構成が必要であり、回答者が前提条件をサポートしていない場合、SIPの使用は、有効でサポートされているという事実にもかかわらず、前提条件にヘッダーを必要とします。潜在的な構成がオファーに含まれていました。
In general, this can be alleviated by use of mandatory and optional attribute capabilities in a potential configuration. There are however cases where permissible SDP values are tied to the use of the SIP Require header. SIP preconditions [RFC3312] is one such example, where preconditions with a "mandatory" strength-tag can only be used when a SIP Require header with the SIP option tag "precondition" is included. Future SIP extensions that may want to use the SDP Capability Negotiation framework should avoid such coupling.
一般に、これは、潜在的な構成で必須およびオプションの属性機能を使用することで軽減できます。ただし、SIPの使用に許容されるSDP値がヘッダーを使用することと結びついている場合があります。SIP Preconditions [RFC3312]はそのような例の1つです。SIPオプションタグ「Precondition」を備えたヘッダーが含まれている場合にのみ、「必須」強度タグを持つ前提条件を使用できます。SDP機能ネゴシエーションフレームワークを使用したい将来のSIP拡張機能は、このような結合を避ける必要があります。
The offer/answer model [RFC3264] requires an offerer to be able to receive media in accordance with the offer prior to receiving the answer. This property is retained with the SDP Capability Negotiation extensions defined here, but only when the actual configuration is selected by the answerer. If a potential configuration is chosen, the offerer may decide not to process any media received before the answer is received. This may lead to clipping. Consequently, the SDP Capability Negotiation framework recommends sending back an answer SDP session description as soon as possible.
オファー/回答モデル[RFC3264]では、オファーが回答を受け取る前にオファーに従ってメディアを受け取ることができる必要があります。このプロパティは、ここで定義されているSDP機能ネゴシエーション拡張機能で保持されますが、実際の構成が回答者によって選択された場合にのみです。潜在的な構成が選択されている場合、オファーは、回答を受信する前に受信したメディアを処理しないことを決定する場合があります。これはクリッピングにつながる可能性があります。その結果、SDP機能交渉のフレームワークは、できるだけ早く回答SDPセッションの説明を送信することを推奨しています。
The issue can be resolved by introducing a three-way handshake. In the case of SIP, this can, for example, be done by defining a precondition [RFC3312] for capability negotiation (or by using an existing precondition that is known to generate a second offer/answer exchange before proceeding with the session). However, preconditions are often viewed as complicated to implement and they may add to overall session establishment delay by requiring an extra offer/answer exchange.
この問題は、3方向の握手を導入することで解決できます。SIPの場合、これは、能力交渉の前提条件[RFC3312]を定義することにより（またはセッションに進む前に2番目のオファー/回答交換を生成することが知られている既存の前提条件を使用することにより）実行できます。ただし、前提条件は実装が複雑であると見なされることが多く、追加のオファー/回答の交換を必要とすることにより、セッションの確立遅延全体に追加される可能性があります。
An alternative three-way handshake can be performed by use of ICE [RFC5245]. When ICE is being used, and the answerer receives a STUN Binding Request for any one of the accepted media streams from the offerer, the answerer knows the offer has received his answer. At that point, the answerer knows that the offerer will be able to process incoming media according to the negotiated configuration and hence he can start sending media without the risk of the offerer either discarding it or playing garbage.
氷を使用することにより、別の3方向の握手を実行できます[RFC5245]。ICEが使用されており、応答者が提供者から受け入れられているメディアストリームのいずれかに対してスタンバインディングリクエストを受け取ったとき、応募者はオファーが彼の答えを受け取ったことを知っています。その時点で、回答者は、提供者が交渉された構成に従って着信メディアを処理できることを知っているため、オファーを廃棄したりゴミをプレイしたりするリスクなしにメディアを送信し始めることができます。
Please note that, the above considerations notwithstanding, this document does not place any requirements on the offerer to process and play media before answer; it merely provides recommendations for how to ensure that media sent by the answerer and received by the offerer prior to receiving the answer can in fact be rendered by the offerer.
上記の考慮事項にもかかわらず、このドキュメントは、回答の前にメディアを処理してプレイするために提供者に要件を掲載していないことに注意してください。それは、答えを受け取る前に、応答者から送信され、提供者が受け取ったメディアが実際に提供者によってレンダリングされることを保証する方法についての推奨事項を提供するだけです。
In some use cases, a three-way handshake is not needed. An example is when the offerer does not need information from the answer, such as keying material in the SDP session description, in order to process incoming media. The SDP Capability Negotiation framework does not define any such solutions; however, extensions may do so. For example, one technique proposed for best-effort SRTP in [BESRTP] is to provide different RTP payload type mappings for different transport protocols used, outside of the actual configuration, while still allowing them to be used by the answerer (exchange of keying material is still needed, e.g., inband). The basic SDP Capability Negotiation framework defined here does not include the ability to do so; however, extensions that enable that may be defined.
一部のユースケースでは、3方向の握手は必要ありません。例としては、受信メディアを処理するために、SDPセッションの説明のキーイング資料など、オファーが回答から情報を必要としない場合です。SDP機能交渉フレームワークは、そのようなソリューションを定義しません。ただし、拡張機能はそうするかもしれません。たとえば、[BESRTP]でベストエフォルトSRTPに提案されている手法の1つは、実際の構成以外で使用されているさまざまなトランスポートプロトコルに異なるRTPペイロードタイプマッピングを提供しながら、回答者が使用することを可能にすることです（キーイングの交換を可能にしますたとえば、インバンド）が必要です。ここで定義されている基本的なSDP機能交渉フレームワークには、そうする能力は含まれていません。ただし、定義できる拡張機能。
The amount of bandwidth used for a particular media stream depends on the negotiated codecs, transport protocol and other parameters. For example the use of Secure RTP [RFC3711] with integrity protection requires more bandwidth than plain RTP [RFC3551]. SDP defines the bandwidth ("b=") parameter to indicate the proposed bandwidth for the session or media stream.
特定のメディアストリームに使用される帯域幅の量は、交渉されたコーデック、輸送プロトコル、その他のパラメーターに依存します。たとえば、整合性保護を備えた安全なRTP [RFC3711]の使用には、プレーンRTP [RFC3551]よりも多くの帯域幅が必要です。SDPは、セッションまたはメディアストリームの提案された帯域幅を示す帯域幅（ "b ="）パラメーターを定義します。
In SDP, as defined by [RFC4566], each media description contains one transport protocol and one or more codecs. When specifying the proposed bandwidth, the worst case scenario must be taken into account, i.e., use of the highest bandwidth codec provided, the transport protocol indicated, and the worst case (bandwidth-wise) parameters that can be negotiated (e.g., a 32-bit Hashed Message Authentication Code (HMAC) or an 80-bit HMAC).
[RFC4566]で定義されているSDPでは、各メディアの説明には1つの輸送プロトコルと1つ以上のコーデックが含まれています。提案された帯域幅を指定する場合、最悪のシナリオを考慮する必要があります。つまり、提供される最高の帯域幅コーデックの使用、輸送プロトコルが示され、最悪のケース（帯域幅ごとの）パラメーターを交渉できる（例：32、32） - ビットハッシュメッセージ認証コード（HMAC）または80ビットHMAC）。
The base SDP Capability Negotiation framework does not provide a way to negotiate bandwidth parameters. The issue thus remains; however, it is potentially worse than with SDP per [RFC4566], since it is easier to negotiate additional codecs, and furthermore possible to negotiate different transport protocols. The recommended approach for addressing this is the same as for plain SDP; the worst case (now including potential configurations) needs to be taken into account when specifying the bandwidth parameters in the actual configuration. This can make the bandwidth value less accurate than in SDP per [RFC4566] (due to potential greater variability in the potential configuration bandwidth use). Extensions can be defined to address this shortcoming.
ベースSDP機能交渉フレームワークは、帯域幅パラメーターをネゴシエートする方法を提供しません。したがって、問題は残っています。ただし、追加のコーデックを交渉しやすく、さらに異なる輸送プロトコルを交渉することが可能であるため、SDPあたりのSDPよりも潜在的に悪化しています。これに対処するための推奨アプローチは、プレーンSDPと同じです。実際の構成で帯域幅パラメーターを指定する際には、最悪のケース（現在は潜在的な構成を含む）を考慮する必要があります。これにより、帯域幅の値は[RFC4566]あたりのSDPよりも精度を低くすることができます（潜在的な構成帯域幅の使用の潜在的なばらつきがあるため）。拡張機能は、この欠点に対処するために定義できます。
Note, that when using RTP retransmission [RFC4588] with the RTCP-based feedback profile [RFC4585] (RTP/AVPF), the retransmitted packets are part of the media stream bandwidth when using synchronization source (SSRC) multiplexing. If a feedback-based protocol is offered as the actual configuration transport protocol, a non-feedback-based protocol is offered as a potential configuration transport protocol and ends up being used, the actual bandwidth usage may be lower than the indicated bandwidth value in the offer (and vice versa).
RTCPベースのフィードバックプロファイル[RFC4585]（RTP/AVPF）を使用してRTP再送信[RFC4588]を使用する場合、再送信されたパケットは、同期ソース（SSRC）多重化を使用する場合のメディアストリーム帯域幅の一部であることに注意してください。フィードバックベースのプロトコルが実際の構成輸送プロトコルとして提供される場合、非フィードバックベースのプロトコルが潜在的な構成輸送プロトコルとして提供され、使用されることになります。提供（そしてその逆）。
When using the SDP Capability Negotiation, it is easy to generate offers that contain a large number of potential configurations. For example, in the offer:
SDP機能交渉を使用する場合、多数の潜在的な構成を含むオファーを簡単に生成できます。たとえば、オファーで：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=acap:3 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,3|2,3
a=pcfg:2 t=2 a=1|2
a=pcfg:3 t=3 a=3
we have 5 potential configurations on top of the actual configuration for a single media stream. Adding an extension capability with just two alternatives for each would double that number (to 10), and doing the equivalent with two media streams would again double that number (to 20). While it is easy (and inexpensive) for the offerer to generate such offers, processing them at the answering side may not be. Consequently, it is RECOMMENDED that offerers do not create offers with unnecessarily large number of potential configurations in them.
単一のメディアストリームの実際の構成の上に5つの潜在的な構成があります。それぞれに2つの選択肢だけで拡張機能を追加すると、その数値が2倍になり（10）、2つのメディアストリームで同等のものを実行すると、その数（20）が2倍になります。オファーがそのようなオファーを生成するのは簡単（そして安価）ですが、答え側でそれらを処理することはそうではないかもしれません。その結果、提供者は、不必要に多数の潜在的な構成を含むオファーを作成しないことをお勧めします。
On the answering side, implementers MUST take care to avoid excessive memory and CPU consumption. For example, a naive implementation that first generates all the valid potential configuration SDP session descriptions internally, could find itself being memory exhausted, especially if it supports a large number of endpoints. Similarly, a naive implementation that simply performs iterative trial-and-error processing on each possible potential configuration SDP session description (in the preference order specified) could find itself being CPU constrained. An alternative strategy is to prune the search space first by discarding the set of offered potential configurations where the transport protocol indicated (if any) is not supported, and/or one or more mandatory attribute capabilities (if any) are either not supported or not valid. Potential configurations with unsupported mandatory extension configurations in them can be discarded as well.
答え側では、実装者は過度のメモリとCPUの消費を避けるように注意する必要があります。たとえば、特に多数のエンドポイントをサポートしている場合、最初にすべての有効な潜在的な構成SDPセッションの説明を内部的に生成する素朴な実装は、メモリが使い果たされていることがわかります。同様に、可能な各潜在的な構成SDPセッションの説明（指定された優先順序で）で単純に反復的な試行錯誤処理を実行する素朴な実装は、CPUが制約されていることがわかります。別の戦略は、最初に検索スペースをプルナンスすることです。提供された潜在的な構成のセットを廃棄することです。有効。サポートされていない必須拡張構成を備えた潜在的な構成も破棄できます。
An intermediary is here defined as an entity between a SIP user agent A and a SIP user agent B, that needs to perform some kind of processing on the SDP session descriptions exchanged between A and B, in order for the session establishment to operate as intended. Examples of such intermediaries include Session Border Controllers (SBCs) that may perform media relaying, Proxy Call Session Control Functions (P-CSCFs) that may authorize use of a certain amount of network resources (bandwidth), etc. The presence and design of such intermediaries may not follow the "Internet" model or the SIP requirements for proxies (which are not supposed to look in message bodies such as SDP session descriptions); however, they are a fact of life in some deployment scenarios and hence deserve consideration.
ここでは、SIPユーザーエージェントAとSIPユーザーエージェントBの間のエンティティとして定義されています。これは、AとBの間で交換されるSDPセッションの説明で何らかの処理を実行する必要があります。。このような仲介業者の例には、メディアリレーを実行する可能性のあるセッションボーダーコントローラー（SBC）、特定の量のネットワークリソース（帯域幅）の使用を許可する可能性のあるプロキシコールセッションコントロール関数（P-CSCF）などが含まれます。仲介者は、「インターネット」モデルまたはプロキシのSIP要件に従うことはできません（SDPセッションの説明などのメッセージ本文を見ることは想定されていません）。しかし、それらはいくつかの展開シナリオでの生活の事実であり、したがって考慮に値します。
If the intermediary needs to understand the characteristics of the media sessions being negotiated, e.g., the amount of bandwidth used or the transport protocol negotiated, then use of the SDP Capability Negotiation framework may impact them. For example, some intermediaries are known to disallow answers where the transport protocol differs from the one in the offer. Use of the SDP Capability Negotiation framework in the presence of such intermediaries could lead to session failures. Intermediaries that need to authorize use of network resources based on the negotiated media stream parameters are affected as well. If they inspect only the offer, then they may authorize parameters assuming a different transport protocol, codecs, etc., than what is actually being negotiated. For these, and other, reasons it is RECOMMENDED that implementers of intermediaries add support for the SDP Capability Negotiation framework.
仲介者が交渉中のメディアセッションの特性を理解する必要がある場合、たとえば使用される帯域幅または交通プロトコルの交渉の量を理解する必要がある場合、SDP能力交渉フレームワークの使用はそれらに影響を与える可能性があります。たとえば、一部の仲介業者は、輸送プロトコルがオファーのものと異なる場合、回答を禁止することが知られています。このような仲介者の存在下でのSDP機能交渉フレームワークの使用は、セッションの失敗につながる可能性があります。交渉されたメディアストリームパラメーターに基づいてネットワークリソースの使用を許可する必要がある仲介者も影響を受けます。彼らがオファーのみを検査する場合、彼らは実際に交渉されているものとは異なる輸送プロトコル、コーデックなどを仮定してパラメーターを承認することができます。これらおよびその他の理由については、仲介者の実装者がSDP機能交渉フレームワークのサポートを追加することをお勧めします。
The SDP Capability Negotiation framework itself attempts to help out these intermediaries as well, by recommending a second offer/answer exchange when use of a potential configuration has been negotiated (see Section 3.6.3). However, there are several limitations with this approach. First of all, although the second offer/answer exchange is RECOMMENDED, it is not required and hence may not be performed. Secondly, the intermediary may refuse the initial answer, e.g., due to perceived transport protocol mismatch. Thirdly, the strategy is not foolproof since the offer/answer procedures [RFC3264] leave the original offer/answer exchange in effect when a subsequent one fails. Consider the following example:
SDP機能交渉フレームワーク自体は、潜在的な構成の使用が交渉された場合に2回目のオファー/回答交換を推奨することにより、これらの仲介者を支援しようとします（セクション3.6.3を参照）。ただし、このアプローチにはいくつかの制限があります。まず第一に、2番目のオファー/回答の交換が推奨されますが、それは必須ではないため、実行されない場合があります。第二に、仲介者は、たとえば、輸送プロトコルの不一致が認識されているため、最初の回答を拒否する場合があります。第三に、オファー/回答手順[RFC3264]が後続の場合が失敗したときに元のオファー/回答の交換を有効にしているため、戦略は完全に困難ではありません。次の例を考えてみましょう。
1. Offerer generates an SDP session description offer with the actual configuration specifying a low-bandwidth configuration (e.g., plain RTP) and a potential configuration specifying a high(er) bandwidth configuration (e.g., Secure RTP with integrity).
1. Offererは、低帯域幅構成（プレーンRTPなど）を指定する実際の構成を使用してSDPセッションの説明オファーを生成し、高（ER）帯域幅構成（整合性のあるセキュアRTP）を指定する潜在的な構成を生成します。
2. An intermediary (e.g., an SBC or P-CSCF), that does not support SDP Capability Negotiation, authorizes the session based on the actual configuration it sees in the SDP session description.
2. SDP機能の交渉をサポートしていない仲介者（SBCまたはP-CSCFなど）は、SDPセッションの説明で表示される実際の構成に基づいてセッションを承認します。
3. The answerer chooses the high(er) bandwidth potential configuration and generates an answer SDP session description based on that.
3. Answererは、高（ER）帯域幅の電位構成を選択し、それに基づいて回答SDPセッションの説明を生成します。
4. The intermediary passes through the answer SDP session description.
4. 仲介者は、回答SDPセッションの説明を通過します。
5. The offerer sees the accepted answer, and generates an updated offer that contains the selected potential configuration as the actual configuration. In other words, the high(er) bandwidth configuration (which has already been negotiated successfully) is now the actual configuration in the offer SDP session description.
5. オファーは、受け入れられた回答を見て、選択した潜在的な構成を実際の構成として含む更新されたオファーを生成します。言い換えれば、高（ER）帯域幅構成（すでに正常に交渉されている）は、オファーSDPセッションの説明の実際の構成になりました。
6. The intermediary sees the new offer; however, it does not authorize the use of the high(er) bandwidth configuration, and consequently generates a rejection message to the offerer.
6. 仲介者は新しいオファーを見ます。ただし、高（ER）帯域幅構成の使用を許可せず、その結果、提供者への拒否メッセージが生成されます。
7. The offerer receives the rejected offer.
7. オファーは拒否された申し出を受け取ります。
After step 7, per RFC 3264, the offer/answer exchange that completed in step 5 remains in effect; however, the intermediary may not have authorized the necessary network resources and hence the media stream may experience quality issues. The solution to this problem is to upgrade the intermediary to support the SDP Capability Negotiation framework.
ステップ7の後、RFC 3264ごとに、ステップ5で完了したオファー/回答交換は引き続き有効です。ただし、仲介者は必要なネットワークリソースを許可していない可能性があるため、メディアストリームは質の高い問題を経験する可能性があります。この問題の解決策は、SDP機能交渉フレームワークをサポートするために仲介者をアップグレードすることです。
The base SDP Capability Negotiation framework defines transport capabilities and attribute capabilities. Media capabilities, which can be used to describe media formats and their associated parameters, are not defined in this document; however, the "rtpmap" and "fmtp" attributes can nevertheless be used as attribute capabilities. Using such attribute capabilities in a potential configuration requires a bit of care though.
ベースSDP機能交渉フレームワークは、輸送機能と属性機能を定義します。メディア形式とそれに関連するパラメーターを記述するために使用できるメディア機能は、このドキュメントでは定義されていません。ただし、「RTPMAP」および「FMTP」属性は、属性機能として使用できます。ただし、潜在的な構成でこのような属性機能を使用するには、少し注意が必要です。
The rtpmap parameter binds an RTP payload type to a media format (e.g., codec). While it is possible to provide rtpmaps for payload types not found in the corresponding "m=" line, such rtpmaps provide no value in normal offer/answer exchanges, since only the payload types found in the "m=" line are part of the offer (or answer). This applies to the base SDP Capability Negotiation framework as well.
RTPMAPパラメーターは、RTPペイロードタイプをメディア形式（Codecなど）にバインドします。対応する「m =」行には見られないペイロードタイプにrtpmapsを提供することは可能ですが、そのようなrtpmapsは通常のオファー/回答交換で価値を提供しません。申し出（または回答）。これは、ベースSDP機能交渉フレームワークにも適用されます。
Only the media formats (e.g., RTP payload types) provided in the "m=" line are actually offered; inclusion of "rtpmap" attributes with other RTP payload types in a potential configuration does not change this fact and hence they do not provide any useful information there. They may still be useful as pure capabilities though (outside a potential configuration) in order to inform a peer of additional codecs supported.
「m =」行で提供されるメディア形式（例：RTPペイロードタイプ）のみが実際に提供されます。潜在的な構成に他のRTPペイロードタイプに「RTPMAP」属性を含めることは、この事実を変更することはなく、そこで有用な情報を提供しません。ただし、サポートされている追加のコーデックをピアに通知するために、純粋な機能として（潜在的な構成以外で）依然として有用かもしれません。
It is possible to provide an "rtpmap" attribute capability with a payload type mapping to a different codec than a corresponding actual configuration "rtpmap" attribute for the media description has. Such practice is permissible as a way of indicating a capability. If that capability is included in a potential configuration, then delete-attributes (see Section 3.5.1) MUST be used to ensure that there is not multiple "rtpmap" attributes for the same payload type in a given media description (which would not be allowed by SDP [RFC4566]).
メディアの説明の対応する実際の構成「rtpmap」属性とは異なるコーデックへのペイロードタイプマッピングを使用して、「rtpmap」属性機能を提供することができます。このような実践は、能力を示す方法として許されます。その機能が潜在的な構成に含まれている場合、特定のメディアの説明に同じペイロードタイプに対して複数の「rtpmap」属性がないことを確認するために、削除aTtributes（セクション3.5.1を参照）を使用する必要があります（SDP [RFC4566]による許可）。
Similar considerations and rules apply to the "fmtp" attribute. An "fmtp" attribute capability for a media format not included in the "m=" line is useless in a potential configuration (but may be useful as a capability by itself). An "fmtp" attribute capability in a potential configuration for a media format that already has an "fmtp" attribute in the actual configuration may lead to multiple fmtp format parameters for that media format and that is not allowed by SDP [RFC4566]. The delete-attributes MUST be used to ensure that there are not multiple "fmtp" attributes for a given media format in a media description.
同様の考慮事項とルールは、「FMTP」属性に適用されます。「M =」行に含まれていないメディア形式の「FMTP」属性機能は、潜在的な構成では役に立たない（ただし、単独では機能として役立つ場合があります）。実際の構成に「FMTP」属性を既に持っているメディア形式の潜在的な構成の「FMTP」属性機能は、そのメディア形式の複数のFMTP形式パラメーターにつながる可能性があり、SDP [RFC4566]によって許可されていません。削除アトリビュートを使用して、メディアの説明に特定のメディア形式に複数の「FMTP」属性がないことを確認する必要があります。
Extensions to the base SDP Capability Negotiation framework may change the above behavior.
ベースSDP機能交渉フレームワークへの拡張は、上記の動作を変更する場合があります。
SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" direction attributes. The direction attributes can be applied at either the session level or the media level. In either case, it is possible to define attribute capabilities for these direction capabilities; if used by a potential configuration, the normal offer/answer procedures still apply. For example, if an offered potential configuration includes the "sendonly" direction attribute, and it is selected as the actual configuration, then the answer MUST include a corresponding "recvonly" (or "inactive") attribute.
SDPは、「非アクティブ」、「Sendonly」、「Recvonly」、および「SendRecv」方向属性を定義します。方向属性は、セッションレベルまたはメディアレベルのいずれかで適用できます。どちらの場合でも、これらの方向機能の属性機能を定義することができます。潜在的な構成によって使用される場合、通常のオファー/回答手順がまだ適用されます。たとえば、提供された潜在的な構成に「sendonly」方向属性が含まれ、実際の構成として選択されている場合、答えには対応する「recvonly」（または「非アクティブ」）属性を含める必要があります。
RFC 3407 defines capability descriptions with limited abilities to describe attributes, bandwidth parameters, transport protocols and media formats. RFC 3407 does not define any negotiation procedures for actually using those capability descriptions.
RFC 3407は、属性、帯域幅パラメーター、トランスポートプロトコル、メディア形式を記述する能力が限られている機能の説明を定義します。RFC 3407は、実際にそれらの機能の説明を使用するための交渉手順を定義していません。
This document defines new attributes for describing attribute capabilities and transport capabilities. It also defines procedures for using those capabilities as part of an offer/answer exchange. In contrast to RFC 3407, this document does not define bandwidth parameters, and it also does not define how to express ranges of values. Extensions to this document may be defined in order to fully cover all the capabilities provided by RFC 3407 (for example, more general media capabilities).
このドキュメントは、属性機能と輸送機能を記述するための新しい属性を定義します。また、これらの機能をオファー/回答交換の一部として使用する手順を定義します。RFC 3407とは対照的に、このドキュメントは帯域幅パラメーターを定義せず、値の範囲を表現する方法も定義しません。このドキュメントの拡張は、RFC 3407（たとえば、より一般的なメディア機能）によって提供されるすべての機能を完全にカバーするために定義できます。
It is RECOMMENDED that implementations use the attributes and procedures defined in this document instead of those defined in [RFC3407]. If capability description interoperability with legacy RFC 3407 implementations is desired, implementations MAY include both RFC 3407 capability descriptions and capabilities defined by this document. The offer/answer negotiation procedures defined in this document will not use the RFC 3407 capability descriptions.
[RFC3407]で定義されているものではなく、このドキュメントで定義されている属性と手順を実装することをお勧めします。Legacy RFC 3407実装との相互運用性が必要な場合、実装には、このドキュメントで定義されたRFC 3407機能の説明と機能が含まれる場合があります。このドキュメントで定義されているオファー/回答の交渉手順では、RFC 3407機能の説明は使用されません。
In this section, we provide examples showing how to use the SDP Capability Negotiation.
このセクションでは、SDP機能交渉の使用方法を示す例を示します。
The following example illustrates how to use the SDP Capability Negotiation extensions to negotiate use of one out of several possible transport protocols. The offerer uses the expected least-common-denominator (plain RTP) as the actual configuration, and the alternative transport protocols as the potential configurations.
次の例は、SDP機能交渉拡張機能を使用して、いくつかの可能な輸送プロトコルのうち1つの使用を交渉する方法を示しています。オファーは、予想される最小コモンデノミネーター（プレーンRTP）を実際の構成として使用し、代替輸送プロトコルを潜在的な構成として使用します。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
この例は、以下の申し出/回答の交換によって示されています。ここでは、アリスはボブに申し出を送ります。
Alice Bob
アリスボブ
| (1) Offer (RTP/[S]AVP[F]) |
|--------------------------------->|
| |
| (2) Answer (RTP/AVPF) |
|<---------------------------------|
| |
| (3) Offer (RTP/AVPF) |
|--------------------------------->|
| |
| (4) Answer (RTP/AVPF) |
|<---------------------------------|
| |
Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default, with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and preferred in the order listed:
アリスのオファーには、プレーンRTP（RTP/AVP）、RTCPベースのフィードバック（RTP/AVPF）を備えたRTP、セキュアRTP（RTP/SAVP）、およびRTCPベースのフィードバック（RTP/SAVPF）を使用したRTPを代替品として保護することが含まれます。RTPはデフォルトであり、RTP/SAVPF、RTP/SAVP、およびRTP/AVPFが代替案として、リストされている順序で優先されます。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,[2]
a=pcfg:2 t=2 a=1
a=pcfg:3 t=3 a=[2]
The "m=" line indicates that Alice is offering to use plain RTP with PCMU or G.729. The capabilities are provided by the "a=tcap" and "a=acap" attributes. The "tcap" capability indicates that Secure RTP with RTCP-based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and RTP with RTCP-based feedback are supported. The first "acap" attribute provides an attribute capability with a handle of 1. The capability is a "crypto" attribute, which provides the keying material for SRTP using SDP security descriptions [RFC4568]. The second "acap" attribute provides an attribute capability with a handle of 2. The capability is an "rtcp-fb" attribute, which is used by the RTCP-based feedback profiles to indicate that payload type 0 (PCMU) supports feedback type "nack". The "a=pcfg" attributes provide the potential configurations included in the offer by reference to the capabilities. There are three potential configurations:
「M =」行は、AliceがPCMUまたはG.729でプレーンRTPを使用することを申し出ていることを示しています。機能は、「a = tcap」および「a = acap」属性によって提供されます。「TCAP」機能は、RTCPベースのフィードバック（RTP/SAVPF）、セキュアRTP（RTP/SAVP）、およびRTCPベースのフィードバックを備えたRTPを使用したSecure RTPがサポートされていることを示しています。最初の「ACAP」属性は、1のハンドルを備えた属性機能を提供します。機能は「Crypto」属性であり、SDPセキュリティ説明[RFC4568]を使用してSRTPのキーリング材料を提供します。2番目の「ACAP」属性は、2のハンドルで属性機能を提供します。機能は「RTCP-FB」属性です。これは、RTCPベースのフィードバックプロファイルで使用され、ペイロードタイプ0（PCMU）がフィードバックタイプをサポートしていることを示します。ナック」。「A = PCFG」属性は、機能を参照することにより、オファーに含まれる潜在的な構成を提供します。3つの潜在的な構成があります。
o Potential configuration 1, which is the most preferred potential configuration specifies use of transport protocol capability 1 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) and 2 (the "rtcp-fb" attribute). Support for the first one is mandatory whereas support for the second one is optional.
o 最も優先される潜在的な構成である潜在的な構成1は、輸送プロトコル機能1（RTP/SAVPF）および属性機能1（「crypto」属性）と2（「rtcp-fb」属性）の使用を指定します。最初のサポートは必須ですが、2番目のサポートはオプションです。
o Potential configuration 2, which is the second most preferred potential configuration specifies use of transport protocol capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the "crypto" attribute).
o 潜在的な構成2は、2番目に優先される潜在的な構成であり、輸送プロトコル機能2（RTP/SAVP）の使用と必須属性機能1（「crypto」属性）の使用を指定します。
o Potential configuration 3, which is the least preferred potential configuration (but the second least preferred configuration overall, since the actual configuration provided by the "m=" line is always the least preferred configuration), specifies use of transport protocol capability 3 (RTP/AVPF) and optional attribute capability 2 (the "rtcp-fb" attribute).
o 潜在的な構成3は、「M =」行で提供される実際の構成は常に最小の設定であるため、最も優先される電位構成ではありません。AVPF）およびオプションの属性機能2（「RTCP-FB」属性）。
Bob receives the SDP session description offer from Alice. Bob does not support any Secure RTP profiles; however, he supports plain RTP and RTP with RTCP-based feedback, as well as the SDP Capability Negotiation extensions, and hence he accepts the potential configuration for RTP with RTCP-based feedback provided by Alice:
ボブは、アリスからSDPセッションの説明オファーを受け取ります。ボブは安全なRTPプロファイルをサポートしていません。ただし、彼はRTCPベースのフィードバックを備えたPlain RTPとRTP、およびSDP機能交渉拡張をサポートするため、Aliceが提供するRTCPベースのフィードバックでRTPの潜在的な構成を受け入れます。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
a=acfg:1 t=3 a=[2]
Bob includes the "a=acfg" attribute in the answer to inform Alice that he based his answer on an offer containing the potential configuration with transport protocol capability 3 and optional attribute capability 2 from the offer SDP session description (i.e., the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also includes an "rtcp-fb" attribute with the value "nack" value for RTP payload type 0.
ボブには、回答に「a = acfg」属性を含めて、アリスに、オファーSDPセッションの説明からの輸送プロトコル機能3およびオプションの属性機能2を備えた潜在的な構成を含むオファーに基づいていることをアリスに知らせます（すなわち、RTP/AVPF提供された「RTCP-FB」値を使用したプロファイル）。ボブには、RTPペイロードタイプ0の値「nack」値を持つ「rtcp-fb」属性も含まれています。
When Alice receives Bob's answer, session negotiation has completed, however Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the SDP Capability Negotiation framework (and hence may not understand the negotiation that just took place):
アリスがボブの回答を受け取ったとき、セッションの交渉は完了しましたが、それでもアリスは実際の構成を使用して新しいオファーを生成することを選択します。これは、アリスとボブの間に存在するが、SDP能力交渉フレームワークをサポートしていない可能性のある仲介者を支援するために純粋に行われます（したがって、行われたばかりの交渉を理解していない可能性があります）：
Alice's updated offer includes only RTP/AVPF, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Aliceの更新されたオファーにはRTP/AVPFのみが含まれており、SDP機能交渉フレームワークを使用していません（アリスは、必要に応じて機能を含めることもできます）：
v=0 o=- 25678 753850 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 m=audio 53456 RTP/AVPF 0 18 a=rtcp-fb:0 nack
V = 0 O = -25678 753850 IN IP4 192.0.2.1 s = c = in ip4 192.0.2.1 t = 0 0 M = audio 53456 rtp/avpf 0 18 a = rtcp-fb：0 nack
The "m=" line now indicates that Alice is offering to use RTP with RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" attribute provides the feedback type "nack" for payload type 0 again (but as part of the actual configuration).
「M =」行は、AliceがRTCPベースのフィードバックでRTPを使用し、PCMUまたはG.729を使用することを申し出ていることを示しています。「RTCP-FB」属性は、ペイロードタイプ0のフィードバックタイプ「NACK」を再度提供します（ただし、実際の構成の一部として）。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
ボブは、アリスからSDPセッションの説明オファーを受け取り、それを受け入れ、アリスへの回答を生成します。
v=0 o=- 24351 621815 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 m=audio 54568 RTP/AVPF 0 18 a=rtcp-fb:0 nack
V = 0 O = -24351 621815 IN IP4 192.0.2.2 S = C = IN IP4 192.0.2.2 T = 0 0 M = Audio 54568 RTP/AVPF 0 18 A = RTCP-FB：0 NACK
Bob includes the same "rtcp-fb" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
ボブには以前と同じ「RTCP-FB」属性が含まれており、セッションは変更なしで進行します。ボブは彼の答えに能力を含めていませんでしたが、彼が望んでいれば彼はそうすることができたでしょう。
Note that in this particular example, the answerer supported the SDP Capability Negotiation framework and hence the attributes and procedures defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
この特定の例では、AnswererがSDP機能交渉フレームワークをサポートしているため、ここで定義されている属性と手順をサポートしていたことに注意してください。しかし、彼がそうでなければ、応答者はステップ1で受け取った新しい属性を単に無視し、通常のRTPを使用するという申し出を受け入れたでしょう。その場合、次の答えは、代わりにステップ2で生成されていました。
v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 m=audio 54568 RTP/AVP 0 18
V = 0 O = -24351 621814 IN IP4 192.0.2.2 S = C = IN IP4 192.0.2.2 T = 0 0 M = Audio 54568 RTP/AVP 0 18
The following example illustrates how to use the SDP Capability Negotiation framework to negotiate use of SRTP using either SDP security descriptions or DTLS-SRTP. The offerer (Alice) wants to establish a Secure RTP audio stream but is willing to use plain RTP. Alice prefers to use DTLS-SRTP as the key management protocol, but supports SDP security descriptions as well (note that [RFC5763] contains additional DTLS-SRTP examples).
次の例は、SDPセキュリティの説明またはDTLS-SRTPを使用してSRTPの使用を交渉してSDP機能交渉フレームワークを使用する方法を示しています。Offerer（Alice）は、安全なRTPオーディオストリームを確立したいと考えていますが、Plain RTPを使用することをいとわない。アリスは、主要な管理プロトコルとしてDTLS-SRTPを使用することを好みますが、SDPセキュリティの説明もサポートしています（[RFC5763]には追加のDTLS-SRTPの例が含まれていることに注意してください）。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
この例は、以下の申し出/回答の交換によって示されています。ここでは、アリスはボブに申し出を送ります。
Alice Bob
アリスボブ
| (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)|
|--------------------------------------->|
| |
|<--------- DTLS-SRTP handshake -------->|
| |
| (2) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (3) Offer (DTLS-SRTP) |
|--------------------------------------->|
| |
| (4) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
Alice's offer includes an audio stream that offers use of plain RTP and Secure RTP as alternatives. For the Secure RTP stream, it can be established using either DTLS-SRTP or SDP security descriptions:
アリスのオファーには、プレーンRTPを使用し、代替品として安全なRTPを使用するオーディオストリームが含まれています。安全なRTPストリームの場合、DTLS-SRTPまたはSDPセキュリティの説明を使用して確立できます。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 setup:actpass
a=acap:2 fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=3
The first (and preferred) potential configuration for the audio stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), i.e., DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive mode and certificate fingerprint), both of which must be supported to choose this potential configuration. The second (and less preferred) potential configuration specifies use of transport capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e., the SDP security description.
オーディオストリームの最初の（および優先される）潜在的な構成は、トランスポート機能1（UDP/TLS/RTP/SAVP）の使用、つまりDTLS-SRTP、および属性機能1および2（アクティブ/パッシブモードと証明書指紋）を指定します。どちらもこの潜在的な構成を選択するためにサポートする必要があります。2番目の（およびそれ以下の優先度の低い）構成は、トランスポート機能2（RTP/SAVP）および必須属性機能3の使用、つまりSDPセキュリティの説明を指定します。
Bob receives the SDP session description offer from Alice. Bob supports DTLS-SRTP as preferred by Alice and Bob now initiates the DTLS-SRTP handshake to establish the DTLS-SRTP session (see [RFC5764] for details).
ボブは、アリスからSDPセッションの説明オファーを受け取ります。ボブは、アリスとボブが好むDTLS-SRTPをサポートし、DTLS-SRTPハンドシェイクを開始して、詳細についてはDTLS-SRTPセッションを確立します（[RFC5764]を参照）。
Bob also sends back an answer to Alice as follows:
ボブはまた、次のようにアリスへの回答を送り返します：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
For the audio stream, Bob accepted the use of DTLS-SRTP, and hence the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also includes a "setup:active" attribute to indicate he is the active endpoint for the DTLS-SRTP session as well as the fingerprint for Bob's certificate. Bob's "acfg" attribute indicates that he chose potential configuration 1 from Alice's offer.
オーディオストリームの場合、ボブはDTLS-SRTPの使用を受け入れ、したがって「m =」行のプロファイルは「udp/tls/rtp/savp」です。ボブには、「セットアップ：アクティブ」属性も含まれており、彼がDTLS-SRTPセッションのアクティブエンドポイントであり、ボブの証明書の指紋であることを示します。ボブの「ACFG」属性は、アリスの申し出から潜在的な構成1を選択したことを示しています。
When Alice receives Bob's answer, session negotiation has completed (and Alice can verify the DTLS handshake using Bob's certificate fingerprint in the answer); however, Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the capability negotiation extensions (and hence may not understand the negotiation that just took place).
アリスがボブの回答を受け取ると、セッションの交渉が完了しました（アリスは、回答でボブの証明書指紋を使用してDTLSハンドシェイクを確認できます）。ただし、アリスは、実際の構成を使用して新しいオファーを生成することを選択します。これは、アリスとボブの間に存在するが、能力交渉拡張をサポートしていない可能性のある仲介者を支援するために純粋に行われます（したがって、行われた交渉を理解していない可能性があります）。
Alice's updated offer includes only DTLS-SRTP for the audio stream, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Aliceの更新されたオファーには、オーディオストリームのDTLS-SRTPのみが含まれており、SDP機能交渉フレームワークを使用していません（アリスは、必要に応じて機能を含めることもできます）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000
The "m=" line for the audio stream now indicates that Alice is offering to use DTLS-SRTP in active/passive mode using her certificate fingerprint provided.
オーディオストリームの「M =」行は、Aliceが提供された証明書指紋を使用してアクティブ/パッシブモードでDTLS-SRTPを使用することを提供していることを示しています。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
ボブは、アリスからSDPセッションの説明オファーを受け取り、それを受け入れ、アリスへの回答を生成します。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
Bob includes the same "setup:active" and fingerprint attributes as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
ボブには、以前と同じ「セットアップ：アクティブ」と指紋属性が含まれており、セッションは変更なしで進行します。ボブは彼の答えに能力を含めていませんでしたが、彼が望んでいれば彼はそうすることができたでしょう。
Note that in this particular example, the answerer supported the capability extensions defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
この特定の例では、回答者はここで定義されている機能拡張機能をサポートしていたことに注意してください。しかし、彼がそうでなければ、応答者はステップ1で受け取った新しい属性を単に無視し、通常のRTPを使用するという申し出を受け入れたでしょう。その場合、次の答えは、代わりにステップ2で生成されていました。
v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= t=0 0 c=IN IP4 192.0.2.2 m=audio 54568 RTP/AVP 98 a=rtpmap:98 AMR/8000
V = 0 O = -24351 621814 IN IP4 192.0.2.2 S = T = 0 0 C = IN IP4 192.0.2.2 M = Audio 54568 RTP/AVP 98 A = RTPMAP：98 AMR/8000
Finally, if Bob had chosen to use SDP security descriptions instead of DTLS-SRTP, the following answer would have been generated:
最後に、ボブがDTLS-SRTPの代わりにSDPセキュリティの説明を使用することを選択した場合、次の答えが生成されます。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:2 t=2 a=3
The following example illustrates how to use the SDP Capability Negotiation extensions to support so-called Best-Effort Secure RTP as well as alternative keying mechanisms, more specifically MIKEY [RFC3830] and SDP security descriptions. The offerer (Alice) wants to establish an audio and video session. Alice prefers to use session-level MIKEY as the key management protocol, but supports SDP security descriptions as well.
次の例は、SDP機能交渉拡張機能を使用して、いわゆるベストエフォルトセキュアなRTPと代替キーイングメカニズム、より具体的にはマイキー[RFC3830]およびSDPセキュリティ記述をサポートする方法を示しています。オファー（アリス）は、オーディオとビデオセッションを確立したいと考えています。アリスは、セッションレベルのマイキーを主要な管理プロトコルとして使用することを好みますが、SDPセキュリティの説明もサポートしています。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
この例は、以下の申し出/回答の交換によって示されています。ここでは、アリスはボブに申し出を送ります。
Alice Bob
アリスボブ
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (3) Offer (RTP/SAVP, SDES) |
|--------------------------------------->|
| |
| (4) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
Alice's offer includes an audio and a video stream. The audio stream offers use of plain RTP and Secure RTP as alternatives, whereas the video stream offers use of plain RTP, RTP with RTCP-based feedback, Secure RTP, and Secure RTP with RTCP-based feedback as alternatives:
アリスのオファーには、オーディオとビデオストリームが含まれています。オーディオストリームは、代替としてプレーンRTPと安全なRTPの使用を提供しますが、ビデオストリームは、代替としてRTCPベースのフィードバック、セキュアRTP、およびRTPベースのフィードバックを備えた安全なRTPを備えたプレーンRTP、RTPを代替として使用します。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=2 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtcp-fb:* nack
a=pcfg:1 t=1 a=1,4|3,4
a=pcfg:2 t=2 a=1|3
a=pcfg:3 t=3 a=4
The potential configuration for the audio stream specifies use of transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY as the keying mechanism) or 2 (SDP security descriptions as the keying mechanism). Support for either of these attribute capabilities is mandatory. There are three potential configurations for the video stream.
オーディオストリームの潜在的な構成は、トランスポート機能2（RTP/SAVP）および属性機能1（キーイングメカニズムとしてのセッションレベルのマイキー）または2（キーイングメカニズムとしてのSDPセキュリティ説明）の使用を指定します。これらの属性機能のいずれかのサポートは必須です。ビデオストリームには3つの潜在的な構成があります。
o The first configuration with configuration number 1 uses transport capability 1 (RTP/SAVPF) with either attribute capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" attribute) or attribute capabilities 3 and 4 (SDP security descriptions and the "rtcp-fb" attribute). In this example, the offerer insists on not only the keying mechanism being supported, but also that the "rtcp-fb" attribute is supported with the value indicated. Consequently, all the attribute capabilities are marked as mandatory in this potential configuration.
o 構成番号1を使用した最初の構成では、属性機能1と4（セッションレベルのMikeyおよび「RTCP-FB」属性）または属性機能3と4（SDPセキュリティ記述と属性機能を備えたトランスポート機能1（RTP/SAVPF）を使用します。rtcp-fb "属性）。この例では、提供者は、サポートされているキーイングメカニズムだけでなく、「RTCP-FB」属性が示された値とサポートされることを主張しています。したがって、すべての属性機能は、この潜在的な構成で必須としてマークされています。
o The second configuration with configuration number 2 uses transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY) or attribute capability 3 (SDP security descriptions). Both attribute capabilities are mandatory in this configuration.
o 構成番号2の2番目の構成では、トランスポート機能2（RTP/SAVP）と属性機能1（セッションレベルのMikey）または属性機能3（SDPセキュリティの説明）を使用します。この構成では、両方の属性機能が必須です。
o The third configuration with configuration number 3 uses transport capability 3 (RTP/AVPF) and mandatory attribute capability 4 (the "rtcp-fb" attribute).
o 構成番号3の3番目の構成では、トランスポート機能3（RTP/AVPF）と必須属性機能4（「RTCP-FB」属性）を使用します。
Bob receives the SDP session description offer from Alice. Bob supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP Capability Negotiation extensions. Bob also supports SDP security descriptions, but not MIKEY, and hence he generates the following answer:
ボブは、アリスからSDPセッションの説明オファーを受け取ります。BOBは、RTCPベースのフィードバックとSDP機能交渉拡張を備えたSecure RTP、Secure RTPをサポートしています。ボブはSDPセキュリティの説明もサポートしていますが、マイキーではありません。したがって、彼は次の答えを生成します。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=2 a=2
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
a=acfg:1 t=1 a=3,4
For the audio stream, Bob accepted the use of Secure RTP, and hence the profile in the "m=" line is "RTP/SAVP". Bob also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the audio media stream from the offer, using transport capability 2 (RTP/SAVP) and attribute capability 2 (the "crypto" attribute from the offer). For the video stream, Bob accepted the use of Secure RTP with RTCP-based feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the video stream from the offer, using transport capability 1 (RTP/SAVPF) and attribute capabilities 3 (the "crypto" attribute from the offer) and 4 (the "rtcp-fb" attribute from the offer).
オーディオストリームの場合、ボブは安全なRTPの使用を受け入れ、したがって「M =」行のプロファイルは「RTP/SAVP」です。ボブには、彼自身のキーイング素材を備えた「暗号」属性、およびオファー能力2（RTP/avp）と属性機能2を使用して、オファーからのオーディオメディアストリームの実際の構成1を識別する「ACFG」属性も含まれています（crypto 2（」「オファーからの属性）。ビデオストリームの場合、ボブはRTCPベースのフィードバックを備えた安全なRTPの使用を受け入れ、したがって「m =」行のプロファイルは「RTP/SAVPF」です。ボブには、彼自身のキーイング素材を備えた「暗号」属性、およびオファー能力1（RTP/SAVPF）と属性機能3（「Crypto」」を使用して、オファーからのビデオストリームの実際の構成1を識別する「ACFG」属性も含まれています。オファーからの属性）および4（オファーからの「RTCP-FB」属性）。
When Alice receives Bob's answer, session negotiation has completed; however, Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the capability negotiation extensions (and hence may not understand the negotiation that just took place).
アリスがボブの回答を受け取ると、セッションの交渉が完了しました。ただし、アリスは、実際の構成を使用して新しいオファーを生成することを選択します。これは、アリスとボブの間に存在するが、能力交渉拡張をサポートしていない可能性のある仲介者を支援するために純粋に行われます（したがって、行われた交渉を理解していない可能性があります）。
Alice's updated offer includes only SRTP for the audio stream SRTP with RTCP-based feedback for the video stream, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well is she wanted):
Aliceの更新されたオファーには、ビデオストリームのRTCPベースのフィードバックを備えたオーディオストリームSRTPのSRTPのみが含まれており、SDP機能交渉フレームワークを使用していません（アリスは、彼女が望んでいる機能も含めていたかもしれません）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 52000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nack
The "m=" line for the audio stream now indicates that Alice is offering to use Secure RTP with PCMU or G.729, whereas the "m=" line for the video stream indicates that Alice is offering to use Secure RTP with RTCP-based feedback and H.261. Each media stream includes a "crypto" attribute, which provides the SRTP keying material, with the same value again.
オーディオストリームの「M =」行は、AliceがPCMUまたはG.729で安全なRTPを使用することを提供していることを示していますが、ビデオストリームの「M =」行は、AliceがRTCPで安全なRTPを使用することを申し出ていることを示しています。ベースのフィードバックとH.261。各メディアストリームには、「暗号」属性が含まれており、SRTPキーイング素材を提供し、同じ値を再び提供します。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
ボブは、アリスからSDPセッションの説明オファーを受け取り、それを受け入れ、アリスへの回答を生成します。
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
Bob includes the same "crypto" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
ボブには以前と同じ「暗号」属性が含まれており、セッションは変更なしで進行します。ボブは彼の答えに能力を含めていませんでしたが、彼が望んでいれば彼はそうすることができたでしょう。
Note that in this particular example, the answerer supported the capability extensions defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
この特定の例では、回答者はここで定義されている機能拡張機能をサポートしていたことに注意してください。しかし、彼がそうでなければ、応答者はステップ1で受け取った新しい属性を単に無視し、通常のRTPを使用するという申し出を受け入れたでしょう。その場合、次の答えは、代わりにステップ2で生成されていました。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
m=video 55468 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
Finally, if Bob had chosen to use session-level MIKEY instead of SDP security descriptions, the following answer would have been generated:
最後に、ボブがSDPセキュリティの説明の代わりにセッションレベルのマイキーを使用することを選択した場合、次の答えが生成されます。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4
It should be noted, that although Bob could have chosen session-level MIKEY for one media stream, and SDP security descriptions for another media stream, there are no well-defined offerer processing rules of the resulting answer for this, and hence the offerer may incorrectly assume use of MIKEY for both streams. To avoid this, if the answerer chooses session-level MIKEY, then all Secure RTP-based media streams SHOULD use MIKEY (this applies irrespective of whether or not SDP Capability Negotiation is being used). Use of media-level MIKEY does not have a similar constraint.
ボブは1つのメディアストリームにセッションレベルのマイキーを選択でき、別のメディアストリームのSDPセキュリティの説明を選択できたかもしれませんが、結果の回答の明確なオファー処理ルールはありません。両方のストリームでマイキーの使用を誤って想定しています。これを回避するために、回答者がセッションレベルのマイキーを選択した場合、すべての安全なRTPベースのメディアストリームはMikeyを使用する必要があります（これは、SDP機能交渉が使用されているかどうかに関係なく適用されます）。メディアレベルのマイキーの使用には、同様の制約はありません。
The following example illustrates how to use the SDP Capability Negotiation framework to negotiate use of either MIKEY or SDP security descriptions, when one of them is included as part of the actual configuration, and the other one is being selected. The offerer (Alice) wants to establish an audio and video session. Alice prefers to use session-level MIKEY as the key management protocol, but supports SDP security descriptions as well.
次の例は、SDP機能交渉フレームワークを使用してMikeyまたはSDPセキュリティの説明の使用を交渉する方法を示しています。オファー（アリス）は、オーディオとビデオセッションを確立したいと考えています。アリスは、セッションレベルのマイキーを主要な管理プロトコルとして使用することを好みますが、SDPセキュリティの説明もサポートしています。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
この例は、以下の申し出/回答の交換によって示されています。ここでは、アリスはボブに申し出を送ります。
Alice Bob
アリスボブ
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
Alice's offer includes an audio and a video stream. Both the audio and the video stream offer use of Secure RTP:
アリスのオファーには、オーディオとビデオストリームが含まれています。オーディオとビデオストリームの両方で、安全なRTPを使用しています。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 a=-s:1
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 a=-s:2
Alice does not know whether Bob supports MIKEY or SDP security descriptions. She could include attributes for both; however, the resulting procedures and potential interactions are not well-defined. Instead, she places a session-level "key-mgmt" attribute for MIKEY in the actual configuration with SDP security descriptions as an alternative in the potential configuration. The potential configuration for the audio stream specifies that all session-level attributes are to be deleted (i.e., the session-level "a=key-mgmt" attribute) and that mandatory attribute capability 2 is to be used (i.e., the "crypto" attribute). The potential configuration for the video stream is similar, except it uses its own mandatory "crypto" attribute capability (2). Note how the deletion of the session-level attributes does not affect the media-level attributes.
アリスは、ボブがマイキーとSDPのセキュリティの説明をサポートしているかどうかを知りません。彼女は両方の属性を含めることができます。ただし、結果の手順と潜在的な相互作用は明確に定義されていません。代わりに、彼女は潜在的な構成の代替としてSDPセキュリティの説明を使用して、実際の構成にマイキーのセッションレベルの「key-mgmt」属性を配置します。オーディオストリームの潜在的な構成は、すべてのセッションレベルの属性が削除されること（つまり、セッションレベルの「a = key-mgmt "属性）を削除すること、および必須属性機能2が使用されることを指定します（つまり、「crypto」" 属性）。ビデオストリームの潜在的な構成は類似していますが、独自の必須の「暗号」属性機能（2）を使用します。セッションレベルの属性の削除がメディアレベルの属性にどのように影響しないかに注意してください。
Bob receives the SDP session description offer from Alice. Bob supports Secure RTP and the SDP Capability Negotiation framework. Bob also supports both SDP security descriptions and MIKEY. Since the potential configuration is more preferred than the actual configuration, Bob (conceptually) generates an internal potential configuration SDP session description that contains the "crypto" attributes for the audio and video stream, but not the "key-mgmt" attribute for MIKEY, thereby avoiding any ambiguity between the two keying mechanisms. As a result, he generates the following answer:
ボブは、アリスからSDPセッションの説明オファーを受け取ります。Bobは、Secure RTPとSDP機能交渉フレームワークをサポートしています。ボブは、SDPセキュリティの説明とマイキーの両方をサポートしています。潜在的な構成は実際の構成よりも優先されるため、BOBは（概念的に）オーディオおよびビデオストリームの「暗号」属性を含む内部潜在的な構成SDPセッション説明を生成しますが、Mikeyの「Key-MGMT」属性ではありません。それにより、2つのキーイングメカニズム間のあいまいさを回避します。その結果、彼は次の答えを生成します。
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 a=-s:1
m=video 55468 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=acfg:1 a=-s:2
For the audio stream, Bob accepted the use of Secure RTP using SDP security descriptions. Bob therefore includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying the actual configuration 1 for the audio media stream from the offer, with the delete-attributes ("-s") and attribute capability 1 (the "crypto" attribute from the offer). For the video stream, Bob also accepted the use of Secure RTP using SDP security descriptions. Bob therefore includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the video stream from the offer, with the delete-attributes ("-s") and attribute capability 2.
オーディオストリームの場合、ボブはSDPセキュリティの説明を使用して安全なRTPの使用を受け入れました。したがって、ボブには、彼自身のキーイング素材を備えた「暗号」属性と、オファーからのオーディオメディアストリームの実際の構成1を識別する「ACFG」属性が含まれています。オファーからの「暗号」属性）。ビデオストリームの場合、ボブはSDPセキュリティの説明を使用して安全なRTPの使用も受け入れました。したがって、ボブには、彼自身のキーイング素材を備えた「暗号」属性と、オファーからのビデオストリームの実際の構成1を識別する「ACFG」属性が含まれており、削除アトリブ（ "-s"）と属性機能2が含まれています。
Below, we illustrate the offer SDP session description, when Bob instead offers the "crypto" attribute as the actual configuration keying mechanism and "key-mgmt" as the potential configuration:
以下に、Bobが実際の構成キーイングメカニズムとして「Crypto」属性を提供し、「キー-MGMT」を潜在的な構成として「Crypto」属性を提供する場合、SDPセッションのオファーの説明を示します。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:2 rtpmap:98 AMR/8000
a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtpmap:31 H261/90000
a=pcfg:1 a=-m:1,4
Note how we this time need to perform delete-attributes at the media level instead of the session level. When doing that, all attributes from the actual configuration SDP session description, including the rtpmaps provided, are removed. Consequently, we had to include these rtpmaps as capabilities as well, and then include them in the potential configuration, thereby effectively recreating the original "rtpmap" attributes in the resulting potential configuration SDP session description.
今回は、セッションレベルの代わりにメディアレベルで削除アトリブを実行する必要がある方法に注意してください。それを行うと、提供されたRTPMAPを含む実際の構成SDPセッションの説明からのすべての属性が削除されます。その結果、これらのrtpMapを機能として含める必要があり、潜在的な構成にそれらを含める必要がありました。
The SDP Capability Negotiation framework is defined to be used within the context of the offer/answer model, and hence all the offer/answer security considerations apply here as well [RFC3264]. Similarly, the Session Initiation Protocol (SIP) uses SDP and the offer/answer model, and hence, when used in that context, the SIP security considerations apply as well [RFC3261].
SDP機能交渉フレームワークは、オファー/回答モデルのコンテキスト内で使用されるように定義されているため、すべてのオファー/回答のセキュリティに関する考慮事項もここにも適用されます[RFC3264]。同様に、セッション開始プロトコル（SIP）はSDPとオファー/回答モデルを使用するため、そのコンテキストで使用すると、SIPセキュリティに関する考慮事項も適用されます[RFC3261]。
However, SDP Capability Negotiation introduces additional security issues. Its use as a mechanism to enable alternative transport protocol negotiation (secure and non-secure) as well as its ability to negotiate use of more or less secure keying methods and material warrant further security considerations. Also, the (continued) support for receiving media before answer combined with negotiation of alternative transport protocols (secure and non-secure) warrants further security considerations. We discuss these issues below.
ただし、SDP機能交渉は追加のセキュリティ問題を導入します。代替輸送プロトコルの交渉（安全および非セキュア）を可能にするメカニズムとしての使用、および多かれ少なかれ安全なキーイング方法と重要な材料の使用を交渉する能力と、さらなるセキュリティ上の考慮事項を保証します。また、回答の前にメディアを受け取ることに対する（継続的な）サポートと代替輸送プロトコル（安全および非セキュア）の交渉と組み合わされて、さらなるセキュリティ上の考慮事項が必要です。これらの問題については、以下で説明します。
The SDP Capability Negotiation framework allows for an offered media stream to both indicate and support various levels of security for that media stream. Different levels of security can for example be negotiated by use of alternative attribute capabilities each indicating more or less secure keying methods as well as more or less strong ciphers. Since the offerer indicates support for each of these alternatives, he will presumably accept the answerer seemingly selecting any of the offered alternatives. If an attacker can modify the SDP session description offer, he can thereby force the negotiation of the weakest security mechanism that the offerer is willing to accept. This may enable the attacker to compromise the security of the negotiated media stream. Similarly, if the offerer wishes to negotiate use of a secure media stream (e.g., Secure RTP), but includes a non-secure media stream (e.g., plain RTP) as a valid (but less preferred) alternative, then an attacker that can modify the offered SDP session description will be able to force the establishment of an insecure media stream. The solution to both of these problems involves the use of integrity protection over the SDP session description. Ideally, this integrity protection provides end-to-end integrity protection in order to protect from any man-in-the-middle attack; secure multiparts such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] provide one such solution; however, S/MIME requires use and availability of a Public Key Infrastructure (PKI). A slightly less secure alternative when using SIP, but generally much easier to deploy in practice, is to use SIP Identity [RFC4474]; this requires the existence of an authentication service (see [RFC4474]). Although this mechanism still requires a PKI, it only requires that servers (as opposed to end-users) have third-party validatable certificates, which significantly reduces the barrier to entry by ordinary users. Yet another, and considerably less secure, alternative is to use hop-by-hop security only, e.g., TLS or IPsec thereby ensuring the integrity of the offered SDP session description on a hop-by-hop basis. This is less secure because SIP allows partially trusted intermediaries on the signaling path, and such intermediaries processing the SIP request at each hop would be able to perform a man-in-the-middle attack by modifying the offered SDP session description. In simple architectures where the two UA's proxies communicate directly, the security provided by this method is roughly comparable to that provided by the previously discussed signature-based mechanisms.
SDP機能交渉フレームワークにより、提供されたメディアストリームがそのメディアストリームのさまざまなレベルのセキュリティを示し、サポートすることができます。たとえば、さまざまなレベルのセキュリティは、それぞれが多かれ少なかれ安全なキーイング方法と多かれ少なかれ強力な暗号を示す代替属性機能を使用することで交渉できます。オファーはこれらのそれぞれの代替品のサポートを示しているため、提供されている代替案のいずれかを選択しているように見える回答者をおそらく受け入れるでしょう。攻撃者がSDPセッションの説明オファーを変更できる場合、それにより、提供者が受け入れようとする最も弱いセキュリティメカニズムの交渉を強制することができます。これにより、攻撃者はネゴシエートされたメディアストリームのセキュリティを妥協することができます。同様に、オファーが安全なメディアストリームの使用（たとえば、セキュアRTP）の使用を交渉したいが、有効な（ただし希望のない）代替として非セキュアなメディアストリーム（たとえばプレーンRTP）が含まれている場合、できる場合は、できる攻撃者を含む場合提供されるSDPセッションの説明を変更すると、安全でないメディアストリームの確立が強制されます。これらの両方の問題の解決策には、SDPセッションの説明に対する整合性保護の使用が含まれます。理想的には、この整合性保護は、中間の攻撃から保護するためにエンドツーエンドの完全性保護を提供します。Secure/Multipurpose Internet Mail Extensions（S/MIME）[RFC5751]などの安全なマルチパートは、そのようなソリューションを提供します。ただし、S/MIMEでは、公開キーインフラストラクチャ（PKI）の使用と可用性が必要です。SIPを使用する場合は少し安全性の低い代替品ですが、一般的に実際に展開するのがはるかに簡単なものは、SIP ID [RFC4474]を使用することです。これには、認証サービスの存在が必要です（[RFC4474]を参照）。このメカニズムにはPKIが依然として必要ですが、サーバー（エンドユーザーとは対照的に）がサードパーティの有効な証明書を持つことのみが必要であり、通常のユーザーによるエントリへの障壁を大幅に削減します。さらに別の、そしてかなり安全でない代替手段は、ホップバイホップセキュリティのみを使用することです。たとえば、TLSやIPSECなど、ホップバイホップベースで提供されたSDPセッションの説明の整合性を確保します。SIPは信号パスで部分的に信頼できる仲介者を許可するため、これはそれほど安全ではありません。また、各ホップでSIP要求を処理するような仲介者は、提供されるSDPセッションの説明を変更することにより、中間の攻撃を実行できるためです。2つのUAのプロキシが直接通信する単純なアーキテクチャでは、この方法で提供されるセキュリティは、以前に議論された署名ベースのメカニズムによって提供されたセキュリティとほぼ匹敵します。
Per the normal offer/answer procedures, as soon as the offerer has generated an offer, the offerer must be prepared to receive media in accordance with that offer. The SDP Capability Negotiation preserves that behavior for the actual configuration in the offer; however, the offerer has no way of knowing which configuration (actual or potential) was selected by the answerer, until an answer indication is received. This opens up a new security issue where an attacker may be able to interject media towards the offerer until the answer is received. For example, the offerer may use plain RTP as the actual configuration and Secure RTP as an alternative potential configuration. Even though the answerer selects Secure RTP, the offerer will not know that until he receives the answer, and hence an attacker will be able to send media to the offerer meanwhile. The easiest protection against such an attack is to not offer use of the non-secure media stream in the actual configuration; however, that may in itself have undesirable side effects: If the answerer does not support the secure media stream and also does not support the capability negotiation framework, then negotiation of the media stream will fail. Alternatively, SDP security preconditions [RFC5027] can be used. This will ensure that media is not flowing until session negotiation has completed and hence the selected configuration is known. Use of preconditions however requires both sides to support them. If they don't, and use of them is required, the session will fail. As a (limited) work around to this, it is RECOMMENDED that SIP entities generate an answer SDP session description and send it to the offerer as soon as possible, for example, in a 183 Session Progress message. This will limit the time during which an attacker can send media to the offerer. Section 3.9 presents other alternatives as well.
通常のオファー/回答手順に従って、オファーがオファーを生成するとすぐに、オファーはそのオファーに従ってメディアを受け取る準備をしなければなりません。SDP機能交渉は、オファーの実際の構成の動作を保持します。ただし、オファーは、回答者が受信するまで、応答者によってどの構成（実際または電位）が選択されたかを知る方法がありません。これにより、攻撃者が回答が受信されるまでメディアをオファーに向けて介入できる新しいセキュリティ問題が開かれます。たとえば、オファーはプレーンRTPを実際の構成として使用し、代替の潜在的な構成としてRTPを保護することができます。回答者は安全なRTPを選択しますが、提供者は回答を受け取るまでそれを知りません。このような攻撃に対する最も簡単な保護は、実際の構成で非セキュアなメディアストリームを使用しないことです。ただし、それ自体が望ましくない副作用がある場合があります。応答者が安全なメディアストリームをサポートせず、機能交渉のフレームワークもサポートしていない場合、メディアストリームのネゴシエーションは失敗します。または、SDPセキュリティの前提条件[RFC5027]を使用できます。これにより、セッションの交渉が完了するまでメディアが流れないため、選択された構成が既知になります。ただし、前提条件を使用するには、双方がサポートする必要があります。そうでない場合、およびそれらの使用が必要な場合、セッションは失敗します。これについて（限られた）回避策として、SIPエンティティは回答SDPセッションの説明を生成し、たとえば183セッションの進捗メッセージでできるだけ早く提供者に送信することをお勧めします。これにより、攻撃者がメディアをオファーに送ることができる時間が制限されます。セクション3.9は、他の代替品も示しています。
Additional security considerations apply to the answer SDP session description as well. The actual configuration attribute tells the offerer on which potential configuration the answer was based, and hence an attacker that can either modify or remove the actual configuration attribute in the answer can cause session failure as well as extend the time window during which the offerer will accept incoming media that does not conform to the actual answer. The solutions to this SDP session description answer integrity problem are the same as for the offer, i.e., use of end-to-end integrity protection, SIP identity, or hop-by-hop protection. The mechanism to use depends on the mechanisms supported by the offerer as well as the acceptable security trade offs.
追加のセキュリティ上の考慮事項は、回答SDPセッションの説明にも適用されます。実際の構成属性は、回答の潜在的な構成のどの潜在的な構成のかについて提供者に伝えます。したがって、回答の実際の構成属性を変更または削除できる攻撃者は、セッション障害を引き起こし、提供者が受け入れる時間ウィンドウを延長する可能性があります実際の答えに準拠していない着信メディア。このSDPセッション説明の解決策の解決策の整合性の問題は、オファーの場合と同じです。つまり、エンドツーエンドの整合性保護、SIP ID、またはホップバイホップ保護の使用です。使用するメカニズムは、提供者がサポートするメカニズムと、許容可能なセキュリティトレードオフに依存します。
As described in Sections 3.1 and 3.11, SDP Capability Negotiation conceptually allows an offerer to include many different offers in a single SDP session description. This can cause the answerer to process a large number of alternative potential offers, which can consume significant memory and CPU resources. An attacker can use this amplification feature to launch a denial-of-service attack against the answerer. The answerer must protect itself from such attacks. As explained in Section 3.11, the answerer can help reduce the effects of such an attack by first discarding all potential configurations that contain unsupported transport protocols, unsupported or invalid mandatory attribute capabilities, or unsupported mandatory extension configurations. The answerer should also look out for potential configurations that are designed to pass the above test, but nevertheless produce a large number of potential configuration SDP session descriptions that cannot be supported.
セクション3.1および3.11で説明されているように、SDP機能交渉により、オファー担当者は単一のSDPセッションの説明に多くの異なるオファーを含めることができます。これにより、回答者が多数の代替潜在的なオファーを処理する可能性があり、重要なメモリとCPUリソースを消費できます。攻撃者は、この増幅機能を使用して、回答者に対するサービス拒否攻撃を開始できます。応答者は、そのような攻撃から身を守らなければなりません。セクション3.11で説明したように、アンサーは、サポートされていない輸送プロトコル、サポートされていないまたは無効な必須属性機能、またはサポートされていない必須拡張構成を含むすべての潜在的な構成を最初に破棄することにより、このような攻撃の影響を減らすのに役立ちます。また、回答者は、上記のテストに合格するように設計された潜在的な構成を調べる必要がありますが、それでもサポートできない多数の潜在的な構成SDPセッションの説明を生成します。
A possible way of achieving that is for an attacker to find a valid session-level attribute that causes conflicts or otherwise interferes with individual media description configurations. At the time of publication of this document, we do not know of such an SDP attribute; however, this does not mean it does not exist, or that it will not exist in the future. If such attributes are found to exist, implementers should explicitly protect against them.
それを達成する可能性のある方法は、攻撃者が競合を引き起こすか、そうでなければ個々のメディアの説明構成を妨げる有効なセッションレベルの属性を見つけることです。このドキュメントの公開時点では、そのようなSDP属性を知りません。ただし、これは存在しないことを意味するものではなく、将来存在しないことを意味しません。そのような属性が存在することがわかった場合、実装者はそれらから明示的に保護する必要があります。
A significant number of valid and supported potential configurations may remain. However, since all of those contain only valid and supported transport protocols and attributes, it is expected that only a few of them will need to be processed on average. Still, the answerer must ensure that it does not needlessly consume large amounts of memory or CPU resources when processing those as well as be prepared to handle the case where a large number of potential configurations still need to be processed.
かなりの数の有効でサポートされている潜在的な構成が残っている可能性があります。ただし、それらはすべて有効でサポートされている輸送プロトコルと属性のみを含むため、平均して処理する必要があるのは数人だけであると予想されます。それでも、回答者は、それらを処理するときに大量のメモリまたはCPUリソースを不必要に消費しないことを確認し、多数の潜在的な構成を処理する必要がある場合を処理する準備をする必要があります。
The IANA has registered the following new SDP attributes:
IANAは、次の新しいSDP属性を登録しています。
Attribute name: csup Long form name: Supported capability negotiation extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Option tags for supported SDP Capability Negotiation extensions Appropriate values: See Section 3.3.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名：CSUPロングフォーム名：サポートされている機能交渉拡張型属性タイプ：セッションレベルとメディアレベルcharsetの対象：目的なし：サポートされているSDP機能交渉拡張のオプションタグ適切な値：RFC 5939連絡先セクション3.3.1を参照名前：Flemming Andreasen、fandreas@cisco.com
Attribute name: creq Long form name: Required capability negotiation extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Option tags for required SDP Capability Negotiation extensions Appropriate values: See Section 3.3.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com Attribute name: acap Long form name: Attribute capability Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute capability containing an attribute name and associated value Appropriate values: See Section 3.4.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名：CREQ LONGフォーム名：必要な機能交渉拡張属性のタイプ：セッションレベルとメディアレベルcharsetの対象：目的なし：必要なSDP機能交渉拡張のオプションタグ適切な値：RFC 5939のセクション3.3.2を参照名前：Flemming Andreasen、fandreas@cisco.com属性名：ACAPロングフォーム名：属性機能タイプの属性：セッションレベルおよびメディアレベルの文字の対象：charset：属性名と関連する値を含む属性機能：適切な値：RFC 5939のセクション3.4.1を参照してください
Attribute name: tcap Long form name: Transport Protocol Capability Type of attribute: Session-level and media-level Subject to charset: No Purpose: Transport protocol capability listing one or more transport protocols Appropriate values: See Section 3.4.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名：TCAPロングフォーム名：トランスポートプロトコル機能の属性のタイプ：セッションレベルとメディアレベルのcharset：なし目的：輸送プロトコル機能リスト1つ以上の輸送プロトコル適切な値：RFC 5939連絡先セクション3.4.2を参照名前：Flemming Andreasen、fandreas@cisco.com
Attribute name: pcfg Long form name: Potential Configuration Type of attribute: Media-level Subject to charset: No Purpose: Potential configuration for SDP Capability Negotiation Appropriate values: See Section 3.5.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名：PCFGロングフォーム名：潜在的な構成属性のタイプ：メディアレベルの文献の対象：charset：なし目的：SDP機能交渉の潜在的な構成適切な値：RFCのセクション3.5.1連絡先名：Flemming Andreasen、Fandreas@cisco.com
Attribute name: acfg Long form name: Actual configuration Type of attribute: Media-level Subject to charset: No Purpose: Actual configuration for SDP Capability Negotiation Appropriate values: See Section 3.5.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名：ACFGロングフォーム名：実際の構成属性のタイプ：メディアレベルcharsetの対象：charset：なし目的：SDP機能交渉の実際の構成適切な値：RFCのセクション3.5.2を参照.com
The IANA has created a new SDP Capability Negotiation Option Tag registry. An IANA SDP Capability Negotiation Option Tag registration MUST be documented in an RFC in accordance with the [RFC5226] IETF Review policy. The RFC MUST provide the name of the option tag, a syntax, and a semantic specification of any new SDP attributes and any extensions to the potential configuration ("a=pcfg") and actual configuration ("a=acfg") attributes provided in this document. If the extension defines any new SDP attributes that are intended to be capabilities for use by the capability negotiation framework (e.g., similar to "a=acap"), those capabilities MUST adhere to the guidelines provided in Section 3.4.3. Extensions to the potential and actual configuration attributes MUST adhere to the syntax provided in Sections 3.5.1 and 3.5.2.
IANAは、新しいSDP機能交渉オプションタグレジストリを作成しました。IANA SDP機能交渉オプションタグ登録は、[RFC5226] IETFレビューポリシーに従ってRFCに文書化する必要があります。RFCは、オプションタグの名前、構文、および新しいSDP属性のセマンティック仕様と、潜在的な構成（ "a = pcfg"）および実際の構成（ "a = acfg"）属性の拡張機能を提供する必要があります。このドキュメント。拡張機能が、機能交渉フレームワークで使用する機能になることを目的とした新しいSDP属性を定義する場合（たとえば、「A = ACAP」と同様）、それらの機能はセクション3.4.3で提供されるガイドラインに準拠する必要があります。電位および実際の構成属性への拡張は、セクション3.5.1および3.5.2で提供されている構文に準拠する必要があります。
The option tag "cap-v0" is defined in this document, and the IANA has registered this option tag.
オプションタグ「CAP-V0」はこのドキュメントで定義されており、IANAはこのオプションタグを登録しています。
The IANA has created a new SDP Capability Negotiation Potential Configuration Parameter registry. An IANA SDP Capability Negotiation Potential Configuration registration MUST be documented in an RFC in accordance with the [RFC5226] IETF Review policy. The RFC MUST define the syntax and semantics of each new potential configuration parameter. The syntax MUST adhere to the syntax provided for extensions in Section 3.5.1 and the semantics MUST adhere to the semantics provided for extensions in Section 3.5.1 and 3.5.2. Associated with each registration MUST be the encoding name for the parameter as well as a short descriptive name for it.
IANAは、新しいSDP機能交渉潜在的な構成パラメーターレジストリを作成しました。IANA SDP機能交渉潜在的な構成登録は、[RFC5226] IETFレビューポリシーに従ってRFCに文書化する必要があります。RFCは、新しい潜在的な構成パラメーターごとに構文とセマンティクスを定義する必要があります。構文は、セクション3.5.1の拡張に提供される構文に付着する必要があり、セマンティクスはセクション3.5.1および3.5.2の拡張に提供されるセマンティクスに付着する必要があります。各登録に関連付けられていることは、パラメーターのエンコード名とその短い記述名でなければなりません。
The potential configuration parameters "a" for "attribute" and "t" for "transport protocol" are defined in this document, and the IANA has registered them.
「属性」の潜在的な構成パラメーター「a」と「トランスポートプロトコル」の「t」は、このドキュメントで定義されており、IANAはそれらを登録しています。
The SDP Capability Negotiation solution defined in this document draws on the overall capability negotiation framework that was defined by [SDPng]. Also, the SDP Capability Negotiation solution is heavily influenced by the discussions and work done by the SDP Capability Negotiation Design Team. The following people in particular provided useful comments and suggestions to either the document itself or the overall direction of the solution defined here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean-Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas Stach, and Dan Wing.
このドキュメントで定義されているSDP機能交渉ソリューションは、[SDPNG]によって定義された全体的な機能交渉フレームワークに基づいています。また、SDP能力交渉ソリューションは、SDP Capability Negotiation Design Teamによって行われた議論と作業に大きく影響されます。特に以下の人々は、ドキュメント自体またはここで定義されているソリューションの全体的な方向のいずれかに有用なコメントと提案を提供しました：フランソワ・オーデット、ジョン・エルウェル、ロニ・イヴ・イ・イヴ・ギルシア、ロバート・ギルマン、カレン・ジェニングス、ジョナサン・レノックス、マット・レピンキ、ジャン-Francois Mule、Joerg Ott、Colin Perkins、Jonathan Rosenberg、Thomas Stach、Dan Wing。
General Area review comments were provided by Christian Vogt, and Stephen Kent provided Security Directorate review comments. Eric Rescorla provided textual input to the Security Considerations. Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided several review comments as well.
一般的なレビューのコメントはChristian Vogtによって提供され、Stephen Kentはセキュリティ局のレビューコメントを提供しました。Eric Rescorlaは、セキュリティ上の考慮事項にテキスト入力を提供しました。Alexey Melnikov、Robert Sparks、Magnus Westerlundもいくつかのレビューコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] Camarillo、G.、Ed。、Marshall、W.、Ed。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、F。、「セッション説明プロトコル（SDP）シンプルな機能宣言」、RFC 3407、2002年10月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4567] 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.
[RFC4567] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ説明」、RFC 4568、2006年7月。
[RFC4585] 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.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP再送信ペイロードフォーマット」、RFC 4588、2006年7月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756] Li、A。、「セッション説明プロトコルのフォワードエラー補正セマンティクス」、RFC 4756、2006年11月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027] Andreasen、F。およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ前提条件」、RFC 5027、2007年10月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124] OTT、J。およびE. Carrara、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）のセキュアーRTPプロファイルを拡張しました」、RFC 5124、2008年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「データグラム輸送層セキュリティ（DTLS）を使用した安全なリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション説明プロトコル（SDP）グループ化フレームワーク」、RFC 5888、2010年6月。
[BESRTP] Kaplan, H. and F. Audet, "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", Work in Progress, October 2006.
[BESRTP] Kaplan、H。およびF. Audet、「セッション説明プロトコル（SDP）は、ベストエフォルトセキュアリアルタイムトランスポートプロトコルのためのオファー/回答交渉」、2006年10月の進行中の作業。
[ICETCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, September 2010.
[ICETCP] Rosenberg、J.、Keranen、A.、Lowekamp、B。、およびA. Roach、「Interactive Connectivity Indecivity Indecivitive（ICE）を備えたTCP候補」、2010年9月の作業。
[SDPMedCap] Gilman, R., Even, R., and F. Andreasen, "SDP media capabilities Negotiation", Work in Progress, July 2010.
[SDPMedCap]ギルマン、R。、偶数、R。、およびF.アンドレアセン、「SDPメディア機能交渉」、2010年7月の作業。
[SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description and Capability Negotiation", Work in Progress, February 2005.
[SDPNG] Kutscher、D.、Ott、J。、およびC. Bormann、「セッションの説明と能力交渉」、2005年2月の作業。
Author's Address
著者の連絡先
Flemming Andreasen Cisco Systems Iselin, NJ 08830 USA
Flemming Andreasen Cisco Systems Iselin、NJ 08830 USA
EMail: fandreas@cisco.com