draft-ietf-avtcore-multi-media-rtp-session-12.txt | draft-ietf-avtcore-multi-media-rtp-session-13.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: June 12, 2016 J. Lennox | Expires: June 20, 2016 J. Lennox | |||
Vidyo | Vidyo | |||
December 10, 2015 | December 18, 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-12 | draft-ietf-avtcore-multi-media-rtp-session-13 | |||
Abstract | Abstract | |||
This document specifies how an RTP session can contain RTP Streams | This document specifies how an RTP session can contain RTP Streams | |||
with media from multiple media types such as audio, video, and text. | with media from multiple media types such as audio, video, and text. | |||
This has been restricted by the RTP Specification, and thus this | This has been restricted by the RTP Specification, and thus this | |||
document updates RFC 3550 and RFC 3551 to enable this behaviour for | document updates RFC 3550 and RFC 3551 to enable this behaviour for | |||
applications that satisfy the applicability for using multiple media | applications that satisfy the applicability for using multiple media | |||
types in a single RTP session. | types in a single RTP session. | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 12, 2016. | This Internet-Draft will expire on June 20, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 14 | 11.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol [RFC3550] was designed to use | The Real-time Transport Protocol [RFC3550] was designed to use | |||
separate RTP sessions to transport different types of media. This | separate RTP sessions to transport different types of media. This | |||
implies that different transport layer flows are used for different | implies that different transport layer flows are used for different | |||
media streams. For example, a video conferencing application might | RTP streams. For example, a video conferencing application might | |||
send audio and video traffic RTP flows on separate UDP ports. With | send audio and video traffic RTP flows on separate UDP ports. With | |||
increased use of network address/port translation, firewalls, and | increased use of network address/port translation, firewalls, and | |||
other middleboxes it is, however, becoming difficult to establish | other middleboxes it is, however, becoming difficult to establish | |||
multiple transport layer flows between endpoints. Hence, there is | multiple transport layer flows between endpoints. Hence, there is | |||
pressure to reduce the number of concurrent transport flows used by | pressure to reduce the number of concurrent transport flows used by | |||
RTP applications. | RTP applications. | |||
This memo updates [RFC3550] and [RFC3551] to allow multiple media | This memo updates [RFC3550] and [RFC3551] to allow multiple media | |||
types to be sent in a single RTP session in certain cases, thereby | types to be sent in a single RTP session in certain cases, thereby | |||
reducing the number of transport layer flows that are needed. It | reducing the number of transport layer flows that are needed. It | |||
skipping to change at page 4, line 24 ¶ | skipping to change at page 4, line 24 ¶ | |||
it makes it easy to use network layer quality of service (QoS) | it makes it easy to use network layer quality of service (QoS) | |||
mechanisms to give differentiated performance for different flows. | mechanisms to give differentiated performance for different flows. | |||
However, we note that many RTP-using application don't use network | However, we note that many RTP-using application don't use network | |||
QoS features, and don't expect or desire any separation in network | QoS features, and don't expect or desire any separation in network | |||
treatment of their media packets, independent of whether they are | treatment of their media packets, independent of whether they are | |||
audio, video or text. When an application has no such desire, it | 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. | |||
Given the above issues, it might seem appropriate for RTP-based | Given the above issues, it might seem appropriate for RTP-based | |||
applications to send all their media streams bundled into one RTP | applications to send all their RTP streams bundled into one RTP | |||
session, running over a single transport layer flow. However, this | session, running over a single transport layer flow. However, this | |||
is prohibited by the RTP specification, because the design of RTP | is prohibited by the RTP specification, because the design of RTP | |||
makes certain assumptions that can be incompatible with sending | makes certain assumptions that can be incompatible with sending | |||
multiple media types in a single RTP session. Specifically, the RTP | multiple media types in a single RTP session. Specifically, the RTP | |||
control protocol (RTCP) timing rules assume that all RTP media flows | control protocol (RTCP) timing rules assume that all RTP media flows | |||
in a single RTP session have broadly similar RTCP reporting and | in a single RTP session have broadly similar RTCP reporting and | |||
feedback requirements, which can be problematic when different types | feedback requirements, which can be problematic when different types | |||
of media are multiplexed together. Various RTP extensions also make | of media are multiplexed together. Various RTP extensions also make | |||
assumptions about SSRC use and RTCP reporting that are incompatible | assumptions about SSRC use and RTCP reporting that are incompatible | |||
with sending different media types in a single RTP session. | with sending different media types in a single RTP session. | |||
skipping to change at page 4, line 47 ¶ | skipping to change at page 4, line 47 ¶ | |||
contain more than one media type in certain circumstances, and gives | contain more than one media type in certain circumstances, and gives | |||
guidance on when it is safe to send multiple media types in a single | guidance on when it is safe to send multiple media types in a single | |||
RTP session. | RTP session. | |||
4. Applicability | 4. Applicability | |||
This specification has limited applicability, and anyone intending to | This specification has limited applicability, and anyone intending to | |||
use it needs to ensure that their application and use case meets the | use it needs to ensure that their application and use case meets the | |||
following criteria: | following criteria: | |||
Equal treatment of media: The use of a single RTP session requires | Equal treatment of media: The use of a single RTP session normally | |||
similar network treatment for all types of media used within the | results in similar network treatment for all types of media used | |||
session. Applications that require significantly different | within the session. Applications that require significantly | |||
network quality of service (QoS) or RTCP configuration for | different network quality of service (QoS) or RTCP configuration | |||
different media streams are better suited by sending those media | for different RTP streams are better suited by sending those RTP | |||
streams on separate RTP session, using separate transport layer | streams in separate RTP session, using separate transport layer | |||
flows for each, since that gives greater flexibility. Further | flows for each, since that gives greater flexibility. Further | |||
guidance on how to provide differential treatment for some media | guidance on how to provide differential treatment for some media | |||
is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657]. | is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657]. | |||
Compatible RTCP Behaviour: The RTCP timing rules enforce a single | Compatible RTCP Behaviour: The RTCP timing rules enforce a single | |||
RTCP reporting interval for all participants in an RTP session. | RTCP reporting interval for all participants in an RTP session. | |||
Flows with very different media sending rate or RTCP feedback | Flows with very different media sending rate or RTCP feedback | |||
requirements cannot be multiplexed together, since this leads to | requirements cannot be multiplexed together, since this leads to | |||
either excessive or insufficient RTCP for some flows, depending on | either excessive or insufficient RTCP for some flows, depending on | |||
how the RTCP session bandwidth, and hence reporting interval, is | how the RTCP session bandwidth, and hence reporting interval, is | |||
skipping to change at page 6, line 23 ¶ | skipping to change at page 6, line 23 ¶ | |||
or media source identity name space that is common across all | or media source identity name space that is common across all | |||
interconnect parts is needed. | interconnect parts is needed. | |||
Ability to operate with limited payload type space: An RTP session | Ability to operate with limited payload type space: An RTP session | |||
has only a single 7-bit payload type space for all its payload | has only a single 7-bit payload type space for all its payload | |||
type numbers. Some applications might find this space limiting | type numbers. Some applications might find this space limiting | |||
when using different media types and RTP payload formats within a | when using different media types and RTP payload formats within a | |||
single RTP session. | single RTP session. | |||
Avoids incompatible Extensions: Some RTP and RTCP extensions rely on | Avoids incompatible Extensions: Some RTP and RTCP extensions rely on | |||
the existence of multiple RTP sessions and relate media streams | the existence of multiple RTP sessions and relate RTP streams | |||
between sessions. Others report on particular media types, and | between sessions. Others report on particular media types, and | |||
cannot be used with other media types. Applications that send | cannot be used with other media types. Applications that send | |||
multiple types of media into a single RTP session need to avoid | multiple types of media into a single RTP session need to avoid | |||
such extensions. | such extensions. | |||
5. Using Multiple Media Types in a Single RTP Session | 5. Using Multiple Media Types in a Single RTP Session | |||
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. | |||
skipping to change at page 7, line 28 ¶ | skipping to change at page 7, line 28 ¶ | |||
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 | |||
MAY be used in parallel to send multiple media types. An RTP | MAY be used in parallel to send multiple media types. An RTP | |||
source MAY change payload types within the same media type during | source MAY change payload types within the same media type during | |||
a session. See the section "Multiplexing RTP Sessions" of RFC | a session. See the section "Multiplexing RTP Sessions" of RFC | |||
3550 for additional explanation. | 3550 for additional explanation. | |||
This specifications purpose is to override that existing SHALL NOT | This specification's purpose is to override that existing SHALL NOT | |||
under certain conditions. Thus this sentence also has to be changed | under certain conditions. Thus this sentence also has to be changed | |||
to allow for multiple media type's payload types in the same session. | to allow for multiple media type's payload types in the same session. | |||
The above sentence is changed to: | The sentence containing "SHALL NOT" in the above paragraph is changed | |||
to: | ||||
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 unless [RFCXXXX] is used, | multiplexed within a single RTP session unless [RFCXXXX] is used, | |||
and the application conforms to the applicability constraints. | and the application conforms to the applicability constraints. | |||
Multiple RTP sessions MAY be used in parallel to send multiple | Multiple RTP sessions MAY be used in parallel to send multiple | |||
media types. | 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. | |||
5.2. Demultiplexing media types within an RTP session | 5.2. Demultiplexing media types within an RTP session | |||
When receiving packets from a transport layer flow, an endpoint will | When receiving packets from a transport layer flow, an endpoint will | |||
first separate the RTP and RTCP packets from the non-RTP packets, and | first separate the RTP and RTCP packets from the non-RTP packets, and | |||
pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets | pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets | |||
are then demultiplexed based on their SSRC into the different media | are then demultiplexed based on their SSRC into the different RTP | |||
streams. For each media stream, incoming RTCP packets are processed, | streams. For each RTP stream, incoming RTCP packets are processed, | |||
and the RTP payload type is used to select the appropriate media | and the RTP payload type is used to select the appropriate media | |||
decoder. This process remains the same irrespective of whether | decoder. This process remains the same irrespective of whether | |||
multiple media types are sent in a single RTP session or not. | multiple media types are sent in a single RTP session or not. | |||
It is important to note that the RTP payload type is never used to | As explained below, it is important to note that the RTP payload type | |||
distinguish media streams. The RTP packets are demultiplexed into | is never used to distinguish RTP streams. The RTP packets are | |||
media streams based on their SSRC, then the RTP payload type is used | demultiplexed into RTP streams based on their SSRC, then the RTP | |||
to select the correct media decoding pathway for each media stream. | payload type is used to select the correct media decoding pathway for | |||
each RTP stream. | ||||
5.3. Per-SSRC Media Type Restrictions | 5.3. Per-SSRC Media Type Restrictions | |||
An SSRC in an RTP session can change between media formats of the | An SSRC in an RTP session can change between media formats of the | |||
same type, subject to certain restrictions [RFC7160], but MUST NOT | same type, subject to certain restrictions [RFC7160], but MUST NOT | |||
change media type during its lifetime. For example, an SSRC can | change media type during its lifetime. For example, an SSRC can | |||
change between different audio formats, but cannot start sending | change between different audio formats, but cannot start sending | |||
audio then change to sending video. The lifetime of an SSRC ends | audio then change to sending video. The lifetime of an SSRC ends | |||
when an RTCP BYE packet for that SSRC is sent, or when it ceases | when an RTCP BYE packet for that SSRC is sent, or when it ceases | |||
transmission for long enough that it times out for the other | transmission for long enough that it times out for the other | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 9, line 49 ¶ | |||
to be associated. This can be signalled using SDP with the BUNDLE | to be associated. This can be signalled using SDP with the BUNDLE | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888] | [I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888] | |||
extensions. These SDP extensions require each "m=" line to only be | extensions. These SDP extensions require each "m=" line to only be | |||
included in a single FID group, but the RTP retransmission payload | included in a single FID group, but the RTP retransmission payload | |||
format uses FID groups to indicate the m= lines that form an original | format uses FID groups to indicate the m= lines that form an original | |||
and retransmission pair. Accordingly, when using the BUNDLE | and retransmission pair. Accordingly, when using the BUNDLE | |||
extension to allow multiple media types to be sent in a single RTP | extension to allow multiple media types to be sent in a single RTP | |||
session, each original media source (m= line) that is retransmitted | session, each original media source (m= line) that is retransmitted | |||
needs a corresponding m= line in the retransmission RTP session. In | needs a corresponding m= line in the retransmission RTP session. In | |||
case there are multiple media lines for retransmission, these media | case there are multiple media lines for retransmission, these media | |||
lines will form a independent BUNDLE group from the BUNDLE group with | lines will form an independent BUNDLE group from the BUNDLE group | |||
the source streams. | with the source streams. | |||
An example SDP fragment showing the grouping structures is provided | An example SDP fragment showing the grouping structures is provided | |||
in Figure 1. This example is not legal SDP and only the most | in Figure 1. This example is not legal SDP and only the most | |||
important attributes have been left in place. Note that this SDP is | important attributes have been left in place. Note that this SDP is | |||
not an initial BUNDLE offer. As can be seen there are two bundle | not an initial BUNDLE offer. As can be seen there are two bundle | |||
groups, one for the source RTP session and one for the | groups, one for the source RTP session and one for the | |||
retransmissions. Then each of the media sources are grouped with its | retransmissions. Then each of the media sources are grouped with its | |||
retransmission flow using FID, resulting in three more groupings. | retransmission flow using FID, resulting in three more groupings. | |||
a=group:BUNDLE foo bar fiz | a=group:BUNDLE foo bar fiz | |||
skipping to change at page 11, line 9 ¶ | skipping to change at page 11, line 9 ¶ | |||
When sending FEC as a separate stream, the RTP Payload Format for | When sending FEC as a separate stream, the RTP Payload Format for | |||
generic FEC requires that FEC stream to be sent in a separate RTP | generic FEC requires that FEC stream to be sent in a separate RTP | |||
session to the original stream, using the same SSRC, with the FEC | session to the original stream, using the same SSRC, with the FEC | |||
stream being associated by matching the SSRC between sessions. The | stream being associated by matching the SSRC between sessions. The | |||
RTP session used for the original streams can include multiple RTP | RTP session used for the original streams can include multiple RTP | |||
streams, and those RTP streams can use multiple media types. The | streams, and those RTP streams can use multiple media types. The | |||
repair session only needs one RTP Payload type to indicate FEC data, | repair session only needs one RTP Payload type to indicate FEC data, | |||
irrespective of the number of FEC streams sent, since the SSRC is | irrespective of the number of FEC streams sent, since the SSRC is | |||
used to associate the FEC streams with the original streams. Hence, | used to associate the FEC streams with the original streams. Hence, | |||
it is RECOMMENDED that FEC stream use the "application/ulpfec" media | it is RECOMMENDED that the FEC stream use the "application/ulpfec" | |||
type for [RFC5109], and the "application/parityfec" media type for | media type for [RFC5109], and the "application/parityfec" media type | |||
[RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams | for [RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams | |||
using media specific payload format names (e.g., if an original RTP | using media specific payload format names (e.g., using both the | |||
session contains audio and video flows, for the associated FEC RTP | "audio/ulpfec" and "video/ulpfec" payload formats for a single RTP | |||
session where to use the "audio/ulpfec" and "video/ulpfec" payload | session containing both audio and video flows), since this | |||
formats), since this unnecessarily uses up RTP payload type values, | unnecessarily uses up RTP payload type values, and adds no value for | |||
and adds no value for demultiplexing since there might be multiple | demultiplexing since there might be multiple streams of the same | |||
streams of the same media type). | media type). | |||
The combination of an original RTP session using multiple media types | The combination of an original RTP session using multiple media types | |||
with a associated generic FEC session can be signalled using SDP with | with an associated generic FEC session can be signalled using SDP | |||
the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In | with the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. | |||
this case, the RTP session carrying the FEC streams will be its own | In this case, the RTP session carrying the FEC streams will be its | |||
BUNDLE group. The m= line for each original stream and the m= line | own BUNDLE group. The m= line for each original stream and the m= | |||
for the corresponding FEC stream are grouped using the SDP grouping | line for the corresponding FEC stream are grouped using the SDP | |||
framework using either the FEC-FR [RFC5956] grouping or, for | grouping framework using either the FEC-FR [RFC5956] grouping or, for | |||
backwards compatibility, the FEC [RFC4756] grouping. This is similar | backwards compatibility, the FEC [RFC4756] grouping. This is similar | |||
to the situation that arises for RTP retransmission with session | to the situation that arises for RTP retransmission with session | |||
multiplexing discussed in Section 6.1. | multiplexing discussed in Section 6.1. | |||
The Source-Specific Media Attributes [RFC5576] specification defines | The Source-Specific Media Attributes [RFC5576] specification defines | |||
an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) | an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) | |||
to signal FEC relationships between multiple RTP streams within a | to signal FEC relationships between multiple RTP streams within a | |||
single RTP session. This cannot be used with generic FEC, since the | single RTP session. This cannot be used with generic FEC, since the | |||
FEC repair packets need to have the same SSRC value as the source | FEC repair packets need to have the same SSRC value as the source | |||
packets being protected. There is ongoing work on an ULP extension | packets being protected. There was work on an Unequal Layer | |||
to allow it be use FEC RTP streams within the same RTP Session as the | Protection (ULP) extension to allow it be use FEC RTP streams within | |||
source stream [I-D.lennox-payload-ulp-ssrc-mux]. | the same RTP Session as the source stream | |||
[I-D.lennox-payload-ulp-ssrc-mux]. | ||||
When the FEC is sent as a redundant encoding, the considerations in | When the FEC is sent as a redundant encoding, the considerations in | |||
Section 6.3 apply. | Section 6.3 apply. | |||
6.3. RTP Payload Format for Redundant Audio | 6.3. RTP Payload Format for Redundant Audio | |||
The RTP Payload Format for Redundant Audio [RFC2198] can be used to | The RTP Payload Format for Redundant Audio [RFC2198] can be used to | |||
protect audio streams. It can also be used along with the generic | protect audio streams. It can also be used along with the generic | |||
FEC payload format to send original and repair data in the same RTP | FEC payload format to send original and repair data in the same RTP | |||
packets. Both are compatible with RTP sessions containing multiple | packets. Both are compatible with RTP sessions containing multiple | |||
media types. | media types. | |||
This payload format requires each different redundant encoding use a | This payload format requires each different redundant encoding use a | |||
different RTP payload type number. When used with generic FEC in | different RTP payload type number. When used with generic FEC in | |||
sessions that contain multiple media types, this requires each media | sessions that contain multiple media types, this requires each media | |||
type use a different payload type for the FEC stream. For example, | type to use a different payload type for the FEC stream. For | |||
if audio and text are sent in a single RTP session with generic ULP | example, if audio and text are sent in a single RTP session with | |||
FEC sent as a redundant encoding for each, then payload types need to | generic ULP FEC sent as a redundant encoding for each, then payload | |||
be assigned for FEC using the audio/ulpfec and text/ulpfec payload | types need to be assigned for FEC using the audio/ulpfec and text/ | |||
formats. If multiple original payload types are used in the session, | ulpfec payload formats. If multiple original payload types are used | |||
different redundant payload types need to be allocated for each one. | in the session, different redundant payload types need to be | |||
This has potential to rapidly exhaust the available RTP payload type | allocated for each one. This has potential to rapidly exhaust the | |||
numbers. | available RTP payload type numbers. | |||
7. Signalling | 7. Signalling | |||
Establishing a single RTP session using multiple media types requires | Establishing a single RTP session using multiple media types requires | |||
signalling. This signalling has to: | signalling. This signalling has to: | |||
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 | |||
is an RTP session with multiple media types; | is an RTP session with multiple media types; | |||
2. ensure that the payload types in use in the RTP session are using | 2. ensure that the payload types in use in the RTP session are using | |||
skipping to change at page 13, line 14 ¶ | skipping to change at page 13, line 15 ¶ | |||
different requirements. This can have significant costs in terms of | different requirements. This can have significant costs in terms of | |||
resource usage, session set-up time, etc. | resource usage, session set-up time, etc. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This memo makes no request of IANA. | This memo makes no request of IANA. | |||
10. Acknowledgements | 10. Acknowledgements | |||
The authors would like to thank Christer Holmberg, Gunnar Hellstroem, | The authors would like to thank Christer Holmberg, Gunnar Hellstroem, | |||
Charles Eckel, Tolga Asveren, and Warren Kumari for their feedback on | Charles Eckel, Tolga Asveren, Warren Kumari, and Meral Shirazipour | |||
the document. | for their feedback on the document. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-avtcore-rtp-multi-stream] | [I-D.ietf-avtcore-rtp-multi-stream] | |||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | |||
"Sending Multiple Media Streams in a Single RTP Session", | "Sending Multiple RTP Streams in a Single RTP Session", | |||
draft-ietf-avtcore-rtp-multi-stream-10 (work in progress), | draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), | |||
November 2015. | December 2015. | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-23 (work in progress), July 2015. | negotiation-23 (work in progress), July 2015. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
End of changes. 19 change blocks. | ||||
55 lines changed or deleted | 58 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/ |