draft-ietf-avtcore-multi-media-rtp-session-00.txt   draft-ietf-avtcore-multi-media-rtp-session-01.txt 
AVTCORE WG M. Westerlund AVTCORE WG M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3550 (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: April 11, 2013 J. Lennox Expires: April 25, 2013 J. Lennox
Vidyo Vidyo
October 8, 2012 October 22, 2012
Multiple Media Types in an RTP Session Multiple Media Types in an RTP Session
draft-ietf-avtcore-multi-media-rtp-session-00 draft-ietf-avtcore-multi-media-rtp-session-01
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 to enable this behavior for applications document updates RFC 3550 and RFC 3551 to enable this behavior for
that satisfy the applicability for using multiple media types in a applications that satisfy the applicability for using multiple media
single RTP session. types in a single RTP session.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 11, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 22 skipping to change at page 2, line 22
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 4 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 4
3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5
3.3. Architectural Equality . . . . . . . . . . . . . . . . . . 5 3.3. Architectural Equality . . . . . . . . . . . . . . . . . . 5
4. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 5
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Usage of the RTP session . . . . . . . . . . . . . . . . . 6 5.1. Usage of the RTP session . . . . . . . . . . . . . . . . . 6
5.2. Signalled Support . . . . . . . . . . . . . . . . . . . . 6 5.2. Signalled Support . . . . . . . . . . . . . . . . . . . . 7
5.3. Homogeneous Multi-party . . . . . . . . . . . . . . . . . 7 5.3. Homogeneous Multi-party . . . . . . . . . . . . . . . . . 7
5.4. Reduced number of Payload Types . . . . . . . . . . . . . 8 5.4. Reduced number of Payload Types . . . . . . . . . . . . . 8
5.5. Stream Differentiation . . . . . . . . . . . . . . . . . . 8 5.5. Stream Differentiation . . . . . . . . . . . . . . . . . . 8
5.6. Non-compatible Extensions . . . . . . . . . . . . . . . . 8 5.6. Non-compatible Extensions . . . . . . . . . . . . . . . . 9
6. RTP Session Specification . . . . . . . . . . . . . . . . . . 9 6. RTP Session Specification . . . . . . . . . . . . . . . . . . 9
6.1. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Sender Source Restrictions . . . . . . . . . . . . . . . . 10 6.2. Sender Source Restrictions . . . . . . . . . . . . . . . . 11
6.3. Payload Type Applicability . . . . . . . . . . . . . . . . 10 6.3. Payload Type Applicability . . . . . . . . . . . . . . . . 12
6.4. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Extension Considerations . . . . . . . . . . . . . . . . . . . 11 7. Extension Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 12 7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 14
7.2. Generic FEC . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Generic FEC . . . . . . . . . . . . . . . . . . . . . . . 14
8. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. SDP-Based Signalling . . . . . . . . . . . . . . . . . . . 13 8.1. SDP-Based Signalling . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
When the Real-time Transport Protocol (RTP) [RFC3550] was designed, When the Real-time Transport Protocol (RTP) [RFC3550] was designed,
close to 20 years ago, IP networks were very different compared to close to 20 years ago, IP networks were very different compared to
the ones in 2012 when this is written. The almost ubiquitous the ones in 2012 when this is written. The almost ubiquitous
deployment of Network Address Translators (NAT) and Firewalls has deployment of Network Address Translators (NAT) and Firewalls has
increased the cost and likely-hood of communication failure when increased the cost and likely-hood of communication failure when
using many different transport flows. Thus there exists a pressure using many different transport flows. Thus there exists a pressure
to reduce the number of concurrent transport flows. to reduce the number of concurrent transport flows.
RTP [RFC3550] as defined recommends against having multiple media RTP [RFC3550] recommends against sending several different types of
types, like audio and video, in the same RTP session. The motivation media, for example audio and video, in a single RTP session. The RTP
for this is dependent on particular usage or dependencies on lower profile for Audio and Video Conferences with Minimal Control (RTP/
layer Quality of Service (QoS). When these aren't present, there are AVP) [RFC3551] mandates a similar restriction. The motivation for
no strong RTP reasons for not allowing multiple media types in one these limitations is partly to allow lower layer Quality of Service
RTP session. However, the Session Description Protocol (SDP) (QoS) mechanisms to be used, and partly due to limitations of the
[RFC4566], as one of the dominant signalling method for establishing RTCP timing rules that require all media in a session to have similar
RTP session, has enforced this rule, by not allowing multiple media bandwidth. The Session Description Protocol (SDP) [RFC4566], as one
types for a given receiver destination or set of ICE candidates, of the dominant signalling method for establishing RTP session, has
which is the most common method to determine which RTP session the enforced this rule, simply by not allowing multiple media types for a
packets are intended for. given receiver destination or set of ICE candidates, which is the
most common method to determine which RTP session the packets are
intended for.
The fact that these limitations have been in place for so long a The fact that these limitations have been in place for so long a
time, in addition to RFC 3550 being written without fully considering time, in addition to RFC 3550 being written without fully considering
multiple media types in an RTP session, does result in a number of multiple media types in an RTP session, does result in a number of
considerations being needed. This document provides such considerations being needed when allowing this behavior. This
considerations regarding applicability as well as functionality, document provides such considerations regarding applicability as well
including normative specification of behavior. as functionality, including normative specification of behavior.
First, some basic definitions are provided. This is followed by a First, some basic definitions are provided. This is followed by a
background that discusses the motivation in more detail. A overview background that discusses the motivation in more detail. A overview
of the solution of how to provide multiple media types in one RTP of the solution of how to provide multiple media types in one RTP
session is then presented. Next is the formal applicability this session is then presented. Next is the formal applicability this
specification have followed by the normative specification. This is specification have followed by the normative specification. This is
followed by a discussion how some RTP/RTCP Extensions should function followed by a discussion how some RTP/RTCP Extensions should function
in the case of multiple media types in one RTP session. A in the case of multiple media types in one RTP session. A
specification of the requirements on signalling from this specification of the requirements on signalling from this
specification and a look how this is realized in SDP using Bundle specification and a look how this is realized in SDP using Bundle
skipping to change at page 5, line 31 skipping to change at page 5, line 31
Many RTP-using applications don't utilize any network level Quality Many RTP-using applications don't utilize any network level Quality
of Service functions. Nor do they expect or desire any separation in of Service functions. Nor do they expect or desire any separation in
network treatment of its media packets, independent of whether they network treatment of its media packets, independent of whether they
are audio, video or text. When an application has no such desire, it are audio, video or text. When an application has no such desire, it
doesn't need to provide a transport flow structure that simplifies doesn't need to provide a transport flow structure that simplifies
flow based QoS. flow based QoS.
3.3. Architectural Equality 3.3. Architectural Equality
For applications that don't desire any type of different treatment, For applications that don't require different lower-layer QoS for
neither on the transport level nor in RTP or RTCP reporting, using different media types, and that have no special requirements for RTP
the same RTP session for both media types appears a reasonable extensions or RTCP reporting, the requirement to separate different
choice. The architecture should be neutral to media type, rather media into different RTP sessions may seem unnecessary. Provided the
look at what it provides based on the application users choice. media flows have similar bandwidth requirements, so that the RTCP
Therefore this bias should be removed and let the application timing rules work, using the same RTP session for several types of
designer make the choice if they need multiple RTP sessions or not media at once appears a reasonable choice. The architecture should
based on other aspects. be agnostic about the type of media being carried in an RTP session
to the extent possible given the constraints of the protocol.
4. Overview of Solution 4. Overview of Solution
The goal of the solution is to enable having one or more RTP The goal of the solution is to enable having one or more RTP
sessions, where each RTP session may contain two or more media types. sessions, where each RTP session may contain two or more media types.
This includes having multiple RTP sessions containing a given media This includes having multiple RTP sessions containing a given media
type, for example having three sessions containing video and audio. type, for example having three sessions containing video and audio.
The solution is quite straightforward. The first step is to override The solution is quite straightforward. The first step is to override
the SHOULD and SHOULD NOT language of the RTP specification the SHOULD and SHOULD NOT language of the RTP specification
[RFC3550]. This is done by appropriate exception clauses given that [RFC3550]. Similar change is needed to a sentence in Section 6 of
this specification is followed. [RFC3551] that states that "different media types SHALL NOT be
interleaved or multiplexed within a single RTP Session". This is
resolved by appropriate exception clauses given that this
specification and its applicability is followed.
Within an RTP session where multiple media types have been configured Within an RTP session where multiple media types have been configured
for use, a SSRC may only send one media type during its lifetime. for use, an SSRC may send only one type of media during its lifetime
Different SSRCs must be used for the different media sources, the (i.e., it can switch between different audio codecs, since those are
same way multiple media sources of the same media type already have both the same type of media, but cannot switch between audio and
to do. The payload type will inform a receiver which media type the video). Different SSRCs must be used for the different media
SSRC is being used for. Thus the payload type must be unique across sources, the same way multiple media sources of the same media type
all of the payload configurations independent of media type that may already have to do. The payload type will inform a receiver which
be used in the RTP session. media type the SSRC is being used for. Thus the payload type must be
unique across all of the payload configurations independent of media
type that may be used in the RTP session.
Some few extra considerations within the RTP sessions also needs to Some few extra considerations within the RTP sessions also needs to
be considered. RTCP bandwidth and regular reporting suppression be considered. RTCP bandwidth and regular reporting suppression
(AVPF and SAVPF) should be considered to be configured. Certain (AVPF and SAVPF) should be considered to be configured. Certain
payload types like FEC also need additional rules. payload types like FEC also need additional rules.
The final important part of the solution to this is to use signalling The final important part of the solution to this is to use signalling
and ensure that agreement on using multiple media types in an RTP and ensure that agreement on using multiple media types in an RTP
session exists, and how that then is configured. Thus document session exists, and how that then is configured. Thus document
documents some existing requirements, while an external reference documents some existing requirements, while an external reference
defines how this is accomplished in SDP. defines how this is accomplished in SDP.
5. Applicability 5. Applicability
This specification has limited applicability and any one intending to This specification has limited applicability and any one intending to
use must ensure that their application and usage meets the below use it must ensure that their application and usage meets the below
criteria for usage. criteria.
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 Guidance on RTP Multiplexing Architecture feedback. The document Guidelines for using the Multiplexing
[I-D.westerlund-avtcore-multiplex-architecture] gives more detailed Features of RTP [I-D.westerlund-avtcore-multiplex-architecture] gives
guidance on aspects to consider when choosing how to use RTP and more detailed guidance on aspects to consider when choosing how to
specifically sessions. RTP-using applications that need or would use RTP and specifically sessions. RTP-using applications that need
prefer multiple RTP sessions, but do not require the functionalities or would prefer multiple RTP sessions, but do not require the
or behaviors that multiple transport flows give, can consider using functionalities or behaviors that multiple transport flows give, can
Multiple RTP Sessions on a Single Lower-Layer Transport consider using Multiple RTP Sessions on a Single Lower-Layer
[I-D.westerlund-avtcore-transport-multiplexing]. Transport [I-D.westerlund-avtcore-transport-multiplexing].
The second important consideration is that all media flows to be sent
within a single RTP session need to have similar bandwidth. This is
due to limitations of the RTCP timing rules, and the need for a
common RTCP reporting interval across all participants in a session
to avoid problems with premature SSRC timeouts. If an RTP session
contains flows with very different bandwidths, for example low-rate
audio coupled with high-quality video, this will result in either
excessive or insufficient RTCP for some flows, depending how the RTCP
session bandwidth, and hence reporting interval, is configured. This
is discussed further in Section 6.4.
5.2. Signalled Support 5.2. Signalled Support
Usage of this specification is not compatible with anyone following Usage of this specification is not compatible with anyone following
RFC 3550 and intending to have different RTP sessions for each media RFC 3550 and intending to have different RTP sessions for each media
type. Therefore there must be mutual agreement to use multiple media type. Therefore there must be mutual agreement to use multiple media
types in one RTP session by all participants within an RTP session. types in one RTP session by all participants within an RTP session.
This agreement must in most cases be determined using signalling. This agreement must in most cases be determined using signalling.
This requirement can be a problem for signalling solutions that can't This requirement can be a problem for signalling solutions that can't
skipping to change at page 10, line 6 skipping to change at page 10, line 26
applicability constraints. applicability constraints.
The second sentence is changed to: The second sentence is changed to:
Separate audio and video streams SHOULD NOT be carried in a single Separate audio and video streams SHOULD NOT be carried in a single
RTP session and demultiplexed based on the payload type or SSRC RTP session and demultiplexed based on the payload type or SSRC
fields, unless multiplexed based on both SSRC and payload type and fields, unless multiplexed based on both SSRC and payload type and
usage meets what Multiple Media Types in an RTP Session [RFCXXXX] usage meets what Multiple Media Types in an RTP Session [RFCXXXX]
specifies. specifies.
Second paragraph of Section 6 in RTP Profile for Audio and Video
Conferences with Minimal Control [RFC3551] says:
The payload types currently defined in this profile are assigned
to exactly one of three categories or media types: audio only,
video only and those combining audio and video. The media types
are marked in Tables 4 and 5 as "A", "V" and "AV", respectively.
Payload types of different media types SHALL NOT be interleaved or
multiplexed within a single RTP session, but multiple RTP sessions
MAY be used in parallel to send multiple media types. An RTP
source MAY change payload types within the same media type during
a session. See the section "Multiplexing RTP Sessions" of RFC
3550 for additional explanation.
This specifications purpose is to violate that existing SHALL NOT
under certain conditions. Thus also this sentence must be changed to
allow for multiple media type's payload types in the same session.
The above sentence is changed to:
Payload types of different media types SHALL NOT be interleaved or
multiplexed within a single RTP session unless as specifified and
under the restriction in Multiple Media Types in an RTP Session
[RFCXXXX]. Multiple RTP sessions MAY be used in parallel to send
multiple media types.
RFC-Editor Note: Please replace RFCXXXX with the RFC number of this RFC-Editor Note: Please replace RFCXXXX with the RFC number of this
specification when assigned. specification when assigned.
TBD: Discussion of the motivations in Section 5.2 of the RTP We can now go on and discuss the five bullets that are motivating the
Specification [RFC3550]. previous in Section 5.2 of the RTP Specification [RFC3550]. They are
repeated here for the reader's convenience:
1. If, say, two audio streams shared the same RTP session and the
same SSRC value, and one were to change encodings and thus
acquire a different RTP payload type, there would be no general
way of identifying which stream had changed encodings.
2. An SSRC is defined to identify a single timing and sequence
number space. Interleaving multiple payload types would require
different timing spaces if the media clock rates differ and would
require different sequence number spaces to tell which payload
type suffered packet loss.
3. The RTCP sender and receiver reports (see Section 6.4 of RFC
3550) can only describe one timing and sequence number space per
SSRC and do not carry a payload type field.
4. An RTP mixer would not be able to combine interleaved streams of
incompatible media into one stream.
5. Carrying multiple media in one RTP session precludes: the use of
different network paths or network resource allocations if
appropriate; reception of a subset of the media if desired, for
example just audio if video would exceed the available bandwidth;
and receiver implementations that use separate processes for the
different media, whereas using separate RTP sessions permits
either single- or multiple-process implementations.
Bullets 1 to 3 are all related to that each media source must use one
or more unique SSRCs to avoid these issues as mandated below
(Section 6.2). Bullet 4 can be served by two arguments, first of all
each SSRC will commonly a native media type, communicated through the
RTP payload type, allowing a middlebox to do media type specific
operations. The second argument is that in many contexts blind
combining without additional contexts are anyway not suitable.
Regarding bullet 5 this is a understood and explicitly stated
applicability limitations for the method described in this document.
6.2. Sender Source Restrictions 6.2. Sender Source Restrictions
A SSRC in the RTP session MUST only send one media type (audio, A SSRC in the RTP session MUST only send one media type (audio,
video, text etc.) during the SSRC's lifetime. The main motivation is video, text etc.) during the SSRC's lifetime. The main motivation is
that a given SSRC has its own RTP timestamp and sequence number 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
skipping to change at page 10, line 42 skipping to change at page 12, line 26
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
Generic FEC is a excellent example of an RTP payload type that has no Generic FEC is a excellent example of an RTP payload type that has no
natural media type. The media type for what it protects is not natural media type. The media type for what it protects is not
relevant as it is the recovered RTP packets that have a particular relevant as it is the recovered RTP packets that have a particular
media type, and thus Generic FEC is best categorized as an media type, and thus Generic FEC is best categorized as an
application media type. application media type.
The above discussion is relevant to what limitations exist for RTP The above discussion is relevant to what limitations exist for RTP
payload type usage within an RTP session that has multiple media payload type usage within an RTP session that has multiple media
types. When it comes to Generic FEC, is an configured payload type types. In fact this document (Section 7.2) suggest that for usage of
allowed to be used to protect both audio SSRCs and Video SSRCs? Note Generic FEC (XOR-based) as defined in RFC 5109 can actually use a
a particular SSRC carrying Generic FEC will clearly only protect a single media type when used with independent RTP sessions for source
specific SSRC and thus that instance is bound to the SSRC's media and repair data.
type. For this specific case, it appears possible to have one be
applicable to both. However, in cases when the signalling is setup
to enable fallback to using separate RTP sessions, then using a
different media type, e.g. application, than the media being
protected can create issues.
TBD: What recommendations are needed here? Note a particular SSRC carrying Generic FEC will clearly only
protect a specific SSRC and thus that instance is bound to the
SSRC's media type. For this specific case, it is possible to have
one be applicable to both. However, in cases when the signalling
is setup to enable fallback to using separate RTP sessions, then
using a different media type, e.g. application, than the media
being protected can create issues.
6.4. RTCP 6.4. RTCP
All SSRCs in an RTP session fall under the same set of RTCP An RTP session has a single set of parameters that configure the
configuration parameters, such as the RR and RS bandwidth and the session bandwidth, the RTCP sender and receiver fractions (e.g., via
trr-int parameter if AVPF or SAVPF is used. This means that at least the SDP "b=RR:" and "b=RS: lines), and the parameters of the RTP/AVPF
the regular reporting period by, and on, a source will be equal, profile [RFC4585] (e.g., trr-int) if that profile (or its secure
independent of the media type for that source. This should in most extension, RTP/SAVPF [RFC5124]) is used. As a consequence, the RTCP
cases not be an issue, but it may result in more frequent reporting reporting interval will be the same for every SSRC in an RTP session.
than is considered necessary for a particular media type or set of This uniform RTCP reporting interval can result in RTCP reports being
media sources. Having multiple media types in one RTP session also sent more often than is considered desirable for a particular media
results in more SSRCs being present in this RTP session. This type. For example, if an audio flow is multiplexed with a high
increasing the amount of cross reporting between the SSRCs. From an quality video flow where the session bandwidth is configured to match
RTCP perspective, two RTP sessions with half the number of SSRCs in the video bandwidth, this can result in the RTCP packets having a
each will be slightly more efficient. If someone needs either the greater bandwidth allocation than the audio data rate. If the
higher efficiency due to the lesser number of SSRCs or the fact that reduced minimum RTCP interval described in Section 6.2 of [RFC3550]
one can't tailor RTCP usage per media type, they need to use is used in the session, which might be appropriate for video where
independent RTP sessions. rapid feedback is wanted, the audio sources could be required to send
RTCP packets more often than they send audio data packets. This is
clearly undesirable, and while the mismatch can be reduced through
careful tuning of the RTCP parameters, particularly trr_int in RTP/
AVPF sessions, it is inherent in the design of the RTCP timing rules,
and affects all RTP sessions containing flows with mismatched
bandwidth.
(tbd: A future version of this draft needs to provide details of
the extent of this problem, recommendations for how to tune the
RTCP bandwidth fraction and trr_int, and when the mismatch is so
great that it's better to use separate RTP sessions. The
recommendations will likely be different for RTP/AVP and RTP/AVPF
sessions, since trr_int offers a potential solution that is not
suitable in legacy session.)
Having multiple media types in one RTP session also results in more
SSRCs being present in this RTP session. This increasing the amount
of cross reporting between the SSRCs. From an RTCP perspective, two
RTP sessions with half the number of SSRCs in each will be slightly
more efficient. If someone needs either the higher efficiency due to
the lesser number of SSRCs or the fact that one can't tailor RTCP
usage per media type, they need to use independent RTP sessions.
When it comes to handling multiple SSRCs in an RTP session there is a When it comes to handling multiple SSRCs in an RTP session there is a
clarification under discussion in Real-Time Transport Protocol (RTP) clarification under discussion in Real-Time Transport Protocol (RTP)
Considerations for Multi-Stream Endpoints Considerations for Multi-Stream Endpoints
[I-D.lennox-avtcore-rtp-multi-stream]. When it comes to configuring [I-D.lennox-avtcore-rtp-multi-stream]. When it comes to configuring
RTCP the need for regular periodic reporting needs to be weighted RTCP the need for regular periodic reporting needs to be weighted
against any feedback or control messages being sent. The against any feedback or control messages being sent. The
applications using AVPF or SAVPF are RECOMMENDED to consider setting applications using AVPF or SAVPF are RECOMMENDED to consider setting
trr-int parameter to a value suitable for the applications needs, trr-int parameter to a value suitable for the applications needs,
thus potentially reducing the need for regular reporting and thus thus potentially reducing the need for regular reporting and thus
skipping to change at page 12, line 32 skipping to change at page 14, line 38
Open Issue: When using SDP to signal retransmission for one RTP Open Issue: When using SDP to signal retransmission for one RTP
session with multiple media types and one RTP session for the session with multiple media types and one RTP session for the
retransmission data will cause a situation where one will have retransmission data will cause a situation where one will have
multiple m= lines grouped using FID and the ones belonging to multiple m= lines grouped using FID and the ones belonging to
respective RTP session being grouped using BUNDLE. This usage may respective RTP session being grouped using BUNDLE. This usage may
contradict both the FID semantics [RFC5888] and an assumption in the contradict both the FID semantics [RFC5888] and an assumption in the
RTP retransmission specification [RFC4588]. RTP retransmission specification [RFC4588].
7.2. Generic FEC 7.2. Generic FEC
TBW: The RTP Payload Format for Generic Forward Error Correction
[RFC5109], and also its predecessor [RFC2733], requires some
considerations, and they are different depending on what type of
configuration of usage one has.
Independent RTP Sessions, i.e. where source and repair data are sent
in different RTP sessions. As this mode of configuration requires
different RTP session, there must be at least one RTP session for
source data, this session can be one using multiple media types. The
repair session only needs one RTP Payload type indicating repair
data, i.e. x/ulpfec or x/parityfec depending if RFC 5109 or RFC 2733
is used. The media type in this session is not relevant and can in
theory be any of the defined ones. It is recommended that one uses
"Application".
In stream, using RTP Payload for Redundant Audio Data [RFC2198]
combining repair and source data in the same packets. This is
possible to use within a single RTP session. However, the usage and
configuration of the payload types can create an issue. First of all
it might be required to have one payload type per media type for the
FEC repair data payload format, i.e. one for audio/ulpfec and one for
text/ulpfec if audio and text are combined in an RTP session.
Secondly each combination of source payload and its FEC repair data
must be an explicit configured payload type. This has potential for
making the limitation of RTP payload types available into a real
issue.
8. Signalling 8. Signalling
The Signalling requirements The Signalling requirements
Establishing an RTP session with multiple media types requires Establishing an RTP session with multiple media types requires
signalling. This signalling needs to fulfill the following signalling. This signalling needs to fulfill the following
requirements: requirements:
1. Ensure that any participant in the RTP session is aware that this 1. Ensure that any participant in the RTP session is aware that this
skipping to change at page 14, line 29 skipping to change at page 17, line 15
draft-lennox-avtcore-rtp-multi-stream-00 (work in draft-lennox-avtcore-rtp-multi-stream-00 (work in
progress), July 2012. progress), July 2012.
[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
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
12.2. Informative References 12.2. Informative References
[I-D.westerlund-avtcore-multiplex-architecture] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., Perkins, C., and H. Westerlund, M., Burman, B., Perkins, C., and H.
Alvestrand, "Guidelines for using the Multiplexing Alvestrand, "Guidelines for using the Multiplexing
Features of RTP", Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-02 (work draft-westerlund-avtcore-multiplex-architecture-02 (work
in progress), July 2012. in progress), July 2012.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
skipping to change at page 15, line 8 skipping to change at page 17, line 46
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, for Generic Forward Error Correction", RFC 2733,
December 1999. December 1999.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
 End of changes. 26 change blocks. 
94 lines changed or deleted 237 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/