draft-ietf-mmusic-sdp-bundle-negotiation-16.txt   draft-ietf-mmusic-sdp-bundle-negotiation-17.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: July 31, 2015 C. Jennings Expires: September 4, 2015 C. Jennings
Cisco Cisco
January 27, 2015 March 3, 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-16.txt draft-ietf-mmusic-sdp-bundle-negotiation-17.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 10 skipping to change at page 2, line 10
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 July 31, 2015. This Internet-Draft will expire on September 4, 2015.
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 26 skipping to change at page 3, line 26
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . 24
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 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. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
12.3. New text replacing section 5.1 (2nd paragraph) of RFC 12.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
12.5. New text replacing section 8.2 (2nd paragraph) of RFC 12.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
12.7. New text replacing section 8.4 (6th paragraph) of RFC 12.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. RTP/RTCP extensions for identification-tag transport . . . . 26 13. RTP/RTCP extensions for identification-tag transport . . . . 26
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Example: Bundle Address Selection . . . . . . . . . . . 29 16.1. Example: Bundle Address Selection . . . . . . . . . . . 30
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31
16.3. Example: Offerer Adds A Media Description To A BUNDLE 16.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 32 Group . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.4. Example: Offerer Moves A Media Description Out Of A 16.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
16.5. Example: Offerer Disables A Media Description Within A 16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
19.1. Normative References . . . . . . . . . . . . . . . . . . 42 19.1. Normative References . . . . . . . . . . . . . . . . . . 43
19.2. Informative References . . . . . . . . . . . . . . . . . 43 19.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Design Considerations . . . . . . . . . . . . . . . 44 Appendix A. Design Considerations . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 45
A.3. Usage of port number value zero . . . . . . . . . . . . . 46 A.3. Usage of port number value zero . . . . . . . . . . . . . 46
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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
skipping to change at page 21, line 4 skipping to change at page 21, line 5
'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.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offerer wants to When an offerer generates an initial offer, if the offerer wants to
negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the
offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with
each bundled RTP-based "m=" line (including any bundle-only "m=" each bundled RTP-based "m=" line (including any bundle-only "m="
line) in the offer. In addition, the offerer MUST associate an SDP line) in the offer.
'rtcp' attribute [RFC3605] with each bundled RTP-based "m=" line
(including any bundle-only "m=" line), with an attribute value that
is identical to the port value assigned to the "m=" line itself, in
the offer.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate usage of RTP/RTCP
multiplexing, it MUST NOT associate the SDP attributes above with any multiplexing, it MUST NOT associate an SDP 'rtcp-mux' attribute with
bundled "m=" line. any bundled "m=" line in the offer.
In addition, the offerer can associate an SDP 'rtcp' attribute
[RFC3605] with one or more bundled RTP-based "m=" lines (including
any bundle-only "m=" line) in the offer, in order to provide a port
for receiving RTCP packets (if the answerer does not accept usage of
RTP/RTCP multiplexing, or if the offerer does not want to negotiate
usage of RTP/RTCP multiplexing).
In the initial offer, the IP address and port combination for RTCP
MUST be unique in each bundled RTP-based "m=" line, similar to RTP.
NOTE: In case the offer wants to receive RTCP packets on the next
higher port value, the SDP 'rtcp' attribute is not needed.
10.3.2.3. Generating the SDP Answer 10.3.2.3. Generating the SDP Answer
When an answerer generates an answer, if the offerer indicated When an answerer generates an answer, if the offerer indicated
support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in
the associated offer, the answerer MUST either accept or reject the the associated offer, the answerer MUST either accept or reject the
usage of RTP/RTCP multiplexing in the answer. usage of RTP/RTCP multiplexing for the whole BUNDLE group in the
answer.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts the usage of RTP/RTCP multiplexing within the
BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with each BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with each
bundled RTP-based "m=" line in the answer. The answerer MUST NOT bundled RTP-based "m=" line in the answer. The answerer MUST NOT
associate an SDP 'rtcp' attribute with any bundled "m=" line in the associate an SDP 'rtcp' attribute with any bundled "m=" line in the
answer. The answerer will use the port number of the selected answer. The answerer will use the port value of the selected offerer
offerer BUNDLE address for sending RTP and RTCP packets associated BUNDLE address for sending RTP and RTCP packets associated with each
with each bundled RTP-based "m=" line towards the offerer. RTP-based bundled "m=" line towards the offerer.
If the answerer rejects usage of RTP/RTCP multiplexing within the If the answerer does not accept the usage of RTP/RTCP multiplexing
BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux' or SDP 'rtcp' within the BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux'
attribute with any bundled "m=" line in the answer. The answerer attribute with any bundled "m=" line in the answer. The answerer
MUST, based on the port number of the selected offerer BUNDLE will use the RTP and RTCP port values associated with the selected
address, use the next higher (odd) destination port number [RFC3550] offerer BUNDLE address for sending RTP and RTCP packets associated
for sending RTCP packets associated with each bundled RTP-based "m=" with each RTP-based bundled "m=" line towards the offerer.
line towards the offerer.
NOTE: When the answerer rejects usage of RTP/RTCP multiplexing, the In addition, if the answerer rejects the usage of RTP/RTCP
reason for mandating usage of the next higher (odd) destination port multiplexing within the BUNDLE group, it MAY associate an SDP 'rtcp'
number for RTCP is to allign the procedures for the corresponding attribute, with identical attribute values, with each RTP-based
offer. bundled "m=" line in the answer, in order to provide a port value for
receiving RTCP packets from the offerer.
If the usage of RTP/RTCP multiplexing has been negotiated in a NOTE: In case the answerer wants to receive RTCP packets on the next
previous offer/answer transaction, and the offerer indicates that it higher port value, the SDP 'rtcp' attribute is not needed.
wants to continue using RTP/RTCP multiplexing in a subsequent offer,
the answerer MUST associate an SDP 'rtcp-mux' attribute with each If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
bundled "m=" line in the answer. I.e. the answerer MUST NOT disable negotiated in a previous offer/answer transaction, and if the offerer
the usage of RTP/RTCP multiplexing. indicates that it wants to continue using RTP/RTCP multiplexing in a
subsequent offer, the answerer MUST associate an SDP 'rtcp-mux'
attribute with each bundled "m=" line in the answer. I.e. the
answerer MUST NOT disable the usage of RTP/RTCP multiplexing.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has not
been negotiated in a previous offer/answer transaction, and if the
offerer indicates that it wants to use RTP/RTCP multiplexing in a
subsequent offer, the answerer either accepts or rejects the usage,
using the procedures above.
10.3.2.4. Offerer Processing of the SDP Answer 10.3.2.4. Offerer Processing of the SDP Answer
When the offerer receives an answer, if the answerer accepts the When an offerer receives an answer, if the answerer has accepted the
usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux' usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer
attribute to each bundled "m=" line in the answer [Section 10.3.2.3], follows the procedures for RTP/RTCP multiplexing defined in
the answerer follows the procedures for RTP/RTCP multiplexing defined [RFC5761]. The offerer will use the port value associated with the
in [RFC5761]. The offerer will use the port number of the answerer answerer BUNDLE address for sending RTP and RTCP packets associated
BUNDLE address for sending RTP and RTCP packets associated with each with each RTP-based bundled "m=" line towards the answerer.
bundled "m=" line towards the answerer.
If the answerer does not accept the usage of RTP/RTCP multiplexing If the answerer did not accept the usage of RTP/RTCP multiplexing
[Section 10.3.2.3], the offerer MUST use separate address:port (see Section 10.3.2.3), the offerer will use separate address + port
combinations for RTP and RTCP. The offerer will, based on the port combinations for sending RTP and RTCP packets towards the answerer.
number of the answerer BUNDLE address, use the next higher (odd) If the answerer associated an SDP 'rtcp' attribute with the "m=" line
destination port number [RFC3550] for sending RTCP packets associated representing the answerer BUNDLE address, the offerer will use the
with a bundled "m=" line towards the answerer. attribute port value for sending RTCP packets associated with each
bundled RTP-based "m=" line towards the answerer. Otherwise the
offerer will use the next higher port value associated with the
answerer BUNDLE address for sending RTCP packets towards the
answerer.
10.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
When an offerer generates a subsequent offer, if it wants to When an offerer generates a subsequent offer, if it wants to
negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if negotiate the usage of RTP/RTCP multiplexing within a BUNDLE group,
it wants to continue usage of RTP/RTCP multiplexing (negotiated in a or if it wants to continue the use of previously negotiated RTP/RTCP
previous offer/answer transaction), it MUST associate SDP 'rtcp-mux' multiplexing, it MUST associate an SDP 'rtcp-mux' attribute with each
and 'rtcp' attributes with each bundled "m=" line (including any RTP-based bundled "m=" line (including any bundled "m=" line that the
bundled "m=" line that the offerer wants to add to the BUNDLE group), offerer wants to add to the BUNDLE group), unless the offerer wants
unless the offerer wants to disable or remove the "m=" line from the to disable or remove the "m=" line from the BUNDLE group.
BUNDLE group.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate the usage of RTP/RTCP
multiplexing within the BUNDLE group, or if it wants to disable usage multiplexing within the BUNDLE group, or if it wants to disable
of RTP/RTCP multiplexing (negotiated in a previous offer/answer previously negotiated usage of RTP/RTCP multiplexing, it MUST NOT
transaction), the offerer MUST NOT associate SDP 'rtcp-mux' and associate an SDP 'rtcp-mux' and attribute with any bundled "m=" line
'rtcp' attributes with any bundled "m=" line in the subsequent offer. in the subsequent offer.
NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has In addition, if the offerer does not indicate support of RTP/RTCP
been negotiated within a BUNDLE group, that the usage is not multiplexing within the subsequent offer, it MAY associate an SDP
'rtcp' attribute, with identical attribute values, with each RTP-
based bundled "m=" line (including any bundled "m=" line that the
offerer wants to add to the BUNDLE group), in order to provide a port
for receiving RTCP packets.
NOTE: It is RECOMMENDED that, once the usage of RTP/RTCP multiplexing
has been negotiated within a BUNDLE group, that the usage is not
disabled. Disabling RTP/RTCP multiplexing means that the offerer and disabled. Disabling RTP/RTCP multiplexing means that the offerer and
answerer need to reserve new ports, to be used for sending and answerer need to reserve new ports, to be used for sending and
receiving RTCP packets. receiving RTCP packets. Similar, if the usage of a specific RTCP
port has been negotiated within a BUNDLE group, it is RECOMMENDED
that the port value is not modified.
11. ICE Considerations 11. ICE Considerations
11.1. General 11.1. General
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [RFC5245]. mechanism [RFC5245].
The procedures defined in [RFC5245] also apply to usage of ICE with The procedures defined in [RFC5245] also apply to usage of ICE with
skipping to change at page 28, line 18 skipping to change at page 28, line 35
[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 "RTCP SDES item This document adds the MID SDES item to the IANA "RTCP 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
14.2. New RTP Header Extension URI 14.2. New RTP 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 Compact Header This document defines a new extension URI in the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP) Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data: Parameters registry, according to the following data:
skipping to change at page 29, line 5 skipping to change at page 29, line 18
Reference: RFCXXXX Reference: RFCXXXX
14.3. New SDP Attribute 14.3. New SDP Attribute
[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 SDP media-level attribute, 'bundle-only', This document defines a new SDP media-level attribute, 'bundle-only',
according to the following data: according to the following data:
Attribute name: bundle-only Attribute name: bundle-only
Type of attribute: media Type of attribute: media
Subject to charset: No Subject to charset: No
Purpose: Request a media description to be accepted Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE in the answer only if kept within a BUNDLE
group by the answerer. group by the answerer.
Appropriate values: N/A Appropriate values: N/A
Contact name: Christer Holmberg Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX Reference: RFCXXXX
15. Security Considerations 15. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information to the BUNDLE extension. Bundle does not change which information
flows over the network but only changes which ports that information flows over the network but only changes which ports that information
is flowing on and thus has very little impact on the security of the is flowing on and thus has very little impact on the security of the
RTP sessions. RTP sessions.
When the BUNDLE extension is used, a single set of security When the BUNDLE extension is used, a single set of security
skipping to change at page 38, line 16 skipping to change at page 38, line 16
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach and Ari Keraenen for taking the time to read the text along the Stach and Ari Keraenen for taking the time to read the text along the
way, and providing useful feedback. way, and providing useful feedback.
18. Change Log 18. 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-16
o - Modification of RTP/RTCP multiplexing section, based on comments
from Magnus Westerlund.
o - Reference updates.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15
o - Editorial fix. o - Editorial fix.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14
o - Editorial changes. o - Editorial changes.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13
skipping to change at page 43, line 23 skipping to change at page 43, line 30
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[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-05 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08
(work in progress), November 2014. (work in progress), January 2015.
19.2. Informative References 19.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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, October
2003. 2003.
skipping to change at page 44, line 12 skipping to change at page 44, line 20
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, May 2010.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160, April 2014.
[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-01 (work in progress), February 2014. mmusic-trickle-ice-02 (work in progress), January 2015.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. General A.1. General
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value
should be inserted in "m=" lines associated with a BUNDLE group, as should be inserted in "m=" lines associated with a BUNDLE group, as
the purpose of the extension is to negotiate the usage of a single the purpose of the extension is to negotiate the usage of a single
address:port combination for media associated with the "m=" lines. address:port combination for media associated with the "m=" lines.
 End of changes. 33 change blocks. 
90 lines changed or deleted 127 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/