[要約] RFC 8373は、リアルタイムコミュニケーションにおける人間の言語の交渉に関する要約です。その目的は、異なる言語を話す人々が効果的にコミュニケーションできるようにするためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8373 Core Technology Consulting
Category: Standards Track May 2018
ISSN: 2070-1721
Negotiating Human Language in Real-Time Communications
リアルタイム通信における人間の言語の交渉
Abstract
概要
Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).
ユーザーは、話し言葉、書き言葉、および手話の言語に関して、さまざまな人間（つまり、自然）言語のニーズ、能力、および好みを持っています。このドキュメントでは、新しいセッション記述プロトコル（SDP）のメディアレベルの属性を定義しているため、インタラクティブな通信セッション（「通話」）を確立するときに、発信者の言語とメディアのニーズについて、着信側。これは、緊急通話の場合に特に重要です。これは、ユーザーと通信できる通話係が通話を処理したり、セットアップ中に翻訳者や中継オペレーターを通話にブリッジしたりできるためです。ただし、これは緊急ではない通話（会社のコールセンターへの通話など）にも適用されます。
This document describes the need as well as a solution that uses new SDP media attributes.
このドキュメントでは、新しいSDPメディア属性を使用する必要性とソリューションについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8373.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8373で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Desired Semantics . . . . . . . . . . . . . . . . . . . . . . 5
4. The Existing 'lang' Attribute . . . . . . . . . . . . . . . . 5
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The 'hlang-send' and 'hlang-recv' Attributes . . . . . . 5
5.2. No Language in Common . . . . . . . . . . . . . . . . . . 7
5.3. Usage Notes . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. att-field Subregistry of SDP Parameters . . . . . . . . . 10
6.2. Warning Codes Subregistry of SIP Parameters . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
A mutually comprehensible language is helpful for human communication. This document addresses the negotiation of human language and media modality (spoken, signed, or written) in real-time communications. A companion document [RFC8255] addresses language selection in email.
相互理解可能な言語は、人間のコミュニケーションに役立ちます。このドキュメントでは、リアルタイムコミュニケーションにおける人間の言語とメディアモダリティ（音声、署名、または書面）の交渉について説明します。コンパニオンドキュメント[RFC8255]は、電子メールでの言語選択を扱います。
Unless the caller and callee know each other or there is contextual or out-of-band information from which the language(s) and media modalities can be determined, there is a need for spoken, signed, or written languages to be negotiated based on the caller's needs and the callee's capabilities. This need applies to both emergency and non-emergency calls. An example of a non-emergency call is when a caller contacts a company call center; an emergency call typically involves a caller contacting a Public Safety Answering Point (PSAP). In such scenarios, it is helpful for the caller to be able to indicate preferred signed, written, and/or spoken languages and for the callee to be able to indicate its capabilities; this allows the call to proceed using the language(s) and media forms supported by both.
発信者と着信者がお互いを知っているか、または言語とメディアモダリティを決定できるコンテキスト情報または帯域外情報がある場合を除いて、音声、署名、または書面による言語は、以下に基づいて交渉する必要があります。呼び出し元のニーズと呼び出し先の機能。このニーズは、緊急通話と非緊急通話の両方に当てはまります。非緊急通話の例は、発信者が会社のコールセンターに連絡した場合です。緊急コールには、通常、発信者が公衆安全応答ポイント（PSAP）に連絡することが含まれます。そのようなシナリオでは、発信者が優先される署名済み言語、書き言葉、および/または話された言語を示すことができ、着信者がその機能を示すことができると便利です。これにより、両方でサポートされている言語とメディアフォームを使用して通話を進めることができます。
For various reasons, including the ability to establish multiple streams using different media (i.e., voice, text, and/or video), it makes sense to use a per-stream negotiation mechanism known as the Session Description Protocol (SDP). Utilizing SDP [RFC4566] enables the solution described in this document to be applied to all interactive communications negotiated using SDP, in emergency as well as non-emergency scenarios.
さまざまなメディア（音声、テキスト、ビデオなど）を使用して複数のストリームを確立する機能など、さまざまな理由により、セッション記述プロトコル（SDP）と呼ばれるストリームごとのネゴシエーションメカニズムを使用することは理にかなっています。 SDP [RFC4566]を利用すると、このドキュメントで説明されているソリューションを、緊急シナリオと非緊急シナリオの両方で、SDPを使用してネゴシエートされるすべての対話型通信に適用できます。
By treating language as another SDP attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called-party facilities. For example, some users may be able to speak several languages but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or they may have a limited number of call takers able to use certain languages. Another example would be a user who is able to speak but is deaf or hard of hearing and desires a voice stream to send spoken language plus a text stream to receive written language. Making language a media attribute allows standard session negotiation to handle this by providing the information and mechanism for the endpoints to make appropriate decisions.
言語をメディアストリームの他の側面と一緒にネゴシエートされる別のSDP属性として扱うことにより、さまざまなユーザーのニーズと着信側機能に対応することが可能になります。たとえば、一部のユーザーは複数の言語を話すことができても、好みを持っている場合があります。一部の着信側は、これらの言語の一部を内部でサポートしているが、他の言語の翻訳サービスを使用する必要がある場合や、特定の言語を使用できる限られた数の通話係がいる場合があります。別の例は、話すことはできるが聴覚障害者または難聴者であり、音声ストリームを送信するための音声ストリームと、書き言葉を受信するためのテキストストリームを希望するユーザーです。言語をメディア属性にすると、エンドポイントが適切な決定を行うための情報とメカニズムを提供することにより、標準のセッションネゴシエーションでこれを処理できます。
The term "negotiation" is used here rather than "indication" because human language (spoken/written/signed) can be negotiated in the same manner as media (audio/text/video) and codecs. For example, if we think of a user calling an airline reservation center, the user may be able to use a set of languages, perhaps with preferences for one or a few, while the airline reservation center may support a fixed set of languages. Negotiation should select the user's most preferred language that is supported by the call center. Both sides should be aware of which language was negotiated.
ここでは「指示」ではなく「交渉」という用語を使用します。これは、人間の言語（音声/筆記/署名）がメディア（オーディオ/テキスト/ビデオ）およびコーデックと同じ方法で交渉できるためです。たとえば、ユーザーが航空会社の予約センターに電話をかける場合、ユーザーは言語のセットを使用できますが、おそらく1つまたはいくつかの設定で、航空会社の予約センターが固定の言語のセットをサポートしている場合があります。ネゴシエーションでは、コールセンターでサポートされているユーザーの最も優先される言語を選択する必要があります。どちらの側も交渉された言語を認識している必要があります。
In the offer/answer model used here, the offer contains a set of languages per media (and direction) that the offerer is capable of using, and the answer contains one language per media (and direction) that the answerer will support. Supporting languages and/or modalities can require taking extra steps, such as bridging external translation or relay resources into the call or having a call handled by an agent who speaks a requested language and/or has the ability to use a requested modality. The answer indicates the media and languages that the answerer is committing to support (possibly after additional steps have been taken). This model also provides knowledge so both ends know what has been negotiated. Note that additional steps required to support the indicated languages or modalities may or may not be in place in time for any early media.
ここで使用するオファー/アンサーモデルでは、オファーには、メディア（および方向）ごとにオファー者が使用できる言語のセットが含まれ、アンサーには、メディア（および方向）ごとに1つの言語が含まれます。言語やモダリティをサポートするには、外部翻訳やリレーリソースを通話にブリッジする、要求された言語を話すエージェントや、要求されたモダリティを使用できるエージェントが通話を処理するなど、追加の手順が必要になる場合があります。回答は、回答者がサポートに取り組んでいるメディアと言語を示します（追加の手順が実行された後など）。このモデルは知識も提供するので、両端が交渉されたものを知ることができます。示された言語またはモダリティをサポートするために必要な追加の手順が、初期のメディアに間に合うように配置されている場合とそうでない場合があることに注意してください。
Since this is a protocol mechanism, the user equipment (UE) client needs to know the user's preferred languages; while this document does not address how clients determine this, reasonable techniques could include a configuration mechanism with a default of the language of the user interface. In some cases, a UE client could tie language and media preferences, such as a preference for a video stream using a signed language and/or a text or audio stream using a written/spoken language.
これはプロトコルメカニズムであるため、ユーザー機器（UE）クライアントはユーザーの優先言語を知る必要があります。このドキュメントでは、クライアントがこれをどのように決定するかについては触れていませんが、合理的な手法には、ユーザーインターフェイスの言語のデフォルトの構成メカニズムを含めることができます。場合によっては、UEクライアントは、署名された言語を使用するビデオストリームや、記述/音声言語を使用するテキストまたはオーディオストリームの設定など、言語とメディアの設定を関連付けることができます。
This document does not address user interface (UI) issues, such as if or how a UE client informs a user about the result of language and media negotiation.
このドキュメントでは、言語およびメディアネゴシエーションの結果についてUEクライアントがユーザーに通知するかどうか、またはどのようにユーザーに通知するかなど、ユーザーインターフェイス（UI）の問題は扱いません。
Within this document, it is assumed that the negotiating endpoints have already been determined so that a per-stream negotiation based on SDP can proceed.
このドキュメントでは、SDPに基づくストリームごとのネゴシエーションを続行できるように、ネゴシエーションエンドポイントがすでに決定されていると想定しています。
When setting up interactive communication sessions, it is necessary to route signaling messages to the appropriate endpoint(s). This document does not address the problem of language-based routing.
対話型通信セッションを設定する場合、シグナリングメッセージを適切なエンドポイントにルーティングする必要があります。このドキュメントでは、言語ベースのルーティングの問題は扱いません。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The desired solution is a media attribute (preferably per direction) that may be used within an offer to indicate the preferred language(s) of each (direction of a) media stream and within an answer to indicate the accepted language. When multiple languages are included for a media stream within an offer, the languages are listed in order of preference (most preferred first).
望ましい解決策は、メディアストリーム（方向ごと）のメディア属性です。オファー内で各メディアストリームの（使用する方向）の優先言語を示すために使用することができます。オファー内のメディアストリームに複数の言語が含まれている場合、言語は優先順にリストされます（最初に優先される）。
Note that negotiating multiple simultaneous languages within a media stream is out of scope of this document.
メディアストリーム内で複数の言語を同時にネゴシエートすることは、このドキュメントの範囲外であることに注意してください。
RFC 4566 [RFC4566] specifies an attribute 'lang' that is similar to what is needed here but is not sufficiently specific or flexible for the needs of this document. In addition, 'lang' is not mentioned in [RFC3264], and there are no known implementations in SIP. Further, it is useful to be able to specify language per direction (sending and receiving). This document therefore defines two new attributes.
RFC 4566 [RFC4566]は、ここで必要なものと同様の属性「lang」を指定していますが、このドキュメントのニーズに対して十分に具体的または柔軟ではありません。さらに、[lang]は[RFC3264]で言及されておらず、SIPでの既知の実装はありません。さらに、方向（送信と受信）ごとに言語を指定できると便利です。したがって、このドキュメントでは2つの新しい属性を定義しています。
An SDP attribute (per direction) seems the natural choice to negotiate human language of an interactive media stream, using the language tags of [BCP47].
SDP属性（方向ごと）は、[BCP47]の言語タグを使用して、インタラクティブメディアストリームの人間の言語をネゴシエートするための自然な選択のようです。
This document defines two media-level attributes: 'hlang-send' and 'hlang-recv' (registered in Section 6). Both start with 'hlang', short for "human language". These attributes are used to negotiate which human language is selected for use in (each direction of) each interactive media stream. (Note that not all streams will necessarily be used.) Each can appear for media streams in offers and answers.
このドキュメントでは、「hlang-send」と「hlang-recv」（セクション6で登録済み）の2つのメディアレベル属性を定義しています。どちらも「hlang」で始まり、「人間の言語」の略です。これらの属性は、各インタラクティブメディアストリーム（の各方向）で使用するために選択された人間の言語をネゴシエートするために使用されます。 （すべてのストリームが必ずしも使用されるわけではないことに注意してください。）それぞれがオファーとアンサーのメディアストリームに表示されます。
In an offer, the 'hlang-send' value is a list of one or more language(s) the offerer is willing to use when sending using the media, and the 'hlang-recv' value is a list of one or more language(s) the offerer is willing to use when receiving using the media. The list of languages is in preference order (first is most preferred). When a media is intended for interactive communication in only one direction (e.g., a user in France with difficulty speaking but able to hear who indicates a desire to receive French using audio and send French using text), either 'hlang-send' or 'hlang-recv' MAY be omitted. Note that the media can still be useful in both directions. When a media is not primarily intended for language (for example, a video or audio stream intended for background only), both SHOULD be omitted. Otherwise, both SHOULD have the same value. Note that specifying different languages for each direction (as opposed to the same, or essentially the same, language in different modalities) can make it difficult to complete the call (e.g., specifying a desire to send audio in Hungarian and receive audio in Portuguese).
オファーでは、「hlang-send」値は、オファー提供者がメディアを使用して送信するときに使用する1つ以上の言語のリストであり、「hlang-recv」値は1つ以上の言語のリストです（s）提供者は、メディアを使用して受信するときに使用することをいとわない。言語のリストは優先順です（最初が最も優先されます）。メディアが一方向のみの双方向通信を目的としている場合（たとえば、話すのが難しいが、オーディオを使用してフランス語を受信し、テキストを使用してフランス語を送信したいという意思を示すことができるフランスのユーザー）、 'hlang-send'または ' hlang-recv 'は省略できます。ただし、メディアは両方向で役立つ場合があります。メディアが主に言語を対象としていない場合（たとえば、背景のみを対象としたビデオまたはオーディオストリーム）、両方を省略してください。それ以外の場合は、両方の値が同じである必要があります（SHOULD）。各方向に異なる言語を指定すると（異なるモダリティで同じまたは本質的に同じ言語とは対照的に）、通話を完了するのが困難になる可能性があります（たとえば、ハンガリー語でオーディオを送信し、ポルトガル語でオーディオを受信するという指定） 。
In an answer, 'hlang-send' is the language the answerer will send if using the media for language (which in most cases is one of the languages in the offer's 'hlang-recv'), and 'hlang-recv' is the language the answerer expects to receive if using the media for language (which in most cases is one of the languages in the offer's 'hlang-send').
回答では、「hlang-send」は言語用のメディアを使用する場合に回答者が送信する言語（ほとんどの場合、オファーの「hlang-recv」の言語の1つです）であり、「hlang-recv」は言語用のメディアを使用する場合に回答者が受け取ることを期待する言語（ほとんどの場合、オファーの「hlang-send」の言語の1つです）。
In an offer, each value MUST be a list of one or more language tags per [BCP47], separated by white space. In an answer, each value MUST be one language tag per [BCP47]. [BCP47] describes mechanisms for matching language tags. Note that Section 4.1 of RFC 5646 [BCP47] advises to "tag content wisely" and not include unnecessary subtags.
オファーでは、各値は[BCP47]ごとに1つ以上の言語タグのリストであり、空白で区切られている必要があります。回答では、各値は[BCP47]ごとに1つの言語タグでなければなりません。 [BCP47]は、言語タグを照合するためのメカニズムを説明しています。 RFC 5646 [BCP47]のセクション4.1では、「コンテンツに賢明にタグを付ける」ことを推奨しており、不要なサブタグは含めないでください。
When placing an emergency call, and in any other case where the language cannot be inferred from context, each OFFERed media stream primarily intended for human language communication SHOULD specify the 'hlang-send' and/or 'hlang-recv' attributes for the direction(s) intended for interactive communication.
緊急電話をかけるとき、およびコンテキストから言語を推測できないその他の場合は、主に人間の言語によるコミュニケーションを目的とした各提供メディアストリームで、方向の「hlang-send」属性または「hlang-recv」属性を指定する必要があります（SHOULD）。 （s）インタラクティブなコミュニケーションを目的としています。
Clients acting on behalf of end users are expected to set one or both of the 'hlang-send' and 'hlang-recv' attributes on each OFFERed media stream primarily intended for human communication when placing an outgoing session, and either ignore or take into consideration the attributes when receiving incoming calls, based on local configuration and capabilities. Systems acting on behalf of call centers and PSAPs are expected to take the attributes into account when processing inbound calls.
エンドユーザーに代わって行動するクライアントは、発信セッションを配置するときに主に人間のコミュニケーションを目的とした各OFFERedメディアストリームに「hlang-send」属性と「hlang-recv」属性のいずれかまたは両方を設定し、無視するか、または取り込むことが期待されますローカルの構成と機能に基づいて、着信呼び出しを受信するときの属性を検討します。コールセンターとPSAPに代わって動作するシステムは、インバウンドコールを処理するときに属性を考慮することが求められます。
Note that media and language negotiation might result in more media streams being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted). This is not a problem.
メディアと言語のネゴシエーションにより、ユーザーが必要とするよりも多くのメディアストリームが受け入れられる可能性があることに注意してください（たとえば、メディアと言語のより好ましい組み合わせとあまり好ましくない組み合わせがすべて受け入れられる場合）。これは問題ありません。
A consideration regarding the ability to negotiate language is whether the call proceeds or fails if the callee does not support any of the languages requested by the caller. This document does not mandate either behavior.
言語をネゴシエートする機能に関する考慮事項は、呼び出し先が呼び出し元から要求された言語をサポートしていない場合に、呼び出しが続行するか失敗するかです。このドキュメントではどちらの動作も必須ではありません。
When a call is rejected due to lack of any language in common, the SIP response has SIP response code 488 (Not Acceptable Here) or 606 (Not Acceptable) [RFC3261] and a Warning header field [RFC3261] with a warning code of 308 and warning text indicating that there are no mutually supported languages; the warning text SHOULD also contain the supported languages and media.
共通の言語がないために通話が拒否された場合、SIP応答にはSIP応答コード488（ここでは受け入れられません）または606（受け入れられません）[RFC3261]と警告コード308の警告ヘッダーフィールド[RFC3261]があります。相互にサポートされている言語がないことを示す警告テキスト。警告テキストには、サポートされている言語とメディアも含める必要があります。
Example:
例：
Warning: 308 proxy.example.com "Incompatible language
specification: Requested languages not supported. Supported
languages are: es, en; supported media are: audio, text."
A sign-language tag with a video media stream is interpreted as an indication for sign language in the video stream. A non-sign-language tag with a text media stream is interpreted as an indication for written language in the text stream. A non-sign-language tag with an audio media stream is interpreted as an indication for spoken language in the audio stream.
ビデオメディアストリームの手話タグは、ビデオストリームの手話を示すものとして解釈されます。テキストメディアストリームを含む手話以外のタグは、テキストストリームで書かれた言語を示すものとして解釈されます。音声メディアストリームを含む手話以外のタグは、音声ストリーム内の話し言葉を示すものとして解釈されます。
This document does not define any other use for language tags in video media (such as how to indicate visible captions in the video stream).
このドキュメントでは、ビデオメディアの言語タグの他の使用法（ビデオストリームで表示されるキャプションを示す方法など）を定義していません。
This document does not define the use of sign-language tags in text or audio media.
このドキュメントでは、テキストまたはオーディオメディアでの手話タグの使用を定義していません。
In the IANA registry for language subtags per [BCP47], a language subtag with a Type field "extlang" combined with a Prefix field value "sgn" indicates a sign-language tag. The absence of such "sgn" prefix indicates a non-sign-language tag.
[BCP47]による言語サブタグのIANAレジストリでは、Typeフィールドが「extlang」で、言語フィールドがPrefixフィールドの値が「sgn」である言語サブタグは、手話タグを示します。このような「sgn」接頭辞がない場合は、手話でないタグを示しています。
This document does not define the use of language tags in media other than interactive streams of audio, video, and text (such as "message" or "application"). Such use could be supported by future work or by application agreement.
このドキュメントでは、オーディオ、ビデオ、テキストのインタラクティブストリーム（「メッセージ」や「アプリケーション」など）以外のメディアでの言語タグの使用については定義していません。このような使用は、将来の作業またはアプリケーション契約によってサポートされる可能性があります。
Some examples are shown below. For clarity, only the most directly relevant portions of the SDP block are shown.
以下にいくつかの例を示します。明確にするために、SDPブロックの最も直接関連する部分のみを示しています。
An offer or answer indicating spoken English both ways:
両方向で英語を話していることを示す提案または回答：
m=audio 49170 RTP/AVP 0
a=hlang-send:en
a=hlang-recv:en
An offer indicating American Sign Language both ways:
アメリカ手話を両方の方法で示すオファー：
m=video 51372 RTP/AVP 31 32
a=hlang-send:ase
a=hlang-recv:ase
An offer requesting spoken Spanish both ways (most preferred), spoken Basque both ways (second preference), or spoken English both ways (third preference):
双方向のスペイン語（最も好ましい）、双方向のバスク語（2番目に優先）、または双方向の英語（3番目に優先）を要求するオファー：
m=audio 49250 RTP/AVP 20
a=hlang-send:es eu en
a=hlang-recv:es eu en
An answer to the above offer indicating spoken Spanish both ways:
上記のオファーへの回答は、スペイン語を双方向で話すことを示しています。
m=audio 49250 RTP/AVP 20
a=hlang-send:es
a=hlang-recv:es
An alternative answer to the above offer indicating spoken Italian both ways (as the callee does not support any of the requested languages but chose to proceed with the call):
上記のオファーに対する別の回答は、イタリア語の音声を双方向で示す（呼び出し先は要求された言語をサポートしていないが、呼び出しを続行することを選択したため）：
m=audio 49250 RTP/AVP 20
a=hlang-send:it
a=hlang-recv:it
An offer or answer indicating written Greek both ways:
ギリシャ語で書かれた両方の方法を示す提案または回答：
m=text 45020 RTP/AVP 103 104
a=hlang-send:gr
a=hlang-recv:gr
An offer requesting the following media streams: video for the caller to send using Argentine Sign Language, text for the caller to send using written Spanish (most preferred) or written Portuguese, and audio for the caller to receive spoken Spanish (most preferred) or spoken Portuguese:
次のメディアストリームを要求するオファー：発信者がアルゼンチン手話を使用して送信するビデオ、発信者がスペイン語（最も好ましい）またはポルトガル語を使用して送信するテキスト、および発信者がスペイン語（最も好ましい）を受信するための音声またはポルトガル語話者：
m=video 51372 RTP/AVP 31 32
a=hlang-send:aed
m=text 45020 RTP/AVP 103 104
a=hlang-send:sp pt
m=audio 49250 RTP/AVP 20
a=hlang-recv:sp pt
An answer for the above offer, indicating text in which the callee will receive written Spanish and audio in which the callee will send spoken Spanish. (The answering party has no video capability):
上記のオファーに対する回答。呼び出し先がスペイン語の書面を受け取るテキストと、呼び出し先がスペイン語の音声を送信する音声を示します。 （応答側にはビデオ機能がありません）：
m=video 0 RTP/AVP 31 32
m=text 45020 RTP/AVP 103 104
a=hlang-recv:sp
m=audio 49250 RTP/AVP 20
a=hlang-send:sp
An offer requesting the following media streams: text for the caller to send using written English (most preferred) or written Spanish, audio for the caller to receive spoken English (most preferred) or spoken Spanish, and supplemental video:
次のメディアストリームを要求するオファー：発信者が書かれた英語（最も好ましい）または書かれたスペイン語を使用して送信するテキスト、発信者が話される英語（最も望ましい）または話されるスペイン語を受信するための音声、および補足ビデオ：
m=text 45020 RTP/AVP 103 104
a=hlang-send:en sp
m=audio 49250 RTP/AVP 20
a=hlang-recv:en sp
m=video 51372 RTP/AVP 31 32
m =ビデオ51372 RTP / AVP 31 32
An answer for the above offer, indicating text in which the callee will receive written Spanish, audio in which the callee will send spoken Spanish, and supplemental video:
上記のオファーに対する回答。呼び出し先がスペイン語の書面を受け取るテキスト、呼び出し先がスペイン語を話す音声、および補足ビデオを示します。
m=text 45020 RTP/AVP 103 104
a=hlang-recv:sp
m=audio 49250 RTP/AVP 20
a=hlang-send:sp
m=video 51372 RTP/AVP 31 32
m =ビデオ51372 RTP / AVP 31 32
Note that, even though the examples show the same (or essentially the same) language being used in both directions (even when the modality differs), there is no requirement that this be the case. However, in practice, doing so is likely to increase the chances of successful matching.
例では両方向で使用されている同じ（または基本的に同じ）言語を示していますが（モダリティが異なる場合でも）、これが当てはまる必要はないことに注意してください。ただし、実際には、そうすることでマッチングが成功する可能性が高くなります。
The syntax in this section uses ABNF per RFC 5234 [RFC5234].
このセクションの構文では、RFC 5234 [RFC5234]に従ってABNFを使用しています。
IANA has added two entries to the "att-field (media level only)" subregistry of the "Session Description Protocol (SDP) Parameters" registry.
IANAは、「Session Description Protocol（SDP）Parameters」レジストリの「att-field（media level only）」サブレジストリに2つのエントリを追加しました。
The first entry is for 'hlang-recv':
最初のエントリは「hlang-recv」用です。
Attribute Name: hlang-recv
Long-Form English Name: human language receive
Contact Name: Randall Gellens
Contact Email Address: rg+ietf@coretechnologyconsulting.com
Attribute Value: hlang-value
Attribute Syntax:
hlang-value = hlang-offv / hlang-ansv
; hlang-offv used in offers
; hlang-ansv used in answers
hlang-offv = Language-Tag *( SP Language-Tag )
; Language-Tag as defined in [BCP47]
SP = 1*" " ; one or more space (%x20) characters
hlang-ansv = Language-Tag
Attribute Semantics: Described in Section 5.1 of RFC 8373
Usage Level: media
Mux Category: NORMAL
Charset Dependent: No
Purpose: See Section 5.1 of RFC 8373
O/A Procedures: See Section 5.1 of RFC 8373
Reference: RFC 8373
The second entry is for 'hlang-send':
Attribute Name: hlang-send
Long-Form English Name: human language send
Contact Name: Randall Gellens
Contact Email Address: rg+ietf@coretechnologyconsulting.com
Attribute Value: hlang-value
Attribute Syntax:
hlang-value = hlang-offv / hlang-ansv
Attribute Semantics: Described in Section 5.1 of RFC 8373
Usage Level: media
Mux Category: NORMAL
Charset Dependent: No
Purpose: See Section 5.1 of RFC 8373
O/A Procedures: See Section 5.1 of RFC 8373
Reference: RFC 8373
IANA has added the value 308 to the "Warning Codes (warn-codes)" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry. (The value lies within the range allocated for indicating problems with keywords in the session description.) The reference is to this document. The warn text is "Incompatible language specification: Requested languages not supported. Supported languages are [list of supported languages]; supported media are: [list of supported media]."
IANAは、「Session Initiation Protocol（SIP）Parameters」レジストリの「Warning Codes（warn-codes）」サブレジストリに値308を追加しました。 （値は、セッションの説明でキーワードの問題を示すために割り当てられた範囲内にあります。）参照は、このドキュメントへの参照です。警告テキストは「互換性のない言語仕様：要求された言語はサポートされていません。サポートされている言語は[サポートされている言語のリスト]です。サポートされているメディアは[サポートされているメディアのリスト]です。」
The Security Considerations of [BCP47] apply here. An attacker with the ability to modify signaling could prevent a call from succeeding by altering any of several crucial elements, including the 'hlang-send' or 'hlang-recv' values. RFC 5069 [RFC5069] discusses such threats. Use of TLS or IPsec can protect against such threats. Emergency calls are of particular concern; RFC 6881 [RFC6881], which is specific to emergency calls, mandates use of TLS or IPsec (in ED-57/SP-30).
ここでは、[BCP47]のセキュリティに関する考慮事項が適用されます。シグナリングを変更する機能を持つ攻撃者は、「hlang-send」または「hlang-recv」の値を含むいくつかの重要な要素のいずれかを変更することにより、呼び出しの成功を妨げる可能性があります。 RFC 5069 [RFC5069]は、そのような脅威について説明しています。 TLSまたはIPsecを使用すると、このような脅威から保護できます。緊急通報は特に問題です。緊急通話に固有のRFC 6881 [RFC6881]は、TLSまたはIPsec（ED-57 / SP-30）の使用を義務付けています。
Language and media information can suggest a user's nationality, background, abilities, disabilities, etc.
言語とメディアの情報は、ユーザーの国籍、経歴、能力、障害などを示唆しています。
[BCP47] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006.
[BCP47]フィリップス、A。、エド。 M.デイビス編、「言語タグのマッチング」、BCP 47、RFC 4647、DOI 10.17487 / RFC4647、2006年9月。
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.
フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月。
[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>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[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>。
[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>。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, DOI 10.17487/RFC5069, January 2008, <https://www.rfc-editor.org/info/rfc5069>.
[RFC5069]テイラー、T。、編、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「セキュリティ上の脅威と緊急コールマーキングとマッピングの要件」、RFC 5069、DOI 10.17487 / RFC5069、2008年1月、 <https://www.rfc-editor.org/info/rfc5069>。
[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]ローゼン、B。およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、BCP 181、RFC 6881、DOI 10.17487 / RFC6881、2013年3月、<https：//www.rfc-editor .org / info / rfc6881>。
[RFC8255] Tomkinson, N. and N. Borenstein, "Multiple Language Content Type", RFC 8255, DOI 10.17487/RFC8255, October 2017, <https://www.rfc-editor.org/info/rfc8255>.
[RFC8255] Tomkinson、N。およびN. Borenstein、「Multiple Language Content Type」、RFC 8255、DOI 10.17487 / RFC8255、2017年10月、<https://www.rfc-editor.org/info/rfc8255>。
Acknowledgements
謝辞
Many thanks to Bernard Aboba, Harald Alvestrand, Flemming Andreasen, Francois Audet, Eric Burger, Keith Drage, Doug Ewell, Christian Groves, Andrew Hutton, Hadriel Kaplan, Ari Keranen, John Klensin, Mirja Kuhlewind, Paul Kyzivat, John Levine, Alexey Melnikov, Addison Phillips, James Polk, Eric Rescorla, Pete Resnick, Alvaro Retana, Natasha Rooney, Brian Rosen, Peter Saint-Andre, and Dale Worley for their reviews, corrections, suggestions, and participation in email and in-person discussions.
Bernard Aboba、Harald Alvestrand、Flemming Andreasen、Francois Audet、Eric Burger、Keith Drage、Doug Ewell、Christian Groves、Andrew Hutton、Hadriel Kaplan、Ari Keranen、John Klensin、Mirja Kuhlewind、Paul Kyzivat、John Levine、Alexey Melnikov 、Addison Phillips、James Polk、Eric Rescorla、Pete Resnick、Alvaro Retana、Natasha Rooney、Brian Rosen、Peter Saint-Andre、Dale Worleyのレビュー、修正、提案、メールへの参加、対面のディスカッション。
Contributors
貢献者
Gunnar Hellstrom deserves special mention for his reviews and assistance.
Gunnar Hellstromは、彼のレビューと支援について特に言及するに値します。
Author's Address
著者のアドレス
Randall Gellens Core Technology Consulting
Randall Gellensコアテクノロジーコンサルティング
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com