draft-ietf-mmusic-sdp-bundle-negotiation-04.txt   draft-ietf-mmusic-sdp-bundle-negotiation-05.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track H. Alvestrand Intended status: Standards Track H. Alvestrand
Expires: December 16, 2013 Google Expires: April 17, 2014 Google
C. Jennings C. Jennings
Cisco Cisco
June 14, 2013 October 14, 2013
Multiplexing Negotiation Using Session Description Protocol (SDP) Port Multiplexing Negotiation Using Session Description Protocol (SDP) Port
Numbers Numbers
draft-ietf-mmusic-sdp-bundle-negotiation-04.txt draft-ietf-mmusic-sdp-bundle-negotiation-05.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 media associated which refers to the usage of a single 5-tuple for media associated
with multiple SDP media descriptions ("m=" lines). with multiple SDP media descriptions ("m=" lines).
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2013. This Internet-Draft will expire on April 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5 6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6 6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6
6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6 6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6
6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6 6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6
6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6 6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6
6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6 6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6
6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6 6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6
6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6 6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6
6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 6 6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 7
6.4.1. SDP Offerer Bundle Address Request and Usage . . . . 7 6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
6.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 7 6.4.2. Request BUNDLE address selection . . . . . . . . . . 8
6.4.3. Adding a media description to a BUNDLE group . . . . 8 6.4.3. Bundle Address Synchronization (BAS) . . . . . . . . 8
6.4.4. Moving A Media Description Out Of A BUNDLE Group . . 8 6.4.4. Adding a media description to a BUNDLE group . . . . 8
6.4.5. Disabling A Media Description In A BUNDLE Group . . . 9 6.4.5. Moving A Media Description Out Of A BUNDLE Group . . 9
6.4.6. Disabling A Media Description In A BUNDLE Group . . . 9
6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9 6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9
6.5.1. Answerer Bundle Address Selection and Usage . . . . . 9 6.5.1. Offerer Bundle Address Selection . . . . . . . . . . 10
6.5.2. Moving A Media Description Out Of A BUNDLE Group . . 10 6.5.2. Anwerer Bundle Address Selection . . . . . . . . . . 10
6.5.3. Rejecting A Media Description In A BUNDLE Group . . . 10 6.5.3. Moving A Media Description Out Of A BUNDLE Group . . 10
6.5.4. Rejecting A Media Description In A BUNDLE Group . . . 11
7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11
8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 11 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Example: Bundle Address Selection . . . . . . . . . . . 12 10.1. Example: Bundle Address Selection . . . . . . . . . . . 13
10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14 10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14
10.3. Example: Offerer Adds A Media Description To A BUNDLE 10.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 15 Group . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.4. Example: Offerer Moves A Media Description Out Of A 10.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 17 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Example: Offerer Disables A Media Description In A 10.5. Example: Offerer Disables A Media Description In A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 18 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Design Considerations . . . . . . . . . . . . . . . 21 Appendix A. Design Considerations . . . . . . . . . . . . . . . 22
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 22 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 23
A.3. Usage of port number value zero . . . . . . . . . . . . . 23 A.3. Usage of port number value zero . . . . . . . . . . . . . 24
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 24 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 25
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 24 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 25
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 25 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 6, line 36 skipping to change at page 6, line 41
6.2.6. SDES crypto Attribute 6.2.6. SDES crypto Attribute
When SDES is used, for each RTP media "m=" line in a BUNDLE group, an When SDES is used, for each RTP media "m=" line in a BUNDLE group, an
Offerer and Answerer MUST assign an SDP crypto attribute, with unique Offerer and Answerer MUST assign an SDP crypto attribute, with unique
attribute values. attribute values.
6.2.7. Other Attributes (a=) 6.2.7. Other Attributes (a=)
There are also special rules for handling many different attributes There are also special rules for handling many different attributes
as defined in [I-D.nandakumar-mmusic-sdp-attributes]. It might not as defined in [I-D.nandakumar-mmusic-sdp-mux-attributes]. It might
possible to use bundle with some attributes. not possible to use bundle with some attributes.
6.3. RFC 5888 restrictions 6.3. RFC 5888 restrictions
Based on the rules and procedures in [RFC5888], the following Based on the rules and procedures in [RFC5888], the following
restrictions also apply to BUNDLE groups in SDP Answers: restrictions also apply to BUNDLE groups in SDP Answers:
o 1) A BUNDLE group must not be added to an SDP Answer, unless the o 1) A BUNDLE group must not be added to an SDP Answer, unless the
same BUNDLE group was included in the associated SDP Offer; and same BUNDLE group was included in the associated SDP Offer; and
o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP
Answer, unless it was in the same BUNDLE group in the associated Answer, unless it was in the same BUNDLE group in the associated
SDP Offer. SDP Offer.
6.4. SDP Offerer Procedures 6.4. SDP Offerer Procedures
6.4.1. SDP Offerer Bundle Address Request and Usage
An Offerer can assign a BUNDLE address to multiple "m=" lines in a 6.4.1. General
BUNDLE group, once the Answerer has selected the BUNDLE address for
the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple
"m=" lines until the Answerer has selected the BUNDLE address.
OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to When an Offerer generates an Offer, it assigns an address to each
multiple "m=" lines in a BUNDLE group, before the Answerer has "m=" line, according to the procedures in [RFC3264]. To each "m="
selected the BUNDLE address? line within a BUNDLE group the Offerer assigns either an address that
is unique to that "m=" line, or a shared address that is also
assigned to other "m=" lines within the BUNDLE group. Such shared
address can be, but does not have to be, a previously selected BUNDLE
address Section 6.5.1.
In order to negotiate (or, to re-negotiate) the BUNDLE address OPEN ISSUE (Q6): There is a discussion on whether assigning a shared
associated with a BUNDLE group, the Offerer, in the SDP Offer, address to multiple "m=" lines shall be allowed until the Answerer
assigns a unique address to each "m=" line in the BUNDLE group. In has indicated support of BUNDLE.
addition, the Offerer indicates which unique address it wishes the
Answerer to select as the Offerer's BUNDLE address. The Offerer
places the mid, associated with the unique address requested to be
selected as the BUNDLE address, first in the SDP group:BUNDLE
attribute mid list. The Answerer will then select the BUNDLE address
for the Offerer ([ref-to-be-added]).
If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the o (http://www.ietf.org/mail-archive/web/mmusic/current/
BUNDLE address associated with a BUNDLE group, it MAY assign the msg12245.html)
previously negotiated BUNDLE address as a unique address to one of
the "m=" lines in the BUNDLE group.
If the Offerer assigns the previously selected BUNDLE address to more The Offerer MUST NOT assign an address (unique or shared), that it
than one "m=" line in a BUNDLE group, the first mid in the SDP has assigned to an "m=" line within a BUNDLE group, to an "m=" line
group:BUNDLE attribute mid list MUST represent an "m=" line to which outside the BUNDLE group.
the BUNDLE address is assigned. Hence, in order to re-negotiate the
BUNDLE address, the Offerer needs to assign a unique address to each
"m=" line in the BUNDLE group, as described above.
An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is The Offerer MUST, for a BUNDLE group, on the SDP session level
not associated with a BUNDLE group. An Offerer MUST NOT assign a [RFC4566], insert an SDP group:BUNDLE attribute associated with the
BUNDLE address, that has been negotiated for a BUNDLE group, to an BUNDLE group. The Offerer MUST assign an SDP 'mid' attribute
"m=" line that is associated with another BUNDLE group. [RFC5888] to each "m=" line within the BUNDLE group, and place the
mid value in the group:BUNDLE attribute mid list.
The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be-
added] to one or more "m=" lines within a BUNDLE group.
OPEN ISSUE (Q8): It still needs to be decided whether a zero port
value can be assigned to a 'bundle-only' "m=" line.
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12075.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12226.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12339.html)
6.4.2. Request BUNDLE address selection
When an Offerer generates an Offer, it MUST indicate which address
(unique or shared) within a BUNDLE group it wishes the Answer to
select as the Offerer's BUNDLE address for the BUNDLE group
Section 6.5.1. The Offerer MUST do this even if the Answerer has, in
a previous Answer within the dialog, already selected the Offerer's
BUNDLE address.
In order to request an address (unique or shared) to be selected as
the Offerer's BUNDLE address for a BUNDLE group, the Offerer places
the mid value, associated with the "m=" line representing the
requested address, first in the SDP group:BUNDLE attribute mid list
associated with the BUNDLE group.
Section 10.1 shows an example of a Bundle Address Request. Section 10.1 shows an example of a Bundle Address Request.
6.4.2. Bundle Address Synchronization (BAS) 6.4.3. Bundle Address Synchronization (BAS)
When an Offerer has requested the Answerer to select the Offerer's When an Offerer receives an Answer, in which an offered BUNDLE group
BUNDLE address, and the Offerer did not assign the requested BUNDLE is accepted, if the Offerer in the associated Offer assigned an
address to each "m=" line in the BUNDLE group of the SDP Offer used address (unique or shared), that does not represent the BUNDLE
to request the BUNDLE address, when the associated SDP Answer is address selected for the Offerer, to an "m=" line within the BUNDLE
received the Offerer MUST send a subsequent SDP Offer. In the group, the Offerer MUST send a subsequent Offer, in which it assigns
subsequent SDP Offer the Offerer MUST assign the selected BUNDLE the BUNDLE address selected for the Offerer to each "m=" line within
address to each "m=" line in the BUNDLE group. This procedure is the BUNDLE group. This procedure is referred to as Bundle Address
referred to as Bundle Address Synchronization (BAS). Synchronization (BAS), and the Offer is referred to as a BAS Offer.
When the Offerer performs a BAS, the Offerer MAY modify SDP The Offerer MAY modify any SDP parameter in a BAS Offer.
parameters in the same SDP Offer.
NOTE: It is important that the SDP Offer used for the BAS gets NOTE: It is important that the BAS Offer gets accepted by the
accepted by the Answerer, so the Offerer needs to consider the Answerer, so the Offerer needs to consider the necessity to modify
necessity to modify SDP parameters that could get the Answerer to SDP parameters that could get the Answerer to reject the BAS Offer.
reject the SDP Offer. Removing "m=" lines, or reducing the number of Removing "m=" lines, or reducing the number of codecs, in the BAS
codecs, in the SDP Offer used for the BAS is considered to have a low Offer used for the is considered to have a low risk of being
risk of being rejected. rejected.
NOTE: The main purpose of the BAS is to make sure that NOTE: The main purpose of the BAS Offer is to make sure that
intermediaries, that might not support the BUNDLE mechanism, have intermediaries, that might not support the BUNDLE mechanism, have
correct information regarding which IP address and port is going to correct information regarding which address is going to be used for
be used for the bundled media. the bundled media.
Section 10.1 shows an example of an SDP Offer used to perform a BAS. Section 10.1 shows an example of an BAS Offer.
6.4.3. Adding a media description to a BUNDLE group 6.4.4. Adding a media description to a BUNDLE group
When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST When an Offerer generates an Offer, in which it adds an "m=" line to
assign either a unique address, or the BUNDLE address associated with a BUNDLE group, the Offerer assigns an address (unique or shared) to
the BUNDLE group, to the added "m=" line. In addition, the Offerer the "m=" line, assigns an SDP 'mid' attribute to the "m=" line, and
MUST assign a mid value to the "m=" line, and place the mid in the places the mid value in the group:BUNDLE attribute mid list
SDP group:BUNDLE attribute mid list associated with the BUNDLE group, associated with the BUNDLE group, according to the procedures in
in order to group the "m=" line to the BUNDLE group. Section 6.4.2. If the Offerer wishes the Answerer to select the
address assigned to the added "m=" as the Offerer's BUNDLE address,
the mid value associated with the "m=" line is placed first in the
list, according to the procedures in Section 6.4.2.
NOTE: If the Offerer assigns a unique address to the added "m=" line, Section 10.3 shows an example of an Offer used to add an "m=" line to
it allows the Answerer to move the "m=" line out of the BUNDLE group a BUNDLE group.
without having to reject the "m=" line ([ref-to-be-added]).
To the previously added "m=" lines in the BUNDLE group, the Offerer 6.4.5. Moving A Media Description Out Of A BUNDLE Group
assigns either unique addresses or the BUNDLE address associated with
the BUNDLE group, according to the procedures in Section 6.4.1.
Section 10.3 shows an example of an SDP Offer used to add an "m=" When an Offerer generates an Offer, in which an "m=" line is moved
line to a BUNDLE group. out of a BUNDLE group, the Offerer MUST assign a unique address to
the moved "m=" line. In addition, the Offerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute mid list associated with the BUNDLE group.
6.4.4. Moving A Media Description Out Of A BUNDLE Group Section 10.4 shows an example of an Offer used to move an "m=" line
out of a BUNDLE group.
When an Offerer moves an "m=" line out of a BUNDLE group, the Offerer 6.4.6. Disabling A Media Description In A BUNDLE Group
MUST assign a unique address to the moved "m=" line. In addition,
the Offerer MUST NOT anymore use a mid value to group the "m=" line
with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Offerer assigns When an Offerer generates an Offer, in which an "m=" line associated
either unique addresses or the BUNDLE address associated with the with a BUNDLE group is disabled, the Offerer MUST assign an address
BUNDLE group, according to the procedures in Section 6.4.1. with a zero port value [RFC4566] to the disabled "m=" line. In
addition, the Offerer MUST NOT anymore include a mid value,
representing the "m=" line, in the SDP group:BUNDLE attribute mid
list associated with the BUNDLE group.
Section 10.4 shows an example of an SDP Offer used to move an "m=" OPEN ISSUE (Q8): It still needs to be decided whether a zero port
line out of a BUNDLE group. value can be assigned to a 'bundle-only' "m=" line.
6.4.5. Disabling A Media Description In A BUNDLE Group o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12075.html)
When an Offerer disables an "m=" line in a BUNDLE group, the Offerer o (http://www.ietf.org/mail-archive/web/mmusic/current/
MUST assign a zero port value [RFC3264] to the disabled "m=" line. msg12226.html)
In addition, the Offerer MUST NOT anymore use a mid value to group
the "m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Offerer assigns o (http://www.ietf.org/mail-archive/web/mmusic/current/
either unique addresses or the BUNDLE address associated with the msg12339.html)
BUNDLE group, according to the procedures in Section 6.4.1.
Section 10.5 shows an example of an SDP Offer used to move an "m=" Section 10.5 shows an example of an Offer used to disable an "m="
line out of a BUNDLE group. line in a BUNDLE group.
6.5. SDP Answerer Procedures 6.5. SDP Answerer Procedures
6.5.1. Offerer Bundle Address Selection
6.5.1. Answerer Bundle Address Selection and Usage When an Answerer generates an Answer that contains a BUNDLE group,
the Answer MUST select the Offerer's BUNDLE address. The first mid
6.5.1.1. Offerer Bundle Address Selection value in the SDP group:BUNDLE attribute mid list of the Offer
represents the address which the Offerer wishes the Answer to select
If the Offerer, in an SDP Offer, assigned a unique address to each as the Offerer's BUNDLE address Section 6.4.2.
"m=" line in a BUNDLE group, it means that the Offerer has requested
the Answerer to select a BUNDLE address for the Offerer. The first
mid in the SDP group:BUNDLE attribute mid list of the SDP Offer
represents the unique address which the Offerer requests the Answer
to select as the Offerer's BUNDLE address.
The Answerer SHOULD select the unique address associated with the The Answerer SHOULD select the address represented by the first mid
first mid to become the Offerer's BUNDLE address, unless the Answerer value, unless the Answerer in the associated Answer will reject the
in the SDP Answer will move the "m=" line represented by the mid out "m=" line associated with the mid value, or remove the "m=" line from
of the BUNDLE group, or if there is some other reason why the the BUNDLE group. In such case the Answerer MUST select an address
Answerer can not select the unique address associated with the mid. associated with the first unrejected mid value that remains in the
In that case, the Answerer MUST try the next mid in the list. SDP group:BUNDLE attribute mid list of the Offer.
In the SDP Answer, the Answerer MUST place the mid associated with In the SDP Answer, the Answerer MUST place the mid value associated
the selected BUNDLE address first in the SDP group:BUNDLE attribute with the selected Offerer's BUNDLE address first in the SDP
mid list associated with the BUNDLE group. group:BUNDLE attribute mid list associated with the BUNDLE group.
Section 10.1 shows an example of an Offerer's BUNDLE address Section 10.1 shows an example of an Offerer's BUNDLE address
selection. selection.
6.5.1.2. Anwerer Bundle Address Selection 6.5.2. Anwerer Bundle Address Selection
The Answerer MUST select a local BUNDLE address, and in the SDP When an Answerer creates an Answer that contains a BUNDLE group, the
Answer assign it to each "m=" line associated with the BUNDLE group. Answerer MUST assign a local shared address, the Answerer's BUNDLE
address, to each "m=" line within the BUNDLE group.
The Answerer is allowed to change its BUNDLE address in any SDP The Answerer is allowed to change its BUNDLE address in any SDP
Answer. Answer.
The Answerer MUST NOT assign a BUNDLE address to an "m=" line that is The Answerer MUST NOT assign a shared address, that it has assigned
not associated with a BUNDLE group. The Answerer MUST NOT assign a to an "m=" line within a BUNDLE group, to an "m=" line outside the
BUNDLE address, associated with a BUNDLE group, to an "m=" line BUNDLE group.
associated with another BUNDLE group.
Section 10.1 shows an example of an Answerer's local BUNDLE address Section 10.1 shows an example of an Answerer's local BUNDLE address
selection. selection.
6.5.2. Moving A Media Description Out Of A BUNDLE Group 6.5.3. Moving A Media Description Out Of A BUNDLE Group
When an Answerer moves an "m=" line out of a BUNDLE group, the
Answerer MUST assign a unique address to the moved "m=" line. In
addition, the Answerer MUST NOT anymore use a mid value to group the
"m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Answerer assigns When an Answerer generates an Answer, in which an "m=" line is moved
the Answerer's BUNDLE address. out of a BUNDLE group, the Answerer assigns an address to the moved
"m=" line based on the type of address that the Offerer assigned to
the associated "m=" line in the associated Offer, as described below.
An Answerer MUST NOT move an "m=" line out of a BUNDLE group, unless: If the Offerer assigned a shared address to the "m=" line, the
answerer MUST reject the moved "m=" line, according to the procedures
in Section 6.5.4.
o 1) The Offerer assigned a unique address to the "m=" line in the If the Offerer assigned an SDP 'bundle-only' attribute to the "m="
associated SDP Offer; or line, the Answerer MUST reject the moved "m=" line, according to the
procedures in Section 6.5.4.
o 2) The Answerer also rejects the "m=" line Section 6.5.3. If the Offerer assigned a unique address to the "m=" line, the Answer
MUST assign a unique address to the moved "m=" line.
6.5.3. Rejecting A Media Description In A BUNDLE Group In addition, in either case above, the Answerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute list associated with the BUNDLE group.
When an Answerer rejects an "m=" line in a BUNDLE group, the Answerer 6.5.4. Rejecting A Media Description In A BUNDLE Group
MUST assign a zero port value to the rejected "m=" line. In
addition, the Answerer MUST NOT anymore use a mid value to group the
"m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Answerer assigns When an Answerer generates an Answer, in which an "m=" line
the Answerer's BUNDLE address. associated with a BUNDLE group is rejected, the Answerer MUST assign
an address with a zero port value to the rejected "m=" line,
according to the procedures in [RFC4566]. In addition, the Answerer
MUST NOT anymore include a mid value, representing the "m=" line, in
the SDP group:BUNDLE attribute midlist associated with the BUNDLE
group.
7. Single vs Multiple RTP Sessions 7. Single vs Multiple RTP Sessions
7.1. General 7.1. General
By default, all RTP based media flows within a given BUNDLE group By default, all RTP based media flows within a given BUNDLE group
belong to a single RTP session [RFC3550]. Multiple BUNDLE groups belong to a single RTP session [RFC3550]. Multiple BUNDLE groups
will form multiple RTP Sessions. will form multiple RTP Sessions.
The usage of multiple RTP Sessions within a given BUNDLE group, or The usage of multiple RTP Sessions within a given BUNDLE group, or
skipping to change at page 11, line 28 skipping to change at page 11, line 49
7.2. Single RTP Session 7.2. Single RTP Session
When a single RTP Session is used, media associated with all "m=" When a single RTP Session is used, media associated with all "m="
lines part of a bundle group share a single SSRC [RFC3550] numbering lines part of a bundle group share a single SSRC [RFC3550] numbering
space. space.
In addition, the following rules and restrictions apply for a single In addition, the following rules and restrictions apply for a single
RTP Session: RTP Session:
o - The dynamic payload type values used in the "m=" lines MUST NOT o The dynamic payload type values used in the "m=" lines MUST NOT
overlap. overlap.
o - The "proto" value in each "m=" line MUST be identical (e.g. RTP/ o The "proto" value in each "m=" line MUST be identical (e.g. RTP/
AVPF). 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 "m=" lines. that originates from different "m=" lines.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap RTP and RTCP fails to function. Even if done in with time overlap RTP and RTCP fails to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues [ref proper sequence this causes RTP Timestamp rate switching issues [ref
to draft-ietf-avtext-multiple-clock-rates]. to draft-ietf-avtext-multiple-clock-rates].
8. Usage With ICE 8. Usage With ICE
skipping to change at page 13, line 11 skipping to change at page 13, line 31
o 2. An SDP Answer, in which the Answerer selects the BUNDLE o 2. An SDP Answer, in which the Answerer selects the BUNDLE
address for the Offerer, and assigns its own local BUNDLE address address for the Offerer, and assigns its own local BUNDLE address
to each "m=" line in the BUNDLE group. to each "m=" line in the BUNDLE group.
o 3. A subsequent SDP Offer, which is used to perform a Bundle o 3. A subsequent SDP Offer, which is used to perform a Bundle
Address Synchronization (BAS). Address Synchronization (BAS).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
skipping to change at page 13, line 29 skipping to change at page 14, line 4
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Offer (3) SDP Offer (3)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
skipping to change at page 14, line 33 skipping to change at page 15, line 8
o 1. An SDP Offer, in which the Offerer assigns unique addresses to o 1. An SDP Offer, in which the Offerer assigns unique addresses to
each "m=" line in the BUNDLE group, and requests the Answerer to each "m=" line in the BUNDLE group, and requests the Answerer to
select the Offerer's BUNDLE address. select the Offerer's BUNDLE address.
o 2. An SDP Answer, in which the Answerer rejects the BUNDLE group, o 2. An SDP Answer, in which the Answerer rejects the BUNDLE group,
and assigns unique addresses to each "m=" line. and assigns unique addresses to each "m=" line.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
10.3. Example: Offerer Adds A Media Description To A BUNDLE Group 10.3. Example: Offerer Adds A Media Description To A BUNDLE Group
skipping to change at page 15, line 39 skipping to change at page 16, line 15
o 2. An SDP Answer, in which the Answerer assigns its own local o 2. An SDP Answer, in which the Answerer assigns its own local
BUNDLE address to each "m=" line (including the added "m=" line) BUNDLE address to each "m=" line (including the added "m=" line)
in the BUNDLE group. in the BUNDLE group.
o 3. A subsequent SDP Offer, which is used to perform a Bundle o 3. A subsequent SDP Offer, which is used to perform a Bundle
Address Synchronization (BAS). Address Synchronization (BAS).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
skipping to change at page 16, line 18 skipping to change at page 16, line 39
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
a=mid:zen a=mid:zen
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
a=mid:zen a=mid:zen
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Offer (3) SDP Offer (3)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
skipping to change at page 17, line 31 skipping to change at page 18, line 8
address to the remaining "m=" lines in the BUNDLE group. address to the remaining "m=" lines in the BUNDLE group.
o 2. An SDP Answer, in which the Answerer moves the corresponding o 2. An SDP Answer, in which the Answerer moves the corresponding
"m=" line out of the BUNDLE group, and assigns unique address to "m=" line out of the BUNDLE group, and assigns unique address to
the moved "m=" line, and assigns the previously negotiated BUNDLE the moved "m=" line, and assigns the previously negotiated BUNDLE
address to the remaining "m=" lines in the BUNDLE group. address to the remaining "m=" lines in the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 50000 RTP/AVP 66 m=video 50000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
skipping to change at page 18, line 46 skipping to change at page 19, line 24
o 2. An SDP Answer, in which the Answerer moves the corresponding o 2. An SDP Answer, in which the Answerer moves the corresponding
"m=" line out of the BUNDLE group, and assigns a zero port value "m=" line out of the BUNDLE group, and assigns a zero port value
to the moved "m=" line in order to disable it, and assigns the to the moved "m=" line in order to disable it, and assigns the
previously negotiated BUNDLE address to the remaining "m=" lines previously negotiated BUNDLE address to the remaining "m=" lines
in the BUNDLE group. in the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
skipping to change at page 20, line 21 skipping to change at page 20, line 39
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.
13. Change Log 13. 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-04
o Updated Offerer procedures (http://www.ietf.org/mail-archive/web/
mmusic/current/msg12293.html).
o Updated Answerer procedures (http://www.ietf.org/mail-archive/web/
mmusic/current/msg12333.html).
o Usage of SDP 'bundle-only' attribute added.
o Reference to Trickle ICE document added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
o Mechanism modified, to be based on usage of SDP Offers with both o Mechanism modified, to be based on usage of SDP Offers with both
different and identical port number values, depending on whether different and identical port number values, depending on whether
it is known if the remote endpoint supports the extension. it is known if the remote endpoint supports the extension.
o Cullen Jennings added as co-author. o Cullen Jennings added as co-author.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
skipping to change at page 21, line 22 skipping to change at page 22, line 8
[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, July 2006.
[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.nandakumar-mmusic-sdp-attributes] [I-D.nandakumar-mmusic-sdp-mux-attributes]
Nandakumar, S. and C. Jennings, "A Framework for SDP Nandakumar, S. and C. Jennings, "A Framework for SDP
Attributes when Multiplexing", draft-nandakumar-mmusic- Attributes when Multiplexing ", draft-nandakumar-mmusic-
sdp-attributes-00 (work in progress), February 2013. sdp-mux-attributes-04 (work in progress), September 2013.
14.2. Informative References 14.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.
[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, April
2010. 2010.
[I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol ", draft-ietf-
mmusic-trickle-ice-00 (work in progress), October 2013.
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 number been whether, in SDP Offers and SDP Answers, the same port number
value should be inserted in "m=" lines associated with a BUNDLE value should be inserted in "m=" lines associated with a BUNDLE
group, as the purpose of the extension is to negotiate the usage of a group, as the purpose of the extension is to negotiate the usage of a
single 5-tuple for media associated with the "m=" lines. Issues with single 5-tuple for media associated with the "m=" lines. Issues with
both approaches, discussed in the Appendix have been raised. The both approaches, discussed in the Appendix have been raised. The
skipping to change at page 22, line 32 skipping to change at page 23, line 23
Appendix might be removed. Appendix might be removed.
A.2. UA Interoperability A.2. UA Interoperability
Consider the following SDP Offer/Answer exchange, where Alice sends Consider the following SDP Offer/Answer exchange, where Alice sends
an SDP Offer to Bob: an SDP Offer to Bob:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97 m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 97 m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97 m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
RFC 4961 specifies a way of doing symmetric RTP but that is an a RFC 4961 specifies a way of doing symmetric RTP but that is an a
later invention to RTP and Bob can not assume that Alice supports RFC later invention to RTP and Bob can not assume that Alice supports RFC
4961. This means that Alice may be sending RTP from a different port 4961. This means that Alice may be sending RTP from a different port
than 10000 or 10002 - some implementation simply send the RTP from an than 10000 or 10002 - some implementation simply send the RTP from an
skipping to change at page 23, line 26 skipping to change at page 24, line 18
is by looking at the port it was received on. This lead some SDP is by looking at the port it was received on. This lead some SDP
implementations to use the fact that each "m=" line had a different implementations to use the fact that each "m=" line had a different
port number to use that port number as an index to find the correct m port number to use that port number as an index to find the correct m
line in the SDP. As a result, some implementations that do support line in the SDP. As a result, some implementations that do support
symmetric RTP and ICE still use a SDP data structure where SDP with symmetric RTP and ICE still use a SDP data structure where SDP with
"m=" lines with the same port such as: "m=" lines with the same port such as:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98 m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000 a=rtpmap:98 H261/90000
will result in the second "m=" line being considered an SDP error will result in the second "m=" line being considered an SDP error
because it has the same port as the first line. because it has the same port as the first line.
A.3. Usage of port number value zero A.3. Usage of port number value zero
skipping to change at page 24, line 28 skipping to change at page 25, line 19
understand, the B2BUS still generates that SDP attribute in the Offer understand, the B2BUS still generates that SDP attribute in the Offer
for the outgoing call leg. Consider an B2BUA that did not understand for the outgoing call leg. Consider an B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this cases, if the where it did not see any RTCP for 5 minutes. In this cases, if the
B2BUA received an Offer like: B2BUA received an Offer like:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtcp:53020 a=rtcp:53020
It would be looking for RTCP on port 49172 but would not see any It would be looking for RTCP on port 49172 but would not see any
because the RTCP would be on port 53020 and after five minutes, it because the RTCP would be on port 53020 and after five minutes, it
would tear down the call. Similarly, an SBC that did not understand would tear down the call. Similarly, an SBC that did not understand
BUNDLE yet put BUNDLE in it's offer may be looking for media on the BUNDLE yet put BUNDLE in it's offer may be looking for media on the
wrong port and tear down the call. It is worth noting that a B2BUA wrong port and tear down the call. It is worth noting that a B2BUA
that generated an Offer with capabilities it does not understand is that generated an Offer with capabilities it does not understand is
skipping to change at page 25, line 27 skipping to change at page 26, line 18
bandwidth. That may either simply lead to bad user experience, or to bandwidth. That may either simply lead to bad user experience, or to
termination of the call. termination of the call.
A.5. Candidate Gathering A.5. Candidate Gathering
When using ICE, an candidate needs to be gathered for each port. When using ICE, an candidate needs to be gathered for each port.
This takes approximately 20 ms extra for each extra "m=" line due to This takes approximately 20 ms extra for each extra "m=" line due to
the NAT pacing requirements. All of this gather can be overlapped the NAT pacing requirements. All of this gather can be overlapped
with other things while the page is loading to minimize the impact. with other things while the page is loading to minimize the impact.
If the client only wants to generate TURN or STUN ICE candidates for If the client only wants to generate TURN or STUN ICE candidates for
one of the "m=" lines and then use trickle ICE [TODO REF] to get the one of the "m=" lines and then use trickle ICE
non host ICE candidates for the rest of the "m=" lines, it MAY do [I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for
that and will not need any additional gathering time. the rest of the "m=" lines, it MAY do that and will not need any
additional gathering time.
Some people have suggested a TURN extension to get a bunch of TURN Some people have suggested a TURN extension to get a bunch of TURN
allocation at once. This would only provide a single STUN result so allocation at once. This would only provide a single STUN result so
in cases where the other end did not support BUNDLE, may cause more in cases where the other end did not support BUNDLE, may cause more
use of the TURN server but would be quick in the cases where both use of the TURN server but would be quick in the cases where both
sides supported BUNDLE and would fall back to a successful call in sides supported BUNDLE and would fall back to a successful call in
the other cases. the other cases.
Authors' Addresses Authors' Addresses
 End of changes. 99 change blocks. 
209 lines changed or deleted 251 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/