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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |