draft-ietf-mmusic-sdp-bundle-negotiation-27.txt   draft-ietf-mmusic-sdp-bundle-negotiation-28.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: August 27, 2016 C. Jennings Expires: October 16, 2016 C. Jennings
Cisco Cisco
February 24, 2016 April 14, 2016
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-27.txt draft-ietf-mmusic-sdp-bundle-negotiation-28.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
To assist endpoints in negotiating the use of bundle this To assist endpoints in negotiating the use of bundle this
specification defines a new SDP attribute, 'bundle-only', which can specification defines a new SDP attribute, 'bundle-only', which can
be used to request that specific media is only used if bundled. be used to request that specific media is only used if bundled.
There are multiple ways to correlate the bundled RTP packets with the There are multiple ways to correlate the bundled RTP packets with the
appropriate media descriptions. This specification defines a new appropriate media descriptions. This specification defines a new
Real-time Transport Protocol (RTP) source description (SDES) item and Real-time Transport Protocol (RTP) source description (SDES) item and
a new RTP header extension that provides an additional way to do this a new RTP header extension that provides an additional way to do this
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2016. This Internet-Draft will expire on October 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7
7. SDP Information Considerations . . . . . . . . . . . . . . . 8 7. SDP Information Considerations . . . . . . . . . . . . . . . 8
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 8.2. Mux Category Considerations . . . . . . . . . . . . . . . 10
8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.3. Generating the Initial SDP Offer . . . . . . . . . . . . 10
8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 8.3.2. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 8.4. Generating the SDP Answer . . . . . . . . . . . . . . . . 11
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 8.4.2. Answerer Selection of Offerer Bundle Address . . . . 12
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13 8.4.3. Answerer Selection of Answerer BUNDLE Address . . . . 13
8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 8.4.4. Moving A Media Description Out Of A BUNDLE Group . . 13
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 8.4.5. Rejecting A Media Description In A BUNDLE Group . . . 14
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 8.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.6. Modifying the Session . . . . . . . . . . . . . . . . . . 14
8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 14 8.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.5.3. Adding a media description to a BUNDLE group . . . . 15 8.6.2. Suggesting a new offerer BUNDLE address . . . . . . . 15
8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16 8.6.3. Adding a media description to a BUNDLE group . . . . 15
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16 8.6.4. Moving A Media Description Out Of A BUNDLE Group . . 16
8.6.5. Disabling A Media Description In A BUNDLE Group . . . 16
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
13.3. New text replacing section 5.1 (2nd paragraph) of RFC 13.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26
13.5. New text replacing section 8.2 (2nd paragraph) of RFC 13.5. New text replacing section 8.2 (2nd paragraph) of RFC
skipping to change at page 4, line 25 skipping to change at page 4, line 27
A.3. Usage of port number value zero . . . . . . . . . . . . . 50 A.3. Usage of port number value zero . . . . . . . . . . . . . 50
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 50 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 50
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 51 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 51
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 51 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 51
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 52 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media specified by
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a
BUNDLE address is used for receiving media associated with multiple BUNDLE address is used for receiving media specified by multiple "m="
"m=" lines. This is referred to as bundled media. lines. This is referred to as bundled media.
The offerer and answerer [RFC3264] use the BUNDLE extension to The offerer and answerer [RFC3264] use the BUNDLE extension to
negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE negotiate the 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 receiving the bundled media associated with a BUNDLE group. used for receiving the bundled media specified by a BUNDLE group.
Once the offerer and the answerer have negotiated a BUNDLE group, Once the offerer and the answerer have negotiated a BUNDLE group,
they associate their respective BUNDLE address with each "m=" line in they associate their respective BUNDLE address with each "m=" line in
the BUNDLE group. The BUNDLE addresses are used to receive all media the BUNDLE group. The BUNDLE addresses are used to receive all media
associated with the BUNDLE group. specified by the BUNDLE group.
The use of a BUNDLE group and a BUNDLE address also allows the usage The use of a BUNDLE group and a BUNDLE address also allows the usage
of a single set of Interactive Connectivity Establishment (ICE) of a single set of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] candidates for multiple "m=" lines. [I-D.ietf-ice-rfc5245bis] candidates for multiple "m=" lines.
This specification also defines a new SDP attribute, 'bundle-only', This specification also defines a new SDP attribute, 'bundle-only',
which can be used to request that specific media is only used if kept which can be used to request that specific media is only used if kept
within a BUNDLE group. within a BUNDLE group.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same As defined in RFC 4566 [RFC4566], the semantics of assigning the same
skipping to change at page 5, line 25 skipping to change at page 5, line 25
This specification also defines a new Real-time Transport Protocol This specification also defines a new Real-time Transport Protocol
(RTP) [RFC3550] source description (SDES) item and a new RTP header (RTP) [RFC3550] source description (SDES) item and a new RTP header
extension that can be used to carry a value that associates RTP/RTCP extension that can be used to carry a value that associates RTP/RTCP
packets with a specific media description. This can be used to packets with a specific media description. This can be used to
correlate a RTP packet with the correct media. correlate a RTP packet with the correct media.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. The address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given procedures in this specification apply independently to a given
BUNDLE group. All RTP based media flows associated with a single BUNDLE group. All RTP based media flows described by a single BUNDLE
BUNDLE group belong to a single RTP session [RFC3550]. group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to without an SDP 'group:BUNDLE' attribute, and are expected to
associate a unique address with each "m=" line within an offer and associate a unique address with each "m=" line within an offer and
answer, according to the procedures in [RFC4566] and [RFC3264] answer, according to the procedures in [RFC4566] and [RFC3264]
2. Terminology 2. Terminology
"m=" line: SDP bodies contain one or more media descriptions. Each "m=" line: SDP bodies contain one or more media descriptions. Each
skipping to change at page 6, line 10 skipping to change at page 6, line 10
with multiple "m=" lines within an offer or answer. with multiple "m=" lines within an offer or answer.
Offerer BUNDLE-tag: The first identification-tag in a given SDP Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
Answerer BUNDLE-tag: The first identification-tag in a given SDP Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
Offerer BUNDLE address: Within a given BUNDLE group, an IP address Offerer BUNDLE address: Within a given BUNDLE group, an IP address
and port combination used by an offerer to receive all media and port combination used by an offerer to receive all media
associated with each "m=" line within the BUNDLE group. specified by 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 port combination used by an answerer to receive all media and port combination used by an answerer to receive all media
associated with each "m=" line within the BUNDLE group. specified by 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, which uses the same BUNDLE address for receiving media. exchange, which uses the same BUNDLE address for receiving media.
Bundled "m=" line: An "m=" line, whose identification-tag is placed Bundled "m=" line: An "m=" line, whose identification-tag is placed
in an SDP 'group:BUNDLE' attribute identification-tag list in an in an SDP 'group:BUNDLE' attribute identification-tag list in an
offer or answer. offer or answer.
Bundle-only "m=" line: A bundled "m=" line with an associated SDP Bundle-only "m=" line: A bundled "m=" line with an associated SDP
'bundle-only' attribute. 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. Bundled media: All media specified by a given BUNDLE group.
Initial offer: The first offer, within an SDP session (e.g. a SIP Initial offer: The first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used dialog when the Session Initiation Protocol (SIP) [RFC3261] is used
to carry SDP), in which the offerer indicates that it wants to create to carry SDP), in which the offerer indicates that it wants to create
a given BUNDLE group. a given BUNDLE group.
Subsequent offer: An offer which contains a BUNDLE group that has Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous offer/answer exchange. been created as part of a previous offer/answer exchange.
Identification-tag: A unique token value that is used to identify an Identification-tag: A unique token value that is used to identify an
skipping to change at page 7, line 25 skipping to change at page 7, line 25
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate the usage of a single Offer/Answer mechanism to negotiate the usage of a single
address:port combination (BUNDLE address) for receiving bundled address:port combination (BUNDLE address) for receiving bundled
media. media.
A single address:port combination is also used for sending bundled A single address:port combination is also used for sending bundled
media. The address:port combination used for sending bundled media media. The address:port combination used for sending bundled media
MAY be the same as the BUNDLE address, used to receive bundled media, MAY be the same as the BUNDLE address, used to receive bundled media,
depending on whether symmetric RTP [RFC4961] is used. depending on whether symmetric RTP [RFC4961] is used.
All media associated with a BUNDLE group share a single 5-tuple, i.e. All media specified by a BUNDLE group share a single 5-tuple, i.e. in
in addition to using a single address:port combination all bundled addition to using a single address:port combination all bundled media
media MUST be transported using the same transport-layer protocol MUST be transported using the same transport-layer protocol (e.g.
(e.g. UDP or TCP). UDP or TCP).
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An identification-tag is a "BUNDLE" semantics value [RFC5888]. An identification-tag is
associated with each bundled "m=" line, and each identification-tag associated with each bundled "m=" line, and each identification-tag
is listed in the SDP 'group:BUNDLE' attribute identification-tag is listed in the SDP 'group:BUNDLE' attribute identification-tag
list. Each "m=" line whose identification-tag is listed in the list. Each "m=" line whose identification-tag is listed in the
identification-tag list is associated with a given BUNDLE group. identification-tag list is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" line MUST NOT be associated with more than one BUNDLE group. "m=" line MUST NOT be associated with more than one BUNDLE group.
skipping to change at page 10, line 13 skipping to change at page 10, line 13
apply. Hence, if an offerer generates an offer in which the offerer apply. Hence, if an offerer generates an offer in which the offerer
wants to create a BUNDLE group, and the answerer rejects the offer, wants to create a BUNDLE group, and the answerer rejects the offer,
the BUNDLE group is not created. the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value represented by a bundled "m=" line. Section 10 "m=" line proto value represented by a bundled "m=" line. Section 10
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism . [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.2. Generating the Initial SDP Offer 8.2. Mux Category Considerations
8.2.1. General When an offerer associates a shared address with a bundled "m=" line,
the offerer shall associate IDENTICAL and TRANSPORT mux category SDP
attributes [I-D.ietf-mmusic-sdp-mux-attributes] with the "m=" line
only if the "m=" line is associated with the offerer BUNDLE-tag.
Otherwise the offerer MUST NOT associate such SDP attributes with the
"m=" line.
When an answerer associates a shared address with a bundled "m="
line, the answerer shall associate IDENTICAL and TRANSPORT category
SDP attributes with the "m=" line only if the "m=" line is associated
with the answerer BUNDLE-tag. Otherwise the answerer MUST NOT
associate such SDP attributes with the "m=" line.
NOTE: As bundled "m=" lines associated with a shared address will
share the same IDENTICAL and TRANSPORT mux category SDP attributes,
and attribute values, there is no need to associate such SDP
attributes with each "m=" line.
8.3. Generating the Initial SDP Offer
8.3.1. General
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address to each "m=" line within the offer, o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264], unless the media line is a following the procedures in [RFC3264], unless the media line is a
'bundle-only' "m=" line (see below); and 'bundle-only' "m=" line (see below); and
o Add an SDP 'group:BUNDLE' attribute to the offer; and o Add an SDP 'group:BUNDLE' attribute to the offer; and
o Place the identification-tag of each bundled "m=" line in the SDP o Place the identification-tag of each bundled "m=" line in the SDP
'group:BUNDLE' attribute identification-tag list; and 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address the offerer suggests as the offerer o Indicate which unique address the offerer suggests as the offerer
BUNDLE address [Section 8.2.2]. BUNDLE address [Section 8.3.2].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
bundled "m=" line only if the answerer keeps the "m=" line within the bundled "m=" line only if the answerer keeps the "m=" line within the
BUNDLE group, the offerer MUST: BUNDLE group, the offerer MUST:
o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the o Associate an SDP 'bundle-only' attribute [Section 8.3.2] with the
"m=" line; and "m=" line; and
o Assign a zero port value to the "m=" line. o Assign a zero port value to the "m=" line.
NOTE: If the offerer assigns a zero port value to an "m=" line, but NOTE: If the offerer assigns a zero port value to an "m=" line, but
does not also associate an SDP 'bundle-only' attribute with the "m=" does not also associate an SDP 'bundle-only' attribute with the "m="
line, it is an indication that the offerer wants to disable the "m=" line, it is an indication that the offerer wants to disable the "m="
line [Section 8.5.5]. line [Section 8.6.5].
[Section 17.1] shows an example of an initial offer. [Section 17.1] shows an example of an initial offer.
8.2.2. Suggesting the offerer BUNDLE address 8.3.2. Suggesting the offerer BUNDLE address
In the offer, the address associated with the "m=" line associated In the offer, the address associated with the "m=" line associated
with the offerer BUNDLE-tag indicates the address that the offerer with the offerer BUNDLE-tag indicates the address that the offerer
suggests as the offerer BUNDLE address. suggests as the offerer BUNDLE address.
The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain
a zero port value or an SDP 'bundle-only' attribute. a zero port value or an SDP 'bundle-only' attribute.
8.3. Generating the SDP Answer 8.4. Generating the SDP Answer
8.3.1. General 8.4.1. General
When an answerer generates an answer that contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group,
the following general SDP grouping framework restrictions, defined in the following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group: [RFC5888], also apply to the BUNDLE group:
o The answerer MUST NOT include a BUNDLE group in the answer, unless o The answerer MUST NOT include a BUNDLE group in the answer, unless
the offerer requested the BUNDLE group to be created in the the offerer requested the BUNDLE group to be created in the
associated offer; and corresponding offer; and
o The answerer MUST NOT include an "m=" line within a BUNDLE group, o The answerer MUST NOT include an "m=" line within a BUNDLE group,
unless the offerer requested the "m=" line to be within that unless the offerer requested the "m=" line to be within that
BUNDLE group in the associated offer. BUNDLE group in the corresponding offer.
If the answer contains a BUNDLE group, the answerer MUST: If the answer contains a BUNDLE group, the answerer MUST:
o Select an Offerer BUNDLE Address [Section 8.3.2]; and o Select an Offerer BUNDLE Address [Section 8.4.2]; and
o Select an Answerer BUNDLE Address [Section 8.3.3]; o Select an Answerer BUNDLE Address [Section 8.4.3];
The answerer is allowed to select a new Answerer BUNDLE address each The answerer is allowed to select a new Answerer BUNDLE address each
time it generates an answer to an offer. time it generates an answer to an offer.
If the answerer does not want to keep an "m=" line within a BUNDLE If the answerer does not want to keep an "m=" line within a BUNDLE
group, it MUST: group, it MUST:
o Move the "m=" line out of the BUNDLE group [Section 8.3.4]; or o Move the "m=" line out of the BUNDLE group [Section 8.4.4]; or
o Reject the "m=" line [Section 8.3.5]; o Reject the "m=" line [Section 8.4.5];
If the answerer keeps a bundle-only "m=" line within the BUNDLE If the answerer keeps a bundle-only "m=" line within the BUNDLE
group, it follows the procedures (associates the answerer BUNDLE group, it follows the procedures (associates the answerer BUNDLE
address with the "m=" line etc) for any other "m=" line kept within address with the "m=" line etc) for any other "m=" line kept within
the BUNDLE group. the BUNDLE group.
If the answerer does not want to keep a bundle-only "m=" line within If the answerer does not want to keep a bundle-only "m=" line within
the BUNDLE group, it MUST reject the "m=" line [Section 8.3.5]. the BUNDLE group, it MUST reject the "m=" line [Section 8.4.5].
The answerer MUST NOT associate an SDP 'bundle-only' attribute with The answerer MUST NOT associate an SDP 'bundle-only' attribute with
any "m=" line in an answer. any "m=" line in an answer.
NOTE: If a bundled "m=" line in an offer contains a zero port value, NOTE: If a bundled "m=" line in an offer contains a zero port value,
but the "m=" line does not contain an SDP 'bundle-only' attribute, it but the "m=" line does not contain an SDP 'bundle-only' attribute, it
is an indication that the offerer wants to disable the "m=" line is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5]. [Section 8.6.5].
8.3.2. Answerer Selection of Offerer Bundle Address 8.4.2. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) associated with the In an offer, the address (unique or shared) associated with the
bundled "m=" line associated with the offerer BUNDLE-tag indicates bundled "m=" line associated with the offerer BUNDLE-tag indicates
the address that the offerer suggests as the offerer BUNDLE address the address that the offerer suggests as the offerer BUNDLE address
[Section 8.2.2]. The answerer MUST check whether that "m=" line [Section 8.3.2]. The answerer MUST check whether that "m=" line
fulfils the following criteria: fulfils the following criteria:
o The answerer will not move the "m=" line out of the BUNDLE group o The answerer will not move the "m=" line out of the BUNDLE group
[Section 8.3.4]; and [Section 8.4.4]; and
o The answerer will not reject the "m=" line [Section 8.3.5]; and o The answerer will not reject the "m=" line [Section 8.4.5]; and
o The "m=" line does not contain a zero port value. o The "m=" line does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the address associated with the "m=" line as the offerer BUNDLE the address associated with the "m=" line as the offerer BUNDLE
address. In the answer, the answerer BUNDLE-tag represents the "m=" address. In the answer, the answerer BUNDLE-tag represents the "m="
line, and the address associated with the "m=" line in the offer line, and the address associated with the "m=" line in the offer
becomes the offerer BUNDLE address. becomes the offerer BUNDLE address.
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
select the next identification-tag in the identification-tag list, select the next identification-tag in the identification-tag list,
and perform the same criteria check for the "m=" line associated with and perform the same criteria check for the "m=" line associated with
that identification-tag. If there are no more identification-tags in that identification-tag. If there are no more identification-tags in
the identification-tag list, the answerer MUST NOT create the BUNDLE the identification-tag list, the answerer MUST NOT create the BUNDLE
group. In addition, unless the answerer rejects the whole offer, the group. In addition, unless the answerer rejects the whole offer, the
answerer MUST apply the answerer procedures for moving an "m=" line answerer MUST apply the answerer procedures for moving an "m=" line
out of a BUNDLE group [Section 8.3.4] to each bundled "m=" line in out of a BUNDLE group [Section 8.4.4] to each bundled "m=" line in
the offer when creating the answer. the offer when creating the answer.
[Section 17.1] shows an example of an offerer BUNDLE address [Section 17.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.3. Answerer Selection of Answerer BUNDLE Address 8.4.3. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST associate that address with each the answerer BUNDLE address, it MUST associate that address with each
bundled "m=" line within the created BUNDLE group in the answer. bundled "m=" line within the created BUNDLE group in the answer.
The answerer MUST NOT associate the answerer BUNDLE address with an The answerer MUST NOT associate the answerer BUNDLE address with an
"m=" line that is not within the BUNDLE group, or to an "m=" line "m=" line that is not within the BUNDLE group, or to an "m=" line
that is within another BUNDLE group. that is within another BUNDLE group.
[Section 17.1] shows an example of an answerer BUNDLE address [Section 17.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.4. Moving A Media Description Out Of A BUNDLE Group 8.4.4. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move an "m=" line out of a BUNDLE group, it When an answerer wants to move an "m=" line out of a BUNDLE group, it
MUST first check the following criteria: MUST first check the following criteria:
o In the associated offer, the "m=" line is associated with a shared o In the corresponding offer, the "m=" line is associated with a
address (e.g. a previously selected offerer BUNDLE address); or shared address (e.g. a previously selected offerer BUNDLE
address); or
o In the associated offer, if an SDP 'bundle-only' attribute is o In the corresponding offer, if an SDP 'bundle-only' attribute is
associated with the "m=" line, and if the "m=" line contains a associated with the "m=" line, and if the "m=" line contains a
zero port value. zero port value.
If either criteria above is fulfilled, the answerer MUST reject the If either criteria above is fulfilled, the answerer MUST reject the
"m=" line [Section 8.3.5]. "m=" line [Section 8.4.5].
Otherwise, if in the associated offer the "m=" line is associated Otherwise, if in the corresponding offer the "m=" line is associated
with a unique address, the answerer MUST associate a unique address with a unique address, the answerer MUST associate a unique address
with the "m=" line in the answer (the answerer does not reject the with the "m=" line in the answer (the answerer does not reject the
"m=" line). "m=" line).
In addition, in either case above, the answerer MUST NOT place the In addition, in either case above, the answerer MUST NOT place the
identification-tag, associated with the moved "m=" line, in the SDP identification-tag, associated with the moved "m=" line, in the SDP
'group' attribute identification-tag list associated with the BUNDLE 'group' attribute identification-tag list associated with the BUNDLE
group. group.
8.3.5. Rejecting A Media Description In A BUNDLE Group 8.4.5. Rejecting A Media Description In A BUNDLE Group
When an answerer rejects an "m=" line, it MUST associate an address When an answerer rejects an "m=" line, it MUST associate an address
with a zero port value with the "m=" line in the answer, according to with a zero port value with the "m=" line in the answer, according to
the procedures in [RFC4566]. the procedures in [RFC4566].
In addition, the answerer MUST NOT place the identification-tag, In addition, the answerer MUST NOT place the identification-tag,
associated with the rejected "m=" line, in the SDP 'group' attribute associated with the rejected "m=" line, in the SDP 'group' attribute
identification-tag list associated with the BUNDLE group. identification-tag list associated with the BUNDLE group.
8.4. Offerer Processing of the SDP Answer 8.5. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" line in the group, the offerer MUST check that any bundled "m=" line in the
answer was indicated as bundled in the associated offer. If there is answer was indicated as bundled in the corresponding offer. If there
no mismatch, the offerer MUST use the offerer BUNDLE address, is no mismatch, the offerer MUST use the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], as the address for each selected by the answerer [Section 8.4.2], as the address for each
bundled "m=" line. bundled "m=" line.
NOTE: As the answerer might reject one or more bundled "m=" lines, or NOTE: As the answerer might reject one or more bundled "m=" lines, or
move a bundled "m=" line out of a BUNDLE group, each bundled "m=" move a bundled "m=" line out of a BUNDLE group, each bundled "m="
line in the offer might not be indicated as bundled in the answer. line in the offer might not be indicated as bundled in the answer.
If the answer does not contain a BUNDLE group, the offerer MUST If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer. process the answer as a normal answer.
8.5. Modifying the Session 8.6. Modifying the Session
8.5.1. General 8.6.1. General
When an offerer generates a subsequent offer, it MUST associate the When an offerer generates a subsequent offer, it MUST associate the
previously selected offerer BUNDLE address [Section 8.3.2] with each previously selected offerer BUNDLE address [Section 8.4.2] with each
bundled "m=" line (including any bundle-only "m=" line), except if: bundled "m=" line (including any bundle-only "m=" line), except if:
o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; o The offerer suggests a new offerer BUNDLE address [Section 8.6.2];
or or
o The offerer wants to add a bundled "m=" line to the BUNDLE group o The offerer wants to add a bundled "m=" line to the BUNDLE group
[Section 8.5.3]; or [Section 8.6.3]; or
o The offerer wants to move a bundled "m=" line out of the BUNDLE o The offerer wants to move a bundled "m=" line out of the BUNDLE
group [Section 8.5.4]; or group [Section 8.6.4]; or
o The offerer wants to disable the bundled "m=" line o The offerer wants to disable the bundled "m=" line
[Section 8.5.5]. [Section 8.6.5].
In addition, the offerer MUST select an offerer BUNDLE-tag In addition, the offerer MUST select an offerer BUNDLE-tag
[Section 8.2.2] associated with the previously selected offerer [Section 8.3.2] associated with the previously selected offerer
BUNDLE address, unless the offerer suggests a new offerer BUNDLE BUNDLE address, unless the offerer suggests a new offerer BUNDLE
address. address.
8.5.2. Suggesting a new offerer BUNDLE address 8.6.2. Suggesting a new offerer BUNDLE address
When an offerer generates an offer, in which it suggests a new When an offerer generates an offer, in which it suggests a new
offerer BUNDLE address [Section 8.2.2], the offerer MUST: offerer BUNDLE address [Section 8.3.2], the offerer MUST:
o Assign the address (shared address) to each "m=" line within the o Assign the address (shared address) to each "m=" line within the
BUNDLE group; or BUNDLE group; or
o Assign the address (unique address) to one bundled "m=" line. o Assign the address (unique address) to one bundled "m=" line.
In addition, the offerer MUST indicate that the address is the new In addition, the offerer MUST indicate that the address is the new
suggested offerer BUNDLE address [Section 8.2.2]. suggested offerer BUNDLE address [Section 8.3.2].
NOTE: Unless the offerer associates the new suggested offerer BUNDLE NOTE: Unless the offerer associates the new suggested offerer BUNDLE
address with each bundled "m=" line, it can associate unique address with each bundled "m=" line, it can associate unique
addresses with any number of bundled "m=" lines (and the previously addresses with any number of bundled "m=" lines (and the previously
selected offerer BUNDLE address to any remaining bundled "m=" line) selected offerer BUNDLE address to any remaining bundled "m=" line)
if it wants to suggest multiple alternatives for the new offerer if it wants to suggest multiple alternatives for the new offerer
BUNDLE address. BUNDLE address.
8.5.3. Adding a media description to a BUNDLE group 8.6.3. Adding a media description to a BUNDLE group
When an offerer generates an offer, in which it wants to add a When an offerer generates an offer, in which it wants to add a
bundled "m=" line to a BUNDLE group, the offerer MUST: bundled "m=" line to a BUNDLE group, the offerer MUST:
o Assign a unique address to the added "m=" line; or o Assign a unique address to the added "m=" line; or
o Assign the previously selected offerer BUNDLE address to the added o Assign the previously selected offerer BUNDLE address to the added
"m=" line; or "m=" line; or
o If the offerer associates a new (shared address) suggested offerer o If the offerer associates a new (shared address) suggested offerer
BUNDLE address with each bundled "m=" line [Section 8.5.2], also BUNDLE address with each bundled "m=" line [Section 8.6.2], also
associate that address with the added "m=" line. associate that address with the added "m=" line.
In addition, the offerer MUST extend the SDP 'group:BUNDLE' attribute In addition, the offerer MUST extend the SDP 'group:BUNDLE' attribute
identification-tag list with the BUNDLE group [Section 8.2.2] by identification-tag list with the BUNDLE group [Section 8.3.2] by
adding the identification-tag associated with the added "m=" line to adding the identification-tag associated with the added "m=" line to
the list. the list.
NOTE: Assigning a unique address to the "m=" line allows the answerer NOTE: Assigning a unique address to the "m=" line allows the answerer
to move the "m=" line out of the BUNDLE group [Section 8.3.4], to move the "m=" line out of the BUNDLE group [Section 8.4.4],
without having to reject the "m=" line. without having to reject the "m=" line.
If the offerer associates a unique address with the added "m=" line, If the offerer associates a unique address with the added "m=" line,
and if the offerer suggests that address as the new offerer BUNDLE and if the offerer suggests that address as the new offerer BUNDLE
address [Section 8.5.2], the offerer BUNDLE-tag MUST represent the address [Section 8.6.2], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.2]. added "m=" line [Section 8.3.2].
If the offerer associates a new suggested offerer BUNDLE address with If the offerer associates a new suggested offerer BUNDLE address with
each bundled "m=" line [Section 8.5.2], including the added "m=" each bundled "m=" line [Section 8.6.2], including the added "m="
line, the offerer BUNDLE-tag MAY represent the added "m=" line line, the offerer BUNDLE-tag MAY represent the added "m=" line
[Section 8.2.2]. [Section 8.3.2].
[Section 17.3] shows an example where an offerer sends an offer in [Section 17.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group. order to add a bundled "m=" line to a BUNDLE group.
8.5.4. Moving A Media Description Out Of A BUNDLE Group 8.6.4. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" line out of a BUNDLE group it was added to in a previous bundled "m=" line out of a BUNDLE group it was added to in a previous
offer/answer transaction, the offerer: offer/answer transaction, the offerer:
o MUST associate a unique address with the "m=" line; and o MUST associate a unique address with the "m=" line; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
line in the SDP 'group:BUNDLE' attribute identification-tag list line in the SDP 'group:BUNDLE' attribute identification-tag list
associated with the BUNDLE group. associated with the BUNDLE group.
NOTE: If the removed "m=" line is associated with the previously NOTE: If the removed "m=" line is associated with the previously
selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
[Section 8.2.2]. [Section 8.3.2].
NOTE: If an "m=" line, when being moved out of a BUNDLE group, is NOTE: If an "m=" line, when being moved out of a BUNDLE group, is
added to another BUNDLE group, the offerer applies the procedures in added to another BUNDLE group, the offerer applies the procedures in
[Section 8.5.3] to the "m=" line. [Section 8.6.3] to the "m=" line.
[Section 17.4] shows an example of an offer for moving an "m=" line [Section 17.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group. out of a BUNDLE group.
8.5.5. Disabling A Media Description In A BUNDLE Group 8.6.5. Disabling A Media Description In A BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST associate an address with a zero port value with the "m=" o MUST associate an address with a zero port value with the "m="
line, following the procedures in [RFC4566]; and line, following the procedures in [RFC4566]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
line in the SDP 'group:BUNDLE' attribute identification-tag list line in the SDP 'group:BUNDLE' attribute identification-tag list
skipping to change at page 18, line 43 skipping to change at page 19, line 10
with time overlap, RTP and RTCP fail to function. Even if done in with time overlap, RTP and RTCP fail to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues proper sequence this causes RTP Timestamp rate switching issues
[RFC7160]. However, once an SSRC has left the RTP session (by [RFC7160]. However, once an SSRC has left the RTP session (by
sending an RTCP BYE packet), that SSRC value can later be reused by sending an RTCP BYE packet), that SSRC value can later be reused by
another source(possibly associated with a different bundled "m=" another source(possibly associated with a different bundled "m="
line. line.
10.1.2. Payload Type (PT) Value Reuse 10.1.2. Payload Type (PT) Value Reuse
Multiple bundled "m=" lines might represent RTP based media. As all Multiple bundled "m=" lines might represent RTP based media. As all
RTP based media associated with a BUNDLE group belong to the same RTP RTP based media specified by a BUNDLE group belong to the same RTP
session, in order for a given payload type value to be used inside session, in order for a given payload type value to be used inside
more than one bundled "m=" line, all codecs associated with the more than one bundled "m=" line, all codecs associated with the
payload type number MUST share an identical codec configuration. payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values must be identical for all codecs that use the same
payload type value. payload type value.
skipping to change at page 20, line 4 skipping to change at page 20, line 15
the SSRC values. the SSRC values.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP and RTCP packets with the correct "m=" line, an offerer
and answerer using the BUNDLE extension MUST support the mechanism and answerer using the BUNDLE extension MUST support the mechanism
defined in Section 14, where the remote endpoint inserts the defined in Section 14, where the remote endpoint inserts the
identification-tag associated with an "m=" line in RTP and RTCP identification-tag associated with an "m=" line in RTP and RTCP
packets associated with that "m=" line. packets associated with that "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
10.3.1. General 10.3.1. General
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based media associated with the multiplexing [RFC5761] for the RTP-based media specified by the
BUNDLE group. BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for sending all RTP packets and the RTCP combination will be used for sending all RTP packets and the RTCP
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
the packets towards the BUNDLE address of the other endpoint. The the packets towards the BUNDLE address of the other endpoint. The
same address:port combination MAY be used for receiving RTP packets same address:port combination MAY be used for receiving RTP packets
and RTCP packets. and RTCP packets.
10.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
10.3.2.1. General 10.3.2.1. General
This section describes how an offerer and answerer use the SDP 'rtcp- This section describes how an offerer and answerer use the SDP 'rtcp-
mux' attribute [RFC5761] to negotiate usage of RTP/RTCP multiplexing mux' attribute [RFC5761] to negotiate usage of RTP/RTCP multiplexing
for RTP-based media associated with a BUNDLE group. for RTP-based media specified by a BUNDLE group.
The procedures in this section only apply to RTP-based "m=" lines. The procedures in this section only apply to RTP-based "m=" lines.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST
associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
RTP-based "m=" line (including any bundle-only "m=" line) in the RTP-based "m=" line (including any bundle-only "m=" line) in the
offer. offer.
skipping to change at page 21, line 11 skipping to change at page 21, line 21
In the initial offer, the address:port combination for RTCP MUST be In the initial offer, the address:port combination for RTCP MUST be
unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' unique in each bundled RTP-based "m=" line (excluding a 'bundle-only'
"m=" line), similar to RTP. "m=" line), similar to RTP.
10.3.2.3. Generating the SDP Answer 10.3.2.3. Generating the SDP Answer
When an answerer generates an answer, if the answerer accepts an RTP- When an answerer generates an answer, if the answerer accepts an RTP-
based "m=" line within a BUNDLE group, the answerer MUST enable usage based "m=" line within a BUNDLE group, the answerer MUST enable usage
of RTP/RTCP multiplexing. The answerer MUST associate an SDP "rtcp- of RTP/RTCP multiplexing. The answerer MUST associate an SDP "rtcp-
mux" attribute with the "m=" line in the answer. In addition, if the mux" attribute with the "m=" line in the answer. In addition, if the
"m=" line in the associated offer contained an SDP "rtcp-mux- "m=" line in the corresponding offer contained an SDP "rtcp-mux-
exclusive" attribute, the answerer MUST associate an SDP "rtcp-mux- exclusive" attribute, the answerer MUST associate an SDP "rtcp-mux-
exclusive" attribute with the "m=" line in the answer. exclusive" attribute with the "m=" line in the answer.
If an RTP-based "m=" line in the associated offer did not contain an If an RTP-based "m=" line in the corresponding offer did not contain
SDP "rtcp-mux" attribute, the answerer MUST NOT accept the "m=" line an SDP "rtcp-mux" attribute, the answerer MUST NOT accept the "m="
within a BUNDLE group in the answer. line within a BUNDLE group in the answer.
If an RTP-based "m=" line in the associated offer contained an SDP If an RTP-based "m=" line in the corresponding offer contained an SDP
"rtcp-mux-exclusive" attribute, and if the answerer moves the "m=" "rtcp-mux-exclusive" attribute, and if the answerer moves the "m="
line out of the BUNDLE group in the answer Section 8.3.4, the line out of the BUNDLE group in the answer Section 8.4.4, the
answerer MUST still either enable RTP/RTCP multiplexing, or reject answerer MUST still either enable RTP/RTCP multiplexing, or reject
the "m=" line Section 8.3.5. the "m=" line Section 8.4.5.
When the answerer accepts the usage of RTP/RTCP multiplexing within When the answerer accepts the usage of RTP/RTCP multiplexing within
the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with
each bundled RTP-based "m=" line in the answer. In addition, if the each bundled RTP-based "m=" line in the answer. In addition, if the
"m=" line in the associated offer contained an SDP 'rtcp-mux- "m=" line in the corresponding offer contained an SDP 'rtcp-mux-
exclusive' attribute, the answerer MUST associated an SDP 'rtcp-mux- exclusive' attribute, the answerer MUST associated an SDP 'rtcp-mux-
exclusive' attribute with the corresponding "m=" line in the answer, exclusive' attribute with the corresponding "m=" line in the answer,
as described in. as described in.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any The answerer MUST NOT associate an SDP 'rtcp' attribute with any
bundled "m=" line in the answer. The answerer will use the port bundled "m=" line in the answer. The answerer will use the port
value of the selected offerer BUNDLE address for sending RTP and RTCP value of the selected offerer BUNDLE address for sending RTP and RTCP
packets associated with each RTP-based bundled "m=" line towards the packets associated with each RTP-based bundled "m=" line towards the
offerer. offerer.
skipping to change at page 23, line 29 skipping to change at page 23, line 35
associate ICE-related SDP attributes with the "m=" line. associate ICE-related SDP attributes with the "m=" line.
When an answerer associates a shared address with a bundled "m=" When an answerer associates a shared address with a bundled "m="
line, if the "m=" line is associated with the answerer BUNDLE-tag, line, if the "m=" line is associated with the answerer BUNDLE-tag,
the answerer MUST associate SDP 'candidate' attributes (and other the answerer MUST associate SDP 'candidate' attributes (and other
applicable ICE-related media-level SDP attributes), containing shared applicable ICE-related media-level SDP attributes), containing shared
ICE properties, with the "m=" line. If the "m=" line is not ICE properties, with the "m=" line. If the "m=" line is not
associated with the answerer BUNDLE-tag, the answerer MUST NOT associated with the answerer BUNDLE-tag, the answerer MUST NOT
associate ICE-related SDP attributes with the "m=" line. associate ICE-related SDP attributes with the "m=" line.
NOTE: As bundled "m=" lines associated with a shared address will NOTE: As most ICE-related media-level SDP attributes belong to the
share the same ICE properties, there is no need to associated ICE- TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the
related media-level SDP attributes with each "m=" line. offerer and answerer follow the rules in Section 8.2. However, in
the case of ICE-related media-level attributes, the rules apply to
all attributes (see note below), even if they belong to a different
mux category.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-
candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
pacing'. pacing'.
11.2.2. Generating the Initial SDP Offer 11.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST
associate ICE-related media-level SDP attributes with each bundled associate ICE-related media-level SDP attributes with each bundled
skipping to change at page 24, line 10 skipping to change at page 24, line 17
When an answerer generates an answer that contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group,
the answerer MUST associated ICE-related SDP attributes with the "m=" the answerer MUST associated ICE-related SDP attributes with the "m="
line associated with the answerer BUNDLE-tag, according to line associated with the answerer BUNDLE-tag, according to
[Section 11.2.1]. [Section 11.2.1].
11.2.4. Offerer Processing of the SDP Answer 11.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST the ICE mechanism and the BUNDLE extension, the offerer MUST
associate the ICE properties associated with the offerer BUNDLE associate the ICE properties associated with the offerer BUNDLE
address, selected by the answerer [Section 8.3.2], with each bundled address, selected by the answerer [Section 8.4.2], with each bundled
"m=" line. "m=" line.
11.2.5. Modifying the Session 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it MUST associated When an offerer generates a subsequent offer, it MUST associated
unique or shared ICE properties to one or more bundled "m=" lines, unique or shared ICE properties to one or more bundled "m=" lines,
according to [Section 11.2.1]. according to [Section 11.2.1].
12. DTLS Considerations 12. DTLS Considerations
skipping to change at page 30, line 38 skipping to change at page 30, line 38
16. Security Considerations 16. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information to the BUNDLE extension. Bundle does not change which information
flows over the network but only changes which addresses and ports flows over the network but only changes which addresses and ports
that information is flowing on and thus has very little impact on the that information is flowing on and thus has very little impact on the
security of the RTP sessions. security of the RTP sessions.
When the BUNDLE extension is used, a single set of security When the BUNDLE extension is used, a single set of security
credentials might be used for all media streams associated with a credentials might be used for all media streams specified by a BUNDLE
BUNDLE group. group.
When the BUNDLE extension is used, the number of SSRC values within a When the BUNDLE extension is used, the number of SSRC values within a
single RTP session increases, which increases the risk of SSRC single RTP session increases, which increases the risk of SSRC
collision. [RFC4568] describes how SSRC collision may weaken SRTP collision. [RFC4568] describes how SSRC collision may weaken SRTP
and SRTCP encryption in certain situations. and SRTCP encryption in certain situations.
17. Examples 17. Examples
17.1. Example: Bundle Address Selection 17.1. Example: Bundle Address Selection
skipping to change at page 39, line 37 skipping to change at page 39, line 37
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
19. Change Log 19. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27
o - Yet another terminology change.
o - Mux category considerations added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26
o - ICE considerations modified: ICE-related SDP attributes only o - ICE considerations modified: ICE-related SDP attributes only
added to the bundled m- line representing the selected BUNDLE added to the bundled m- line representing the selected BUNDLE
address. address.
o - Reference to draft-ietf-mmusic-ice-sip-sdp added. o - Reference to draft-ietf-mmusic-ice-sip-sdp added.
o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- o - Reference to RFC 5245 replaced with reference to draft-ietf-ice-
rfc5245bis. rfc5245bis.
skipping to change at page 48, line 34 skipping to change at page 48, line 40
mmusic-trickle-ice-02 (work in progress), January 2015. mmusic-trickle-ice-02 (work in progress), January 2015.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. General A.1. General
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value
should be inserted in "m=" lines associated with a BUNDLE group, as should be inserted in "m=" lines associated with a BUNDLE group, as
the purpose of the extension is to negotiate the usage of a single the purpose of the extension is to negotiate the usage of a single
address:port combination for media associated with the "m=" lines. address:port combination for media specified by the "m=" lines.
Issues with both approaches, discussed in the Appendix have been Issues with both approaches, discussed in the Appendix have been
raised. The outcome was to specify a mechanism which uses SDP Offers raised. The outcome was to specify a mechanism which uses SDP Offers
with both different and identical port values. with both different and identical port values.
Below are the primary issues that have been considered when defining Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension: the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs. o 1) Interoperability with existing UAs.
o 2) Interoperability with intermediary B2BUA- and proxy entities. o 2) Interoperability with intermediary B2BUA- and proxy entities.
skipping to change at page 50, line 24 skipping to change at page 50, line 28
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
In an SDP Offer or SDP Answer, the media associated with an "m=" line In an SDP Offer or SDP Answer, the media specified by an "m=" line
can be disabled/rejected by setting the port number value to zero. can be disabled/rejected by setting the port number value to zero.
This is different from e.g. using the SDP direction attributes, where This is different from e.g. using the SDP direction attributes, where
RTCP traffic will continue even if the SDP "inactive" attribute is RTCP traffic will continue even if the SDP "inactive" attribute is
indicated for the associated "m=" line. indicated for the associated "m=" line.
If each "m=" line associated with a BUNDLE group would contain If each "m=" line associated with a BUNDLE group would contain
different port values, and one of those port values would be used for different port values, and one of those port values would be used for
a BUNDLE address associated with the BUNDLE group, problems would a BUNDLE address associated with the BUNDLE group, problems would
occur if an endpoint wants to disable/reject the "m=" line associated occur if an endpoint wants to disable/reject the "m=" line associated
with that port, by setting the port value to zero. After that, no with that port, by setting the port value to zero. After that, no
skipping to change at page 51, line 43 skipping to change at page 51, line 46
retrieved from the SDP. This typically occurs once the session is retrieved from the SDP. This typically occurs once the session is
already established and ongoing. already established and ongoing.
A.4.2. Bandwidth Allocation A.4.2. Bandwidth Allocation
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, don't modify SDP bodies, nor do they terminate SIP dialogs. Still,
however, they may use SDP information (e.g. codecs and media types) however, they may use SDP information (e.g. codecs and media types)
in order to control bandwidth allocation functions. The bandwidth in order to control bandwidth allocation functions. The bandwidth
allocation is done per "m=" line, which means that it might not be allocation is done per "m=" line, which means that it might not be
enough if media associated with all "m=" lines try to use that enough if media specified by all "m=" lines try to use that
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
 End of changes. 91 change blocks. 
122 lines changed or deleted 152 lines changed or added

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