[要約] RFC 7006は、SDPでのさまざまな機能の交渉に関する規格であり、SDPセッションの機能の交渉を改善するために設計されています。目的は、SDPセッションの参加者間での機能の交渉を効率化し、互換性を向上させることです。

Internet Engineering Task Force (IETF)                  M. Garcia-Martin
Request for Comments: 7006                                      Ericsson
Category: Standards Track                                S. Veikkolainen
ISSN: 2070-1721                                                    Nokia
                                                               R. Gilman
                                                          September 2013
        

Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)

セッション記述プロトコル(SDP)のその他の機能ネゴシエーション

Abstract

概要

The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.

セッション記述プロトコル(SDP)は、エンドポイントがトランスポートプロトコルと属性をネゴシエートできるようにする機能ネゴシエーションメカニズムフレームワークで拡張されました。このフレームワークは、エンドポイントが追加のメディア関連機能をネゴシエートできるようにするメディア機能ネゴシエーションメカニズムで拡張されました。この交渉は、広く使用されているSDPオファー/アンサー手順に組み込まれています。

This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).

このメモは、SDP機能ネゴシエーションフレームワークを拡張して、エンドポイントが3つの追加のSDP機能をネゴシエートできるようにします。特に、このメモは、帯域幅( "b ="行)、接続データ( "c ="行)、およびセッションまたはメディアタイトル(各セッションまたはメディアの "i ="行)をネゴシエートするメカニズムを提供します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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(Internet Engineering Task Force)の製品です。これは、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/rfc7006.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7006で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2013 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文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................3
   3. Protocol Description ............................................4
      3.1. Extensions to SDP ..........................................4
           3.1.1. Bandwidth Capability ................................6
           3.1.2. Connection Data Capability ..........................8
           3.1.3. Title Capability ...................................12
      3.2. Session Level versus Media Level ..........................16
      3.3. Offer/Answer Model Extensions .............................17
           3.3.1. Generating the Initial Offer .......................17
           3.3.2. Generating the Answer ..............................17
           3.3.3. Offerer Processing of the Answer ...................18
           3.3.4. Modifying the Session ..............................18
   4. Field Replacement Rules ........................................18
   5. Security Considerations ........................................18
   6. IANA Considerations ............................................19
      6.1. New SDP Attributes ........................................19
      6.2. New Option Tags ...........................................20
      6.3. New SDP Capability Negotiation Configuration Parameters ...20
   7. Acknowledgments ................................................20
   8. References .....................................................20
      8.1. Normative References ......................................20
      8.2. Informative References ....................................21
        
1. Introduction
1. はじめに

The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP has been extended with an SDP Capability Negotiation Mechanism Framework [RFC5939] that allows the endpoints to negotiate capabilities, such as support for the Real-time Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport Protocol (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation [RFC6871] provides negotiation capabilities to media lines as well.

セッション記述プロトコル(SDP)[RFC4566]は、セッションのアナウンス、セッションへの招待、および他の形式のマルチメディアセッション開始のために、マルチメディアセッションを記述することを目的としています。 SDPは、エンドポイントがリアルタイムトランスポートプロトコル(RTP)[RFC3550]やセキュアリアルタイムトランスポートプロトコル(SRTP)のサポートなどの機能をネゴシエートできるようにするSDP機能ネゴシエーションメカニズムフレームワーク[RFC5939]で拡張されました。 RFC3711]。 SDPメディア機能ネゴシエーション[RFC6871]は、メディア回線にもネゴシエーション機能を提供します。

The capability negotiation is embedded into the widely used SDP offer/answer procedure [RFC3264]. This memo provides the means to negotiate further capabilities than those specified in the SDP Capability Negotiation Mechanism Framework [RFC5939] and the SDP Media Capabilities Negotiation [RFC6871]. In particular, this memo provides a mechanism to negotiate bandwidth ("b="), connection data ("c="), and session or media titles ("i=").

機能ネゴシエーションは、広く使用されているSDPオファー/アンサー手順[RFC3264]に組み込まれています。このメモは、SDP機能ネゴシエーションメカニズムフレームワーク[RFC5939]およびSDPメディア機能ネゴシエーション[RFC6871]で指定された機能よりもさらに機能をネゴシエートする手段を提供します。特に、このメモは、帯域幅( "b =")、接続データ( "c =")、セッションまたはメディアのタイトル( "i =")をネゴシエートするメカニズムを提供します。

Since the three added capabilities are independent, it is not expected that implementations will necessarily support all of them at the same time. Instead, it is expected that applications will choose their needed capability for their specific purpose. For this reason, the normative part pertaining to each capability is in a self-contained section: Section 3.1.1 describes the bandwidth capability extension, Section 3.1.2 describes the connection data capability extension, and Section 3.1.3 describes the title capability extension. Separate SDP Capability Negotiation option tags are defined for each capability, allowing endpoints to indicate and/or require support for these extensions according to procedures defined in SDP Capability Negotiation [RFC5939].

追加された3つの機能は独立しているため、実装が必ずしもそれらすべてを同時にサポートすることは期待されていません。代わりに、アプリケーションが特定の目的に必要な機能を選択することが期待されます。このため、各機能に関連する規範的な部分は自己完結型のセクションにあります。セクション3.1.1は帯域幅機能拡張について説明し、セクション3.1.2は接続データ機能拡張について説明し、セクション3.1.3はタイトル機能拡張について説明します。 。機能ごとに個別のSDP機能ネゴシエーションオプションタグが定義されており、エンドポイントはSDP機能ネゴシエーション[RFC5939]で定義された手順に従ってこれらの拡張機能のサポートを示したり要求したりできます。

2. Conventions Used in This Document
2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。

3. Protocol Description
3. プロトコルの説明
3.1. Extensions to SDP
3.1. SDPの拡張

The SDP Capability Negotiation Framework [RFC5939] and the SDP Media Capabilities Negotiation [RFC6871] specify attributes for negotiating SDP capabilities. These documents specify new attributes (e.g., "acap", "tcap", "rmcap", and "omcap") for achieving their purpose. In this document, we define three new additional capability attributes for SDP lines of the general form:

SDP機能ネゴシエーションフレームワーク[RFC5939]およびSDPメディア機能ネゴシエーション[RFC6871]は、SDP機能をネゴシエートするための属性を指定します。これらのドキュメントでは、目的を達成するための新しい属性(「acap」、「tcap」、「rmcap」、「omcap」など)を指定しています。このドキュメントでは、一般的な形式のSDPラインに3つの新しい追加機能属性を定義します。

type=value

type = value

for types "b", "c", and "i". The corresponding capability attributes are respectively defined as:

タイプ「b」、「c」、および「i」の場合。対応する機能属性は、それぞれ次のように定義されます。

o "bcap": bandwidth capability

o 「bcap」:帯域幅機能

o "ccap": connection data capability

o 「ccap」:接続データ機能

o "icap": title capability

o 「icap」:タイトル機能

From the sub-rules of the attribute ("a=") line in SDP [RFC4566], SDP attributes are of the form:

SDP [RFC4566]の属性( "a =")行のサブルールから、SDP属性は次の形式になります。

         attribute          = (att-field ":" att-value) / att-field
         att-field          = token
         att-value          = byte-string
        

Capability attributes use only the "att-field:att-value" form.

機能属性は、「att-field:att-value」形式のみを使用します。

The new capabilities may be referenced in potential configurations ("a=pcfg") or in latent configurations ("a=lcfg") as productions conforming to the <extension-config-list>, as respectively defined in RFC 5939 [RFC5939] and RFC 6871 [RFC6871].

