Negotiating Human Language in Real-Time Communications
draft-gellens-mmusic-negotiating-human-language-02
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Randall Gellens | ||
| Last updated | 2014-10-15 (Latest revision 2014-02-14) | ||
| Replaced by | draft-gellens-slim-negotiating-human-language | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-gellens-slim-negotiating-human-language | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication "calls" there needs to be a way to communicate and ideally match (i.e., negotiate) the caller's language preferences with the capabilities of the called party. This is especially important with emergency calls, where a call can be routed to a Public Safety Answering Point (PSAP) or call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and expected use, and describes a solution using new SDP stream attributes plus an optional SIP "hint."
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)