draft-ietf-mmusic-sdp-bundle-negotiation-35.txt   draft-ietf-mmusic-sdp-bundle-negotiation-36.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: April 28, 2017 C. Jennings Expires: April 30, 2017 C. Jennings
Cisco Cisco
October 25, 2016 October 27, 2016
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-35.txt draft-ietf-mmusic-sdp-bundle-negotiation-36.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, specified by multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 28, 2017. This Internet-Draft will expire on April 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 3, line 27 skipping to change at page 3, line 27
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 24 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 25
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 26 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 26
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 27 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 27
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 27 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 27
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 13.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 28 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 28
skipping to change at page 4, line 17 skipping to change at page 4, line 17
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 36 Group . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38
17.5. Example: Offerer Disables A Media Description Within A 17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 40 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 40
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
20.1. Normative References . . . . . . . . . . . . . . . . . . 50 20.1. Normative References . . . . . . . . . . . . . . . . . . 50
20.2. Informative References . . . . . . . . . . . . . . . . . 51 20.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Design Considerations . . . . . . . . . . . . . . . 52 Appendix A. Design Considerations . . . . . . . . . . . . . . . 52
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 53 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 53
A.2. Usage of port number value zero . . . . . . . . . . . . . 54 A.2. Usage of port number value zero . . . . . . . . . . . . . 54
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 54 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 55
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 55 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 55
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 55 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 55
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 56 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
When multimedia communications are established, each 5-tuple reserved When multimedia communications are established, each 5-tuple reserved
for an individual media stream consume additional resources for an individual media stream consume additional resources
(especially when Interactive Connectivity Establishment (ICE) (especially when Interactive Connectivity Establishment (ICE)
skipping to change at page 5, line 30 skipping to change at page 5, line 30
an explicit grouping mechanism needs to be used to express the an explicit grouping mechanism needs to be used to express the
intended semantics. This specification provides such an extension. intended semantics. This specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the "m=" line in the value to an "m=" line in an SDP answer, even if the "m=" line in the
associated SDP offer contained a zero port value. associated SDP offer contained a zero port value.
This specification also defines a new Real-time Transport Protocol This specification also defines a new Real-time Transport Protocol
(RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP
SDES header extension that can be used to carry a value that SDES header extension that can be used to associate RTP streams with
associates RTP/RTCP packets with a specific media description. This media descriptions.
can be used to correlate a RTP packet with the correct media.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. The address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given procedures in this specification apply independently to a given
BUNDLE group. All RTP based media flows described by a single BUNDLE BUNDLE group. All RTP based media flows described by a single BUNDLE
group belong to a single RTP session [RFC3550]. group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to without an SDP 'group:BUNDLE' attribute, and are expected to
skipping to change at page 19, line 30 skipping to change at page 19, line 30
[RFC5764] does not describe how to identify different protocols [RFC5764] does not describe how to identify different protocols
transported on DTLS, only how to identify the DTLS protocol itself. transported on DTLS, only how to identify the DTLS protocol itself.
If multiple protocols are transported on DTLS, there MUST exist a If multiple protocols are transported on DTLS, there MUST exist a
specification describing a mechanism for identifying each individual specification describing a mechanism for identifying each individual
protocol. In addition, if a received DTLS packet can be associated protocol. In addition, if a received DTLS packet can be associated
with more than one "m=" line, there MUST exist a specification which with more than one "m=" line, there MUST exist a specification which
describes a mechanism for associating the received DTLS packet with describes a mechanism for associating the received DTLS packet with
the correct "m=" line. the correct "m=" line.
[Section 10.2] describes how to associate a received (S)RTP packet [Section 10.2] describes how to associate the packets in a received
with the correct "m=" line. SRTP stream with the correct "m=" line.
10. RTP Considerations 10. RTP Considerations
10.1. Single RTP Session 10.1. Single RTP Session
All RTP-based media within a single BUNDLE group belong to a single All RTP-based media within a single BUNDLE group belong to a single
RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP RTP session [RFC3550].
sessions, one per BUNDLE group.
Since a single RTP session is used for each bundle group, all "m=" Since a single RTP session is used for each bundle group, all "m="
lines representing RTP-based media in a bundle group will share a lines representing RTP-based media in a bundle group will share a
single SSRC numbering space [RFC3550]. single SSRC numbering space [RFC3550].
The following rules and restrictions apply for a single RTP session: The following rules and restrictions apply for a single RTP session:
o A specific payload type value can be used in multiple bundled "m=" o A specific payload type value can be used in multiple bundled "m="
lines only if each codec associated with the payload type number lines only if each codec associated with the payload type number
shares an identical codec configuration [Section 10.1.1]. shares an identical codec configuration [Section 10.1.1].
skipping to change at page 20, line 43 skipping to change at page 20, line 40
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values must be identical for all codecs that use the same
payload type value. payload type value.
10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description
As described in [RFC3550], RTP/RTCP packets are associated with RTP As described in [RFC3550], RTP/RTCP packets are associated with RTP
streams. Each RTP stream is identified by an SSRC value, and each streams [RFC7656]. Each RTP stream is identified by an SSRC value,
RTP/RTCP packet carries an SSRC value that is used to associate the and each RTP/RTCP packet carries an SSRC value that is used to
packet with the correct RTP stream (an RTCP packet can carry multiple associate the packet with the correct RTP stream (an RTCP packet can
SSRC values, and might therefore be associated with multiple RTP carry multiple SSRC values, and might therefore be associated with
streams). multiple RTP streams).
In order to be able to process received RTP/RTCP packets correctly it In order to be able to process received RTP/RTCP packets correctly it
must be possible to associate an RTP stream with the correct "m=" must be possible to associate an RTP stream with the correct "m="
line, as the "m=" line and SDP attributes associated with the "m=" line, as the "m=" line and SDP attributes associated with the "m="
line contain information needed to process the packets. line contain information needed to process the packets.
As all RTP streams associated with a BUNDLE group are using the same As all RTP streams associated with a BUNDLE group are using the same
address:port combination for sending and receiving RTP/RTCP packets, address:port combination for sending and receiving RTP/RTCP packets,
the local address:port combination cannot be used to associate an RTP the local address:port combination cannot be used to associate an RTP
stream with the correct "m=" line. In addition, multiple RTP streams stream with the correct "m=" line. In addition, multiple RTP streams
skipping to change at page 21, line 34 skipping to change at page 21, line 31
SSRC values mid-session, without informing each other using the SDP SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute. 'ssrc' attribute.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" line, the offerer and answerer an RTP stream with the correct "m=" line, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 14, where the offerer and answerer insert the identification- Section 14, where the offerer and answerer insert the identification-
tag (provided by the remote peer) associated with an "m=" line in RTP tag (provided by the remote peer) associated with an "m=" line in RTP
and RTCP packets associated with a BUNDLE group. and RTCP packets associated with a BUNDLE group.
Once an offerer or answerer recieve an RTP/RTCP packet carrying an The mapping from an SSRC to an identification-tag is carried in RTCP
identification-tag and an SSRC value (an RTCP packet might carry SDES packets or in RTP header extensions (Section 14). Since a
multiple identification-tags and SSRC values), it creates a mapping compound RTCP packet can contain multiple RTCP SDES packets, and each
between the SSRC value and the identification-tag, in order to RTCP SDES packet can contain multiple chunks, an RTCP packet can
associate the RTP stream with the "m=" line associated with the contain several SSRC to identification-tag mappings. The offerer and
identification-tag. Note that the mapping might change mid-session answerer maintain tables mapping RTP streams identified by SSRC, to
if, for a given SSRC value, a different identification-tag is a€œm=a€œ lines identified by the identification-
provided in an RTP/RTCP packet. tag. These tables are updated each time an RTP/RTCP packet
containing one or more mappings from SSRC to identification-tag is
received. Note that the mapping from SSRC to identification-tag can
change at any time during an RTP session. Once an offerer or
answerer recieve an RTP/RTCP packet carrying an identification-tag
and an SSRC value (an RTCP packet might carry multiple
identification-tags and SSRC values), it creates a mapping between
the SSRC value and the identification-tag, in order to associate the
RTP stream with the "m=" line associated with the identification-tag.
Note that the mapping might change mid-session if, for a given SSRC
value, a different identification-tag is provided in an RTP/RTCP
packet.
If an offerer and answerer is not able to associate an RTP stream If an offerer and answerer is not able to associate an RTP stream
with an "m=" line (using the mechanisms described in this section, or with an "m=" line (using the mechanisms described in this section, or
using other appropriate mechanism, e.g, based on the payload type using other appropriate mechanism, e.g, based on the payload type
value if it is unique to a single a€œm=a€ line), value if it is unique to a single "m=" line), it MUST either drop the
it MUST either drop the RTP/RTCP packets associated with the RTP RTP/RTCP packets associated with the RTP stream, or process them in
stream, or process them in an application specific manner, once non- an application specific manner, once non-stream specific processing
stream specific processing (e.g., related to congestion control) of (e.g., related to congestion control) of the packets have occurred.
the packets have occurred. Note that RTCP packets might be Note that RTCP packets can report on multiple RTP streams.
associated with multiple RTP streams.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based media specified by the multiplexing [RFC5761] for the RTP-based media specified by the
BUNDLE group. BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for sending all RTP packets and the RTCP combination will be used for sending all RTP packets and the RTCP
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
skipping to change at page 29, line 18 skipping to change at page 29, line 18
tags with "m=" lines within SDP Offers and Answers, using the tags with "m=" lines within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" line. an "m=" line.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension [RFC7941], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
The SDES item and RTP SDES header extension make it possible for a The SDES item and RTP SDES header extension make it possible for a
receiver to associate received RTCP- and RTP packets with a specific receiver to associate each RTP stream with with a specific "m=" line,
"m=" line, with which the receiver has associated an identification- with which the receiver has associated an identification-tag, even if
tag, even if those "m=" lines are part of the same RTP session. The those "m=" lines are part of the same RTP session. The RTP SDES
RTP SDES header extension also ensures that the media recipient gets header extension also ensures that the media recipient gets the
the identification-tag upon receipt of the first decodable media and identification-tag upon receipt of the first decodable media and is
is able to associate the media with the correct application. able to associate the media with the correct application.
A media recipient informs the media sender about the identification- A media recipient informs the media sender about the identification-
tag associated with an "m=" line through the use of an 'mid' tag associated with an "m=" line through the use of an 'mid'
attribute [RFC5888]. The media sender then inserts the attribute [RFC5888]. The media sender then inserts the
identification-tag in RTCP and RTP packets sent to the media identification-tag in RTCP and RTP packets sent to the media
recipient. recipient.
NOTE: This text above defines how identification-tags are carried in NOTE: This text above defines how identification-tags are carried in
SDP Offers and Answers. The usage of other signalling protocols for SDP Offers and Answers. The usage of other signalling protocols for
carrying identification-tags is not prevented, but the usage of such carrying identification-tags is not prevented, but the usage of such
skipping to change at page 31, line 20 skipping to change at page 31, line 20
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
15.2. New RTP SDES Header Extension URI 15.2. New RTP SDES Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new extension URI in the RTP SDES Compact This document defines a new extension URI in the RTP SDES Compact
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
skipping to change at page 42, line 9 skipping to change at page 42, line 9
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
19. Change Log 19. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35
o Editorial changes on RTP streaming mapping section based on
comments from Colin Perkins.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34
o RTP streams, instead of RTP packets, are associated with m- lines. o RTP streams, instead of RTP packets, are associated with m- lines.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33
o Editorial changes based on comments from Eric Rescorla and Cullen o Editorial changes based on comments from Eric Rescorla and Cullen
Jennings: Jennings:
o - Changes regarding usage of RTP/RTCP multiplexing attributes. o - Changes regarding usage of RTP/RTCP multiplexing attributes.
skipping to change at page 51, line 20 skipping to change at page 51, line 25
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>. August 2016, <http://www.rfc-editor.org/info/rfc7941>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-04 (work in progress), June 2016.
 End of changes. 17 change blocks. 
43 lines changed or deleted 62 lines changed or added

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