[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-hellstrom-mmusic-multi-party-rtt

Network Working Group                                       G. Hellstrom
Internet-Draft                                                   Omnitor
Intended status: Best Current                                A. van Wijk
Practice                                                RealTimeText.org
Expires: July 5, 2008                                    January 2, 2008


   Text media handling in RTP based real-time and message conferences
                   draft-hellstrom-text-conference-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 July 5, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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
   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



Hellstrom & van Wijk      Expires July 5, 2008                  [Page 1]


Internet-Draft          Text conference handling            January 2008


   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.

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].


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Centralized conference model  . . . . . . . . . . . . . . . . . 3
   3.  Identification of the source of text  . . . . . . . . . . . . . 4
   4.  Presentation of multi-party text  . . . . . . . . . . . . . . . 5
     4.1.  Associating identities with text streams  . . . . . . . . . 5
     4.2.  Selecting what to present . . . . . . . . . . . . . . . . . 5
   5.  Transmission of text from each user . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Congestion considerations . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8




















Hellstrom & van Wijk      Expires July 5, 2008                  [Page 2]


Internet-Draft          Text conference handling            January 2008


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 calls.

   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 RFC
   3261[RFC3261] Session Initiation Protocol 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 July 5, 2008                  [Page 3]


Internet-Draft          Text conference handling            January 2008


   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.

   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.

   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 Focus UA acts 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
   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.

   In 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



Hellstrom & van Wijk      Expires July 5, 2008                  [Page 4]


Internet-Draft          Text conference handling            January 2008


   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 SOULD 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.

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 NAME field should be given a value that is suitable as an
   identifier of text from the user of the UA.




Hellstrom & van Wijk      Expires July 5, 2008                  [Page 5]


Internet-Draft          Text conference handling            January 2008


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   The security considerations valid for RFC 4103 and RFC 3550 are valid
   also for the multi-party sessions with text.


8.  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.


9.  Acknowledgements


10.  Normative References

   [I-D.hellstrom-textpreview]
              Hellstrom, G., "Text conversation with real-time preview",
              draft-hellstrom-textpreview-02 (work in progress),
              August 2007.

   [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 July 5, 2008                  [Page 6]


Internet-Draft          Text conference handling            January 2008


   [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:   +4658900051
   Email: gunnar.hellstrom@omnitor.se
   URI:   www.omnitor.se


   Arnoud van Wijk
   RealTimeText.org

   Email: arnoud@realtimetext.org
   URI:   http://www.realtimetext.org












Hellstrom & van Wijk      Expires July 5, 2008                  [Page 7]


Internet-Draft          Text conference handling            January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hellstrom & van Wijk      Expires July 5, 2008                  [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/