Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8373 Core Technology Consulting
Category: Standards Track May 2018
ISSN: 2070-1721
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
能够使用一组语言，可能有一种或几种语言的首选项，而航空公司预订中心可能支持一组固定的语言。协商应选择呼叫中心支持的用户最喜欢的语言。双方都应该知道谈判的语言。
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.
在这里使用的报价/应答模型中，报价包含报价人能够使用的每种媒体（和方向）的一组语言，而应答人将支持的每种媒体（和方向）包含一种语言。支持语言和/或方式可能需要采取额外的步骤，例如将外部翻译或中继资源连接到呼叫中，或者让讲请求语言和/或能够使用请求方式的代理处理呼叫。答案表示回答者承诺支持的媒体和语言（可能在采取其他步骤后）。该模型还提供了知识，以便双方都知道协商的内容。请注意，对于任何早期媒体，支持所示语言或模式所需的额外步骤可能及时到位，也可能没有到位。
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.
本文档不涉及用户界面（UI）问题，例如UE客户端是否或如何通知用户语言和媒体协商的结果。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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”，该属性类似于此处所需的属性，但对于本文档的需求而言，该属性不够具体或灵活。此外，[RFC3264]中没有提到“lang”，SIP中也没有已知的实现。此外，能够指定每个方向（发送和接收）的语言是有用的。因此，本文档定义了两个新属性。
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节中注册）。两者都以“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
在要约中，“hlang send”值是要约人在使用媒体发送时愿意使用的一种或多种语言的列表，“hlang recv”值是一种或多种语言的列表
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”或“hlang recv”。请注意，介质在两个方向上仍然有用。当媒体主要不用于语言（例如，仅用于背景的视频或音频流）时，两者都应省略。否则，两者应具有相同的值。请注意，为每个方向指定不同的语言（与不同模式下相同或基本相同的语言相反）可能会使完成呼叫变得困难（例如，指定希望发送匈牙利语音频和接收葡萄牙语音频）。
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”中的语言之一），而“hlang recv”是回答者在使用媒体进行语言交流时希望收到的语言（在大多数情况下，这是要约“hlang send”中的语言之一）。
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]的一个或多个语言标记的列表，用空格分隔。在回答中，每个值必须是每个[BCP47]的一个语言标记。[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”属性。
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.
代表最终用户的客户端应在每个提供的媒体流上设置一个或两个“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]和警告头字段[RFC3261]，警告代码308和警告文本指示不存在相互支持的语言；警告文本还应包含支持的语言和媒体。
Example:
例子：
Warning: 308 proxy.example.com "Incompatible language
specification: Requested languages not supported. Supported
languages are: es, en; supported media are: audio, text."
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语言子标签注册表中，带有类型字段“extlang”和前缀字段值“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
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
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):
要求双向说西班牙语（最优先）、双向说巴斯克语（第二优先）或双向说英语（第三优先）的报价：
m=audio 49250 RTP/AVP 20
a=hlang-send:es eu en
a=hlang-recv:es eu en
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
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
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
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=video 51372 RTP/AVP 31 32
a=hlang-send:aed
m=text 45020 RTP/AVP 103 104
a=hlang-send:sp pt
m=text 45020 RTP/AVP 103 104
a=hlang-send:sp pt
m=audio 49250 RTP/AVP 20
a=hlang-recv: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=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
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=text 45020 RTP/AVP 103 104
a=hlang-send:en sp
m=audio 49250 RTP/AVP 20
a=hlang-recv: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=text 45020 RTP/AVP 103 104
a=hlang-recv:sp
m=audio 49250 RTP/AVP 20
a=hlang-send: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在“会话描述协议（SDP）参数”注册表的“att字段（仅媒体级别）”子区添加了两个条目。
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
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':
第二个条目是“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
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已将值308添加到“会话启动协议（SIP）参数”注册表的“警告代码（警告代码）”子区。（该值位于为指示会话描述中的关键字问题而分配的范围内。）参考此文档。警告文本为“不兼容的语言规范：不支持请求的语言。支持的语言为[支持的语言列表]；支持的媒体为：[支持的媒体列表]。”
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]Phillips，A.，Ed.和M.Davis，Ed.，“语言标记的匹配”，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.
Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标记”，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：会话描述协议”，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]Crocker，D.，Ed.和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]Taylor，T.，Ed.，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]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，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]北汤金森和北伯伦斯坦，“多语言内容类型”，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.
感谢伯纳德·阿博巴、哈拉尔·阿尔维斯特兰、弗莱明·安德烈森、弗朗索瓦·奥德特、埃里克·伯格、基思·德拉格、道格·埃威尔、克里斯蒂安·格罗夫斯、安德鲁·赫顿、哈德里尔·卡普兰、阿里·凯拉宁、约翰·克列文、保罗·基齐瓦特、约翰·莱文、阿列克谢·梅尔尼科夫、艾迪森·菲利普斯、詹姆斯·波尔克、埃里克·雷索拉、皮特·雷斯尼克、阿尔瓦罗·雷塔纳、娜塔莎·鲁尼，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
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com