Network Working Group G. Hellstrom
Internet-Draft Omnitor
Intended status: BCP A. van Wijk
Expires: January 13, 2010 Real-Time Text Taskforce (R3TF)
July 12, 2009
Text media handling in RTP based real-time conferences
draft-hellstrom-text-conference-01
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 January 13, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo specifies methods for text media handling in multi-party
calls, where the text is carried by the RTP protocol. Real-time text
Hellstrom & van Wijk Expires January 13, 2010 [Page 1]
Internet-Draft Text conference handling July 2009
is carried in a time-sampled mode according to RFC 4103. Centralized
multi-party handling of real-time text is achieved through a media
control unit coordinating multiple RTP text streams into one RTP
session, identifying each stream with its own SSRC. Identification
for the streams are provided through the RTCP messages. This
mechanism enables the receiving application to present the received
real-time text medium in different ways according to user
preferences. Some presentation related features are also described
explaining suitable variations of transmission and presentation of
text. Call control features are described for the SIP environment,
while the transport mechanisms should be suitable for any IP based
call control environment using RTP transport. An alternative method
using a single RTP stream and source identification inline in the
text stream is also described.
Requirements Language
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 January 13, 2010 [Page 2]
Internet-Draft Text conference handling July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Centralized conference model . . . . . . . . . . . . . . . . . 4
2.1. Coordination of text RTP streams . . . . . . . . . . . . . 5
2.2. Session control of multi-party sessions . . . . . . . . . . 5
3. Identification of the source of text . . . . . . . . . . . . . 5
4. Presentation of multi-party text . . . . . . . . . . . . . . . 6
4.1. Associating identities with text streams . . . . . . . . . 6
4.2. Selecting what to present . . . . . . . . . . . . . . . . . 7
5. Transmission of text from each user . . . . . . . . . . . . . . 7
6. Alternative source indicator for use of an RTP mixer for
text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. Congestion considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Hellstrom & van Wijk Expires January 13, 2010 [Page 3]
Internet-Draft Text conference handling July 2009
1. Introduction
Real-time text is a medium in real-time conversational sessions.
Text entered by participants in a session is transmitted in a time-
sampled fashion, so that no specific user action is needed to cause
transmission. This gives a direct flow of text that is suitable in a
real-time conversational setting. The real-time text medium can be
combined with other media in multimedia sessions.
A number of multimedia sessions can be combined in a multi-party
session. This memo specifies how the real-time text streams are
handled in such multi-party sessions.
The description is mainly focused on the transport level, but also
describes a few presentation level features.
Transport of real-time text is specified in RFC 4103 [RFC4103] RTP
Payload for text conversation. It makes use of RFC 3550 [RFC3550]
Real Time Protocol, for transport, and is usually used in the SIP
Session Initiation Protocol RFC 3261[RFC3261] environment, even if it
is also used in other call control environments. Call control
aspects in this specification are explained with examples from SIP.
The specifications about how to handle multi-party text transport,
identification and presentation are valid also for other call control
environments where RTP and RTCP are used.
A very brief overview of functions for both real-time and messaging
text handling in multi-party sessions is described in RFC 4597
Conferencing Scenarios [RFC4579]. This specification builds on that
description and indicates what existing protocol mechanisms should be
used to implement multi-party handling of text in real-time sessions.
2. Centralized conference model
In the centralized conference model, one function co-ordinates the
sessions with participants in the multi-party session. This function
also controls media mixer functions for the media appearing in the
session. The central function is common for control of all media,
while the media mixers may work differently for each medium.
The central function is called the Focus UA and may be co-located in
an advanced terminal including multi-party control functions, or it
may be located in a separate location. Many variants exist for
setting up sessions including the multipoint control centre, It is
not within scope of this description to describe these, but rather
the media specific handling in the mixer required to handle multi-
party calls.
Hellstrom & van Wijk Expires January 13, 2010 [Page 4]
Internet-Draft Text conference handling July 2009
The main principle for handling real-time text media in a centralized
conference is that one RTP session for real-time text is established
between the multipoint media control centre and each participant who
is going to have real-time text exchange with the others.
2.1. Coordination of text RTP streams
The preferred way of coordinating text RTP streams is that within
each RTP session, text from each participant is transmitted from the
media mixer as a separate RTP stream, thus all using the same
destination address/port combination, but using different RTP SSRCs
as described in Section 7.1 of RTP RFC 3550 [RFC3550] about the
Translator function. This methods enables the receiver to freely
select display characteristics of the text conversation.
When coordinating the RTP streams from the Translator, they all get
the same RTP Payload type numbers and redundancy level, resulting
from the SDP negotiation of the session.
An alternative way to coordinate the RTP streams is to combine them
into one by an RTP Mixer function as described in RTP RFC 3550
[RFC3550] Section 7.1. In this case, the text source must be
indicated inline in text as described in the section on alternative
transport in this memo.
2.2. Session control of multi-party sessions
General session control aspects for multi-party sessions are
described in RFC 4575 A Session Initiation Protocol (SIP) Event
Package for Conference State[RFC4575], and RFC 4579 Session
Initiation Protocol (SIP) Call Control - Conferencing for User Agents
[RFC4579]. The nomenclature of these specifications are used here.
3. Identification of the source of text
The Focus UA co-ordinates the media flow. Real-time text media from
different sources are combined in one text media session by the Focus
UA. The main principle is that the Focus UA SHOULD act as an RTP
Translator as described in RFC 3550 RTP [RFC3550] Section 7.1.
The RTP text stream from each participant who transmits text is
allocated one unique SSRC. The SSRC is used by the receiver to
identify text packets originating from one source. Each RTP packet
MUST contain text from only one source.
The redundancy mechanism for increased robustness used by the RFC
4103 transport makes use of the RTP sequence number for detection of
Hellstrom & van Wijk Expires January 13, 2010 [Page 5]
Internet-Draft Text conference handling July 2009
loss. One sequence number series is maintained per RTP stream
identified by one SSRC. The RTP Translation mechanism maintains a
separate SSRC for each source RTP stream in the combined RTP session.
Therefore the RTP Translation mechanism can be used for conveying
text from multiple sources to one destination, with maintained
possibility to detect and recover loss and identify text from the
different sources.
As soon as a new member is added to the RTP session, its
characteristics shall be transmitted in RTCP SDES reports according
to section 6.5 in RFC 3550.
The RTCP SDES report, SHOULD contain identification of the source
represented by the SSRC identifier. This identification MUST contain
the CNAME field and MAY contain the NAME field and other defined
fields of the SDES report.
A focus UA SHOULD primarily convey SDES information received from the
sources of the session members. When such information is not
available, the focus UA SHOULD compose CNAME and NAME information
from available information from the SIP session with the participant.
4. Presentation of multi-party text
All session participants MUST observe the SSRC field of incoming text
RTP packets, and make note of what source they came from in order to
be able to present text in a way that makes it easy to read text from
each participant in a session, and get information about the source
of the text.
4.1. Associating identities with text streams
A source identity SHOULD be composed from available information
sources and displayed together with the text as indicated in ITU-T
T.140 Appendix [T.140].
The source should primarily be the NAME field from incoming SDES
packets. If this information is not available, and the session is a
two-party session, then the T.140 source identity SHOULD be composed
from the SIP session participant information. For multi-party
sessions the source identity may be composed by local information if
sufficient information is not available in the session.
Applications may abbreviate the presented source identity to a
suitable form for the available display.
Hellstrom & van Wijk Expires January 13, 2010 [Page 6]
Internet-Draft Text conference handling July 2009
4.2. Selecting what to present
Display space limitations and other considerations may call for an
opportunity for the user to select what sources of text to present,
at what stage in the reception process to display them and how to
present them. The specification draft-hellstrom-text-preview
[I-D.hellstrom-textpreview] specifies such presentation aspects.
5. Transmission of text from each user
UAs participating in sessions with real-time text, SHOULD send SDES
packets in RTCP giving values to appropriate identification fields.
The CNAME field SHALL be included in SDES packets.
The NAME field should be given a value that is suitable as an
identifier of text from the user of the UA.
6. Alternative source indicator for use of an RTP mixer for text.
In certain application environments, it may be known to be unsuitable
to send multiple SSRC streams in one RTP session. In such cases, an
inline coding of the source of text SHOULD be applied in the data
stream itself, and an RTP mixer function used for coordinating the
sources of text into one RTP stream.
The information otherwise conveyed in the CNAME field of an SDES
packet SHALL then be placed as the parameter value in the T.140
application protocol function with the function code "c". The
identifier shall thus be formatted like this: SOS c cname field
contents ST, where SOS and ST are coded as specified in ITU-T T.140
[T.140]
The information otherwise conveyed in the NAME field of an SDES
packet SHOULD then be placed as the parameter value in the T.140
application protocol function with the function code "n".
A T.140 application protocol function with the function code "c" MUST
be included in the text in the beginning of text when the source of
the text changes. A T.140 application protocol function with the
function code "c" MAY be repeated in the text from the same the
source. A T.140 application protocol function with the function code
"n" MAY be included in the text to further provide identification of
the transmitting party. This information SHOULD also be provided in
the SDES name field. A receiving UA SHOULD separate text from the
different sources and identify and display them accordingly.
Hellstrom & van Wijk Expires January 13, 2010 [Page 7]
Internet-Draft Text conference handling July 2009
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
The security considerations valid for RFC 4103 and RFC 3550 are valid
also for the multi-party sessions with text.
9. Congestion considerations
The congestion considerations described in RFC 4103 are valid also
for multi-party use of the real-time text RTP transport. A risk for
congestion may appear if a number of conference participants are
active transmitting text simultaneously, because this multi-party
transmission method does not allow multiple sources of text to
contribute to the same packet.
In situations of risk for congestion, the Focus UA MAY combine
packets from the same source to increase the transmission interval
per source up to one second. Local conference policy in the Focus UA
may be used to decide on which streams shall be selected for such
transmission frequency reduction.
10. Acknowledgements
11. Normative References
[I-D.hellstrom-textpreview]
Hellstrom, G., Williams, N., Wijk, A., and G.
Vanderheiden, "Presentation of Text Conversation in
realtime and en-bloc form", draft-hellstrom-textpreview-06
(work in progress), July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
Hellstrom & van Wijk Expires January 13, 2010 [Page 8]
Internet-Draft Text conference handling July 2009
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[T.140] ITU-T., "Protocol for multimedia application text
conversation", 1998,
<http://www.itu.int/rec/T-REC-T.140/en>.
Authors' Addresses
Gunnar Hellstrom
Omnitor
Box 92054
Stockholm SE-120 06
Sweden
Phone: +46858900056
Fax: +46858900051
Email: gunnar.hellstrom@omnitor.se
URI: www.omnitor.se
Arnoud van Wijk
Real-Time Text Taskforce (R3TF)
NL
Email: arnoud@realtimetext.org
URI: www.realtimetext.org
Hellstrom & van Wijk Expires January 13, 2010 [Page 9]