draft-ietf-mmusic-sdp-bundle-negotiation-06.txt   draft-ietf-mmusic-sdp-bundle-negotiation-07.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: October 9, 2014 C. Jennings Expires: October 25, 2014 C. Jennings
Cisco Cisco
April 7, 2014 April 23, 2014
Multiplexing Negotiation Using Session Description Protocol (SDP) Port Negotiating Media Multiplexing Using the Session Description Protocol
Numbers (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-06.txt draft-ietf-mmusic-sdp-bundle-negotiation-07.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
"BUNDLE", that can be used with the Session Description Protocol "BUNDLE", that can be used with the Session Description Protocol
(SDP) Offer/Answer mechanism to negotiate the usage of bundled media, (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
which refers to the usage of a single 5-tuple for sending and which refers to the usage of a single 5-tuple for sending and
receiving media associated with multiple SDP media descriptions ("m=" receiving media associated with multiple SDP media descriptions ("m="
lines). lines).
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 October 9, 2014. This Internet-Draft will expire on October 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6 5.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.2. SDP Information Considerations . . . . . . . . . . . 7 5.2.2. SDP Information Considerations . . . . . . . . . . . 7
5.2.3. Generating the Initial Offer . . . . . . . . . . . . 7 5.2.3. Generating the Initial SDP Offer . . . . . . . . . . 8
5.2.4. Generating the Answer . . . . . . . . . . . . . . . . 8 5.2.4. Generating the SDP Answer . . . . . . . . . . . . . . 8
5.2.5. Offerer Processing of the Answer . . . . . . . . . . 10 5.2.5. Offerer Processing of the SDP Answer . . . . . . . . 10
5.2.6. Modifying the Session . . . . . . . . . . . . . . . . 11 5.2.6. Modifying the Session . . . . . . . . . . . . . . . . 11
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 13 6.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 13
6.2.1. Generating the Initial Offer . . . . . . . . . . . . 13 6.2.1. Generating the Initial SDP Offer . . . . . . . . . . 13
6.2.2. Generating the Answer . . . . . . . . . . . . . . . . 13 6.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 13
6.2.3. Offerer Processing of the Answer . . . . . . . . . . 14 6.2.3. Offerer Processing of the SDP Answer . . . . . . . . 14
6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14 6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14
7. Protocol Identification . . . . . . . . . . . . . . . . . . . 14 7. Protocol Identification . . . . . . . . . . . . . . . . . . . 15
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15 7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15
8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15 8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15
8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 15 8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16 8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16
8.2. Associating RTP Packets With Correct SDP Media 8.2. Associating RTP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . . 16 Description . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17 8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17
8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 17 8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 18
9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 19 9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 20
9.2.1. Generating the Initial Offer . . . . . . . . . . . . 19 9.2.1. Generating the Initial SDP Offer . . . . . . . . . . 20
9.2.2. Generating the Answer . . . . . . . . . . . . . . . . 20 9.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 20
9.2.3. Offerer Processing of the Answer . . . . . . . . . . 20 9.2.3. Offerer Processing of the SDP Answer . . . . . . . . 20
9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20 9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20
9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20 9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20
10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 20 10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 21
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 20 10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 21
10.3. New text replacing section 5.1 (2nd paragraph) of RFC 10.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 21 10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 22
10.5. New text replacing section 8.2 (2nd paragraph) of RFC 10.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22 10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22
10.7. New text replacing section 8.4 (6th paragraph) of RFC 10.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Example: Bundle Address Selection . . . . . . . . . . . 22 12.1. Example: Bundle Address Selection . . . . . . . . . . . 23
12.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 24 12.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 24
12.3. Example: Offerer Adds A Media Description To A BUNDLE 12.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 25 Group . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.4. Example: Offerer Moves A Media Description Out Of A 12.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 27 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 27
12.5. Example: Offerer Disables A Media Description Within A 12.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 29 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Design Considerations . . . . . . . . . . . . . . . 34 Appendix A. Design Considerations . . . . . . . . . . . . . . . 35
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 34 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 36
A.3. Usage of port number value zero . . . . . . . . . . . . . 36 A.3. Usage of port number value zero . . . . . . . . . . . . . 37
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 36 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 37
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 37 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 38
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 37 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 38
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 37 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and
receiving media associated with multiple SDP media descriptions ("m=" receiving media associated with multiple SDP media descriptions ("m="
lines) has been identified. This would e.g. allow the usage of a lines) has been identified. This would e.g. allow the usage of a
single set of Interactive Connectivity Establishment (ICE) [RFC5245] single set of Interactive Connectivity Establishment (ICE) [RFC5245]
candidates for multiple media descriptions. Normally different media candidates for multiple media descriptions. Normally different media
types (audio, video etc) will be described using different media types (audio, video etc) will be described using different media
descriptions. descriptions.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the
usage of bundled media, which refers to the usage of a single 5-tuple usage of bundled media, which refers to the usage of a single 5-tuple
for sending and receiving media associated with multiple SDP media for sending and receiving media associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
The offerer and answerer [RFC3264] use the BUNDLE mechanism to The offerer and answerer [RFC3264] use the BUNDLE mechanism to
negotiate BUNDLE addresses, one for the offerer (offerer BUNDLE negotiate BUNDLE addresses, one for the offerer (offerer BUNDLE
address) and one for the answerer (answerer BUNDLE address) to be address) and one for the answerer (answerer BUNDLE address) to be
used for the bundled media associated with a BUNDLE group. used for the bundled media associated with a BUNDLE group.
Once it is known that both the offerer and the answerer supports the Once the offerer and the answerer have negotiated a BUNDLE group, and
BUNDLE mechanism, a BUNDLE group and the associated BUNDLE addresses the associated BUNDLE addresses, each endpoint can assign its BUNDLE
have been negotiated, each endpoint can assign its BUNDLE address to address to each "m=" line within, and use the address to send and
each "m=" line within, and use the address to send and receive all receive all media associated with, the BUNDLE group.
media associated with, the BUNDLE group.
NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning
the same port value to multiple "m=" lines are undefined, and there the same port value to multiple "m=" lines are undefined, and there
is no grouping defined by such means. Instead, an explicit grouping is no grouping defined by such means. Instead, an explicit grouping
mechanism needs to be used to express the intended semantics. This mechanism needs to be used to express the intended semantics. This
specification provides such an extension. specification provides such an extension.
SDP bodies can contain multiple BUNDLE groups. Each BUNDLE group SDP bodies can contain multiple BUNDLE groups. Each BUNDLE group
MUST use a unique 5-tuple. Any given "m=" line can only be MUST use a unique 5-tuple. Any given "m=" line can only be
associated with a single BUNDLE group. associated with a single BUNDLE group.
The procedures in this specification apply to a given BUNDLE group. The procedures in this specification apply independently to a given
BUNDLE group.
The default assumption is that all Real-Time Protocol (RTP) [RFC3550] All Real-time Transport Protocol (RTP) [RFC3550] based media flows
based media flows associated with a BUNDLE group belong to the same associated with a single BUNDLE group belong to a single RTP session
RTP Session [RFC3550]. Future extensions can change that assumption. [RFC3550].
The BUNDLE mechanism is backward compatible. Endpoints that do not The BUNDLE mechanism is backward compatible. Endpoints that do not
support the BUNDLE mechanism are expected to generate SDP offers and support the BUNDLE mechanism are expected to generate SDP offers and
SDP answers without an SDP 'group:BUNDLE' attribute, and are expected SDP answers without an SDP 'group:BUNDLE' attribute, and are expected
to assign a unique address to each "m=" line within an SDP offer and to assign a unique address to each "m=" line within an SDP offer and
SDP answer, according to the procedures in [RFC4566] and [RFC3264] SDP answer, according to the procedures in [RFC4566] and [RFC3264]
This specification also updates sections 5.1, 8.1 and 8.2 of This specification also updates sections 5.1, 8.1 and 8.2 of
[RFC3264], in order to allow an answerer to assign a non-zero port [RFC3264], in order to allow an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the offerer in the value to an "m=" line in an SDP answer, even if the offerer in the
skipping to change at page 5, line 30 skipping to change at page 5, line 30
Shared address: An IP address and IP port combination that is Shared address: An IP address and IP port combination that is
assigned to multiple "m=" lines in an SDP offer or SDP answer. assigned to multiple "m=" lines in an SDP offer or SDP answer.
Offerer suggested BUNDLE mid: The first mid value in a given SDP Offerer suggested BUNDLE mid: The first mid value in a given SDP
'group:BUNDLE' attribute mid list in an SDP offer. 'group:BUNDLE' attribute mid list in an SDP offer.
Answerer selected BUNDLE mid: The first mid value in a given SDP Answerer selected BUNDLE mid: The first mid value in a given SDP
'group:BUNDLE' attribute mid list in an SDP answer. 'group:BUNDLE' attribute mid list in an SDP answer.
Offerer BUNDLE address: Within a given BUNDLE group, an IP address Offerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an offerer to send and receive all and IP port combination used by an offerer to receive all media
media associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
Answerer BUNDLE address: Within a given BUNDLE group, an IP address Answerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an answerer to send and receive all and IP port combination used by an answerer to receive all media
media associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
BUNDLE group: A set of "m=" lines, created using an SDP offer/answer BUNDLE group: A set of "m=" lines, created using an SDP offer/answer
exchange, for which a single 5-tuple is used to send and receive exchange, for which a single 5-tuple is used to send and receive
media. Each endpoint uses its BUNDLE address, associated with the media. Each endpoint uses its BUNDLE address, associated with the
BUNDLE group, to send and receive the media. BUNDLE group, to send and receive the media.
Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer, Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer,
associated with a BUNDLE group. associated with a BUNDLE group.
Bundle-only "m=" line: An "m=" line, to which an SDP 'bundle-only' Bundle-only "m=" line: An "m=" line, to which an SDP 'bundle-only'
attribute has been assigned. attribute has been assigned.
Bundled media: All media associated with a BUNDLE group. Bundled media: All media associated with a BUNDLE group.
Initial SDP offer: The first SDP offer, in which the offerer Initial SDP offer: The first SDP offer, within an SDP session, in
indicates that it wants to create a given BUNDLE group. which the offerer indicates that it wants to create a given BUNDLE
group.
Subsequent SDP offer: An SDP offer which contains a BUNDLE group that Subsequent SDP offer: An SDP offer which contains a BUNDLE group that
has been created as part of a previous SDP offer/answer exchange. has been created as part of a previous SDP offer/answer exchange.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
skipping to change at page 6, line 40 skipping to change at page 6, line 44
given BUNDLE group. given BUNDLE group.
5.2. SDP Offer/Answer Procedures 5.2. SDP Offer/Answer Procedures
5.2.1. General 5.2.1. General
This section describes usage of the SDP offer/answer mechanism This section describes usage of the SDP offer/answer mechanism
[RFC3264] for negotiating usage of the BUNDLE mechanism, for creating [RFC3264] for negotiating usage of the BUNDLE mechanism, for creating
a BUNDLE group, for selecting the BUNDLE addresses (offerer BUNDLE a BUNDLE group, for selecting the BUNDLE addresses (offerer BUNDLE
address and answerer BUNDLE address), for adding an "m=" line to a address and answerer BUNDLE address), for adding an "m=" line to a
BUNDLE group, for moving an "m=" line out of a BUNDEL group, and for BUNDLE group, for moving an "m=" line out of a BUNDLE group, and for
disabling an "m=" line within a BUNDLE group. disabling an "m=" line within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE mechanism. For example, if an SDP offer is also apply to the BUNDLE mechanism. For example, if an SDP offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group) and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an SDP offer in which the apply. Hence, if an offerer generates an SDP offer in which the
offerer wants to create a BUNDLE group, and the answerer rejects the offerer wants to create a BUNDLE group, and the answerer rejects the
SDP offer, the BUNDLE group is not created. SDP offer, the BUNDLE group is not created.
skipping to change at page 7, line 43 skipping to change at page 8, line 5
The total proposed bandwidth is the sum of the proposed bandwidth for The total proposed bandwidth is the sum of the proposed bandwidth for
each bundled "m=" line. each bundled "m=" line.
5.2.2.4. Attributes (a=) 5.2.2.4. Attributes (a=)
[I-D.nandakumar-mmusic-sdp-mux-attributes] defines rules and [I-D.nandakumar-mmusic-sdp-mux-attributes] defines rules and
restrictions for assigning different types of SDP attributes to a restrictions for assigning different types of SDP attributes to a
bundled "m=" line. bundled "m=" line.
5.2.3. Generating the Initial Offer 5.2.3. Generating the Initial SDP Offer
5.2.3.1. General 5.2.3.1. General
When an offerer generates an initial SDP offer, in order to create a When an offerer generates an initial SDP offer, in order to create a
BUNDLE group, the offerer MUST in the SDP offer assign a unique BUNDLE group, the offerer MUST in the SDP offer assign a unique
address to each "m=" line with a non-zero port value, following the address to each "m=" line with a non-zero port value, following the
procedures in [RFC3264]. procedures in [RFC3264].
The offerer MUST in the SDP offer insert an SDP session level The offerer MUST in the SDP offer insert an SDP session level
'group:BUNDLE' attribute, associated with the BUNDLE group, and 'group:BUNDLE' attribute, associated with the BUNDLE group, and
skipping to change at page 8, line 22 skipping to change at page 8, line 31
5.2.3.2. Request offerer BUNDLE address selection 5.2.3.2. Request offerer BUNDLE address selection
When an offerer generates an initial SDP offer, in order to create a When an offerer generates an initial SDP offer, in order to create a
BUNDLE group, the offerer MUST in the SDP offer indicate which unique BUNDLE group, the offerer MUST in the SDP offer indicate which unique
address, associated with one of the "m=" lines that the offerer wants address, associated with one of the "m=" lines that the offerer wants
to be within the BUNDLE group, that the offerer wants the answerer to to be within the BUNDLE group, that the offerer wants the answerer to
select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP
offer, the offerer BUNDLE mid value represents that address. offer, the offerer BUNDLE mid value represents that address.
5.2.4. Generating the Answer 5.2.4. Generating the SDP Answer
5.2.4.1. RFC 5888 restrictions 5.2.4.1. RFC 5888 restrictions
When an answerer generates an SDP answer, the following restrictions, When an answerer generates an SDP answer, the following restrictions,
defined in [RFC5888], also apply a BUNDLE group: defined in [RFC5888], also apply a BUNDLE group:
o 1) The answerer MUST NOT in the SDP answer include a BUNDLE group, o 1) The answerer MUST NOT in the SDP answer include a BUNDLE group,
unless the offerer in the associated SDP offer requested the unless the offerer in the associated SDP offer requested the
BUNDLE group to be created; and BUNDLE group to be created; and
o 2) The answerer MUST NOT in the SDP answer include an "m=" line o 2) The answerer MUST NOT in the SDP answer include an "m=" line
within a BUNDLE group, unless the offerer in the associated SDP within a BUNDLE group, unless the offerer in the associated SDP
offer requested the "m=" line to be within the BUNDLE group. offer requested the "m=" line to be within the BUNDLE group.
5.2.4.2. Answerer Selection of Offerer Bundle Address 5.2.4.2. Answerer Selection of Offerer Bundle Address
When an answerer generates an SDP answer, it MUST select a BUNDLE When an answerer generates an SDP answer, it MUST select a BUNDLE
address for the offerer, referred to as the offerer BUNDLE address. address for the offerer, referred to as the offerer BUNDLE address.
The answerer MUST select an address which the offerer in the The answerer MUST select an address which the offerer in the
associated SDP answer requested to be within the BUNDLE group. associated SDP offer requested to be within the BUNDLE group.
In the SDP offer, the offerer suggested BUNDLE mid represents the In the SDP offer, the offerer suggested BUNDLE mid represents the
"m=" line to which the offerer in the SDP offer has assigned the "m=" line to which the offerer in the SDP offer has assigned the
address that it wants the answerer to select as the offerer BUNDLE address that it wants the answerer to select as the offerer BUNDLE
address [Section 5.2.3.2]. The answerer MUST first select the "m=" address [Section 5.2.3.2]. The answerer MUST first select the "m="
line associated with the offerer suggested BUNDLE mid, and check line associated with the offerer suggested BUNDLE mid, and check
whether it fulfils the following criteria: whether it fulfils the following criteria:
o The answerer will in the SDP answer create the BUNDLE group; o The answerer will in the SDP answer create the BUNDLE group;
o The answerer will not in the SDP answer move the "m=" line out of o The answerer will not in the SDP answer move the "m=" line out of
the BUNDLE group [Section 5.2.4.4]; the BUNDLE group [Section 5.2.4.4];
o The answerer will not in the SDP answer reject the "m=" line o The answerer will not in the SDP answer reject the "m=" line
[Section 5.2.4.5]; and [Section 5.2.4.5]; and
o The offerer did not in the associated SDP offer assign a zero port o The offerer did not in the associated SDP offer assign a zero port
value to the "m=" line. value to the "m=" line.
If all of the criteria above is fulfilled, the answerer MUST select If all of the criteria above is fulfilled, the answerer MUST select
skipping to change at page 10, line 35 skipping to change at page 10, line 45
When an answerer generates an SDP answer, in which the answerer When an answerer generates an SDP answer, in which the answerer
rejects an "m=" line, the answerer MUST in the SDP answer assign an rejects an "m=" line, the answerer MUST in the SDP answer assign an
address with a zero port value to the rejected "m=" line, according address with a zero port value to the rejected "m=" line, according
to the procedures in [RFC4566]. to the procedures in [RFC4566].
In addition, the answerer MUST NOT in the SDP answer include a mid In addition, the answerer MUST NOT in the SDP answer include a mid
value, associated with the rejected "m=" line, in the SDP value, associated with the rejected "m=" line, in the SDP
'group:BUNDLE' attribute mid list associated with the BUNDLE group. 'group:BUNDLE' attribute mid list associated with the BUNDLE group.
5.2.5. Offerer Processing of the Answer 5.2.5. Offerer Processing of the SDP Answer
5.2.5.1. General 5.2.5.1. General
When an offerer receives an SDP answer, the offerer MUST apply the When an offerer receives an SDP answer, the offerer MUST apply the
selected offerer BUNDLE address to each bundled "m=" line. If the selected offerer BUNDLE address to each bundled "m=" line. If the
offerer generates a subsequent SDP offer, the offerer MUST in the SDP offerer generates a subsequent SDP offer, the offerer MUST in the SDP
offer assign the offerer BUNDLE address to each bundled "m=" line offer assign the offerer BUNDLE address to each bundled "m=" line
(including any 'bundle-only' "m=" line) [Section 5.2.6]. (including any 'bundle-only' "m=" line) [Section 5.2.6].
If the SDP answer does not contain a BUNDLE group, the offerer MUST If the SDP answer does not contain a BUNDLE group, the offerer MUST
skipping to change at page 12, line 14 skipping to change at page 12, line 25
5.2.6.2. Adding a media description to a BUNDLE group 5.2.6.2. Adding a media description to a BUNDLE group
When an offerer generates an SDP offer, in which the offerer wants to When an offerer generates an SDP offer, in which the offerer wants to
add an "m=" line to a BUNDLE group, the offerer assigns in the SDP add an "m=" line to a BUNDLE group, the offerer assigns in the SDP
offer an address (unique or previously selected offerer BUNDLE offer an address (unique or previously selected offerer BUNDLE
address) to the "m=" line, assigns an SDP 'mid' attribute to the "m=" address) to the "m=" line, assigns an SDP 'mid' attribute to the "m="
line, and places the mid value in the SDP 'group:BUNDLE' attribute line, and places the mid value in the SDP 'group:BUNDLE' attribute
mid list associated with the BUNDLE group [Section 5.2.3.2]. mid list associated with the BUNDLE group [Section 5.2.3.2].
NOTE: If the offerer wants that the answerer selects the address NOTE: If the offerer wants the answerer to select the address
associated with the added "m=" as the offerer BUNDLE address, the associated with the added "m=" as the offerer BUNDLE address, the
offerer suggested BUNDLE mid MUST represent the added "m=" line offerer suggested BUNDLE mid MUST represent the added "m=" line
[Section 5.2.3.2]. [Section 5.2.3.2].
[Section 12.3] shows an example where an offerer sends an SDP offer [Section 12.3] shows an example where an offerer sends an SDP offer
in order to add an "m=" line to a BUNDLE group. in order to add an "m=" line to a BUNDLE group.
5.2.6.3. Moving A Media Description Out Of A BUNDLE Group 5.2.6.3. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an SDP offer, in which the offerer wants to When an offerer generates an SDP offer, in which the offerer wants to
skipping to change at page 13, line 19 skipping to change at page 13, line 35
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. An offerer can in an SDP offer assign a 'bundle-only' 'bundle-only'. An offerer can in an SDP offer assign a 'bundle-only'
"m=" line to a bundled "m=" line (including an "m=" line that the "m=" line to a bundled "m=" line (including an "m=" line that the
offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order
to ensure that the answerer only accepts the "m=" line if the to ensure that the answerer only accepts the "m=" line if the
answerer supports the BUNDLE mechanism, and if the answerer in the answerer supports the BUNDLE mechanism, and if the answerer in the
SDP answer keeps the "m=" line within the BUNDLE group. SDP answer keeps the "m=" line within the BUNDLE group.
6.2. SDP Offer/Answer Procedures 6.2. SDP Offer/Answer Procedures
6.2.1. Generating the Initial Offer 6.2.1. Generating the Initial SDP Offer
When an offerer generates an initial SDP offer, in order to create a When an offerer generates an initial SDP offer, in order to create a
BUNDLE group, the offerer can in the SDP offer assign an SDP 'bundle- BUNDLE group, the offerer can in the SDP offer assign an SDP 'bundle-
only' attribute to an "m=" line that the offerer wants to be within only' attribute to an "m=" line that the offerer wants to be within
the BUNDLE group. the BUNDLE group.
The offerer MUST in the SDP offer assign a zero port value the The offerer MUST in the SDP offer assign a zero port value the
bundle-only "m=" line. bundle-only "m=" line.
6.2.2. Generating the Answer 6.2.2. Generating the SDP Answer
When the answerer selects the offerer BUNDLE address When the answerer selects the offerer BUNDLE address
[Section 5.2.4.2], the answerer MUST also take a bundle-only "m=" [Section 5.2.4.2], the answerer MUST also take a bundle-only "m="
line with a non-zero port value into consideration. line with a non-zero port value into consideration.
If the offerer in the SDP offer has assigned a zero port value to a If the offerer in the SDP offer has assigned a zero port value to a
bundle-only "m=" line, and if the answerer accepts the "m=" line, the bundle-only "m=" line, and if the answerer accepts the "m=" line, the
answerer will treat the "m=" line as any other bundle "m=" line when answerer will treat the "m=" line as any other bundle "m=" line when
the answerer generates the SDP answer [Section 5.2.4]. the answerer generates the SDP answer [Section 5.2.4].
skipping to change at page 14, line 5 skipping to change at page 14, line 20
offerer wants to disable the "m=" line [Section 5.2.6.4]. offerer wants to disable the "m=" line [Section 5.2.6.4].
If the answerer in the SDP answer does not keep the bundle-only "m=" If the answerer in the SDP answer does not keep the bundle-only "m="
line within the BUNDLE group, the answerer MUST in the SDP answer line within the BUNDLE group, the answerer MUST in the SDP answer
reject the "m=" line [Section 5.2.4.5]. reject the "m=" line [Section 5.2.4.5].
The answerer MUST NOT in the SDP answer assign an SDP 'bundle-only' The answerer MUST NOT in the SDP answer assign an SDP 'bundle-only'
attribute to an "m=" line (even if the offerer in the associated SDP attribute to an "m=" line (even if the offerer in the associated SDP
offer has assigned a 'bundle-only' attribute to the "m="line). offer has assigned a 'bundle-only' attribute to the "m="line).
6.2.3. Offerer Processing of the Answer 6.2.3. Offerer Processing of the SDP Answer
When the offerer receives an SDP answer, the offerer follows the When the offerer receives an SDP answer, the offerer follows the
procedures in [Section 5.2.5]. If the offerer in the associated SDP procedures in [Section 5.2.5]. If the offerer in the associated SDP
offer assigned an SDP 'bundle-only' attribute to an "m=" line, and offer assigned an SDP 'bundle-only' attribute to an "m=" line, and
the "m=" line was accepted (and was kept within the BUNDLE group) by the "m=" line was accepted (and was kept within the BUNDLE group) by
the answerer, the selected offerer BUNDLE address also applies to the the answerer, the selected offerer BUNDLE address also applies to the
"m=" line. "m=" line.
6.2.4. Modifying the Session 6.2.4. Modifying the Session
skipping to change at page 15, line 30 skipping to change at page 16, line 4
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 how to associate the received DTLS packet with describes a mechanism how to associate the received DTLS packet with
the correct "m=" line. the correct "m=" line.
[Section 8.2] describes how to associate a received (S)RTP packet [Section 8.2] describes how to associate a received (S)RTP packet
with the correct "m=" line. with the correct "m=" line.
8. RTP Considerations 8. RTP Considerations
8.1. Single RTP Session 8.1. Single RTP Session
8.1.1. General 8.1.1. General
By default, all RTP based media within a BUNDLE group belong to a All RTP-based media within a single BUNDLE group belong to a single
single RTP session [RFC3550]. Multiple BUNDLE groups will form RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP
multiple RTP Sessions. sessions, one per BUNDLE group.
NOTE: The usage of multiple RTP sessions within a BUNDLE group, or
the usage of a single RTP session that spans over multiple BUNDLE
groups, is outside the scope of this specification. Other
specification needs to extend the BUNDLE mechanism in order to allow
such usages.
When a single RTP session is used, all bundled "m=" lines Since a single RTP session is used for each bundle group, all "m="
representing RTP based media share a single SSRC numbering space lines representing RTP-based media in a bundle group will share a
[RFC3550]. single SSRC numbering space [RFC3550].
In addition, the following rules and restrictions apply for a single The following rules and restrictions apply for a single RTP session:
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 if each codec associated with the payload type number shares lines if each codec associated with the payload type number shares
an identical codec configuration [Section 8.1.2]. an identical codec configuration [Section 8.1.2].
o The "proto" value in each bundled "m=" line MUST be identical o The "proto" value in each bundled "m=" line MUST be identical
(e.g. RTP/AVPF). (e.g. RTP/AVPF).
o A given SSRC SHOULD NOT transmit RTP packets using payload types o A given SSRC SHOULD NOT transmit RTP packets using payload types
that originates from different bundled "m=" lines. that originates from different bundled "m=" lines.
skipping to change at page 18, line 5 skipping to change at page 18, line 17
8.3.2. SDP Offer/Answer Procedures 8.3.2. SDP Offer/Answer Procedures
8.3.2.1. General 8.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 associated to negotiate usage of RTP/RTCP multiplexing for RTP based associated
with a BUNDLE group. with a BUNDLE group.
8.3.2.2. Generating the Initial Offer 8.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial SDP offer, if the offerer wants When an offerer generates an initial SDP offer, if the offerer wants
to negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, to negotiate usage of RTP/RTCP multiplexing within a BUNDLE group,
the offerer MUST in the SDP offer assign an SDP 'rtcp-mux' attribute the offerer MUST in the SDP offer assign an SDP 'rtcp-mux' attribute
[RFC5761] to each bundled "m=" line (including any bundle-only "m=" [RFC5761] to each bundled "m=" line (including any bundle-only "m="
line). In addition, the offerer MUST in the SDP offer assign an SDP line). In addition, the offerer MUST in the SDP offer assign an SDP
'rtcp' attribute [RFC3605] to each bundled "m=" line (including any 'rtcp' attribute [RFC3605] to each bundled "m=" line (including any
bundle-only "m=" line), with an attribute value that is identical to bundle-only "m=" line), with an attribute value that is identical to
the port value assigned to the "m=" line itself. the port value assigned to the "m=" line itself.
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, the offerer MUST NOT assign the SDP attributes above to multiplexing, the offerer MUST NOT assign the SDP attributes above to
any bundled "m=" line. any bundled "m=" line.
8.3.2.3. Generating the Answer 8.3.2.3. Generating the SDP Answer
8.3.2.3.1. Generating the Answer to an Initial Offer 8.3.2.3.1. Generating the SDP Answer to an Initial SDP Offer
When the answerer generates an SDP answer to an initial SDP offer, if When the answerer generates an SDP answer to an initial SDP offer, if
the offerer in the associated SDP offer indicated support of RTP/RTCP the offerer in the associated SDP offer indicated support of RTP/RTCP
multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in
the SDP answer either accept or reject usage of RTP/RTCP the SDP answer either accept or reject usage of RTP/RTCP
multiplexing. multiplexing.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST in the SDP answer assign an SDP BUNDLE group, the answerer MUST in the SDP answer assign an SDP
'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST 'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST
skipping to change at page 18, line 38 skipping to change at page 19, line 4
multiplexing. multiplexing.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST in the SDP answer assign an SDP BUNDLE group, the answerer MUST in the SDP answer assign an SDP
'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST 'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST
NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled
"m=" line. "m=" line.
OPEN ISSUE: Do we want to include the SDP 'rtcp' attribute also in OPEN ISSUE: Do we want to include the SDP 'rtcp' attribute also in
the SDP answer, eventhough it is not needed? the SDP answer, eventhough it is not needed?
If the answerer rejects usage of RTP/RTCP multiplexing within the If the answerer rejects usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP
'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line. 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line.
8.3.2.3.2. Generating the Answer to a Subsequent Offer 8.3.2.3.2. Generating the SDP Answer to a Subsequent SDP Offer
When the answerer generates an SDP answer to a subsequent SDP offer, When the answerer generates an SDP answer to a subsequent SDP offer,
if the offerer in the associated SDP offer indicated support of RTP/ if the offerer in the associated SDP offer indicated support of RTP/
RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST
in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp' in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp'
attribute to each bundled "m=" line. attribute to each bundled "m=" line.
NOTE: The BUNDLE mechanism does not allow the answerer to, in a NOTE: The BUNDLE mechanism does not allow the answerer to, in a
subsequent SDP answer, disable usage of RTP/RTCP multiplexing, if the subsequent SDP answer, disable usage of RTP/RTCP multiplexing, if the
offerer in the associated SDP offer indicates that it wants to offerer in the associated SDP offer indicates that it wants to
continue using RTP/RTCP multiplexing. continue using RTP/RTCP multiplexing.
8.3.2.4. Offerer Processing of the Answer 8.3.2.4. Offerer Processing of the SDP Answer
When the offerer receives an SDP answer, it follows the procedures When the offerer receives an SDP answer, it follows the procedures
defined in [RFC5245]. defined in [RFC5245].
8.3.2.5. Modifying the Session 8.3.2.5. Modifying the Session
When an offerer generates a subsequent SDP offer, if the offerer When an offerer generates a subsequent SDP offer, if the offerer
wants to negotiate usage of RTP/RTCP multiplexing within a BUNDLE wants to negotiate usage of RTP/RTCP multiplexing within a BUNDLE
group, or if the offerer wants to continue usage of previously group, or if the offerer wants to continue usage of previously
negotiated RTP/RTCP multiplexing within the BUNDLE group, the offerer negotiated RTP/RTCP multiplexing within the BUNDLE group, the offerer
skipping to change at page 19, line 47 skipping to change at page 20, line 18
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].
Support and usage of ICE mechanism together with the BUNDLE mechanism Support and usage of ICE mechanism together with the BUNDLE mechanism
is optional. is optional.
9.2. SDP Offer/Answer Procedures 9.2. SDP Offer/Answer Procedures
9.2.1. Generating the Initial Offer 9.2.1. Generating the Initial SDP Offer
When an offerer generates an initial SDP offer, which contains a When an offerer generates an initial SDP offer, which contains a
BUNDLE group, the offerer MUST assign ICE candidates [RFC5245] to BUNDLE group, the offerer MUST assign ICE candidates [RFC5245] to
each bundled "m=" line, except to an "m=" line to which the offerer each bundled "m=" line, except to an "m=" line to which the offerer
assigns a zero port value (e.g. a bundle-only "m=" line). The assigns a zero port value (e.g. a bundle-only "m=" line). The
offerer MUST assign unique ICE candidate values to each "m=" line. offerer MUST assign unique ICE candidate values to each "m=" line.
9.2.2. Generating the Answer 9.2.2. Generating the SDP Answer
When an answerer generates and SDP Answer, which contains a BUNDLE When an answerer generates and SDP Answer, which contains a BUNDLE
group, the answerer MUST assign ICE candidates to each bundled "m=" group, the answerer MUST assign ICE candidates to each bundled "m="
line. The answerer MUST assign identical ICE candidate values to line. The answerer MUST assign identical ICE candidate values to
each bundled "m=" line. each bundled "m=" line.
9.2.3. Offerer Processing of the Answer 9.2.3. Offerer Processing of the SDP Answer
When the offerer receives an SDP answer, it follows the procedures When the offerer receives an SDP answer, it follows the procedures
defined in [RFC5245]. defined in [RFC5245].
9.2.4. Modifying the Session 9.2.4. Modifying the Session
When an offerer generates a subsequent SDP offer, for each bundled When an offerer generates a subsequent SDP offer, for each bundled
"m=" line to which the offerer assigns its BUNDLE address, the "m=" line to which the offerer assigns its BUNDLE address, the
offerer MUST assign identical ICE candidate values. The offerer MUST offerer MUST assign identical ICE candidate values. The offerer MUST
assign the ICE candidate values associated with the "m=" line that assign the ICE candidate values associated with the "m=" line that
skipping to change at page 31, line 29 skipping to change at page 32, line 29
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 and Martin Thompson for taking the the time to Thanks to Paul Kyzivat and Martin Thompson for taking the the time to
read the text along the way, and providing useful feedback. read the text along the way, and providing useful feedback.
15. Change Log 15. 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-06
o Draft title changed.
o Added "SDP" to section names containing "Offer" or "Answer".
o Editorial fixes based on comments from Paul Kyzivat (http://
www.ietf.org/mail-archive/web/mmusic/current/msg13314.html).
o Editorial fixed based on comments from Colin Perkins (http://
www.ietf.org/mail-archive/web/mmusic/current/msg13318.html).
o - Removed text about extending BUNDLE to allow multiple RTP
sessions within a BUNDLE group.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05
o Major re-structure of SDP Offer/Answer sections, to align with RFC o Major re-structure of SDP Offer/Answer sections, to align with RFC
3264 structure. 3264 structure.
o Additional definitions added. o Additional definitions added.
o - Shared address. o - Shared address.
o - Bundled "m=" line. o - Bundled "m=" line.
 End of changes. 44 change blocks. 
94 lines changed or deleted 102 lines changed or added

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