新しい機能は、RFC 5939 [RFC5939]で定義されているように、<extension-config-list>に準拠したプロダクションとして、潜在的な構成( "a = pcfg")または潜在構成( "a = lcfg")で参照できます。 RFC 6871 [RFC6871]。

      extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
      ext-cap-name          = 1*(ALPHA / DIGIT)
                              ; ALPHA and DIGIT defined in RFC 5234
      ext-cap-list          = 1*VCHAR  ; VCHAR defined in RFC 5234
        

The optional "+" is used to indicate that the extension is mandatory and MUST be supported in order to use that particular configuration.

オプションの「+」は、拡張が必須であり、その特定の構成を使用するためにサポートする必要があることを示すために使用されます。

The new capabilities may also be referenced in actual configurations ("a=acfg") as productions conforming to the <sel-extension-config> defined in RFC 5939 [RFC5939].

新しい機能は、実際の構成( "a = acfg")で、RFC 5939 [RFC5939]で定義されている<sel-extension-config>に準拠した製品として参照される場合もあります。

         sel-extension-config = ext-cap-name "=" 1*VCHAR
        

The specific parameters are defined in the individual description of each capability below.

特定のパラメーターは、以下の各機能の個別の説明で定義されています。

The "bcap", "ccap", and "icap" capability attributes can be provided at the SDP session and/or media level. According to the SDP Capability Negotiation [RFC5939], each extension capability must specify the implication of making it part of a configuration at the media level.

「bcap」、「ccap」、および「icap」機能属性は、SDPセッションまたはメディアレベル、あるいはその両方で提供できます。 SDP機能ネゴシエーション[RFC5939]によると、各拡張機能は、それをメディアレベルで構成の一部にすることの意味を指定する必要があります。

According to SDP [RFC4566], "b=", "c=", and "i=" lines may appear at either session or media level. In line with this, the "bcap", "ccap", and "icap" capability attributes, when declared at session level, are to be interpreted as if that attribute was provided with that value at the session level. The "bcap", "ccap", and "icap" capability attributes declared at media level are to be interpreted as if that capability attribute was declared at the media level.

SDP [RFC4566]によると、 "b ="、 "c ="、および "i ="の行は、セッションレベルまたはメディアレベルで表示される可能性があります。これに合わせて、「bcap」、「ccap」、および「icap」機能属性は、セッションレベルで宣言されている場合、その属性にセッションレベルでその値が指定されているかのように解釈されます。メディアレベルで宣言された「bcap」、「ccap」、および「icap」機能属性は、その機能属性がメディアレベルで宣言されたかのように解釈されます。

For example, extending the example in [RFC6871] with "icap" and "bcap" capability attributes, we get the following SDP:

たとえば、[RFC6871]の例を「icap」および「bcap」機能属性で拡張すると、次のSDPが得られます。

         v=0
         o=- 25678 753849 IN IP4 192.0.2.1
         s=
         c=IN IP4 192.0.2.1
         t=0 0
         a=bcap:1 CT:200
         a=icap:1 Video conference
         m=audio 54320 RTP/AVP 0
         a=rmcap:1 L16/8000/1
         a=rmcap:2 L16/16000/2
         a=pcfg:1 m=1|2 pt=1:99,2:98
         m=video 66544 RTP/AVP 100
         a=rmcap:3 H263-1998/90000
         a=rtpmap:100 H264/90000
         a=pcfg:10 m=3 pt=3:101 b=1 i=1
        

Figure 1: Example SDP offer with bcap and icap efined at session level

図1:bcapおよびicapがセッションレベルで定義されたSDPオファーの例

The above SDP defines one PCMU audio stream and one H.264 video stream. It also defines two RTP-based media capabilities ("rmcap" numbered 1 and 2), using 16-bit linear (L16) audio at 8 kbps and 16 kbps, respectively, as well as an RTP-based media capability for H.263 video ("rmcap" numbered 3). The RTP-based media capabilities all appear at the media level. The example also contains a single bandwidth capability ("bcap") and a single title capability ("icap"), both defined at session level. According to the definition above, when the capabilities defined in the "bcap" and "icap" attributes are referenced from the potential configuration, in the resulting SDP they are to be interpreted as session-level attributes (but the RTP-based media capabilities are to be interpreted as media-level attributes).

上記のSDPは、1つのPCMUオーディオストリームと1つのH.264ビデオストリームを定義します。また、それぞれ8 kbpsおよび16 kbpsの16ビットリニア(L16)オーディオを使用する2つのRTPベースのメディア機能(「rmcap」の番号が1および2)と、H.263のRTPベースのメディア機能も定義します。ビデオ(「rmcap」の番号は3)。 RTPベースのメディア機能はすべてメディアレベルで表示されます。この例には、単一の帯域幅機能(「bcap」)と単一のタイトル機能(「icap」)も含まれており、どちらもセッションレベルで定義されています。上記の定義によれば、「bcap」および「icap」属性で定義された機能が潜在的な構成から参照される場合、結果のSDPでは、それらはセッションレベルの属性として解釈されます(ただし、RTPベースのメディア機能はメディアレベルの属性として解釈されます)。

3.1.1. Bandwidth Capability
3.1.1. 帯域幅能力

According to RFC 4566 [RFC4566], the bandwidth field denotes the proposed bandwidth to be used by the session or media. In this memo, we specify the bandwidth capability attribute, which can also appear at the SDP session and/or media level. The bandwidth field is specified in RFC 4566 [RFC4566] with the following syntax:

RFC 4566 [RFC4566]によると、帯域幅フィールドは、セッションまたはメディアによって使用される提案された帯域幅を示します。このメモでは、帯域幅機能属性を指定します。これは、SDPセッションやメディアレベルでも表示できます。帯域幅フィールドは、RFC 4566 [RFC4566]で次の構文で指定されています。

      b=<bwtype>:<bandwidth>
        

where <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure.

ここで、<bwtype>は、<bandwidth>の図の意味を示す英数字修飾子です。

In this document, we define a new capability attribute: the bandwidth capability attribute "bcap". This attribute lists bandwidth as capabilities, according to the following definition:

このドキュメントでは、新しい機能属性である帯域幅機能属性「bcap」を定義します。この属性は、次の定義に従って、帯域幅を機能としてリストします。

      "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
        

where <bw-cap-num> is a unique integer within all the bandwidth capabilities in the entire SDP, which is used to number the bandwidth capability and can take a value between 1 and 2^31-1 (both included). The other elements are as defined for the "b=" field in SDP [RFC4566].

ここで、<bw-cap-num>は、SDP全体のすべての帯域幅機能内の一意の整数であり、帯域幅機能の番号付けに使用され、1〜2 ^ 31-1の値(両方を含む)をとることができます。その他の要素は、SDP [RFC4566]の「b =」フィールドで定義されているとおりです。

This format satisfies the general attribute production rules in SDP [RFC4566], according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:

この形式は、次の拡張バッカスナウアフォーム(ABNF)[RFC5234]構文に従って、SDP [RFC4566]の一般的な属性生成規則を満たします。

         att-field       =/ "bcap"
         att-value       =/ bw-cap-num 1*WSP bwtype ":" bandwidth
         bw-cap-num      = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
        

Figure 2: Syntax of the "bcap" attribute

図2:「bcap」属性の構文

Negotiation of bandwidth per media stream can be useful when negotiating media encoding capabilities with different bandwidths.

メディアストリームごとの帯域幅のネゴシエーションは、異なる帯域幅でメディアエンコーディング機能をネゴシエートするときに役立ちます。

3.1.1.1. Configuration Parameters
3.1.1.1. 構成パラメータ

The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.

SDP機能ネゴシエーションフレームワーク[RFC5939]は、「pcfg」および「acfg」属性の存在を提供します。この概念は、潜在的な構成を伝える「lcfg」属性を備えたSDPメディア機能ネゴシエーション[RFC6871]によって拡張されます。

Extensions to the "pcfg" and "lcfg" attributes are defined through <extension-config-list>, and extensions to the "acfg" attribute are defined through the <sel-extension-config>, as defined in the SDP Capability Negotiation [RFC5939].

「pcfg」および「lcfg」属性への拡張は、<extension-config-list>を通じて定義され、「acfg」属性への拡張は、SDP機能ネゴシエーションで定義されているように、<sel-extension-config>を通じて定義されます。 RFC5939]。

In this document, we extend the <extension-config-list> field to be able to convey lists of bandwidth capabilities in latent or potential configurations, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:

このドキュメントでは、次の拡張バッカスナウアフォーム(ABNF)[RFC5234]構文に従って、<extension-config-list>フィールドを拡張して、潜在構成または潜在構成で帯域幅機能のリストを伝達できるようにします。

     extension-config-list  =/ bandwidth-config-list
     bandwidth-config-list  = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
                                 ; BAR defined in RFC 5939
     bw-cap-list            = bw-cap-num *("," bw-cap-num)
     bw-cap-num             = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
        

Figure 3: Syntax of the bandwidth parameter in "lcfg" and "pcfg" attributes

図3:「lcfg」および「pcfg」属性の帯域幅パラメーターの構文

Each bandwidth capability configuration is a comma-separated list of bandwidth capability attribute numbers where <bw-cap-num> refers to the <bw-cap-num> bandwidth capability numbers defined explicitly earlier in this document, and hence MUST be between 1 and 2^31-1 (both included). Alternative bandwidth configurations are separated by a vertical bar ("|").

各帯域幅機能の構成は、帯域幅機能の属性番号のコンマ区切りのリストです。<bw-cap-num>は、このドキュメントの前半で明示的に定義された<bw-cap-num>帯域幅機能の番号を参照するため、1から2 ^ 31-1(両方含まれます)。代替帯域幅構成は、縦棒( "|")で区切られています。

The above syntax is very flexible, allowing referencing to multiple "b=" lines per configuration, even for the same <bwtype>. While the need for such definitions is not seen, we have not restricted this, as it is not restricted in SDP [RFC4566] either.

上記の構文は非常に柔軟で、同じ<bwtype>であっても、構成ごとに複数の "b ="行を参照できます。そのような定義の必要性は見られませんが、SDP [RFC4566]でも制限されていないため、これを制限していません。

   The bandwidth parameter to the actual configuration attribute
   ("a=acfg") is formulated as a <sel-extension-config> with
        
      ext-cap-name = "b"
        

hence

したがって

sel-extension-config =/ sel-bandwidth-config sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.

sel-extension-config = / sel-bandwidth-config sel-bandwidth-config = "b =" bw-cap-list;上記のbw-cap-list。

Figure 4: Syntax of the bandwidth parameter in "acfg" attributes

図4:「acfg」属性の帯域幅パラメーターの構文

3.1.1.2. Option Tag
3.1.1.2. オプション日

The SDP Capability Negotiation Framework [RFC5939] allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag "bcap-v0" that identifies support for the bandwidth capability. The endpoints using the "bcap" capability attribute SHOULD add the option tag to other existing option tags present in the "csup" and "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].

SDP機能ネゴシエーションフレームワーク[RFC5939]では、機能ネゴシエーション拡張を定義できます。このような各拡張子に関連付けられているのは、問題の拡張子を識別するオプションタグです。これにより、帯域幅機能のサポートを識別する新しいオプションタグ「bcap-v0」を定義します。 「bcap」機能属性を使用するエンドポイントは、SDP機能ネゴシエーションフレームワーク[RFC5939]で定義されている手順に従って、SDPの「csup」および「creq」属性にある他の既存のオプションタグにオプションタグを追加する必要があります。

3.1.2. Connection Data Capability
3.1.2. 接続データ機能

According to SDP [RFC4566], the connection data field in SDP contains the connection data, and it has the following syntax:

SDP [RFC4566]によると、SDPの接続データフィールドには接続データが含まれ、次の構文があります。

      c=<nettype> <addrtype> <connection-address>
        

where <nettype> indicates the network type, <addrtype> indicates the address type, and the <connection-address> is the connection address, which is dependent on the address type.

ここで、<nettype>はネットワークタイプを示し、<addrtype>はアドレスタイプを示します。<connection-address>は、アドレスタイプに依存する接続アドレスです。

At the moment, network types already defined include "IN", which indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), used for describing Asynchronous Transfer Mode (ATM) bearer connections. The Circuit-Switched (CS) descriptions in the SDP document [SDP-CS] adds a "PSTN" network type for expressing a Public Switched Telephone Network (PSTN) circuit switch.

現在、すでに定義されているネットワークタイプには、インターネットネットワークタイプを示す「IN」と、非同期転送モード(ATM)ベアラ接続の記述に使用される「ATM」(RFC 3108 [RFC3108]を参照)があります。 SDPドキュメント[SDP-CS]の回線交換(CS)の説明では、公衆交換電話網(PSTN)回線交換を表す「PSTN」ネットワークタイプが追加されています。

SDP [RFC4566] permits specification of connection data at the SDP session and/or media level. In order to permit negotiation of connection data at the media level, we define the connection data capability attribute ("a=ccap") in the form:

SDP [RFC4566]では、SDPセッションまたはメディアレベル、あるいはその両方で接続データを指定できます。メディアレベルで接続データのネゴシエーションを許可するために、次の形式で接続データ機能属性( "a = ccap")を定義します。

"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection-address CRLF

"a = ccap:" conn-cap-num 1 * WSP nettype SP addrtype SP connection-address CRLF

where <conn-cap-num> is a unique integer within all the connection capabilities in the entire SDP, which is used to identify the connection data capability and can take a value between 1 and 2^31-1 (both included). The other elements are as defined in [RFC4566].

ここで、<conn-cap-num>は、SDP全体のすべての接続機能内の一意の整数であり、接続データ機能を識別するために使用され、1と2 ^ 31-1(どちらも含まれる)の間の値を取ることができます。他の要素は[RFC4566]で定義されているとおりです。

This format corresponds to the [RFC4566] attribute production rules, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:

この形式は、次の拡張バッカスナウアフォーム(ABNF)[RFC5234]構文に従って、[RFC4566]属性生成規則に対応しています。

         att-field       =/ "ccap"
         att-value       =/ conn-cap-num 1*WSP nettype SP addrtype
                           SP connection-address
         conn-cap-num    = 1*10(DIGIT)   ; 1 to 2^31-1, inclusive
                                         ; DIGIT defined in RFC 5234
        

Figure 5: Syntax of the "ccap" attribute

図5:「ccap」属性の構文

The "ccap" capability attribute allows for expressing alternative connections address ("c=") lines in SDP as part of the SDP Capability Negotiation process. One of the primary use cases for this is offering alternative connection addresses where the <nettype> is "IN" or "PSTN", i.e., selecting between an IP-based bearer or a circuit-switched bearer.

「ccap」機能属性を使用すると、SDP機能ネゴシエーションプロセスの一部として、SDPで代替接続アドレス( "c =")行を表現できます。これの主な使用例の1つは、<nettype>が「IN」または「PSTN」である代替接続アドレスを提供することです。つまり、IPベースのベアラまたは回線交換ベアラのどちらかを選択します。

