Media multiplexing with Real-time Transport Protocol (RTP) subsessions
draft-ejzak-avtcore-rtp-subsessions-00

AVTCORE                                                         R. Ejzak
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                              June 4, 2012
Expires: December 6, 2012

 Media multiplexing with Real-time Transport Protocol (RTP) subsessions
                 draft-ejzak-avtcore-rtp-subsessions-00

Abstract

   This document describes a means of multiplexing RTP streams having
   different media types within a single transport connection and how to
   represent this multiplexing option in SDP.  This mechanism is an
   alternative to the BUNDLE and SHIM proposals currently under active
   consideration in AVTCORE.  Instead of adding an extra multiplexing
   header as in SHIM to allow multiple RTP sessions within a single
   transport connection, or using the payload type field to separate
   different media streams within a single RTP session, this document
   describes how to partition the existing SSRC space to create RTP
   subsessions from a single RTP session.  A filter can be used to
   identify each RTP subsession for different QoS handling as necessary.
   RTP subsessions can be treated like RTP sessions with a few
   restrictions.  In particular, SSRC mapping may be needed when
   forwarding RTP streams into an RTP subsession to avoid SSRC
   conflicts, but there are few use cases in which this limitation is a
   concern and RTP subsessions can be disabled if necessary.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 6, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the

Ejzak                   Expires December 6, 2012                [Page 1]
Internet-Draft               RTP subsessions                   June 2012

   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 Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Overview of RTP subsessions . . . . . . . . . . . . . . . . . . 3
   3.  Applicability of RTP subsessions  . . . . . . . . . . . . . . . 5
   4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Evaluation  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Comparison to BUNDLE  . . . . . . . . . . . . . . . . . . . 6
     5.2.  Comparison to SHIM  . . . . . . . . . . . . . . . . . . . . 7
     5.3.  Comparison to other SSRC proposals  . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Ejzak                   Expires December 6, 2012                [Page 2]
Internet-Draft               RTP subsessions                   June 2012

1.  Introduction

   The subject of RPT multiplexing has received significant attention
   within RTCWEB and AVTCORE in the last year.  It would be highly
   desirable to multiplex RTP streams associated with a communications
   session onto as few transport connections as possible to reduce the
   messaging required to complete ICE connectivity checks [RFC5245] and
   DTLS key exchange [RFC6347] prior to being able to send media.  RTP
   is specified in [RFC3550].  This document focuses specifically on how
   to multiplex multiple media types on the same transport connection
   since RTP is already capable of multiplexing RTP streams of the same
   media type using the SSRC field.  The following drafts provide key
   background and context, which will not be duplicated here:
   [I-D.ietf-rtcweb-rtp-usage],
   [I-D.westerlund-avtcore-multiplex-architecture] and
   [I-D.westerlund-avtcore-max-ssrc].  The BUNDLE solution
   [I-D.ietf-mmusic-sdp-bundle-negotiation] uses SDP [RFC4566] to assign
   different sets of payload type values for each media line sharing an
   RTP session.  The SHIM solution
   [I-D.westerlund-avtcore-transport-multiplexing] extends the RTP frame
   with an RTP session identifier to allow multiple RTP sessions to
   share a single transport connection.  Schemes no longer under
   consideration based on SSRC are described in
   [I-D.rosenberg-rtcweb-rtpmux] and
   [I-D.peterson-rosenberg-avt-rtp-ssrc-demux].  This document describes
   an alternative approach with advantages compared to the current
   preferred BUNDLE and SHIM approaches.

2.  Overview of RTP subsessions

   An RTP subsession is a set of RTP streams and corresponding RTCP
   packets that use a subset of the entire range of SSRC values.  Each
   RTP subsession has most of the characteristics of a complete RTP
   session with some exceptions described below.  RTP subsessions that
   are assigned non-overlapping SSRC value ranges can share a single
   transport connection.

   Each RTP subsession sharing a single transport connection is assigned
   a unique 16 bit SSRC prefix for each direction of transmission, i.e.,
   the first 15 (highest order) bits of the 32 bit SSRC field have a
   fixed value for all RTP streams associated with the RTP subsession
   and the 16th bit is reserved to indicate each direction of
   transmission.  The SDP offerer selects one value of the 16th bit and
   the SDP answerer selects the other.  The final 16 bits of the SSRC
   are available to specify separate RTP streams within the RTP
   subsession.  The first 15 bits of the SSRC prefix are assigned
   randomly for each RTP subsession.  The SDP offerer is allowed to

