draft-ietf-avtcore-multi-media-rtp-session-03.txt   draft-ietf-avtcore-multi-media-rtp-session-04.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: January 11, 2014 J. Lennox Expires: July 17, 2014 J. Lennox
Vidyo Vidyo
July 10, 2013 January 13, 2014
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-03 draft-ietf-avtcore-multi-media-rtp-session-04
Abstract Abstract
This document specifies how an RTP session can contain media streams This document specifies how an RTP session can contain media 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 January 11, 2014. This Internet-Draft will expire on July 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 29 skipping to change at page 6, line 29
5.1. Usage of the RTP session 5.1. Usage of the RTP session
Before choosing to use this specification, an application implementer Before choosing to use this specification, an application implementer
needs to ensure that they don't have a need for different RTP needs to ensure that they don't have a need for different RTP
sessions between the media types for some reason. The main rule is sessions between the media types for some reason. The main rule is
that if one expects to have equal treatment of all media packets, that if one expects to have equal treatment of all media packets,
then this specification might be suitable. The equal treatment then this specification might be suitable. The equal treatment
include anything from network level up to RTCP reporting and include anything from network level up to RTCP reporting and
feedback. The document Guidelines for using the Multiplexing feedback. The document Guidelines for using the Multiplexing
Features of RTP [I-D.westerlund-avtcore-multiplex-architecture] gives Features of RTP [I-D.ietf-avtcore-multiplex-guidelines] gives more
more detailed guidance on aspects to consider when choosing how to detailed guidance on aspects to consider when choosing how to use RTP
use RTP and specifically sessions. RTP-using applications that need and specifically sessions. RTP-using applications that need or would
or would prefer multiple RTP sessions, but do not require the prefer multiple RTP sessions, but do not require the functionalities
functionalities or behaviours that multiple transport flows give, can or behaviours that multiple transport flows give, can consider using
consider using Multiple RTP Sessions on a Single Lower-Layer Multiple RTP Sessions on a Single Lower-Layer Transport
Transport [I-D.westerlund-avtcore-transport-multiplexing]. It needs [I-D.westerlund-avtcore-transport-multiplexing]. It needs to be
to be noted that some difference in treatment is still possible to noted that some difference in treatment is still possible to achieve,
achieve, for example marking based QoS, or RTCP feedback traffic for for example marking based QoS, or RTCP feedback traffic for only some
only some media streams. media streams.
The second important consideration is the resulting behaviour when The second important consideration is the resulting behaviour when
media flows to be sent within a single RTP session does not have media flows to be sent within a single RTP session does not have
similar bandwidth. There are limitations in the RTCP timing rules, similar bandwidth. There are limitations in the RTCP timing rules,
and this implies a common RTCP reporting interval across all and this implies a common RTCP reporting interval across all
participants in a session. If an RTP session contains flows with participants in a session. If an RTP session contains flows with
very different bandwidths, for example low-rate audio coupled with very different bandwidths, for example low-rate audio coupled with
high-quality video, this can result in either excessive or high-quality video, this can result in either excessive or
insufficient RTCP for some flows, depending how the RTCP session insufficient RTCP for some flows, depending how the RTCP session
bandwidth, and hence reporting interval, is configured. This is bandwidth, and hence reporting interval, is configured. This is
skipping to change at page 12, line 6 skipping to change at page 12, line 6
is that a given SSRC has its own RTP timestamp and sequence number is that a given SSRC has its own RTP timestamp and sequence number
spaces. The same way that you can't send two streams of encoded spaces. The same way that you can't send two streams of encoded
audio on the same SSRC, you can't send one audio and one video audio on the same SSRC, you can't send one audio and one video
encoding on the same SSRC. Each media encoding when made into an RTP encoding on the same SSRC. Each media encoding when made into an RTP
stream needs to have the sole control over the sequence number and stream needs to have the sole control over the sequence number and
timestamp space. If not, one would not be able to detect packet loss timestamp space. If not, one would not be able to detect packet loss
for that particular stream. Nor can one easily determine which clock for that particular stream. Nor can one easily determine which clock
rate a particular SSRCs timestamp will increase with. For additional rate a particular SSRCs timestamp will increase with. For additional
arguments why RTP payload type based multiplexing of multiple media arguments why RTP payload type based multiplexing of multiple media
streams doesn't work see Appendix A in streams doesn't work see Appendix A in
[I-D.westerlund-avtcore-multiplex-architecture]. [I-D.ietf-avtcore-multiplex-guidelines].
6.3. Payload Type Applicability 6.3. Payload Type Applicability
Most Payload Types have a native media type, like an audio codec is Most Payload Types have a native media type, like an audio codec is
natural belonging to the audio media type. However, there exist a natural belonging to the audio media type. However, there exist a
number of RTP payload types that don't have a native media type. For number of RTP payload types that don't have a native media type. For
example, transport robustness mechanisms like RTP Retransmission example, transport robustness mechanisms like RTP Retransmission
[RFC4588] and Generic FEC [RFC5109] inherit their media type from [RFC4588] and Generic FEC [RFC5109] inherit their media type from
what they protect. RTP Retransmission is explicitly bound to the what they protect. RTP Retransmission is explicitly bound to the
payload type it is protecting, and thus will inherit it. However payload type it is protecting, and thus will inherit it. However
skipping to change at page 15, line 32 skipping to change at page 15, line 32
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Christer Holmberg, Gunnar Hellstroem, The authors would like to thank Christer Holmberg, Gunnar Hellstroem,
and Charles Eckel for the feedback on the document. and Charles Eckel for the feedback on the document.
12. References 12. References
12.1. Normative References 12.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, "RTP Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
Considerations for Endpoints Sending Multiple Media "Sending Multiple Media Streams in a Single RTP Session",
Streams", draft-ietf-avtcore-rtp-multi-stream-00 (work in draft-ietf-avtcore-rtp-multi-stream-01 (work in progress),
progress), April 2013. July 2013.
[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,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-04 (work in progress), June 2013. bundle-negotiation-05 (work in progress), October 2013.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
12.2. Informative References 12.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-01 (work in progress), July 2013.
[I-D.lennox-payload-ulp-ssrc-mux] [I-D.lennox-payload-ulp-ssrc-mux]
Lennox, J., "Supporting Source-Multiplexing of the Real- Lennox, J., "Supporting Source-Multiplexing of the Real-
Time Transport Protocol (RTP) Payload for Generic Forward Time Transport Protocol (RTP) Payload for Generic Forward
Error Correction", draft-lennox-payload-ulp-ssrc-mux-00 Error Correction", draft-lennox-payload-ulp-ssrc-mux-00
(work in progress), February 2013. (work in progress), February 2013.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-03 (work
in progress), February 2013.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Single Lower-Layer Transport", draft-westerlund-avtcore- Sessions onto a Single Lower-Layer Transport", draft-
transport-multiplexing-05 (work in progress), February westerlund-avtcore-transport-multiplexing-07 (work in
2013. progress), October 2013.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, December for Generic Forward Error Correction", RFC 2733, December
1999. 1999.
 End of changes. 12 change blocks. 
31 lines changed or deleted 31 lines changed or added

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