By supporting the "IN" <nettype>, the "ccap" attribute enables the signaling of multiple IPv4 and IPv6 addresses; however, the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The "ccap" attribute does not change that; hence, the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the "ccap" attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IPv4" and "IPv6" address families or different IP addresses within the same IP address family.

「IN」<nettype>をサポートすることにより、「ccap」属性は複数のIPv4およびIPv6アドレスのシグナリングを可能にします。ただし、SDPでの代替IPアドレスのネゴシエーションの標準トラックメカニズムは、Interactive Connectivity Establishment(ICE)[RFC5245]です。 「ccap」属性はそれを変更しません。したがって、特定のメディア記述の実際の構成と潜在的な構成の組み合わせ([RFC5939]で定義)は、「ccap」属性を使用して、INネットワークタイプと複数のアドレスをネゴシエートしてはなりません(つまり、 「IPv4」と「IPv6」のアドレスファミリ、または同じIPアドレスファミリ内の異なるIPアドレスから選択します。

Figure 6 is an example of an SDP offer that includes a "ccap" capability attribute. An audio stream can be set up with an RTP flow or by establishing a circuit-switched audio stream:

図6は、「ccap」機能属性を含むSDPオファーの例です。オーディオストリームは、RTPフローを使用して、または回線交換オーディオストリームを確立することによって設定できます。

             v=0
             o=2987933123 2987933123 IN IP4 198.51.100.7
             s=-
             t=0 0
             a=creq:med-v0,ccap-v0
             m=audio 38902 RTP/AVP 0 8
             c=IN IP4 198.51.100.7
             a=ccap:1 PSTN E164 +15555556666
             a=tcap:2 PSTN
             a=omcap:1 -
             a=acap:1 setup:actpass
             a=acap:2 connection:new
             a=acap:3 cs-correlation:callerid:+15555556666
             a=pcfg:1 c=1 t=2 m=1 a=1,2,3
        

Figure 6: Example SDP offer with a "ccap" attribute

図6:「ccap」属性を持つSDPオファーの例

The example in Figure 6 represents an SDP offer indicating an audio flow using RTP, such as the one represented in Figure 7, or an audio flow using a circuit-switched connection, such as the one represented in Figure 8.

図6の例は、図7に示されているようなRTPを使用したオーディオフロー、または図8に示されているような回線交換接続を使用したオーディオフローを示すSDPオファーを表しています。

v=0 o=2987933123 2987933123 IN IP4 198.51.100.7 s=- t=0 0 m=audio 38902 RTP/AVP 0 8 c=IN IP4 198.51.100.7

v = 0 o = 2987933123 2987933123 IN IP4 198.51.100.7 s =-t = 0 0 m = audio 38902 RTP / AVP 0 8 c = IN IP4 198.51.100.7

Figure 7: Equivalent SDP offer with the RTP flow

図7:RTPフローでの同等のSDPオファー

             v=0
             o=2987933123 2987933123 IN IP4 198.51.100.7
             s=-
             t=0 0
             m=audio 9 PSTN -
             c=PSTN E164 +15555556666
             a=setup:actpass
             a=connection:new
             a=cs-correlation:callerid:+15555556666
        

Figure 8: Equivalent SDP offer with the circuit-switched flow

図8:回線交換フローでの同等のSDPオファー

This document does not define any mechanism for negotiating or describing different port numbers; hence, the port number from the "m=" line MUST be used by default. Exceptions to this default can be provided by extension mechanisms or network type specific rules. This document defines an exception when the network type is "PSTN", in which case the port number is replaced with 9 (the "discard" port), as described in "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS]. An endpoint offering alternative IP and PSTN bearers MUST include the IP media description in the actual configuration (IP address in the "c=" line and port number in the "m=" line) and the PSTN media description in the potential configuration.

このドキュメントでは、さまざまなポート番号をネゴシエートまたは説明するメカニズムを定義していません。したがって、「m =」行のポート番号をデフォルトで使用する必要があります。このデフォルトの例外は、拡張メカニズムまたはネットワークタイプ固有のルールによって提供できます。このドキュメントでは、ネットワークタイプが「PSTN」の場合の例外を定義します。この場合、「オーディオおよびビデオメディアストリームを設定するためのセッション記述プロトコル(SDP)拡張機能」で説明されているように、ポート番号は9(「破棄」ポート)に置き換えられます。公衆交換電話網(PSTN)の回線交換ベアラ経由」[SDP-CS]。代替IPおよびPSTNベアラーを提供するエンドポイントは、実際の構成にIPメディアの説明(「c =」行にIPアドレス、「m =」行にポート番号)および潜在的な構成にPSTNメディア説明を含める必要があります。

Exceptions for other network types, such as for the "ATM" network type defined in [RFC3108], require additional specifications.

[RFC3108]で定義されている「ATM」ネットワークタイプなどの他のネットワークタイプの例外には、追加の仕様が必要です。

3.1.2.1. Configuration Parameters
3.1.2.1. 構成パラメータ

The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes, which can convey one or more configurations to be negotiated. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.

SDP機能ネゴシエーションフレームワーク[RFC5939]は、「pcfg」および「acfg」属性の存在を提供します。これらの属性は、ネゴシエートされる1つ以上の構成を伝えることができます。この概念は、潜在的な構成を伝える「lcfg」属性を備えたSDPメディア機能ネゴシエーション[RFC6871]によって拡張されます。

In this document, we define a <connection-config> parameter to be used to specify a connection data capability in a potential or latent configuration attribute. The parameter follows the form of an <extension-config-list> with

このドキュメントでは、潜在的または潜在的な構成属性で接続データ機能を指定するために使用される<connection-config>パラメータを定義します。パラメータは、<extension-config-list>の形式に従います。

      ext-cap-name = "c"
        
      ext-cap-list = conn-cap-list
        

where, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:

ここで、次の拡張バッカスナウアフォーム(ABNF)[RFC5234]構文によると、

         extension-config-list =/ conn-config-list
         conn-config-list      = ["+"] "c=" conn-cap-list
         conn-cap-list         = conn-cap-num *(BAR conn-cap-num)
         conn-cap-num          = 1*10(DIGIT)   ; 1 to 2^32-1 inclusive
        

Figure 9: Syntax of the connection data parameter in "lcfg" and "pcfg" attributes

図9:「lcfg」および「pcfg」属性の接続データパラメータの構文

Each capability configuration alternative contains a single connection data capability attribute number and refers to the conn-cap-num capability number defined explicitly earlier in this document; hence, the values MUST be between 1 and 2^31-1 (both included). The connection data capability allows the expression of only a single capability in each alternative, rather than a list of capabilities, since no more than a single connection data field is permitted per media block. Nevertheless, it is still allowed to express alternative potential connection configurations separated by a vertical bar ("|").

各機能構成の代替には、単一の接続データ機能属性番号が含まれ、このドキュメントの前半で明示的に定義されたconn-cap-num機能番号を参照します。したがって、値は1と2 ^ 31-1の間にある必要があります(両方が含まれます)。メディアブロックごとに許可される接続データフィールドは1つだけなので、接続データ機能では、機能のリストではなく、各代替手段で1つの機能のみを表現できます。それでも、縦棒( "|")で区切られた代替の接続構成を表すことができます。

An endpoint includes a plus sign ("+") in the configuration attribute to mandate support for this extension. An endpoint that receives this parameter prefixed with a plus sign and does not support this extension MUST treat that potential configuration as not valid.

エンドポイントの構成属性には、この拡張機能のサポートを必須とするプラス記号( "+")が含まれています。プラス記号が前に付いたこのパラメーターを受け取り、この拡張機能をサポートしないエンドポイントは、その潜在的な構成を無効として扱う必要があります。

   The connection data parameter to the actual configuration attribute
   ("a=acfg") is formulated as a <sel-extension-config> with
        
      ext-cap-name = "c"
        

hence

したがって

sel-extension-config =/ sel-connection-config sel-connection-config = "c=" conn-cap-num ; as defined above.

sel-extension-config = / sel-connection-config sel-connection-config = "c =" conn-cap-num;上記で定義したとおり。

Figure 10: Syntax of the connection data parameter in "acfg" attributes

図10:「acfg」属性の接続データパラメータの構文

3.1.2.2. Option Tag
3.1.2.2. オプション日

The SDP Capability Negotiation Framework [RFC5939] solution allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag of "ccap-v0" that identifies support for the connection data capability. This option tag SHOULD be added to other existing option tags present in the "csup" and "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].

SDP機能ネゴシエーションフレームワーク[RFC5939]ソリューションでは、機能ネゴシエーションの拡張を定義できます。このような各拡張子に関連付けられているのは、問題の拡張子を識別するオプションタグです。これにより、接続データ機能のサポートを識別する「ccap-v0」の新しいオプションタグを定義します。このオプションタグは、SDP機能ネゴシエーションフレームワーク[RFC5939]で定義されている手順に従って、SDPの "csup"および "creq"属性に存在する他の既存のオプションタグに追加する必要があります(SHOULD)。

3.1.3. Title Capability
3.1.3. タイトル機能

SDP [RFC4566] provides for the existence of an information field expressed in the format of the "i=" line, which can appear at the SDP session and/or media level. An "i=" line that is present at the session level is known as the "session name", and its purpose is to convey human-readable textual information about the session.

SDP [RFC4566]は、「i =」行の形式で表現された情報フィールドの存在を提供します。これは、SDPセッションおよび/またはメディアレベルで表示できます。セッションレベルに存在する「i =」行は「セッション名」と呼ばれ、その目的は、セッションに関する人間が読めるテキスト情報を伝えることです。

The "i=" line in SDP can also appear at the media level, in which case it is used to provide human-readable information about the media stream to which it is related; for example, it may indicate the purpose of the media stream. The "i=" line is not to be confused with the label attribute ("a=label:", [RFC4574]), which provides a machine-readable tag. It is foreseen that applications declaring capabilities related to different configurations of a media stream may need to provide different identifying information for each of those configurations. That is, a party might offer alternative media configurations for a stream, each of which represents a different presentation of the same or similar information. For example, an audio stream might offer English or Spanish configurations, or a video stream might offer a choice of video source such as speaker camera, group camera, or document viewer. The title capability is needed to inform the answering user in order to select the proper choice, and the label is used to inform the offering machine which choice the answerer has selected. Hence, there is value in defining a mechanism to provide titles of media streams as capabilities.

SDPの「i =」行は、メディアレベルでも表示できます。その場合、この行は、関連するメディアストリームに関する人間が読める情報を提供するために使用されます。たとえば、メディアストリームの目的を示す場合があります。 "i ="行は、機械可読タグを提供するlabel属性( "a = label:"、[RFC4574])と混同しないでください。メディアストリームのさまざまな構成に関連する機能を宣言するアプリケーションは、それらの構成ごとに異なる識別情報を提供する必要がある場合があることが予想されます。つまり、パーティは、ストリームの代替メディア構成を提供する場合があり、それぞれが同じまたは類似の情報の異なるプレゼンテーションを表します。たとえば、オーディオストリームは英語またはスペイン語の構成を提供し、ビデオストリームはスピーカーカメラ、グループカメラ、ドキュメントビューアなどのビデオソースの選択肢を提供します。タイトル機能は、適切な選択肢を選択するために応答ユーザーに通知するために必要であり、ラベルは、回答者が選択した選択肢を提供マシンに通知するために使用されます。したがって、メディアストリームのタイトルを機能として提供するメカニズムを定義することには価値があります。

As defined in SDP [RFC4566], the session information field ("i=", referred to as "title" in this document) is subject to the "a=charset" attribute in order to support different character sets and hence internationalization. The title capability attribute itself ("a=icap") is, however, not subject to the "a=charset" attribute as this would preclude the inclusion of alternative session/title information each using different character sets. Instead, the session/title value embedded in an "a=icap" attribute (title capability) will be subject to the "a=charset" value used within a configuration that includes that title capability. This provides for consistent SDP operation while allowing for capabilities and configurations with different session/title information values with different character set encodings (with each such configuration including an "a=charset" value with the relevant character set for the session/title information in question).

SDP [RFC4566]で定義されているように、セッション情報フィールド(このドキュメントでは「i =」、「タイトル」と呼ばれます)は、異なる文字セットをサポートするために「a = charset」属性の影響を受けるため、国際化に対応しています。ただし、タイトル機能属性自体(「a = icap」)は、「a = charset」属性の影響を受けません。これは、それぞれ異なる文字セットを使用する代替セッション/タイトル情報を含めることができないためです。代わりに、「a = icap」属性(タイトル機能)に埋め込まれたセッション/タイトル値は、そのタイトル機能を含む構成内で使用される「a = charset」値の影響を受けます。これにより、一貫したSDP操作が可能になると同時に、異なる文字セットエンコーディングで異なるセッション/タイトル情報値を持つ機能と構成が可能になります(各構成には、問題のセッション/タイトル情報に関連する文字セットを持つ「a = charset」値が含まれます) )。