Ejzak                   Expires December 6, 2012                [Page 3]
Internet-Draft               RTP subsessions                   June 2012

   specify either value for the 16th bit of the SSRC to allow the
   offerer and answerer to change roles during subsequent session
   modifications while allowing continued use of already assigned SSRC
   values.

   When concatenating multiple RTP or RTCP packets within a single IP
   packet, as allowed by existing specifications, RTP systems will only
   combine packets from the same RTP subsession.  RTP subsessions are
   thus segregated into separate IP packets to allow differential
   treatment in the network.

   The use of RTP subsessions is negotiated during the SDP offer/answer
   exchange as follows.  All media lines in an SDP offer that are to
   share a transport connection will include identical connection and
   port information.  If more than one port is specified for any media
   line then the first ports specified for the media lines are
   identical.  Endpoints supporting RTP subsessions will include the
   rtcp-mux attribute [RFC5761] for each media line sharing the same
   transport connection.  Each media line in a sharing group will
   include an "ssrc-prefix" attribute with a number of parameters
   corresponding to the number of ports assigned to the media line
   (usually one).  If use of RTP subsessions is agreed during the SDP
   offer/answer negotiation and more than one port is specified for the
   media line, then a separate RTP subsession (and ssrc-prefix) will be
   assigned to each specified port but all RTP subsessions will be
   multiplexed onto the first port and the other specified ports will
   remain unused.  Each parameter of the ssrc-prefix attribute is a hex
   representation of the 16 bit SSRC prefix to be used by the RTP
   subsession associated with each port for the m line.  When there is
   only one port specified for a media line, then the ssrc-prefix
   attribute has only one parameter and there is only one RTP subsession
   for the media line.

   The SDP offer includes the ssrc-prefix attribute for each media line
   in the sharing group.  The use of a grouping construct to explicitly
   define the sharing group (as in
   [I-D.ietf-mmusic-sdp-bundle-negotiation]) is not strictly necessary
   and its potential use is for further study.  If the SDP answerer
   agrees to use RTP subsessions, then it also includes in the SDP
   answer the ssrc-prefix attribute for each media line in the sharing
   group, with the same parameter values as the corresponding ones from
   the SDP offer, but with the 16th bit changed, i.e., '0' becomes '1'
   or '1' becomes '0'.  The SDP answerer can disable the use of RTP
   subsessions by ignoring the ssrc-prefix attributes and including a
   different port for each m line in the SDP answer.  If the SDP
   answerer includes matching ssrc-prefix attributes for the media lines
   in a sharing group but not all port values are identical, then the
   systems will limit the allocation of SSRC values to RTP streams as

Ejzak                   Expires December 6, 2012                [Page 4]
Internet-Draft               RTP subsessions                   June 2012

   indicated by the ssrc-prefix attribute but the RTP subsessions will
   only be multiplexed for subsets of matching port values, if any.

