draft-ietf-mmusic-sdp-bundle-negotiation-22.txt   draft-ietf-mmusic-sdp-bundle-negotiation-23.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: December 18, 2015 C. Jennings Expires: January 21, 2016 C. Jennings
Cisco Cisco
June 16, 2015 July 20, 2015
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-22.txt draft-ietf-mmusic-sdp-bundle-negotiation-23.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, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 18, 2015. This Internet-Draft will expire on January 21, 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 3, line 23 skipping to change at page 3, line 23
Description . . . . . . . . . . . . . . . . . . . . . . 18 Description . . . . . . . . . . . . . . . . . . . . . . 18
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
13.3. New text replacing section 5.1 (2nd paragraph) of RFC 13.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
13.5. New text replacing section 8.2 (2nd paragraph) of RFC 13.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
13.7. New text replacing section 8.4 (6th paragraph) of RFC 13.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. RTP/RTCP extensions for identification-tag transport . . . . 26 14. RTP/RTCP extensions for identification-tag transport . . . . 26
14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 29 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Example: Bundle Address Selection . . . . . . . . . . . 30 17.1. Example: Bundle Address Selection . . . . . . . . . . . 31
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 33
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 33 Group . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 17.5. Example: Offerer Disables A Media Description Within A
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
20.1. Normative References . . . . . . . . . . . . . . . . . . 44 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
20.2. Informative References . . . . . . . . . . . . . . . . . 44 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Design Considerations . . . . . . . . . . . . . . . 45 20.1. Normative References . . . . . . . . . . . . . . . . . . 45
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 20.2. Informative References . . . . . . . . . . . . . . . . . 46
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46 Appendix A. Design Considerations . . . . . . . . . . . . . . . 47
A.3. Usage of port number value zero . . . . . . . . . . . . . 47 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 48 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 48
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48 A.3. Usage of port number value zero . . . . . . . . . . . . . 49
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 12, line 19 skipping to change at page 12, line 19
but the "m=" line does not contain an SDP 'bundle-only' attribute, it but the "m=" line does not contain an SDP 'bundle-only' attribute, it
is an indication that the offerer wants to disable the "m=" line is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5]. [Section 8.5.5].
8.3.2. Answerer Selection of Offerer Bundle Address 8.3.2. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) assigned to the bundled In an offer, the address (unique or shared) assigned to the bundled
"m=" line associated with the offerer BUNDLE-tag indicates the "m=" line associated with the offerer BUNDLE-tag indicates the
address that the offerer suggests as the offerer BUNDLE address address that the offerer suggests as the offerer BUNDLE address
[Section 8.2.2]. The answerer MUST check whether that "m=" line [Section 8.2.2]. The answerer MUST check whether that "m=" line
fulfills the following criteria: fulfils the following criteria:
o The answerer will not move the "m=" line out of the BUNDLE group o The answerer will not move the "m=" line out of the BUNDLE group
[Section 8.3.4]; [Section 8.3.4];
o The answerer will not reject the "m=" line [Section 8.3.5]; and o The answerer will not reject the "m=" line [Section 8.3.5]; and
o The "m=" line does not contain a zero port value. o The "m=" line does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the address associated with the "m=" line as the offerer BUNDLE the address associated with the "m=" line as the offerer BUNDLE
skipping to change at page 16, line 43 skipping to change at page 16, line 43
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
9.1. General 9.1. General
Each "m=" line within a BUNDLE group MUST use the same transport- Each "m=" line within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" lines use different protocols on top layer protocol. If bundled "m=" lines use different protocols on top
of the transport-layer protocol, there MUST exist a publicly of the transport-layer protocol, there MUST exist a publicly
available specification which describes a mechanism, for this available specification which describes a mechanism, for this
particular protocol combination, how to associate a received data particular protocol combination, how to associate received data with
with the correct protocol. the correct protocol.
In addition, if a received data can be associated with more than one In addition, if received data can be associated with more than one
bundled "m=" line, there MUST exist a publicly available bundled "m=" line, there MUST exist a publicly available
specification which describes a mechanism for associating the specification which describes a mechanism for associating the
received data with the correct "m=" line. received data with the correct "m=" line.
This document describes a mechanism to identify the protocol of This document describes a mechanism to identify the protocol of
received data among the STUN, DTLS and SRTP protocols (in any received data among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but does combination), when UDP is used as transport-layer protocol, but does
not describe how to identify different protocols transported on DTLS. not describe how to identify different protocols transported on DTLS.
While the mechanism is generally applicable to other protocols and While the mechanism is generally applicable to other protocols and
transport-layers protocols, any such use requires further transport-layers protocols, any such use requires further
skipping to change at page 19, line 13 skipping to change at page 19, line 13
(and sent) using single address:port combinations, the local (and sent) using single address:port combinations, the local
address:port combination cannot be used to associate received RTP address:port combination cannot be used to associate received RTP
packets with the correct "m=" line. packets with the correct "m=" line.
As described in [Section 10.1.2], the same payload type value might As described in [Section 10.1.2], the same payload type value might
be used inside RTP packets described by multiple "m=" lines. In such be used inside RTP packets described by multiple "m=" lines. In such
cases, the payload type value cannot be used to associate received cases, the payload type value cannot be used to associate received
RTP packets with the correct "m=" line. RTP packets with the correct "m=" line.
An offerer and answerer can inform each other which SSRC values they An offerer and answerer can inform each other which SSRC values they
will use or RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576]. will use for RTP and RTCP by using the SDP 'ssrc' attribute
To allow for proper association with this mechanism, the 'ssrc' [RFC5576]. To allow for proper association with this mechanism, the
attribute needs to be associated with each "m=" line that shares a 'ssrc' attribute needs to be associated with each "m=" line that
payload type with any other "m=" line in the same bundle. As the shares a payload type with any other "m=" line in the same bundle.
SSRC values will be carried inside the RTP/RTCP packets, the offerer As the SSRC values will be carried inside the RTP/RTCP packets, the
and answerer can then use that information to associate received RTP offerer and answerer can then use that information to associate
packets with the correct "m=" line. However, an offerer will not received RTP packets with the correct "m=" line. However, an offerer
know which SSRC values the answerer will use until it has received will not know which SSRC values the answerer will use until it has
the answer providing that information. Due to this, before the received the answer providing that information. Due to this, before
offerer has received the answer, the offerer will not be able to the offerer has received the answer, the offerer will not be able to
associate received RTP/RTCP packets with the correct "m=" line using associate received RTP/RTCP packets with the correct "m=" line using
the SSRC values. the SSRC values.
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
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP and RTCP packets with the correct "m=" line, an offerer
and answerer using the BUNDLE extension MUST support the mechanism and answerer using the BUNDLE extension MUST support the mechanism
defined in Section 14, where the remote endpoint inserts the defined in Section 14, where the remote endpoint inserts the
identification-tag associated with an "m=" line in RTP and RTCP identification-tag associated with an "m=" line in RTP and RTCP
packets associated with that "m=" line. packets associated with that "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
10.3.1. General 10.3.1. General
When a BUNDLE group, which contains RTP based media, is created, the When a BUNDLE group, which contains RTP based media, is created, the
offerer and answerer MUST negotiate whether to enable RTP/RTCP offerer and answerer MUST negotiate whether to enable RTP/RTCP
multiplexing for the RTP based media associated with the BUNDLE group multiplexing for the RTP based media associated with the BUNDLE group
[RFC5761]. [RFC5761].
If RTP/RTCP multiplexing is enabled, the same address:port If RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for receiving (and sending) all RTP packets combination will be used for sending all RTP packets and the RTCP
and the RTCP packets associated with the BUNDLE group. Each endpoint packets associated with the BUNDLE group. Each endpoint will send
will send the packets towards the BUNDLE address of the other the packets towards the BUNDLE address of the other endpoint. The
endpoint. same address:port combination MAY be used for receiving RTP packets
and RTCP packets.
If RTP/RTCP multiplexing is not enabled, separate address:port If RTP/RTCP multiplexing is not enabled, separate address:port
combinations will be used for receiving (and sending) the RTP packets combinations will be used for sending the RTP packets and the RTCP
and the RTCP packets. If the remote endpoint has associated an SDP packets. The same address:port combinations MAY be used for
'rtcp' attribute with the "m=" line associated with the BUNDLE-tag, receiving RTP packets and RTCP packets. If the remote endpoint has
the attribute value will be used for sending all RTCP packets associated an SDP 'rtcp' attribute with the "m=" line associated with
associated with the BUNDLE group towards that endpoint. the BUNDLE-tag, the attribute value will be used for sending all RTCP
packets associated with the BUNDLE group towards that endpoint.
10.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
10.3.2.1. General 10.3.2.1. General
This section describes how an offerer and answerer can use the SDP This section describes how an offerer and answerer can use the SDP
'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]
to negotiate usage of RTP/RTCP multiplexing for RTP based media to negotiate usage of RTP/RTCP multiplexing for RTP based media
associated with a BUNDLE group. associated with a BUNDLE group.
skipping to change at page 38, line 21 skipping to change at page 39, line 21
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
based on the different alternative proposals, and text (e.g. SDP based on the different alternative proposals, and text (e.g. SDP
examples) have been borrowed (and, in some cases, modified) from examples) have been borrowed (and, in some cases, modified) from
those alternative proposals. those alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach, Ari Keraenen, Adam Roach, Christian Groves, Roman Shpount, Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount,
Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and
Justin Uberti for reading the text, and providing useful feedback. Justin Uberti for reading the text, and providing useful feedback.
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-22
o - Correction of Ari's family name
o - Editorial fixes based on comments from Thomas Stach
o - RTP/RTCP correction based on comment from Magnus Westerlund
o -- http://www.ietf.org/mail-archive/web/mmusic/current/
msg14861.html
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21
o - Correct based on comment from Paul Kyzivat o - Correct based on comment from Paul Kyzivat
o -- 'received packets' replaced with 'received data' o -- 'received packets' replaced with 'received data'
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
o - Clarification based on comment from James Guballa o - Clarification based on comment from James Guballa
o - Clarification based on comment from Flemming Andreasen o - Clarification based on comment from Flemming Andreasen
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19
skipping to change at page 44, line 16 skipping to change at page 45, line 26
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
20. References 20. References
20.1. Normative References 20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[I-D.mmusic-sdp-mux-attributes] [I-D.mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08
(work in progress), January 2015. (work in progress), January 2015.
20.2. Informative References 20.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605,
2003. DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<http://www.rfc-editor.org/info/rfc4568>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>.
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-02 (work in progress), January 2015. mmusic-trickle-ice-02 (work in progress), January 2015.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. General A.1. General
 End of changes. 36 change blocks. 
72 lines changed or deleted 105 lines changed or added

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