According to SDP [RFC4566], the session information ("i=") line has the following syntax:

SDP [RFC4566]によると、セッション情報( "i =")行の構文は次のとおりです。

"i=" text

「i =」テキスト

where "text" represents a human-readable text indicating the purpose of the session or media stream.

ここで、「テキスト」は、セッションまたはメディアストリームの目的を示す、人間が読めるテキストを表します。

In this document, we define a new capability attribute: the title capability "icap". This attribute lists session or media titles as capabilities, according to the following definition:

このドキュメントでは、新しい機能属性であるタイトル機能「icap」を定義します。この属性は、次の定義に従って、セッションまたはメディアのタイトルを機能としてリストします。

      "a=icap:" title-cap-num 1*WSP text
        

where <title-cap-num> is a unique integer within all the connection capabilities in the entire SDP, which is used to identify the particular title capability and can take a value between 1 and 2^31-1 (both included). <text> is a human-readable text that indicates the purpose of the session or media stream it is supposed to characterize.

ここで、<title-cap-num>は、SDP全体のすべての接続機能内の一意の整数であり、特定のタイトル機能を識別するために使用され、1〜2 ^ 31-1の値(両方を含む)をとることができます。 <text>は、人間が読めるテキストであり、特徴となるセッションまたはメディアストリームの目的を示します。

As an example, one might use:

例として、次のものを使用できます。

a=icap:1 Document Camera

a = icap:1書画カメラ

to define a title capability number 1 to identify a particular source of a media stream.

タイトル機能番号1を定義して、メディアストリームの特定のソースを識別します。

Or, in another example, one might offer two title capabilities with different character encodings (using the charset attribute defined in "SDP: Session Description Protocol" [RFC4566] and the generic attribute capability attribute ("a=acap:") defined in "Session Description Protocol (SDP) Capability Negotiation" [RFC5939]).

または、別の例では、異なる文字エンコーディングの2つのタイトル機能を提供する場合があります(「SDP:セッション記述プロトコル」[RFC4566]で定義された文字セット属性と「」で定義された汎用属性機能属性( "a = acap:")を使用) Session Description Protocol(SDP)Capability Negotiation "[RFC5939])。

               a=icap:1 [Text encoded in ISO-8859-1]
               a=acap:1 charset:ISO-8859-1
               a=icap:2 [Text encoded in UTF-8]
               a=acap:2 charset:UTF-8
        