3.  Applicability of RTP subsessions

   Each RTP subsession is able to provide most of the capabilities of a
   full RTP session with some limitations described below associated
   with constraints on SSRC assignment.  No changes are required to RTP
   or SRTP to realize RTP subsessions.  The RTP streams associated with
   an individual media line can be easily identified for separate
   handling (e.g., to provide separate QoS treatment) by filtering on
   the first 16 bits of the SSRC field in addition to the five-tuple.
   RTP systems can enable successful filtering on the port and SSRC
   fields, which are above the IP layer, by adhering to MTU limits to
   avoid IP fragmentation.

   [RFC3550] describes three kinds of systems that can use RTP: end
   systems, translators and mixers.  RTP subsessions can be freely used
   by end systems and mixers since these systems can freely assign any
   SSRC value to each RTP stream.  In particular, a mixer can reassign
   the SSRC value associated with an RTP stream before forwarding.  A
   translator can be realized as a mixer with two differences.  RTCP is
   handled differently, as discussed in
   [I-D.westerlund-avtcore-multiplex-architecture], but these
   differences are well understood and manageable.  In addition, SRTP
   forwarding is more complex when SSRC is changed, as discussed in
   [I-D.westerlund-avtcore-multiplex-architecture].  While there is some
   additional processing needed to change SSRC when forwarding SRTP,
   there seems to be no consensus to require forwarding with SSRC
   preservation.  Systems forwarding RTP streams frequently need to
   provide additional media processing functions, which require the
   decrypting of SRTP packets anyway.

   Some applications require the ability to allocate the same SSRC value
   across multiple ports or media lines.  RTP streams in different RTP
   subsessions are considered to use identical SSRC values if they match
   on the last 16 bits of the SSRC, so RTP subsessions can also be used
   for these applications.

   Most RTP capabilities and extensions depend primarily on the use of a
   different SSRC for each RTP stream.  Since RTP subsessions retain
   this characteristic, they introduce no new compatibility issues.
   Examples of such extensions include FEC, interleaving and RTP
   retransmissions.

Ejzak                   Expires December 6, 2012                [Page 5]
Internet-Draft               RTP subsessions                   June 2012

4.  Example

   An SDP offerer desiring to use a single transport connection for a
   one port audio m line and a two port video m line might construct the
   following SDP offer.

   c=...
   m=audio 49170 RTP/AVP 96 97
   a=rtcp-mux
   a=ssrc-prefix: 0xffc0
   ...
   m=video 49170/2 RTP/AVP 98 99
   a=rtcp-mux
   a=ssrc-prefix: 0xd378 0x2fac
   ...

   The SDP answerer that agrees to use SDP subsessions as described in
   the SDP offer might respond with the following SDP answer.

   c=...
   m=audio 36008 RTP/AVP 96 97
   a=rtcp-mux
   a=ssrc-prefix: 0xffc1
   ...
   m=video 36008/2 RTP/AVP 98 99
   a=rtcp-mux
   a=ssrc-prefix: 0xd379 0x2fad
   ...

   The endpoints will establish one audio and two video SDP subsessions
   associated with the SDP offer/answer exchange.  These SDP subsessions
   and their corresponding RTCP will each share a single transport
   connection using ports 49170 and 36008, respectively.  Media flows
   associated with each SDP subsession can be identified by filtering on
   the first 16 bits of the SSRC field as necessary for differential
   handling, e.g., to assign separate QoS treatment.  Each RTP stream
   sharing the transport connection uses a unique SSRC field so there is
   no ambiguity in associating RTCP messages with their RTP streams.

5.  Evaluation

5.1.  Comparison to BUNDLE

   BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] constrains the
   assignment of SSRC values, so it has similar limitations for use with
   translators.  It must be assured that different RTP streams do not
   share the same SSRC even though they use non-overlapping payload type

Ejzak                   Expires December 6, 2012                [Page 6]
Internet-Draft               RTP subsessions                   June 2012

   values so that each RTCP packet can be uniquely associated with a
   particular RTP stream.  The biggest problem with BUNDLE is that it is
   difficult to partition the RTP streams associated with different
   media lines since this requires filtering on sets of payload type
   values.  RTP subsessions is superior for this purpose since it is
   only necessary to screen for a single value in the first 16 bits of
   the SSRC.  It is also not possible with BUNDLE to associate RTP
   streams from different m lines using a single SSRC value (as it is
   possible to do using the last 16 bits of the SSRC with RTP
   subsessions) due to the need to separate the RTCP messages for each
   RTP stream.  The only short term disadvange of RTP subsessions is
   that the ssrc-prefix attribute has not yet been specified.

   The author proposes that RTP subsessions be considered as a long-term
   replacement for BUNDLE.

