[要約] RFC 8840は、Trickle ICEのためのSIP使用の標準を定義します。このRFCの目的は、ICEエージェントが通信セッション中に候補を追加できるようにすることです。
Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 8840 Jitsi
Category: Standards Track T. Stach
ISSN: 2070-1721 Unaffiliated
E. Marocco
Telecom Italia
C. Holmberg
Ericsson
January 2021
A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
インタラクティブ接続確立の候補の増分プロビジョニングのためのセッション開始プロトコル（SIP）使用法（トリクル氷）
Abstract
概要
The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
インタラクティブ接続確立（ICE）プロトコルは、オファー/アンサーモデルで確立されたUDPベースのマルチメディアセッションのためのネットワークアドレストランスレータ（NAT）トラバースメカニズムを記述します。候補（トリクル氷）の増分プロビジョニングのための氷伸張は、候補集会および接続性の候補収集および接続性チェックの段階を縮小し、それらを並行して実行することによって、氷エージェントがセッション確立遅延を短縮することを可能にするメカニズムを定義する。
This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.
この文書は、セッション開始プロトコル（SIP）とTrckle Iceの使用状況セマンティクスを定義しています。この文書はまた、この使用法を対応するメディアタイプと一緒にサポートするための新しいSIP Infoパッケージを定義します。さらに、新しいセッション記述プロトコル（SDP）「候補の終了」属性と新しいSIPオプションタグ「TRICKLE-ICE」が定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8840.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc8840で入手できます。
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. Protocol Overview
3.1. Discovery Issues
3.2. Relationship with the Offer/Answer Model
4. Incremental Signaling of ICE Candidates
4.1. Initial Offer/Answer Exchange
4.1.1. Sending the Initial Offer
4.1.2. Receiving the Initial Offer
4.1.3. Sending the Initial Answer
4.1.4. Receiving the Initial Answer
4.2. Subsequent Offer/Answer Exchanges
4.3. Establishing the Dialog
4.3.1. Establishing Dialog State through Reliable Offer/Answer
Delivery
4.3.2. Establishing Dialog State through Unreliable Offer/
Answer Delivery
4.3.3. Initiating Trickle ICE without an SDP Answer
4.4. Delivering Candidates in INFO Requests
5. Initial Discovery of Trickle ICE Support
5.1. Provisioning Support for Trickle ICE
5.2. Trickle ICE Discovery with Globally Routable User Agent
URIs (GRUUs)
5.3. Fall Back to Half Trickle
6. Considerations for RTP and RTCP Multiplexing
7. Considerations for Media Multiplexing
8. SDP "end-of-candidates" Attribute
8.1. Definition
8.2. Offer/Answer Procedures
9. Content Type "application/trickle-ice-sdpfrag"
9.1. Overall Description
9.2. Grammar
10. Info Package
10.1. Rationale -- Why INFO?
10.2. Overall Description
10.3. Applicability
10.4. Info Package Name
10.5. Info Package Parameters
10.6. SIP Option Tags
10.7. INFO Request Body Parts
10.8. Info Package Usage Restrictions
10.9. Rate of INFO Requests
10.10. Info Package Security Considerations
11. Deployment Considerations
12. IANA Considerations
12.1. SDP "end-of-candidates" Attribute
12.2. Media Type "application/trickle-ice-sdpfrag"
12.3. SIP Info Package "trickle-ice"
12.4. SIP Option Tag "trickle-ice"
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Acknowledgements
Authors' Addresses
The Interactive Connectivity Establishment (ICE) protocol [RFC8445] describes a mechanism for Network Address Translator (NAT) traversal that consists of three main phases.
インタラクティブ接続確立（ICE）プロトコル[RFC8445]は、3つのメインフェーズからなるネットワークアドレストランスレータ（NAT）トラバーサルのメカニズムを説明しています。
During the first phase, an agent gathers a set of candidate transport addresses (source IP, port, and transport protocol). This is followed by a second phase where these candidates are sent to a remote agent within the Session Description Protocol (SDP) body of a SIP message. At the remote agent, the gathering procedure is repeated and candidates are sent to the first agent. Once the candidate information is available, a third phase starts in parallel where connectivity between all candidates in both sets is checked (connectivity checks). Once these phases have been completed, and only then, both agents can begin communication.
第1段階では、エージェントは一連の候補転送アドレス（送信元IP、Port、およびTransport Protocol）を収集します。これに続いて、SIPメッセージのセッション記述プロトコル（SDP）本体内でこれらの候補がリモートエージェントに送信される第2のフェーズが続く。リモートエージェントでは、収集手順が繰り返され、候補が最初のエージェントに送信されます。候補情報が利用可能になると、両方のセット内のすべての候補間の接続性がチェックされる（接続性チェック）、第3のフェーズが並行して始まります。これらのフェーズが完成したら、そのときのみ、両方のエージェントが通信を開始できます。
According to [RFC8445], the three phases above happen consecutively, in a blocking way, which can introduce undesirable setup delay during session establishment. The Trickle ICE extension [RFC8838] defines generic semantics required for these ICE phases to happen in a parallel, non-blocking way and hence speeds up session establishment.
[RFC8445]によると、上記の3つのフェーズは、ブロッキングウェイで連続的に起こり、セッション確立中に望ましくない設定遅延を導入することができます。Trickle Ice Extension [RFC8838]は、これらのICEフェーズに必要な一般的な意味論を定義して、並行していない方法で発生し、したがってセッション確立を高速化します。
This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO requests [RFC6086] and how the Half Trickle and Full Trickle modes defined in [RFC8838] are to be used by SIP User Agents (UAs) depending on their expectations for support of Trickle ICE by a remote agent.
この仕様では、セッション開始プロトコル（SIP）[RFC3261]によるトリクル氷の使用法を定義しています。SIP Info Requests [RFC6086]を使用してICE候補を徐々に交換する方法と[RFC8838]で定義されているハーフトリクルモードとフルトリクルモードを、トリクルのサポートに応じてSIPユーザーエージェント（UAS）が使用する方法について説明します。リモートエージェントによる氷。
This document defines a new Info Package as specified in [RFC6086] for use with Trickle ICE together with the corresponding media type, SDP attribute, and SIP option tag.
このドキュメントでは、対応するメディアタイプ、SDP属性、およびSIPオプションタグとともに、Trickle ICEで使用するための[RFC6086]で指定されている新しい情報パッケージを定義します。
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 specification makes use of terminology defined by the ICE protocol in [RFC8445] and by its Trickle ICE extension in [RFC8838]. It is assumed that the reader is familiar with the terminology from both documents.
本明細書は、[RFC8445]のICEプロトコルと[RFC8838]でのトリクルアイスエクステンションによって定義された用語を利用しています。リーダーは両方の文書からの用語に精通していると仮定されています。
[RFC8445] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its extension Traversal Using Relays around NAT (TURN) [RFC5766].
[RFC8445] NAT（STUN）プロトコル[RFC5389]のセッショントラバーサルユーティリティとNAT（ターン）[RFC5766]を使用して、ICE（STUN）プロトコルとその拡張トラバースをどのように使用するかについても説明します。
When using ICE for SIP according to [RFC8839], the ICE candidates are exchanged solely via SDP Offer/Answer as per [RFC3264]. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package [RFC6086]. This also allows ICE candidates to be sent in parallel to an ongoing Offer/Answer negotiation and/or after the completion of the Offer/Answer negotiation.
[RFC8839]に従って氷を使用する場合、ICE候補は[RFC3264]に従ってSDPオファー/回答のみを介して交換されます。この仕様は、SIP情報メッセージと新しく定義された情報パッケージ[RFC6086]を使用して交換できる追加のメカニズムを定義しています。これにより、氷上候補は、継続的な募集/回答交渉および/またはオファー回答交渉の完了後に並行して送信されることを可能にする。
Typically, in cases where Trickle ICE is fully supported, the Offerer sends an INVITE request containing a subset of candidates. Once an early dialog is established, the Offerer can continue sending candidates in INFO requests within that dialog.
典型的には、トリクルアイスが完全にサポートされている場合、オファーは候補のサブセットを含む招待要求を送信する。初期のダイアログが確立されると、オファーはそのダイアログ内の情報要求に候補を送信し続けることができます。
Similarly, an Answerer can send ICE candidates using INFO requests within the dialog established by its 18x provisional response. Figure 1 shows such a sample exchange:
同様に、回答者は、その18Xの暫定的な応答によって確立されたダイアログ内の情報要求を使用してICE候補を送信することができます。図1はそのようなサンプル交換を示しています。
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
| STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp|
| | INFO/OK (Relay Cand.) |<---------------|
| |<------------------------| |
| | | |
| | More Cands & ConnChecks| |
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | ACK | |
| |------------------------>| |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
Note: "SRFLX" denotes server-reflexive candidates
注：「SRFLX」はサーバー再帰候補を表します
Figure 1: Sample Trickle ICE Scenario with SIP
図1：SIPのサンプルトリクルアイスシナリオ
In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a minimum, Trickle ICE Agents need to generate SDP Offers and Answers that contain incomplete and potentially empty sets of candidates. Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before using it.
トリクルなアイスの潜在的な可能性を高め、セッション確立待ち時間を最小限に抑えるためには、トリクルな氷の労働者は、不完全で潜在的に空の候補のセットを含むSDPのオファーと回答を生成する必要があります。そのようなオファーおよび回答は、それを使用する前にそのようなサポートを確認する必要性を意味する、実際には増分候補プロビジョニングをサポートするエージェントによってのみ有意義に処理できます。
Contrary to other protocols, where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (i.e., a combination of UA capabilities [RFC3840] and Globally Routable User Agent URIs (GRUUs) [RFC5627]) have only seen low levels of adoption. This presents an issue for Trickle ICE implementations as SIP UAs do not have an obvious means of verifying that their peer will support incremental candidate provisioning.
「事前に」能力発見が広く実施されている他のプロトコルとは反対に、これを可能にするメカニズム（すなわち、UA機能の組み合わせ[RFC3840]およびグローバルなルーティング可能なユーザエージェントURI（Gruus）[RFC5627]）が見られただけである。低レベルの採用。これは、SIP UASがそれらのピアが増分候補プロビジョニングをサポートすることを確認するための明らかな手段を持っていないので、トリクル氷の実装の問題を提示する。
The Half Trickle mode of operation defined in the Trickle ICE specification [RFC8838] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and using only incremental provisioning of remote candidates for the rest of the session.
Trickle Ice仕様書[RFC8838]で定義されている半トリクル操作モードは、最初のオファーを最初のオファーに、ローカルアイス候補の完全なセットを含み、残りのセッションのための遠隔候補の増分プロビジョニングのみを使用することを要求することによって、これを中心にします。
While using Half Trickle does provide a working solution, it also comes at the price of increased latency. Therefore, Section 5 makes several alternative suggestions that enable SIP UAs to engage in Full Trickle right from their first Offer: Section 5.1 discusses the use of online provisioning as a means of allowing the use of Trickle ICE for all endpoints in controlled environments. Section 5.2 describes anticipatory discovery for implementations that actually do support GRUU and UA capabilities, and Section 5.3 discusses the implementation and use of Half Trickle by SIP UAs where none of the above are an option.
ハーフトリクルを使用している間は、作業解決策を提供している間、それはまた待ち時間の増加の価格になります。したがって、セクション5は、SIP UASが最初のオファーから完全な細流に関わることを可能にするいくつかの代替提案を実行します。セクション5.1は、管理された環境ですべてのエンドポイントのために細流氷の使用を可能にする手段としてのオンラインプロビジョニングの使用について説明します。セクション5.2は、実際にサポートされている実装のための予測発見を説明しており、セクション5.3は上記のどれもオプションなしではないSIP UASによるハーフトリクルの実装と使用について説明しています。
From the perspective of SIP middleboxes and proxies, the Offer/Answer exchange for Trickle ICE looks partly similar to the Offer/Answer exchange for regular ICE for SIP [RFC8839]. However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to be considered as well.
SIPミドルボックスやプロキシの観点から、トリクルアイスのオファー/アンサー交換は、SIPのための通常の氷のためのオファー/アンサー交換と同様に見栄えがよくなります[RFC8839]。ただし、候補交換の全体像を描くためには、新しく導入された情報メッセージも考慮する必要があります。
+-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | |
| +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+
| | | |
| | INVITE (Offer) | |
| |--------------------->| |
| | 183 (Answer) | |
| |<---------------------| |
| | | |
| |
| SIP INFO (more candidates) |
|----------------------------------------------------->|
| SIP INFO (more candidates) |
|<-----------------------------------------------------|
| |
| STUN Binding Requests/Responses |
|----------------------------------------------------->|
| STUN Binding Requests/Responses |
|<-----------------------------------------------------|
| |
Figure 2: Distinguishing between Trickle ICE and Traditional Signaling
図2：細流氷と伝統的なシグナリングを区別する
From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE modules and not between Offer/Answer modules of SIP UAs. Then, such INFO requests do not impact the state of the Offer/Answer transaction other than providing additional candidates. Consequently, INFO requests are not considered Offers or Answers. Nevertheless, candidates that have been exchanged using INFO requests SHALL be included in subsequent Offers or Answers. The version number in the "o=" line of that subsequent Offer needs to be incremented by 1 per the rules in [RFC3264].
図2に表示されるように、建築的な観点から、SIP情報要求を通して候補を交換することは、SIP UASのオファー/回答モジュール間ではない。そして、そのような情報要求は、追加の候補を提供する以外のオファー/アンケート取引の状態に影響を与えない。その結果、情報要求はオファーや回答とは見なされません。それにもかかわらず、情報要求を使用して交換された候補者は、その後のオファーまたは回答に含まれるものとします。その後のオファーの「O =」行のバージョン番号は、[RFC3264]のルールごとに1ずつ増分する必要があります。
Trickle ICE Agents will exchange ICE descriptions compliant to [RFC8838] via Offer/Answer procedures and/or INFO request bodies. This requires the following SIP-specific extensions:
トリクルアイスエージェントは、オファー/アンケート手順や情報要求体を介して[RFC8838]に準拠したICE記述を交換します。これには、次のSIP固有の拡張機能が必要です。
1. Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag "trickle-ice" in a SIP Supported: header field within all SIP INVITE requests and responses.
1. トリクルのアイスエージェントは、SIP Sapedied：HEADERフィールドのSIPオプションタグ「Trickle-Ice」を含めることで、Trickle ICEのサポートを示している必要があります。
2. Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option "trickle" within all SDP Offers and Answers in accordance to [RFC8838].
2. トリクルの氷の代理店は、[RFC8838]に従って、すべてのSDPのオファーと回答の中でアイスオプションの「トリクル」を含めることで、トリクルアイスのサポートを示す必要があります。
3. Trickle ICE Agents MAY include any number of ICE candidates, i.e., from zero to the complete set of candidates, in their initial Offer or Answer. If the complete candidate set is already included in the initial Offer, it is called Half Trickle.
3. トリクルの氷の氷剤は、任意の数の任意の数の候補、すなわち候補者のゼロから完全なセット、その初期のオファーまたは答えにおいて、任意の数の候補者から完全なセットを含み得る。完全な候補セットがすでに最初のオファーに含まれている場合は、半分クチクルと呼ばれます。
4. Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an existing INVITE dialog usage (including an early dialog) as specified in [RFC6086]. The INFO requests carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be prepared to receive INFO requests within that same dialog usage, containing additional candidates and/or an indication that trickling of such candidates has ended.
4. Trckle Iceエージェントは、[RFC6086]で指定されている既存のINVITEダイアログ使用法（初期のダイアログを含む）内の情報要求を使用して追加のICE候補を交換することができます。情報要求は情報パッケージを運びます：トリクル氷。チクリクルのアイスエージェントは、追加の候補者を含む、そのような候補の細流化が終了したという同じダイアログの使用範囲内で情報要求を受けるように準備する必要があります。
5. Trickle ICE Agents MAY exchange additional ICE candidates before the Answerer has sent the Answer provided that an invite dialog usage is established at both Trickle ICE Agents. Note that in case of forking, multiple early dialogs may exist.
5. Trckle Iceエージェントは、答え客が招待状の使用が両方のトリクルアイスエージェントで確立されるという条件で、回答者が答えを送った前に追加のアイス候補を交換することができます。フォークする場合は、複数の初期のダイアログが存在する可能性があります。
The following sections provide further details on how Trickle ICE Agents perform the initial Offer/Answer exchange (Section 4.1), perform subsequent Offer/Answer exchanges (Section 4.2), and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle candidates (Section 4.4).
次のセクションでは、トリクルのアイスエージェントが最初のオファー/アンサー交換（セクション4.1）を実行し、後続のオファー/アンサー交換（セクション4.2）を実行し、incime incremallyトリックを確立するためのInviteダイアログの使用法（セクション4.3）を設定します。候補者（セクション4.4）。
If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [RFC8839].
オファーに初期オファーの候補者が含まれている場合は、[RFC8839]で指定されているようにこれらの候補をエンコードする必要があります。
If the Offerer wants to send its initial Offer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Offerer does not want to include the host IP address in the corresponding "c="line, e.g., due to privacy reasons, it SHOULD include a default address in the "c="line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::.
1つ以上のメディアの説明の候補を知る前に、オファーがその初期オファーを送信したい場合は、これらのメディアの説明についてはポートをデフォルト値 '9'に設定する必要があります。提供者が対応する「C =」行にホストIPアドレスを含めたくない場合、例えばプライバシー上の理由から、IPv4アドレス0.0に設定されている「C =」行のデフォルトアドレスを含める必要があります。.0.0またはIPv6換算::。
In this case, the Offerer obviously cannot know the RTP Control Protocol (RTCP) transport address; thus, it MUST NOT include the "rtcp" attribute [RFC3605]. This avoids potential ICE mismatch (see [RFC8839]) for the RTCP transport address.
この場合、オファーは明らかにRTP制御プロトコル（RTCP）トランスポートアドレスを知ることができません。したがって、 "rtcp"属性[RFC3605]を含めてはいけません。これにより、RTCPトランスポートアドレスの潜在的なアイスミスマッチ（[RFC8839]参照）が回避されます。
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [RFC8858], it still will include the "rtcp-mux" and/or "rctp-mux-only" attribute in the initial Offer.
オファーがRTCP多重化[RFC5761]および/または排他RTCP多重化[RFC8858]を使用したい場合は、初期オファーの「RTCP-MUX」および/または「RCTP-MUX only」属性を依然として含めます。
In any case, the Offerer MUST include the "ice-options:trickle" attribute in accordance to [RFC8838] and MUST include in each "m=" line a "mid" attribute in accordance to [RFC5888]. The "mid" attribute identifies the "m=" line to which a candidate belongs and helps in case of multiple "m=" lines, when candidate gathering could occur in an order different from the order of the "m=" lines.
いずれにせよ、オファーは[RFC8838]に従って「ICEオプション：TRICKLE」属性を含めなければならず、[RFC5888]に従って「MID」属性を各 "属性に含める必要があります。「mid」属性は、候補者が属する「M =」行を識別し、候補収集が「M =」行の順序とは異なる順序で候補的に発生させることができる。
If the initial Offer included candidates, the Answerer uses these candidates to start ICE processing as specified in [RFC8838].
初期オファーに候補者が含まれている場合、回答者はこれらの候補を使用して[RFC8838]に指定されているようにICE処理を開始します。
If the initial Offer included the "ice-options:trickle" attribute, the Answerer MUST be prepared for receiving trickled candidates later on.
初期オファーに「ice-options：trickle」属性が含まれている場合、回答者は後でTRICTLED候補者を受信するために準備する必要があります。
In case of a "m/c=" line with default values, none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [RFC8839]).
デフォルト値を持つ "m / c ="行の場合、最終的にTrickled候補者のどれもデフォルトの宛先と一致しません。この状況はICEの不一致を引き起こしてはいけません（[RFC8839]を参照）。
If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [RFC8839].
回答者が最初の回答に候補者を含む場合は、[RFC8839]に指定されているようにこれらの候補をエンコードする必要があります。
If the Answerer wants to send its initial Answer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Answerer does not want to include the host IP address in the corresponding "c="line, e.g., due to privacy reasons, it SHOULD include a default address in the "c="line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::.
回答者が1つ以上のメディア記述の候補を知る前に最初の回答を送信したい場合は、これらのメディアの説明に対してポートをデフォルト値 '9'に設定する必要があります。回答者が対応する「C =」行にホストIPアドレスを含めたくない場合は、例えばプライバシー上の理由から、IPv4アドレス0.0に設定されている「C =」行のデフォルトアドレスを含める必要があります。.0.0またはIPv6換算::。
In this case, the Answerer obviously cannot know the RTCP transport address; thus, it MUST NOT include the "rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [RFC8839]) for the RTCP transport address.
この場合、回答者は明らかにRTCPトランスポートアドレスを知ることができません。したがって、 "rtcp"属性[RFC6086]を含めてはいけません。これにより、RTCPトランスポートアドレスの潜在的なアイスミスマッチ（[RFC8839]参照）が回避されます。
If the Answerer accepts the use of RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [RFC8858], it will include the "rtcp-mux" attribute in the initial Answer.
回答者がRTCP多重化[RFC5761]および/または排他RTCP多重化[RFC8858]の使用を受け付ける場合は、最初の回答の「rtcp-mux」属性を含みます。
In any case, the Answerer MUST include the "ice-options:trickle" attribute in accordance to [RFC8838] and MUST include in each "m=" line a "mid" attribute in accordance to [RFC5888].
いずれにせよ、「RFC8838」に従って「ICEオプション：TRICKLE」属性を含めなければならず、[RFC5888]に従って「Mid」属性を各 "属性に含める必要があります。
If the initial Answer included candidates, the Offerer uses these candidates to start ICE processing as specified in [RFC8838].
最初の回答に候補者が含まれている場合、オファーは、[RFC8838]で指定されているように、これらの候補を使用してICE処理を開始します。
In case of a "m/c=" line with default values, none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [RFC8839]).
デフォルト値を持つ "m / c ="行の場合、最終的にTrickled候補者のどれもデフォルトの宛先と一致しません。この状況はICEの不一致を引き起こしてはいけません（[RFC8839]を参照）。
Subsequent Offer/Answer exchanges are handled the same as regular ICE (see Section 4.4 of [RFC8839]).
その後のオファー/アンサー交換は、通常の氷と同じです（[RFC8839]のセクション4.4を参照）。
If an Offer or Answer needs to be sent while the ICE Agents are in the middle of trickling, Section 4.4 of [RFC8839] applies. This means that an ICE Agent includes candidate attributes for all local candidates it had trickled previously for a specific media stream.
アイスエージェントがトリクルしている間にオファーまたは回答を送信する必要がある場合は、[RFC8839]のセクション4.4が適用されます。つまり、ICEエージェントは、特定のメディアストリームに対して以前にトリクルされたすべてのローカル候補の候補属性を含むことを意味します。
In order to be able to start trickling, the following two conditions need to be satisfied at the SIP UAs:
細流化を始めることができるようにするには、次の2つの条件をSIP UASで満たす必要があります。
* Trickle ICE support at the peer agent MUST be confirmed.
* ピアエージェントでのトリクルアイスサポートは確認されなければなりません。
* A dialog MUST have been created between the peers.
* ピア間にダイアログが作成されている必要があります。
Section 5 discusses in detail the various options for satisfying the first of the above conditions. However, regardless of those mechanisms, agents are certain to have a clear understanding of whether their peers support trickle ICE once an Offer and an Answer have been exchanged, which also allows for ICE processing to commence (see Figure 3).
セクション5は、上記の条件の最初の条件を満たすための様々なオプションを詳細に説明する。しかしながら、これらのメカニズムに関係なく、エージェントは、オファーと答えが交換された後に彼らのピアがトリクルアイスをサポートしているかどうかを明確に理解しています。
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| PRACK/OK |
|------------------------>|
| |
+----------------------------------------+
|Alice and Bob know that both can trickle|
|and know that the dialog is in the early|
|state. Send INFO! |
+----------------------------------------+
| |
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
Note: "SRFLX" denotes server-reflexive candidates
注：「SRFLX」はサーバー再帰候補を表します
Figure 3: A SIP Offerer can freely trickle as soon as it receives an Answer
図3：SIPオファーは答えを受け取るとすぐに自由に細流化することができます
As shown in Figure 3, satisfying both conditions is relatively trivial for ICE Agents that have sent an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is guaranteed to have confirmed support (or lack thereof) for Trickle ICE at the Answerer and to have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the PRACK request) in the above situation can therefore freely commence trickling within the newly established dialog.
図3に示すように、両方の条件を満たすことは、招待者のオファーを送ったアイスエージェントにとって比較的簡単で、信頼できる暫定的な応答で回答を受け取った。回答者でのトリックルアイスのサポート（またはその欠如）を確認し、両端でSIPダイアログを完全に初期化したことが保証されています。そのため、上記の状況では、提供者と回答者（PRACKリクエストを受け取った後）が、新たに確立されたダイアログ内で自由に細流化することができます。
4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery
4.3.2. 信頼できないオファー/回答配信によるダイアログ状態の確立
The situation is a bit more delicate for agents that have received an Offer in an INVITE request and have sent an Answer in an unreliable provisional response because, once the response has been sent, the Answerer does not know when or if it has been received (Figure 4).
応答が送信されたら、回答者はいつ受信されたかどうかを知らないので、状況は招待要求にオファーを受け取ったエージェントにはもう少し繊細です。図4）。
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| |
| +----------------------+
| |Bob: I don't know if |
| |Alice got my 183 or if|
| |her dialog is already |
| |in the early state. |
| | Can I send INFO??? |
| +----------------------+
| |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received or if the dialog at the side of the Offerer has entered the early state
図4：信頼性の低い暫定的な対応で回答を送信したSIP UAは、受信したかどうか、またはオファー側のダイアログが初期の状態に入った場合にはわかりません。
In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential backoff timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a "trickle-ice" Info Package body, on receipt of any other in-dialog request from the Offerer, or on transmission of the Answer in a 2xx response. The Offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. Using the INFO request for dialog confirmation is similar to the procedure described in Section 7.1.1 of [RFC8839], except that the STUN binding request is replaced by the INFO request.
この曖昧さをできるだけ早くクリアするために、回答者は[RFC3262]に記載されている指数関数的バックオフタイマで暫定応答を再送信する必要があります。これらの再送信は、オファーからの他のダイアログ要求を受け取る、または2xX応答での回答の送信について、「トリクルアイス」情報パッケージパッケージボディを搭載した情報要求の受信を中止しなければなりません。オファーは応答を受信するまでダイアログ内の要求を送信することはできませんので、そのような要求の到着は応答が到着したことを証明します。Info Requestを使用すると、[STUNバインディング要求がINFO要求に置き換えられていることを除いて、[RFC8839]のセクション7.1.1で説明されている手順と同様です。
The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already provided in the Offer (as would be the case when Half Trickle is performed or when new candidates have not been learned since then). The first case could happen when Half Trickle is used and all candidates are already in the initial offer. The second case could happen when Full Trickle is used and the Offerer is currently gathering additional candidates but did not yet get them. Also, if the initial Offer did not contain any candidates, depending on how the Offerer gathers its candidates and how long it takes to do so, this INFO could still contain no candidates.
提供者は、信頼性の低い暫定的な応答でSDPの回答を受信するとすぐにトリクルなICE情報要求を送信する必要があります。この情報要求は、既にオファーで既に提供されていた候補者を繰り返す必要があります（半流が実行された場合、または新しい候補が学ばれていない場合など）。ハーフトリクルが使用され、すべての候補者がすでに初期オファーにあるときに最初のケースが発生する可能性があります。2番目のケースは、完全な細流が使用されており、オファーが現在追加の候補者を集めているが、まだそれらを取得していませんでした。また、オファーがその候補者がどのように候補者を収集するか、そしてそれがどのくらいの期間かかるのかに応じて、最初のオファーに候補者が含まれていない場合は、この情報に依然として候補者が含まれていない可能性があります。
When Full Trickle is used and if newly learned candidates are available, the Offerer SHOULD also deliver these candidates in said INFO request, unless it wants to hold back some candidates in reserve, e.g., in case these candidates are expensive to use and would only be trickled if all other candidates failed.
フルトリクルが使用されている場合、新しく学んだ候補者が利用可能である場合、提供者は、これらの候補者が使用するのに費用がかかり、しか費用がかかる場合に備えていない限り、この候補者はこれらの候補者もこの候補者を予約に保ちたいとしない限り、他のすべての候補者が失敗した場合、TrickLED。
The Offerer SHOULD include an "end-of-candidates" attribute in case candidate discovery has ended in the meantime and no further candidates are to be trickled.
候補者はその間に終了した場合に候補者の発見が終了し、それ以上の候補者が激しくなることになっていない場合、オファーの候補者の属性を含めるべきです。
As soon as an Answerer has received such an INFO request, the Answerer has an indication that a dialog is established at both ends and trickling can begin (Figure 5).
回答者がそのような情報要求を受けたとすぐに、回答者は両端でダイアログが確立されて始めることができるという指示を持っています（図5）。
Note: The "+SRFLX" in Figure 5 indicates that additional newly learned server-reflexive candidates are included.
注：図5の「SRFLX」は、追加の新しく学習されたサーバー再帰候補が含まれていることを示しています。
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
注：「SRFLX」はサーバー再帰候補を表します
Figure 5: A SIP UA that received an INFO request after sending an unreliable provisional response knows that the dialog at the side of the receiver has entered the early state
図5：信頼性の低い暫定的な応答を送信した後に情報要求を受けたSIP UAは、受信者側のダイアログが初期の状態に入ったことを知っています。
When sending the Answer in the 200 OK response to the INVITE request, the Answerer needs to repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response.
招待要求に対する200 OK応答で回答を送信するとき、回答者は、[RFC3264]の対応する要件を満たすために、以前に信頼性の低い暫定的な応答で送信された同じ答えを正確に繰り返す必要があります。したがって、オファーは、細流リッチを介して以前に交換されたよりも繰り返しの答えに異なる数の候補を受信するために準備される必要があり、その200 OK応答の候補情報を無視する必要がある。
The ability to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate trickling without actually sending an Answer. Trickle ICE Agents can therefore respond to an INVITE request with provisional responses without an SDP Answer [RFC3261]. Such provisional responses serve for establishing an early dialog.
情報メッセージ本体に任意の候補者を搬送する能力は、実際に答えを送ることなく氷上剤が細流化を開始することを可能にします。したがって、トリクルの氷の代理店は、SDP回答を使用せずに暫定的な応答を伴う招待要求に応答することができます[RFC3261]。そのような暫定的な回答は、早期のダイアログを確立するために役立ちます。
Agents that choose to establish the dialog in this way MUST retransmit these responses with the exponential backoff timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a "trickle-ice" Info Package body, on receipt of any in-dialog requests from the Offerer, or on transmission of the Answer in a 2xx response. The Offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. This is again similar to the procedure described in Section 6.1.1 of [RFC8839], except that an Answer is not yet provided.
このようにダイアログを確立することを選択するエージェントは、[RFC3262]に記載されている指数バックオフタイマでこれらの応答を再送信する必要があります。これらの再送信は、オファーからのダイアログ内の要求を受け取る、または2xxの応答での答えの送信について、「トリクルアイス」情報パッケージ本体を搭載した情報要求の受信を中止しなければなりません。オファーは応答を受信するまでダイアログ内の要求を送信することはできませんので、そのような要求の到着は応答が到着したことを証明します。回答がまだ提供されていないことを除いて、[RFC8839]の6.1.1項に記載されている手順と同様です。
Note: The "+SRFLX" in Figure 6 indicates that additional newly learned server-reflexive candidates are included.
注：図6の「SRFLX」は、追加の新しく学習されたサーバー再帰候補が含まれていることを示しています。
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know again|
| | that Alice is ready. |
| | Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 183 (Answer) opt. |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
注：「SRFLX」はサーバー再帰候補を表します
Figure 6: A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog
図6：SIP UAは、早期のダイアログを確立するための答えなしで信頼性の低い暫定的な回答を送信します
When sending the Answer, the agent MUST repeat all currently known and used candidates, if any, and MAY include all newly gathered candidates since the last INFO request was sent. However, if that Answer was already sent in an unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response to the INVITE request in order to fulfill the corresponding requirements in [RFC3264]. In case that trickling continued, an Offerer needs to be prepared for receiving fewer candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response.
答えを送信するとき、エージェントは、現在知られていて使用されているすべての候補者を繰り返す必要があり、最後の情報要求が送信されてからすべての新しく収集された候補を含めることができます。ただし、その答えが信頼できない暫定的な応答ですでに送信されている場合、[RFC3264]の対応する要件を満たすために、回答者は200 OKの応答では200 OKの応答では同じ回答を繰り返す必要があります。細流が継続している場合は、繰り返しの答えを繰り返しの候補を受け取るために提供される必要があり、以前の復旧を繰り返し復旧し、その200 OK応答の候補情報を無視する必要があります。
Whenever new ICE candidates become available for sending, agents encode them in "candidate" attributes as described by [RFC8839]. For example:
新しい氷の候補が送信可能になるときはいつでも、エージェントは[RFC8839]によって説明されているように「候補」属性にエンコードします。例えば：
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host
The use of SIP INFO requests happens within the context of the Info Package as defined in Section 10. The media type [RFC6838] for their payload MUST be set to "application/trickle-ice-sdpfrag" as defined in Section 9. The INFO request body adheres to the grammar as specified in Section 9.2.
SIP Info要求の使用は、セクション10で定義されているように情報パッケージのコンテキスト内で発生します。ペイロードのメディアタイプ[RFC6838]は、セクション9で定義されている「アプリケーション/ TRICKLE-ICE-SDPFRAG」に設定する必要があります。セクション9.2で指定されているように、要求本体が文法に付着します。
Since neither the "candidate" nor the "end-of-candidates" attributes contain information that would allow correlating them to a specific "m=" line, it is handled through the use of pseudo "m=" lines.
「候補」や「候補の終わり」属性も含まれていないので、それらを特定の「M =」回線に相関させることができる情報が含まれていないため、疑似「M =」行を使用することによって処理されます。
Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC4566] and are linked to the corresponding "m=" line in the SDP Offer or Answer via the identification tag in a "mid" attribute [RFC5888]. A pseudo "m=" line does not provide semantics other than indicating to which "m=" line a candidate belongs. Consequently, the receiving agent MUST ignore any remaining content of the pseudo "m=" line, which is not defined in this document. This guarantees that the "application/trickle-ice-sdpfrag" bodies do not interfere with the Offer/Answer procedures as specified in [RFC3264].
疑似「M =」行は、[RFC4566]で定義されている「M =」行のSDP構文に従って、「MID」属性の識別タグを介してSDPオファーまたは回答の対応する「M =」回線にリンクされています。RFC5888]。疑似「M =」回線は、候補が属する「M =」行を示す以外の意味論を提供しない。その結果、受信側エージェントは、このドキュメントでは定義されていない疑似 "m ="行の残りの内容を無視する必要があります。これにより、[アプリケーション/ TRICKLE-ICE-SDPFRAG "ボディが[RFC3264]で指定されているオファー/アンサープロシージャーと干渉しないことを保証します。
When sending the INFO request, the agent MAY, if already known to the agent, include the same content into the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer. However, since Trickle ICE might be decoupled from the Offer/Answer negotiation, the content might be unknown to the agent. In this case, the agent MUST include the following default values:
info要求を送信するとき、エージェントは、エージェントに既に知られている場合には、対応するオファーまたは答えの「M =」回線に関して同じコンテンツを疑似「M =」行に含めることができる。しかし、トリクルの氷はオファー/アンケートのネゴシエーションから切り離されている可能性があるため、コンテンツはエージェントに不明である可能性があります。この場合、エージェントには次のデフォルト値を含める必要があります。
* The media field is set to 'audio'.
* メディアフィールドは 'Audio'に設定されています。
* The port value is set to '9'.
* ポート値は '9'に設定されています。
* The proto value is set to 'RTP/AVP'.
* プロト値は 'RTP / AVP'に設定されています。
* The fmt field MUST appear only once and is set to '0'.
* FMTフィールドは一度だけ現れ、 '0'に設定されている必要があります。
Agents MUST include a pseudo "m=" line and an identification tag in a "mid" attribute for every "m=" line whose candidate list they intend to update. Such "mid" attributes MUST immediately precede the list of candidates for that specific "m=" line.
エージェントには、候補リストが更新される予定の候補リストのすべての「M =」行ごとに「Mid」属性に疑似 "m ="行と識別タグを含める必要があります。そのような「MID」属性は、その特定の「m =」行の候補のリストの直前になければなりません。
All "candidate" or "end-of-candidates" attributes following a "mid" attribute, up until (and excluding) the next occurrence of a pseudo "m=" line, pertain to the "m=" line identified by that identification tag.
「Mid」属性に続くすべての「候補者」または「候補の終了」属性は、疑似「M =」行の次の出現を（除外）するまで、その識別によって識別される「M =」行に関連している。鬼ごっこ。
Note, that there is no requirement that the INFO request body contains as many pseudo "m=" lines as the Offer/Answer contains "m=" lines, nor that the pseudo "m=" lines be in the same order as the "m=" lines that they pertain to. The correspondence can be made via the "mid" attributes since candidates are grouped in sections headed by "pseudo" "m=" lines. These sections contain "mid" attribute values that point back to the true "m=" line.
オファー/アンサーに「M =」行が含まれているため、情報要求本文には、疑似「M =」ラインが「M =」回線が含まれているという必要がありません。m = "彼らが属する線。候補が「疑似」「M =」行で頭を標準化するセクションにグループ化されているため、対応は「MID」属性を介して行うことができます。これらのセクションには、True "M ="行を指す "mid"属性値が含まれています。
An "end-of-candidates" attribute, preceding the first pseudo "m=" line, indicates the end of all trickling from that agent, as opposed to end of trickling for a specific "m=" line, which would be indicated by a media-level "end-of-candidates" attribute.
第1の疑似「M =」行の前に先行する「候補の終了」属性は、特定の「M =」行のための細流化の終わりとは対照的に、そのエージェントからのすべての細流の終わりを示す。メディアレベルの「候補の終わり」属性。
Refer to Figure 7 for an example of the INFO request content.
INFOリクエストコンテンツの例については、図7を参照してください。
The use of pseudo "m=" lines allows for a structure similar to the one in SDP Offers and Answers where separate media-level and session-level sections can be distinguished. In the current case, lines preceding the first pseudo "m=" line are considered to be session level. Lines appearing in between or after pseudo "m=" lines will be interpreted as media level.
擬似「M =」線の使用は、SDPのオファーおよび応答との似た構造を別々のメディアレベルとセッションレベルのセクションを区別できるようにすることができます。現在の場合、最初の疑似「M =」行の前の線はセッションレベルと見なされます。疑似「M =」行の間または後に現れる線は、メディアレベルとして解釈されます。
| Note that while this specification uses the "mid" attribute | from [RFC5888], it does not define any grouping semantics.
All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes that allow mapping them to a specific ICE generation. An agent MUST discard any received INFO requests containing "ice-pwd" and "ice-ufrag" attributes that do not match those of the current ICE Negotiation Session.
すべての情報要求は、それらを特定の氷生成にマッピングできるようにする「ICE-PWD」と「ICE-UFRAG」属性を持たなければなりません。エージェントは、現在のICEネゴシエーションセッションと一致しない「ice-pwd」と「ice-ufrag」属性を含む受信した情報要求を廃棄する必要があります。
The "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e., preceding the first pseudo "m=" line. If they were originally exchanged as media-level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines.
「ICE-PWD」と「ICE-UFRAG」属性は、オファー/アンサー交換のものと同じレベルに表示されなければなりません。言い換えれば、それらがセッションレベルの属性として存在した場合、それらはまた、すべての情報要求ペイロード、すなわち第1の疑似「M =」行の前に現れる。もともとそれらがメディアレベルの属性として交換された場合、セッションレベルの値を超えると、対応する疑似 "m ="行に続くInfoリクエストペイロードにも含まれます。
Note that when candidates are trickled, [RFC8838] requires that each candidate must be delivered to the receiving Trickle ICE implementation not more than once and in the same order as it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. This requirement is fulfilled as follows.
候補者が細流化されている場合、[RFC8838]は、各候補が受信したトリクルの氷の実装に複数回、伝達されたのと同じ順序で配信されなければならないことに注意してください。シグナリングプロトコルが候補の再送信を提供する場合、それらはICE実装から隠される必要があります。この要件は次のように達成されます。
Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer, it MUST include all currently known and used local candidates in every INFO request. That is, the agent MUST repeat in the INFO request body all candidates that were previously sent under the same combination of "ice-pwd" and "ice-ufrag" in the same order as they were sent before. In other words, the sequence of a previously sent list of candidates MUST NOT change in subsequent INFO requests, and newly gathered candidates MUST be added at the end of that list. Although repeating all candidates creates some overhead, it also allows easier handling of problems that could arise from unreliable transports like, e.g., loss of messages and reordering, which can be detected through the CSeq: header field in the INFO request.
エージェントはそのピアでのICEネゴシエーションセッションの状態を十分に認識していないので、それはすべての情報要求において現在知られていて使用されているすべてのローカル候補を含めなければなりません。すなわち、エージェントは、以前に送信されたのと同じ順序で、以前に「ICE-PWD」と「ICE-UFRAG」の組み合わせで以前に送信されたすべての候補者で、その他の候補を繰り返す必要があります。言い換えれば、以前に送信された候補リストのシーケンスは後続の情報要求で変更してはならず、新しく収集された候補はそのリストの最後に追加されなければならない。すべての候補者を繰り返すと、何らかのオーバーヘッドが発生しますが、INFOリクエストのCSEQ：ヘッダーフィールドを介して検出できます。
In addition, an ICE Agent needs to adhere to Section 17 of [RFC8838] on preserving candidate order while trickling.
さらに、氷剤は、候補の順序を維持しながら候補の順序を保存する際のセクション17に準拠する必要があります。
When receiving INFO requests carrying any candidates, agents MUST first identify and discard the attribute lines containing candidates they have already received in previous INFO requests or in the Offer/ Answer exchange preceding them.
候補者を運ぶ情報要求を受信すると、エージェントは最初に前の情報要求ですでに受信した候補者を含む属性行を識別して破棄する必要があります。
Such candidates are considered to be equal if their IP address port, transport, and component ID are the same. After identifying and discarding the known candidates, the agents MUST forward the actual new candidates to the ICE Agents in the same order as they were received in the INFO request body. The ICE Agents will then process the new candidates according to the rules described in [RFC8838].
そのような候補は、それらのIPアドレスポート、トランスポート、およびコンポーネントIDが同じであれば等しいと考えられている。既知の候補を識別して廃棄した後、エージェントは、情報要求本文で受信されたのと同じ順序で実際の新しい候補をICEエージェントに転送する必要があります。その後、[RFC8838]に記載されている規則に従って、アイスエージェントは新しい候補を処理します。
Receiving an "end-of-candidates" attribute in an INFO request body -- with the "ice-ufrag" and "ice-pwd" attributes matching the current ICE generation -- is an indication from the peer agent that it will not send any further candidates. When included at the session level, i.e., before any pseudo "m=" line, this indication applies to the whole session; when included at the media level, the indication applies only to the corresponding "m=" line. Handling of such end-of-candidates indications is defined in [RFC8838].
情報要求本文 - 現在のICE生成と一致する「ICE-UFRAG」および「ICE-PWD」属性を持つ「候補の終了」属性を受信します。さらなる候補者。セッションレベルに含まれる場合、すなわち擬似「M =」行前に、この表示はセッション全体に適用される。メディアレベルに含まれるとき、指示は対応する「M =」行にのみ適用されます。そのような候補の終わりの指示の取り扱いは[RFC8838]で定義されています。
The example in Figure 7 shows the content of a candidate delivering INFO request. In the example, the "end-of-candidates" attributes indicate that the candidate gathering is finished and that no further INFO requests follow.
図7の例は、候補情報要求の満足の内容を示しています。この例では、「候補の終了」属性は、候補収集が終了し、それ以上の情報要求が続かないことを示しています。
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 862
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
raddr 192.0.2.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
raddr 192.0.2.1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
raddr 192.0.2.1 rport 9998
a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
raddr 192.0.2.1 rport 9998
a=end-of-candidates
Note: In a real INFO request, there will be no line breaks in the "candidate" attributes
注：本当の情報要求では、「候補」属性に改行はありません。
Figure 7: An Example for the Content of an INFO Request
図7：情報要求の内容の例
SIP UAs are required by [RFC8838] to indicate their support of and intent to use Trickle ICE in their Offers and Answers by using the "ice-options:trickle" attribute, and they MUST include the SIP option-tag "trickle-ice" in a SIP Supported: or Require: header field. This makes discovery fairly straightforward for Answerers or for cases where Offers need to be generated within existing dialogs (i.e., when sending UPDATE or re-INVITE requests). In both scenarios, prior SDP bodies will have provided the necessary information.
SIP UASは[RFC8838]が「ice-options：TRICKLE」属性を使用することで、オファーと回答のサポートと答えを使用することを目的としており、SIPオプションタグ「トリクル氷」を含める必要があります。サポートされているSIPで：または必要：ヘッダーフィールド。これにより、既存のダイアログ内に提供される必要がある場合（すなわち、更新または再招待要求を送信するとき）を提供する必要がある場合には、発見を公正に簡単に発見します。両方のシナリオでは、以前のSDPボディが必要な情報を提供しています。
Obviously, such information is not available at the time a first Offer is being constructed, and it is therefore impossible for ICE Agents to determine support for incremental provisioning that way. The following options are suggested as ways of addressing this issue.
明らかに、このような情報は最初のオファーが構築されている時点では利用できず、したがってICEエージェントがその方法の増分プロビジョニングのためのサポートを決定することは不可能です。次のオプションは、この問題に対処する方法として提案されています。
In certain situations, it may be possible for integrators deploying Trickle ICE to know in advance that some or all endpoints reachable from within the deployment will support Trickle ICE. This is the case, for example, if Session Border Controllers (SBCs) with support for this specification are used to connect to UAs that do not support Trickle ICE.
特定の状況では、展開内から到達可能な一部またはすべてのエンドポイントが細流氷をサポートすることを事前に知るようにトリクル氷を展開する積分器が可能であるかもしれません。これは、たとえば、この仕様のサポートを持つセッションボーダーコントローラ（SBCS）がTRICCLE ICEをサポートしていないUASに接続するために使用される場合です。
While the exact mechanism for allowing such provisioning is out of scope here, this specification encourages trickle ICE implementations to allow the option in the way they find most appropriate.
そのようなプロビジョニングを許可するための正確なメカニズムはここでは範囲外のメカニズムが不足していますが、この仕様はトリクルの氷の実装を最も適切で見つける方法でオプションを許可することを奨励します。
However, an Offerer assuming Trickle ICE support MUST include a SIP Require: trickle-ice header field. That way, if the provisioned assumption of Trickle ICE support ends up being incorrect, the failure is (a) operationally easy to track down and (b) recoverable by the client, i.e., they can resend the request without the SIP Require: header field and without the assumption of Trickle ICE support.
しかし、トリクルの氷のサポートを想定しているオファーは、SIPが必要とする必要があります。トリクルアイスヘッダーフィールド。このように、トリクル氷のサポートのプロビジョニングされた仮定が正しくないと、障害は（a）autalingで追跡が簡単で、（b）クライアントによって回復可能な（b）、すなわちSIPが必要な要求を再送信することができます：ヘッダーフィールドそして細流の氷のサポートの仮定なしに。
5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs)
5.2. グローバルにルーティング可能なユーザーエージェントのURIS（Gruus）を持つトリクルなアイスディスカバリ
[RFC3840] provides a way for SIP UAs to query for support of specific capabilities using, among others, OPTIONS requests. On the other hand, support for GRUU according to [RFC5627] allows SIP requests to be addressed to specific UAs (as opposed to arbitrary instances of an address of record). Combining the two and using the "trickle-ice" option tag defined in Section 10.6 provides SIP UAs with a way of learning the capabilities of specific SIP UA instances and then addressing them directly with INVITE requests that require Trickle ICE support.
[RFC3840]と、とりわけオプション要求を使用して、SIP UASが特定の機能をサポートするための照会方法を提供します。一方、[RFC5627]に準拠したGRUUのサポートにより、SIP要求を特定のUASにアドレス指定することができます（レコードのアドレスの任意のインスタンスとは対照的に）。2つの2つを組み合わせると、セクション10.6で定義されている「Trickle-ICE」オプションタグを組み合わせると、SIP UASを特定のSIP UAインスタンスの機能を学習してから、トリクルなICEサポートを必要とするINVITEリクエストで直接アドレス指定する方法を示します。
Such learning of capabilities may happen in different ways. One option for a SIP UA is to learn the GRUU instance ID of a peer through presence and then to query its capabilities with an OPTIONS request. Alternatively, it can also just send an OPTIONS request to the Address of Record (AOR) it intends to contact and then inspect the returned response(s) for support of both GRUU and Trickle ICE (Figure 8). It is noted that using the GRUU means that the INVITE request can go only to that particular device. This prevents the use of forking for that request.
そのような能力の学習は異なる方法で起こるかもしれません。SIP UAの場合の1つの選択肢は、プレゼンスを通してピアのGRUUインスタンスIDを学習し、次にその機能をオプション要求で照会することです。あるいは、それはまた、それが連絡を取り合うことを意図したアドレス（AOR）にオプション要求を送信することもでき、次にgruuとtrckle iceの両方のサポートのための返された応答を検査することもできます（図8）。GRUUを使用することは、INVITE要求がその特定の装置にのみ行くことができることを意味する。これにより、そのリクエストのためにフォークするのを防ぎます。
Alice Bob
| |
| OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->|
| |
| 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... |
|<--------------------------------------------------|
| |
| INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
| Supported: trickle-ice |
| (Offer) |
|-------------------------------------------------->|
| |
| 183 (Answer) |
|<--------------------------------------------------|
| INFO/OK (Trickling) |
|<------------------------------------------------->|
| |
| ... |
| |
Figure 8: Trickle ICE Support Discovery with OPTIONS and GRUU
図8：オプションとgruuを使ったトリクルアイスサポート発見
Confirming support for Trickle ICE through [RFC3840] gives SIP UAs the option to engage in Full Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they send.
[RFC3840]を介してトリクルアイスのサポートを確認すると、SIP UASが（より長い半細トリクルとは対照的に）完全な細流交渉に参加するオプションを提供します。
In cases where none of the other mechanisms in this section are acceptable, SIP UAs should use the Half Trickle mode defined in [RFC8838]. With Half Trickle, agents initiate sessions the same way they would when using ICE for SIP [RFC8839]. This means that, prior to actually sending an Offer, agents first gather ICE candidates in a blocking way and then send them all in that Offer. The blocking nature of the process implies that some amount of latency will be accumulated, and it is advised that agents try to anticipate it where possible, for example, when user actions indicate a high likelihood for an imminent call (e.g., activity on a keypad or a phone going off hook).
このセクションの他のメカニズムのどれも受け入れられない場合は、SIP UASは[RFC8838]で定義されている半トリクルモードを使用する必要があります。ハーフトリクルで、エージェントはSIPのためにICEを使用するときに同じ方法でセッションを開始します[RFC8839]。つまり、実際にオファーを送信する前に、エージェントは最初に氷の候補者をブロッキング方法で集めてから、そのオファーでそれらをすべて送信します。プロセスのブロッキングの性質は、ある程度の待ち時間が累積されることを意味し、例えばユーザーの行動が差し迫ったコールのための高い可能性を示しているときに可能な限り、エージェントがそれを予測しようとすることを指示します（例：キーパッド上の活動）。または電話をオフにしている電話機
Using Half Trickle results in Offers that are compatible with both ICE SIP endpoints [RFC8839] and legacy endpoints [RFC3264].
ハーフトリクルを使用すると、ICE SIPエンドポイント[RFC8839]とレガシーエンドポイントの両方と互換性のあるオファーがあります[RFC3264]。
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
|<--------------| | |
| | | |
| | | |
| Candidate | | |
| | | |
| | | |
| Discovery | | |
| | | |
| | | |
|-------------->| INVITE (Offer) | |
| |---------------------------->| |
| | 183 (Answer) |-------------->|
| |<----------------------------| |
| | INFO (repeated candidates) | |
| |---------------------------->| |
| | | |
| | INFO (more candidates) | Candidate |
| |<----------------------------| |
| | Connectivity Checks | |
| |<===========================>| Discovery |
| | INFO (more candidates) | |
| |<----------------------------| |
| | Connectivity Checks |<--------------|
| |<===========================>| |
| | | |
| | 200 OK | |
| |<----------------------------| |
| | | |
| |<======= MEDIA FLOWS =======>| |
| | | |
Figure 9: Example of a Typical (Half) Trickle ICE Exchange with SIP
図9：SIPとの典型的な（半分）トリクルの氷交換の例
As a reminder, once a single Offer or Answer has been exchanged within a specific dialog, support for Trickle ICE will have been determined. No further use of Half Trickle will therefore be necessary within that same dialog, and all subsequent exchanges can use the Full Trickle mode of operation.
注意として、一度のオファーまたは答えが特定のダイアログ内で交換されたら、トリクルな氷のサポートが決定されました。したがって、そのままのダイアログ内に半分クロクルの使用は必要ありません。その後のすべての交換は完全なトリクルモードの動作モードを使用できます。
The following consideration describes options for Trickle ICE in order to give some guidance to implementers on how trickling can be optimized with respect to providing RTCP candidates.
以下の考察は、RTCP候補を提供することに関してどのように最適化できるかについての実装者にいくつかのガイダンスを与えるために、トリクル氷のためのオプションを説明する。
Handling of the "rtcp" attribute [RFC3605] and the "rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already considered in Section 5.1.1.1 of [RFC8445] and in [RFC5761]. These considerations are still valid for Trickle ICE; however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.
"RTCP"属性[RFC3605]の処理とRTP / RTCP多重化[RFC5761]の「RFC5761」の「RFC5761」の「RFC8445」および[RFC5761]では、既に検討されています。これらの考慮事項はまだ細流氷に有効です。ただし、TrcklingはRTCP多重化の場合の候補交換のシーケンスにとってより柔軟性を高めます。
If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [RFC8858], the procedures in that document apply for the handling of the "rtcp-mux-only", "rtcp", and "rtcp-mux" attributes.
オファーが[RFC8858]で指定されているRTP / RTCPを排他的にサポートしている場合、その文書内の手順は「RTCP-MUX専用」、「RTCP」、および「RTCP-MUX」属性の処理に適用されます。
While a Half Trickle Offerer has to send an Offer compliant to [RFC8839] and [RFC5761] including candidates for all components, the flexibility of a Full Trickle Offerer allows the sending of only RTP candidates (component 1) in the initial Offer assuming that RTCP multiplexing is supported by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP candidates (component 2) only after having received an indication in the Answer that the Answerer unexpectedly does not support RTCP multiplexing.
ハーフトリクルオファーは、すべてのコンポーネントの候補を含む[RFC8839]と[RFC5761]に準拠したオファーを送信しなければなりませんが、フルトリクルオファーの柔軟性により、RTCPを想定して初期オファーのみのRTP候補のみの送信を可能にします。多重化は回答者によってサポートされています。完全なトリクルオファーは、回答者が突然RTCP多重化をサポートしていないという答えの表示を受け取った後にのみ、RTCP候補（コンポーネント2）の集まりを開始する必要があります。
A Trickle Answerer MAY include an "rtcp-mux" attribute [RFC5761] in the "application/trickle-ice-sdpfrag" body if it supports and uses RTP and RTCP multiplexing. The Trickle Answerer needs to follow the guidance on the usage of the "rtcp" attribute as given in [RFC8839] and [RFC3605]. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information, e.g., for stopping the gathering of RTCP candidates and/ or for freeing corresponding resources.
トリクル回答者は、それがサポートしてRTPおよびRTCP多重化を使用する場合、「rtcp-mux」属性[RFC5761]を含むことができる。トリクルな回答者は、[RFC8839]と[RFC3605]の「RTCP」属性の使用方法に関するガイダンスに従う必要があります。回答の前に情報要求のこの属性にこの属性を受信して、回答者がRTPとRTCP多重化をサポートして使用することを示します。オファーは、この情報を使用することができ、例えばRTCP候補の収集を停止し、および/または対応するリソースを解放するために使用することができる。
This behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing.
この動作は、RTPとRTCP多重化のサポートを示す次のオファーの例で説明されています。
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 5000 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
Once the dialog is established as described in Section 4.3, the Answerer sends the following INFO request.
セクション4.3で説明されているようにダイアログが確立されると、回答者は次の情報要求を送信します。
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 161
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host
This INFO request indicates that the Answerer supports and uses RTP and RTCP multiplexing as well. It allows the Offerer to omit gathering RTCP candidates or releasing already gathered RTCP candidates. If the INFO request did not contain the "rtcp-mux" attribute, the Offerer has to gather RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for RTP and RTCP multiplexing. In case the Offerer already sent RTCP candidates in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even when that support for RTCP multiplexing was confirmed by the Answerer and the Offerer has released its RTCP candidates.
この情報要求は、回答者がRTPとRTCP多重化をサポートして使用することを示しています。それは、オファーがRTCP候補の集まりを省略すること、またはすでにRTCP候補を収集していることを省略することを可能にします。info要求に "rtcp-mux"属性が含まれていない場合、オファーは、最終的にRTPとRTCP多重化のサポートまたはサポートがサポートされていない状態を確認する回答を受信するまで待機した場合を除き、RTCP候補を収集する必要があります。オファーが以前の情報要求でRTCP候補をすでに送信している場合は、RTCP多重化のサポートが回答者によって確認されていて、オファーがRTCP候補をリリースした場合でも、後続のInfo要求でそれらを繰り返す必要があります。
The following considerations describe options for Trickle ICE in order to give some guidance to implementers on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [RFC8843]. It is assumed that the reader is familiar with [RFC8843].
以下の考慮事項は、メディア多重化の場合に候補を提供することに関してどのように最適化することができるかについての実装者にいくつかのガイダンスを与えるために、トリクル氷のためのオプションを説明しています[RFC8843]。リーダーが[RFC8843]に精通していると仮定されています。
ICE candidate exchange is already considered in Section 10 of [RFC8843]. These considerations are still valid for Trickle ICE; however, trickling provides more flexibility for the sequence of candidate exchange, especially in Full Trickle mode.
[RFC8843]の第10章のICE候補交換はすでに検討されています。これらの考慮事項はまだ細流氷に有効です。しかし、細流化は、特にフルトリクルモードで、候補交換のシーケンスの柔軟性をもっと柔軟に提供します。
Except for bundle-only "m=" lines, a Half Trickle Offerer has to send an Offer with candidates for all bundled "m=" lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the "m=" line with the suggested Offerer BUNDLE address.
バンドル専用の「M =」ラインを除いて、半分クリクルオファーは、バンドルされたすべての "M ="行の候補者とオファーを送信しなければなりません。しかしながら、追加の柔軟性は、フルトリクルオファーが最初に「M =」行の候補だけを提案されたオファーバンドルアドレスと共に送信することを可能にする。
On receipt of the Answer, the Offerer will detect if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected. In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle. However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining "m=" lines as necessary. If the Answerer selects an Offerer BUNDLE address that is different from the suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle candidates for the "m=" line that carries the selected Offerer BUNDLE address.
答えを受けて、オファーは、バンドルが回答者によってサポートされているかどうかを検出し、提案されたオファーバンドルアドレスが選択された場合。この場合、オファーは、バンドル内の残りの "M ="行のためにさらに候補をトリクルする必要はありません。ただし、バンドルがサポートされていない場合、フルトリクルオファーは必要に応じて残りの "M ="行の候補を集める必要があります。回答者が提案されたオファーバンドルアドレスとは異なるオファーバンドルアドレスを選択した場合、完全なトリクルオファーは、選択されたオファーバンドルアドレスを搭載した「M =」行の候補を集めて細流化する必要があります。
A Trickle Answerer SHOULD include a "group:BUNDLE" attribute [RFC8843] at session level in the "application/trickle-ice-sdpfrag" body if it supports and uses bundling. When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer.
それがサポートしてバンドリングを使用する場合は、 "group：bundle"属性[rfc8843]を "group：bundle" attribute [rfc8843]を含める必要があります。そうするとき、回答者は、使用されるのと同じ順序ですべての識別タグを含める必要があります。
Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses bundling. The Offerer can use this information, e.g., for stopping the gathering of candidates for the remaining "m=" lines in a bundle and/ or for freeing corresponding resources.
答えの前に情報要求でオファーのこの属性の受信は、回答者がバンドリングをサポートして使用することを示しています。提供者は、この情報を使用することができ、例えば、バンドル内の残りの「M =」線の候補の収集を停止すること、および/または対応するリソースを解放するために使用することができる。
This behavior is illustrated by the following example Offer that indicates support for Media Multiplexing.
この動作は、メディア多重化のサポートを示す次のオファーの例で説明されています。
If the Offerer already sent candidates for "m=" lines in a bundle in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even when that support for bundling was confirmed by the Answerer and the Offerer has released candidates that are no longer needed.
前回の情報要求のバンドル内の「M =」回線の候補者が既に候補者に送信されている場合は、その後の情報要求でそれらを繰り返す必要があります。もはや必要ありません。
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
The example Offer indicates support for RTP and RTCP multiplexing and contains a "candidate" attribute only for the "m=" line with the suggested Offerer BUNDLE address. Once the dialog is established as described in Section 4.3, the Answerer sends the following INFO request.
例のオファーは、RTPとRTCPの多重化のサポートを示し、推奨されるオファーバンドルアドレスを持つ "m ="行のみの "候補"属性を含みます。セクション4.3で説明されているようにダイアログが確立されると、回答者は次の情報要求を送信します。
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 219
a=group:BUNDLE foo bar
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
This INFO request indicates that the Answerer supports and uses Media Multiplexing as well. Note that the Answerer only includes a single pseudo "m=" line since candidates matching those from the second "m=" line in the offer are not needed from the Answerer.
この情報要求は、回答者がメディア多重化をサポートして使用することを示しています。また、オファー内の第2の「M =」回線からの候補と一致する候補は、回答者から必要とされないので、回答者は単一の疑似「M =」回線のみを含むことに留意されたい。
The INFO request also indicates that the Answerer accepted the suggested Offerer BUNDLE address. This allows the Offerer to omit gathering RTP and RTCP candidates for the other "m=" lines or releasing already gathered candidates. If the INFO request did not contain the "group:BUNDLE" attribute, the Offerer has to gather RTP and RTCP candidates for the other "m=" lines unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for Media Multiplexing.
情報要求はまた、回答者が提案されたオファーバンドルアドレスを受け入れたことを示しています。これにより、オファーは、他の「M =」回線のRTPおよびRTCP候補を収集することも、すでに収集されている候補を解放することを省略することができます。情報要求に "group：bundle"属性が含まれていない場合、オファーは、最終的にサポートまたは非サポートを確認する回答を受信するまで待機した場合を除き、他の "m ="行のRTPとRTCP候補を収集する必要があります。メディア多重化のために。
Independent of using Full Trickle or Half Trickle mode, the rules from [RFC8859] apply to both, Offerer and Answerer, when putting attributes as specified in Section 9.2 in the "application/trickle-ice-sdpfrag" body.
フルトリクルまたはハーフトリクルモードの使用とは無関係に、[RFC8859]からのルールは、「アプリケーション/ Trickle-Ice-SDPFrag」ボディでセクション9.2で指定されている属性を設定するときに、Profiewer、およびDevererの両方に適用されます。
This section defines the new SDP media-level and session-level [RFC4566] "end-of-candidates" attribute. "end-of-candidates" is a property attribute [RFC4566]; hence, it has no value. By including this attribute in an Offer or Answer, the sending agent indicates that it will not trickle further candidates. When included at the session level, this indication applies to the whole session; when included at the media level, the indication applies only to the corresponding media description.
このセクションでは、新しいSDPメディアレベルとセッションレベル[RFC4566]「候補の終了」属性を定義します。「候補の終了」はプロパティ属性[RFC4566]です。したがって、価値はありません。この属性をオファーまたは答えに含めることで、送信元エージェントはそれがさらなる候補をトリクルしないことを示します。セッションレベルに含まれる場合、この表示はセッション全体に適用されます。メディアレベルに含まれる場合、指示は対応するメディア記述にのみ適用されます。
Name: end-of-candidates
名前：候補者の終わり
Value: N/A
値：N / A.
Usage Level: media and session level
使用量レベル：メディアとセッションレベル
Charset Dependent: no
文字セットに依存する：いいえ
Mux Category: IDENTICAL
MUXカテゴリ：同一です
Example: a=end-of-candidates
例：a =候補者の終わり
The Offerer or Answerer MAY include an "end-of-candidates" attribute in case candidate discovery has ended and no further candidates are to be trickled. The Offerer or Answerer MUST provide the "end-of-candidates" attribute together with the "ice-ufrag" and "ice-pwd" attributes of the current ICE generation as required by [RFC8838]. When included at the session level, this indication applies to the whole session; when included at the media level, the indication applies only to the corresponding media description.
オファーまたは回答者は、候補発見が終了し、それ以上の候補者が著しく把握されない場合に備えて「候補終了」属性を含み得る。オファーまたは回答者は、[RFC8838]で要求される現在のICE世代の「ICE-UFRAG」および「ICE-PWD」属性とともに「候補者の終了」属性を提供する必要があります。セッションレベルに含まれる場合、この表示はセッション全体に適用されます。メディアレベルに含まれる場合、指示は対応するメディア記述にのみ適用されます。
Receipt of an "end-of-candidates" attribute at an Offerer or Answerer -- with the "ice-ufrag" and "ice-pwd" attributes matching the current ICE generation -- indicates that the gathering of candidates has ended at the peer, for either the session or only the corresponding media description as specified above. The receiving agent forwards an end-of-candidates indication to the ICE Agent, which in turn acts as specified in [RFC8838].
「ICE-UFRAG」および「ICE-PWD」の属性が現在の氷生成に一致する「候補者または回答者」の「候補者の終了」属性を受信する - 現在の氷生成に一致する「ICE-UFRAG」属性を持つ - 候補者の収集がピアで終了したことを示します。上記のセッションまたは対応するメディアの説明のみの場合。受信エージェントは、候補の終わりの指示をICEエージェントに転送します。これは次に[RFC8838]で指定されているとおりに機能します。
An "application/trickle-ice-sdpfrag" body is used exclusively by the "trickle-ice" Info Package. Other SDP-related applications need to define their own media type. The INFO request body uses a subset of the possible SDP lines as defined by the grammar in [RFC4566]. A valid body uses only pseudo "m=" lines and certain attributes that are needed and/or useful for trickling candidates. The content adheres to the following grammar.
「Application / Trickle-Ice-SDPFrag」本体は、「トリクルアイス」情報パッケージによって排他的に使用されています。他のSDP関連のアプリケーションは、独自のメディアタイプを定義する必要があります。情報要求本文は、[RFC4566]の文法によって定義された可能性のあるSDP行のサブセットを使用します。有効な本体は、疑似「M =」線と細流の候補に必要および/または有用な特定の属性のみを使用します。コンテンツは次の文法に準拠しています。
The grammar of an "application/trickle-ice-sdpfrag" body is based on the following ABNF [RFC5234]. It specifies the subset of existing SDP attributes that is needed or useful for trickling candidates. The grammar uses the indicator for case-sensitive %s, as defined in [RFC7405], but it also imports grammar for other SDP attributes that precede the production of [RFC7405]. A sender SHOULD use lower case for attributes from such earlier grammar, but a receiver MUST treat them as case insensitive.
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = *(session-level-field CRLF)
session-level-field = ice-lite-attribute / ice-pwd-attribute / ice-ufrag-attribute / ice-options-attribute / ice-pacing-attribute / end-of-candidates-attribute / bundle-group-attribute / extension-attribute-fields ; for future extensions
セッションレベルフィールド= ICE-LITE - 属性/ ICE-PWD-attribute / ICE-UFRAG-属性/ ice-options-attribute / ice-pacing-attribute / and-of-and-of-of-of-of-of-of-of-of-of-of-of-of-of-attributes-属性/ bundle-group-属性/拡張属性 - フィールド将来の拡張のために
ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options
end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = %s"end-of-candidates"
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields )
trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
trickle-ice-attribute-field = mid-attribute /
candidate-attributes /
ice-pwd-attribute /
ice-ufrag-attribute /
remote-candidate-attribute /
end-of-candidates-attribute /
rtcp-attribute /
rtcp-mux-attribute /
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp"
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
candidate-attributes = %s"a" "=" candidate-attribute
remote-candidate-attribute = %s"a" "=" remote-candidate-att
ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate-attribute, and remote-candidate-att are from [RFC8839]; identification-tag and mid-attribute are from [RFC5888]; and media-field and attribute-fields are from [RFC4566]. The "rtcp" attribute is defined in [RFC3605], the "rtcp-mux" attribute is defined in [RFC5761], and the "rtcp-mux-only" attribute is defined in [RFC8858]. The latter attributes lack formal grammar in their corresponding RFCs and are reproduced here.
アイスライト、ICE-PWD-ATT、リモート候補ATT、ICE-UFRAG-ATT、ICEPACING-ATT、ICEオプション、候補属性、およびリモート候補att; [RFC8839]。識別タグとmid-属性は[RFC5888]からです。そして、メディアフィールドと属性フィールドは[RFC4566]からのものです。"rtcp"属性は[RFC3605]で定義されていますが、[RFC5761]で "rtcp-mux"属性が定義され、 "RFC8858]で" rtcp-mux-only "属性が定義されています。後者の属性は、対応するRFCに正式な文法を欠いており、ここで再現されています。
The "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e., preceding all pseudo "m=" lines. If they were originally exchanged as media-level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines.
「ICE-PWD」と「ICE-UFRAG」属性は、オファー/アンサー交換のものと同じレベルに表示されなければなりません。言い換えれば、それらがセッションレベルの属性として存在していた場合、それらはまた、すべての疑似値のペイロード、すなわちすべての疑似「M =」行の先頭にも現れる。もともとそれらがメディアレベルの属性として交換された場合、セッションレベルの値を超えると、対応する疑似 "m ="行に続くInfoリクエストペイロードにも含まれます。
An Agent MUST ignore any received unknown extension-attribute-fields.
エージェントは、受信した未知の拡張属性フィールドを無視する必要があります。
The decision to use SIP INFO requests as a candidate transport method is based primarily on their lightweight nature. Once a dialog has been established, INFO requests can be exchanged both ways with no restrictions on timing and frequency and no risk of collision.
SIP INFO要求を候補転送方式として使用するという決定は、主に軽量の性質に基づいています。ダイアログが確立されると、情報要求はタイミングと頻度と衝突の危険性がないと両方の方法で交換できます。
A critical fact is that the sending of Trickle ICE candidates in one direction is entirely uncoupled from sending candidates in the other direction. Thus, the sending of candidates in each direction can be done by a stream of INFO requests that is not correlated with the stream of INFO requests in the other direction. And since each INFO request cumulatively includes the contents of all previous INFO requests in that direction, the ordering between INFO requests need not be preserved. All of this permits using largely independent INFO requests.
具体的な事実は、一方向への細流氷候補の送付が完全に他の方向に候補を送ることから始められていることである。したがって、各方向の候補の送信は、他の方向の情報要求のストリームと相関しない情報要求のストリームによって行うことができる。また、各情報要求は累積的にその方向にすべての前の情報要求の内容を含んでいるため、情報要求間の順序は保存される必要はありません。これはすべて、主に独立した情報要求を使用して許可されています。
Contrarily, UPDATE or other Offer/Answer mechanisms assume that the messages in each direction are tightly coupled with messages in the other direction. Using Offer/Answer and UPDATE requests [RFC3311] would introduce the following complications:
反対に、更新または他のオファー/回答メカニズムは、各方向のメッセージが他の方向のメッセージと密接に結合されていると仮定します。申し出/回答および更新要求を使用する[RFC3311]は、以下の合併症を紹介します。
Blocking of messages: Offer/Answer is defined as a strictly sequential mechanism in [RFC3264]. There can only be a maximum of one active exchange at any point of time. Both sides cannot simultaneously send Offers nor can they generate multiple Offers prior to receiving an Answer. Using UPDATE requests for candidate transport would therefore imply the implementation of a candidate pool at every agent where candidates can be stored until it is once again that agent's "turn" to emit an Answer or a new Offer. Such an approach would introduce non-negligible complexity for no additional value.
メッセージのブロック：オファー/回答は[RFC3264]の厳密に順次メカニズムとして定義されています。任意の時点では最大1つの有効交換しかありません。両側は同時にオファーを送信することも、答えを受け取る前に複数のオファーを生成することもできません。したがって、候補転送のための更新要求を使用すると、候補者が再び保存される可能性があるすべてのエージェントでの候補プールの実装は、そのエージェントの「ターン」が答えまたは新しいオファーを発行することができるようになるまでを意味するでしょう。そのようなアプローチは、追加の値を含まない無視できる複雑さを導入するでしょう。
Elevated risk of glare: The sequential nature of Offer/Answer also makes it impossible for both sides to send Offers simultaneously. What's worse is that there are no mechanisms in SIP to actually prevent that. [RFC3261], where the situation of Offers crossing on the wire is described as "glare", only defines a procedure for addressing the issue after it has occurred. According to that procedure, both Offers are invalidated and both sides need to retry the negotiation after a period between 0 and 4 seconds. The high likelihood for glare and the average two-second backoff intervals to occur implies that the duration of Trickle ICE processing would not only fail to improve but actually exceed those of regular ICE.
グレアのリスクを高める：募集/回答の順次の性質もまた、両側がオファーを同時に送ることを不可能にします。さらに悪いことは、実際にそれを防ぐためにSIPにメカニズムがないということです。[RFC3261]、ワイヤーの交差点が「GLARE」として説明されている場合は、発生した後に問題を解決するための手順のみを定義してください。その手順によると、両方のオファーが無効化され、両側は0から4秒の間の期間の後にネゴシエーションを再試行する必要があります。グレアのための高い尤度および発生する平均2秒のバックオフ間隔は、トリクルアイス加工の持続時間が改善することができないが実際には通常の氷のものを超えることであることを意味する。
INFO messages decouple the exchange of candidates from the Offer/ Answer negotiation and are subject to none of the glare issues described above, which makes them a very convenient and lightweight mechanism for asynchronous delivery of candidates.
情報メッセージ候補者の交換を募集/回答交渉から切り離し、上記のglareの問題の対象となり、候補者の非同期配達のための非常に便利で軽量のメカニズムになります。
Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered end to end, between the same entities that are actually in the process of initiating a session. Out-of-dialog alternatives would have implied requiring support for GRUU [RFC5627] that, given GRUUs relatively low adoption levels, would have constituted too strong of a constraint to the adoption of Trickle ICE.
ダイアログ内情報メッセージを使用すると、セッションを開始するプロセスにある同じエンティティの間で、候補が終了することが終了することを保証する方法も提供します。ダイアログ外の選択肢は、Gruu [RFC5627]が比較的低い採用レベルを考えると、トリクル氷の採用に対する制約の強力な強すぎることを強化したであろう。
This specification defines an Info Package for use by SIP UAs implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer UAs have confirmed mutual support for Trickle ICE.
この仕様は、Trickle Iceを実装するSIP UASが使用するための情報パッケージを定義しています。InfoリクエストピアUASがトリクル氷の相互支援を確認した後に発見されたICE候補を運びます。
The purpose of the ICE protocol is to establish a media path in the presence of NAT and firewalls. The candidates are transported in INFO requests and are part of this establishment.
ICEプロトコルの目的は、NATおよびファイアウォールの存在下でメディアパスを確立することです。候補者は情報要求で輸送され、この設立の一部です。
Candidates sent by a Trickle ICE Agent after the Offer follow the same signaling path and reach the same entity as the Offer itself. While it is true that GRUUs can be used to achieve this, one of the goals of this specification is to allow operation of Trickle ICE in as many environments as possible including those without GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy this goal.
オファーの後にトリクルアイスエージェントによって送信された候補者は、同じシグナリングパスに従い、オファー自体と同じエンティティに到達します。これを達成するためにGruusを使用することができるのは当てはまりますが、この仕様の目標の1つは、GRUUサポートなしのものを含む可能な限り多くの環境でトリクルアイスの操作を可能にすることです。ダイアログ外付けの購読/ NOTIFY要求を使用すると、この目標が満たされません。
This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this package is "trickle-ice".
このドキュメントは[RFC6086]のようにSIP Infoパッケージを定義します。このパッケージの情報パッケージのトークン名は「トリクル氷」です。
This document does not define any Info Package parameters.
この文書は、情報パッケージのパラメータを定義しません。
[RFC6086] allows Info Package specifications to define SIP option-tags. This specification extends the option-tag construct of the SIP grammar as follows:
[RFC6086] infoパッケージの仕様にSIPオプションタグを定義できます。この仕様は、次のようにSIP文法のoption-tag構文を拡張します。
option-tag /= "trickle-ice"
オプションタグ/ =「トリクル氷」
SIP entities that support this specification MUST place the "trickle-ice" option-tag in a SIP Supported: or Require: header field within all SIP INVITE requests and responses.
この仕様をサポートするSIPエンティティは、SIPの "TRICKLE-ICE"オプションタグをSIPにサポートされています。またはすべてのSIP INVITE要求と応答内のヘッダーフィールド。
When responding to, or generating, a SIP OPTIONS request, a SIP entity MUST also include the "trickle-ice" option-tag in a SIP Supported: or Require: header field.
SIPオプション要求に応答する、または生成、生成、SIPエンティティには、SIPサポートされているSIPの「TRICKLE-ICE」オプションタグも含める必要があります。
Entities implementing this specification MUST include a payload of type "application/trickle-ice-sdpfrag" in SIP INFO requests as defined in Section 9.2. The payload is used to convey SDP-encoded ICE candidates.
この仕様を実装するエンティティは、セクション9.2で定義されているSIP Info要求では、「Application / Trickle-ICE-SDPFRAG」のペイロードを含める必要があります。ペイロードはSDPエンコードされた氷候補を伝えるために使用されます。
This document does not define any Info Package Usage Restrictions.
この文書では、情報パッケージの使用制限の制限を定義していません。
Given that IP addresses may be gathered rapidly, a Trickle ICE Agent with many network interfaces might create a high rate of INFO requests if every newly detected candidate is trickled individually without aggregation. An implementation MUST aggregate ICE candidates in case an unreliable transport protocol such as UDP is used. A Trickle ICE Agent MUST NOT have more than one INFO request pending at any one time. When INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in [RFC3261], Section 17.1.2.1.
IPアドレスが迅速に収集される可能性があることを考えると、新たに検出された候補が集約なしに個別に細かく解消される場合、多くのネットワークインターフェースを持つトリクルアイスエージェントが高い情報要求を作成する可能性があります。UDPなどの信頼性の低いトランスポートプロトコルが使用されている場合、実装はICE候補を集約しなければなりません。トリクルアイスエージェントには、一度に保留中の1つ以上の情報要求が保留されてはいけません。情報メッセージが信頼できないトランスポートで送信されると、[RFC3261]で指定された規則に従って再送信されます。
If the INFO requests are sent on top of TCP, which is probably the standard way, it is not an issue for the network anymore, but it can remain one for SIP proxies and other intermediaries forwarding the SIP INFO messages. Also, an endpoint may not be able to tell that it has congestion controlled transport all the way.
情報要求がTCPの上に送信されます。また、エンドポイントは、それが輻輳制御された輸送を常に輸送していることを伝えることができないかもしれません。
See Section 13.
13節を参照してください。
Trickle ICE uses two mechanisms for the exchange of candidate information. This imposes new requirements to certain middleboxes that are used in some networks, e.g., for monitoring purposes. While the first mechanism, SDP Offers and Answers, is already used by regular ICE and is assumed to be supported, the second mechanism, INFO request bodies, needs to be considered by such middleboxes as well when trickle ICE is used. Such middleboxes need to make sure that they remain in the signaling path of the INFO requests and understand the INFO request body.
Trckle Iceは候補情報の交換に2つのメカニズムを使用します。これは、例えば監視目的のために、いくつかのネットワークで使用される特定のミドルボックスに新しい要件を課します。最初のメカニズム、SDPの提供および回答は、すでに通常の氷で使用されており、サポートされていると仮定されていると仮定されていると仮定されています。そのようなミドルボックスは、それらが情報要求のシグナリング経路に残ることを確認し、情報要求本文を理解する必要があります。
This section defines a new SDP media-level and session-level [RFC4566] "end-of-candidates" attribute, which is a property attribute [RFC4566] and hence has no value.
このセクションでは、新しいSDPメディアレベルとセッションレベル[RFC4566]「候補の終了」属性[RFC4566]で、したがって値がありません。
Name: end-of-candidates
名前：候補者の終わり
Value: N/A
値：N / A.
Usage Level: media and session
使用量レベル：メディアとセッション
Charset Dependent: no
文字セットに依存する：いいえ
Purpose: The sender indicates that it will not trickle further ICE candidates.
目的：送信者はそれがさらなる氷の候補を細くしないことを示しています。
O/A Procedures: RFC 8840 defines the detailed SDP Offer/Answer procedures for the "end-of-candidates" attribute.
O / A手順：RFC 8840は、「候補の終了」属性の詳細なSDPオファー/回答手順を定義しています。
Mux Category: IDENTICAL
MUXカテゴリ：同一です
Reference: RFC 8840
参照：RFC 8840
Example: a=end-of-candidates
例：a =候補者の終わり
This document defines the new media type "application/trickle-ice-sdpfrag" in accordance with [RFC6838].
このドキュメントは、[RFC6838]に従って、新しいメディアタイプ「アプリケーション/ TRICKLE-ICE-SDPFRAG」を定義します。
Type name: application
タイプ名：アプリケーション
Subtype name: trickle-ice-sdpfrag
サブタイプ名：TRICKLE-ICE-SDPFRAG
Required parameters: None.
必要なパラメータ：なし。
Optional parameters: None.
オプションのパラメータ：なし。
Encoding considerations: The media contents follow the same rules as SDP, except as noted in this document. The media contents are text, with the grammar specified in Section 9.2.
エンコードに関する考慮事項：メディアの内容は、この文書に記載されている場合を除き、SDPと同じ規則に従います。メディアコンテンツはテキストで、文法はセクション9.2で指定されています。
Although the initially defined content of a trickle-ice-sdpfrag body does only include ASCII characters, UTF-8-encoded content might be introduced via extension attributes. The "charset" attribute may be used to signal the presence of other character sets in certain parts of a trickle-ice-sdpfrag body (see [RFC4566]). Arbitrary binary content cannot be directly represented in SDP or a trickle-ice-sdpfrag body.
TRICKLE-ICE-SDPFRAG本体の最初に定義されている内容には、ASCII文字のみが含まれていますが、UTF-8エンコードコンテンツは拡張属性を介して導入される可能性があります。"charset"属性は、トリクル氷-SDPFrag本体の特定の部分で他の文字セットの存在を知らせるために使用されます（[RFC4566]参照）。任意のバイナリコンテンツを直接SDPまたはTrickle-Ice-SDPFrag本体に表現することはできません。
Security considerations: See [RFC4566] and RFC 8840
セキュリティ上の考慮事項：[RFC4566]とRFC 8840を参照
Interoperability considerations: See RFC 8840
相互運用性の考慮事項：RFC 8840を参照してください
Published specification: See RFC 8840
公開仕様：RFC 8840を参照
Applications that use this media type: Trickle ICE
このメディアタイプを使用するアプリケーション：Trincle Ice
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information:
追加情報：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A
Person and email address to contact for further information: The IESG (iesg@ietf.org)
さらなる情報について連絡する人と電子メールアドレス：IESG（iesg@ietf.org）
Intended usage: Trickle ICE for SIP as specified in RFC 8840.
意図された用途：RFC 8840で指定されているSIPのためのトリクル氷。
Restrictions on usage: N/A
使用制限：N / A.
Author/Change controller: The IESG (iesg@ietf.org)
Provisional registration? (standards tree only): N/A
暫定登録？（標準ツリーのみ）：N / A.
This document defines a new SIP Info Package named "trickle-ice" and updates the "Info Packages Registry" with the following entry.
このドキュメントでは、「Trickle-Ice」という名前の新しいSIP Infoパッケージを定義し、次のエントリで「Info Packagesレジストリ」を更新します。
+=============+===========+
| Name | Reference |
+=============+===========+
| trickle-ice | RFC 8840 |
+-------------+-----------+
Table 1
表1
This specification registers a new SIP option tag "trickle-ice" as per the guidelines in Section 27.1 of [RFC3261] and updates the "Option Tags" subregistry of the SIP Parameters registry with the following entry:
この仕様は、[RFC3261]の27.1項のガイドラインに従って、新しいSIPオプションタグ「Trickle-ICE」を登録し、次のエントリを使用してSIPパラメータレジストリの「オプションタグ」サブレイストリを更新します。
+=============+==============================+===========+
| Name | Description | Reference |
+=============+==============================+===========+
| trickle-ice | This option tag is used to | RFC 8840 |
| | indicate that a UA supports | |
| | and understands Trickle ICE. | |
+-------------+------------------------------+-----------+
Table 2
表2.
The Security Considerations of [RFC6086], [RFC8838], and [RFC8839] apply. This document clarifies how the above specifications are used together for trickling candidates and does not create additional security risks.
[RFC6086]、[RFC8838]、[RFC8839]のセキュリティ上の考慮事項が適用されます。この文書では、上記の仕様を細流候補のために一緒に使用し、追加のセキュリティリスクを作成しない方法を明確にします。
The new Info Package "trickle-ice" and the new media type "application/trickle-ice-sdpfrag" do not introduce additional security considerations when used in the context of Trickle ICE. Both are not intended to be used for other applications, so any security considerations for its use in other contexts is out of the scope of this document
新しい情報パッケージ「TRICKLE-ICE」と新しいメディアタイプ「アプリケーション/ TRICKLE-ICE-SDPFRAG」は、トリクルアイスの文脈で使用されている場合は、追加のセキュリティ上の考慮事項を導入しません。どちらも他のアプリケーションに使用されることを意図していませんので、他のコンテキストでの使用に関するセキュリティ上の考慮事項はこの文書の範囲外です。
[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>。
[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>。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, <https://www.rfc-editor.org/info/rfc3262>.
[RFC3262] Rosenberg、J.およびH.Schulzrinne、「セッション開始プロトコル（SIP）」、RFC 3262、DOI 10.17487 / RFC3262、2002年6月、<https：//ww.rfc-editor.org/情報/ RFC3262>。
[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>。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-editor.org/info/rfc3605>.
[RFC3605] HUITEMA、C、「リアルタイム制御プロトコル（SDP）」（SDP） "、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<https://ww.rfc-editor.org/情報/ RFC3605>。
[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>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[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>。
[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>。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, <https://www.rfc-editor.org/info/rfc6086>.
[RFC6086] Holmberg、C、Burger、E.、およびH。Kaplan、「セッション開始プロトコル（SIP）情報方法およびパッケージフレームワーク」、RFC 6086、DOI 10.17487 / RFC6086、2011年1月、<https：// www。rfc-editor.org/info/rfc6086>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] KYZIVAT、P.、「ABNFの大文字と小文字の区別文字列サポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https：//www.rfc-editor.org/info/rfc7405>。
[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>。
[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>。
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, <https://www.rfc-editor.org/info/rfc8838>.
[RFC8838] IVOV、E.、Uberti、J.、およびP.Saint-Andre、「トリクルアイス：インタラクティブ接続確立の候補（ICE）プロトコルの候補の増分プロビジョニング」、RFC 8838、DOI 10.17487 / RFC8838、2021年1月、<https://www.rfc-editor.org/info/rfc8838>。
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8839] Petit-Huguenin、M.、Nandakumar、S.、Holmberg、C.、Keränen、A.、R. Shpount、「セッション説明プロトコル（SDP）オファー/回答手順インタラクティブ接続確立（ICE）」RFC 8839、DOI 10.17487 / RFC8839、2021年1月、<https：//www.rfc-editor.org/info/rfc8839>。
[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>。
[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021, <https://www.rfc-editor.org/info/rfc8858>.
[RFC8858] Holmberg、C、「RTPとRTP制御プロトコルの排他的サポートとRTP）多重化（SDP） "、RFC 8858、DOI 10.17487 / RFC8858、2021年1月、<https：// www。rfc-editor.org/info/rfc8858>。
[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https：//www.rfc-editor.org/info/rfc8859>。
[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>。
[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>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P.、およびD. Wing、「Stun（Stun）のセッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：//www.rfc-editor.org/info/rfc5389>。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <https://www.rfc-editor.org/info/rfc5627>.
[RFC5627]セッション開始プロトコル（SIP） "、RFC 5627、DOI 10.17487 / RFC5627、2009年10月、<https：///www.rfc-editor.org/info/rfc5627>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P.、J. Rosenberg、「NAT（ターン）の中継（ターン）：Nat（Stun）のセッショントラバーサルユーティリティへのリレー拡張（STUN） "、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>。
Acknowledgements
謝辞
The authors like to thank Flemming Andreasen, Ayush Jain, Paul Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount, and Martin Thomson for reviewing and/or making various suggestions for improvements and optimizations.
著者らは、Flemming Andreasen、Ayush Jain、Paul Kyzivat、Jonathan Lennox、Simon PerreAlt、Roman Shpount、およびMartin Thomson、および/または改良と最適化のためのさまざまな提案をしてくれてありがとう。
The authors also like to thank Flemming Andreasen for shepherding this document and Ben Campbell for his AD review and suggestions. In addition, the authors thank Benjamin Kaduk, Adam Roach, Mirja Kühlewind, and Eric Rescorla for their comments and/or text proposals for improving the document during IESG review.
著者らはまた、このドキュメントとベンキャンベルの広告レビューと提案のために、Flemming Andreasenに感謝しています。また、IESGレビュー中に文書を改善するためのコメントやテキストの提案のために、Benjamin Kaduk、Adam Roach、MirjaKühlewind、Eric Rescorlaに感謝します。
Many thanks to Dale Worley for the Gen-Art review and proposed enhancements for several sections.
Gen-Art ReviewのためのDale Worleyに感謝し、いくつかのセクションの機能強化を提案しています。
Many thanks to Joerg Ott for the TSV-Art review and suggested improvements.
TSVアートレビューのためにJoerg Ottに感謝し、改善を推奨しています。
The authors thank Shawn Emery for the Security Directorate review.
著者らはセキュリティ担当者のレビューのためにEmeryをショーンエメリーに感謝します。
Authors' Addresses
著者の住所
Emil Ivov Jitsi 67000 Strasbourg France
Emil Ivov Jitsi 67000 Strasbourgフランス
Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org
Thomas Stach Unaffiliated 1130 Vienna Austria
Thomas Stach Unfiliated 1130ウィーンオーストリア
Email: thomass.stach@gmail.com
Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 10148 Turin Italy
Enrico Marocco Telecom Italia via G. Reiss Romoli、274 10148トリノイタリア
Email: enrico.marocco@telecomitalia.it
Christer Holmberg Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
Christer Holmberg Ericsson Hirsalantie 11 Fi-02420 Jorvas Finland
Email: christer.holmberg@ericsson.com