draft-ietf-avtcore-multi-media-rtp-session-06.txt | draft-ietf-avtcore-multi-media-rtp-session-07.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: April 11, 2015 J. Lennox | Expires: September 10, 2015 J. Lennox | |||
Vidyo | Vidyo | |||
October 08, 2014 | March 9, 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-06 | draft-ietf-avtcore-multi-media-rtp-session-07 | |||
Abstract | Abstract | |||
This document specifies how an RTP session can contain media 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. | |||
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. | |||
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 April 11, 2015. | This Internet-Draft will expire on September 10, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 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 | |||
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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Overview of Solution . . . . . . . . . . . . . . . . . . . . 5 | 4. Overview of Solution . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. Usage of the RTP session . . . . . . . . . . . . . . . . 6 | 5.1. Usage of the RTP session . . . . . . . . . . . . . . . . 6 | |||
5.2. Signalled Support . . . . . . . . . . . . . . . . . . . . 7 | 5.2. Signalled Support . . . . . . . . . . . . . . . . . . . . 6 | |||
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 . . . . . . . . . . . . . . . . 8 | |||
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 . . . . . . . . . . . . . . . 12 | 6.2. Sender Source Restrictions . . . . . . . . . . . . . . . 11 | |||
6.3. Payload Type Applicability . . . . . . . . . . . . . . . 12 | 6.3. Payload Type Applicability . . . . . . . . . . . . . . . 12 | |||
6.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 12 | 6.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. Extension Considerations . . . . . . . . . . . . . . . . . . 13 | 7. Extension Considerations . . . . . . . . . . . . . . . . . . 12 | |||
7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . 13 | 7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . 13 | |||
7.2. Generic FEC . . . . . . . . . . . . . . . . . . . . . . . 13 | 7.2. Generic FEC . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.1. SDP-Based Signalling . . . . . . . . . . . . . . . . . . 15 | 8.1. SDP-Based Signalling . . . . . . . . . . . . . . . . . . 16 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 16 | 12.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | 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 different to those deployed | close to 20 years ago, IP networks were different to those deployed | |||
at the time of this writing. The virtually ubiquitous deployment of | at the time of this writing. The virtually ubiquitous deployment of | |||
Network Address Translators (NAT) and Firewalls has since increased | Network Address Translators (NAT) and Firewalls has since increased | |||
the cost and likely-hood of communication failure when using many | the cost and likely-hood of communication failure when using many | |||
different transport flows. Hence, there is pressure to reduce the | different transport flows. Hence, there is pressure to reduce the | |||
number of concurrent transport flows used by RTP applications. | number of concurrent transport flows used by RTP applications. | |||
skipping to change at page 3, line 22 ¶ | skipping to change at page 3, line 22 ¶ | |||
sessions, and has enforced this rule by not allowing multiple media | sessions, and has enforced this rule by not allowing multiple media | |||
types for a given destination or set of ICE candidates. | types for a given destination or set of ICE candidates. | |||
The fact that these limitations have been in place for so long, in | The fact that these limitations have been in place for so long, in | |||
addition to RFC 3550 being written without fully considering the use | addition to RFC 3550 being written without fully considering the use | |||
of multiple media types in an RTP session, results in a number of | of multiple media types in an RTP session, results in a number of | |||
issues when allowing this behaviour. This memo updates [RFC3550] and | issues when allowing this behaviour. This memo updates [RFC3550] and | |||
[RFC3551] with important considerations regarding applicability and | [RFC3551] with important considerations regarding applicability and | |||
functionality when using multiple types of media in an RTP session, | functionality when using multiple types of media in an RTP session, | |||
including normative specification of behaviour. This memo makes no | including normative specification of behaviour. This memo makes no | |||
changes to RTP behaviour when using multiple streams of media of the | changes to RTP behaviour when using multiple RTP streams with media | |||
same type (e.g., multiple audio streams or multiple video streams) in | of the same type (e.g., multiple audio streams or multiple video | |||
a single RTP session. | streams) in a single RTP session. Instead it relies on the | |||
clarifications in [I-D.ietf-avtcore-rtp-multi-stream]. | ||||
This memo is structured as follows. First, some basic definitions | This memo is structured as follows. First, some basic definitions | |||
are provided. This is followed by a background that discusses the | are provided. This is followed by a background that discusses the | |||
motivation in more detail. A overview of the solution of how to | motivation in more detail. A overview of the solution of how to | |||
provide multiple media types in one RTP session is then presented. | provide multiple media types in one RTP session is then presented. | |||
Next is the formal applicability this specification have followed by | Next is the formal applicability this specification have followed by | |||
the normative specification. This is followed by a discussion how | the normative specification. This is followed by a discussion how | |||
some RTP/RTCP Extensions are expected to function in the case of | some RTP/RTCP Extensions are expected to function in the case of | |||
multiple media types in one RTP session. A specification of the | multiple media types in one RTP session. A specification of the | |||
requirements on signalling from this specification and a look how | requirements on signalling from this specification and a look how | |||
this is realized in SDP using Bundle | this is realized in SDP using Bundle | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation]. The memo ends with the | [I-D.ietf-mmusic-sdp-bundle-negotiation]. The memo ends with the | |||
security considerations. | security considerations. | |||
2. Definitions | 2. Definitions | |||
The following terms are used with supplied definitions: | Media Type: The general type of media data used by a real-time | |||
application. The media type corresponds to the value used in the | ||||
Endpoint: A single entity sending or receiving RTP packets. It can | <media> field of an SDP m= line. The media types defined at the | |||
be decomposed into several functional blocks, but as long as it | time of this writing are "audio", "video", "text", "application", | |||
behaves as a single RTP stack entity it is classified as a single | and "message". | |||
endpoint. | ||||
Media Stream: A sequence of RTP packets using a single SSRC that | ||||
together carries part or all of the content of a specific Media | ||||
Type from a specific sender source within a given RTP session. | ||||
Media Type: Audio, video, text or application whose form and meaning | ||||
are defined by a specific real-time application. | ||||
QoS: Quality of Service, i.e. network mechanisms that 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. | |||
RTP Session: As defined by [RFC3550], the endpoints belonging to the | The terms Encoded Stream, Endpoint, Media Source, RTP Session, and | |||
same RTP Session are those that share a single SSRC space. That | RTP Stream are used as defined in | |||
is, those endpoints can see an SSRC identifier transmitted by any | [I-D.ietf-avtext-rtp-grouping-taxonomy]. | |||
one of the other endpoints. An endpoint can receive an SSRC | ||||
either as SSRC or as CSRC in RTP and RTCP packets. Thus, the RTP | ||||
Session scope is decided by the endpoints' network interconnection | ||||
topology, in combination with RTP and RTCP forwarding strategies | ||||
deployed by endpoints and any interconnecting middle nodes. | ||||
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", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Motivation | 3. Motivation | |||
The existence of NATs and Firewalls at almost all Internet access has | The existence of NATs and Firewalls at almost all Internet access has | |||
had implications on protocols like RTP that were designed to use | had implications on protocols like RTP that were designed to use | |||
multiple transport flows. First of all, the NAT/FW traversal | multiple transport flows. First of all, the NAT/FW traversal | |||
skipping to change at page 6, line 6 ¶ | skipping to change at page 5, line 32 ¶ | |||
(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 | |||
media type the SSRC is being used for. Thus the payload type MUST be | media type the SSRC is being used for. Thus the payload type MUST be | |||
unique across all of the payload configurations independent of media | unique across all of the payload configurations independent of media | |||
type that is used in the RTP session. | type that is 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 (RTP | be considered. RTCP bandwidth and regular reporting suppression | |||
/AVPF and RTP/SAVPF) SHOULD be configured to reduce the impact for | (RTP/AVPF and RTP/SAVPF) SHOULD be configured to reduce the impact | |||
bit-rate variations between streams and media types. It is also | for bit-rate variations between RTP streams and media types. It is | |||
clarified how timeout calculations are to be done to avoid any | also clarified how timeout calculations are to be done to avoid any | |||
issues. Certain payload types like FEC also need additional rules. | issues. Certain 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. This memo describes | session exists, and how that then is configured. This memo describes | |||
some existing requirements, while an external reference defines how | some existing requirements, while an external reference defines how | |||
this is accomplished in SDP. | this is accomplished in SDP. | |||
5. Applicability | 5. Applicability | |||
skipping to change at page 6, line 35 ¶ | skipping to change at page 6, line 16 ¶ | |||
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.ietf-avtcore-multiplex-guidelines] gives more | Features of RTP [I-D.ietf-avtcore-multiplex-guidelines] gives more | |||
detailed guidance on aspects to consider when choosing how to use RTP | detailed guidance on aspects to consider when choosing how to use RTP | |||
and specifically sessions. RTP-using applications that need or would | and specifically sessions. | |||
prefer multiple RTP sessions, but do not require the functionalities | ||||
or behaviours that multiple transport flows give, can consider using | There is some work in progress | |||
Multiple RTP Sessions on a Single Lower-Layer Transport | [I-D.westerlund-avtcore-transport-multiplexing] that attempt to | |||
[I-D.westerlund-avtcore-transport-multiplexing]. | address a solution for RTP-using applications that need or would | |||
prefer multiple RTP sessions, but do not require the | ||||
functionalities or behaviours that multiple transport flows give. | ||||
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 RTCP requirements. There are limitations in the RTCP timing | similar RTCP requirements. There are limitations in the RTCP timing | |||
rules, and this implies a common RTCP reporting interval across all | rules, 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 RTCP requirements, for example due to media streams | very different RTCP requirements, for example due to RTP Streams | |||
bandwidth consumption and packet rate, for example low-rate audio | bandwidth consumption and packet rate, for example low-rate audio | |||
coupled with high-quality video, this can result in either excessive | coupled with high-quality video, this can result in either excessive | |||
or insufficient RTCP for some flows, depending how the RTCP session | or 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 | |||
discussed further in Section 6.4. | 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 | |||
skipping to change at page 7, line 27 ¶ | skipping to change at page 7, line 10 ¶ | |||
in one RTP session can be a way of attempting to ensure that all | in one RTP session can be a way of attempting to ensure that all | |||
participants in the RTP session follow the requirement. However, for | participants in the RTP session follow the requirement. However, for | |||
signalling solutions that lack methods for enforcing that a receiver | signalling solutions that lack methods for enforcing that a receiver | |||
supports a specific feature, this can still cause issues. | supports a specific feature, this can still cause issues. | |||
5.3. Homogeneous Multi-party | 5.3. Homogeneous Multi-party | |||
In multiparty communication scenarios it is important to separate two | In multiparty communication scenarios it is important to separate two | |||
different cases. One case is where the RTP session contains multiple | different cases. One case is where the RTP session contains multiple | |||
participants in a common RTP session. This occurs for example in Any | participants in a common RTP session. This occurs for example in Any | |||
Source Multicast (ASM) and Transport Translator topologies as defined | Source Multicast (ASM) and Relay (Transport Translator) topologies as | |||
in RTP Topologies [RFC5117]. It can also occur in some | defined in RTP Topologies [I-D.ietf-avtcore-rtp-topologies-update]. | |||
implementations of RTP mixers that share the same SSRC/CSRC space | It can also occur in some implementations of RTP mixers that share | |||
across all participants. The second case is when the RTP session is | the same SSRC/CSRC space across all participants. The second case is | |||
terminated in a middlebox and the other participants sources are | when the RTP session is terminated in a middlebox and the other | |||
projected or switched into each RTP session and rewritten on RTP | participants sources are projected or switched into each RTP session | |||
header level including SSRC mappings. | and rewritten on RTP header level including SSRC mappings. | |||
For the first case, with a common RTP session or at least shared SSRC | For the first case, with a common RTP session or at least shared | |||
/CSRC values, all participants in multiparty communication are | SSRC/CSRC values, all participants in multiparty communication are | |||
REQUIRED to support multiple media types in an RTP session. An | REQUIRED to support multiple media types in an RTP session. An | |||
participant using two or more RTP sessions towards a multiparty | participant using two or more RTP sessions towards a multiparty | |||
session can't be collapsed into a single session with multiple media | session can't be collapsed into a single session with multiple media | |||
types. The reason is that in case of multiple RTP sessions, the same | types. The reason is that in case of multiple RTP sessions, the same | |||
SSRC value can be use in both RTP sessions without any issues, but | SSRC value can be use in both RTP sessions without any issues, but | |||
when collapsed to a single session there is an SSRC collision. In | when collapsed to a single session there is an SSRC collision. In | |||
addition some collisions can't be represented in the multiple | addition some collisions can't be represented in the multiple | |||
separate RTP sessions. For example, in a session with audio and | separate RTP sessions. For example, in a session with audio and | |||
video, an SSRC value used for video will not show up in the Audio RTP | video, an SSRC value used for video will not show up in the Audio RTP | |||
session at the participant using multiple RTP sessions, and thus not | session at the participant using multiple RTP sessions, and thus not | |||
skipping to change at page 8, line 18 ¶ | skipping to change at page 7, line 48 ¶ | |||
willing to remap the SSRCs used by a participant with multiple RTP | willing to remap the SSRCs used by a participant with multiple RTP | |||
sessions into non-used values in the single RTP session SSRC space | sessions into non-used values in the single RTP session SSRC space | |||
for each of the participants using a single RTP session with multiple | for each of the participants using a single RTP session with multiple | |||
media types. It can be noted that this type of implementation has to | media types. It can be noted that this type of implementation has to | |||
understand all types of RTP/RTCP extension being used in the RTP | understand all types of RTP/RTCP extension being used in the RTP | |||
sessions to correctly be able to translate them between the RTP | sessions to correctly be able to translate them between the RTP | |||
sessions. It might also suffer issues due to differencies in | sessions. It might also suffer issues due to differencies in | |||
configured RTCP bandwidth and other parameters between the RTP | configured RTCP bandwidth and other parameters between the RTP | |||
sessions. It can also negatively impact the possibility for loop | sessions. It can also negatively impact the possibility for loop | |||
detection, as SSRC/CSRC can't be used to detect the loops, instead | detection, as SSRC/CSRC can't be used to detect the loops, instead | |||
some other media stream identity name space that is common across all | some other RTP stream or media source identity name space that is | |||
interconnect parts are needed. | common across all interconnect parts are needed. | |||
5.4. Reduced number of Payload Types | 5.4. Reduced number of Payload Types | |||
An RTP session with multiple media types in it have only a single | An RTP session with multiple media types in it have only a single | |||
7-bit Payload Type range for all its payload types. Within the 128 | 7-bit Payload Type range for all its payload types. Within the 128 | |||
available values, only 96 or less if "Multiplexing RTP Data and | available values, only 96 or less if "Multiplexing RTP Data and | |||
Control Packets on a Single Port" [RFC5761] is used, all the | Control Packets on a Single Port" [RFC5761] is used, all the | |||
different RTP payload configurations for all the media types need to | different RTP payload configurations for all the media types need to | |||
fit in the available space. For most applications this will not be a | fit in the available space. For most applications this will not be a | |||
real problem, but the limitation exists and could be encountered. | real problem, but the limitation exists and could be encountered. | |||
5.5. Stream Differentiation | 5.5. Stream Differentiation | |||
If network level differentiation of the media streams of different | If network level differentiation of the RTP streams with different | |||
media types are desired using this specification can cause severe | media types is desired, using this specification can cause severe | |||
limitations. All media streams in an RTP session, independent of the | limitations. All RTP streams in an RTP session, independent of the | |||
media type, will be sent over the same underlying transport flow. | media type, will be sent over the same underlying transport flow. | |||
Any flow-based Quality of Service (QoS) mechanism will be unable to | Any flow-based Quality of Service (QoS) mechanism will be unable to | |||
provide differentiated treatment between different media types, e.g. | provide differentiated treatment between different media types, e.g. | |||
to prioritize audio over video. If differentiated treatment is | to prioritize audio over video. If differentiated treatment is | |||
desired using flow-based QoS, separate RTP sessions over different | desired using flow-based QoS, separate RTP sessions over different | |||
underlying transport flows needs to be used. | underlying transport flows needs to be used. | |||
Marking-based QoS scheme like DiffServ can be affected if network | Marking-based QoS schemes like DiffServ can be affected if a network | |||
ingress is the one that performs markings based on flows. Endpoint | ingress is the one that performs, markings based on flows. Endpoint | |||
marking where the network API supports marking on individual packet | marking where the network API supports marking on individual packet | |||
level will be unaffected by this specification. However, there exist | level will be unaffected by this specification. However, there exist | |||
limitations as discussed in [I-D.ietf-avtcore-multiplex-guidelines] | limitations, as discussed in [I-D.ietf-dart-dscp-rtp], on how | |||
exist for how different traffic classes can be applied on a single | different traffic classes can be applied on different packets or RTP | |||
RTP media stream. | streams within a single transport flow. | |||
5.6. Non-compatible Extensions | 5.6. Non-compatible Extensions | |||
There exist some RTP and RTCP extensions that rely on the existence | There exist some RTP and RTCP extensions that rely on the existence | |||
of multiple RTP sessions. If the goal of using an RTP session with | of multiple RTP sessions. If the goal of using an RTP session with | |||
multiple media types is to have only a single RTP session, then these | multiple media types is to have only a single RTP session, then these | |||
extensions can't be used. If one has no need to have different RTP | extensions can't be used. If one has no need to have different RTP | |||
sessions for the media types but is willing to have multiple RTP | sessions for the media types but is willing to have multiple RTP | |||
sessions, one for the main media transmission and one for the | sessions, one for the main media transmission and one for the | |||
extension, they can be used. It is to be noted that this assumes | extension, they can be used. It is to be noted that this assumes | |||
that it is possible to get the extension working when the related RTP | that it is possible to get the extension working when the related RTP | |||
session contains multiple media types. | session contains multiple media types. | |||
skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 17 ¶ | |||
XOR-Based FEC: The RTP Payload Format for Generic Forward Error | XOR-Based FEC: The RTP Payload Format for Generic Forward Error | |||
Correction [RFC5109] and its predecessor [RFC2733] requires a | Correction [RFC5109] and its predecessor [RFC2733] requires a | |||
separate RTP session unless the FEC data is carried in RTP Payload | separate RTP session unless the FEC data is carried in RTP Payload | |||
for Redundant Audio Data [RFC2198]. However, using the Generic | for Redundant Audio Data [RFC2198]. However, using the Generic | |||
FEC with the Redundancy payload has another set of restrictions, | FEC with the Redundancy payload has another set of restrictions, | |||
see Section 7.2. | see Section 7.2. | |||
Note that the Source-Specific Media Attributes [RFC5576] | Note that the Source-Specific Media Attributes [RFC5576] | |||
specification defines an SDP syntax (the "FEC" semantic of the | specification defines an SDP syntax (the "FEC" semantic of the | |||
"ssrc-group" attribute) to signal FEC relationships between | "ssrc-group" attribute) to signal FEC relationships between | |||
multiple media streams within a single RTP session. However, this | multiple RTP streams within a single RTP session. However, this | |||
can't be used as the FEC repair packets need to have the same SSRC | can't be used as the FEC repair packets need to have the same SSRC | |||
value as the source packets being protected. [RFC5576] does not | value as the source packets being protected. [RFC5576] does not | |||
normatively update and resolve that restriction. There is ongoing | normatively update and resolve that restriction. There is ongoing | |||
work on an ULP extension to allow it be use FEC streams within the | work on an ULP extension to allow it be use FEC RTP streams within | |||
same RTP Session as the source stream | the same RTP Session as the source stream | |||
[I-D.lennox-payload-ulp-ssrc-mux]. | [I-D.lennox-payload-ulp-ssrc-mux]. | |||
6. RTP Session Specification | 6. RTP Session Specification | |||
This section defines what needs to be done or avoided to make an RTP | This section defines what needs to be done or avoided to make an RTP | |||
session with multiple media types function without issues. | session with multiple media types function without issues. | |||
6.1. RTP Session | 6.1. RTP Session | |||
Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" | Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" | |||
skipping to change at page 10, line 24 ¶ | skipping to change at page 10, line 7 ¶ | |||
sentence is changed to: | sentence is changed to: | |||
For example, in a teleconference composed of audio and video media | For example, in a teleconference composed of audio and video media | |||
encoded separately, each medium SHOULD be carried in a separate | encoded separately, each medium SHOULD be carried in a separate | |||
RTP session with its own destination transport address, unless | RTP session with its own destination transport address, unless | |||
specification [RFCXXXX] is followed and the application meets the | specification [RFCXXXX] is followed and the application meets the | |||
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 media sources SHOULD NOT be carried in a | |||
RTP session and demultiplexed based on the payload type or SSRC | single RTP session and demultiplexed based on the payload type or | |||
fields, unless multiplexed based on both SSRC and payload type and | SSRC fields, unless multiplexed based on both SSRC and payload | |||
usage meets what Multiple Media Types in an RTP Session [RFCXXXX] | type and usage meets what Multiple Media Types in an RTP Session | |||
specifies. | [RFCXXXX] specifies. | |||
Second paragraph of Section 6 in RTP Profile for Audio and Video | Second paragraph of Section 6 in RTP Profile for Audio and Video | |||
Conferences with Minimal Control [RFC3551] says: | Conferences with Minimal Control [RFC3551] says: | |||
The payload types currently defined in this profile are assigned | The payload types currently defined in this profile are assigned | |||
to exactly one of three categories or media types: audio only, | to exactly one of three categories or media types: audio only, | |||
video only and those combining audio and video. The media types | video only and those combining audio and video. The media types | |||
are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. | are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. | |||
Payload types of different media types SHALL NOT be interleaved or | Payload types of different media types SHALL NOT be interleaved or | |||
multiplexed within a single RTP session, but multiple RTP sessions | multiplexed within a single RTP session, but multiple RTP sessions | |||
skipping to change at page 12, line 8 ¶ | skipping to change at page 11, line 35 ¶ | |||
each SSRC will be associated with a specific media type, communicated | each SSRC will be associated with a specific media type, communicated | |||
through the RTP payload type, allowing a middlebox to do media type | through the RTP payload type, allowing a middlebox to do media type | |||
specific operations. The second argument is that in many contexts | specific operations. The second argument is that in many contexts | |||
blind combining without additional contexts are anyway not suitable. | blind combining without additional contexts are anyway not suitable. | |||
Regarding bullet 5 this is a understood and explicitly stated | Regarding bullet 5 this is a understood and explicitly stated | |||
applicability limitations for the method described in this document. | 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 | video, text etc.) during the SSRC's lifetime. The main motivation is | |||
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 encoded streams of | |||
audio on the same SSRC, you can't send one audio and one video | audio on the same SSRC, you can't send one encoded audio and one | |||
encoding on the same SSRC. Each media encoding when made into an RTP | encoded video stream on the same SSRC. Each encoded stream when made | |||
stream needs to have the sole control over the sequence number and | into an RTP stream needs to have the sole control over the sequence | |||
timestamp space. If not, one would not be able to detect packet loss | number and timestamp space. If not, one would not be able to detect | |||
for that particular stream. Nor can one easily determine which clock | packet loss for that particular encoded stream. Nor can one easily | |||
rate a particular SSRCs timestamp will increase with. For additional | determine which clock rate a particular SSRCs timestamp will increase | |||
arguments why RTP payload type based multiplexing of multiple media | with. For additional arguments why RTP payload type based | |||
streams doesn't work see Appendix A in | multiplexing of multiple media sources doesn't work see | |||
[I-D.ietf-avtcore-multiplex-guidelines]. | [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 | |||
skipping to change at page 12, line 48 ¶ | skipping to change at page 12, line 32 ¶ | |||
types. In fact this document (Section 7.2) suggest that for usage of | types. In fact this document (Section 7.2) suggest that for usage of | |||
Generic FEC (XOR-based) as defined in RFC 5109 can actually use a | Generic FEC (XOR-based) as defined in RFC 5109 can actually use a | |||
single media type when used with independent RTP sessions for source | single media type when used with independent RTP sessions for source | |||
and repair data. | and repair data. | |||
Note a particular SSRC carrying Generic FEC will clearly only | Note a particular SSRC carrying Generic FEC will clearly only | |||
protect a specific SSRC and thus that instance is bound to the | 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 | SSRC's media type. For this specific case, it is possible to have | |||
one be applicable to both. However, in cases when the signalling | one be applicable to both. However, in cases when the signalling | |||
is setup to enable fall back to using separate RTP sessions, then | is setup to enable fall back to using separate RTP sessions, then | |||
using a different media type, e.g. application, than the media | using a different media type, e.g. application, than the media | |||
being protected can create issues. | being protected can create issues. | |||
6.4. RTCP Considerations | 6.4. RTCP Considerations | |||
Guidelines for handling RTCP when sending multiple media streams with | ||||
Guidelines for handling RTCP when sending multiple RTP streams with | ||||
disparate rates in a single RTP session are outlined in | disparate rates in a single RTP session are outlined in | |||
[I-D.ietf-avtcore-rtp-multi-stream]. These guidelines apply when | [I-D.ietf-avtcore-rtp-multi-stream]. These guidelines apply when | |||
sending multiple types of media in a single RTP session if the | sending multiple types of media in a single RTP session if the | |||
different types of media have different rates. | different types of media have different rates. | |||
7. Extension Considerations | 7. Extension Considerations | |||
This section discusses the impact on some RTP/RTCP extensions due to | This section discusses the impact on some RTP/RTCP extensions due to | |||
usage of multiple media types in on RTP session. Only extensions | usage of multiple media types in on RTP session. Only extensions | |||
where something worth noting has been included. | where something worth noting has been included. | |||
7.1. RTP Retransmission | 7.1. RTP Retransmission | |||
SSRC-multiplexed RTP retransmission [RFC4588] is actually very | SSRC-multiplexed RTP retransmission [RFC4588] is actually very | |||
straightforward. Each retransmission RTP payload type is explicitly | straightforward. Each retransmission RTP payload type is explicitly | |||
connected to an associated payload type. If retransmission is only | connected to an associated payload type. If retransmission is only | |||
to be used with a subset of all payload types, this is not a problem, | to be used with a subset of all payload types, this is not a problem, | |||
as it will be evident from the retransmission payload types which | as it will be evident from the retransmission payload types which | |||
payload types that have retransmission enabled for them. | payload types have retransmission enabled for them. | |||
Session-multiplexed RTP retransmission is also possible to use where | Session-multiplexed RTP retransmission is also possible to use where | |||
an retransmission session contains the retransmissions of the | an retransmission session contains the retransmissions of the | |||
associated payload types in the source RTP session. The only | associated payload types in the source RTP session. The only | |||
difference to previously is that the source RTP session is one which | difference to the previous case is if the source RTP session is one | |||
contains multiple media types. Thus it is even more likely that only | which contains multiple media types. This results in the | |||
a subset of the source RTP session's payload types and SSRCs are | retransmission streams in the RTP session for the retransmission | |||
actually retransmitted. | having multiple associated media types. | |||
Open Issue: When using SDP to signal retransmission for one RTP | When using SDP signalling for a multiple media type RTP session, i.e. | |||
session with multiple media types and one RTP session for the | BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], the session | |||
retransmission data will cause a situation where one will have | multiplexed case do require some recommendations on how to signal | |||
multiple m= lines grouped using FID and the ones belonging to | this. To avoid breaking the semantics of the FID grouping as defined | |||
respective RTP session being grouped using BUNDLE. This usage might | by [RFC5888] each media line can only be included in one FID group. | |||
contradict both the FID semantics [RFC5888] and an assumption in the | FID is used by RTP retransmission to indicate the SDP media lines | |||
RTP retransmission specification [RFC4588]. | that is a source and retransmission pair. Thus, for SDP using | |||
BUNDLE, each original media source (m= line) that is retransmitted | ||||
needs a corresponding media line in the retransmission RTP session. | ||||
In case there are multiple media lines for retransmission, these | ||||
media lines will form a independent BUNDLE group from the BUNDLE | ||||
group with the source streams. | ||||
Below is an SDP example (Figure 1) which shows the grouping | ||||
structures. This example is not legal SDP and only the most | ||||
important attributes has been left in place. Note that this SDP is | ||||
not an initial BUNDLE offer. As can be seen there are two bundle | ||||
groups, one for the source RTP session and one for the | ||||
retransmissions. Then each of the media sources are grouped with its | ||||
retransmission flow using FID, resulting in three more groupings. | ||||
a=group:BUNDLE foo bar fiz | ||||
a=group:BUNDLE zoo kelp glo | ||||
a=group:FID foo zoo | ||||
a=group:FID bar kelp | ||||
a=group:FID fiz glo | ||||
m=audio 10000 RTP/AVP 0 | ||||
a=mid:foo | ||||
a=rtpmap:0 PCMU/8000 | ||||
m=video 10000 RTP/AVP 31 | ||||
a=mid:bar | ||||
a=rtpmap:31 H261/90000 | ||||
m=video 10000 RTP/AVP 31 | ||||
a=mid:fiz | ||||
a=rtpmap:31 H261/90000 | ||||
m=audio 40000 RTP/AVPF 99 | ||||
a=rtpmap:99 rtx/90000 | ||||
a=fmtp:99 apt=0;rtx-time=3000 | ||||
a=mid:zoo | ||||
m=video 40000 RTP/AVPF 100 | ||||
a=rtpmap:100 rtx/90000 | ||||
a=fmtp:199 apt=31;rtx-time=3000 | ||||
a=mid:kelp | ||||
m=video 40000 RTP/AVPF 100 | ||||
a=rtpmap:100 rtx/90000 | ||||
a=fmtp:199 apt=31;rtx-time=3000 | ||||
a=mid:glo | ||||
Figure 1: SDP example of Session Multiplexed RTP Retransmission | ||||
7.2. Generic FEC | 7.2. Generic FEC | |||
The RTP Payload Format for Generic Forward Error Correction | The RTP Payload Format for Generic Forward Error Correction | |||
[RFC5109], and also its predecessor [RFC2733], requires some | [RFC5109], and also its predecessor [RFC2733], requires some | |||
considerations, and they are different depending on what type of | considerations, and they are different depending on what type of | |||
configuration of usage one has. | configuration of usage one has. | |||
Independent RTP Sessions, i.e. where source and repair data are sent | Independent RTP Sessions, i.e. where source and repair data are sent | |||
in different RTP sessions. As this mode of configuration requires | in different RTP sessions. As this mode of configuration requires | |||
different RTP session, there has to be at least one RTP session for | different RTP session, there has to be at least one RTP session for | |||
source data, this session can be one using multiple media types. The | source data, this session can be one using multiple media types. The | |||
repair session only needs one RTP Payload type indicating repair | 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 | 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 | 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 | theory be any of the defined ones. It is RECOMMENDED that one uses | |||
"Application". | "Application". | |||
If one uses SDP signalling with BUNDLE | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation], then the RTP session | ||||
carrying the FEC streams will be its own BUNDLE group. The media | ||||
line with the source stream for the FEC and the FEC stream's media | ||||
line will be grouped using media line grouping using the FEC or FEC- | ||||
FR [RFC5956] grouping. This is very similar to the situation that | ||||
arise for RTP retransmission with session multiplexing discussed | ||||
above inSection 7.1. | ||||
In stream, using RTP Payload for Redundant Audio Data [RFC2198] | In stream, using RTP Payload for Redundant Audio Data [RFC2198] | |||
combining repair and source data in the same packets. This is | combining repair and source data in the same packets. This is | |||
possible to use within a single RTP session. However, the usage and | possible to use within a single RTP session. However, the usage and | |||
configuration of the payload types can create an issue. First of all | configuration of the payload types can create an issue. First of all | |||
it might be necessary to have one payload type per media type for the | it might be necessary to have one payload type per media type for the | |||
FEC repair data payload format, i.e. one for audio/ulpfec and one | FEC repair data payload format, i.e. one for audio/ulpfec and one for | |||
for text/ulpfec if audio and text are combined in an RTP session. | text/ulpfec if audio and text are combined in an RTP session. | |||
Secondly each combination of source payload and its FEC repair data | Secondly each combination of source payload and its FEC repair data | |||
has to be an explicit configured payload type. This has potential | has to be an explicit configured payload type. This has potential | |||
for making the limitation of RTP payload types available into a real | for making the limitation of RTP payload types available into a real | |||
issue. | 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 | |||
skipping to change at page 15, line 51 ¶ | skipping to change at page 16, line 51 ¶ | |||
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, | 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-05 (work in progress), | draft-ietf-avtcore-rtp-multi-stream-06 (work in progress), | |||
July 2014. | October 2014. | |||
[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-11 (work in progress), September 2014. | negotiation-17 (work in progress), March 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, 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] | [I-D.ietf-avtcore-multiplex-guidelines] | |||
Westerlund, M., Perkins, C., and H. Alvestrand, | Westerlund, M., Perkins, C., and H. Alvestrand, | |||
"Guidelines for using the Multiplexing Features of RTP to | "Guidelines for using the Multiplexing Features of RTP to | |||
Support Multiple Media Streams", draft-ietf-avtcore- | Support Multiple Media Streams", draft-ietf-avtcore- | |||
multiplex-guidelines-02 (work in progress), January 2014. | multiplex-guidelines-03 (work in progress), October 2014. | |||
[I-D.ietf-avtcore-rtp-topologies-update] | ||||
Westerlund, M. and S. Wenger, "RTP Topologies", draft- | ||||
ietf-avtcore-rtp-topologies-update-06 (work in progress), | ||||
March 2015. | ||||
[I-D.ietf-avtext-rtp-grouping-taxonomy] | ||||
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, | ||||
"A Taxonomy of Grouping Semantics and Mechanisms for Real- | ||||
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- | ||||
rtp-grouping-taxonomy-06 (work in progress), March 2015. | ||||
[I-D.ietf-dart-dscp-rtp] | ||||
Black, D. and P. Jones, "Differentiated Services | ||||
(DiffServ) and Real-time Communication", draft-ietf-dart- | ||||
dscp-rtp-10 (work in progress), November 2014. | ||||
[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-transport-multiplexing] | [I-D.westerlund-avtcore-transport-multiplexing] | |||
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP | Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP | |||
Sessions onto a Single Lower-Layer Transport", draft- | Sessions onto a Single Lower-Layer Transport", draft- | |||
skipping to change at page 17, line 12 ¶ | skipping to change at page 18, line 30 ¶ | |||
[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. | |||
[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, | ||||
January 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. | |||
Authors' Addresses | [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in | |||
the Session Description Protocol", RFC 5956, September | ||||
2010. | ||||
Authors' Addresses | ||||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Farogatan 6 | Farogatan 6 | |||
SE-164 80 Kista | SE-164 80 Kista | |||
Sweden | Sweden | |||
Phone: +46 10 714 82 87 | Phone: +46 10 714 82 87 | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
Colin Perkins | Colin Perkins | |||
End of changes. 44 change blocks. | ||||
119 lines changed or deleted | 178 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/ |