diff options
Diffstat (limited to 'doc/rfc/rfc8373.txt')
| -rw-r--r-- | doc/rfc/rfc8373.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc8373.txt b/doc/rfc/rfc8373.txt new file mode 100644 index 0000000..b0fbf17 --- /dev/null +++ b/doc/rfc/rfc8373.txt @@ -0,0 +1,731 @@ + + + + + + +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). + + This document describes the need as well as a solution that uses new + SDP media attributes. + +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. + + 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. + + + + + + + + + + + + +Gellens Standards Track [Page 1] + +RFC 8373 Negotiating Human Language May 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + + + + + + + + +Gellens Standards Track [Page 2] + +RFC 8373 Negotiating Human Language May 2018 + + +1. Introduction + + 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. + + 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. + + 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. + + 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. + + 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 + + + +Gellens Standards Track [Page 3] + +RFC 8373 Negotiating Human Language May 2018 + + + 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. + + 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. + +1.1. Applicability + + 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. + + 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. + + + + + + + + + +Gellens Standards Track [Page 4] + +RFC 8373 Negotiating Human Language May 2018 + + +2. Terminology + + 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. + +3. Desired Semantics + + 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. + +4. The Existing 'lang' Attribute + + 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. + +5. Solution + + An SDP attribute (per direction) seems the natural choice to + negotiate human language of an interactive media stream, using the + language tags of [BCP47]. + +5.1. The 'hlang-send' and 'hlang-recv' Attributes + + 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. + + 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 + + + +Gellens Standards Track [Page 5] + +RFC 8373 Negotiating Human Language May 2018 + + + 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). + + 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'). + + 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. + + 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. + + 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. + + 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. + + + +Gellens Standards Track [Page 6] + +RFC 8373 Negotiating Human Language May 2018 + + +5.2. No Language in Common + + 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. + + Example: + + Warning: 308 proxy.example.com "Incompatible language + specification: Requested languages not supported. Supported + languages are: es, en; supported media are: audio, text." + +5.3. Usage Notes + + 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. + + 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. + + + + + + +Gellens Standards Track [Page 7] + +RFC 8373 Negotiating Human Language May 2018 + + +5.4. Examples + + Some examples are shown below. For clarity, only the most directly + relevant portions of the SDP block are shown. + + 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): + + 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 + + + +Gellens Standards Track [Page 8] + +RFC 8373 Negotiating Human Language May 2018 + + + 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 + + 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 + + + + +Gellens Standards Track [Page 9] + +RFC 8373 Negotiating Human Language May 2018 + + + 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. + +6. IANA Considerations + +6.1. att-field Subregistry of SDP Parameters + + The syntax in this section uses ABNF per RFC 5234 [RFC5234]. + + IANA has added two entries to the "att-field (media level only)" + subregistry of the "Session Description Protocol (SDP) Parameters" + registry. + + The first entry is for '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 + + + + + + + + + + + + + +Gellens Standards Track [Page 10] + +RFC 8373 Negotiating Human Language May 2018 + + + 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 + +6.2. Warning Codes Subregistry of SIP Parameters + + 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]." + +7. Security Considerations + + 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). + +8. Privacy Considerations + + Language and media information can suggest a user's nationality, + background, abilities, disabilities, etc. + + + + + + + + +Gellens Standards Track [Page 11] + +RFC 8373 Negotiating Human Language May 2018 + + +9. References + +9.1. Normative References + + [BCP47] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language + Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September + 2006. + + Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + +9.2. Informative References + + [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>. + + [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>. + + + +Gellens Standards Track [Page 12] + +RFC 8373 Negotiating Human Language May 2018 + + + [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>. + + [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>. + +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. + +Contributors + + Gunnar Hellstrom deserves special mention for his reviews and + assistance. + +Author's Address + + Randall Gellens + Core Technology Consulting + + Email: rg+ietf@coretechnologyconsulting.com + URI: http://www.coretechnologyconsulting.com + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 13] + |