NOTE: Due to limitations of the ASCII encoding of RFCs, the actual text with non-printable characters cannot be represented in the text. See the PDF format of this RFC for a figure with non-printable characters.

注:RFCのASCIIエンコードの制限により、印刷不可能な文字を含む実際のテキストはテキストで表すことができません。印刷できない文字を含む図については、このRFCのPDF形式を参照してください。

The title capability attribute satisfies the general attribute production rules in SDP [RFC4566], according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:

タイトル機能属性は、次の拡張バッカスナウアフォーム(ABNF)[RFC5234]構文に従って、SDP [RFC4566]の一般的な属性生成規則を満たします。

         att-field       =/ "icap"
         att-value       =/ title-cap-num 1*WSP text
                                     ; text defined in RFC 4566
         title-cap-num   = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
        

Figure 11: Syntax of the "icap" attribute

図11:「icap」属性の構文

3.1.3.1. Configuration Parameters
3.1.3.1. 構成パラメータ

The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.

SDP機能ネゴシエーションフレームワーク[RFC5939]は、「pcfg」および「acfg」属性の存在を提供します。この概念は、潜在的な構成を伝える「lcfg」属性を備えたSDPメディア機能ネゴシエーション[RFC6871]によって拡張されます。

In this document, we define a <title-config-list> parameter to be used to convey title capabilities in a potential or latent configuration. This parameter is defined as an <extension-config-list> with the following associations:

このドキュメントでは、潜在的な構成または潜在的な構成でタイトル機能を伝達するために使用される<title-config-list>パラメータを定義します。このパラメーターは、次の関連付けを持つ<extension-config-list>として定義されます。

      ext-cap-name = "i"
        
      ext-cap-list = title-cap-list
        

This leads to the following definition for the title capability parameter:

これにより、title機能パラメーターが次のように定義されます。

         extension-config-list =/ title-config-list
         title-config-list     = ["+"] "i=" title-cap-list
         title-cap-list        = title-cap-num *(BAR title-cap-num)
                                         ; BAR defined in RFC 5939
         title-cap-num         = 1*10(DIGIT) ; DIGIT defined in RFC 5234
        

Figure 12: Syntax of the title capability parameter in "lcfg" and "pcfg" attributes

図12:「lcfg」および「pcfg」属性のタイトル機能パラメーターの構文

Each potential capability configuration contains a single title capability attribute number where "title-cap-num" is the title capability number defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). The title capability allows the expression of only a single capability in each alternative, since no more than a single-title field is permitted per block. Nevertheless, it is still allowed to express alternative potential title configurations separated by a vertical bar ("|").

各潜在的な機能構成には、1つのタイトル機能属性番号が含まれます。「title-cap-num」は、このドキュメントの前半で明示的に定義されたタイトル機能番号であるため、1と2 ^ 31-1(両方を含む)の間でなければなりません。タイトル機能では、ブロックごとに1つのタイトルフィールドしか許可されないため、代替案では1つの機能のみを表現できます。それでも、縦棒( "|")で区切られた代替のタイトル構成を表すことは引き続き許可されます。

An endpoint includes a plus sign ("+") in the configuration attribute to mandate support for this extension. An endpoint that receives this parameter prefixed with a plus sign and does not support this extension MUST treat that potential configuration as not valid.

エンドポイントの構成属性には、この拡張機能のサポートを必須とするプラス記号( "+")が含まれています。プラス記号が前に付いたこのパラメーターを受け取り、この拡張機能をサポートしないエンドポイントは、その潜在的な構成を無効として扱う必要があります。

The title parameter to the actual configuration attribute ("a=acfg") is formulated as a <sel-extension-config> with

実際の構成属性( "a = acfg")のタイトルパラメータは、<sel-extension-config>として次のように作成されます。

      ext-cap-name = "i"
        

hence

したがって

sel-extension-config =/ sel-title-config sel-title-config = "i=" title-cap-num ; as defined above.

sel-extension-config = / sel-title-config sel-title-config = "i =" title-cap-num;上記で定義したとおり。

Figure 13: Syntax of the title parameter in "acfg" attributes

図13:「acfg」属性のタイトルパラメータの構文

3.1.3.2. Option Tag
3.1.3.2. オプション日

At present, it is difficult to envision a scenario in which the "icap" attribute must be supported or the offer must be rejected. In most cases, if the icap attribute or its contents were to be ignored, an offered configuration could still be chosen based on other criteria such as configuration numbering. However, one might imagine an SDP offer that contained English and Spanish potential configurations for an audio stream. The session might be unintelligible if the choice is based on configuration numbering, rather than informed user selection. Based on such considerations, it may well prove useful to announce the ability to use the icap attribute and its contents to select media configurations, or to inform the user about the selected configuration(s). Therefore, we define a new option tag of "icap-v0" that identifies support for the title capability. This option tag SHOULD be added to other existing option tags present in the "csup" and/or "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939]. The discussion above suggests that "icap-v0" will typically appear in a "csup" attribute, but rarely in a "creq" attribute.

現時点では、「icap」属性をサポートする必要がある、またはオファーを拒否する必要があるシナリオを想定することは困難です。ほとんどの場合、icap属性またはその内容が無視される場合でも、構成番号などの他の基準に基づいて、提供される構成を選択できます。ただし、オーディオストリームの英語とスペイン語の潜在的な構成を含むSDPオファーを想像するかもしれません。選択が通知されたユーザーの選択ではなく、構成の番号付けに基づいている場合、セッションは理解できない場合があります。そのような考慮事項に基づいて、メディア構成を選択するためにicap属性とその内容を使用する機能を発表するか、または選択した構成についてユーザーに通知することは有用であるとよく証明するかもしれません。したがって、タイトル機能のサポートを識別する「icap-v0」の新しいオプションタグを定義します。このオプションタグは、SDP機能ネゴシエーションフレームワーク[RFC5939]で定義されている手順に従って、SDPの「csup」または「creq」属性に存在する他の既存のオプションタグに追加する必要があります(SHOULD)。上記の説明では、「icap-v0」は通常「csup」属性に表示されますが、「creq」属性にはほとんど表示されないことを示唆しています。

3.2. Session Level versus Media Level
3.2. セッションレベルとメディアレベル

The "bcap", "ccap", and "icap" attributes can appear at the SDP session and/or media level. Endpoints MUST interpret capabilities declared at session level as part of the session level in the resulting SDP for that particular configuration. Endpoints MUST interpret capabilities declared at media description as part of the media level in the resulting SDP for that particular configuration.

「bcap」、「ccap」、および「icap」属性は、SDPセッションおよび/またはメディアレベルで表示できます。エンドポイントは、セッションレベルで宣言された機能を、その特定の構成の結果のSDPのセッションレベルの一部として解釈する必要があります。エンドポイントは、メディア記述で宣言された機能を、その特定の構成の結果のSDPのメディアレベルの一部として解釈する必要があります。

The presence of the "bcap" capability for the same <bwtype> at both the session and media level is subject to the same constraints and restrictions specified in RFC 4566 [RFC4566] for the bandwidth attribute "b=".

セッションレベルとメディアレベルの両方で同じ<bwtype>の「bcap」機能が存在する場合は、帯域幅属性「b =」のRFC 4566 [RFC4566]で指定されているのと同じ制約と制限が適用されます。

To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap", and "a=icap" line MUST be unique across all capability attributes of the same type within the entire session description.

