draft-ietf-mmusic-sdp-bundle-negotiation-32.txt   draft-ietf-mmusic-sdp-bundle-negotiation-33.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: February 18, 2017 C. Jennings Expires: April 10, 2017 C. Jennings
Cisco Cisco
August 17, 2016 October 7, 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-32.txt draft-ietf-mmusic-sdp-bundle-negotiation-33.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, specified by multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 February 18, 2017. This Internet-Draft will expire on April 10, 2017.
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 44 skipping to change at page 2, line 44
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 8 7. SDP Information Considerations . . . . . . . . . . . . . . . 9
7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
7.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 7.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10
8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer Bundle Address . . . . 12 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 13 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 13 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14
8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 14 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 15
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 15 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16
8.5.2. Adding a media description to a BUNDLE group . . . . 15 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 16 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 16 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 21
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 21
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 24
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 23 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 23 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 24 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 25
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 24 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 25
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 26
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 26
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 13.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 26 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 27
13.4. New text replacing section 8.2 (2nd paragraph) of RFC 13.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 26 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 27
13.6. New text replacing section 8.4 (6th paragraph) of RFC 13.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14. RTP/RTCP extensions for identification-tag transport . . . . 27 14. RTP/RTCP extensions for identification-tag transport . . . . 28
14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 28 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 29
14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 28 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 29
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 29 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 30
15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 29 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 30
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 30 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 31
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32
17.1. Example: Bundle Address Selection . . . . . . . . . . . 31 17.1. Example: Bundle Address Selection . . . . . . . . . . . 32
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 33 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 34
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 34 Group . . . . . . . . . . . . . . . . . . . . . . . . . 35
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37
17.5. Example: Offerer Disables A Media Description Within A 17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 39
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 40 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 41
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
20.1. Normative References . . . . . . . . . . . . . . . . . . 47 20.1. Normative References . . . . . . . . . . . . . . . . . . 48
20.2. Informative References . . . . . . . . . . . . . . . . . 49 20.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Design Considerations . . . . . . . . . . . . . . . 50 Appendix A. Design Considerations . . . . . . . . . . . . . . . 51
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 50 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 51
A.2. Usage of port number value zero . . . . . . . . . . . . . 52 A.2. Usage of port number value zero . . . . . . . . . . . . . 53
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 52 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 53
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 53 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 54
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 53 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 54
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 53 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
When multimedia communications are established, each 5-tuple reserved
for an individual media stream consume additional resources
(especially when Interactive Connectivity Establishment (ICE)
[RFC5245] is used). For this reason, it is attractive to use a
5-tuple for multiple media streams.
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 specified by 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 specified by multiple "m=" BUNDLE address is used for receiving media specified by multiple "m="
lines. This is referred to as bundled media. lines. This is referred to as bundled media.
skipping to change at page 5, line 23 skipping to change at page 5, line 29
undefined, and there is no grouping defined by such means. Instead, undefined, and there is no grouping defined by such means. Instead,
an explicit grouping mechanism needs to be used to express the an explicit grouping mechanism needs to be used to express the
intended semantics. This specification provides such an extension. intended semantics. This specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the "m=" line in the value to an "m=" line in an SDP answer, even if the "m=" line in the
associated SDP offer contained a zero port value. associated SDP offer contained a zero port value.
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, 'MID', and a new RTP
extension that can be used to carry a value that associates RTP/RTCP SDES header extension that can be used to carry a value that
packets with a specific media description. This can be used to associates RTP/RTCP packets with a specific media description. This
correlate a RTP packet with the correct media. can be used to 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 described by a single BUNDLE BUNDLE group. All RTP based media flows described by a single 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
skipping to change at page 7, line 32 skipping to change at page 7, line 34
[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 specified by a BUNDLE group share a single 5-tuple, i.e. in All media associated with a BUNDLE group MUST be transport using the
addition to using a single address:port combination all bundled media same transport-layer protocol (e.g., UDP or TCP).
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
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.
NOTE: The order of the "m=" lines listed in the SDP 'group:BUNDLE'
attribute identification-tag list does not have to be the same as the
order in which the "m=" lines occur in the SDP.
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
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and
hence has no value. hence has no value.
Name: bundle-only Name: bundle-only
skipping to change at page 11, line 35 skipping to change at page 11, line 42
8.2.1. Suggesting the offerer BUNDLE address 8.2.1. 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.2.2. Example: Initial SDP Offer
The example shows an initial SDP offer. The offer includes two "m="
lines in the SDP, and suggests that both are included in a BUNDLE
group. The audio "m=" line is associated with the offerer BUNDLE-tag
(placed first in the SDP group:BUNDLE attribute identificatoin-id
list).
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.3. Generating the SDP Answer 8.3. Generating the SDP Answer
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
corresponding offer; and corresponding offer; and
skipping to change at page 14, line 20 skipping to change at page 15, line 15
8.3.4. Rejecting A Media Description In A BUNDLE Group 8.3.4. 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 [RFC3264]. the procedures in [RFC3264].
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.3.5. Example: SDP Answer
The example shows an SDP answer, based on the SDP offer in
[Section 8.2.2]. The answers acceppts both "m=" lines in the BUNDLE
group.
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.4. Offerer Processing of the SDP Answer 8.4. 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 corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is 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.1], as the address for each selected by the answerer [Section 8.3.1], 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
skipping to change at page 15, line 44 skipping to change at page 17, line 21
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.1], also BUNDLE address with each bundled "m=" line [Section 8.5.1], 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 add the identification-tag associated
identification-tag list with the BUNDLE group [Section 8.2.1] by with the added "m=" line to the SDP 'group:BUNDLE' attribute
adding the identification-tag associated with the added "m=" line to identification-tag list with the BUNDLE group [Section 8.2.1].
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.3], to move the "m=" line out of the BUNDLE group [Section 8.3.3],
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.1], the offerer BUNDLE-tag MUST represent the address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.1]. added "m=" line [Section 8.2.1].
skipping to change at page 18, line 20 skipping to change at page 19, line 48
RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP
sessions, one per BUNDLE group. sessions, one per BUNDLE group.
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 only if each codec associated with the payload type number
an identical codec configuration [Section 10.1.1]. shares an identical codec configuration [Section 10.1.1].
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 The RTP MID header extension MUST be enabled, by associating an o The RTP MID header extension MUST be enabled, by associating an
SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp-
hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line
in every offer and answer. 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
skipping to change at page 27, line 14 skipping to change at page 28, line 30
14. RTP/RTCP extensions for identification-tag transport 14. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" lines within SDP Offers and Answers, using the tags with "m=" lines within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" line. an "m=" line.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension section also defines a new RTP SDES header extension [RFC7914], which
[I-D.ietf-avtext-sdes-hdr-ext], which is used to carry the 'MID' RTCP is used to carry the 'MID' RTCP SDES item in RTP packets.
SDES item in RTP packets.
The SDES item and RTP SDES header extension make it possible for a The SDES item and RTP SDES header extension make it possible for a
receiver to associate received RTCP- and RTP packets with a specific receiver to associate received RTCP- and RTP packets with a specific
"m=" line, with which the receiver has associated an identification- "m=" line, with which the receiver has associated an identification-
tag, even if those "m=" lines are part of the same RTP session. The tag, even if those "m=" lines are part of the same RTP session. The
RTP SDES header extension also ensures that the media recipient gets RTP SDES header extension also ensures that the media recipient gets
the identification-tag upon receipt of the first decodable media and the identification-tag upon receipt of the first decodable media and
is able to associate the media with the correct application. is able to associate the media with the correct application.
A media recipient informs the media sender about the identification- A media recipient informs the media sender about the identification-
skipping to change at page 28, line 31 skipping to change at page 29, line 47
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
14.2. RTP SDES Header Extension For MID 14.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
two-byte header [I-D.ietf-avtext-sdes-hdr-ext]. The identification- two-byte header [RFC7914]. The identification-tag payload is UTF-8
tag payload is UTF-8 encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that the set of The identification-tag is not zero terminated. Note, that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC5285]. next 32-bit boundary using zero bytes [RFC5285].
As the identification-tag is included in either an RTCP SDES item or As the identification-tag is included in either an RTCP SDES item or
an RTP SDES header extension, or both, there should be some an RTP SDES header extension, or both, there should be some
consideration about the packet expansion caused by the consideration about the packet expansion caused by the
identification-tag. To avoid Maximum Transmission Unit (MTU) issues identification-tag. To avoid Maximum Transmission Unit (MTU) issues
for the RTP packets, the header extension's size needs to be taken for the RTP packets, the header extension's size needs to be taken
skipping to change at page 40, line 9 skipping to change at page 41, line 9
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-32
o Editorial changes based on comments from Eric Rescorla and Cullen
Jennings:
o - Justification for mechanism added to Introduction.
o - Clarify that the order of m- lines in the group:BUNDLE attribute
does not have to be the same as the order in which the m- lines
are listed in the SDP.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31
o Editorial changes based on GitHub Pull requests by Martin Thomson: o Editorial changes based on GitHub Pull requests by Martin Thomson:
o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 o - https://github.com/cdh4u/draft-sdp-bundle/pull/2
o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1
o Editorial change based on comment from Diederick Huijbers (9th o Editorial change based on comment from Diederick Huijbers (9th
July 2016). July 2016).
skipping to change at page 48, line 39 skipping to change at page 50, line 5
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <http://www.rfc-editor.org/info/rfc7914>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-04 (work in progress), June 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-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-13 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14
(work in progress), June 2016. (work in progress), September 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-10 (work in progress), August 2016. exclusive-10 (work in progress), August 2016.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-10 (work in progress), July 2016. sdp-10 (work in progress), July 2016.
[I-D.ietf-avtext-sdes-hdr-ext]
Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for RTCP Source Description Items",
draft-ietf-avtext-sdes-hdr-ext-07 (work in progress), June
2016.
20.2. Informative References 20.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[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. 27 change blocks. 
94 lines changed or deleted 169 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/