draft-ietf-mmusic-sdp-bundle-negotiation-17.txt   draft-ietf-mmusic-sdp-bundle-negotiation-18.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: September 4, 2015 C. Jennings Expires: September 10, 2015 C. Jennings
Cisco Cisco
March 3, 2015 March 9, 2015
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-17.txt draft-ietf-mmusic-sdp-bundle-negotiation-18.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. bundle-only . . . . . . . . . . . . . . . . . . . . . . . 8
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. Generating the Initial SDP Offer . . . . . . . . . . . . 10
8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11
skipping to change at page 3, line 51 skipping to change at page 3, line 48
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
12.7. New text replacing section 8.4 (6th paragraph) of RFC 12.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. RTP/RTCP extensions for identification-tag transport . . . . 26 13. RTP/RTCP extensions for identification-tag transport . . . . 26
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Example: Bundle Address Selection . . . . . . . . . . . 30 16.1. Example: Bundle Address Selection . . . . . . . . . . . 30
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32
16.3. Example: Offerer Adds A Media Description To A BUNDLE 16.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 32 Group . . . . . . . . . . . . . . . . . . . . . . . . . 33
16.4. Example: Offerer Moves A Media Description Out Of A 16.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 16.5. Example: Offerer Disables A Media Description Within A
18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
19.1. Normative References . . . . . . . . . . . . . . . . . . 43 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
19.2. Informative References . . . . . . . . . . . . . . . . . 43 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Design Considerations . . . . . . . . . . . . . . . 44 19.1. Normative References . . . . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44 19.2. Informative References . . . . . . . . . . . . . . . . . 44
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 45 Appendix A. Design Considerations . . . . . . . . . . . . . . . 45
A.3. Usage of port number value zero . . . . . . . . . . . . . 46 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47 A.3. Usage of port number value zero . . . . . . . . . . . . . 47
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 47
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 6, line 31 skipping to change at page 6, line 28
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 associated with a given BUNDLE group.
Initial offer: The first offer, within an SDP session, in which the Initial offer: The first offer, within an SDP session (e.g. a SIP
offerer indicates that it wants to create a given BUNDLE group. dialog when the Session Initiation Protocol (SIP) [RFC3261] is used
to carry SDP), in which the offerer indicates that it wants to create
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
"m=" line. The SDP 'mid' attribute [RFC5888], associated with an "m=" line. The SDP 'mid' attribute [RFC5888], associated with an
"m=" line, carries an unique identification-tag. The session-level "m=" line, carries an unique identification-tag. The session-level
SDP 'group' attribute [RFC5888] carries a list of identification- SDP 'group' attribute [RFC5888] carries a list of identification-
tags, identifying the "m=" lines associated with that particular tags, identifying the "m=" lines associated with that particular
'group' attribute. 'group' attribute.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
The mechanism in this specification only applies to the Session The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
offer/answer mechanism [RFC3264]. offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of
scope of this document, and is thus undefined.
5. SDP Grouping Framework BUNDLE Extension 5. SDP Grouping Framework BUNDLE Extension
5.1. General
This section defines a new SDP Grouping Framework extension This section defines a new SDP Grouping Framework extension
[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 is used. A given address:port depending on whether symmetric RTP is used. A given address:port
combination MUST NOT be used for sending media associated with combination MUST NOT be used for sending media associated with
multiple BUNDLE groups. multiple BUNDLE groups.
All media associated with a BUNDLE group share a single 5-tuple, i.e. All media associated with a BUNDLE group share a single 5-tuple, i.e.
in addition to using a single address:port combination all bundled in addition to using a single address:port combination all bundled
media MUST be transported using the same transport-layer protocol. media MUST be transported using the same transport-layer protocol
(e.g. 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
assigned to each bundled "m=" line, and each identification-tag is assigned to each bundled "m=" line, and each identification-tag is
listed in the SDP 'group:BUNDLE' attribute identification-tag list. listed in the SDP 'group:BUNDLE' attribute identification-tag list.
Each "m=" line, whose identification-tag is listed in the 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.
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 8 defines the detailed SDP Offer/Answer procedures for the
BUNDLE extension. BUNDLE extension.
6. SDP 'bundle-only' Attribute 6. SDP 'bundle-only' Attribute
6.1. General
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. 'bundle-only'.
6.2. bundle-only
Name: bundle-only Name: bundle-only
Value: Value:
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Example: Example:
skipping to change at page 10, line 14 skipping to change at page 10, line 14
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group) and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an 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
transport protocol 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) [RFC5245] the usage of Interactive Connectivity Establishment (ICE) [RFC5245]
mechanism . mechanism .
The offerer and answerer MUST follow the rules and restrictions The offerer and answerer MUST follow the rules and restrictions
defined in Section 7 when creating offers and answers. defined in Section 7 when creating offers and answers.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
skipping to change at page 10, line 36 skipping to change at page 10, line 36
group. group.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
8.2.1. General 8.2.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]; following the procedures in [RFC3264], unless the media line is a
'bundle-only' "m=" line (see below);
o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264];
o Add an SDP 'group:BUNDLE' attribute to the offer; o Add an SDP 'group:BUNDLE' attribute to the offer;
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.2.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
skipping to change at page 12, line 4 skipping to change at page 11, line 49
o Select an Answerer BUNDLE Address [Section 8.3.3]; o Select an Answerer BUNDLE Address [Section 8.3.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.3.4]; or
o Reject the "m=" line [Section 8.3.5];
o Reject the "m=" line [Section 8.3.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 (assigns the answerer BUNDLE address group, it follows the procedures (assigns the answerer BUNDLE address
to the "m=" line etc) for any other "m=" line kept within the BUNDLE to the "m=" line etc) for any other "m=" line kept within the BUNDLE
group. 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.3.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.
skipping to change at page 15, line 39 skipping to change at page 15, line 39
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]; [Section 8.5.3];
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.5.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.5.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], even if the offerer does not suggest a new offerer [Section 8.2.2] associated with the previously selected offerer
BUNDLE address. BUNDLE address, unless the offerer suggests a new offerer BUNDLE
address.
8.5.2. Suggesting a new offerer BUNDLE address 8.5.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.2.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.
NOTE: If the offerer assigns a unique address, there might be a need
to send a subsequent BAS offer [Section 8.4.2] once the offerer has
received the associated answer.
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.2.2].
NOTE: Unless the offerer assigns the new suggested offerer BUNDLE NOTE: Unless the offerer assigns the new suggested offerer BUNDLE
address to each bundled "m=" line, it can assign unique addresses to address to each bundled "m=" line, it can assign unique addresses to
any number of bundled "m=" lines (and the previously selected offerer any number of bundled "m=" lines (and the previously selected offerer
BUNDLE address to any remaining bundled "m=" line) if it wants to BUNDLE address to any remaining bundled "m=" line) if it wants to
suggest multiple alternatives for the new offerer BUNDLE address. suggest multiple alternatives for the new offerer BUNDLE address.
8.5.3. Adding a media description to a BUNDLE group 8.5.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 "m=" line; o Assign a unique address to the "m=" line;
o Assign the previously selected offerer BUNDLE address to the "m=" o Assign the previously selected offerer BUNDLE address to the "m="
line; or line; or
o If the offerer assigns a new suggested offerer BUNDLE address to o If the offerer assigns a new (shared address) suggested offerer
each bundled "m=" line [Section 8.5.2], also assign that address BUNDLE address to each bundled "m=" line [Section 8.5.2], also
to the added "m=" line. assign that address to 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.2.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.3.4],
without having to reject the "m=" line. without having to reject the "m=" line.
skipping to change at page 18, line 49 skipping to change at page 18, line 49
Since a single RTP session is used for each bundle group, all "m=" Since a single RTP session is used for each bundle group, all "m="
lines representing RTP-based media in a bundle group will share a lines representing RTP-based media in a bundle group will share a
single SSRC numbering space [RFC3550]. single SSRC numbering space [RFC3550].
The following rules and restrictions apply for a single RTP session: The following rules and restrictions apply for a single RTP session:
o A specific payload type value can be used in multiple bundled "m=" o A specific payload type value can be used in multiple bundled "m="
lines if each codec associated with the payload type number shares lines if each codec associated with the payload type number shares
an identical codec configuration [Section 10.1.2]. an identical codec configuration [Section 10.1.2].
o The "proto" value in each bundled RTP-based "m=" line MUST be o The proto value in each bundled RTP-based "m=" line MUST be
identical (e.g. RTP/AVPF). identical (e.g. RTP/AVPF).
o An SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- o The RTP MID header extension MUST be enabled, by associating an
hdrext:sdes:mid' URI value, MUST, in every offer and answer, be SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp-
associated with each bundled "m=" line representing RTP-based hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line
media. in every offer and answer.
o A given SSRC MUST NOT transmit RTP packets using payload types o A given SSRC MUST NOT transmit RTP packets using payload types
that originate from different bundled "m=" lines. that originate from different bundled "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 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
skipping to change at page 20, line 7 skipping to change at page 20, line 7
address:port combination cannot be used to associate received RTP address:port combination cannot be used to associate received RTP
packets with the correct "m=" line. packets with the correct "m=" line.
As described in [Section 10.1.2], the same payload type value might As described in [Section 10.1.2], the same payload type value might
be used inside RTP packets described by multiple "m=" lines. In such be used inside RTP packets described by multiple "m=" lines. In such
cases, the payload type value cannot be used to associate received cases, the payload type value cannot be used to associate received
RTP packets with the correct "m=" line. RTP packets with the correct "m=" line.
An offerer and answerer can in an offer and answer inform each other An offerer and answerer can in an offer and answer inform each other
which SSRC values they will use inside sent RTP/RTCP packets, by which SSRC values they will use inside sent RTP/RTCP packets, by
associating an SDP 'ssrc' attribute [RFC5576] with each bundled "m=" associating one or more SDP 'ssrc' attributes [RFC5576] with each
line which contains a payload type value that is also used inside bundled "m=" line which contains a payload type value that is also
another bundled "m=" line. As the SSRC values will be carried inside used inside another bundled "m=" line. As the SSRC values will be
the RTP/RTCP packets, the offerer and answerer can then use that carried inside the RTP/RTCP packets, the offerer and answerer can
information to associate received RTP packets with the correct "m=" then use that information to associate received RTP packets with the
line. However, an offerer will not know which SSRC values the correct "m=" line. However, an offerer will not know which SSRC
answerer will use until it has received the answer providing that values the answerer will use until it has received the answer
information. Due to this, before the offerer has received the providing that information. Due to this, before the offerer has
answer, the offerer will not be able to associate received RTP/RTCP received the answer, the offerer will not be able to associate
packets with the correct "m=" line using the SSRC values. received RTP/RTCP packets with the correct "m=" line using 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 13, where the remote endpoint inserts the defined in Section 13, 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
skipping to change at page 22, line 31 skipping to change at page 22, line 31
10.3.2.4. Offerer Processing of the SDP Answer 10.3.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer has accepted the When an offerer receives an answer, if the answerer has accepted the
usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer
follows the procedures for RTP/RTCP multiplexing defined in follows the procedures for RTP/RTCP multiplexing defined in
[RFC5761]. The offerer will use the port value associated with the [RFC5761]. The offerer will use the port value associated with the
answerer BUNDLE address for sending RTP and RTCP packets associated answerer BUNDLE address for sending RTP and RTCP packets associated
with each RTP-based bundled "m=" line towards the answerer. with each RTP-based bundled "m=" line towards the answerer.
If the answerer did not accept the usage of RTP/RTCP multiplexing If the answerer did not accept the usage of RTP/RTCP multiplexing
(see Section 10.3.2.3), the offerer will use separate address + port (see Section 10.3.2.3), the offerer will use separate address:port
combinations for sending RTP and RTCP packets towards the answerer. combinations for sending RTP and RTCP packets towards the answerer.
If the answerer associated an SDP 'rtcp' attribute with the "m=" line If the answerer associated an SDP 'rtcp' attribute with the "m=" line
representing the answerer BUNDLE address, the offerer will use the representing the answerer BUNDLE address, the offerer will use the
attribute port value for sending RTCP packets associated with each attribute port value for sending RTCP packets associated with each
bundled RTP-based "m=" line towards the answerer. Otherwise the bundled RTP-based "m=" line towards the answerer. Otherwise the
offerer will use the next higher port value associated with the offerer will use the next higher port value associated with the
answerer BUNDLE address for sending RTCP packets towards the answerer BUNDLE address for sending RTCP packets towards the
answerer. answerer.
10.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
skipping to change at page 28, line 17 skipping to change at page 28, line 17
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
13.3. RTP MID Header Extension 13.3. RTP MID Header Extension
The payload, containing the identification-tag, of the RTP MID header The payload, containing the identification-tag, of the RTP MID header
extension element can be encoded using either the one-byte or two- extension element can be encoded using either the one-byte or two-
byte header [RFC5285]. The identification-tag payload is UTF-8 byte header [RFC5285]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, however, that The identification-tag is not zero terminated. Note, that set of
RTP header extensions that are not a multiple of 32 bits in length header extensions included in the packet needs to be padded to the
MUST be padded to the next 32-bit boundary using zero bytes; these next 32-bit boundary using zero bytes [RFC5285].
padding bytes are not included in the header length field [RFC3550].
As the identification-tag is included in either an RTCP SDES item or
an RTP header extension, or both, there should be some consideration
about the packet expansion caused by the identification-tag. To
avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the
header extension's size needs to be taken into account when the
encoding media.
It is recommended that the identification-tag is kept short. Due to
the properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in that a
minimal number of 32-bit words are used for the RTP header extension,
in case no other header extensions are included at the same time.
Note, do take into account that some single characters when UTF-8
encoded will result in multiple octets.
14. IANA Considerations 14. IANA Considerations
14.1. New SDES item 14.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
skipping to change at page 38, line 16 skipping to change at page 39, line 16
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach and Ari Keraenen for taking the time to read the text along the Stach and Ari Keraenen for taking the time to read the text along the
way, and providing useful feedback. way, and providing useful feedback.
18. Change Log 18. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
o - Editorial changes based on comments from Magnus Westerlund.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
o - Modification of RTP/RTCP multiplexing section, based on comments o - Modification of RTP/RTCP multiplexing section, based on comments
from Magnus Westerlund. from Magnus Westerlund.
o - Reference updates. o - Reference updates.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15
o - Editorial fix. o - Editorial fix.
skipping to change at page 43, line 35 skipping to change at page 44, line 37
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.mmusic-sdp-mux-attributes] [I-D.mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08
(work in progress), January 2015. (work in progress), January 2015.
19.2. Informative References 19.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
 End of changes. 31 change blocks. 
67 lines changed or deleted 89 lines changed or added

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