draft-ietf-avtcore-multi-media-rtp-session-11.txt   draft-ietf-avtcore-multi-media-rtp-session-12.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: May 15, 2016 J. Lennox Expires: June 12, 2016 J. Lennox
Vidyo Vidyo
November 12, 2015 December 10, 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-11 draft-ietf-avtcore-multi-media-rtp-session-12
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 May 15, 2016. This Internet-Draft will expire on June 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Using Multiple Media Types in a Single RTP Session . . . . . 6 5. Using Multiple Media Types in a Single RTP Session . . . . . 6
5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6
5.2. Demultiplexing media types within an RTP session . . . . 7 5.2. Demultiplexing media types within an RTP session . . . . 7
5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8
5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
6. Extension Considerations . . . . . . . . . . . . . . . . . . 9 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9
6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9
6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10
6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11
7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 51 skipping to change at page 2, line 51
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
makes no changes to RTP behaviour when using multiple RTP streams makes no changes to RTP behaviour when using multiple RTP streams
containing media of the same type (e.g., multiple audio streams or containing media of the same type (e.g., multiple audio streams or
multiple video streams) in a single RTP session, however multiple video streams) in a single RTP session. However
[I-D.ietf-avtcore-rtp-multi-stream] provides important clarifications [I-D.ietf-avtcore-rtp-multi-stream] provides important clarifications
to RTP behaviour in that case. to RTP behaviour in that case.
This memo is structured as follows. Section 2 defines terminology. This memo is structured as follows. Section 2 defines terminology.
Section 3 further describes the background to, and motivation for, Section 3 further describes the background to, and motivation for,
this memo and Section 4 describes the scenarios where this memo is this memo and Section 4 describes the scenarios where this memo is
applicable. Section 5 discusses issues arising from the base RTP and applicable. Section 5 discusses issues arising from the base RTP and
RTCP specification when using multiple types of media in a single RTP RTCP specification when using multiple types of media in a single RTP
session, while Section 6 considers the impact of RTP extensions. We session, while Section 6 considers the impact of RTP extensions. We
discuss signalling in Section 7. Finally, security considerations discuss signalling in Section 7. Finally, security considerations
are discussed in Section 8. are discussed in Section 8.
2. Terminology 2. Terminology
The terms Encoded Stream, Endpoint, Media Source, RTP Session, and The terms Encoded Stream, Endpoint, Media Source, RTP Session, and
RTP Stream are used as defined in RTP Stream are used as defined in [RFC7656]. We also define the
[I-D.ietf-avtext-rtp-grouping-taxonomy]. We also define the
following terms: following terms:
Media Type: The general type of media data used by a real-time Media Type: The general type of media data used by a real-time
application. The media type corresponds to the value used in the application. The media type corresponds to the value used in the
<media> field of an SDP m= line. The media types defined at the <media> field of an SDP m= line. The media types defined at the
time of this writing are "audio", "video", "text", "image", time of this writing are "audio", "video", "text", "image",
"application", and "message". [RFC4566] [RFC6466] "application", and "message". [RFC4566] [RFC6466]
Quality of Service (QoS): Network mechanisms that are intended to Quality of Service (QoS): Network mechanisms that are intended to
ensure that the packets within a flow or with a specific marking ensure that the packets within a flow or with a specific marking
skipping to change at page 5, line 10 skipping to change at page 5, line 6
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 requires
similar network treatment for all types of media used within the similar network treatment for all types of media used within the
session. Applications that require significantly different session. Applications that require significantly different
network quality of service (QoS) or RTCP configuration for network quality of service (QoS) or RTCP configuration for
different media streams are better suited by sending those media different media streams are better suited by sending those media
streams on separate RTP session, using separate transport layer streams on 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 is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657].
[I-D.ietf-dart-dscp-rtp].
Compatible RTCP Behaviour: The RTCP timing rules enforce a single Compatible RTCP Behaviour: The RTCP timing rules enforce a single
RTCP reporting interval for all participants in an RTP session. RTCP reporting interval for all participants in an RTP session.
Flows with very different media sending rate or RTCP feedback Flows with very different media sending rate or RTCP feedback
requirements cannot be multiplexed together, since this leads to requirements cannot be multiplexed together, since this leads to
either excessive or insufficient RTCP for some flows, depending either excessive or insufficient RTCP for some flows, depending on
how the RTCP session bandwidth, and hence reporting interval, is how the RTCP session bandwidth, and hence reporting interval, is
configured. For example, it is likely not feasible to find a configured. For example, it is likely infeasible to find a single
single RTCP configuration that simultaneously suits both a low- RTCP configuration that simultaneously suits both a low-rate audio
rate audio flow with no feedback and a high-quality video flow flow with no feedback, and a high-quality video flow with
with sophisticated RTCP-based feedback needs, making it difficult sophisticated RTCP-based feedback. Thus, combining these into a
to combine these into a single RTP session. single RTP session is difficult and/or inadvisable.
Signalled Support: The extensions defined in this memo are not Signalled Support: The extensions defined in this memo are not
compatible with unmodified [RFC3550]-compatible endpoints. Their compatible with unmodified [RFC3550]-compatible endpoints. Their
use requires signalling and mutual agreement by all participants use requires signalling and mutual agreement by all participants
within an RTP session. This requirement can be a problem for within an RTP session. This requirement can be a problem for
signalling solutions that can't negotiate with all participants. signalling solutions that can't negotiate with all participants.
For declarative signalling solutions, mandating that the session For declarative signalling solutions, mandating that the session
is using multiple media types in one RTP session can be a way of is using multiple media types in one RTP session can be a way of
attempting to ensure that all participants in the RTP session attempting to ensure that all participants in the RTP session
follow the requirement. However, for signalling solutions that follow the requirement. However, for signalling solutions that
skipping to change at page 6, line 18 skipping to change at page 6, line 12
sessions into one also needs to be aware of all possible RTCP sessions into one also needs to be aware of all possible RTCP
packet types that might be used, so that it can remap the SSRC packet types that might be used, so that it can remap the SSRC
values in those packets. This is impossible to do without values in those packets. This is impossible to do without
restricting the set of RTCP packet types that can be used to those restricting the set of RTCP packet types that can be used to those
that are known by the middlebox. Such a middlebox might also have that are known by the middlebox. Such a middlebox might also have
difficulty due to differences in configured RTCP bandwidth and difficulty due to differences in configured RTCP bandwidth and
other parameters between the RTP sessions. other parameters between the RTP sessions.
Finally, the use of a middlebox that translates SSRC values can Finally, the use of a middlebox that translates SSRC values can
negatively impact the possibility for loop detection, as SSRC/CSRC negatively impact the possibility for loop detection, as SSRC/CSRC
can't be used to detect the loops, instead some other RTP stream can't be used to detect the loops; instead some other RTP stream
or media source identity name space that is common across all or media source identity name space that is common across all
interconnect parts are 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 media different media types and RTP payload formats are using when using different media types and RTP payload formats within a
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 media 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
skipping to change at page 7, line 34 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 violate that existing SHALL NOT This specifications 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 above sentence 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.
skipping to change at page 8, line 36 skipping to change at page 8, line 31
The main motivation is that a given SSRC has its own RTP timestamp The main motivation is that a given SSRC has its own RTP timestamp
and sequence number spaces. The same way that you can't send two and sequence number spaces. The same way that you can't send two
encoded streams of audio with the same SSRC, you can't send one encoded streams of audio with the same SSRC, you can't send one
encoded audio and one encoded video stream with the same SSRC. Each encoded audio and one encoded video stream with the same SSRC. Each
encoded stream when made into an RTP stream needs to have the sole encoded stream when made into an RTP stream needs to have the sole
control over the sequence number and timestamp space. If not, one control over the sequence number and timestamp space. If not, one
would not be able to detect packet loss for that particular encoded would not be able to detect packet loss for that particular encoded
stream. Nor can one easily determine which clock rate a particular stream. Nor can one easily determine which clock rate a particular
SSRCs timestamp will increase with. For additional arguments why RTP SSRCs timestamp will increase with. For additional arguments why RTP
payload type based multiplexing of multiple media sources doesn't payload type based multiplexing of multiple media sources doesn't
work see [I-D.ietf-avtcore-multiplex-guidelines]. work, see [I-D.ietf-avtcore-multiplex-guidelines].
Within an RTP session where multiple media types have been configured Within an RTP session where multiple media types have been configured
for use, an SSRC can only send one type of media during its lifetime for use, an SSRC can only send one type of media during its lifetime
(i.e., it can switch between different audio codecs, since those are (i.e., it can switch between different audio codecs, since those are
both the same type of media, but cannot switch between audio and both the same type of media, but cannot switch between audio and
video). Different SSRCs MUST be used for the different media video). Different SSRCs MUST be used for the different media
sources, the same way multiple media sources of the same media type sources, the same way multiple media sources of the same media type
already have to do. The payload type will inform a receiver which already have to do. The payload type will inform a receiver which
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
skipping to change at page 11, line 10 skipping to change at page 11, line 5
The RTP Payload Format for Generic Forward Error Correction (FEC) The RTP Payload Format for Generic Forward Error Correction (FEC)
[RFC5109] (and its predecessor [RFC2733]) can either send the FEC [RFC5109] (and its predecessor [RFC2733]) can either send the FEC
stream as a separate RTP stream, or it can send the FEC combined with stream as a separate RTP stream, or it can send the FEC combined with
the original RTP stream as a redundant encoding [RFC2198]. the original RTP stream as a redundant encoding [RFC2198].
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 stream 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 FEC stream use the "application/ulpfec" media
type for [RFC5109], and the "application/parityfec" media type for type for [RFC5109], and the "application/parityfec" media type for
[RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams [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., if an original RTP
session contains audio and video flows, for the associated FEC RTP session contains audio and video flows, for the associated FEC RTP
session where to use the "audio/ulpfec" and "video/ulpfec" payload session where to use the "audio/ulpfec" and "video/ulpfec" payload
formats), since this unnecessarily uses up RTP payload type values, formats), since this unnecessarily uses up RTP payload type values,
skipping to change at page 12, line 14 skipping to change at page 12, line 9
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 use a different payload type for the FEC stream. For example,
if audio and text are sent in a single RTP session with generic ULP if audio and text are sent in a single RTP session with generic ULP
FEC sent as a redundant encoding for each, then payload types need to FEC sent as a redundant encoding for each, then payload types need to
be assigned for FEC using the audio/ulpfec and text/ulpfec payload be assigned for FEC using the audio/ulpfec and text/ulpfec payload
formats. If multiple original payload types of used in the session, formats. If multiple original payload types are used in the session,
different redundant payload types need to be allocated for each one. different redundant payload types need to be allocated for each one.
This has potential to rapidly exhaust the available RTP payload type This has potential to rapidly exhaust the available RTP payload type
numbers. 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
skipping to change at page 12, line 47 skipping to change at page 12, line 42
configuring multiple code-points for the same thing. configuring multiple code-points for the same thing.
When using SDP signalling, the BUNDLE extension When using SDP signalling, the BUNDLE extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP
sessions containing multiple media types. sessions containing multiple media types.
8. Security Considerations 8. Security Considerations
RTP provides a range of strong security mechanisms that can be used RTP provides a range of strong security mechanisms that can be used
to secure sessions [RFC7201], [RFC7202]. The majority of these are to secure sessions [RFC7201], [RFC7202]. The majority of these are
independent of the type of media sent in the RTP session, however it independent of the type of media sent in the RTP session; however it
is important to check that the security mechanism chosen is is important to check that the security mechanism chosen is
compatible with all types of media sent within the session. compatible with all types of media sent within the session.
Sending multiple media types in a single RTP session will generally Sending multiple media types in a single RTP session will generally
require that all use the same security mechanism, whereas media sent require that all use the same security mechanism, whereas media sent
using different RTP sessions can be secured in different ways. When using different RTP sessions can be secured in different ways. When
different media types have different security requirements, it might different media types have different security requirements, it might
be necessary to send them using separate RTP sessions to meet those be necessary to send them using separate RTP sessions to meet those
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, and Tolga Asveren for their feedback on the document. Charles Eckel, Tolga Asveren, and Warren Kumari for their feedback on
the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-09 (work in progress), draft-ietf-avtcore-rtp-multi-stream-10 (work in progress),
September 2015. November 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,
skipping to change at page 14, line 13 skipping to change at page 14, line 13
<http://www.rfc-editor.org/info/rfc3551>. <http://www.rfc-editor.org/info/rfc3551>.
11.2. Informative References 11.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-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July
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.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, DOI 10.17487/RFC2198, September 1997,
skipping to change at page 15, line 48 skipping to change at page 15, line 34
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <http://www.rfc-editor.org/info/rfc7202>. 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>.
Authors' Addresses 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
 End of changes. 22 change blocks. 
40 lines changed or deleted 38 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/