Internet DRAFT - draft-hellstrom-text-turntaking
draft-hellstrom-text-turntaking
Network Working Group G. Hellstrom
Internet-Draft Omnitor
Intended status: Informational A. van Wijk
Expires: September 7, 2010 Real-Time Text Taskforce (R3TF)
March 8, 2010
Registration of the Real-time-text Media Feature Tag
draft-hellstrom-text-turntaking-03
Abstract
This memo defines a new Media Feature Tag "real-time-text" for use in
SIP registration and session establishment. This is used to indicate
if a device capable of text communication has full real-time text
capabilities or limitations in its capabilities requiring the users
to apply some turn-taking habits.
To the RFC editor
Please replace y.y with the assigned ASN.1 identifier and XXXX with
the RFC number of this specification.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2010.
Copyright Notice
Hellstrom & van Wijk Expires September 7, 2010 [Page 1]
Internet-Draft Real-time-text Media Feature Tag March 2010
Copyright (c) 2010 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
(http://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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Hellstrom & van Wijk Expires September 7, 2010 [Page 2]
Internet-Draft Real-time-text Media Feature Tag March 2010
1. Introduction
Media feature tags for use in SIP headers are introduced in RFC 3840
[RFC3840]. They are used with the Session Initiation Protocol (SIP).
When negotiating a text communication medium in a session, a user may
find it very desirable to achieve a text communication path with
real-time text capabilities. In order to support routing of
negotiating to support this preference, an indication in a SIP media-
feature tag can be used. That media-feature tag is defined in this
specification. One value is given to the parameter for indication of
full simultaneous two way capabilities of the text communication.
When interworking with legacy telecommunication devices through a
gateway, an IP based text phone using SIP may be required to limit
its capabilities to match those devices. For example, V.21 based
textphones are full duplex in transport, but have varying handling of
the presentation. Some types merge the two sources in one window.
Some have a kind of irc-like display with labels in front of the text
from different participants. And yet some do a split in two windows
of real-time text from each direction.
In order for a SIP-based text capable device to display an
appropriate user interface when interacting with one of these legacy
devices, it is necessary to convey a parameter indicating the limited
capability of the legacy device. It is also of interest to route
calls to the most capable device.
When it is interacting with a legacy device, an IP text capable
device may receive an offer that contains the 'real-time-text' tag
indicating some restriction. That tag then acts as a cue to
configure the user interface appropriately, although there is nothing
in the generated answer to indicate that this has been done.
Similiarly, if an answer is received that contains a 'real-time-text'
tag with a value indicating restrictions, that indicates that the
remote device has limited capabilities regarding simulaneity, and the
user-interface should present some indication of this to the user.
More information on handling of real-time text is found in RFC 5194.
Framework for real-time text over IP using the Session Initiation
Protocol [RFC5194]. This memo defines such a parameter.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Hellstrom & van Wijk Expires September 7, 2010 [Page 3]
Internet-Draft Real-time-text Media Feature Tag March 2010
3. IANA Considerations
This specification defines a Media Feature tag 'real-time-text'. Its
formatting in SIP headers is described in the following:
Media Feature Tag name: sip.real-time-text
ASN.1 Identifier: y.y.
Summary of the media feature indicated by this tag: The sip.real-
time-text media feature tag indicates whether a communications device
can simultaneously handle the real-time text medium and audio in its
user interface or towards attached devices, or if limitations must be
applied by users who communicate with the device.
Values appropriate for use with this feature tag: Token with an
equality relationship.
Defined values are:
full: The device can handle real-time text simultaneously in both
directions and if it supports audio, audio and text can also be
handled simultaneously. (default)
restricted: The device requires some ordered turn-taking to take
place. It is not specified how strict this turntaking must be,
and it is left to the users to figure out what level of turntaking
signaling is needed.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a SIP multimedia communication device,
SIP application servers implementing services including real-time
text, or a PSTN textphone gateway, connecting SIP devices with legacy
textphones, with the intention both to support routing of the call
and indication to the SIP device user if turntaking must be applied.
Examples of typical use: Choosing to communicate with a native, real-
time text capable device rather than a legacy textphone behind a
gateway, when a selection is possible. Instruct the user of the SIP
device about the need to apply turntaking habits as used with legacy
textphones when the call is made through a gateway with that kind of
device.
Related standards or documents: RFC XXXX.
Security Considerations: Security considerations for this media
Hellstrom & van Wijk Expires September 7, 2010 [Page 4]
Internet-Draft Real-time-text Media Feature Tag March 2010
feature tag are discussed in Section 11.1 of RFC 3840.
4. Example
The following example shows the use of the 'real-time-text' tag in a
SIP message.
REGISTER sip:example.com SIP/2.0
From: sip:user@example.com;tag=asd98
To: sip:user@example.com
Call-ID: hh89as0d-asd88jkk@host.example.com
CSeq: 9987 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact: <sip:user@host.example.com>;audio;text;
real-time-text=restricted
Content-Length: 0
5. Security Considerations
Security considerations for this media feature tag are discussed in
Section 11.1 of RFC 3840.
6. Acknowledgements
The need for this registration was discussed with Barry Dingle,
Gonzalo Camarillo , and Colin Perkins.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Hellstrom & van Wijk Expires September 7, 2010 [Page 5]
Internet-Draft Real-time-text Media Feature Tag March 2010
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text
over IP Using the Session Initiation Protocol (SIP)",
RFC 5194, June 2008.
Authors' Addresses
Gunnar Hellstrom
Omnitor
Box 92 054
Stockholm 12006
Sweden
Email: gunnar.hellstrom@omnitor.se
URI: http://www.omnitor.se
Arnoud van Wijk
Real-Time Text Taskforce (R3TF)
NL
Email: arnoud@realtimetext.org
URI: www.realtimetext.org
Hellstrom & van Wijk Expires September 7, 2010 [Page 6]
