[要約] RFC 9248は、聴覚障害者や言語障害者と通信するためのビデオリレーサービスの相互運用プロファイルを定義し、ビデオ通話の標準化と直接通話の実現を目指しています。
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 9248 June 2022
Category: Standards Track
ISSN: 2070-1721
Interoperability Profile for Relay User Equipment
リレーユーザー機器の相互運用性プロファイル
Abstract
概要
Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider.
Video Relay Service（VRS）は、聴覚障害者が聴覚障害者、耳が聞こえない、または聴覚障害者（HOH）である手話スピーカーと通信できるか、通訳者を使用して言語障害を持っている方法を説明するために使用される用語です。ビデオフォンを介して手話スピーカーに接続され、聴覚ユーザーへの音声電話に接続されています。 CAは、ビデオ恐怖症のリンクで手話と電話リンクの音声を使用して解釈します。多くの場合、通訳者は、この文書の「プロバイダー」と呼ばれる会社または代理店によって雇用される場合があります。プロバイダーは、ユーザーがビデオデバイスをサービスに接続し、その後CASやその他の手話スピーカーに接続できるビデオサービスも提供しています。手話スピーカーが使用するビデオフォンが標準に準拠しているため、任意のデバイスをプロバイダーと一緒に使用し、手話スピーカー間の直接ビデオ通話が機能することが望ましいです。このドキュメントでは、ビデオフォンとプロバイダーの間のインターフェイスについて説明します。
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/rfc9248.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9248で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. Requirements Language
4. General Requirements
5. SIP Signaling
5.1. Registration
5.2. Session Establishment
5.2.1. Normal Call Origination
5.2.2. Dial-Around Origination
5.2.3. RUE Contact Information
5.2.4. Incoming Calls
5.2.5. Emergency Calls
5.3. Mid-Call Signaling
5.4. URI Representation of Phone Numbers
5.5. Transport
6. Media
6.1. SRTP and SRTCP
6.2. Text-Based Communication
6.3. Video
6.4. Audio
6.5. DTMF Digits
6.6. Session Description Protocol
6.7. Privacy
6.8. Negative Acknowledgement, Picture Loss Indicator, and Full
Intraframe Request Features
7. Contacts
7.1. CardDAV Login and Synchronization
7.2. Contacts Import/Export Service
8. Video Mail
9. Provisioning and Provider Selection
9.1. RUE Provider Selection
9.2. RUE Configuration Service
9.2.1. Provider Configuration
9.2.2. RUE Configuration
9.2.3. Versions
9.2.4. Examples
9.2.5. Using the Provider Selection and RUE Configuration
Services Together
9.3. OpenAPI Interface Descriptions
9.3.1. Provider List
9.3.2. Configuration
10. IANA Considerations
10.1. RUE Provider List Registry
10.2. Registration of Rue-Owner Value of the Purpose Parameter
11. Security Considerations
12. Normative References
13. Informative References
Acknowledgements
Author's Address
Video Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables people with hearing disabilities who use sign language, such as American Sign Language (ASL), to communicate with voice telephone users through video equipment. These services also enable communication between such individuals directly in suitable modalities, including any combination of sign language via video, real-time text, and speech.
Video Relay Service（VRS）は、アメリカ手話（ASL）などの手話を使用する聴覚障害のある人がビデオ機器を介して音声電話ユーザーと通信できるようにする電気通信リレーサービス（TRS）の形式です。また、これらのサービスは、ビデオ、リアルタイムテキスト、音声を介した手話の任意の組み合わせなど、適切なモダリティで直接そのような個人間のコミュニケーションを可能にします。
This interoperability profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and related media protocols that enables end-user equipment registration and calling for VRS calls. It specifies the minimal set of call flows and IETF and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and extended capabilities for RUE calls.
リレーユーザー機器（RUE）のこの相互運用性プロファイルは、セッション開始プロトコル（SIP）およびエンドユーザー機器の登録を可能にし、VRSコールの呼び出しを可能にする関連メディアプロトコルのプロファイルです。サポートする必要があるコールフローとIETFおよびITU-T規格の最小セットを指定し、標準が複数の実装オプションを残し、RUEコールの最小限と拡張機能を指定します。
Both subscriber-to-provider (interpreted) and direct subscriber-to-subscriber calls are supported on this interface. While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices. This document only describes the interface between the device and the provider, not any other interface the provider may have.
サブスクライバーからプロバイダー（解釈）と直接サブスクライバー間呼び出しの両方が、このインターフェイスでサポートされています。このドキュメントには、VRSサービスを提供するために使用される他のデバイスやサービスとの逆方向の互換性を最大化するためのいくつかの宿泊施設がありますが、後方互換性は要件ではなく、古いデバイスへの直接ビデオ通話を許可するためにインターワークが必要になる場合があります。このドキュメントは、プロバイダーが持っている他のインターフェイスではなく、デバイスとプロバイダー間のインターフェイスのみを記述します。
The following illustrates a typical relay call. The RUE device and the communications assistant (sign language interpreter) have videophones. The hearing user has a telephone (mobile or fixed).
以下は、典型的なリレーコールを示しています。RUEデバイスと通信アシスタント（手話通訳者）にはビデオ恐怖症があります。聴覚ユーザーには電話（モバイルまたは固定）があります。
||== RUE Interface (this document)
||
\/
+------+ +------+ - +--------+ - +-------+
|User | |RUE | ( ) |Provider| ( ) |User |
|who is| |Device|<-(Internet)->| | |who is |
|Deaf |<->| | | |<-( PSTN )->|Hearing|
+------+ +------+ -------- +--------+ ------ +-------+
^
|
+--------------+
|Communications|
|Assistant |
+--------------+
Communications Assistant (CA): A sign-language interpreter working for a VRS provider, providing functionally equivalent phone service.
Communications Assistant（CA）：VRSプロバイダーで働く標識通訳者で、機能的に同等の電話サービスを提供します。
Communication modality (modality): A specific form of communication that may be employed by two users, e.g., English voice, Spanish voice, American Sign Language, English lipreading, or French real-time text. Here, one communication modality is assumed to encompass both the language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities.
コミュニケーションモダリティ（モダリティ）：2人のユーザーが採用できる特定の形式のコミュニケーション、例えば、英語の声、スペイン語の声、アメリカ手話、英語のリップリーディング、またはフランスのリアルタイムテキスト。ここでは、1つのコミュニケーションモダリティが言語とその言語の交換方法の両方を含むと想定されています。たとえば、英語の声とフランスの声は、2つの異なるコミュニケーションモダリティです。
Default video relay service: The video relay service operated by a subscriber's default VRS provider.
デフォルトのビデオリレーサービス：サブスクライバーのデフォルトVRSプロバイダーが運営するビデオリレーサービス。
Default video relay service provider (default provider): The VRS provider that registers and assigns a telephone number to a specific subscriber and, by default, provides the VRS for incoming voice calls to the user. The default provider, also by default, provides the VRS for outgoing relay calls. The user can have more than one telephone number, and each has a default provider.
デフォルトのビデオリレーサービスプロバイダー（デフォルトプロバイダー）：電話番号を特定のサブスクライバーに登録および割り当てるVRSプロバイダー、デフォルトでは、ユーザーに着信音声通話のVRSを提供します。デフォルトのプロバイダーは、デフォルトでは、発信リレーコールのVRSを提供します。ユーザーは複数の電話番号を持つことができ、それぞれにデフォルトのプロバイダーがあります。
Outbound dial-around call: A relay call where the subscriber specifies the use of a VRS provider other than the default VRS provider. This can be accomplished by the user dialing a "front-door" number for a VRS provider and signing or texting a phone number to call ("two-stage"). Alternatively, this can be accomplished by the user's RUE software instructing the server of its default VRS provider to automatically route the call through the alternate provider to the desired Public Switched Telephone Network (PSTN) directory number ("one-stage"). Dial-around is per call; for any call, a user can use the default VRS provider or any dial-around VRS provider.
アウトバウンドダイヤルアラウンドコール：サブスクライバーがデフォルトのVRSプロバイダー以外のVRSプロバイダーの使用を指定するリレーコール。これは、ユーザーがVRSプロバイダーの「フロントドア」番号をダイヤルし、電話番号（「2段階」）に署名またはテキストメッセージを送信することで達成できます。あるいは、これは、デフォルトのVRSプロバイダーのサーバーに指示するユーザーのRUEソフトウェアによって実現することができます。ダイヤルアラウンドは通話ごとです。任意の呼び出しでは、ユーザーはデフォルトのVRSプロバイダーまたはダイヤルアラウンドVRSプロバイダーを使用できます。
Full Intra Request (FIR): A request to a video media sender, requiring that media sender to send a decoder refresh point at the earliest opportunity. FIR is sometimes known as "instantaneous decoder refresh request", "video fast update request", or "fast update request".
完全なリクエスト（FIR）：ビデオメディア送信者へのリクエスト。メディア送信者は、最も早い機会にデコーダーリフレッシュポイントを送信する必要があります。FIRは、「瞬時デコーダーリフレッシュリクエスト」、「ビデオ高速更新リクエスト」、または「高速更新リクエスト」として知られる場合があります。
Point-to-Point Call (P2P Call): A call between two RUEs, without including a CA.
ポイントツーポイントコール（P2Pコール）：CAを含めることなく、2つのリューの間のコール
Relay call: A call that allows people with hearing or speech disabilities to use a RUE to talk to users of conventional voice services with the aid of a CA to relay the communication.
リレーコール：聴覚障害または言語障害を持つ人々が、通信を中継するためにCAの助けを借りて従来の音声サービスのユーザーと話すためにRUEを使用できるようにするコール。
Relay service (RS): A service that allows a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions provided by the relay service include the provision of media links supporting the communication modalities used by the caller and callee, user registration and validation, authentication, authorization, automatic call distributor (ACD) platform functions, routing (including emergency call routing), call setup, mapping, call features (such as call forwarding and video mail), and assignment of CAs to relay calls.
リレーサービス（RS）：登録されたサブスクライバーがRUEを使用してリレーコール、ポイントツーポイントコール、リレーからリレーコールを作成できるようにするサービス。リレーサービスが提供する機能には、発信者とCalleeが使用する通信モダリティをサポートするメディアリンクの提供、ユーザー登録と検証、認証、認証、自動コールディストリビューター（ACD）プラットフォーム機能、ルーティング（緊急通話ルーティングを含む）、コールセットアップ、マッピング、コール機能（コール転送やビデオメールなど）、およびCASの割り当てへの割り当て。
Relay service provider (provider): An organization that operates a relay service. A subscriber selects a relay service provider to assign and register a telephone number for their use, to register with for receipt of incoming calls, and to provide the default service for outgoing calls.
リレーサービスプロバイダー（プロバイダー）：リレーサービスを運営する組織。サブスクライバーは、リレーサービスプロバイダーを選択して、使用するために電話番号を割り当てて登録し、着信の受信のために登録し、発信コールのデフォルトサービスを提供します。
Relay user: Please refer to "subscriber".
リレーユーザー：「サブスクライバー」を参照してください。
Relay user E.164 Number (user E.164): The telephone number (in ITU-T E.164 format) assigned to the user.
リレーユーザーE.164番号（ユーザーE.164）：ユーザーに割り当てられた電話番号（ITU-T e.164形式）。
Relay User Equipment (RUE): A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting, receiving, and using relay calls. A RUE may take many forms, including a stand-alone device; an application running on a general-purpose computing device, such as a laptop, tablet, or smartphone; or proprietary equipment connected to a server that provides the RUE interface.
リレーユーザー機器（RUE）：SIPユーザーエージェント（UA）は、リレーコールを要求、受信、および使用する際にサブスクライバーをサポートする追加機能で強化されました。RUEは、スタンドアロンデバイスを含む多くの形をとることがあります。ラップトップ、タブレット、スマートフォンなどの汎用コンピューティングデバイスで実行されるアプリケーション。または、RUEインターフェイスを提供するサーバーに接続された独自の機器。
RUE interface: The interfaces described in this document between a RUE and a VRS provider who supports it.
RUEインターフェイス：このドキュメントで説明されているインターフェイスは、RUEとそれをサポートするVRSプロバイダーの間で説明しています。
Sign language: A language that uses hand gestures and body language to convey meaning, including, but not limited to, American Sign Language (ASL).
手話：ハンドジェスチャーとボディーランゲージを使用して、アメリカの手話（ASL）を含むがこれらに限定されない意味を伝える言語。
Subscriber: An individual who has registered with a provider and who obtains service by using a RUE. This is the conventional telecom term for an end-user customer, which in this case is a relay user. A user may be a subscriber to more than one VRS provider.
サブスクライバー：プロバイダーに登録し、RUEを使用してサービスを受ける個人。これは、エンドユーザーの顧客向けの従来の通信用語であり、この場合はリレーユーザーです。ユーザーは、複数のVRSプロバイダーのサブスクライバーである場合があります。
Video Relay Service (VRS): A relay service for people with hearing or speech disabilities who use sign language to communicate using video equipment (video RUE) with other people in real time. The video link allows the CA to view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party.
Video Relay Service（VRS）：聴覚障害または言語障害を持つ人向けのリレーサービス手話を使用して、ビデオ機器（ビデオRUE）を使用して他の人とリアルタイムで通信します。ビデオリンクにより、CAはサブスクライバーの署名された会話を表示および解釈し、相手と会話を前後に伝えることができます。
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. Lower- or mixed-case uses of these key words are not to be interpreted as carrying special significance.
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。これらのキーワードの低いまたは混合ケースの使用は、特別な意味を持つものと解釈されるべきではありません。
All HTTP/HTTPS [RFC9110] [RFC9112] connections specified throughout this document MUST use HTTPS. Both HTTPS and all SIP connections MUST use TLS conforming to at least [RFC7525] and MUST support [RFC8446].
このドキュメント全体で指定されたすべてのHTTP/HTTPS [RFC9110] [RFC9112]接続は、HTTPSを使用する必要があります。HTTPSとすべてのSIP接続の両方が、少なくとも[RFC7525]に準拠しているTLSを使用し、[RFC8446]をサポートする必要があります。
All text data payloads not otherwise constrained by a specification in another standards document MUST be encoded as Unicode UTF-8.
別の標準ドキュメントの仕様によって制約されていないすべてのテキストデータペイロードは、Unicode UTF-8としてエンコードする必要があります。
Implementations MUST support IPv4 and IPv6. Dual-stack support is NOT required, and provider implementations MAY support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where there is either an A or AAAA record in each server DNS record but not both. The same version of IP MUST be used for both signaling and media of a call unless Interactive Connectivity Establishment (ICE) [RFC8445] is used; in which case, candidates may explicitly offer IPv4, IPv6, or both for any media stream.
実装は、IPv4とIPv6をサポートする必要があります。デュアルスタックサポートは必要ありません。プロバイダーの実装は、各サーバーDNSレコードにAまたはAAAAレコードがあるが両方ではなく、適切なSRVレコードに複数のサーバーを持つことにより、IPv4とIPv6の個別のインターフェイスをサポートする場合があります。IPの同じバージョンのIPは、インタラクティブ接続確立（ICE）[RFC8445]を使用しない限り、コールのシグナルとメディアの両方に使用する必要があります。その場合、候補者は、メディアストリームに対してIPv4、IPv6、またはその両方を明示的に提供する場合があります。
Implementations of the RUE interface MUST conform to the following core SIP standards:
RUEインターフェイスの実装は、次のコアSIP標準に準拠する必要があります。
* [RFC3261] (Base SIP)
* [RFC3261]（ベースSIP）
* [RFC3263] (Locating SIP Servers)
* [RFC3263]（SIPサーバーの位置）
* [RFC3264] (Offer/Answer)
* [RFC3264]（申し出/回答）
* [RFC3840] (User Agent Capabilities)
* [RFC3840]（ユーザーエージェント機能）
* [RFC5626] (Outbound)
* [RFC5626]（アウトバウンド）
* [RFC8866] (Session Description Protocol)
* [RFC8866]（セッション説明プロトコル）
* [RFC3323] (Privacy)
* [RFC3323]（プライバシー）
* [RFC3605] (RTCP Attribute in SDP)
* [RFC3605]（SDPのRTCP属性）
* [RFC3311] (UPDATE Method)
* [RFC3311]（更新方法）
* [RFC5393] (Loop-Fix)
* [RFC5393]（ループフィックス）
* [RFC5658] (Record-Route Fix)
* [RFC5658]（レコードルート修正）
* [RFC5954] (ABNF Fix)
* [RFC5954]（ABNF修正）
* [RFC3960] (Early Media)
* [RFC3960]（初期メディア）
* [RFC6442] (Geolocation Header Field)
* [RFC6442]（ジオロケーションヘッダーフィールド）
In the above documents, the RUE device conforms to the requirements of a SIP user agent, and the provider conforms to the requirements of the registrar and proxy server where the document specifies different behavior for different roles. For providers offering a video mail service, [RFC6665] (SIP Events) MUST be implemented to support the Message-Waiting Indicator (MWI) (see Section 8).
上記のドキュメントでは、RUEデバイスはSIPユーザーエージェントの要件に準拠しており、プロバイダーは、ドキュメントが異なる役割に対して異なる動作を指定するレジストラとプロキシサーバーの要件に準拠しています。ビデオメールサービスを提供するプロバイダーの場合、[RFC6665]（SIPイベント）を実装して、メッセージ待機インジケーター（MWI）をサポートする必要があります（セクション8を参照）。
In addition, implementations MUST conform to:
さらに、実装は以下に適合する必要があります。
* [RFC3327] (Path Header Field)
* [RFC3327]（パスヘッダーフィールド）
* [RFC8445] and [RFC8839] (ICE)
* [RFC8445]および[RFC8839]（ICE）
* [RFC3326] (Reason Header Field)
* [RFC3326]（理由ヘッダーフィールド）
* [RFC3515] (REFER Method)
* [RFC3515]（メソッドを参照）
* [RFC3891] (Replaces Header Field)
* [RFC3891]（ヘッダーフィールドを交換）
* [RFC3892] (Referred-By Header Field)
* [RFC3892]（ヘッダーフィールドを参照）
Implementations MUST implement full ICE, although they MAY interwork with user agents that implement ICE-lite.
実装は完全なICEを実装する必要がありますが、アイスライトを実装するユーザーエージェントとインターワークする場合があります。
Implementations MUST include a "User-Agent" header field uniquely identifying the RUE application, platform, and version in all SIP requests and MUST include a "Server" header field with the same content in SIP responses.
実装には、すべてのSIPリクエストでRUEアプリケーション、プラットフォーム、およびバージョンを一意に識別する「ユーザーエージェント」ヘッダーフィールドを含める必要があり、SIP応答で同じコンテンツを持つ「サーバー」ヘッダーフィールドを含める必要があります。
Implementations intended to support mobile platforms MUST support [RFC8599] and MUST use it as at least one way to support waking up the client from the background state.
モバイルプラットフォームをサポートすることを目的とした実装は、[RFC8599]をサポートする必要があり、バックグラウンド状態からクライアントを目覚めるのをサポートするための少なくとも1つの方法として使用する必要があります。
The SIP signaling for registration and placing/receiving calls depends on the configuration of various values into the RUE device. Section 9.2 describes the configuration mechanism that provides values that are used in the signaling. When the device starts, the configuration mechanism is run, which retrieves the configuration data; then, SIP registration occurs using the values from the configuration. After registration, calls may be sent or received by the RUE device.
登録および通話の配置/受信のSIPシグナリングは、RUEデバイスへのさまざまな値の構成に依存します。セクション9.2では、シグナル伝達で使用される値を提供する構成メカニズムについて説明します。デバイスが起動すると、構成メカニズムが実行され、構成データが取得されます。次に、SIP登録は、構成の値を使用して発生します。登録後、RUEデバイスから通話が送信または受信される場合があります。
The RUE MUST register with a SIP registrar, following [RFC3261] and [RFC5626], at a provider it has an account with. If the configuration (see Section 9.2) contains multiple "outbound-proxies" in "RueConfigurationData", then the RUE MUST use them as specified in [RFC5626] to establish multiple flows.
RUEは、[RFC3261]および[RFC5626]に続いて、アカウントを持っているプロバイダーにSIPレジストラに登録する必要があります。構成（セクション9.2を参照）に「rueconfigurationData」に複数の「アウトバウンドポキシ」が含まれている場合、RUEは[RFC5626]で指定されたとおりにそれらを使用して複数のフローを確立する必要があります。
The Request-URI for the REGISTER request MUST contain the "provider-domain" from the configuration. The To URI and From URI MUST be identical URIs and formatted as follows:
レジスタリクエストのリクエスト-URIには、構成から「プロバイダードメイン」が含まれている必要があります。To URIとURIからは同一のurisでなければならず、次のようにフォーマットされている必要があります。
* if "user-name" is provided: "username@provider-domain"
* 「user-name」が提供されている場合：「username@provider-domain」
* if "user-name" is not provided: as specified in Section 5.4, use "phone-number" and "provider-domain" from the configuration
* 「user-name」が提供されていない場合：セクション5.4で指定されているように、構成から「電話番号」と「プロバイダードメイン」を使用します
The RUE determines the URI to resolve by initially determining if one or more "outbound-proxies" are configured. If they are configured, the URI will be that of one of the "outbound-proxies". If no "outbound-proxies" are configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry MUST contain NAPTR records conforming to [RFC3263]. One of those NAPTR records MUST specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.net" could return:
RUEは、最初に1つ以上の「アウトバウンドポキシ」が構成されているかどうかを最初に決定することにより、解決するURIを決定します。それらが構成されている場合、URIは「アウトバウンドプロキシ」の1つになります。「アウトバウンドプロキシ」が構成されていない場合、URIはレジスタリクエストからのリクエスト-URIになります。RUEはそのURIからドメインを抽出し、そのドメインのDNSレコードに相談します。DNSエントリには、[RFC3263]に準拠したNAPTRレコードを含める必要があります。これらのNAPTRレコードの1つは、SIPの優先輸送としてTLSを指定する必要があります。たとえば、「sip：p1.red.example.net」のdns naptrクエリは戻ります。
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net
in naptr 50 50 "s" "sips d2t" "" _sips._tcp.p1.red.example.net in naptr 90 50 "s" "sip d2t" "" _sip._tcp.p1.red.example.net
If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST reattempt registration without using the outbound mechanism.
RUEがレジスタリクエストに対する439（First Hopにはアウトバウンドサポートが欠けている）応答を受け取った場合、アウトバウンドメカニズムを使用せずに登録を再試行する必要があります。
The registrar MAY authenticate the RUE using SIP digest authentication. The credentials to be used MUST come from the configuration in Section 9.2: "user-name" if provided or "phone-number" if user-name is not provided, and "sip-password". This "user-name"/"sip-password" combination SHOULD NOT be the same as that used for other purposes, except as expressly described below, such as retrieving the RUE configuration or logging into the provider's customer service portal. [RFC8760] MUST be supported by all implementations, and SHA-512 digest algorithms MUST be supported.
レジストラは、SIPダイジェスト認証を使用してRUEを認証できます。使用する資格情報は、セクション9.2の構成から得られる必要があります：提供されている場合は「ユーザー名」またはユーザー名が提供されていない場合は「電話番号」、および「sip-password」。この「ユーザー名」/「SIP-PASSWORD」の組み合わせは、RUE構成の取得やプロバイダーのカスタマーサービスポータルへのログインなど、以下に明示的に説明する場合を除き、他の目的で使用されるものと同じであるべきではありません。[RFC8760]はすべての実装によってサポートされ、SHA-512ダイジェストアルゴリズムをサポートする必要があります。
If the registration request fails with an indication that credentials from the configuration are invalid, then the RUE MUST retrieve a fresh version of the configuration. If credentials from a freshly retrieved configuration are found to be invalid, then the RUE MUST cease attempts to register and inform the RUE user of the problem.
登録要求が構成からの資格情報が無効であることを示すことで失敗した場合、RUEは構成の新しいバージョンを取得する必要があります。新たに検索した構成からの資格情報が無効であることが判明した場合、RUEはRUEユーザーに問題を登録して通知する試みを停止する必要があります。
Support for multiple simultaneous registrations with multiple providers by the RUE is OPTIONAL for the RUE (and providers do not need any support for this option).
RUEの複数のプロバイダーとの複数の同時登録のサポートは、RUEにとってオプションです（プロバイダーはこのオプションをサポートする必要はありません）。
Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI SHOULD be permitted by the provider. The provider MAY limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the provider MAY then prematurely terminate another registration; however, it SHOULD NOT do this if it would disconnect an active call.
同じSIP URIを備えた異なるRUEデバイスからの複数の同時RUE SIP登録は、プロバイダーによって許可される必要があります。プロバイダーは、同時登録の総数を制限する場合があります。同時登録の制限を超える新しい登録要求が受信されると、プロバイダーは別の登録を早期に終了することがあります。ただし、アクティブな呼び出しを切断する場合、これを行うべきではありません。
If a provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it SHOULD take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition.
プロバイダーが同じURIとの同時登録の総数を減らすために登録を早期に終了する場合、影響を受けるRUEが条件を自動的に再登録して再トリガーするのを防ぐために何らかの措置を講じる必要があります。
After initial SIP registration, the RUE adheres to SIP [RFC3261] basic call flows, as documented in [RFC3665].
最初のSIP登録の後、RUEは[RFC3665]に記載されているように、SIP [RFC3261]基本的なコールフローを順守します。
A RUE device MUST route all outbound calls through an outbound proxy if configured.
RUEデバイスは、構成されている場合は、すべてのアウトバウンドコールをアウトバウンドプロキシを介してルーティングする必要があります。
The SIP URIs in the To field and the Request-URI MUST be formatted as specified in Section 5.4 using the destination phone number or as SIP URIs as provided in the configuration (Section 9.2). The domain field of the URIs SHOULD be the "provider-domain" from the configuration (e.g., sip:+15551234567@red.example.com;user=phone), except that an anonymous call would not use the provider domain.
TOフィールドのSIP URIとリクエストURIは、宛先電話番号を使用してセクション5.4で指定されているように、または構成（セクション9.2）で提供されるSIP URIとしてフォーマットする必要があります。URISのドメインフィールドは、構成の「プロバイダードメイン」でなければなりません（例：sip：1551234567@red.example.com; user =電話）。ただし、匿名の通話がプロバイダードメインを使用しないことを除きます。
Anonymous calls MUST be supported by all implementations. An anonymous call is signaled per [RFC3323].
匿名の呼び出しは、すべての実装によってサポートされる必要があります。[RFC3323]ごとに匿名の呼び出しが通知されます。
The From URI MUST be formatted as specified in Section 5.4, using the "phone-number" and "provider-domain" from the configuration. It SHOULD also contain the display-name from the configuration when present. (Please refer to Section 9.2.)
From URIは、構成から「電話番号」と「プロバイダードメイン」を使用して、セクション5.4で指定されているようにフォーマットする必要があります。また、存在するときに構成からディスプレイ名を含める必要があります。（セクション9.2を参照してください。）
Negotiated media MUST follow the requirements specified in Section 6 of this document.
ネゴシエートされたメディアは、このドキュメントのセクション6で指定された要件に従う必要があります。
To allow time for an unanswered call to time out and direct it to a videomail server, the User Agent Client MUST NOT impose a time limit less than the default SIP INVITE transaction timeout of 3 minutes.
未回答の呼び出しがタイムアウトし、それをビデオメイルサーバーに向ける時間を確保するために、ユーザーエージェントクライアントは、3分のデフォルトのSIP Inviteトランザクションタイムアウトよりも時間制限を課すことはできません。
Providers and RUE devices MUST support both one-stage and two-stage dial-around.
プロバイダーとRUEデバイスは、1段階と2段のダイヤルアラウンドの両方をサポートする必要があります。
Outbound dial-around calls allow a RUE user to select any provider to provide interpreting services for any call. "Two-stage" dial-around calls involve the RUE calling a telephone number that reaches the dial-around provider and using signing or dual-tone multi-frequency (DTMF) to provide the called party's telephone number. In two-stage dial-around, the To URI is the "front-door" URI (see Section 9.2) in "ProviderConfigurationData" of the dial-around provider. The RUE Provider Selection service (Section 9.1) can be used by the RUE to obtain a list of providers; then, the provider configuration (Section 9.2.1) can be used to find the front-door URI for each of these providers.
アウトバウンドダイヤルアラウンドコールを使用すると、RUEユーザーがプロバイダーを選択して、通話の通訳サービスを提供できます。「2段階」のダイヤルアラウンドコールには、ダイヤルアラウンドプロバイダーに到達する電話番号を呼び出し、署名またはデュアルトーンマルチ周波数（DTMF）を使用して、電話番号を提供します。2段階のダイヤルアラウンドでは、To URIは、ダイヤルアラウンドプロバイダーの「ProviderConfigurationData」の「フロントドア」URI（セクション9.2を参照）です。RUEプロバイダーの選択サービス（セクション9.1）は、RUEがプロバイダーのリストを取得するために使用できます。次に、プロバイダーの構成（セクション9.2.1）を使用して、これらの各プロバイダーのフロントドアURIを見つけることができます。
One-stage dial-around is a method where the called party's telephone number is provided in the To URI and the Request-URI, using the domain of the dial-around provider.
1段のダイヤルアラウンドは、ダイヤルアラウンドプロバイダーのドメインを使用して、呼び出した当事者の電話番号がURIとリクエスト-URIで提供される方法です。
For one-stage dial-around, the RUE MUST follow the procedures in Section 5.2.1 with the following exception: the domain part of the SIP URIs in the To field and the Request-URI MUST be the domain of the dial-around provider discovered as described in Section 9.1.
1段階のダイヤルアラウンドの場合、RUEは次の例外を除き、セクション5.2.1の手順に従う必要があります。セクション9.1で説明されているように発見されました。
The following is a partial example of a one-stage dial-around call from VRS user +1-555-222-0001 hosted by red.example.com to a hearing user +1-555-123-4567 using dial-around to green.example.com for the relay service. Only important details of the messages are shown, and many header fields have been omitted:
以下は、red.example.comが聴覚ユーザー1-555-123-4567にホストしたVRSユーザー1-555-222-0001からの1段階のダイヤルアラウンドコールの部分的な例です。リレーサービスのExample.com。メッセージの重要な詳細のみが表示され、多くのヘッダーフィールドは省略されています。
,-+-. ,----+----. ,-----+-----.
|RUE| |Default | |Dial-Around|
| | |Provider | | Provider |
`-+-' `----+----' `-----+-----'
| | |
| [1] INVITE | |
|-------------->| [2] INVITE |
| |-------------->|
Message Details:
メッセージの詳細：
[1] INVITE Rue -> Default Provider
[1] RUE->デフォルトプロバイダーを招待します
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" <sip:+15552220001@red.example.net;user=phone>
[2] INVITE Default Provider -> Dial-Around Provider
[2] デフォルトプロバイダーを招待します - >ダイヤルアラウンドプロバイダー
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+15552220001@red.example.net;user=phone
P-Asserted-Identity: sip:+15552220001@red.example.net
Figure 1: One-Stage Dial-Around
図1：1段のダイヤルアラウンド
To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK the RUE uses to accept a call, identifies the owner by sending a Call-Info header field with a purpose parameter of "rue-owner". The URI MAY be an HTTPS URI or Content-ID URL. The latter is defined by [RFC2392] to locate message body parts. This URI type is present in a SIP message to convey the RUE ownership information as a MIME body. The form of the RUE ownership information is an xCard [RFC6351]. Please refer to [RFC6442] for an example of using content indirection URLs in SIP messages. Note that use of the content indirection URL usually implies multiple message bodies ("mime/multipart"). The RUE owner is the entity that has local control over the device that is not necessarily the legal owner of the equipment. It often is the user, but that is not necessarily true. While no minimum fields in the xCard are specified, the name, address, phone number, and email address of the RUE owner are expected to be supplied.
RUEの所有者を特定するには、RUEからの電話への最初の招待、またはRUEが電話を受け入れるために使用する200 OKを特定するために、「RUE所有者の目的パラメーターを持つコールINFOヘッダーフィールドを送信することで所有者を識別します。 "。 URIは、HTTPS URIまたはContent-ID URLである可能性があります。後者は[RFC2392]で定義され、メッセージボディの部分を見つけます。このURIタイプは、RUEの所有権情報をMime Bodyとして伝えるためのSIPメッセージに存在します。 RUE所有情報の形式はXcard [RFC6351]です。 SIPメッセージでコンテンツ間接URLを使用する例については、[RFC6442]を参照してください。コンテンツの間接URLの使用は通常、複数のメッセージ本文を意味することに注意してください（「Mime/Multipart」）。 RUE所有者は、必ずしも機器の法的所有者ではないデバイスをローカルに制御するエンティティです。多くの場合、ユーザーですが、必ずしも真実ではありません。 Xcardの最小フィールドは指定されていませんが、RUE所有者の名前、住所、電話番号、および電子メールアドレスが供給されると予想されます。
The RUE MUST only accept inbound calls sent to it by a proxy mentioned in the configuration.
RUEは、構成に記載されているプロキシによって送信されたインバウンドコールのみを受け入れる必要があります。
If multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist, the provider MUST parallel fork the call to all registered RUEs so that they ring at the same time. The first RUE to reply with a 200 OK answers the call, and the provider MUST cancel other call branches using a CANCEL request.
同じSIP URIが存在するさまざまなRUEデバイスからの複数の同時RUE SIP登録が存在する場合、プロバイダーはすべての登録されたリューへの呼び出しを並行して、同時に鳴るように並行する必要があります。200 okで最初に返信することで通話に応答し、プロバイダーはキャンセルリクエストを使用して他のコールブランチをキャンセルする必要があります。
Implementations MUST conform to [RFC6881] for handling of emergency calls, except that if the device is unable to determine its own location, it MAY send the emergency call without a Geolocation header field and without a Route header field (since it would be unable to query the Location-to-Service Translation (LoST) server for a route, per [RFC6881]). If an emergency call arrives at the provider without a Geolocation header field, the provider MUST supply location by adding the Geolocation header field and MUST supply the route by querying the LoST server with that location.
実装は、緊急通話の処理のために[RFC6881]に準拠する必要があります。ただし、デバイスが独自の場所を決定できない場合、ジオロケーションヘッダーフィールドとルートヘッダーフィールドなしで緊急通話を送信する場合があります（[RFC6881]ごとにルートの場所からサービスへの翻訳（失われた）サーバーをクエリします。Geolocation Headerフィールドなしでプロバイダーに緊急コールが到着した場合、プロバイダーはジオロケーションヘッダーフィールドを追加して場所を提供する必要があり、その場所で失われたサーバーをクエリすることでルートを供給する必要があります。
If the emergency call is to be handled using existing country-specific procedures, the provider is responsible for modifying the INVITE to conform to the country-specific requirements. In this case, the location MAY be extracted from the [RFC6881] conformant INVITE and used to propagate it to the appropriate country-specific entities. If the configuration specifies it, an implementation of a RUE device MAY send a Geolocation header field containing its location in the REGISTER request. If implemented, users MUST be offered an opt-out. Country-specific procedures might require the location to be preloaded in some entity prior to placing an emergency call; however, the RUE may have a more accurate and timely device location than the manual, preloaded entry. That information MAY be used to populate the location to appropriate country-specific entities. Re-registration SHOULD be used to update the location, so long as the rate of re-registration is limited if the device is moving.
緊急電話が既存の国固有の手順を使用して処理される場合、プロバイダーは、国固有の要件に準拠するために招待を変更する責任があります。この場合、場所は[RFC6881]コンフォーマント招待から抽出され、適切な国固有のエンティティに伝播するために使用できます。構成が指定した場合、RUEデバイスの実装は、レジスタリクエストにその場所を含むジオロケーションヘッダーフィールドを送信する場合があります。実装されている場合、ユーザーにオプトアウトを提供する必要があります。国固有の手順では、緊急電話をかける前に、一部のエンティティで場所をプリロードする必要がある場合があります。ただし、RUEには、マニュアルがプリロードされたエントリよりも正確でタイムリーなデバイスの位置がある場合があります。その情報は、場所を適切な国固有のエンティティに入力するために使用される場合があります。デバイスが移動している場合、再登録率が制限されている限り、再登録を使用して場所を更新する必要があります。
Implementations MUST implement additional data [RFC7852]. RUE devices MUST implement data provider information, device information, and owner/subscriber information blocks.
実装は追加データを実装する必要があります[RFC7852]。RUEデバイスは、データプロバイダー情報、デバイス情報、および所有者/サブスクライバー情報ブロックを実装する必要があります。
Implementations MUST support re-INVITE to renegotiate media session parameters (among other uses). Per Section 6.8, implementations MUST be able to support an INFO message for full frame refresh for devices that do not support SRTCP (please refer to Section 6.1). Implementations MUST support an in-dialog REFER (as described in [RFC3515] and updated by [RFC7647], and including support for norefersub per [RFC4488]) with the Replaces header field [RFC3891] to enable call transfer.
実装は、メディアセッションのパラメーターを再交渉するための再入力をサポートする必要があります（他の用途の中でも）。セクション6.8ごとに、実装は、SRTCPをサポートしていないデバイスのフルフレーム更新の情報メッセージをサポートできる必要があります（セクション6.1を参照してください）。実装は、ダイアログ内参照（[RFC3515]で説明され、[RFC7647]によって更新され、[RFC4488]あたりのnoreferSubのサポートを含む）を交換ヘッダーフィールド[RFC3891]とともにサポートして通話転送を有効にする必要があります。
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE MUST be represented as follows, depending on whether they can be represented as an E.164 number. In this section, "expressed as an E.164 number" includes numbers, such as toll-free numbers that are not actually E.164 numbers but have the same format.
非URIソース（ダイヤル文字列）から構築され、RUEによってSIPプロキシに送信されたSIPウリは、E.164番号として表現できるかどうかに応じて、次のように表現する必要があります。このセクションでは、「E.164番号として表現された」には、実際にはE.164の数字ではなく、同じ形式があるダイロンのない数字などの数字が含まれています。
A dial string that can be expressed as an E.164 phone number MUST be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI MUST be in conformance with "global-number", as defined in [RFC3966]. The user part MUST NOT contain any "visual-separator" characters, as defined in [RFC3966].
E.164の電話番号として表現できるダイヤル文字列は、uri "; user = phone"タグを持つSIP URIとして表す必要があります。URIのユーザー部分は、[RFC3966]で定義されているように、「グローバル番号」に準拠している必要があります。[RFC3966]で定義されているように、ユーザーパーツには「視覚的セパレータ」文字を含めてはなりません。
Dial strings that cannot be expressed as E.164 numbers MUST be represented as dialstring URIs, as specified by [RFC4967], e.g., sip:411@red.example.net;user=dialstring.
E.164番号として表現できない文字列は、[RFC4967]で指定されているように、ダイヤルストリングURIとして表現する必要があります。
The domain part of relay service URIs and User Address of Records (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or IPv6 addresses.
リレーサービスURISおよびユーザーアドレスのレコード（AOR）のドメイン部分は、グローバルにルーティング可能なIPv4および/またはIPv6アドレスに解決する必要があります（[RFC3263]）。
Implementations MUST conform to [RFC8835], except for its guidance on the WebRTC data channel, which this specification does not use. See Section 6.2 for how RUE supports real-time text without the data channel.
この仕様では使用されていないWeBRTCデータチャネルに関するガイダンスを除き、実装は[RFC8835]に準拠する必要があります。RUEがデータチャネルなしでリアルタイムテキストをサポートする方法については、セクション6.2を参照してください。
Implementations MUST support SIP outbound [RFC5626] (please also refer to Section 5.1).
実装は、SIPアウトバウンド[RFC5626]をサポートする必要があります（セクション5.1も参照してください）。
This specification adopts the media specifications for WebRTC [RFC8825]. Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SIP call. Various RTPs, RTCPs, SDPs, and specific media requirements specified for WebRTC are adopted for this document. Explicit requirements from the WebRTC suite of documents are described below .
この仕様では、WeBRTC [RFC8825]のメディア仕様が採用されています。WeBRTCがクライアントとしてブラウザを使用してインタラクティブなメディア通信をどのように確立するかを定義する場合、この仕様は通常のSIP呼び出しを想定しています。このドキュメントには、さまざまなRTP、RTCP、SDP、およびWeBRTC用に指定された特定のメディア要件が採用されています。WeBRTCスイートのドキュメントからの明示的な要件を以下に説明します。
To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser and a RUE client interface towards a provider is assumed. The gateway would interwork signaling and, as noted below, interwork at least any real-time text media in order to allow a standard browser-based WebRTC client to be a VRS client. The combination of the browser client and the gateway would be a RUE user. This document does not specify the gateway.
このドキュメントでWeBRTCを使用するには、ブラウザに向けてWeBRTCサーバーインターフェイスを提示するゲートウェイとプロバイダーへのRUEクライアントインターフェイスが想定されています。ゲートウェイはシグナリングをインターワークし、以下に示すように、標準のブラウザベースのWeBRTCクライアントをVRSクライアントにするために、少なくともリアルタイムのテキストメディアをインターワークします。ブラウザクライアントとゲートウェイの組み合わせは、RUEユーザーになります。このドキュメントでは、ゲートウェイを指定しません。
The following sections specify the WebRTC documents to which conformance is required. "Mandatory to Implement" means a conforming implementation MUST implement the specified capability. It does not mean that the capability must be used in every session. For example, Opus is a Mandatory-to-Implement audio codec, and all conforming implementations must support Opus. However, an implementation presenting a call across the RUE interface (where the call originates in the PSTN or an older, non-RUE-compatible device, which only offers G.711 audio) does not need to include the Opus codec in the offer, since it cannot be used with that call. Conformance to this document allows end-to-end RTCP and media congestion control for audio and video.
次のセクションでは、適合が必要なWeBRTCドキュメントを指定します。「実装するための必須」とは、適合実装が指定された機能を実装する必要があることを意味します。すべてのセッションで機能を使用する必要があるという意味ではありません。たとえば、OPUSは必須のオーディオコーデックであり、すべての適合実装はOPUSをサポートする必要があります。ただし、RUEインターフェイス全体に呼び出しを提示する実装（コールはPSTNまたはG.711オーディオのみを提供する古い非希望互換デバイスで発生します）は、OPUSコーデックをオファーに含める必要はありません。その呼び出しで使用できないためです。このドキュメントへの適合により、オーディオとビデオのエンドツーエンドのRTCPおよびメディア混雑制御が可能になります。
Implementations MUST support [RFC8834], except that MediaStreamTracks are not used. Implementations MUST conform to Section 6.4 of [RFC8827].
実装は[RFC8834]をサポートする必要がありますが、MediaStreamTrackが使用されていないことを除きます。実装は[RFC8827]のセクション6.4に準拠する必要があります。
Implementations MUST support real-time text [RFC4102] [RFC4103] via T.140 media. One original and two redundant generations MUST be transmitted and supported with a 300 ms transmission interval. Implementations MUST support [RFC9071], especially for emergency calls. Note that [RFC4103] is not how real-time text is transmitted in WebRTC, and some form of transcoder would be required to interwork real-time text in the data channel of WebRTC to [RFC4103] real-time text.
実装は、T.140メディアを介してリアルタイムテキスト[RFC4102] [RFC4103]をサポートする必要があります。1つのオリジナルと2つの冗長な世代を送信し、300ミリ秒の伝送間隔でサポートする必要があります。実装は、特に緊急電話のために[RFC9071]をサポートする必要があります。[RFC4103]は、WeBRTCでリアルタイムのテキストがどのように送信されるかではなく、WeBRTCのデータチャネルで[RFC4103]リアルタイムテキストにリアルタイムテキストをインターワークするために、何らかの形のトランスコダーが必要であることに注意してください。
Transport of T.140 real-time text in WebRTC is specified in [RFC8865], using the WebRTC data channel. [RFC8865] also has some advice on how gateways between [RFC4103] and [RFC8865] should operate. It is RECOMMENDED that [RFC8865], including multiparty support, be used for communication with browser-based WebRTC implementations. Implementations MUST support [RFC9071].
WeBRTCのT.140リアルタイムテキストの輸送は、WeBRTCデータチャネルを使用して[RFC8865]で指定されています。[RFC8865]は、[RFC4103]と[RFC8865]の間のゲートウェイがどのように動作するかについてのアドバイスもあります。[RFC8865]は、マルチパーティサポートを含む[RFC8865]を、ブラウザーベースのWeBRTC実装との通信に使用することをお勧めします。実装は[RFC9071]をサポートする必要があります。
Implementations MUST conform to [RFC7742] with the following exceptions: only H.264, as specified in [RFC7742], is Mandatory to Implement, and VP8 support is OPTIONAL at both the device and providers. This is because backwards compatibility is desirable, and older devices do not support VP8.
実装は、次の例外を除いて[RFC7742]に準拠する必要があります。[RFC7742]で指定されているH.264のみが実装することが必須であり、VP8サポートはデバイスとプロバイダーの両方でオプションです。これは、後方互換性が望ましいためであり、古いデバイスがVP8をサポートしていないためです。
Implementations MUST conform to [RFC7874].
実装は[RFC7874]に準拠する必要があります。
Implementations MUST support the "audio/telephone-event" [RFC4733] media type. They MUST support conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. Handling of other tones is OPTIONAL.
実装は、「オーディオ/電話イベント」[RFC4733]メディアタイプをサポートする必要があります。[RFC4733]の表7に定義されているイベントコード0〜11（dtmf digits "0" - "9"、 "*"、 "＃"）の伝達をサポートする必要があります。他のトーンの取り扱いはオプションです。
The SDP offers and answers MUST conform to the SDP rules in [RFC8829] except that the RUE interface uses SIP transport for SDP. The SDP for real-time text MUST specify the T.140 payload type [RFC4103].
SDPの提供と回答は、RUEインターフェイスがSDPのSIPトランスポートを使用していることを除いて、[RFC8829]のSDPルールに準拠する必要があります。リアルタイムテキストのSDPは、T.140ペイロードタイプ[RFC4103]を指定する必要があります。
The RUE MUST provide for user privacy by implementing a local one-way mute, without signaling, for both audio and video. However, RUE MUST maintain any states in the network (e.g., NAT bindings) by periodically sending media packets on all active media sessions containing silence, comfort noise, blank screen, etc., per [RFC6263].
RUEは、オーディオとビデオの両方に対して、信号なしでローカルの一方向ミュートを実装することにより、ユーザーのプライバシーを提供する必要があります。ただし、RUEは、[RFC6263]ごとに、沈黙、快適な騒音、空白の画面などを含むすべてのアクティブなメディアセッションでメディアパケットを定期的に送信することにより、ネットワーク内の状態（NATバインディングなど）を維持する必要があります。
6.8. Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features
6.8. 否定的な謝辞、画像損失インジケーター、および完全な枠内リクエスト機能
The NACK, FIR, and Picture Loss Indicator (PLI) features, as described in [RFC4585] and [RFC5104], MUST be implemented. Availability of these features MUST be announced with the "ccm" feedback value. NACK should be used when negotiated and conditions warrant its use and the other end supports it. Signaling picture losses as a PLI should be preferred. FIR should be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per Section 4.3.1.2 of [RFC5104].
[RFC4585]および[RFC5104]に記載されているように、NACK、FIR、およびPicture Lossインジケーター（PLI）機能を実装する必要があります。これらの機能の可用性は、「CCM」フィードバック値を使用して発表する必要があります。NACKはネゴシエートされたときに使用する必要があり、条件はその使用を保証し、もう一方の端はそれをサポートしています。PLIとしてのシグナリング画像の損失を好むはずです。FIRは、[RFC5104]のセクション4.3.1.2によると、デコーダーリフレッシュポイントを送信しないとユーザーが使用できない状況でのみ使用する必要があります。
For backwards compatibility with calling devices that do not support the foregoing methods, implementations MUST implement SIP INFO messages to send and receive XML-encoded Picture Fast Update messages according to [RFC5168].
前述のメソッドをサポートしていない呼び出しデバイスとの逆方向の互換性のために、実装はSIP情報メッセージを実装して、[RFC5168]に従ってXMLエンコード画像高速更新メッセージを送信および受信する必要があります。
Support of vCard Extensions to WebDAV (CardDAV) by providers is OPTIONAL.
プロバイダーによるWebDav（cardDav）へのVCard拡張機能のサポートはオプションです。
The RUE MUST and providers MAY be able to synchronize the user's contact directory between the RUE endpoint and one maintained by the user's VRS provider using CardDAV [RFC6352] [RFC6764].
RUEとプロバイダーは、cardDav [RFC6352] [RFC6764]を使用して、ユーザーのVRSプロバイダーによって維持されているRUEエンドポイントと1つのエンドポイントとの間のユーザーの連絡先ディレクトリを同期できる場合があります。
The configuration (see Section 9.2) RueConfigurationData MAY supply a "carddav-username" and "carddav-domain" identifying a CardDAV server and address book for this account, plus an optional "carddav-password".
構成（セクション9.2を参照）RueconFigurationDataは、このアカウントのCardDavサーバーとアドレス帳を識別する「CardDav-Username」および「CardDav-Domain」とオプションの「CardDav-Password」を識別する場合があります。
To access the CardDAV server and address book, the RUE MUST follow Section 6 of [RFC6764], using the configured carddav-username and carddav-domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST continue using matching carddav-username and carddav-password from the configuration. If no carddav-username and carddav-password are configured, the RUE MUST use the SIP user-name and sip-password from the configuration. If the SIP credentials fail, the RUE MUST query the user.
CardDavサーバーとアドレス帳にアクセスするには、RUEは、電子メールアドレスの代わりに構成されたCardDAVユーザー名とCardDav-Domainを使用して、[RFC6764]のセクション6に従う必要があります。リクエストがダイジェスト認証資格情報の課題をトリガーした場合、RUEは構成からCardDav-UsernameとCardDav-Passwordの一致を続ける必要があります。carddav-usernameとcarddav-passwordが構成されていない場合、RUEは構成からSIPユーザー名とSIPパスワードを使用する必要があります。SIP資格情報が失敗した場合、RUEはユーザーを照会する必要があります。
Synchronization using CardDAV MUST be a two-way synchronization service, with proper handling of asynchronous adds, changes, and deletes at either end of the transport channel.
CardDavを使用した同期は、輸送チャネルの両端で非同期の追加、変更、削除を適切に処理する双方向同期サービスでなければなりません。
The RUE MAY support other CardDAV services.
RUEは他のCardDavサービスをサポートする場合があります。
Implementations MUST be able to export/import the list of contacts in xCard [RFC6351] XML format.
実装は、Xcard [RFC6351] XML形式の連絡先のリストをエクスポート/インポートできる必要があります。
The RUE accesses this service via the "contacts-uri" in the configuration. The URL MUST resolve to identify a web server resource that imports/exports contact lists for authorized users.
RUEは、構成の「Contacts-URI」を介してこのサービスにアクセスします。URLは、認定ユーザーの連絡先リストをインポート/エクスポートするWebサーバーリソースを特定するために解決する必要があります。
The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request. If the request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using the "contacts-username" and "contacts-password" from the configuration. If no contacts-username is configured, the SIP user-name from the configuration is used; if the SIP user-name is not configured, the phone-number is used. If user-name or phone-number is used, the sip-password is used to authenticate to the contact list server.
RUEは、HTTPSの投稿またはGetリクエストを発行することにより、連絡先リスト（アドレス帳）を取得します。リクエストがダイジェスト認証資格情報の課題をトリガーした場合、RUEは構成から「連絡先ユーザー名」と「コンタクトパスワード」を使用し続ける必要があります。コンタクトユーザー名が構成されていない場合、構成のSIPユーザー名が使用されます。SIPユーザー名が構成されていない場合、電話番号が使用されます。ユーザー名または電話番号を使用する場合、SIP-Passwordを使用して連絡先リストサーバーに認証されます。
Support for video mail includes a retrieval mechanism and a Message-Waiting Indicator (MWI). Message storage is not specified by this document. RUE devices MUST support message retrieval using a SIP call to a specified SIP URI using DTMF to manage the mailbox, as well as a browser-based interface reached at a specified HTTPS URI. If a provider supports video mail, at least one of these mechanisms MUST be supported. RUE devices MUST support both. See Section 9.2 for how the URI to reach the retrieval interface is obtained.
ビデオメールのサポートには、検索メカニズムとメッセージ待機インジケーター（MWI）が含まれます。メッセージストレージは、このドキュメントで指定されていません。RUEデバイスは、DTMFを使用して指定されたSIP URIへのSIP呼び出しを使用して、メールボックスを管理するメッセージ取得をサポートする必要があります。プロバイダーがビデオメールをサポートする場合、これらのメカニズムの少なくとも1つをサポートする必要があります。RUEデバイスは両方をサポートする必要があります。検索インターフェイスに到達するURIが取得される方法については、セクション9.2を参照してください。
Implementations MUST support subscriptions to "message-summary" events [RFC3842] to the URI specified in the configuration. Providers MUST support MWI if they support video mail. RUE devices MUST support MWI.
実装は、「メッセージスマリー」イベント[RFC3842]へのサブスクリプションを、構成で指定されたURIにサポートする必要があります。プロバイダーは、ビデオメールをサポートする場合はMWIをサポートする必要があります。RUEデバイスはMWIをサポートする必要があります。
The "videomail" and "mwi" properties in the configuration (see RueConfigurationData in Section 9.2.2) give the URIs for message retrieval and "message-summary" subscription.
構成内の「ビデオメイル」および「MWI」プロパティ（セクション9.2.2のRueconFigurationDataを参照）は、メッセージの検索と「メッセージサマリー」サブスクリプションのためにURISを提供します。
In notification bodies, if detailed message summaries are available, messages with video MUST be reported using "message-context-class multimedia-message", as defined in [RFC3458] .
通知機関では、詳細なメッセージの概要が利用可能な場合、[RFC3458]で定義されているように、「メッセージ - コンテキストクラスマルチメディアメサージ」を使用してビデオ付きのメッセージを報告する必要があります。
To simplify how users interact with RUE devices, the RUE interface separates provisioning into two parts. One provides a directory of providers so that a user interface can allow easy provider selection either for registering or for dial-around. The other provides configuration data for the device for each provider.
ユーザーがRUEデバイスと対話する方法を簡素化するために、RUEインターフェイスはプロビジョニングを2つの部分に分離します。ユーザーインターフェイスが登録またはダイヤルアラウンドのいずれかで簡単なプロバイダーの選択を可能にすることができるように、プロバイダーのディレクトリを提供します。もう1つは、各プロバイダーのデバイスの構成データを提供します。
To allow the user to select a relay service, the RUE MAY at any time obtain (typically on startup) a list of providers that provide service in a country. IANA has established a registry that contains a two-letter country code and a list entry point string (see Section 10.1). The entry point, when used with the following OpenAPI interface, returns a list of provider names for a country code suitable for display, with a corresponding entry point to obtain information about that provider. No mechanism to determine the country where the RUE is located is specified in this document. Typically, the country is the home country of the user but may be a local country while traveling. Some countries allow support from their home country when traveling abroad. Regardless, the RUE device will need to allow the user to choose the country.
ユーザーがリレーサービスを選択できるようにするために、RUEはいつでも（通常はスタートアップで）国でサービスを提供するプロバイダーのリストを取得することができます。IANAは、2文字の国コードとリストエントリポイント文字列を含むレジストリを確立しました（セクション10.1を参照）。エントリポイントは、次のOpenAPIインターフェイスで使用される場合、ディスプレイに適した国コードのプロバイダー名のリストを返します。そのプロバイダーに関する情報を取得するための対応するエントリポイントがあります。このドキュメントでは、RUEが位置する国を決定するメカニズムは指定されていません。通常、国はユーザーの母国ですが、旅行中は地方の国である可能性があります。一部の国では、海外旅行中に母国からの支援を許可しています。とにかく、RUEデバイスはユーザーが国を選択できるようにする必要があります。
Each country that supports VRS using this specification MAY support the provider list. This document does not specify who maintains the list. Some possibilities are a regulator or an entity designated by a regulator, an agreement among providers to provide the list, or a user group.
この仕様を使用してVRSをサポートする各国は、プロバイダーリストをサポートする場合があります。このドキュメントでは、誰がリストを維持するかを指定しません。いくつかの可能性は、規制当局または規制当局によって指定されたエンティティ、リストを提供するためのプロバイダー間の合意、またはユーザーグループです。
The interface to obtain the list of providers is described by an OpenAPI [OpenAPI] interface description. In that interface description, the "servers" component includes an occurrence of "localhost". The value from the registry of the "list entry point" string for the desired country is substituted for "localhost" in the "servers" component to obtain the server URI prefix of the interface to be used to obtain the list of providers for that country. The "Providers" path then specifies the rest of the URI used to obtain the list. For example, if the list entryPoint is "example.com/api", the provider list would be obtained from https://example.com/api/rum/v1/Providers.
プロバイダーのリストを取得するためのインターフェイスは、Openapi [Openapi]インターフェイスの説明で説明されています。そのインターフェイスの説明では、「サーバー」コンポーネントには「LocalHost」の発生が含まれます。目的の国の「リストエントリポイント」文字列のレジストリからの値は、「サーバー」コンポーネントの「ローカルホスト」に置き換えられ、その国のプロバイダーのリストを取得するために使用されるインターフェイスのサーバーURIプレフィックスを取得します。「プロバイダー」パスは、リストを取得するために使用されるURIの残りの部分を指定します。たとえば、リストエントリポイントが「example.com/api」の場合、プロバイダーリストはhttps://example.com/api/rum/v1/providersから取得されます。
The V1.0 "ProviderList" is a JSON object consisting of an array where each entry describes one provider. Each entry consists of the following items:
V1.0 "ProviderList"は、各エントリが1つのプロバイダーを記述する配列で構成されるJSONオブジェクトです。各エントリは次の項目で構成されています。
* name: This parameter contains the text label identifying the provider and is meant to be displayed to the human VRS user.
* 名前：このパラメーターには、プロバイダーを識別するテキストラベルが含まれており、Human VRSユーザーに表示されることを目的としています。
* providerEntryPoint: A string used for configuration purposes by the RUE (as discussed in Section 9.2). The string MUST start with a domain but MAY include other URI path elements after the domain.
* ProviderEntryPoint：RUE（セクション9.2で説明したように）が構成目的で使用する文字列。文字列はドメインで開始する必要がありますが、ドメインの後に他のURIパス要素を含めることができます。
The VRS user interacts with the RUE to select from the provider list one or more providers with whom the user has already established an account, wishes to establish an account, or wishes to use the provider for a one-stage dial-around.
VRSユーザーはRUEと対話して、ユーザーがすでにアカウントを確立している、アカウントの確立を希望する1つ以上のプロバイダーをプロバイダーリストから選択します。
{
"providers": [
{
"name": "Red",
"entryPoint": "red.example.net"
},
{
"name": "Green",
"entryPoint": "green.example.net"
},
{
"name": "Blue",
"entryPoint": "blue.example.net"
}
]
}
Figure 2: Example of a ProviderList JSON Object
図2：ProviderList JSONオブジェクトの例
A RUE device may retrieve a provider configuration using a simple HTTPs web service. There are two entry points. One is used without user credentials, and the response includes configuration data for new user signup and dial-around. The other uses a locally stored username and password that results from a new user signup to authenticate to the interface and returns configuration data for the RUE.
RUEデバイスは、単純なHTTPS Webサービスを使用してプロバイダー構成を取得できます。2つのエントリポイントがあります。1つはユーザー資格情報なしで使用され、応答には新しいユーザーサインアップとダイヤルアラウンドの構成データが含まれます。もう1つは、新しいユーザーサインアップから生じるローカルに保存されたユーザー名とパスワードを使用して、インターフェイスに認証し、RUEの構成データを返します。
The interface to obtain configuration data is described by an OpenAPI [OpenAPI] interface description. In that interface description, the "servers" component string includes an occurrence of "localhost". The entry point string obtained from the provider list (Section 9.1) is substituted for "localhost" to obtain the server prefix of the interface. The path then specifies the rest of the URI used to obtain the list. For example, if the entryPoint from the provider list is "red.example.net", the provider configuration would be obtained from https://red.example.net/rum/V1/ProviderConfig and the RUE configuration would be obtained from https://red.example.net/rum/V1/RueConfig.
構成データを取得するインターフェイスは、Openapi [Openapi]インターフェイスの説明によって説明されています。そのインターフェイスの説明では、「サーバー」コンポーネント文字列には「localhost」の発生が含まれます。プロバイダーリスト（セクション9.1）から取得されたエントリポイント文字列は、インターフェイスのサーバープレフィックスを取得するために「localhost」に置き換えられます。パスは、リストを取得するために使用されるURIの残りの部分を指定します。たとえば、プロバイダーリストのエントリポイントが「red.example.net」の場合、プロバイダーの構成はhttps://red.example.net/rum/v1/providerconfigから取得され、rue構成はhttpsから取得されます。：//red.example.net/rum/v1/rueconfig。
In both the queries, an optional parameter may be provided to the interface, which is an API Key (apiKey). The implementation MAY have an apiKey obtained from the provider and specific to the implementation. The method used to obtain the apiKey is not specified in this document. The provider MAY refuse to provide service to an implementation presenting an apiKey it does not recognize.
両方のクエリで、APIキー（Apikey）であるインターフェイスにオプションのパラメーターが提供される場合があります。実装には、プロバイダーから取得され、実装に固有のAPIKEYがある場合があります。このドキュメントでは、Apikeyを取得するために使用される方法は指定されていません。プロバイダーは、認識していないアピケイを提示する実装へのサービスの提供を拒否する場合があります。
Also in both queries, the RUE device provides a client-provided, required parameter, which contains an instance identifier (instanceId). This parameter MUST be the same value each time this instance (same implementation on same device) queries the interface. This MAY be used by the provider, for example, to associate a location with the instance for emergency calls. This should be globally unique. A Universally Unique Identifier (UUID) is suggested.
また、両方のクエリで、RUEデバイスは、インスタンス識別子（InstanceID）を含むクライアントが提供する必要なパラメーターを提供します。このパラメーターは、このインスタンス（同じデバイス上の同じ実装）がインターフェイスをクエリするたびに同じ値である必要があります。これは、たとえば、プロバイダーが場所を緊急通話のインスタンスに関連付けるために使用することができます。これはグローバルにユニークでなければなりません。普遍的に一意の識別子（UUID）が提案されています。
For example, a query for the RUE configuration could be
https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK
t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"
The data returned is a JSON object consisting of key/value configuration parameters to be used by the RUE.
返されるデータは、RUEで使用されるキー/値構成パラメーターで構成されるJSONオブジェクトです。
The configuration data payload includes the following data items. Items not noted as (OPTIONAL) are REQUIRED. If other unexpected items are found, they MUST be ignored.
構成データペイロードには、次のデータ項目が含まれています。（オプション）として記載されていないアイテムが必要です。他の予期しないアイテムが見つかった場合、それらは無視する必要があります。
* signup: (OPTIONAL) an array of JSON objects consisting of:
* サインアップ：（オプション）次のようなJSONオブジェクトの配列
- language: entry from the IANA "Language Subtag Registry" (https://www.iana.org/assignments/language-subtag-registry). Normally, this would be a written language tag.
- 言語：IANA「言語サブタグレジストリ」からのエントリ（https://www.iana.org/assignments/language-subtag-registry）。通常、これは書かれた言語タグになります。
- uri: a URI to the website for creating a new account in the supported language. The new user signup URI may only initiate creation of a new account. Various vetting, approval, and other processes may be needed, which could take time, before the account is established. The result of creating a new account would be account credentials (e.g., username and password), which would be manually entered into the RUE device that forms the authentication parameters for the RUE configuration service described below in Section 9.2.2.
- URI：サポートされている言語で新しいアカウントを作成するためのWebサイトのURI。新しいユーザーサインアップURIは、新しいアカウントの作成のみを開始する場合があります。アカウントが確立される前に、時間がかかる可能性のあるさまざまな審査、承認、およびその他のプロセスが必要になる場合があります。新しいアカウントを作成した結果は、アカウント資格情報（ユーザー名とパスワードなど）になります。これは、セクション9.2.2で説明するRUE構成サービスの認証パラメーターを形成するRUEデバイスに手動で入力されます。
* dial-around: an array of JSON objects consisting of:
* ダイヤルアラウンド：次のようなJSONオブジェクトの配列
- language: entry from the IANA "Language Subtag Registry". Normally, this would be a sign language tag.
- 言語：IANA「言語サブタグレジストリ」からのエントリ。通常、これは手話タグになります。
- front-door: a URI to a queue of interpreters supporting the specified language for a two-stage dial-around.
- フロントドア：2段階のダイヤルアラウンドの指定された言語をサポートする通訳者の列へのURI。
- oneStage: a URI that can be used with a one-stage dial-around (Section 5.2.2) using an interpreter supporting the specified language.
- Onestage：指定された言語をサポートするインタープリターを使用して、1段階のダイヤルアラウンド（セクション5.2.2）で使用できるURI。
* helpDesk: (OPTIONAL) an array of JSON objects consisting of:
* helpdesk ：（オプション）次のようなJSONオブジェクトの配列
- language: entry from the IANA "Language Subtag Registry". Normally, this would be a sign language tag; although, it could be a written language tag if the help desk only supports a chat interface.
- 言語：IANA「言語サブタグレジストリ」からのエントリ。通常、これは手話タグです。ただし、ヘルプデスクがチャットインターフェイスのみをサポートしている場合、それは書かれた言語タグになる可能性があります。
- uri: a URI that reaches a help desk for callers supporting the specified language. The URI MAY be a SIP URI for help provided with a SIP call or MAY be an HTTPS URI for help provided with a browser interface.
- URI：指定された言語をサポートする発信者のヘルプデスクに到達するURI。URIは、SIPコールを提供するヘルプのSIP URIであるか、ブラウザインターフェイスを提供するヘルプのHTTPS URIである場合があります。
A list is specified so that the provider can offer multiple choices to users for language and interface styles.
リストが指定されているため、プロバイダーは言語スタイルとインターフェイススタイルのユーザーに複数の選択肢を提供できます。
* lifetime: (OPTIONAL) specifies how long (in seconds) the RUE MAY cache the configuration values. Values may not be valid when lifetime expires. If the RUE caches configuration values, it MUST cryptographically protect them against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on). The RUE SHOULD retrieve a fresh copy of the configuration before the lifetime expires or as soon as possible after it expires. The lifetime is not guaranteed, i.e., the configuration may change before the lifetime value expires. In that case, the provider MAY indicate this by generating authorization challenges to requests and/or prematurely terminating a registration. Emergency calls MUST continue to work. If not specified, the RUE MUST fetch new configuration data every time it starts.
* Lifetime ：（オプション）RUEが構成値をキャッシュする時間（秒）を指定します。生涯の期限が切れる場合、値は有効ではない場合があります。RUEが構成値をキャッシュする場合、不正な開示から暗号化的に保護する必要があります（たとえば、プラットフォーム上の他のアプリケーションにより、RUEが構築されています）。RUEは、寿命が期限切れになる前、または期限が切れた後、できるだけ早く構成の新鮮なコピーを取得する必要があります。寿命は保証されていません。つまり、生涯値が期限切れになる前に構成が変更される場合があります。その場合、プロバイダーは、リクエストへの承認の課題を生成したり、登録を早めに終了したりすることにより、これを示すことができます。緊急電話は引き続き機能しなければなりません。指定されていない場合、RUEは開始するたびに新しい構成データを取得する必要があります。
* sip-password: (OPTIONAL) a password used for SIP, STUN, and TURN authentication. The RUE device retains this data, which it MUST cryptographically protect against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on). If it is not supplied but was supplied on a prior invocation of this interface, the most recently supplied password MUST be used. If it was never supplied, the password used to authenticate to the configuration service is used for SIP, as well as STUN and TURN servers mentioned in this configuration.
* SIP-PASSWORD ：（オプション）SIP、スタン、およびターン認証に使用されるパスワード。RUEデバイスはこのデータを保持します。これは、不正な開示から暗号化的に保護する必要があります（たとえば、RUEが構築されているプラットフォーム上の他のアプリケーションによって）。提供されていないが、このインターフェイスの事前の呼び出しで提供された場合、最近提供されたパスワードを使用する必要があります。提供されていない場合、構成サービスへの認証に使用されるパスワードは、SIPに使用され、この構成に記載されているスタンおよびターンサーバーが使用されます。
* phone-number: (REQUIRED) the telephone number (in E.164 format) assigned to this subscriber. This becomes the user portion of the SIP URI identifying the subscriber.
* 電話番号：（必須）このサブスクライバーに割り当てられた電話番号（E.164形式）。これは、サブスクライバーを識別するSIP URIのユーザー部分になります。
* user-name: (OPTIONAL) a username used for authenticating to the provider. If not provided, phone-number is used.
* ユーザー名：（オプション）プロバイダーに認証するために使用されるユーザー名。提供されていない場合は、電話番号が使用されます。
* display-name: (OPTIONAL) a human-readable display name for the subscriber.
* display-name ：（オプション）サブスクライバーのヒューマン読み取り可能なディスプレイ名。
* provider-domain: (REQUIRED) the domain for the provider. This becomes the server portion of the SIP URI identifying the subscriber.
* プロバイダードメイン：（必須）プロバイダーのドメイン。これは、サブスクライバーを識別するSIP URIのサーバー部分になります。
* outbound-proxies: (OPTIONAL) an array of URIs of SIP proxies to be used when sending requests to the provider.
* Autbound-Proxies ：（オプション）プロバイダーにリクエストを送信するときに使用するSIPプロキシのURIの配列。
* mwi: (OPTIONAL) a URI identifying a SIP event server that generates "message-summary" events for this subscriber.
* MWI ：（オプション）このサブスクライバーの「メッセージスマリー」イベントを生成するSIPイベントサーバーを識別するURI。
* videomail: (OPTIONAL) a SIP or HTTPS URI that can be used to retrieve video mail messages.
* ビデオメイル：（オプション）ビデオメールメッセージの取得に使用できるSIPまたはHTTPS URI。
* contacts: (OPTIONAL) an HTTPS URI ("contacts-uri"), (OPTIONAL) "contacts-username", and "contacts-password" that may be used to export (retrieve) the subscriber's complete contact list managed by the provider. At least the URI MUST be provided if the subscriber has contacts. If contact-username and contacts-password are not supplied, the sip credentials are used. If the contacts-username is provided, contacts-password MUST be provided. If contacts-password is provided, contacts-username MUST be provided.
* 連絡先：（オプション）https uri（ "Contacts-uri"）、（オプション）「連絡先ユーザー名」、およびプロバイダーが管理するサブスクライバーの完全な連絡先リストをエクスポート（取得）するために使用できる「連絡先パスワード」。サブスクライバーに連絡先がある場合は、少なくともURIを提供する必要があります。連絡先ユーザー名と連絡先のパスワードが提供されていない場合、SIP資格情報が使用されます。連絡先ユーザー名が提供されている場合、連絡先のパスワードを提供する必要があります。Contacts-Passwordが提供されている場合、連絡先ユーザー名を提供する必要があります。
* carddav: (OPTIONAL) an address ("carddav-domain"), (OPTIONAL) "carddav-username", and "carddav-password" identifying a "CardDAV" server and account that can be used to synchronize the RUE's contact list with the contact list managed by the provider. If carddav-username and carddav-password are not supplied, the sip credentials are used. If the carddav-username is provided, carddav-password MUST be provided. If carddav-password is provided, carddav-username MUST be provided.
* cardDav ：（オプション）アドレス（ "carddav-domain"）、（optional） "carddav-username"、および "carddav-password"「carddav」サーバーと「carddav-password」と、RUEの連絡先リストを同期するために使用できるアカウントを識別する「carddav-password」プロバイダーが管理する連絡先リスト。carddav-usernameとcarddav-passwordが提供されていない場合、SIP資格情報が使用されます。carddav-usernameが提供されている場合、carddav-passwordを提供する必要があります。carddav-passwordが提供されている場合、carddav-usernameを提供する必要があります。
* sendLocationWithRegistration: (OPTIONAL) true if the RUE should send a Geolocation header field with REGISTER; false if it should not. Defaults to false if not present.
* sendlocationwithregistration ：（オプション）rueがジオロケーションヘッダーフィールドをレジスタで送信する必要がある場合はtrue。それがすべきではない場合は偽。存在しない場合、デフォルトはfalseになります。
* ice-servers: (OPTIONAL) an array of server types and URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the provider. If the same URL provides both STUN and TURN services, it MUST be listed twice, each with different server types.
* Ice-Servers ：（オプション）プロバイダーを介して通話でメディアストリームを確立するためにRUEが使用できるStunおよびTurnサーバーを識別するサーバータイプとURLの配列。同じURLがStunサービスとターンサービスの両方を提供する場合、それぞれ異なるサーバータイプを持つ2回リストする必要があります。
Both web services also have a simple version mechanism that returns a list of versions of the web service it supports. This document describes version 1.0. Versions are displayed as a major version, followed by a period ".", followed by a minor version, where the major and minor versions are integers. A backwards compatible change within a major version MAY increment only the minor version number. A non-backwards, compatible change MUST increment the major version number. Backwards compatibility applies to both the server and the client. Either may have any higher or lower minor revision and interoperate with its counterpart with the same major version. To achieve backwards compatibility, implementations MUST ignore any object members they do not implement. Minor version definitions SHALL only add objects, optional members of existing objects, and non-mandatory-to-use functions and SHALL NOT delete or change any objects, members of objects, or functions. This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. The version mechanism returns an array of supported versions, one for each major version supported, with the minor version listed being the highest-supported minor version.
どちらのWebサービスにも、サポートするWebサービスのバージョンのリストを返すシンプルなバージョンメカニズムもあります。このドキュメントでは、バージョン1.0について説明しています。バージョンはメジャーバージョンとして表示され、その後に「期間」が続き、その後にマイナーバージョンが続き、メジャーバージョンとマイナーバージョンが整数です。メジャーバージョン内の後方互換の変更により、マイナーバージョン番号のみが増加する場合があります。互換性のない互換性のある変更は、メジャーバージョン番号を増やす必要があります。後方互換性は、サーバーとクライアントの両方に適用されます。より高いまたは低いマイナー改訂を持ち、同じメジャーバージョンでそのカウンターパートと相互運用する場合があります。逆方向の互換性を達成するには、実装が実装していないオブジェクトメンバーを無視する必要があります。マイナーバージョンの定義は、オブジェクト、既存のオブジェクトのオプションのメンバー、および使用しない機能を追加するだけで、オブジェクト、オブジェクト、または関数のメンバーを削除または変更してはなりません。これは、特定のメジャーバージョンの実装とマイナーバージョンがメジャーバージョンのすべてのマイナーバージョンと互換性があることを意味します。バージョンメカニズムは、サポートされている各メジャーバージョン用に1つのサポートされているバージョンの配列を返し、マイナーバージョンは最もサポートされているマイナーバージョンです。
Unless the per-country provider list service is operated by a provider at the same base URI as that provider's configuration service, the version of the configuration service MAY be different from the version of the provider list service.
国ごとのプロバイダーリストサービスがそのプロバイダーの構成サービスと同じベースURIのプロバイダーによって運営されていない限り、構成サービスのバージョンはプロバイダーリストサービスのバージョンとは異なる場合があります。
{
"versions": [
{
"major": 1,
"minor": 6
},
{
"major": 2,
"minor": 13
},
{
"major": 3,
"minor": 2
}
]
}
Figure 3: Example of a Version JSON Object
図3：バージョンJSONオブジェクトの例
{
"signUp": [
{ "language" : "en", "uri" : "https:hello-en.example.net"},
{ "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
"dial-around": [
{ "language" : "en", "front-door" : "sip:fd-en.example.net",
"oneStage" : "sip:1stg-eng.example.com" } ,
{ "language" : "es", "front-door" : "sip:fd-es.example.net",
"oneStage" : "sip:1stg-spn.example.com" } ] ,
"helpDesk": [
{ "language" : "en", "uri" : "sip:help-en.example.net"} ,
{ "language" : "es", "uri" : "sip:help-es.example.net"} ]
}
Figure 4: Example JSON Provider Configuration Payload
図4：JSONプロバイダーの構成ペイロードの例
{
"lifetime": 86400,
"display-name" : "Bob Smith",
"phone-number": "+15551234567",
"provider-domain": "red.example.net",
"outbound-proxies": [
"sip:p1.red.example.net",
"sip:p2.red.example.net" ],
"mwi": "sip:+15551234567@red.example.net;user=phone",
"videomail": "sip:+15551234567@vm.red.example.net;user=phone",
"contacts": {
"contacts-uri":
"https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
"contacts-username": "bob",
"contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb"
},
"carddav": {
"carddav-domain": "carddav.example.com",
"carddav-username": "bob",
"carddav-password": "sj887%dd*jJty%87hyys5hHT"
},
"sendLocationWithRegistration": false,
"ice-servers": [
{"stun":"stun.red.example.com:19302" },
{"turn":"turn.red.example.com:3478"}
]
}
Figure 5: Example JSON RUE Configuration Payload
図5：例JSON RUE構成ペイロード
9.2.5. Using the Provider Selection and RUE Configuration Services Together
9.2.5. プロバイダーの選択とRUE構成サービスを一緒に使用します
One way to use these two services is:
これら2つのサービスを使用する1つの方法は、次のとおりです。
1. At startup, the RUE retrieves the provider list for the country it is located in.
1. スタートアップでは、RUEはそれがある国のプロバイダーリストを取得します。
2. For each provider in the list:
2. リスト内の各プロバイダーについて：
* If the RUE does not have credentials for that provider, if requested by the user, use the ProviderConfig path without credentials to obtain signup, dial-around, and help desk information.
* RUEにそのプロバイダーの資格情報がない場合、ユーザーが要求した場合、資格情報なしでプロバイダーConfigパスを使用して、サインアップ、ダイヤルアラウンド、ヘルプデスク情報を取得します。
* If the RUE has credentials for that provider, use the RueConfig path with the locally stored credentials to configure the RUE for that provider.
* RUEにそのプロバイダーの資格情報がある場合は、ローカルに保存された資格情報を使用してRueconfigパスを使用して、そのプロバイダーのRUEを構成します。
The interfaces in Sections 9.1 and 9.2 are formally specified with OpenAPI 3.0 [OpenAPI] descriptions in YAML form.
セクション9.1および9.2のインターフェイスは、YAML形式のOpenAPI 3.0 [OpenAPI]説明で正式に指定されています。
The OpenAPI description below is normative. If there is any conflict between the text or examples and this section, the OpenAPI description takes precedence.
以下のOpenapiの説明は規範的です。テキストまたは例とこのセクションの間に矛盾がある場合、Openapiの説明が優先されます。
openapi: 3.0.1
info:
title: RUM Provider List API
version: "1.0"
servers:
- url: https://localhost/rum/v1
paths:
/Providers:
get:
summary: Get a list of providers and domains to get
config data from
operationId: GetProviderList
responses:
'200':
description: List of providers for a country
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderList'
/Versions:
servers:
- url: https://localhost/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderList:
type: object
required:
- providers
properties:
providers:
type: array
items:
type: object
required:
- name
- providerEntryPoint
properties:
name:
type: string
description: Human-readable provider name
providerEntryPoint:
type: string
description: Provider entry point for interface
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
Figure 6: Provider List OpenAPI Description (RueProviderList.yaml)
図6：プロバイダーリストOpenapi説明（rueproviderList.yaml）
openapi: 3.0.1
info:
title: RUM Configuration API
version: "1.0"
servers:
- url: https://localhost/rum/v1
paths:
/ProviderConfig:
get:
summary: Configuration data for one provider
operationId: GetProviderConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: Configuration object
content:
application/json:
schema:
$ref:
'#/components/schemas/ProviderConfigurationData'
/RueConfig:
get:
summary: Configuration data for one RUE
operationId: GetRueConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: Configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/RueConfigurationData'
/Versions:
servers:
- url: https://localhost/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderConfigurationData:
type: object
required:
- dial-around
properties:
signup:
type: array
items:
type: object
required:
- language
- uri
properties:
language:
type: string
description: Entry from IANA "Language Subtag
Registry"
uri:
type: string
format: uri
description: URI to signup website supporting
this language
dial-around:
type: array
items:
type: object
required:
- language
- front-door
- oneStage
properties:
language:
type: string
description: Entry from IANA "Language Subtag
Registry"
front-door:
type: string
format: uri
description: SIP URI for two-stage dial-around
oneStage:
type: string
format: uri
description: SIP URI for one-stage dial-around
helpDesk:
type: array
items:
type: object
required:
- language
- uri
properties:
language:
type: string
description: Entry from IANA "Language Subtag
Registry"
uri:
type: string
format: uri
description: SIP URI of help desk supporting language
RueConfigurationData:
type: object
required:
- phone-number
- provider-domain
properties:
lifetime:
type: integer
description: How long (in seconds) the RUE MAY cache the
configuration values
sip-password:
type: string
phone-number:
type: string
description: Telephone number assigned this subscriber in
E.164 format
user-name:
type: string
description: A username assigned to this subscriber
display-name:
type: string
description: Display name for the subscriber
provider-domain:
type: string
description: Domain of the provider for this subscriber
outbound-proxies:
type: array
items:
type: string
format: uri
description: SIP URI of a proxy to be used when sending
requests to the provider
mwi:
type: string
format: uri
description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber
videomail:
type: string
format: uri
description: An HTTPS or SIP URI that can be used to
retrieve video mail messages
contacts:
type: object
description: Server and credentials for contact
import/export
required:
- contacts-uri
properties:
contacts-uri:
type: string
format: uri
description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list
managed by the provider
contacts-username:
type: string
description: Username for authentication with the
CardDAV server. Use SIP user-name if not provided
contacts-password:
type: string
description: Password for authentication. Use provider
sip-password if not provided
carddav:
type: object
description: CardDAV server and user information that can
be used to synchronize the RUE's contact list with
the contact list managed by the provider
required:
- carddav-domain
properties:
carddav-domain:
type: string
description: CardDAV server address
carddav-username:
type: string
description: Username for authentication with the
CardDAV server. Use SIP user-name if not provided
carddav-password:
type: string
description: Password for authentication to the CardDAV
server. Use provider sip-password if not provided
sendLocationWithRegistration:
type: boolean
description: True if the RUE should send a Geolocation
header field with REGISTER; false if it should not.
Defaults to false if not present
ice-servers:
type: array
items:
type: object
required:
- server-type
- uri
properties:
server-type:
type: string
description: Server type ("stun" or "turn")
uri:
type: string
format: uri
description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing
media streams in calls via the provider
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
Figure 7: Configuration OpenAPI Description (RueConfiguration.yaml)
図7：構成OpenAPI説明（rueconfiguration.yaml）
IANA has created the "RUE Provider List" registry. The registration policy is "Expert Review" [RFC8126]. A regulator operated or designated list interface operator is preferred. Otherwise, evidence that the proposed list interface operator will provide a complete list of providers is required to add the entry to the registry. Updates to the registry are permitted if the expert determines that the proposed URI provides a more accurate list than the existing entry. Each entry has two fields; values for both MUST be provided when registering or updating an entry:
IANAは「RUEプロバイダーリスト」レジストリを作成しました。登録ポリシーは「Expert Review」[RFC8126]です。レギュレーターの動作または指定リストインターフェイス演算子が推奨されます。それ以外の場合、提案されたリストインターフェイスオペレーターがプロバイダーの完全なリストを提供するという証拠が、レジストリにエントリを追加するために必要です。提案されたURIが既存のエントリよりも正確なリストを提供すると専門家が判断した場合、レジストリの更新が許可されます。各エントリには2つのフィールドがあります。エントリを登録または更新するときは、両方の値を提供する必要があります。
* country code: a two-letter ISO93166 country code
* 国コード：2文字のISO93166国コード
* list entry point: a string is used to compose the URI to the provider list interface for that country
* リストエントリポイント：文字列は、その国のURIをプロバイダーリストインターフェースに構成するために使用されます
This document defines the new predefined value "rue-owner" for the "purpose" header field parameter of the Call-Info header field. The use for rue-owner is defined in Section 5.2.3. IANA has added a reference to this document in the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" for the header field "Call-Info" and parameter name "purpose".
このドキュメントでは、Call-INFOヘッダーフィールドの「目的」ヘッダーフィールドパラメーターの新しい事前定義値「RUE所有者」を定義します。RUE所有者の使用は、セクション5.2.3で定義されています。IANAは、「ヘッダーフィールドパラメーターとパラメーター値「セッション開始プロトコル（SIP）パラメーター」の「Call-INFO」とパラメーター名「目的」の「ヘッダーフィールドパラメーターとパラメーター値」の参照を追加しました。
Header Field: Call-Info
ヘッダーフィールド：call-info
Parameter Name: purpose
パラメーター名：目的
Predefined Values: Yes
事前定義された値：はい
The RUE is required to communicate with servers on public IP addresses and specific ports to perform its required functions. If it is necessary for the RUE to function on a corporate or other network that operates a default-deny firewall between the RUE and these services, the user must arrange with their network manager for passage of traffic through such a firewall in accordance with the protocols and associated SRV records as exposed by the provider. Because VRS providers may use different ports for different services, these port numbers may differ from provider to provider.
RUEは、パブリックIPアドレスと特定のポートでサーバーと通信して、必要な機能を実行する必要があります。RUEがRUEとこれらのサービスの間にデフォルトのデニーファイアウォールを操作する企業または他のネットワークでRUEが機能する必要がある場合、ユーザーはプロトコルに従ってそのようなファイアウォールを通過するトラフィックの通過のためにネットワークマネージャーと一緒に手配する必要がありますプロバイダーによって公開されていると関連するSRVレコード。VRSプロバイダーはさまざまなサービスに異なるポートを使用する可能性があるため、これらのポート番号はプロバイダーごとに異なる場合があります。
This document requires implementation and use of a number of other specifications in order to fulfill the RUE profile; the security considerations described in those documents apply accordingly to the RUE interactions.
このドキュメントでは、RUEプロファイルを満たすために、他の多くの仕様の実装と使用が必要です。これらのドキュメントで説明されているセキュリティ上の考慮事項は、RUEの相互作用にそれに応じて適用されます。
When a CA participates in a conversation, they have access to the content of the conversation even though it is nominally a conversation between the two endpoints. There is an expectation that the CA will keep the communication contents in confidence. This is usually defined by contractual or legal requirements.
CAが会話に参加すると、名目上2つのエンドポイント間の会話であるにもかかわらず、会話の内容にアクセスできます。CAがコミュニケーションの内容を自信を保つことが期待されています。これは通常、契約または法的要件によって定義されます。
Since different providers (within a given country) may have different policies, RUE implementations MUST include a user interaction step to select from available providers before proceeding to actually register with any given provider.
異なるプロバイダー（特定の国内）には異なるポリシーがある場合があるため、RUE実装には、特定のプロバイダーに実際に登録する前に、利用可能なプロバイダーから選択するためのユーザーインタラクションステップを含める必要があります。
[OpenAPI] Miller, D., Whitlock, J., Gardiner, M., Ralphson, M., Ratovsky, R., and U. Sarid, "OpenAPI Specification v3.0.1", December 2017, <https://spec.openapis.org/oas/v3.0.1>.
[Openapi] Miller、D.、Whitlock、J.、Gardiner、M.、Ralphson、M.、Ratovsky、R。、およびU. Sarid、「Openapi仕様v3.0.1」、2017年12月、<https：// spec.openapis.org/oas/v3.0.1>。
[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.
[RFC2392]レビンソン、E。、「コンテンツIDおよびメッセージIDユニフォームリソースロケーター」、RFC 2392、DOI 10.17487/RFC2392、1998年8月、<https://www.rfc-editor.org/info/rfc2392>
[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：SESSION INTIANIATION Protocol」、RFC 3261、DOI 10.17487/RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、DOI 10.17487/RFC3263、2002年6月、<https：//www.rfc-editor.org/info/RFC3263>。
[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：//www.rfc-editor.org/info/rfc3264>。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、DOI 10.17487/RFC3311、2002年10月、<https://www.rfc-editor.org/info/rfc3311>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487/RFC3323、2002年11月、<https://www.rfc-editor.org/info/RFC3323>。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <https://www.rfc-editor.org/info/rfc3326>.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487/RFC3326、2002年12月、<https：//.rfc-editor.org/info/rfc3326>。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, <https://www.rfc-editor.org/info/rfc3327>.
[RFC3327] Willis、D。およびB. Hoeneisen、「Adjacent Contactsを登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、DOI 10.17487/RFC3327、2002年12月、<https：//www.rfc-editor.org/info/rfc3327>。
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, DOI 10.17487/RFC3458, January 2003, <https://www.rfc-editor.org/info/rfc3458>.
[RFC3458] Burger、E.、Candell、E.、Eliot、C。、およびG. Klyne、「インターネットメールのメッセージコンテキスト」、RFC 3458、DOI 10.17487/RFC3458、2003年1月、<https：//www.rfc-editor.org/info/rfc3458>。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <https://www.rfc-editor.org/info/rfc3515>.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、DOI 10.17487/RFC3515、2003年4月、<https://www.rfc-editor.org/info/rfc3515>
[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）のリアルタイム制御プロトコル（RTCP）属性」、RFC 3605、DOI 10.17487/RFC3605、2003年10月、<https：//www.rfc-editor.org/情報/RFC3605>。
[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：//.rfc-editor.org/info/rfc3840>。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 2004, <https://www.rfc-editor.org/info/rfc3842>.
[RFC3842] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、DOI 10.17487/RFC3842、2004年8月、<https：//www.rfc-editor。org/info/rfc3842>。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://www.rfc-editor.org/info/rfc3891>.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、DOI 10.17487/RFC3891、2004年9月、<https：// www。rfc-editor.org/info/rfc3891>。
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, September 2004, <https://www.rfc-editor.org/info/rfc3892>.
[RFC3892] Sparks、R。、「セッション開始プロトコル（SIP）紹介メカニズム」、RFC 3892、DOI 10.17487/RFC3892、2004年9月、<https://www.rfc-editor.org/info/rfc3892>。
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, <https://www.rfc-editor.org/info/rfc3960>.
[RFC3960] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）の初期メディアとリンギングトーン生成」、RFC 3960、DOI 10.17487/RFC3960、2004年12月、<https：//ww.rfc-editor.org/info/rfc3960>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H。、「電話番号の電話」、RFC 3966、DOI 10.17487/RFC3966、2004年12月、<https://www.rfc-editor.org/info/rfc3966>
[RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, DOI 10.17487/RFC4102, June 2005, <https://www.rfc-editor.org/info/rfc4102>.
[RFC4102]ジョーンズ、P。、「テキスト/レッドマイムサブタイプの登録」、RFC 4102、DOI 10.17487/RFC4102、2005年6月、<https://www.rfc-editor.org/info/rfc4102>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。およびP. Jones、「テキスト会話のRTPペイロード」、RFC 4103、DOI 10.17487/RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, DOI 10.17487/RFC4488, May 2006, <https://www.rfc-editor.org/info/rfc4488>.
[RFC4488] Levin、O。、「セッション開始プロトコルの抑制（SIP）メソッドメソッド暗黙のサブスクリプション」、RFC 4488、DOI 10.17487/RFC4488、2006年5月、<https://www.rfc-editor.org/info/rfc448888888888888>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、doi 10.17487/rfc4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, <https://www.rfc-editor.org/info/rfc4733>.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、テレフォニー信号のRTPペイロード」、RFC 4733、DOI 10.17487/RFC4733、2006年12月、<https://ww.rfc-editor.org/info/rfc4733>。
[RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, DOI 10.17487/RFC4967, July 2007, <https://www.rfc-editor.org/info/rfc4967>.
[RFC4967] Rosen、B。、「セッション開始プロトコルユニフォームリソース識別子のダイヤル文字列パラメーター」、RFC 4967、DOI 10.17487/RFC4967、2007年7月、<https://www.rfc-editor.org/info/rfc4967>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバックを備えたRTPオーディオビジュアルプロファイルのコーデック制御メッセージ」、RFC 5104、DOI 10.17487/RFC5104、2月2月2008、<https://www.rfc-editor.org/info/rfc5104>。
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, DOI 10.17487/RFC5168, March 2008, <https://www.rfc-editor.org/info/rfc5168>.
[RFC5168] Levin、O.、Even、R。、およびP. Hagendorf、「XML Schema for Media Control for Media Control」、RFC 5168、DOI 10.17487/RFC5168、2008年3月、<https://www.rfc-editor.org/情報/RFC5168>。
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, DOI 10.17487/RFC5393, December 2008, <https://www.rfc-editor.org/info/rfc5393>.
[RFC5393] Sparks、R.、Ed。、Ed。、Lawrence、S.、Hawrylyshen、A.、およびB. Campen、「セッション開始プロトコル（SIP）フォーキングプロキシの増幅脆弱性に対処する」、RFC 5393、DOI 10.17487/RFC5393、2008年12月、<https://www.rfc-editor.org/info/rfc5393>。
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>.
[RFC5626] Jennings、C.、Ed。、Mahy、R.、ed。、およびF. Audet、ed。、「セッション開始プロトコル（SIP）のクライアント開始接続の管理」、RFC 5626、DOI 10.17487/RFC5626、2009年10月、<https://www.rfc-editor.org/info/rfc5626>。
[RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing Record-Route Issues in the Session Initiation Protocol (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, <https://www.rfc-editor.org/info/rfc5658>.
[RFC5658] Froment、T.、Lebel、C。、およびB. Bonnaerens、「セッション開始プロトコル（SIP）での記録的な問題への対処」、RFC 5658、DOI 10.17487/RFC5658、2009年10月、<https：///////www.rfc-editor.org/info/rfc5658>。
[RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, <https://www.rfc-editor.org/info/rfc5954>.
[RFC5954] Gurbani、V.、ed。、Ed。、Carpenter、B.、ed。、およびB. Tate、ed。、「RFC 3261のIPv6 ABNFおよびURI比較の本質的な修正」、RFC 5954、DOI 10.17487/RFC5954、8月2010、<https://www.rfc-editor.org/info/rfc5954>。
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <https://www.rfc-editor.org/info/rfc6263>.
[RFC6263] Marjou、X。およびA. Sollaud、「RTP/RTPコントロールプロトコル（RTCP）フローに関連するNATマッピングを維持するためのアプリケーションメカニズム」、RFC 6263、DOI 10.17487/RFC6263、2011年6月、<HTTPS：//www.rfc-editor.org/info/rfc6263>。
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, <https://www.rfc-editor.org/info/rfc6351>.
[RFC6351] Perreault、S。、 "xcard：vcard xml表現"、rfc 6351、doi 10.17487/rfc6351、2011年8月、<https://www.rfc-editor.org/info/rfc6351>
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011, <https://www.rfc-editor.org/info/rfc6352>.
[RFC6352] Daboo、C。、「carddav：vcard拡張機能へのvcard拡張作家とバージョン（webdav）」、RFC 6352、doi 10.17487/rfc6352、<https：//www.rfc-editor.org/info/RFC6352>。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>.
[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルの位置輸送」、RFC 6442、DOI 10.17487/RFC6442、2011年12月、<https：//www.rfc-editor。org/info/rfc6442>。
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <https://www.rfc-editor.org/info/rfc6665>.
[RFC6665]ローチ、A.B。、「SIP固有のイベント通知」、RFC 6665、DOI 10.17487/RFC6665、2012年7月、<https://www.rfc-editor.org/info/rfc665>。
[RFC6764] Daboo, C., "Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, <https://www.rfc-editor.org/info/rfc6764>.
[RFC6764] Daboo、C。、「webdav（caldav）への拡張機能のカレンダーの配置サービス（caldav）およびvcard拡張機能の配置webdav（carddav）」、rfc 6764、doi 10.17487/rfc6764、2013年2月、<https：//ww.rfc-editor.org/info/rfc6764>。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <https://www.rfc-editor.org/info/rfc6881>.
[RFC6881] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の実践」、BCP 181、RFC 6881、DOI 10.17487/RFC6881、2013年3月、<https：//www.rfc-editor.org/info/rfc6881>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「輸送層セキュリティ（TLS）およびデータグラム輸送層のセキュリティ（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487/RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, September 2015, <https://www.rfc-editor.org/info/rfc7647>.
[RFC7647] Sparks、R。およびA.B.Roach、「RFC 6665での参照を使用するための説明」、RFC 7647、DOI 10.17487/RFC7647、2015年9月、<https://www.rfc-editor.org/info/rfc7647>。
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>.
[RFC7742] Roach、A.B。、「Webrtcビデオ処理およびコーデック要件」、RFC 7742、DOI 10.17487/RFC7742、2016年3月、<https://www.rfc-editor.org/info/rfc7742>
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>.
[RFC7852] Gellens、R.、Rosen、B.、Tschofenig、H.、Marshall、R.、およびJ. Winterbottom、「緊急コールに関連する追加データ」、RFC 7852、DOI 10.17487/RFC7852、2016年7月、<https://www.rfc-editor.org/info/rfc7852>。
[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <https://www.rfc-editor.org/info/rfc7874>.
[RFC7874] Valin、JM。およびC. Bran、「Webrtcオーディオコーデックおよび処理要件」、RFC 7874、DOI 10.17487/RFC7874、2016年5月、<https://www.rfc-editor.org/info/rfc7874>。
[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] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Indecivity Indecivity Indecivity（ICE）：ネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 8445、DOI 10.17487/RFC8445、2018年7月、<<<<https://www.rfc-editor.org/info/rfc8445>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the Session Initiation Protocol (SIP)", RFC 8599, DOI 10.17487/RFC8599, May 2019, <https://www.rfc-editor.org/info/rfc8599>.
[RFC8599] Holmberg、C。およびM. Arnold、「セッション開始プロトコル（SIP）によるプッシュ通知」、RFC 8599、DOI 10.17487/RFC8599、2019年5月、<https://www.rfc-editor.org/info/RFC8599>。
[RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) Digest Access Authentication Scheme", RFC 8760, DOI 10.17487/RFC8760, March 2020, <https://www.rfc-editor.org/info/rfc8760>.
[RFC8760] Shekh-Yusef、R。、「セッション開始プロトコル（SIP）ダイジェストアクセス認証スキーム」、RFC 8760、DOI 10.17487/RFC8760、2020年3月、<https://www.rfc-editor.org/info/RFC8760>。
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.
[RFC8825] Alvestrand、H。、「概要：ブラウザベースのアプリケーション用のリアルタイムプロトコル」、RFC 8825、DOI 10.17487/RFC8825、2021年1月、<https://www.rfc-editor.org/info/rfc825>。
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[RFC8827] Rescorla、E。、「Webrtc Security Architecture」、RFC 8827、DOI 10.17487/RFC8827、2021年1月、<https://www.rfc-editor.org/info/rfc827>。
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, <https://www.rfc-editor.org/info/rfc8829>.
[RFC8829] Uberti、J.、Jennings、C。、およびE. Rescorla、ed。、「JavaScript Session Enditivent Protocol（JSEP）」、RFC 8829、DOI 10.17487/RFC8829、2021年1月、<https：//ww.rfc-editor.org/info/rfc8829>。
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8834] Perkins、C.、Westerlund、M。、およびJ. Ott、「WebrtcでのRTPのメディア輸送と使用」、RFC 8834、DOI 10.17487/RFC8834、2021年1月、<https：//www.rfc-editor.org/info/rfc8834>。
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, January 2021, <https://www.rfc-editor.org/info/rfc8835>.
[RFC8835] Alvestrand、H。、「Webrtcの輸送」、RFC 8835、DOI 10.17487/RFC8835、2021年1月、<https://www.rfc-editor.org/info/rfc835>。
[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>。
[RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text Conversation over WebRTC Data Channels", RFC 8865, DOI 10.17487/RFC8865, January 2021, <https://www.rfc-editor.org/info/rfc8865>.
[RFC8865] Holmberg、C。and G.Hellström、「T.140 Webrtcデータチャネルを介したリアルタイムテキスト会話」、RFC 8865、DOI 10.17487/RFC8865、2021年1月、<https：//www.rfc-editor.org/info/rfc8865>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C.、およびM. Handley、「SDP：SESSION説明プロトコル」、RFC 8866、DOI 10.17487/RFC866、2021年1月、<https：//www.rfc8866-editor.org/info/rfc8866>。
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real-Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, <https://www.rfc-editor.org/info/rfc9071>.
[RFC9071]Hellström、G。、「MultipartyリアルタイムテキストのRTP-Mixerフォーマット」、RFC 9071、DOI 10.17487/RFC9071、2021年7月、<https://www.rfc-editor.org/info/rfc9071>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9112] Fielding、R.、Ed。、Ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<https：//www.rfc-editor.org/info/rfc9112>。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC3665] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C.、およびK. Summers、「セッション開始プロトコル（SIP）基本的なコールフローの例」、BCP 75、RFC 3665、DOI 10.17487/RFC3665、2003年12月、<https://www.rfc-editor.org/info/rfc3665>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
Acknowledgements
謝辞
Brett Henderson and Jim Malloy provided many helpful edits to prior draft versions of this document. Paul Kyzivat provided extensive reviews and comments.
ブレット・ヘンダーソンとジム・マロイは、このドキュメントの以前のドラフトバージョンに多くの有用な編集を提供しました。Paul Kyzivatは、広範なレビューとコメントを提供しました。
Author's Address
著者の住所
Brian Rosen 470 Conrad Dr Mars, PA 16046 United States of America Email: br@brianrosen.net
Brian Rosen 470 Conrad Dr Mars、PA 16046アメリカ合衆国電子メール：br@brianrosen.net