draft-ietf-avtcore-multi-media-rtp-session-10.txt   draft-ietf-avtcore-multi-media-rtp-session-11.txt 
AVTCORE WG M. Westerlund AVTCORE WG M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3550, 3551 (if approved) C. Perkins Updates: 3550, 3551 (if approved) C. Perkins
Intended status: Standards Track University of Glasgow Intended status: Standards Track University of Glasgow
Expires: March 18, 2016 J. Lennox Expires: May 15, 2016 J. Lennox
Vidyo Vidyo
September 15, 2015 November 12, 2015
Sending Multiple Types of Media in a Single RTP Session Sending Multiple Types of Media in a Single RTP Session
draft-ietf-avtcore-multi-media-rtp-session-10 draft-ietf-avtcore-multi-media-rtp-session-11
Abstract Abstract
This document specifies how an RTP session can contain RTP Streams This document specifies how an RTP session can contain RTP Streams
with media from multiple media types such as audio, video, and text. with media from multiple media types such as audio, video, and text.
This has been restricted by the RTP Specification, and thus this This has been restricted by the RTP Specification, and thus this
document updates RFC 3550 and RFC 3551 to enable this behaviour for document updates RFC 3550 and RFC 3551 to enable this behaviour for
applications that satisfy the applicability for using multiple media applications that satisfy the applicability for using multiple media
types in a single RTP session. types in a single RTP session.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 18, 2016. This Internet-Draft will expire on May 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Using Multiple Media Types in a Single RTP Session . . . . . 6 5. Using Multiple Media Types in a Single RTP Session . . . . . 6
5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6
5.2. Demultiplexing media types within an RTP session . . . . 7 5.2. Demultiplexing media types within an RTP session . . . . 7
5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8
5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9
6. Extension Considerations . . . . . . . . . . . . . . . . . . 9 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9
6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9
6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10
6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11
7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Real-time Transport Protocol [RFC3550] was designed to use The Real-time Transport Protocol [RFC3550] was designed to use
separate RTP sessions to transport different types of media. This separate RTP sessions to transport different types of media. This
implies that different transport layer flows are used for different implies that different transport layer flows are used for different
media streams. For example, a video conferencing application might media streams. For example, a video conferencing application might
send audio and video traffic RTP flows on separate UDP ports. With send audio and video traffic RTP flows on separate UDP ports. With
increased use of network address/port translation, firewalls, and increased use of network address/port translation, firewalls, and
skipping to change at page 3, line 35 skipping to change at page 3, line 35
application. The media type corresponds to the value used in the application. The media type corresponds to the value used in the
<media> field of an SDP m= line. The media types defined at the <media> field of an SDP m= line. The media types defined at the
time of this writing are "audio", "video", "text", "image", time of this writing are "audio", "video", "text", "image",
"application", and "message". [RFC4566] [RFC6466] "application", and "message". [RFC4566] [RFC6466]
Quality of Service (QoS): Network mechanisms that are intended to Quality of Service (QoS): Network mechanisms that are intended to
ensure that the packets within a flow or with a specific marking ensure that the packets within a flow or with a specific marking
are transported with certain properties. are transported with certain properties.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Background and Motivation 3. Background and Motivation
RTP was designed to support multimedia sessions, containing multiple RTP was designed to support multimedia sessions, containing multiple
types of media sent simultaneously, by using multiple transport layer types of media sent simultaneously, by using multiple transport layer
flows. The existence of network address translators, firewalls, and flows. The existence of network address translators, firewalls, and
other middleboxes complicates this, however, since a mechanism is other middleboxes complicates this, however, since a mechanism is
needed to ensure that all the transport layer flows needed by the needed to ensure that all the transport layer flows needed by the
application can be established. This has three consequences: application can be established. This has three consequences:
skipping to change at page 4, line 44 skipping to change at page 4, line 48
with sending different media types in a single RTP session. with sending different media types in a single RTP session.
This memo updates [RFC3550] and [RFC3551] to allow RTP sessions to This memo updates [RFC3550] and [RFC3551] to allow RTP sessions to
contain more than one media type in certain circumstances, and gives contain more than one media type in certain circumstances, and gives
guidance on when it is safe to send multiple media types in a single guidance on when it is safe to send multiple media types in a single
RTP session. RTP session.
4. Applicability 4. Applicability
This specification has limited applicability, and anyone intending to This specification has limited applicability, and anyone intending to
use it MUST ensure that their application and use meets the following use it needs to ensure that their application and use case meets the
criteria: following criteria:
Equal treatment of media: The use of a single RTP session enforces Equal treatment of media: The use of a single RTP session requires
similar treatment on all types of media used within the session. similar network treatment for all types of media used within the
Applications that require significantly different network QoS or session. Applications that require significantly different
RTCP configuration for different media streams are better suited network quality of service (QoS) or RTCP configuration for
by sending those media streams on separate RTP session, using different media streams are better suited by sending those media
separate transport layer flows for each, since that gives greater streams on separate RTP session, using separate transport layer
flexibility. Further guidance is given in flows for each, since that gives greater flexibility. Further
[I-D.ietf-avtcore-multiplex-guidelines] and guidance on how to provide differential treatment for some media
is given in [I-D.ietf-avtcore-multiplex-guidelines] and
[I-D.ietf-dart-dscp-rtp]. [I-D.ietf-dart-dscp-rtp].
Compatible RTCP Behaviour: The RTCP timing rules enforce a single Compatible RTCP Behaviour: The RTCP timing rules enforce a single
RTCP reporting interval for all participants in an RTP session. RTCP reporting interval for all participants in an RTP session.
Flows with very different media sending rate or RTCP feedback Flows with very different media sending rate or RTCP feedback
requirements cannot be multiplexed together, since this leads to requirements cannot be multiplexed together, since this leads to
either excessive or insufficient RTCP for some flows, depending either excessive or insufficient RTCP for some flows, depending
how the RTCP session bandwidth, and hence reporting interval, is how the RTCP session bandwidth, and hence reporting interval, is
configured. For example, it is likely not feasible to find a configured. For example, it is likely not feasible to find a
single RTCP configuration that simultaneously suits both a low- single RTCP configuration that simultaneously suits both a low-
skipping to change at page 8, line 23 skipping to change at page 8, line 28
same type, subject to certain restrictions [RFC7160], but MUST NOT same type, subject to certain restrictions [RFC7160], but MUST NOT
change media type during its lifetime. For example, an SSRC can change media type during its lifetime. For example, an SSRC can
change between different audio formats, but cannot start sending change between different audio formats, but cannot start sending
audio then change to sending video. The lifetime of an SSRC ends audio then change to sending video. The lifetime of an SSRC ends
when an RTCP BYE packet for that SSRC is sent, or when it ceases when an RTCP BYE packet for that SSRC is sent, or when it ceases
transmission for long enough that it times out for the other transmission for long enough that it times out for the other
participants in the session. participants in the session.
The main motivation is that a given SSRC has its own RTP timestamp The main motivation is that a given SSRC has its own RTP timestamp
and sequence number spaces. The same way that you can't send two and sequence number spaces. The same way that you can't send two
encoded streams of audio on the same SSRC, you can't send one encoded encoded streams of audio with the same SSRC, you can't send one
audio and one encoded video stream on the same SSRC. Each encoded encoded audio and one encoded video stream with the same SSRC. Each
stream when made into an RTP stream needs to have the sole control encoded stream when made into an RTP stream needs to have the sole
over the sequence number and timestamp space. If not, one would not control over the sequence number and timestamp space. If not, one
be able to detect packet loss for that particular encoded stream. would not be able to detect packet loss for that particular encoded
Nor can one easily determine which clock rate a particular SSRCs stream. Nor can one easily determine which clock rate a particular
timestamp will increase with. For additional arguments why RTP SSRCs timestamp will increase with. For additional arguments why RTP
payload type based multiplexing of multiple media sources doesn't payload type based multiplexing of multiple media sources doesn't
work see [I-D.ietf-avtcore-multiplex-guidelines]. work see [I-D.ietf-avtcore-multiplex-guidelines].
Within an RTP session where multiple media types have been configured Within an RTP session where multiple media types have been configured
for use, an SSRC can only send one type of media during its lifetime for use, an SSRC can only send one type of media during its lifetime
(i.e., it can switch between different audio codecs, since those are (i.e., it can switch between different audio codecs, since those are
both the same type of media, but cannot switch between audio and both the same type of media, but cannot switch between audio and
video). Different SSRCs MUST be used for the different media video). Different SSRCs MUST be used for the different media
sources, the same way multiple media sources of the same media type sources, the same way multiple media sources of the same media type
already have to do. The payload type will inform a receiver which already have to do. The payload type will inform a receiver which
skipping to change at page 11, line 25 skipping to change at page 11, line 30
formats), since this unnecessarily uses up RTP payload type values, formats), since this unnecessarily uses up RTP payload type values,
and adds no value for demultiplexing since there might be multiple and adds no value for demultiplexing since there might be multiple
streams of the same media type). streams of the same media type).
The combination of an original RTP session using multiple media types The combination of an original RTP session using multiple media types
with a associated generic FEC session can be signalled using SDP with with a associated generic FEC session can be signalled using SDP with
the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In
this case, the RTP session carrying the FEC streams will be its own this case, the RTP session carrying the FEC streams will be its own
BUNDLE group. The m= line for each original stream and the m= line BUNDLE group. The m= line for each original stream and the m= line
for the corresponding FEC stream are grouped using the SDP grouping for the corresponding FEC stream are grouped using the SDP grouping
framework with either the FEC [RFC4756] or the FEC-FR [RFC5956] framework using either the FEC-FR [RFC5956] grouping or, for
grouping. This is similar to the situation that arises for RTP backwards compatibility, the FEC [RFC4756] grouping. This is similar
retransmission with session multiplexing discussed in Section 6.1. to the situation that arises for RTP retransmission with session
multiplexing discussed in Section 6.1.
The Source-Specific Media Attributes [RFC5576] specification defines The Source-Specific Media Attributes [RFC5576] specification defines
an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) an SDP extension (the "FEC" semantic of the "ssrc-group" attribute)
to signal FEC relationships between multiple RTP streams within a to signal FEC relationships between multiple RTP streams within a
single RTP session. This cannot be used with generic FEC, since the single RTP session. This cannot be used with generic FEC, since the
FEC repair packets need to have the same SSRC value as the source FEC repair packets need to have the same SSRC value as the source
packets being protected. There is ongoing work on an ULP extension packets being protected. There is ongoing work on an ULP extension
to allow it be use FEC RTP streams within the same RTP Session as the to allow it be use FEC RTP streams within the same RTP Session as the
source stream [I-D.lennox-payload-ulp-ssrc-mux]. source stream [I-D.lennox-payload-ulp-ssrc-mux].
skipping to change at page 13, line 21 skipping to change at page 13, line 29
The authors would like to thank Christer Holmberg, Gunnar Hellstroem, The authors would like to thank Christer Holmberg, Gunnar Hellstroem,
Charles Eckel, and Tolga Asveren for their feedback on the document. Charles Eckel, and Tolga Asveren for their feedback on the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-08 (work in progress), draft-ietf-avtcore-rtp-multi-stream-09 (work in progress),
July 2015. September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-23 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 12 change blocks. 
30 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/