[要約] RFC 8848は、CLUE（Telepresenceのための複数ストリーム制御のためのセッションシグナリング）に関する標準化されたセッション制御プロトコルです。このRFCの目的は、複数のメディアストリームを制御するためのセッションシグナリングの仕組みを提供し、Telepresence環境での効率的な通信を可能にすることです。
Internet Engineering Task Force (IETF) R. Hanton
Request for Comments: 8848 Cisco Systems
Category: Experimental P. Kyzivat
ISSN: 2070-1721
L. Xiao
Beijing Chuangshiyoulian
C. Groves
January 2021
Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
TelePresence（CLUE）の複数のストリームを制御するためのセッションシグナリング
Abstract
概要
This document is about Controlling Multiple Streams for Telepresence (CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the Session Description Protocol (SDP), to produce a telepresence call.
この文書は、TelePresence（Clue）シグナリングのための複数のストリームを制御することです。それは、CLUEプロトコルと手がかりデータチャネルが互いにどのように使用され、SIPやセッション記述プロトコル（SDP）などの既存のシグナリングメカニズム（SDP）と共に指定されて、TelePresence Callを作成します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8848.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc8848で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Media Feature Tag Definition
4. SDP Grouping Framework CLUE Extension Semantics
4.1. General
4.2. The CLUE Data Channel and the CLUE Grouping Semantic
4.3. CLUE-Controlled Media and the CLUE Grouping Semantic
4.4. SDP Semantics for CLUE-Controlled Media
4.4.1. Signaling CLUE Encodings
4.4.1.1. Referencing Encodings in the CLUE Protocol
4.4.2. Negotiating Receipt of CLUE Capture Encodings in SDP
4.5. SDP Offer/Answer Procedures
4.5.1. Generating the Initial Offer
4.5.2. Generating the Answer
4.5.2.1. Negotiating Use of CLUE and the CLUE Data Channel
4.5.2.2. Negotiating CLUE-Controlled Media
4.5.2.3. Negotiating Non-CLUE-controlled Media
4.5.3. Processing the Initial Offer/Answer Negotiation
4.5.3.1. Successful CLUE Negotiation
4.5.3.2. CLUE Negotiation Failure
4.5.4. Modifying the Session
4.5.4.1. Adding and Removing CLUE-Controlled Media
4.5.4.2. Enabling CLUE Mid-Call
4.5.4.3. Disabling CLUE Mid-Call
4.5.4.4. CLUE Protocol Failure Mid-Call
5. Interaction of the CLUE Protocol and SDP Negotiations
5.1. Independence of SDP and CLUE Negotiation
5.2. Constraints on Sending Media
5.3. Recommendations for Operating with Non-atomic Operations
6. Interaction of the CLUE Protocol and RTP/RTCP CaptureID
6.1. CaptureID Reception during MCC Redefinition
7. Multiplexing of CLUE-Controlled Media Using BUNDLE
7.1. Overview
7.2. Usage of BUNDLE with CLUE
7.2.1. Generating the Initial Offer
7.2.2. Multiplexing of the Data Channel and RTP Media
8. Example: A Call between Two CLUE-Capable Endpoints
9. Example: A Call between a CLUE-Capable and Non-CLUE Endpoint
10. IANA Considerations
10.1. New SDP Grouping Framework Attribute
10.2. New SIP Media Feature Tag
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses
To enable devices to participate in a telepresence call, where they select the sources they wish to view, receive those media sources, and display them in an optimal fashion, Controlling Multiple Streams for Telepresence (CLUE) employs two principal and interrelated protocol negotiations. SDP [RFC4566], conveyed via SIP [RFC3261], is used to negotiate the specific media capabilities that can be delivered to specific addresses on a device. Meanwhile, CLUE protocol messages [RFC8847], transported via a CLUE data channel [RFC8850], are used to negotiate the Capture Sources available, their attributes, and any constraints in their use. They also allow the far-end device to specify which Captures they wish to receive. It is recommended that those documents be read prior to this one as this document assumes familiarity with those protocols and hence uses terminology from each with limited introduction.
デバイスがテレプレゼンスコールに参加できるようにするために、それらが表示したいソースを選択し、それらのメディアソースを受信し、それらを最適な方法で表示し、テレプレゼンスのための複数のストリームを制御する（CLUE）2つのプリンシパルと相互に関連付けられているプロトコル交渉を採用しています。SIP [RFC4566]、SIP [RFC3261]を介して運搬され、デバイス上の特定のアドレスに配信できる特定のメディア機能をネゴシエートするために使用されます。一方、手がかりデータチャネル[RFC8850]を介して転送されたCLUEプロトコルメッセージ[RFC8847]は、利用可能なキャプチャソース、属性、およびそれらの使用中の制約をネゴシエートするために使用されます。彼らはまた、遠端デバイスが受信したいキャプチャを指定できるようにします。この文書がこれらのプロトコルに精通していることを前提としているため、これらの文書を読み取ることをお勧めします。
Beyond negotiating the CLUE channel, SDP is also used to negotiate the details of supported media streams and the maximum capability of each of those streams. As the CLUE Framework [RFC8845] defines a manner in which the Media Provider expresses their maximum Encoding Group capabilities, SDP is also used to express the encoding limits for each potential Encoding.
手がかりチャネルの交渉を超えて、SDPはサポートされているメディアストリームの詳細とそれらの各ストリームの最大能力をネゴシエートするためにも使用されます。CLUE Framework [RFC8845]は、メディアプロバイダが最大エンコーディンググループ機能を表現する方法を定義しているため、SDPは各電位符号化の符号化制限を表現するためにも使用されます。
Backwards compatibility is an important consideration of the protocol: it is vital that a CLUE-capable device contacting a device that does not support CLUE is able to fall back to a fully functional non-CLUE call. The document also defines how a non-CLUE call may be upgraded to CLUE mid-call and, similarly, how CLUE functionality can be removed mid-call to return to a standard non-CLUE call.
後方互換性は、プロトコルの重要な考慮事項です.Cyueをサポートしないデバイスに接触する手淫デバイスが完全に機能的な非手がかりコールに戻ることができることが不可欠です。この文書はまた、Checure CallがCyue Mid-CallをClue-Mid-Call Cyn-Call Cyn-Callにアップグレードすることができる方法を定義し、同様に、CLUEの機能を除去して標準の非Clueコールに戻ることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきです。
This document uses terminology defined in the CLUE Framework [RFC8845].
この文書は、Clue Frameworkで定義されている用語を使用しています[RFC8845]。
A few additional terms specific to this document are defined as follows:
この文書に固有の追加の用語は、次のように定義されています。
CLUE-controlled media: A media "m=" line that is under CLUE control; the Capture Source that provides the media on this "m=" line is negotiated in CLUE. See Section 4 for details on how this control is signaled in SDP. There is a corresponding "non-CLUE-controlled" media term.
手がかり媒体：手がかり制御下にあるメディア「M =」線。この「M =」行にメディアを提供するキャプチャソースは、CLUEでネゴシエートされます。このコントロールがSDPでどのようにシグナリングされるかについては、セクション4を参照してください。対応する「手がかりがない」メディア用語があります。
non-CLUE device: A device that supports standard SIP and SDP but either does not support CLUE or does support CLUE but does not currently wish to invoke CLUE capabilities.
非手がかりデバイス：標準のSIPとSDPをサポートするデバイスは、Chegueをサポートしたり、Chueをサポートしたりしていますが、現在はCLUE機能を呼び出していません。
RTCP: RTP Control Protocol.
RTCP：RTP制御プロトコル。
SCTP: Stream Control Transmission Protocol.
SCTP：ストリーム制御伝送プロトコル。
STUN: Session Traversal Utilities for NAT.
stun：NATのセッショントラバーサルユーティリティ。
The "sip.clue" media feature tag [RFC3840] indicates support for CLUE in SIP [RFC3261] calls. A CLUE-capable device SHOULD include this media feature tag in its REGISTER requests and OPTION responses. It SHOULD also include the media feature tag in INVITE and UPDATE [RFC3311] requests and responses.
「SIP.Clue」メディア機能タグ[RFC3840]は、SIP [RFC3261]呼び出しのCLUEのサポートを示します。手軽のデバイスには、このメディア機能タグをそのレジスタ要求とオプション応答に含める必要があります。INVITEおよびUPDATE [RFC3311]要求と応答のメディア機能タグも含める必要があります。
Presence of the media feature tag in the contact field of a request or response can be used to determine that the far end supports CLUE.
要求または応答の連絡欄にメディア機能タグの存在は、遠端が手がかりをサポートしていると判断するために使用することができる。
This section defines a new SDP Grouping Framework [RFC5888] extension called 'CLUE'.
このセクションでは、「Clue」という新しいSDPグループ化フレームワーク[RFC5888]拡張子を定義します。
The CLUE extension can be indicated using an SDP session-level 'group' attribute. Each SDP media "m=" line that is included in this group, using SDP media-level mid attributes, is CLUE controlled by a CLUE data channel that is also included in this CLUE group.
CLUE拡張機能は、SDPセッションレベルの 'group'属性を使用して表示できます。SDPメディアレベルの中間属性を使用して、このグループに含まれる各SDPメディア「M =」回線は、この手がかりグループに含まれる手がかりデータチャネルによって制御されます。
Currently, only support for a single CLUE group is specified; support for multiple CLUE groups in a single session is outside the scope of this document. A device MUST NOT include more than one CLUE group in its SDP message unless it is following a specification that defines how multiple CLUE channels are signaled and is able to either determine that the other side of the SDP exchange supports multiple CLUE channels or fail gracefully in the event it does not.
現在、単一の手がかりグループのサポートのみが指定されています。単一のセッション内の複数の手がかりグループのサポートは、この文書の範囲外です。複数のClueチャネルがどのように複数のClueチャネルがどのようにシグナリングされるかを定義し、SDP Exchangeの他方の側が複数の手がかりチャネルをサポートするか、または正常に障害があることを判断することができない限り、デバイスはSDPメッセージに複数のCLUEグループを含めてはいけません。それがしないイベント。
The CLUE data channel [RFC8850] is a bidirectional data channel [RFC8831] used for the transport of CLUE messages, conveyed within an SCTP over DTLS connection. This channel must be established before CLUE protocol messages can be exchanged and CLUE-controlled media can be sent.
CLUEデータチャネル[RFC8850]は、DTLS接続を介してSCTP内で伝達された、手がかりメッセージのトランスポートに使用される双方向データチャネル[RFC8831]です。CLUEプロトコルメッセージを交換することができる前に、このチャネルを確立し、必要なメディアを送信することができます。
The data channel is negotiated over SDP as described in [RFC8864]. A CLUE-capable device wishing to negotiate CLUE MUST also include a CLUE group in their SDP Offer or Answer and include the "mid" of the "m=" line for the data channel in that group. The CLUE group MUST include the "mid" of the "m=" line for one (and only one) data channel.
[RFC8864]に記載されているように、データチャネルはSDPを介してネゴシエートされます。手がかりを交渉することを望む手軽の装置はまた、それらのSDPオファーまたは回答の手がかりグループを含む必要があり、そのグループ内のデータチャネルの「M =」行の「MID」を含む。手がかりグループには、1つのデータチャネルの「M =」行の「MID」を含める必要があります。
Presence of the data channel in the CLUE group in an SDP Offer or Answer also serves, along with the "sip.clue" media feature tag, as an indication that the device supports CLUE and wishes to upgrade the call to include CLUE-controlled media. A CLUE-capable device SHOULD include a data channel "m=" line in offers and, when allowed by [RFC3264], answers.
SDPオファーまたは答えのCLUEグループ内のデータチャネルの存在は、デバイスが手がかりをサポートしているという指示として、CLUE制御メディアを含むように呼び出しをアップグレードしたいという指示としても役立ちます。。手掛かりの装置は、オファーのデータチャネル「M =」回線を含み、[RFC3264]で許可されている場合は回答を含める必要があります。
CLUE-controlled media lines in an SDP are "m=" lines in which the content of the media streams to be sent is negotiated via the CLUE protocol [RFC8847]. For an "m=" line to be CLUE controlled, its "mid" attribute value MUST be included in the CLUE group. CLUE-controlled media is controlled by the CLUE protocol as negotiated on the CLUE data channel with a "mid" included in the CLUE group.
SDP内の手がかりメディアラインは、送信されるメディアストリームの内容がCLUEプロトコル[RFC8847]を介してネゴシエートされる「M =」行です。「M =」回線が手がかりを制御するためには、その「Mid」属性値を手がかりグループに含める必要があります。手がかり媒体は、手がかりグループに含まれている「MID」を持つ、手がかりデータチャネル上で交渉されているCLUEプロトコルによって制御されます。
"m=" lines not specified as being under CLUE control follow normal rules for media streams negotiated in SDP as defined in documents such as [RFC3264].
「M =」回線は、Clue Controlの下にあるとは指定されていません[RFC3264]のような文書で定義されているSDPでネゴシエートされたメディアストリームの通常の規則に従ってください。
The restrictions on CLUE-controlled media that are defined below always apply to "m=" lines in an SDP Offer or Answer, even if negotiation of the data channel in SDP failed due to lack of CLUE support by the remote device or for any other reason, or in an offer if the recipient does not include the "mid" of the corresponding "m=" line in their CLUE group.
以下に定義されている手がかりメディアの制限は、リモートデバイスによる手がかりサポートの欠如、またはその他のためにSDPのデータチャネルのネゴシエーションが失敗した場合でも、SDPのオファーまたは回答の「M =」ラインに常に適用されます。理由、または受信者に対応する「M =」回線の「MID」を含んでいない場合は、自分の手がかりグループに「MID」を含まない場合。
The CLUE Framework [RFC8845] defines the concept of "Encodings", which represent the sender's encode ability. Each Encoding the Media Provider wishes to signal is done so via an "m=" line of the appropriate media type, which MUST be marked as sendonly with the "a=sendonly" attribute or as inactive with the "a=inactive" attribute.
Clue Framework [RFC8845]は、送信者のエンコード機能を表す「エンコード」の概念を定義します。メディアプロバイダを符号化する各エンコードは、適切なメディアタイプの「M =」行を介して、「a = sendonly」属性または「a =非アクティブ」属性で非アクティブとしてマークされなければならない。
The encoder limits of active (e.g., "a=sendonly") Encodings can then be expressed using existing SDP syntax. For instance, for H.264, see Table 6 in Section 8.2.2 of [RFC6184] for a list of valid parameters for representing encoder sender stream limits.
アクティブのエンコーダの制限（例えば、「A = SendOnly」）のエンコーディングは、既存のSDP構文を使用して表現できます。たとえば、H.264の場合は、エンコーダ送信者ストリームの制限を表すための有効なパラメータのリストについては、[RFC6184]の「8.2.2」の表6を参照してください。
These Encodings are CLUE controlled and hence MUST include a "mid" in the CLUE group as defined above.
これらの符号化は手がかり制御されており、したがって、上で定義された手がかり群の「中」には「MID」を含める必要があります。
In addition to the normal restrictions defined in [RFC3264], the stream MUST be treated as if the "m=" line direction attribute had been set to "a=inactive" until the Media Provider has received a valid CLUE 'configure' message specifying the Capture to be used for this stream. This means that RTP packets MUST NOT be sent until configuration is complete, while non-media packets such as STUN, RTCP, and DTLS MUST be sent as per their relevant specifications, if negotiated.
[RFC3264]で定義されている通常の制限に加えて、メディアプロバイダーが有効なClue 'Configure'メッセージを指定するまで "m ="行方向属性が "A =非アクティブ"に設定されているかのように扱う必要があります。このストリームに使用されるキャプチャ。つまり、RTPパケットは設定が完了するまで送信されてはいけません。一方、STUN、RTCP、DTLなどの非メディアパケットは、ネゴシエートされた場合に関連する仕様に従って送信されなければなりません。
Every "m=" line representing a CLUE Encoding MUST contain a "label" attribute as defined in [RFC4574]. This label is used to identify the Encoding by the sender in CLUE 'advertisement' messages and by the receiver in CLUE 'configure' messages. Each label used for a CLUE-controlled "m=" line MUST be different from the label on all other "m=" lines in the CLUE group, unless an "m=" line represents a dependent stream related to another "m=" line (such as a Forward Error Correction (FEC) stream), in which case it MUST have the same label value as the "m=" line on which it depends.
CLUEエンコードを表すすべての "M ="行には、[RFC4574]で定義されている「Label」属性を含める必要があります。このラベルは、Cyner 'Advertisement'メッセージ内の送信者によるエンコーディングを識別し、Configure 'Configure'メッセージの受信者によって識別されます。「M =」行が別の「m =」に関連しない依存ストリームを表す限り、手がかりの「M =」行に使用される各ラベルは、手がかりグループ内の他のすべての「M =」行のラベルとは異なる必要があります。行（順方向誤り訂正（FEC）ストリームなど）、その場合、それが依存する「M =」行と同じラベル値を持つ必要があります。
CLUE Encodings are defined in SDP but can be referenced from CLUE protocol messages -- this is how the protocol defines which Encodings are a part of an Encoding Group (in 'advertisement' messages) and which Encoding is used to encode a specific Capture (in 'configure' messages). The labels on the CLUE-controlled "m=" lines are the references that are used in the CLUE protocol.
手がかりエンコーディングはSDPで定義されていますが、CLUEプロトコルメッセージから参照できます。これは、プロトコルがどのエンコードグループの一部であるか（ 'アドバタイズメント'メッセージ）、特定のキャプチャをエンコードするためにどのエンコードを定義するかです。'メッセージを設定します）。手がかり「M =」行のラベルは、CLUEプロトコルで使用される参照です。
Each <encID> (in encodingIDList) in a CLUE 'advertisement' message SHOULD represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP Offer/Answer message sent by the sender of the 'advertisement' message with a label value corresponding to the text content of the <encID>. If the <encID> is not defined in SDP, it MUST be one it anticipates sending in a subsequent SDP Offer/Answer exchange.
手がかりの「広告」メッセージ内の各<encid>（encodingIdlist内）は、SDPで定義されているエンコーディングを表す必要があります。参照されている特定のエンコーディングは、<encid>のテキスト内容に対応するラベル値を持つ、 '広告'メッセージの送信者によって送信された最新のSDPオファー/回答メッセージの中の手がかり "M ="行です。<encid>がSDPで定義されていない場合、それは次のSDPオファー/回答Exchangeで送信を予想するものでなければなりません。
Each <encodingID> (in captureEncodingType) in a CLUE 'configure' message MUST represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP Offer/Answer message received by the sender of the 'configure' message with a label value corresponding to the text content of the <encodingID>.
Clue 'Configure'メッセージの各<encodingID>（CaptureCondodingType）は、SDPで定義されているエンコーディングを表している必要があります。参照される特定のエンコーディングは、<encodingID>のテキスト内容に対応するラベル値を持つ、 'configure'メッセージの送信者によって受信された最新のSDPオファー/回答メッセージの中の手がかり "m ="行です。
Note that the non-atomic nature of SDP/CLUE protocol interaction may mean that there are temporary periods where an <encID>/<encodingID> in a CLUE message does not reference an SDP "m=" line, or where an Encoding represented in SDP is not referenced in a CLUE protocol message. See Section 5 for specifics.
SDP / CLUEプロトコルの対話の非原子的な性質は、CLUEメッセージ内の<符号> / <encodingID>がSDP "M ="行を参照しない、あるいはエンコーディングが表現されている一時的な期間があることを意味します。SDPはCLUEプロトコルメッセージで参照されていません。詳細についてはセクション5を参照してください。
A receiver who wishes to receive a CLUE stream via a specific Encoding requires an "a=recvonly" "m=" line that matches the "a=sendonly" Encoding.
特定の符号化を介して手がかりストリームを受信したい受信機は、「a = sendonly」符号化と一致する「a = Revonly」行を必要とする。
These "m=" lines are CLUE controlled and hence MUST include their "mid" in the CLUE group. They MAY include a "label" attribute, but this is not required by CLUE, as only label values associated with "a=sendonly" Encodings are referenced by CLUE protocol messages.
これらの「M =」線は手がかりが制御されており、したがって手がかりグループの「中」を含める必要があります。「label」属性を含めることができますが、 "A = SendOnly"エンコーディングに関連付けられているラベル値のみがClue Protocolメッセージによって参照されるため、これは手がかりでは必要ありません。
A CLUE-capable device sending an initial SDP Offer of a SIP session and wishing to negotiate CLUE will include an "m=" line for the data channel to convey the CLUE protocol, along with a CLUE group containing the "mid" of the data channel "m=" line.
CLUE対応デバイスは、SIPセッションの初期SDPオファーを送信し、手がかりをネゴシエートすることを望むChueは、データチャネルの「M =」ラインを含み、データの「MID」を含む手がかりグループと共に含む。チャネル "m ="行。
For interoperability with non-CLUE devices, a CLUE-capable device sending an initial SDP Offer SHOULD NOT include any "m=" line for CLUE-controlled media beyond the "m=" line for the CLUE data channel, and it SHOULD include at least one non-CLUE-controlled media "m=" line.
非手がかりデバイスとの相互運用性については、最初のSDPオファーを送信するCLUE対応デバイスは、手がかりデータチャネルの「M =」回線を超えて、手がかりメディアの任意の "M ="行を含めないでください。少なくとも1つの非手立地制御媒体「M =」行。
If the device has evidence that the receiver is also CLUE capable, for instance, due to receiving an initial INVITE with no SDP but including a "sip.clue" media feature tag, the above recommendation is waived, and the initial offer MAY contain "m=" lines for CLUE-controlled media.
デバイスが受信機がClueが可能なという証拠を持っている場合は、例えばSDPのNO SDPのNO SDPの受信により、「SIP.Clue」メディア機能タグを含めて、上記の推奨事項が放棄され、初期オファーが含まれている場合があります」手がかりメディアのためのm = "線。
With the same interoperability recommendations as for Encodings, the sender of the initial SDP Offer MAY also include "a=recvonly" media lines to preallocate "m=" lines to receive media. Alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange -- see Section 5 for recommendations.
エンコーディングに関して同じ相互運用性の推奨事項で、初期SDPオファーの送信者は、メディアを受信するための「M =」行を事前に置き換えるための「A = Revonly」メディアラインを含み得る。あるいは、新しいオファー/回答Exchangeでこれらの行を含める前に、手がかりプロトコルのネゴシエーションが完了するまで待つことがあります。推奨事項についてはセクション5を参照してください。
If the recipient of an initial offer is CLUE capable, and the offer contains both an "m=" line for a data channel and a CLUE group containing the "mid" for that "m=" line, they SHOULD negotiate data channel support for an "m=" line and include the "mid" of that "m=" line in a corresponding CLUE group.
初期オファーの受信者がCLUE対応であり、オファーにはデータチャネルの「M =」行とその「M =」行の「MID」を含む手がかりグループの両方が含まれています。「M =」線で、対応する手がかりグループ内の「M =」線の「MID」を含みます。
A CLUE-capable recipient that receives an "m=" line for a data channel but no corresponding CLUE group containing the "mid" of that "m=" line MAY still include a corresponding data channel "m=" line if there are any other non-CLUE protocols it can convey over that channel, but the use of the CLUE protocol MUST NOT be negotiated on this channel.
データチャネルの「M =」ラインを受信するが、その「M =」行の「MID」を含む対応する手がかりグループは、依然として対応するデータチャネル「M =」行がある場合には、ある場合には対応するデータチャネル「M =」行を含むことができる。それはそのチャネルを伝えることができる他の非手がかりプロトコルですが、手がかりプロトコルの使用はこのチャネル上でネゴシエートされてはいけません。
If the initial offer contained "a=recvonly" CLUE-controlled media lines, the recipient SHOULD include corresponding "a=sendonly" CLUE-controlled media lines for accepted Encodings, up to the maximum number of Encodings it wishes to advertise. As CLUE-controlled media, the "mid" of these "m=" lines MUST be included in the corresponding CLUE group. The recipient MUST set the direction of the corresponding "m=" lines of any remaining "a=recvonly" CLUE-controlled media lines received in the offer to "a=inactive".
初期オファーが「A = Revonly」の手がかりのあるメディアラインを含んでいた場合、受信者は、承認されたエンコーディングの対応する「A = SendOnly」の手がかり制御メディア行を、宣伝したいエンコードの最大数まで含める必要があります。手がかり媒体として、これらの「M =」ラインの「MID」を対応する手がかりグループに含める必要があります。受信者は、オファーで受信された残りの「A = Recvonly」の手がかり制御メディア線の対応する「M =」行の方向を「A =非アクティブ」に設定する必要があります。
If the initial offer contained "a=sendonly" CLUE-controlled media lines, the recipient MAY include corresponding "a=recvonly" CLUE-controlled media lines, up to the maximum number of Capture Encodings it wishes to receive. Alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange -- see Section 5 for recommendations. The recipient MUST set the direction of the corresponding "m=" lines of any remaining "a=sendonly" CLUE-controlled media lines received in the offer to "a=inactive".
初期オファーが「A = SendOnly」の手がかり制御メディアラインを含んでいた場合、受信者は、受信したい最大キャプチャエンコーディングの最大数まで、対応する "A = Revonly"の手がかり制御メディアラインを含めることができます。あるいは、新しいオファー/回答Exchangeでこれらの行を含める前に、手がかりプロトコルのネゴシエーションが完了するまで待つことがあります。推奨事項についてはセクション5を参照してください。受信者は、オファー内で受信された残りの「A = SendOnly」の任意の「M =」行の方向を「A =非アクティブ」に設定する必要があります。
A CLUE-controlled device implementation MAY prefer to render initial, single-stream audio and/or video for the user as rapidly as possible, transitioning to CLUE-controlled media once that has been negotiated. Alternatively, an implementation MAY wish to suppress initial media, only providing media once the final, CLUE-controlled streams have been negotiated.
手がかり装置の実装は、ユーザのための初期、シングルストリームオーディオおよび/またはビデオを可能な限り迅速にレンダリングすることを好み、それが交渉されたClue制御媒体に移行する。あるいは、実装は初期メディアを抑制し、最終的な手がかりストリームが交渉された後にメディアを提供するだけである。
The receiver of the initial offer, if making the call CLUE-enabled with their SDP Answer, can make their preference clear by their action in accepting or rejecting non-CLUE-controlled media lines. Rejecting these "m=" lines will ensure that no non-CLUE-controlled media flows before the CLUE-controlled media is negotiated. In contrast, accepting one or more non-CLUE-controlled "m=" lines in this initial answer will enable initial media to flow.
最初のオファーの受信者は、コールをSDP回答で許可されている場合は、手がかりのないメディアラインを受け入れるか拒否する際のそれらのアクションによって彼らの好みを明確にすることができます。これらの「M =」線を拒否すると、手がかり媒体が交渉される前に、手がかりがない媒体が流れないことを確認します。対照的に、この最初の回答で1つ以上の手がかりのない「M =」ラインを受け入れると、初期メディアが流れます。
If the answerer chooses to send initial non-CLUE-controlled media in a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it once the CLUE-controlled media is fully negotiated.
回答者がClue対応の呼び出しで最初の非Clue制御メディアを送信することを選択した場合、セクション4.5.4.1は、CLUE制御メディアが完全にネゴシエートされたら、それを無効にする必要があります。
In the event that both the offer and answer include a data channel "m=" line with a "mid" value included in corresponding CLUE groups, CLUE has been successfully negotiated, and the call is now CLUE enabled. If not, then the call is not CLUE enabled.
対応する手がかりグループに含まれる「MID」値を持つデータチャネル「M =」行の両方が含まれている場合、CLUEは正常にネゴシエートされ、CallはCyue Enabledになりました。そうでない場合、呼び出しはClue Enabledされません。
In the event of successful CLUE enablement of the call, devices MUST now begin negotiation of the CLUE channel; see [RFC8850] for negotiation details. If negotiation is successful, the sending of CLUE protocol messages [RFC8847] can begin.
コールの手がかりの有効化が成功した場合、デバイスはChuneチャネルのネゴシエーションを開始する必要があります。ネゴシエーションの詳細については[RFC8850]を参照してください。ネゴシエーションが成功した場合は、CLUEプロトコルメッセージの送信[RFC8847]を開始できます。
A CLUE-capable device MAY choose not to send RTP on the non-CLUE-controlled channels during the period in which control of the CLUE-controlled media lines is being negotiated (though RTCP MUST still be sent and received as normal). However, a CLUE-capable device MUST still be prepared to receive media on non-CLUE-controlled media lines that have been successfully negotiated as defined in [RFC3264].
手がかり可能な装置は、手がかり媒体線の制御がネゴシエートされている期間中に、手がかりがないチャネル上にRTPを送信しないことを選択することができる（RTCPは依然として通常として送信され受信されなければならない）。ただし、[RFC3264]で定義されているように正常にネゴシエートされた非手立地制御メディアライン上のメディアを受信するようにする必要があることを依然として準備する必要があります。
If either side of the call wishes to add additional CLUE-controlled "m=" lines to send or receive CLUE-controlled media, they MAY now send a SIP request with a new SDP Offer following the normal rules of SDP Offer/Answer and any negotiated extensions.
Callのどちら側の側面が手がかり制御されたメディアを送受信するために追加の手がかり "m ="行を追加したい場合、それらはSDPオファー/回答の通常の規則に従って新しいSDPオファーでSIPリクエストを送信することができます。交渉された拡張機能
In the event that the negotiation of CLUE fails and the call is not CLUE enabled once the initial offer/answer negotiation completes, then CLUE is not in use in the call. CLUE-capable devices MUST either revert to non-CLUE behavior or terminate the call.
CLUEのネゴシエーションが失敗し、最初のオファー/アンケートのネゴシエーションが完了すると、Calueが有効になっていない場合は、CLUEは呼び出しに使用されていません。CLUE対応デバイスは、非手間の動作に戻すか、呼び出しを終了する必要があります。
Subsequent offer/answer exchanges MAY add additional "m=" lines for CLUE-controlled media or activate or deactivate existing "m=" lines per the standard SDP mechanisms.
後続のオファー/回答交換は、手がかりメディアのための追加の「M =」行を追加することも、標準のSDPメカニズムごとに既存の「M =」行を有効または無効にすることができます。
In most cases, at least one additional exchange after the initial offer/answer exchange will be required before both sides have added all the Encodings and the ability to receive Encodings that they desire. Devices MAY delay adding "a=recvonly" CLUE-controlled "m=" lines until after CLUE protocol negotiation completes -- see Section 5 for recommendations.
ほとんどの場合、両側がすべてのエンコーディングとそれらが望むエンコーディングを受信する能力を追加する前に、最初のオファー/回答交換後の少なくとも1つの追加の交換が必要とされます。手がかりプロトコルのネゴシエーションが完了するまで、「A = Revonly」の「M =」回線を追加することを遅らせることができます。推奨についてはセクション5を参照してください。
Once CLUE media has been successfully negotiated, devices SHOULD ensure that non-CLUE-controlled media is deactivated by setting their ports to 0 in cases where it corresponds to the media type of CLUE-controlled media that has been successfully negotiated. This deactivation may require an additional SDP exchange or may be incorporated into one that is part of the CLUE negotiation.
Clue Mediaが正常にネゴシエートされたら、デバイスは、正常にネゴシエートされたClue制御メディアのメディアタイプに対応する場合、ポートを0に設定することによって、非CLUE制御されていないメディアが非アクティブ化されることを確認する必要があります。この非活性化は追加のSDP交換を必要とし得るか、または手がかり交渉の一部であるものに組み込むことができる。
A CLUE-capable device that receives an initial SDP Offer from a non-CLUE device SHOULD include a new data channel "m=" line and corresponding CLUE group in any subsequent offers it sends, to indicate that it is CLUE capable.
非手がかり装置からの初期SDPオファーを受信する手対応の装置は、それがChele可能であることを示すために、それが送信することを示すために、それが送信することを示すために、新しいデータチャネル「M =」回線および対応する手がかりグループを含むべきである。
If, in an ongoing non-CLUE call, an SDP Offer/Answer exchange completes with both sides having included a data channel "m=" line in their SDP and with the "mid" for that channel in a corresponding CLUE group, then the call is now CLUE enabled; negotiation of the data channel and subsequently the CLUE protocol begins.
進行中の非手がかりでは、SDPオファー/回答Exchangeが、SDP内にデータチャネル「M =」ラインを含み、そのチャネルの「MID」を対応する手がかりグループ内の「MID」と共に完了した場合、CallはClue Enabledになりました。データチャネルのネゴシエーションとその後の手がかりプロトコルが始まります。
If, during an ongoing CLUE-enabled call, a device wishes to disable CLUE, it can do so by following the procedures for closing a data channel as defined in Section 6.6.1 of [RFC8864]: sending a new SDP Offer/Answer exchange and subsequent SCTP Stream Sequence Number (SSN) reset for the CLUE channel. It MUST also remove the CLUE group. Without the CLUE group, any "m=" lines that were previously CLUE controlled no longer are; implementations MAY disable them by setting their ports to 0 or MAY continue to use them -- in the latter case, how they are used is outside the scope of this document.
進行中のClue対応の呼び出し中に、デバイスがChecueを無効にしたい場合は、[RFC8864]のセクション6.6.1で定義されているデータチャネルを閉じる手順に従って実行できます。新しいSDPオファー/回答Exchangeそして、後続のSCTPストリームシーケンス番号（SSN）は、手がかりチャネルに対してリセットされます。手がかりグループも取り外す必要があります。手がかりグループなしでは、以前に制御されていなかったすべての「M =」行はもはやそうではありません。実装は、ポートを0に設定したり、それらを使用し続けることによってそれらを無効にすることができます - 後者の場合、それらの使用方法はこの文書の範囲外です。
If a device follows the procedure above, or an SDP Offer/Answer negotiation completes in a fashion in which either the "m=" CLUE data channel line was not successfully negotiated and/or one side did not include the data channel in the CLUE group, then CLUE for this call is disabled. In the event that this occurs, CLUE is no longer enabled. Any active "m=" lines still included in the CLUE group are no longer CLUE controlled, and the implementation MAY either disable them in a subsequent negotiation or continue to use them in some other fashion. If the data channel is still present but not included in the CLUE group semantic, CLUE protocol messages MUST no longer be sent.
デバイスが上記の手順に従う場合、または「M =」の手がかりデータチャネルラインが正常にネゴシエートされていない方法でSDPオファー/アンケートのネゴシエーションが完了し、CLUEグループにデータチャネルが含まれていませんでした。この呼び出しのための手がかりは無効になります。これが発生した場合、Clueは有効になっていません。手がかりグループにまだ含まれているすべてのアクティブな「M =」行は、もはや手がかりが制御されず、実装はその後のネゴシエーションでそれらを無効にするか、または他の方法でそれらを使用し続けることができます。データチャネルがまだ存在しているがCLUEグループのセマンティックに含まれていない場合は、Clue Protocolメッセージを送信しなくなる必要があります。
In contrast to the specific disablement of the use of CLUE described above, the CLUE channel may fail unexpectedly. Two circumstances where this can occur are:
上記の手がかりの使用の具体的な無効化とは対照的に、手がかりチャネルは予期せずに失敗する可能性があります。これが発生する可能性がある2つの状況は次のとおりです。
* The CLUE data channel terminates, either gracefully or ungracefully, without any corresponding SDP renegotiation.
* 手がかりデータチャネルは、対応するSDP再ネゴシエーションなしに、優雅にまたは未知のいずれかで終了します。
* A channel error of the CLUE protocol causes it to return to the IDLE state as defined in Section 6 of [RFC8847].
* CLUEプロトコルのチャネルエラーは、[RFC8847]のセクション6で定義されているようにアイドル状態に戻ります。
In this circumstance, implementations SHOULD continue to transmit and receive CLUE-controlled media on the basis of the last negotiated CLUE messages, until the CLUE protocol is re-established (in the event of a channel error) or disabled mid-call by an SDP exchange as defined in Section 4.5.4.3. Implementations MAY choose to send such an SDP request to disable CLUE immediately or MAY continue on in a call-preservation mode.
このような状況では、実装は最後のネゴシエートされた手がかりメッセージに基づいて（チャネルエラーが発生した場合）、またはSDPによるミッドコールを無効にするまで、実装は継続的に手がかりメディアを送受信し続けるべきです。セクション4.5.4.3で定義されている交換。実装は、すぐにChyueを無効にするようにそのようなSDP要求を送信するか、または通話保存モードで続行することができます。
Information about media streams in CLUE is split between two message types: SDP, which defines media addresses and limits, and the CLUE channel, which defines properties of Capture Devices available, scene information, and additional constraints. As a result, certain operations, such as advertising support for a new transmissible Capture with an associated stream, cannot be performed atomically, as they require changes to both SDP and CLUE messaging.
CLUE内のメディアストリームに関する情報は、メディアアドレスと制限を定義する2つのメッセージタイプ：SDP、およびキャプチャデバイスのプロパティ、シーン情報、および追加の制約を定義する2つのメッセージタイプ間で分割されます。その結果、SDPとClue Messagingの両方に変更が必要なので、関連するストリームを有する新しい送信可能キャプチャに対する広告サポートなどの特定の操作は原子的に実行することができない。
This section defines how the negotiation of the two protocols interact, provides some recommendations on dealing with intermediate stages in non-atomic operations, and mandates additional constraints on when CLUE-configured media can be sent.
このセクションでは、2つのプロトコルのネゴシエーションが対話する方法を定義し、非原子演算での中間段階に対処するための推奨事項をいくつか示し、CLUE構成のメディアを送信できるときに追加の制約を義務付けます。
To avoid the need to implement interlocking state machines with the potential to reach invalid states if messages were to be lost, or be rewritten en route by middleboxes, the state machines in SDP and CLUE operate independently. The state of the CLUE channel does not restrict when an implementation may send a new SDP Offer or Answer; likewise, the implementation's ability to send a new CLUE 'advertisement' or 'configure' message is not restricted by the results of or the state of the most recent SDP negotiation (unless the SDP negotiation has removed the CLUE channel).
メッセージが失われた場合、またはMiddleBoxesによってenルートを書き直すことができ、または書き換えられた状態で、無効な状態に到達する可能性のあるインターロック状態マシンを実装する必要性を回避するために、SDPとClueの状態マシンは独立して動作します。手がかりチャネルの状態は、実装が新しいSDPオファーまたは回答を送信することができる場合に制限されません。同様に、新しい手がかり「広告」または「構成」メッセージを送信する能力は、最新のSDPネゴシエーションの結果または最新のSDPネゴシエーションの状態によって制限されません（SDPネゴシエーションが手がかりチャネルを削除した場合を除く）。
The primary implication of this is that a device may receive an SDP Offer/Answer message with a CLUE Encoding for which it does not yet have Capture information or receive a CLUE 'configure' message specifying a Capture Encoding for which the far end has not negotiated a media stream in SDP.
この主な意味は、デバイスが、まだキャプチャ情報を持っていない、または遠端が交渉されていないキャプチャエンコーディングを指定しているClue 'Configure'メッセージを受信する手がかりエンコーディングを使用して、デバイスがSDPオファー/アンサーメッセージを受信できることです。SDPのメディアストリーム。
CLUE messages contain an <encID> (in encodingIDList) or <encodingID> (in captureEncodingType), which is used to identify a specific Encoding or captureEncoding in SDP; see [RFC8846] for specifics. The non-atomic nature of CLUE negotiation means that a sender may wish to send a new CLUE 'advertisement' message before the corresponding SDP message. As such, the sender of the CLUE message MAY include an <encID> that does not currently match a CLUE-controlled "m=" line label in SDP; a CLUE-capable implementation MUST NOT reject a CLUE protocol message solely because it contains <encID> elements that do not match a label in SDP.
CLUEメッセージには、（CaptureEncodingType内のencid>（encidIdList）または<encodingId>が含まれています。これは、SDPで特定のエンコードまたはCaptureCondodingを識別するために使用されます。詳細については[RFC8846]を参照してください。CLUEネゴシエーションの非原子的な性質は、送信者が対応するSDPメッセージの前に新しい手がかりの「広告」メッセージを送信したいと思うかもしれません。したがって、手がかりメッセージの送信者は、SDP内の手がかり制御された「M =」回線ラベルを現在一致していない<符号>を含み得る。CLUE対応の実装は、SDPのラベルと一致しない<符号>要素が含まれているため、手がかりプロトコルメッセージを拒否してはいけません。
The current state of the CLUE Participant or Media Provider/Consumer state machines does not affect compliance with any of the normative language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP exchange as part of a SIP server or client transaction; an implementation MUST NOT delay an SDP exchange while waiting for CLUE negotiation to complete or for a 'configure' message to arrive.
手がかり参加者またはメディアプロバイダー/コンシューマ州の州のマシンの現在の状態は、[RFC3264]の規範的な言語のいずれにも影響を与えません。つまり、SIPサーバーまたはクライアントトランザクションの一部として進行中のSDP Exchangeを遅らせることはできません。実装は、CLUEネゴシエーションを完了するのを待っている間、または「設定」メッセージを到着させるのを待っている間、SDP交換を遅らせることはできません。
Similarly, a device in a CLUE-enabled call MUST NOT delay any mandatory state transitions in the CLUE Participant or Media Provider/Consumer state machines due to the presence or absence of an ongoing SDP exchange.
同様に、CLUE対応コールのデバイスは、進行中のSDP Exchangeの有無により、手がかり参加者またはメディアプロバイダ/コンシューマステートマシン内の必須の状態遷移を遅らせることはできません。
A device with the CLUE Participant state machine in the ACTIVE state MAY choose to delay moving from ESTABLISHED to ADV (Media Provider state machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media Consumer state machine) based on the SDP state. See [RFC8847] for CLUE state machine specifics. Similarly, a device MAY choose to delay initiating a new SDP exchange based on the state of their CLUE state machines.
アクティブ状態にある手がかりステートマシンを持つデバイスは、SDP状態に基づいて、確立された、ADV（メディアプロバイダーステートマシン）からADV（Media Provider State Machine）への移動を遅らせることを選択できます。Clue State Machineの詳細については[RFC8847]を参照してください。同様に、デバイスは、それらの手がかりマシンの状態に基づいて新しいSDP交換の開始を遅らせることを選択することができる。
While SDP and CLUE message states do not impose constraints on each other, both impose constraints on the sending of media -- CLUE-controlled media MUST NOT be sent unless it has been negotiated in both CLUE and SDP: an implementation MUST NOT send a specific CLUE Capture Encoding unless its most recent SDP exchange contains an active media channel for that Encoding AND it has received a CLUE 'configure' message specifying a valid Capture for that Encoding.
SDPおよびCLUEメッセージの状態が互いに制約を課しないが、メディア制御メディアの送信に対する制約を課すことは、CLUEとSDPの両方でネゴシエートされていない限り送信されてはならない。実装は特定のものを送信してはいけません最新のSDP Exchangeには、そのエンコード用のアクティブメディアチャネルが含まれていない限り、CLUEキャプチャエンコーディングで、そのエンコーディングの有効なキャプチャを指定したCLUE 'Configure'メッセージを受信しました。
CLUE-capable devices MUST be able to handle states in which CLUE messages make reference to EncodingIDs that do not match the most recently received SDP, irrespective of the order in which SDP and CLUE messages are received. While these mismatches will usually be transitory, a device MUST be able to cope with such mismatches remaining indefinitely. However, this document makes some recommendations on message ordering for these non-atomic transitions.
CLUE対応デバイスは、SDPメッセージとCLUEメッセージを受信した順序に関係なく、CLUEメッセージが最後に受信されたSDPと一致しないEncodingIDを参照する状態を処理できる必要があります。これらのミスマッチは通常一時的であるが、装置は無期限に残っているそのような不整合に対処することができなければならない。ただし、この文書はこれらの非原子遷移のメッセージ順序付けに関するいくつかの推奨事項を作成します。
CLUE-capable devices MUST ensure that any inconsistencies between SDP and CLUE signaling are temporary by sending updated SDP or CLUE messages as soon as the relevant state machines and other constraints permit.
CLUE対応デバイスは、関連するステートマシンやその他の制約が許可されるとすぐに、更新されたSDPまたはCLUEメッセージを送信することによって、SDPとClueシグナリングの間の不一致が一時的なものであることを確認する必要があります。
Generally, implementations that receive messages with incomplete information will be most efficient if they wait until they have the corresponding information they lack before sending messages to make changes related to that information. For example, an answerer that receives a new SDP Offer with three new "a=sendonly" CLUE "m=" lines for which it has received no CLUE 'advertisement' message providing the corresponding capture information would typically include corresponding "a=inactive" lines in its answer, and it would only make a new SDP Offer with "a=recvonly" when and if a new 'advertisement' message arrives with Captures relevant to those Encodings.
一般に、不完全な情報を持つメッセージを受信する実装は、メッセージを送信する前に、その情報に関連する変更を加える前に、対応する情報を持っているまで待機しても最も効率的です。たとえば、対応するキャプチャ情報を提供する手がかりが「A = SendOnly」のCLUE "M ="行を受信した新しいSDPオファーを受信した回答者は、通常、対応する「A =非アクティブ」を含みます。答えの中の行で、新しい「広告」メッセージがそれらのエンコーディングに関連するキャプチャに到着した場合には、「A = Recvonly」という新しいSDPオファーだけを作成します。
Because of the constraints of SDP Offer/Answer and because new SDP negotiations are generally more 'costly' than sending a new CLUE message, implementations needing to make changes to both channels SHOULD prioritize sending the updated CLUE message over sending the new SDP message. The aim is for the recipient to receive the CLUE changes before the SDP changes, allowing the recipient to send their SDP Answers without incomplete information and reducing the number of new SDP Offers required.
SDPオファー/回答の制約のため、そして新しいSDPネゴシエーションは一般的に新しいCLUEメッセージを送信するよりも「費用がかかる」ため、両方のチャネルを変更する必要がある実装は、新しいSDPメッセージを送信する上で更新されたCLUEメッセージの送信を優先する必要があります。目的は、受信者がSDPの変更前に手がかりの変更を受け取ることで、受信者が不完全な情報なしでSDP回答を送信し、必要な新しいSDPオファーの数を減らすことができます。
The CLUE Framework [RFC8845] allows for Multiple Content Captures (MCCs): Captures that contain multiple source Captures, whether composited into a single stream or switched based on some metric.
CLUE Framework [RFC8845]は、複数のコンテンツキャプチャ（MCCS）を使用できます。複数のソースキャプチャを含むキャプチャ、または複数のストリームに基づいて切り替えられるかどうか。
The Captures that contribute to these MCCs may or may not be defined in the 'advertisement' message. If they are defined and the MCC is providing them in a switched format, the recipient may wish to determine which originating source Capture is currently being provided, so that they can apply geometric corrections based on that Capture's geometry or take some other action based on the original Capture information.
これらのMCCに貢献するキャプチャは、「広告」メッセージで定義されている場合があります。それらが定義されており、MCCがそれらを切り替えられたフォーマットに提供している場合、受信者は、どの発信元のキャプチャが現在提供されているかを判断し、そのキャプチャのジオメトリに基づいて幾何学的修正を適用することができ、またはそれらに基づいて他の何らかの行動を取ることができるかを決定することができる。元のキャプチャ情報
To do this, [RFC8849] allows for the CaptureID of the originating Capture to be conveyed via RTP or RTCP. A Media Provider sending switched media for an MCC with defined originating sources MUST send the CaptureID in both RTP and RTCP, as described in the mapping document.
これを行うには、[RFC8849]は、RTPまたはRTCPを介して発信キャプチャのCaptureIdを伝達することを可能にします。定義された発信元の送信元を備えたMCC用のスイッチドメディアを送信するメディアプロバイダは、マッピング文書で説明されているように、RTPとRTCPの両方でCaptureIDを送信する必要があります。
Because the RTP/RTCP CaptureID is delivered via a different channel to the 'advertisement' message in which in the contents of the MCC are defined, there is an intrinsic race condition in cases where the contents of an MCC are redefined.
RTP / RTCP CaptureIDは、MCCの内容が定義されている「広告」メッセージに異なるチャネルを介して配信されるため、MCCの内容が再定義されている場合には、固有の競合状態があります。
When a Media Provider redefines an MCC that involves CaptureIDs, the reception of the relevant CaptureIDs by the recipient will either lead or lag reception and the processing of the new 'advertisement' message by the recipient. As such, a Media Consumer MUST NOT be disrupted by any of the following scenarios in any CLUE-controlled media stream it is receiving, whether that stream is for a static Capture or for an MCC (as any static Capture may be redefined to an MCC in a later 'advertisement' message):
メディアプロバイダがCaptureIDを含むMCCを再定義すると、受信者による関連キャプチャーの受信は、リードまたは遅れ受信と受信者による新しい「広告」メッセージの処理となります。このように、メディアコンシューマは、それが受信しているすべての手がかりメディアストリーム内のいずれかのシナリオでは、そのストリームが静的キャプチャの場合（静的キャプチャがMCCに再定義される可能性があるため）。後の「広告」メッセージで）
* By receiving RTP or RTCP containing a CaptureID when the most recently processed 'advertisement' message means that no media CaptureIDs are expected.
* 最も最近処理された「広告」メッセージがメディアキャプチャーを想定していないことを意味する場合、CaptureIDを含むRTPまたはRTCPを受信することによって。
* By receiving RTP or RTCP without CaptureIDs when the most recently processed 'advertisement' message means that media CaptureIDs are expected.
* 最も最近処理された「広告」メッセージがメディアキャプチャされていることを意味するときに、CaptureIDなしでRTPまたはRTCPを受信することによって。
* By receiving a CaptureID in RTP or RTCP for a Capture defined in the most recently processed 'advertisement' message, but which the same 'advertisement' message does not include in the MCC.
* 最後に処理された「広告」メッセージで定義されているキャプチャのためにRTPまたはRTCPでCaptureIDを受信することによって、MCCに同じ「広告」メッセージが含まれていません。
* By receiving a CaptureID in RTP or RTCP for a Capture not defined in the most recently processed 'advertisement' message.
* 最も最近処理された「広告」メッセージで定義されていないキャプチャのためにRTPまたはRTCPでCaptureIdを受信することによって。
A CLUE call may involve sending and/or receiving significant numbers of media streams. Conventionally, media streams are sent and received on unique ports. However, each separate port used for this purpose may impose costs that a device wishes to avoid, such as the need to open that port on firewalls and NATs, the need to collect Interactive Connectivity Establishment (ICE) candidates [RFC8445], etc.
手がかり呼び出しは、かなりの数のメディアストリームを送信および/または受信することを含み得る。従来、メディアストリームは固有のポートで送受信されます。ただし、この目的のために使用された各別のポートは、ファイアウォールやNATS上のそのポートを開く必要性、インタラクティブ接続確立（ICE）候補[RFC8445]などを開く必要性など、デバイスが回避したいコストを課すことがあります。
The BUNDLE extension [RFC8843] can be used to negotiate the multiplexing of multiple media lines onto a single 5-tuple for sending and receiving media, allowing devices in calls to another BUNDLE-supporting device to potentially avoid some of the above costs.
バンドル拡張[RFC8843]を使用して、メディアを送受信するために複数のメディアラインのマルチプレックスを単一の5タプル上にネゴシエートして、他のバンドルサポートデバイスへの呼び出しのデバイスが上記のコストの一部を回避する可能性があります。
While CLUE-capable devices MAY support the BUNDLE extension for this purpose, supporting the extension is not mandatory for a device to be CLUE compliant.
CLUE対応デバイスはこの目的のためにバンドル拡張をサポートするかもしれませんが、拡張子をサポートすることは、デバイスが手がかりに準拠するのに必須ではありません。
A CLUE-capable device that supports BUNDLE SHOULD also support rtcp-mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux may or may not support BUNDLE.
バンドルをサポートするClue対応デバイスもRTCP-MUX [RFC5761]をサポートする必要があります。ただし、RTCP-MUXをサポートするCLUE対応デバイスは、バンドルをサポートしていてもできない場合があります。
This specification imposes no additional requirements or restrictions on the usage of BUNDLE when used with CLUE. There is no restriction on combining CLUE-controlled media lines and non-CLUE-controlled media lines in the same BUNDLE group or in multiple such groups. However, there are several steps an implementation may wish to take to ameliorate the cost and time requirements of extra SDP Offer/ Answer exchanges between CLUE and BUNDLE.
この仕様は、CLUEと共に使用されたときのバンドルの使用方法に追加の要件または制限を課しません。同じ束グループまたは複数のそのようなグループ内の手がかり媒体線および非手立地制御媒体ラインを組み合わせることに制限はない。しかしながら、手がかりと束の間の追加のSDPオファー/回答交換のコストと時間要件を改善するために実装が望むかもしれないいくつかのステップがあるかもしれない。
BUNDLE mandates that the initial SDP Offer MUST use a unique address for each "m=" line with a non-zero port. Because CLUE implementations generally will not include CLUE-controlled media lines, with the exception of the data channel in the initial SDP Offer, CLUE devices that support large numbers of streams can avoid ever having to open large numbers of ports if they successfully negotiate BUNDLE.
バンドルは、初期SDPオファーが、ゼロ以外のポートを使用して各 "M ="行ごとに一意のアドレスを使用する必要があることを義務付けています。手がかりの実装は一般にChement Controlside Media Lineを含めないため、初期SDPオファーのデータチャネルを除いて、多数のストリームをサポートする手がかりデバイスは、バンドルを正常にネゴシエートした場合は多数のポートを開く必要があります。
An implementation that does include CLUE-controlled media lines in its initial SDP Offer while also using BUNDLE must take care to avoid rendering its CLUE-controlled media lines unusable in the event the far end does not negotiate BUNDLE if it wishes to avoid the risk of additional SDP exchanges to resolve this issue. This is best achieved by not sending any CLUE-controlled media lines in an initial offer with the 'bundle-only' attribute unless it has been established via some other channel that the recipient supports and is able to use BUNDLE.
バンドルを使用している間に、最初のSDPオファーの中の手がかりメディアラインを含む実装では、バンドルを使用している間には、手がかりの制御メディアラインを使用できなくなります。この問題を解決するための追加のSDP交換。これは、受信者がサポートしていてバンドルを使用できるように、他のチャネルを介して確立されていない限り、「バンドル専用」属性を使用して、初期オファーで手がかり制御メディアラインを送信しないことによって最もよく達成されます。
BUNDLE-supporting CLUE-capable devices MAY include the data channel in the same BUNDLE group as RTP media. In this case, the device MUST be able to demultiplex the various transports -- see Section 9.2 of the BUNDLE specification [RFC8843]. If the BUNDLE group includes protocols other than the data channel transported via DTLS, the device MUST also be able to differentiate the various protocols.
バンドルサポートの手軽デバイスは、RTPメディアと同じバンドルグループ内のデータチャネルを含めることができます。この場合、デバイスはさまざまなトランスポートを逆多重化できなければなりません - バンドル指定[RFC8843]のセクション9.2を参照してください。バンドルグループがDTLSを介して輸送されたデータチャネル以外のプロトコルを含む場合、デバイスはさまざまなプロトコルも区別できなければなりません。
This example illustrates a call between two CLUE-capable Endpoints. Alice, initiating the call, is a system with three cameras and three screens. Bob, receiving the call, is a system with two cameras and two screens. A call-flow diagram is presented, followed by a summary of each message.
この例では、2つのCLUE対応エンドポイント間の呼び出しを示します。呼び出しを開始して、3つのカメラと3つのスクリーンを持つシステムです。電話を受けるBOBは、2つのカメラと2つのスクリーンを持つシステムです。コールフロー図を表示し、続いて各メッセージの概要を示します。
To manage the size of this section, the SDP snippets only illustrate video "m=" lines. SIP ACKs are not always discussed. Note that BUNDLE is not in use.
このセクションのサイズを管理するために、SDPスニペットはビデオ "m ="行を示しています。SIP ACKは必ずしも議論されていません。バンドルは使用されていません。
+----------+ +-----------+
| Alice | | Bob |
| | | |
+----+-----+ +-----+-----+
| |
| |
| SIP INVITE 1 |
|--------------------------------->|
| |
| |
| SIP 200 OK 1 |
|<---------------------------------|
| |
| |
| SIP ACK 1 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 1 ############>|
| 1 video A->B, 1 video B->A |
|<################################>|
| |
| |
| |
|<================================>|
| CLUE DATA CHANNEL ESTABLISHED |
|<================================>|
| |
| |
| CLUE OPTIONS |
|<*********************************|
| |
| |
| CLUE OPTIONS RESPONSE |
|*********************************>|
| |
| |
| CLUE ADVERTISEMENT 1 |
|*********************************>|
| |
| |
| CLUE ADVERTISEMENT 2 |
|<*********************************|
| |
| |
| CLUE ACK 1 |
|<*********************************|
| |
| |
| CLUE ACK 2 |
|*********************************>|
| |
| |
| SIP INVITE 2 (+3 sendonly) |
|--------------------------------->|
| |
| |
| CLUE CONFIGURE 1 |
|<*********************************|
| |
| |
| SIP 200 OK 2 (+2 recvonly) |
|<---------------------------------|
| |
| |
| CLUE CONFIGURE RESPONSE 1 |
|*********************************>|
| |
| |
| SIP ACK 2 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 2 ############>|
| 2 video A->B, 1 video B->A |
|<################################>|
| |
| |
| SIP INVITE 3 (+2 sendonly) |
|<---------------------------------|
| |
| |
| CLUE CONFIGURE 2 |
|*********************************>|
| |
| |
| SIP 200 OK 3 (+2 recvonly) |
|--------------------------------->|
| |
| |
| CLUE CONFIGURE RESPONSE 2 |
|<*********************************|
| |
| |
| SIP ACK 3 |
|<---------------------------------|
| |
| |
| |
|<########### MEDIA 3 ############>|
| 2 video A->B, 2 video B->A |
|<################################>|
| |
| |
| |
v v
In SIP INVITE 1, Alice sends Bob a SIP INVITE with the basic audio and video capabilities and data channel included in the SIP body as per [RFC8841]. Alice also includes the "sip.clue" media feature tag in the INVITE. A snippet of the SDP showing the grouping attribute and the video "m=" line are shown below. Alice has included a "CLUE" group and the mid corresponding to a data channel in the group (3). Note that Alice has chosen not to include any CLUE-controlled media in the initial offer -- the "mid" value of the video line is not included in the "CLUE" group.
SIP INVITE 1では、AliceはBOB A SIP INVITEを基本的なオーディオとビデオ機能とSIPボディに含まれるデータチャネルを[RFC8841]に含まれています。Aliceには、INVITE内の「SIP.Clue」メディア機能タグも含まれています。グループ化属性とビデオ "M ="行を示すSDPのスニペットを以下に示します。Aliceには、グループ（3）のデータチャネルに対応する「手がかり」グループとMIDが含まれています。アリスは、最初のオファーで手がかり媒体を含めないように選択したことに注意してください - ビデオ行の「Mid」値は「CLUE」グループに含まれていません。
...
a=group:CLUE 3
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=setup:actpass
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3
Bob responds with a similar SDP in SIP 200 OK 1, which also has a "CLUE" group including the "mid" value of a data channel; due to their similarity, no SDP snippet is shown here. Bob wishes to receive initial media and thus includes corresponding non-CLUE-controlled audio and video lines. Bob also includes the "sip.clue" media feature tag in the 200 OK. Alice and Bob are each now able to send a single audio and video stream. This is illustrated as MEDIA 1.
BOBはSIP 200 OK 1の類似のSDPで応答し、データチャネルの「MID」値を含む「手がかり」グループもあります。それらの類似性のために、ここではSDPスニペットは示されていない。ボブは初期媒体を受け取りたいと考えており、したがって対応する非結晶制御オーディオおよびビデオラインを含む。BOBは、200 OKの「SIP.Clue」メディア機能タグも含まれています。AliceとBobはそれぞれ、単一のオーディオストリームとビデオストリームを送信できるようになりました。これはメディア1として示されています。
With the successful initial SDP Offer/Answer exchange complete, Alice and Bob are also free to negotiate the CLUE data channel. This is illustrated as CLUE DATA CHANNEL ESTABLISHED.
最初のSDPオファー/回答を成功させた場合は、AliceとBobもまた、手がかりデータチャネルを交渉することも自由です。これはCLUEデータチャネルとして示されています。
Once the data channel is established, CLUE protocol negotiation begins. In this case, Bob was the DTLS client (sending "a=active" in his SDP Answer) and hence is the CLUE Channel Initiator. He sends a CLUE OPTIONS message describing his version support. On receiving that message, Alice sends her corresponding CLUE OPTIONS RESPONSE.
データチャネルが確立されると、手がかりプロトコルのネゴシエーションが始まります。この場合、BOBはDTLSクライアント（彼のSDP回答で "A = Active"を送信する）であり、したがって手がかりチャネルイニシエータです。彼は彼のバージョンのサポートを説明する手がかりオプションメッセージを送ります。そのメッセージを受信すると、Aliceは対応する手がかりオプションの応答を送信します。
With the OPTIONS phase complete, Alice now sends her CLUE 'advertisement' message (CLUE ADVERTISEMENT 1). She advertises three static Captures representing her three cameras. She also includes switched Captures suitable for systems with one or two screens. All of these Captures are in a single Capture Scene, with suitable Capture Scene Views that tell Bob he should subscribe to the three static Captures, the two switched Captures, or the one switched Capture. Alice has no simultaneity constraints, so all six Captures are included in one simultaneous set. Finally, Alice includes an Encoding Group with three Encoding IDs: "enc1", "enc2", and "enc3". These Encoding IDs aren't currently valid but will match the next SDP Offer she sends.
オプションフェーズが完了したら、Aliceは現在彼女の手がかりの「広告」メッセージ（Chune Advertisement 1）を送信します。彼女は彼女の3つのカメラを表す3つの静的キャプチャを宣伝します。彼女はまた、1つまたは2つのスクリーンを持つシステムに適したスイッチ付きキャプチャを含みます。これらのキャプチャのすべては、BOBを伝える適切なキャプチャシーンビューを使用して、2つの静的キャプチャ、2つの切り替えキャプチャ、または1つのスイッチされたキャプチャを伝える必要があるキャプチャシーンビューがあります。Aliceには同時性の制約がないため、6つのキャプチャーすべてが1つの同時セットに含まれています。最後に、Aliceには、 "ENC1"、 "Enc2"、および "Enc3"の3つのエンコードIDを持つ符号化グループが含まれています。これらのエンコードIDは現在無効ではありませんが、SETSを送信する次のSDPオファーと一致します。
Bob received CLUE ADVERTISEMENT 1 but does not yet send a 'configure' message, because he has not yet received Alice's Encoding information; thus, he does not know if she will have sufficient resources in order to send him the two streams he ideally wants at a quality he is happy with. Because Bob is not sending an immediate 'configure' message with the "ack" element set, he must send an explicit 'ack' message (CLUE ACK 1) to signal receipt of CLUE ADVERTISEMENT 1.
BOBはCLUE広告1を受信しましたが、まだ「Configure」メッセージを送信していません。したがって、彼は彼が彼が理想的に彼が幸せであることを理想的に望んでいる2つのストリームを彼に送るために十分なリソースを持っているかどうかわかりません。BOBは「ACK」要素セットで即値の「設定」メッセージを送信していないため、明示的な「ACK」メッセージ（CLUE ACK 1）をCLUE広告1の受信に送信する必要があります。
Bob also sends his CLUE 'advertisement' message (CLUE ADVERTISEMENT 2) -- though the diagram shows that this occurs after Alice sends CLUE ADVERTISEMENT 1, Bob sends his 'advertisement' message independently and does not wait for CLUE ADVERTISEMENT 1 to arrive. He advertises two static Captures representing his cameras. He also includes a single composed Capture for single-screen systems, in which he will composite the two camera views into a single video stream. All three Captures are in a single Capture Scene, with suitable Capture Scene Views that tell Alice she should subscribe to either the two static Captures or the single composed Capture. Bob also has no simultaneity constraints, so he includes all three Captures in one simultaneous set. Bob also includes a single Encoding Group with two Encoding IDs: "foo" and "bar".
ボブは彼の手がかりの「広告」メッセージを送ります（手がかり広告2） - AliceがClue Advertisement 1を送信した後にこれが発生したことを示していますが、Bobは彼の「広告」メッセージを独立して送信し、手がかり広告1が到着するのを待ちません。彼は彼のカメラを代表する2つの静的キャプチャを宣伝します。彼はまた、シングルスクリーンシステムのための単一の合成キャプチャを含み、そこでは2つのカメラビューを単一のビデオストリームに合成します。3つのキャプチャーはすべて単一のキャプチャシーンにあり、アリスに2つの静的キャプチャまたはシングルコンプリートキャプチャをサブスクライブすることを伝える適切なキャプチャシーンビューがあります。BOBには同時性の制約もありませんので、1つの同時セット内の3つのキャプチャーすべてを含みます。BOBは、2つのエンコーディングIDを持つ単一のエンコーディンググループも含まれています。 "foo"と "bar"。
Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send a 'configure' message, because she has not yet received Bob's Encoding information; instead, she sends an 'ack' message (CLUE ACK 2).
同様に、アリスはChulue Advertisement 2を受信しますが、まだBOBのエンコーディング情報を受信していないため、まだ「設定」メッセージを送信しません。代わりに、彼女は 'ACK'メッセージ（CLUE ACK 2）を送ります。
Both sides have now sent their CLUE 'advertisement' messages, and an SDP exchange is required to negotiate Encodings. For simplicity, in this case, Alice is shown sending an INVITE with a new offer; in many implementations, both sides might send an INVITE, which would be resolved by use of the 491 Request Pending resolution mechanism from [RFC3261].
両側が自分の手がかりの「広告」メッセージを送りました、そして、符号化を交渉するためにSDP交換が必要です。簡単にするために、この場合、Aliceは新しいオファーで招待を送信することが示されています。多くの実装では、両側が招待を送信することができます。
Alice now sends SIP INVITE 2. She maintains the sendrecv audio, video, and CLUE "m=" lines, and she adds three new sendonly "m=" lines to represent the three CLUE-controlled Encodings she can send. Each of these "m=" lines has a label corresponding to one of the Encoding IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute, data channel, and video "m=" lines are shown below:
AliceはSIP INVITE 2を送ります。これらの「M =」線のそれぞれは、Chegue Advertisement1からの符号化IDのうちの1つに対応するラベルを有する。それぞれが、それらが手がかりデータチャネルによって制御されることを示すためにグループ化属性に追加される。グループ化属性、データチャネル、およびビデオ「M =」行を示すSDPのスニペットを以下に示します。
...
a=group:CLUE 3 4 5 6
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3
...
m=video 6004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:4
a=label:enc1
m=video 6006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:5
a=label:enc2
m=video 6008 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:6
a=label:enc3
Bob now has all the information he needs to decide which streams to configure, allowing him to send both a CLUE 'configure' message and his SDP Answer. As such, he now sends CLUE CONFIGURE 1. This requests the pair of switched Captures that represent Alice's scene, and he configures them with encoder ids "enc1" and "enc2".
Bobは、どのストリームを構成するかを決定する必要があるすべての情報を持っています。そのように、彼は今度の手がかりを送信する。
Bob also sends his SDP Answer as part of SIP 200 OK 2. Alongside his original audio, video, and CLUE "m=" lines, he includes three additional "m=" lines corresponding to the three added by Alice: two active recvonly "m= "lines and an inactive "m=" line for the third. He adds their "mid" values to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 100 represents the CLUE data channel, which is not shown):
ボブはまた、SIP 200 OK 2の一部としてSDP回答を送信します。m = "行と非アクティブ" m = "行は、3番目の場合です。彼はそれらが手がかりデータチャネルによって制御されることを示すために、それらの「中」の値をグループ化属性に追加します。グループ化属性とビデオ "M ="行を示すSDPのスニペットを以下に示します（100 MID100は、図示しないCLUEデータチャネルを表します）。
...
a=group:CLUE 11 12 13 100
...
m=video 58722 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:10
...
m=video 58724 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:11
m=video 58726 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:12
m=video 58728 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=inactive
a=mid:13
Alice receives Bob's CLUE CONFIGURE 1 message and sends CLUE CONFIGURE RESPONSE 1 to acknowledge its reception. She does not yet send the Capture Encodings specified, because at this stage, she hasn't processed Bob's answer SDP and thus hasn't negotiated the ability for Bob to receive these streams.
AliceはBobの手がかりを受信し、1メッセージを受信し、その受信を確認するためにConfigure Response 1を送信します。この段階では、指定されたキャプチャエンコーディングをまだ送信していません。
On receiving SIP 200 OK 2 from Bob, Alice sends her SIP ACK (SIP ACK 2). She is now able to send the two streams of video Bob requested -- this is illustrated as MEDIA 2.
BobからSIP 200 OK 2を受信すると、アリスは彼女のSIP ACK（SIP ACK 2）を送ります。彼女は現在、要求されたビデオボブの2つのストリームを送信することができます - これはメディア2として示されています。
The constraints of offer/answer meant that Bob could not include his Encoding information as new "m=" lines in SIP 200 OK 2. As such, Bob now sends SIP INVITE 3 to generate a new offer. Along with all the streams from SIP 200 OK 2, Bob also includes two new sendonly streams. Each stream has a label corresponding to the Encoding IDs in his CLUE ADVERTISEMENT 2 message. He also adds their "mid" values to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 100 represents the CLUE data channel, which is not shown):
オファー/アンサーの制約は、SIP 200 OK 2の新しい "M ="行としての彼のエンコーディング情報を新しい "m ="行として含めることができなかったことを意味していました。SIP 200 OK 2からのすべてのストリームとともに、Bobには2つの新しいSendOnly Streamsも含まれています。各ストリームは、彼の手がかり広告2メッセージ内の符号化IDに対応するラベルを有する。また、それらが手がかりデータチャネルによって制御されていることを示すために、グループ化属性にそれらの「Mid」値を追加します。グループ化属性とビデオ "M ="行を示すSDPのスニペットを以下に示します（100 MID100は、図示しないCLUEデータチャネルを表します）。
...
a=group:CLUE 11 12 14 15 100
...
m=video 58722 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:10
...
m=video 58724 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:11
m=video 58726 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:12
m=video 0 RTP/AVP 96
a=mid:13
m=video 58728 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=label:foo
a=mid:14
m=video 58730 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=label:bar
a=mid:15
Having received this, Alice now has all the information she needs to send her CLUE 'configure' message and her SDP Answer. In CLUE CONFIGURE 2, she requests the two static Captures from Bob to be sent on Encodings "foo" and "bar".
これを受けたことで、アリスは現在彼女の手がかりの「構成」メッセージと彼女のSDPの答えを送る必要があるすべての情報を持っています。Clue Configure 2では、彼女はボブからの2つの静的キャプチャをエンコーディング "foo"と "bar"で送信されるように要求します。
Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to Bob's new sendonly lines. She includes their "mid" values in the grouping attribute to show they are controlled by the CLUE data channel. Alice then deactivates the initial non-CLUE-controlled media, as bidirectional CLUE-controlled media is now available. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 3 represents the data channel, not shown):
アリスはまた、2つのRevonly "M ="行をBobの新しいSendOnly LinesにマッチするSIP 200 OK 3を送信します。彼女は、それらが手がかりデータチャネルによって制御されることを示すために、グループ化属性内のそれらの「MID」値を含みます。次いで、双方向の手がかり媒体が利用可能であるので、アリスは最初の非手がかり培地を無効にする。グループ化属性とビデオ "M ="行を示すSDPのスニペットを以下に示します（3中3は図示せず、データチャネルを表します）。
...
a=group:CLUE 3 4 5 7 8
...
m=video 0 RTP/AVP 96
a=mid:2
...
m=video 6004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:4
a=label:enc1
m=video 6006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:5
a=label:enc2
m=video 0 RTP/AVP 96
a=mid:6
m=video 6010 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:7
m=video 6012 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:8
Bob receives Alice's CLUE CONFIGURE 2 message and sends CLUE CONFIGURE RESPONSE 2 to acknowledge its reception. Bob does not yet send the Capture Encodings specified, because he hasn't yet received and processed Alice's SDP Answer and negotiated the ability to send these streams.
BobはAliceの手がかりを設定し、2メッセージを設定し、その受信を確認するためにConfigure Response 2を送信します。BOBはまだ指定されたキャプチャエンコーディングを送信していません。
Finally, on receiving SIP 200 OK 3, Bob is now able to send the two streams of video Alice requested -- this is illustrated as MEDIA 3.
最後に、SIP 200 OK 3を受信すると、BOBは現在要求されたビデオアリスの2つのストリームを送信することができる - これはメディア3として示されている。
Both sides of the call are now sending multiple video streams with their sources defined via CLUE negotiation. As the call progresses, either side can send a new 'advertisement' or 'configure' message or the new SDP Offers/Answers to add, remove, or change what they have available or want to receive.
コールの両側が現在、Clue Negotiationを介して定義されたそれらのソースで複数のビデオストリームを送信しています。通話が進むにつれて、どちらの側面も、新しい「広告」または「構成」メッセージ、または新しいSDP / Answerが、利用可能なものを追加、削除、または受信したいのかを変更することができます。
In this brief example, Alice is a CLUE-capable Endpoint making a call to Bob, who is not CLUE capable (i.e., is not able to use the CLUE protocol).
この簡単な例では、AliceはBOBへの呼び出しを行う手軽のエンドポイントであり、手ができない（すなわち、手がかりプロトコルを使用することができない）。
+----------+ +-----------+
| Alice | | Bob |
| | | |
+----+-----+ +-----+-----+
| |
| |
| SIP INVITE 1 |
|--------------------------------->|
| |
| |
| 200 0K 1 |
|<---------------------------------|
| |
| |
| SIP ACK 1 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 1 ############>|
| 1 video A->B, 1 video B->A |
|<################################>|
| |
| |
| |
| |
v v
In SIP INVITE 1, Alice sends Bob a SIP INVITE including the basic audio and video capabilities and data channel in the SDP body as per [RFC8841]. Alice also includes the "sip.clue" media feature tag in the INVITE. A snippet of the SDP showing the grouping attribute and the video "m=" line are shown below. Alice has included a "CLUE" group and the mid corresponding to a data channel in the group (3). Note that Alice has chosen not to include any CLUE-controlled media in the initial offer -- the "mid" value of the video line is not included in the "CLUE" group.
SIP INVITE 1では、Aliceは[RFC8841]と同様に、基本的なオーディオとビデオ機能とデータチャネルを含むSIP INVITEをSIP ABITを送信します。Aliceには、INVITE内の「SIP.Clue」メディア機能タグも含まれています。グループ化属性とビデオ "M ="行を示すSDPのスニペットを以下に示します。Aliceには、グループ（3）のデータチャネルに対応する「手がかり」グループとMIDが含まれています。アリスは、最初のオファーで手がかり媒体を含めないように選択したことに注意してください - ビデオ行の「Mid」値は「CLUE」グループに含まれていません。
...
a=group:CLUE 3
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3
Bob is not CLUE capable and hence does not recognize the "CLUE" semantic for the grouping attribute, nor does he support the data channel. IN SIP 200 OK 1, he responds with an answer that includes audio and video, but with the data channel zeroed.
BOBはCLUE対応ではなく、グループ化属性の「手がかり」セマンティックも認識されたり、データチャネルをサポートしたりしません。SIP 200 OK 1では、彼はオーディオとビデオを含むがデータチャネルがゼロになっている答えで反応します。
From the lack of a CLUE group, Alice understands that Bob does not support CLUE, or does not wish to use it. Both sides are now able to send a single audio and video stream to each other. At this point, Alice begins to send her fallback video: in this case, it's likely a switched view from whichever camera shows the current loudest participant on her side.
手がかりグループの欠如から、AliceはBOBが手がかりをサポートしていないか、使用したくないことを理解しています。どちらの側面は現在、単一のオーディオストリームとビデオストリームを互いに送信することができます。この時点で、アリスは彼女のフォールバックビデオを送信し始めます：この場合、どちらのカメラからのカメラが彼女の側に最も大きい参加者を表示するスイッチビューです。
This document registers the following semantics with IANA in the "Semantics for the 'group' SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry) per [RFC5888]:
このドキュメントでは、[RFC5888]ごとに、「グループのSDP属性」サブレジスト（「セッション記述プロトコル（SDP）パラメータ」パラメータの「レジストリ」のセマンティクスにIANAと登録します。
+===========================+=======+==============+===========+
| Semantics | Token | Mux Category | Reference |
+===========================+=======+==============+===========+
| CLUE-controlled "m=" line | CLUE | NORMAL | RFC 8848 |
+---------------------------+-------+--------------+-----------+
Table 1
表1
This specification registers a new media feature tag in the SIP [RFC3261] tree per the procedures defined in [RFC2506] and [RFC3840].
この仕様は、[RFC2506]と[RFC3840]で定義されている手順ごとにSIP [RFC3261]ツリーに新しいメディア機能タグを登録します。
Media feature tag name: sip.clue
メディア機能タグ名：SIP.Clue.
ASN.1 Identifier: 30
ASN.1識別子：30
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports CLUE-controlled media.
このタグで示されるメディア機能の概要：この機能タグは、デバイスがClue制御メディアをサポートすることを示します。
Values appropriate for use with this feature tag: Boolean.
この機能タグでの使用に適した値：Boolean。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device to use the CLUE control protocol to negotiate the use of multiple media streams.
特徴タグは、主に、次のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムで使用するためのものです。この機能タグは、CLUE制御プロトコルを使用して複数の使用をネゴシエートするためのデバイスの機能を説明するための通信アプリケーションで最も役立ちます。メディアストリーム
Related standards or documents: RFC 8848
関連標準または文書：RFC 8848
Security Considerations: Security considerations for this media feature tag are discussed in Section 11 of RFC 8848.
セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項は、RFC 8848のセクション11で説明されています。
Name(s) & email address(es) of person(s) to contact for further
information: Internet Engineering Steering Group <iesg@ietf.org>
Intended usage: COMMON
意図された使用法：一般的な
CLUE makes use of a number of protocols and mechanisms, either defined by CLUE or long-standing. The Security Considerations section of the CLUE Framework document [RFC8845] addresses the need to secure these mechanisms by following the recommendations of the individual protocols.
手がかりは、手がかりまたは長期に定義された、多数のプロトコルとメカニズムを利用します。Clue Frameworkドキュメント[RFC8845]の[セキュリティ上の考慮事項]セクションは、個々のプロトコルの推奨事項に従ってこれらのメカニズムを保護する必要性を求めます。
Beyond the need to secure the constituent protocols, the use of CLUE does impose additional security concerns. One area of increased risk involves the potential for a malicious party to subvert a CLUE-capable device to attack a third party by driving large volumes of media (particularly video) traffic at them by establishing a connection to the CLUE-capable device and directing the media to the victim. While this is a risk for all media devices, a CLUE-capable device may allow the attacker to configure multiple media streams to be sent, significantly increasing the volume of traffic directed at the victim.
構成プロトコルを確保する必要があることを超えて、手がかりの使用は追加のセキュリティ上の懸念を課します。リスクの1つの分野は、悪意のある当事者が手がかり対応の装置への接続を確立し、それらを指示することによって、大量のメディア（特にビデオ）トラフィックを駆動することによって、手当てのある装置が第三者を攻撃する可能性がある。被害者へのメディア。これはすべてのメディアデバイスにとってリスクであるが、攻撃者が攻撃者が送信されるべき複数のメディアストリームを構成し、被害者に向けられたトラフィックの量を大幅に増加させることを可能にし得る。
This attack can be prevented by ensuring that the media recipient intends to receive the media packets. As such, all CLUE-capable devices MUST support key negotiation and receiver intent assurance via DTLS / Secure Real-time Transport Protocol (SRTP) [RFC5763] on CLUE-controlled RTP "m=" lines, and they MUST use it or some other mechanism that provides receiver intent assurance. All CLUE-controlled RTP "m" lines must be secured and implemented using mechanisms such as SRTP [RFC3711]. CLUE implementations MAY choose not to require the use of SRTP to secure legacy (non-CLUE-controlled) media for backwards compatibility with older SIP clients that are incapable of supporting it.
この攻撃は、メディア受信者がメディアパケットを受信しようとしていることを確認することで防ぐことができます。そのため、Clue対応デバイスは、CLUE制御RTP "m ="行のDTLS / Secureリアルタイムトランスポートプロトコル（SRTP）[RFC5763]を介した鍵ネゴシエーションおよび受信機の意図保証をサポートしなければならず、それらはそれを使用する必要があります。受信者の意図保証を提供するメカニズム。すべての手がかりRTP「M」行は、SRTP [RFC3711]などのメカニズムを使用して保護し、実装する必要があります。手がかりの実装は、それをサポートすることができない古いSIPクライアントとの下位互換性のために、従来の（非手立て込み）メディアを保護するためにSRTPの使用を必要とすることを選択できます。
CLUE also defines a new media feature tag that indicates CLUE support. This tag may be present even in non-CLUE calls, which increases the metadata available about the sending device; this can help an attacker differentiate between multiple devices and identify otherwise anonymized users via the fingerprint of features their device supports. To prevent this, SIP signaling used to set up CLUE sessions SHOULD always be encrypted using TLS [RFC5630].
Clueは、Clueサポートを示す新しいメディア機能タグも定義します。このタグは、シーディングデバイスについて利用可能なメタデータを増加させる非手間呼び出しでも存在する場合があります。これは、攻撃者が複数のデバイスを区別するのに役立ち、そのデバイスサポートのフィンガープリントを介して匿名のユーザーを識別するのに役立ちます。これを防ぐために、Clueセッションを設定するために使用されるSIPシグナリングは、常にTLS [RFC5630]を使用して暗号化されるべきです。
The CLUE protocol also carries additional information that could be used to help fingerprint a particular user or to identify the specific version of software being used. The CLUE Framework [RFC8847] provides details about these issues and how to mitigate them.
CLUEプロトコルはまた、特定のユーザを指紋を指紋するため、または使用されている特定のバージョンのソフトウェアを識別するのを助けるために使用され得る追加の情報を担う。CLUE Framework [RFC8847]は、これらの問題に関する詳細とそれらを軽減する方法を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H.、およびP.Kyzivat、「セッション開始プロトコル（SIP）」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<https：// www.rfc-editor.org / info / rfc3840>。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, <https://www.rfc-editor.org/info/rfc4574>.
[RFC4574] Levin、O.およびG. Camarillo、「セッション記述プロトコル（SDP）ラベル属性」、RFC 4574、DOI 10.17487 / RFC4574、2006年8月、<https：//www.rfc-editor.org/info/RFC4574>。
[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, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] FISCHL、J.、TSCHOFENIG、H.、およびE.RESCORLA、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 /を使用したセキュリティコンテキスト（SRTP）セキュリティコンテキストを確立するためのフレームワーク。2010年5月、<https://www.rfc-editor.org/info/rfc5763>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G.およびH.Schulzrinne「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<https：//www.rfc-editor.org/info/RFC5888>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S.、M.Tüxen、「Webrtcデータチャンネル」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https：//www.rfc-editor.org/info/RFC8831>。
[RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport", RFC 8841, DOI 10.17487/RFC8841, January 2021, <https://www.rfc-editor.org/info/rfc8841>.
[RFC8841] Holmberg、C、Shpount、R.、Loreto、S.、およびG. Camarillo、「セッション説明プロトコル（SDP）ストリーム制御伝送プロトコル（SCTP）のための提供/回答手順データグラムトランスポート層セキュリティ（DTLS）輸送、RFC 8841、DOI 10.17487 / RFC8841、2021年1月、<https：//www.rfc-editor.org/info/rfc8841>。
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.
[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル（SDP）」、RFC 8843、DOI 10.17487 / RFC8843、<https：// www。rfc-editor.org/info/rfc8843>。
[RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", RFC 8845, DOI 10.17487/RFC8845, January 2021, <https://www.rfc-editor.org/info/rfc8845>.
[RFC8845]アヒルワース、M。、ED。、Pepperell、A.、およびS.Wenger、 "TelePresence Multi-Streamsのフレームワーク"、RFC 8845、DOI 10.17487 / RFC8845、2021年1月、<https：///www.rfc-editor.org/info/rfc8845>。
[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model", RFC 8846, DOI 10.17487/RFC8846, January 2021, <http://www.rfc-editor.org/info/rfc8846>.
[RFC8846] Presta、R.およびS P. Romano、 "TelePresence（Clue）データモデルのための複数のストリームのためのXMLスキーマ"、RFC 8846、DOI 10.17487 / RFC8846、2021年1月、<http：//ww.rfc-editor.org/info/rfc8846>。
[RFC8847] Presta, R. and S P. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8847, DOI 10.17487/RFC8847, January 2021, <https://www.rfc-editor.org/info/rfc8847>.
[RFC8847] Presta、R.およびS P. Romano、「テレプレゼンスのための複数のストリームを制御するためのプロトコル（CLUE）」、RFC 8847、DOI 10.17487 / RFC8847、2021年1月、<https：//www.rfc-editor.org/情報/ RFC8847>。
[RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021, <https://www.rfc-editor.org/info/rfc8849>.
[RFC8849]偶数、R.およびJ.Lennox、「TelePresence（Clue）メディアキャプチャのための複数のストリームを制御するためのRTPストリームのマッピング」、RFC 8849、DOI 10.17487 / RFC8849、2021年1月、<https：///www.rfc-編集者.ORG / INFO / RFC8849>。
[RFC8850] Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021, <https://www.rfc-editor.org/info/rfc8850>.
[RFC8850] Holmberg、C、「テレプレゼンスのための複数のストリームの制御」、RFC 8850、DOI 10.17487 / RFC8850、1月2021年1月、<https：//www.rfc-editor.org/info/rfc8850>。
[RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>.
[RFC8864]ドラジング、K.、Makaraju、M.、Ejzak、R.、Marcon、J.、およびR.さえ、「セッション記述プロトコルを使用したネゴシエーションデータチャネル（SDP）」、RFC 8864、DOI 10.17487/ RFC8864、2021年1月、<https://www.rfc-editor.org/info/rfc8864>。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, DOI 10.17487/RFC2506, March 1999, <https://www.rfc-editor.org/info/rfc2506>.
[RFC2506] Holtman、K.、Mutz、A.、およびT.硬化、「メディア機能タグ登録手順」、BCP 31、RFC 2506、DOI 10.17487 / RFC2506、1999年3月、<https：///www.rfc-編集者.ORG / INFO / RFC2506>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC3311] Rosenberg、J.、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、DOI 10.17487 / RFC3311、2002年10月、<https：//www.rfc-editor.org/info/rfc3311>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, <https://www.rfc-editor.org/info/rfc5630>.
[RFC5630] Audet、F。、「セッション開始プロトコル（SIP）」、RFC 5630、DOI 10.17487 / RFC5630、2009年10月、<https://ww.rfc-editor.org/情報/ RFC5630>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C、M. Westerlund、 "1つのポート上のRFCのRTPデータとコントロールパケット"、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/info/ RFC5761>。
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <https://www.rfc-editor.org/info/rfc6184>.
[RFC6184] Wang、Y.-K、偶数、R.、Kristensen、T.、およびR.Jesup、RFC 6184、DOI 10.17487 / RFC6184、2011年5月、<HTTPS///www.rfc-editor.org/info/rfc6184>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
Acknowledgements
謝辞
Besides the authors, the team focusing on this document consists of: Roni Even, Simon Pietro Romano, and Roberta Presta.
著者のほかに、この文書に焦点を当てたチームは、Roniさえ、Simon Pietro Romano、およびRoberta Prestaで構成されています。
Christian Groves, Jonathan Lennox, and Adam Roach have contributed detailed comments and suggestions.
クリスチャングローブ、Jonathan Lennox、Adam Roachは詳細なコメントや提案を貢献しました。
Authors' Addresses
著者の住所
Robert Hanton Cisco Systems
ロバートハントンシスコシステムズ
Email: rohanse2@cisco.com
Paul Kyzivat
ポールkyzivat.
Email: pkyzivat@alum.mit.edu
Lennard Xiao Beijing Chuangshiyoulian
Lennard Xiao Beijing Chuangshiyoulian.
Email: lennard.xiao@outlook.com
Christian Groves
クリスチャングローブ
Email: cngroves.std@gmail.com