Negotiating Human Language in Real-Time Communications
updated by
- rfc-8865 — T.140 Real-Time Text Conversation over WebRTC Data Channels
Extracted elements (18)
Per-direction SDP media attributes were chosen so that asymmetric modality scenarios (e.g., a deaf user who sends voice but receives text) can be expressed naturally within the standard offer/answer negotiation model without requiring new signaling mechanisms.
The document uses 'negotiation' rather than 'indication' because human language can be negotiated the same way as media and codecs: the offer lists preferences in order and the answer selects one, giving both sides knowledge of the agreed language.
The existing SDP 'lang' attribute (RFC 4566) is similar but insufficiently specific and flexible; it is not mentioned in RFC 3264 and has no known SIP implementations, which is why the new 'hlang-send' and 'hlang-recv' attributes are defined instead.
This document does not define use of language tags for media other than interactive audio, video, and text streams (e.g., 'message' or 'application'), nor for sign-language tags in text or audio media; such use could be supported by future work or application agreement.
In an answer, each 'hlang-send' and 'hlang-recv' value MUST be exactly one BCP 47 language tag, indicating the single language the answerer commits to use.
In an offer, each 'hlang-send' and 'hlang-recv' value MUST be a list of one or more BCP 47 language tags separated by white space, listed in preference order (most preferred first).
When a call is rejected due to no common language, the SIP response MUST use response code 488 (Not Acceptable Here) or 606 (Not Acceptable), with a Warning header field using warning code 308; the warning text SHOULD contain the supported languages and media.
When a media stream is intended for interactive communication in both directions, 'hlang-send' and 'hlang-recv' SHOULD have the same value; either MAY be omitted only when the stream is intended for one direction only.
When a media stream is not primarily intended for language (e.g., background audio or video), both 'hlang-send' and 'hlang-recv' SHOULD be omitted.
When placing an emergency call, and in any other case where 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 intended interactive direction(s).
Language and media information included in SDP attributes can reveal details about a user's nationality, background, abilities, and disabilities, and should be handled with appropriate confidentiality measures.
Sign-language interpretation rules: a sign-language BCP 47 tag (using 'sgn' extlang prefix) paired with a video stream indicates sign language video; a non-sign-language tag with text indicates written language; a non-sign-language tag with audio indicates spoken language.
SIP Warning code 308 is defined for use when a call is rejected due to incompatible language specification. The warning text indicates 'Requested languages not supported' and lists supported languages and media.
Two new SDP media-level attributes, 'hlang-send' and 'hlang-recv', are defined to negotiate human language (spoken, written, or signed) per direction for each interactive media stream. Both use BCP 47 language tags.
Two entries are added to the 'att-field (media level only)' subregistry of the SDP Parameters registry: 'hlang-recv' (human language receive) and 'hlang-send' (human language send), both with Mux Category NORMAL and charset-independent values.
Warning code 308 is added to the 'Warning Codes (warn-codes)' subregistry of SIP Parameters, with warn text indicating incompatible language specification and listing supported languages and media.
An attacker able to modify SIP signaling could alter 'hlang-send' or 'hlang-recv' values to prevent call completion. Use of TLS or IPsec is recommended to protect against such threats; RFC 6881 mandates TLS or IPsec for emergency calls.
The 'hlang-recv' and 'hlang-send' attribute values use ABNF syntax: in offers, 'hlang-offv' is one or more BCP 47 Language-Tags separated by one or more space characters; in answers, 'hlang-ansv' is a single Language-Tag.