混乱を避けるために、「a = bcap」、「a = ccap」、および「a = icap」の各行の<type-attr-num>は、セッションの説明全体で同じタイプのすべての機能属性にわたって一意である必要があります。

3.3. Offer/Answer Model Extensions
3.3. オファー/アンサーモデル拡張

In this section, we define extensions to the offer/answer model defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP Capability Negotiation [RFC5939] to allow for bandwidth, connection, and title capabilities to be used with the SDP Capability Negotiation Framework.

このセクションでは、SDPオファー/アンサーモデル[RFC3264]で定義され、SDP機能ネゴシエーション[RFC5939]で拡張されたオファー/アンサーモデルの拡張を定義して、帯域幅、接続、およびタイトル機能をSDP機能で使用できるようにします。交渉フレームワーク。

3.3.1. Generating the Initial Offer
3.3.1. 最初のオファーの生成

When an endpoint generates an initial offer and wants to use the functionality described in the current document, it first defines appropriate values for the bandwidth, connection data, and/or title capability attributes according to the rules defined in [RFC4566] for "b=", "c=", and "i=" lines. The endpoint then MUST include the respective capability attributes and associated values in the SDP offer. The preferred configurations for each media stream are identified following the media line in a "pcfg" attribute. Bandwidth and title capabilities may also be referenced in latent configurations in an "lcfg" attribute, as defined in the SDP Media Capabilities Negotiation [RFC6871].

エンドポイントが初期オファーを生成し、現在のドキュメントで説明されている機能を使用する場合、最初に、[RFC4566]で定義されている「b = "、" c = "、および" i = "行。その後、エンドポイントは、SDPオファーにそれぞれの機能属性と関連する値を含める必要があります。各メディアストリームの推奨構成は、「pcfg」属性のメディア行に従って識別されます。帯域幅およびタイトル機能は、SDPメディア機能ネゴシエーション[RFC6871]で定義されているように、「lcfg」属性の潜在構成で参照することもできます。

Implementations are advised to pay attention to the port number that is used in the "m=" line. By default, a potential configuration that includes a connection data capability will use the port number from the "m=" line, unless the network type is "PSTN", in which case the default port number used will be 9.

実装では、「m =」行で使用されているポート番号に注意することをお勧めします。デフォルトでは、接続データ機能を含む可能性のある構成は、ネットワークタイプが「PSTN」である場合を除き、「m =」行のポート番号を使用します。この場合、使用されるデフォルトのポート番号は9になります。

The offer SHOULD include the level of capability negotiation extensions needed to support this functionality in a "creq" attribute.

オファーには、この機能をサポートするために必要な機能ネゴシエーション拡張のレベルを「creq」属性に含める必要があります(SHOULD)。

3.3.2. Generating the Answer
3.3.2. 答えを生成する

When the answering party receives the offer, and if it supports the required capability negotiation extensions, it SHOULD select the most preferred configuration it can support for each media stream and build the answer accordingly, as defined in Section 3.6.2 of the SDP Capability Negotiation [RFC5939].

応答側がオファーを受信すると、必要な機能ネゴシエーション拡張をサポートしている場合、SDP機能ネゴシエーションのセクション3.6.2で定義されているように、各メディアストリームに対してサポートできる最も好ましい構成を選択し、それに応じて応答を構築する必要があります(SHOULD)。 [RFC5939]。

If the connection data capability is used in a selected potential configuration chosen by the answerer, that offer configuration MUST by default use the port number from the actual offer configuration (i.e., the "m=" line), unless the network type is "PSTN", in which case the default port MUST be assumed to be 9. Extensions may be defined to negotiate the port number explicitly instead.

接続データ機能が、回答者によって選択された選択可能な構成で使用される場合、ネットワークタイプが「PSTN」でない限り、そのオファー構成はデフォルトで実際のオファー構成(つまり、「m =」行)のポート番号を使用する必要があります。 「この場合、デフォルトポートは9であると想定する必要があります。代わりに、ポート番号を明示的にネゴシエートするように拡張機能を定義できます。

3.3.3. Offerer Processing of the Answer
3.3.3. 回答者の処理

When the offerer receives the answer, it MUST process the media lines according to normal SDP processing rules to identify the media stream(s) accepted by the answer, if any, as defined in Section 3.6.3 of the SDP Capability Negotiation [RFC5939]. The "acfg" attribute, if present, MUST be used to verify the proposed configuration used to form the answer and to infer the lack of acceptability of higher-preference configurations that were not chosen.

オファーを受け取った場合、オファーは通常のSDP処理ルールに従ってメディアラインを処理して、SDP機能のネゴシエーション[RFC5939]のセクション3.6.3で定義されているように、回答によって受け入れられたメディアストリームを特定する必要があります。 。 「acfg」属性が存在する場合は、回答の形成に使用される提案された構成を検証し、選択されなかったより優先度の高い構成が受け入れられないことを推測するために使用する必要があります。

3.3.4. Modifying the Session
3.3.4. セッションの変更

If, at a later time, one of the parties wishes to modify the operating parameters of a session, e.g., by adding a new media stream or by changing the properties used on an existing stream, it may do so via the mechanisms defined for SDP offer/answer [RFC3264] and in accordance with the procedures defined in Section 3.6.4 of the SDP Capability Negotiation [RFC5939].

後で、パーティの1つがセッションの動作パラメータを変更する場合、たとえば、新しいメディアストリームを追加したり、既存のストリームで使用されているプロパティを変更したりする場合、SDPに定義されたメカニズムを介して行うことができます。オファー/アンサー[RFC3264]およびSDP機能ネゴシエーション[RFC5939]のセクション3.6.4で定義された手順に従って。

4. Field Replacement Rules
4. フィールド交換ルール

To simplify the construction of SDP records, given the need to include fields within the media description in question for endpoints that do not support capabilities negotiation, we define some simple field-replacement rules for those fields invoked by potential or latent configurations. In particular, any "i=" or "c=" lines invoked by a configuration MUST replace the corresponding line, if present within the media description in question. Any "b=" line invoked by a configuration MUST replace any "b=" of the same bandwidth type at the media level, but not at the session level.

SDPレコードの構築を簡略化するために、機能のネゴシエーションをサポートしないエンドポイントの問題のメディア記述内にフィールドを含める必要がある場合、潜在的な構成または潜在的な構成によって呼び出されるこれらのフィールドの簡単なフィールド置換ルールを定義します。特に、構成によって呼び出される「i =」または「c =」行は、問題のメディア記述内に存在する場合、対応する行を置き換える必要があります。構成によって呼び出される「b =」行は、メディアレベルで同じ帯域幅タイプの「b =」を置き換える必要がありますが、セッションレベルでは置き換えません。

5. Security Considerations
5. セキュリティに関する考慮事項

This document provides an extension on top of the SDP [RFC4566], SDP Offer/Answer Model [RFC3264], SDP Capability Negotiation Framework [RFC5939], and SDP Media Capabilities Negotiation [RFC6871]. As such, the security considerations of those documents apply.

このドキュメントは、SDP [RFC4566]、SDPオファー/アンサーモデル[RFC3264]、SDP機能ネゴシエーションフレームワーク[RFC5939]、およびSDPメディア機能ネゴシエーション[RFC6871]に加えて拡張機能を提供します。そのため、これらのドキュメントのセキュリティに関する考慮事項が適用されます。

The bandwidth capability attribute may be used for reserving resources at endpoints and intermediaries that inspect SDP. Modification of the bandwidth value by an attacker can lead to the network being underutilized (too high bandwidth value) or congested (too low bandwidth value).