5.2.  Comparison to SHIM

   SHIM [I-D.westerlund-avtcore-transport-multiplexing] is the most
   successful scheme in preserving all aspects of each RTP session when
   multiplexing those RTP sessions onto a single transport connection.
   Unfortunately, it changes RTP so can potentially impact many
   different middleboxes.  It also slightly increases the size of each
   media packet, which can be of concern in some bandwidth limited
   deployments.  Since SHIM also requires SDP extensions, there is no
   advantage to either in the time needed to stabilize an RFC.  In
   considering the applicability of RTP subsessions as described in
   section 3 and the disadvantage of modifying RTP, the author does not
   consider the narrow range of applicability of SHIM to justify
   standardization.

   The author proposes that RTP subsessions be considered for
   standardization instead of SHIM.

5.3.  Comparison to other SSRC proposals

   Two expired drafts ([I-D.rosenberg-rtcweb-rtpmux] and
   [I-D.peterson-rosenberg-avt-rtp-ssrc-demux]) propose other means of
   multiplexing based on the SSRC field.  [I-D.rosenberg-rtcweb-rtpmux]
   uses a portion of the SSRC to identify the media type for the RTP
   stream.  This scheme redefines the SSRC field and has significant
   limitations when multiple m lines share the same media type, since
   some other mechanism is still needed to separate them.
   [I-D.peterson-rosenberg-avt-rtp-ssrc-demux] assumes a single SSRC
   value per m line so is not consistent with current RTP multiplexing
   requirements.

   Neither earlier SSRC based scheme fully addresses the requirements

Ejzak                   Expires December 6, 2012                [Page 7]
Internet-Draft               RTP subsessions                   June 2012

   for multiplexing agreed in the working groups.

6.  IANA Considerations

   To be completed.

7.  Security Considerations

   To be completed.

8.  Informative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
              Using Session Description Protocol (SDP) Port Numbers",
              draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
              progress), February 2012.

   [I-D.ietf-rtcweb-rtp-usage]
              Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
              Communication (WebRTC): Media Transport and Use of RTP",
              draft-ietf-rtcweb-rtp-usage-02 (work in progress),
              March 2012.

   [I-D.peterson-rosenberg-avt-rtp-ssrc-demux]
              Peterson, J. and J. Rosenberg, "A Multiplexing Mechanism
              for the Real-Time Protocol (RTP)",
              draft-peterson-rosenberg-avt-rtp-ssrc-demux-00 (work in
              progress), July 2004.

   [I-D.rosenberg-rtcweb-rtpmux]
              Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
              Rescorla, E., and T. Terriberry, "Multiplexing of Real-
              Time Transport Protocol (RTP) Traffic for Browser based
              Real-Time Communications (RTC)",
              draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
              July 2011.

   [I-D.westerlund-avtcore-max-ssrc]
              Westerlund, M., Burman, B., and F. Jansson, "Multiple
              Synchronization sources (SSRC) in RTP Session Signaling",
              draft-westerlund-avtcore-max-ssrc-01 (work in progress),
              April 2012.

   [I-D.westerlund-avtcore-multiplex-architecture]

Ejzak                   Expires December 6, 2012                [Page 8]
Internet-Draft               RTP subsessions                   June 2012

              Westerlund, M., Burman, B., and C. Perkins, "RTP
              Multiplexing Architecture",
              draft-westerlund-avtcore-multiplex-architecture-01 (work
              in progress), March 2012.

   [I-D.westerlund-avtcore-transport-multiplexing]
              Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a
              Single Lower-Layer Transport",
              draft-westerlund-avtcore-transport-multiplexing-02 (work
              in progress), March 2012.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

Author's Address

   Richard Ejzak
   Alcatel-Lucent
   1960 Lucent Lane
   Naperville, Illinois  60563-1594
   US

   Phone: +1 630 979 7036
   Email: richard.ejzak@alcatel-lucent.com

Ejzak                   Expires December 6, 2012                [Page 9]