One document matched: draft-ejzak-avtcore-rtp-subsessions-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:47:33 |