帯域幅機能属性は、SDPを検査するエンドポイントおよび仲介者でリソースを予約するために使用できます。攻撃者が帯域幅の値を変更すると、ネットワークが十分に活用されない(帯域幅の値が高すぎる)か、輻輳する(帯域幅の値が低すぎる)可能性があります。

Similarly, by modifying the alternative connection address(es), an attacker would be able to direct media streams to a desired endpoint, thus launching a version of the well-known voice hammer attack (see Section 18.5.1 of [RFC5245]).

同様に、代替の接続アドレスを変更することにより、攻撃者はメディアストリームを目的のエンドポイントに転送できるため、既知のボイスハンマー攻撃のバージョンを起動できます([RFC5245]のセクション18.5.1を参照)。

The title capability provides for alternative "i=" line information, which is intended for human consumption. However, manipulating the textual information could be misused to provide false information, leading to a bad user experience or the person using the service making a wrong choice regarding the available media streams.

タイトル機能は、人間による消費を目的とした代替の「i =」行情報を提供します。ただし、テキスト情報の操作が誤用されて誤った情報が提供され、ユーザーエクスペリエンスが低下したり、利用可能なメディアストリームに関してサービスを誤って選択したりする可能性があります。

In case it is essential to protect the capability attribute values, one of the security mechanisms proposed in [RFC5939] SHOULD be used.

能力属性値を保護することが不可欠である場合、[RFC5939]で提案されているセキュリティメカニズムの1つを使用する必要があります(SHOULD)。

The "i=" line, and thus the value carried in the title capability attribute, is intended for human-readable description only. It should not be parsed programmatically.

「i =」行、つまりtitle機能属性に含まれる値は、人間が読める説明のみを目的としています。プログラムで解析しないでください。

6. IANA Considerations
6. IANAに関する考慮事項
6.1. New SDP Attributes
6.1. 新しいSDP属性

IANA has registered new attributes in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following registration form:

IANAは、次の登録フォームに従って、「Session Description Protocol(SDP)Parameters」レジストリの「att-field(セッションとメディアレベルの両方)」サブレジストリに新しい属性を登録しました。

Attribute name: bcap Long form name: Bandwidth Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate session or media-level bandwidths Appropriate values: See RFC 7066, Section 3.1.1 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com

属性名:bcap長い形式の名前:帯域幅機能属性のタイプ:メディアとセッションレベルの両方文字セットの対象:いいえ目的:セッションまたはメディアレベルの帯域幅のネゴシエート適切な値:RFC 7066のセクション3.1.1の連絡先名:ミゲルA Garcia Miguel.A.Garcia@ericsson.com

Attribute name: ccap Long form name: Connection Data Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate media-level connection data Appropriate values: See RFC 7066, Section 3.1.2 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com

属性名:ccap長い形式の名前:接続データ機能属性のタイプ:メディアとセッションレベルの両方文字セットの対象:いいえ目的:メディアレベルの接続データのネゴシエート適切な値:RFC 7066のセクション3.1.2の連絡先名:ミゲルA Garcia Miguel.A.Garcia@ericsson.com

Attribute name: icap Long form name: Title Capability Type of attribute: Both media and session level Subject to charset: Yes Purpose: Negotiate human-readable information describing the session or media Appropriate values: See RFC 7066, Section 3.1.3 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com

属性名:icap長い形式の名前:タイトル機能属性のタイプ:メディアとセッションレベルの両方文字セットの対象:はい目的:セッションまたはメディアを説明する人間が読み取れる情報をネゴシエートします適切な値:RFC 7066のセクション3.1.3の連絡先名を参照してください:ミゲルA.ガルシアMiguel.A.Garcia@ericsson.com

6.2. New Option Tags
6.2. 新しいオプションタグ

IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability Negotiation Option Tag" subregistry of the "Session Description Protocol (SDP) Parameters" registry.

IANAは、ここに定義されている新しいオプションタグ「bcap-v0」、「ccap-v0」、および「icap-v0」を「セッション記述プロトコル(SDP)パラメータ」の「SDP機能ネゴシエーションオプションタグ」サブレジストリに追加しました。レジストリ。

6.3. New SDP Capability Negotiation Configuration Parameters
6.3. 新しいSDP機能ネゴシエーション構成パラメーター

IANA has added the new parameter identifiers "b" for "Bandwidth", "c" for "Connection Data", and "i" for "Title" to the "SDP Capability Negotiation Configuration Parameters" subregistry of the "Session Description Protocol (SDP) Parameters" registry. These parameters are permitted in "lcfg", "acfg", and "pcfg" attributes.

IANAは、「セッション記述プロトコル(SDP)の「SDP機能ネゴシエーション構成パラメーター」サブレジストリに、「帯域幅」の「b」、「接続データ」の「c」、および「タイトル」の「i」という新しいパラメーター識別子を追加しました。 )パラメータ」レジストリ。これらのパラメーターは、「lcfg」、「acfg」、および「pcfg」属性で許可されています。

7. Acknowledgments
7. 謝辞

Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson for arguing for the existence of this document and reviewing it in the early stages. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox for a detailed review and many suggestions for improvement.

このドキュメントの存在を主張し、初期の段階でレビューしてくれたChrister Holmberg、Alf Heidermark、およびIngemar Johanssonに感謝します。詳細なレビューと改善のための多くの提案をしてくれたFlemming Andreasen、Andrew Allen、Jonathan Lennoxに感謝します。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[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:Session Description Protocol」、RFC 4566、2006年7月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、2008年1月。

[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.

[RFC5939] Andreasen、F。、「Session Description Protocol(SDP)Capability Negotiation」、RFC 5939、2010年9月。

[RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session Description Protocol (SDP) Media Capabilities Negotiation", RFC 6871, February 2013.

[RFC6871] Gilman、R.、Even、R。、およびF. Andreasen、「Session Description Protocol(SDP)Media Capabilities Negotiation」、RFC 6871、2013年2月。

8.2. Informative References
8.2. 参考引用

[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.

[RFC3108] Kumar、R。お​​よびM. Mostafa、「ATMベアラ接続用のセッション記述プロトコル(SDP)の使用に関する規約」、RFC 3108、2001年5月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP:A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、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]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol(SRTP)」、RFC 3711、2004年3月。

[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.

[RFC4574] Levin、O。およびG. Camarillo、「セッション記述プロトコル(SDP)ラベル属性」、RFC 4574、2006年8月。

[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 Establishment(ICE):A Protocol for Network Address Translator(NAT)Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。

[SDP-CS] Garcia, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", Work in Progress, June 2013.

[SDP-CS] Garcia、M。、およびS. Veikkolainen、「公衆交換電話網(PSTN)の回線交換ベアラを介してオーディオおよびビデオメディアストリームを設定するためのセッション記述プロトコル(SDP)拡張機能」、6月に進行中の作業2013。

Authors' Addresses

著者のアドレス

Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid 28033 Spain

Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13マドリード28033スペイン

   Phone: +34 91 339 1000
   EMail: miguel.a.garcia@ericsson.com
        

Simo Veikkolainen Nokia P.O. Box 226 NOKIA GROUP, FI 00045 Finland

Simo Veikkolainen Nokia P.O.ボックス226 NOKIA GROUP、FI 00045フィンランド

   Phone: +358 50 486 4463
   EMail: simo.veikkolainen@nokia.com
        

Robert R. Gilman 3243 W. 11th Ave. Dr. Broomfield, Colorado 80020 U.S.A.

Robert R. Gilman 3243 W. 11th Ave. Dr. Broomfield、Colorado 80020 U.S.A.

   Phone: +1 303 898 9780
   EMail: bob_gilman@comcast.net