draft-ietf-mmusic-sdp-bundle-negotiation-37.txt   draft-ietf-mmusic-sdp-bundle-negotiation-38.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: October 2, 2017 C. Jennings Expires: October 14, 2017 C. Jennings
Cisco Cisco
March 31, 2017 April 12, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-37.txt draft-ietf-mmusic-sdp-bundle-negotiation-38.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 October 2, 2017. This Internet-Draft will expire on October 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 47 skipping to change at page 2, line 47
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 . . . . . . . . . . . . . . . 9 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
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.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14
8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 15 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 15
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
skipping to change at page 3, line 27 skipping to change at page 3, line 27
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 25 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 25
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 28 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 29
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 29 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 29
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 29 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 29
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 29 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 30
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 29 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 30
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 30 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 30 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 31
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 31 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 32
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32
14.6. New text replacing section 8.4 (6th paragraph) of RFC 14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15. RTP/RTCP extensions for identification-tag transport . . . . 32 15. RTP/RTCP extensions for identification-tag transport . . . . 33
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 33 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 34
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 35 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 36
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36
17. Security Considerations . . . . . . . . . . . . . . . . . . . 37
17. Security Considerations . . . . . . . . . . . . . . . . . . . 36
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
18.1. Example: Bundle Address Selection . . . . . . . . . . . 38 18.1. Example: Bundle Address Selection . . . . . . . . . . . 38
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40
18.3. Example: Offerer Adds A Media Description To A BUNDLE 18.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 41 Group . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.4. Example: Offerer Moves A Media Description Out Of A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43
18.5. Example: Offerer Disables A Media Description Within A 18.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
skipping to change at page 9, line 31 skipping to change at page 9, line 31
NOTE: Extensions to this specification can specify usage of the NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones BUNDLE mechanism for other nettype and addrtype values than the ones
listed above. listed above.
7.2. Bandwidth (b=) 7.2. Bandwidth (b=)
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" lines. bandwidth (b=) line with bundled "m=" lines.
7.3. Attributes (a=)
An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating SDP
attributes with bundled "m=" lines.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating and creating a BUNDLE group; and o Negotiating and creating a BUNDLE group; and
o Selecting the BUNDLE addresses (offerer BUNDLE address and o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address); and answerer BUNDLE address); and
o Adding an "m=" line to a BUNDLE group; and o Adding an "m=" line to a BUNDLE group; and
skipping to change at page 10, line 27 skipping to change at page 10, line 19
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.1. Mux Category Considerations 8.1. Mux Category Considerations
When an offerer associates SDP attributes with a bundled "m=" line When an offerer or answerer associates SDP attributes with a bundled
associated with a shared address, IDENTICAL and TRANSPORT mux "m=" line (including any bundle-only "m=" line) associated with a
category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are shared address, IDENTICAL and TRANSPORT mux category SDP attributes
associated with the "m=" line only if the "m=" line is also [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
associated with the offerer BUNDLE-tag. Otherwise the offerer MUST line only if the "m=" line is also associated with the offerer/
NOT associate such SDP attributes with the "m=" line. answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT
associate such SDP attributes with the "m=" line. The rule above
does not apply to a bundled "m=" line associated with a unique
address.
When an answerer associates SDP attributes with a bundled "m=" line, NOTE: As bundled "m=" lines (including any bundle-only "m=" line)
IDENTICAL and TRANSPORT mux category SDP attributes are associated associated with a shared address will share the same IDENTICAL and
with the "m=" line only if the "m=" line is also associated with the TRANSPORT mux category SDP attributes, and attribute values, there is
answerer BUNDLE-tag. Otherwise the answerer MUST NOT associated such no need to associate such SDP attributes with each "m=" line. The
SDP attributes with the "m=" line. attributes and attribute values are implicitly applied to each "m="
line.
NOTE: As bundled "m=" lines associated with a shared address will The semantics of some SDP attributes only apply to specific types of
share the same IDENTICAL and TRANSPORT mux category SDP attributes, media. For example, the semantics of the SDP 'rtcp-mux' and SDP
and attribute values, there is no need to associate such SDP 'rtcp-mux-only' attributes only apply to "m=" lines describing RTP-
attributes with each "m=" line. The attributes and attribute values based media. However, as described in Section 8.1, there are cases
are implicitly applied to each "m=" line associated with the shared where IDENTICAL and TRANSPORT mux category SDP attributes are only
address. associated with the "m=" line associated with the BUNDLE-tag. That
means that media-specific IDENTICAL and TRANSPORT mux category
attributes can be associated with an "m=" line associated with
another type of media.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
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
skipping to change at page 12, line 24 skipping to change at page 12, line 24
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 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:
skipping to change at page 15, line 38 skipping to change at page 15, line 38
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 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
skipping to change at page 26, line 12 skipping to change at page 26, line 12
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.1. SDP Offer/Answer Procedures 10.3.1. SDP Offer/Answer Procedures
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] and the SDP 'rtcp-mux-only' attribute mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP
multiplexing for RTP-based media specified by a BUNDLE group. multiplexing for RTP-based media associated with a BUNDLE group.
The procedures in this section only apply to RTP-based "m=" lines. The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP
'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1
describes the details regarding which bundled "m=" lines an offerer
and answerer associates the attributes with.
RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux'
and SDP 'rtcp-mux-only' attributes might be associated with a non-
RTP-based bundled "m=" line.
10.3.1.1. Generating the Initial SDP Offer 10.3.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, if the offer contains one
associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled or more RTP-based bundled "m=" lines (or, if there is a chance that
RTP-based "m=" line in the offer, including a bundle-only "m=" line. RTP-based "m=" lines will later be added to the BUNDLE group), the
In addition, the offerer MUST associate an SDP 'rtcp-mux-only' offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with one
attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle- or more "m=" lines, following the procedures for IDENTICAL mux
only "m=" line, and MAY associated an SDP 'rtcp-mux-only' attribute category attributes in Section 8.1. In addition, the offerer MAY
with other bundled RTP-based "m=" lines. associate an SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] with the same "m=" lines.
NOTE: Whether the offerer associates an SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer associates the SDP 'rtcp-mux-only'
with a bundled "m=" line or not depends on whether the offerer attribute depends on whether the offerer supports fallback to usage
supports fallback to usage of a separate port for RTCP in case the of a separate port for RTCP in case the answerer moves one or more
answerer does not include the "m=" line in the BUNDLE group. RTP-based "m=" line out of the BUNDLE group in the answer.
NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with a NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with one
bundled "m=" line, but does not associate an SDP 'rtcp-mux-only' or more bundled "m=" lines, but does not associate an SDP 'rtcp-mux-
attribute with the "m=" line, the offerer can also associate an SDP only' attribute, the offerer can also associate an SDP 'rtcp'
'rtcp' attribute [RFC3605] with the "m=" line in order to provide a attribute [RFC3605] with one or more RTP-based "m=" line in order to
fallback port for RTCP, as described in [RFC5761]. However, the provide a fallback port for RTCP, as described in [RFC5761].
fallback port will only be used in case the answerer does not include However, the fallback port will only be used for RTP-based "m=" lines
the "m=" line in the BUNDLE group. moved out of the BUNDLE group by the answerer.
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.1.2. Generating the SDP Answer 10.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer accepts one or When an answerer generates an answer, if the answerer supports RTP-
more RTP-based "m=" lines within a BUNDLE group, the answerer MUST based media, and if a bundled "m=" line in the offer contained an SDP
enable usage of RTP/RTCP multiplexing. The answerer MUST associate 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP
an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the multiplexing, even if there currently are no RTP-based "m=" lines
answer. In addition, if an "m=" line in the corresponding offer within the BUNDLE group. The answerer MUST associate an SDP 'rtcp-
contained an SDP "rtcp-mux-only" attribute, the answerer MUST mux' attribute with "m=" lines within the BUNDLE group in the answer
associate an SDP "rtcp-mux-only" attribute with the "m=" line in the following the procedures for IDENTICAL mux category attributes in
answer. Section 8.1. In addition, if the "m=" line in the offer contained an
an SDP "rtcp-mux-only" attribute, the answerer MUST associate an SDP
If an RTP-based "m=" line in the corresponding offer did not contain "rtcp-mux-only" attribute with the "m=" line in the answer.
an SDP 'rtcp-mux' attribute, the answerer MUST NOT include the "m="
line within a BUNDLE group in the answer.
If an RTP-based "m=" line in the corresponding offer contained an SDP If the "m=" line associated with the offerer BUNDLE-tag in the offer
"rtcp-mux-only" attribute, and if the answerer moves the "m=" line contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves
out of the BUNDLE group in the answer Section 8.3.3, the answerer an RTP-based "m=" line out of the BUNDLE group in the answer
MUST still either enable RTP/RTCP multiplexing for the media Section 8.3.3, the answerer MUST either associate the attribute with
associated with the "m=" line, or reject the "m=" line Section 8.3.4. the moved "m=" line (and enable RTP/RTCP multiplexing for the media
associated with the "m=" line), or reject the "m=" line
Section 8.3.4.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any The answerer MUST NOT associate an SDP 'rtcp' attribute with any "m="
bundled "m=" line in the answer. The answerer will use the port line within the BUNDLE group in the answer. The answerer will use
value of the selected offerer BUNDLE address for sending RTP and RTCP the port value of the selected offerer BUNDLE address for sending RTP
packets associated with each RTP-based bundled "m=" line towards the and RTCP packets associated with each RTP-based bundled "m=" line
offerer. towards the offerer.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer transaction, the answerer MUST negotiated in a previous offer/answer transaction, the answerer MUST
associate an SDP 'rtcp-mux' attribute with each bundled RTP-based associate an SDP 'rtcp-mux' attribute with the "m=" line associated
"m=" line in the answer. with the answerer BUNDLE-tag in the answer. It is not possible to
disable RTP/RTCP multiplexing within a BUNDLE group.
10.3.1.3. Offerer Processing of the SDP Answer 10.3.1.3. 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.1.2), the answerer usage of RTP/RTCP multiplexing (see Section 10.3.1.2), 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.
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines
that the answerer included in the BUNDLE group. that the answerer included in the BUNDLE group.
10.3.1.4. Modifying the Session 10.3.1.4. Modifying the Session
When an offerer generates a subsequent offer, for each RTP-based "m=" When an offerer generates a subsequent offer, the offerer MUST
line that was previously added to the BUNDLE group the offerer MUST associate an SDP 'rtcp-mux' attribute with a bundled "m=" line,
associate an SDP 'rtcp-mux' attribute and an SDP 'rtcp-mux-only' following the procedures for IDENTICAL mux category attributes in
attribute with the "m=" line in the same way it was previously done, Section 8.1.
unless the offerer wants to disable or remove the "m=" line from the
BUNDLE group.
If the offerer wants to add a bundled RTP-based "m=" line to the If the offerer wants to add a bundled RTP-based "m=" line to the
BUNDLE group, it associates an SDP 'rtcp-mux' attribute and an SDP BUNDLE group, it MAY also associate an SDP 'rtcp-mux-only' attribute
'rtcp-mux-only' attribute with the "m=" line using the procedures in with a bundled "m=", following the procedures for IDENTICAL mux
[Section 10.3.1.1]. category attributes in Section 8.1. This allows the offerer to
mandate RTP/RTCP multiplexing for the added "m=" line (or the "m="
line to be rejected by the answerer) even if the answerer does not
accept the "m=" line within the BUNDLE group.
11. ICE Considerations 11. ICE Considerations
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [I-D.ietf-ice-rfc5245bis]. mechanism [I-D.ietf-ice-rfc5245bis].
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
o When BUNDLE addresses for a BUNDLE group have been selected for o When BUNDLE addresses for a BUNDLE group have been selected for
both endpoints, ICE connectivity checks and keep-alives only need both endpoints, ICE connectivity checks and keep-alives only need
to be performed for the whole BUNDLE group, instead of per bundled to be performed for the whole BUNDLE group, instead of per bundled
"m=" line. "m=" line.
o Among bundled "m=" lines with which the offerer has associated a o Among bundled "m=" lines (including any bundle-only "m=" line)
shared address, the offerer only associates ICE-related media- with which the offerer has associated a shared address, the
level SDP attributes with the "m=" line associated with the offerer only associates ICE-related media-level SDP attributes
offerer BUNDLE-tag. with the "m=" line associated with the offerer BUNDLE-tag,
following the procedures in Section 8.1.
o Among bundled "m=" lines with which the answerer has associated a o Among "m=" lines with which the answerer has associated a shared
shared address, the answerer only associates ICE-related media- address within a BUNDLE group, the answerer only associates ICE-
level SDP attributes with the "m=" line associated with the related media-level SDP attributes with the "m=" line associated
answerer BUNDLE-tag. with the answerer BUNDLE-tag, following the procedures in
Section 8.1.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL. is OPTIONAL.
11.1. SDP Offer/Answer Procedures 11.1. SDP Offer/Answer Procedures
When an offerer associates a unique address with a bundled "m=" line When an offerer associates a unique address with a bundled "m=" line
(excluding any bundle-only "m=" line), the offerer MUST associate SDP (excluding any bundle-only "m=" line), the offerer MUST associate SDP
'candidate' attributes (and other applicable ICE-related media-level 'candidate' attributes (and other applicable ICE-related media-level
SDP attributes), containing unique ICE properties (candidates etc), SDP attributes), containing unique ICE properties (candidates etc),
with the "m=" line, according to the procedures in with the "m=" line, according to the procedures in
[I-D.ietf-mmusic-ice-sip-sdp]. [I-D.ietf-mmusic-ice-sip-sdp].
When an offerer associates a shared address with a bundled "m=" line, When an offerer associates a shared address with a bundled "m=" line,
if the "m=" line is associated with the offerer BUNDLE-tag, the the offerer MUST associate SDP 'candidate' attributes (and other
offerer MUST associate SDP 'candidate' attributes (and other applicable ICE-related media-level SDP attributes) with the "m=" line
applicable ICE-related media-level SDP attributes), containing shared following the procedures in Section 8.1.
ICE properties, with the "m=" line. If the "m=" line is not
associated with the offerer BUNDLE-tag, the offerer MUST NOT
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 an "m=" line within
line, if the "m=" line is associated with the answerer BUNDLE-tag, a BUNDLE group, if the answerer MUST associate SDP 'candidate'
the answerer MUST associate SDP 'candidate' attributes (and other attributes (and other applicable ICE-related media-level SDP
applicable ICE-related media-level SDP attributes), containing shared attributes) with the "m=" line following the procedures in
ICE properties, with the "m=" line. If the "m=" line is not Section 8.1.
associated with the answerer BUNDLE-tag, the answerer MUST NOT
associate ICE-related SDP attributes with the "m=" line.
NOTE: As most ICE-related media-level SDP attributes belong to the NOTE: As most ICE-related media-level SDP attributes belong to the
TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the
offerer and answerer follow the rules in Section 8.1. However, in offerer and answerer follow the procedures in Section 8.1 when
the case of ICE-related media-level attributes, the rules apply to deciding whether to associate an attribute with a bundled "m=" line.
all attributes (see note below), even if they belong to a different However, in the case of ICE-related media-level attributes, the rules
mux category. 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.1.1. Generating the Initial SDP Offer 11.1.1. 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 bundled "m="
"m=" line, according to [Section 11.1]. lines forllowin the procedures in [Section 11.1].
11.1.2. Generating the SDP Answer 11.1.2. 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 answerer MUST associate ICE-related SDP attributes with the "m=" the answer MUST associate ICE-related SDP attributes to "m=" lines
line associated with the answerer BUNDLE-tag, according to within the BUNDLE group according to [Section 11.1].
[Section 11.1].
11.1.3. Offerer Processing of the SDP Answer 11.1.3. 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.1], with each bundled address, selected by the answerer [Section 8.3.1], with each bundled
"m=" line. "m=" line.
11.1.4. Modifying the Session 11.1.4. Modifying the Session
When an offerer generates a subsequent offer, it MUST associate When an offerer generates a subsequent offer, it MUST associate ICE
unique or shared ICE properties to one or more bundled "m=" lines, properties to bundled "m=" lines following the procedures in
according to [Section 11.1]. [Section 11.1].
12. DTLS Considerations 12. DTLS Considerations
One or more media streams within a BUNDLE group might use the One or more media streams within a BUNDLE group might use the
Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order
to encrypt the data, or to negotiate encryption keys if another to encrypt the data, or to negotiate encryption keys if another
encryption mechanism is used to encrypt media. encryption mechanism is used to encrypt media.
When DTLS is used within a BUNDLE group, the following rules apply: When DTLS is used within a BUNDLE group, the following rules apply:
skipping to change at page 39, line 46 skipping to change at page 39, line 46
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.2. Example: BUNDLE Extension Rejected 18.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o An offer, in which the offerer associates a unique address with o An offer, in which the offerer associates a unique address with
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
skipping to change at page 42, line 36 skipping to change at page 42, line 36
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 43, line 17 skipping to change at page 43, line 16
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer moves a previous offer/answer transaction), in which the offerer moves a
bundled "m=" line out of a BUNDLE group, associates a unique bundled "m=" line out of a BUNDLE group, associates a unique
skipping to change at page 44, line 17 skipping to change at page 44, line 14
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 50000 RTP/AVP 66 m=video 50000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
skipping to change at page 44, line 44 skipping to change at page 44, line 40
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18.5. Example: Offerer Disables A Media Description Within A BUNDLE 18.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
skipping to change at page 45, line 42 skipping to change at page 45, line 41
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
skipping to change at page 46, line 22 skipping to change at page 46, line 18
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
19. Acknowledgements 19. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
skipping to change at page 47, line 15 skipping to change at page 47, 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.
20. Change Log 20. 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-37
o The following GitHub pull request was merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/33
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36
o The following GitHub pull requests were merged: o The following GitHub pull requests were merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/32 o https://github.com/cdh4u/draft-sdp-bundle/pull/32
o - extmap handling in BUNDLE. o - extmap handling in BUNDLE.
o https://github.com/cdh4u/draft-sdp-bundle/pull/31 o https://github.com/cdh4u/draft-sdp-bundle/pull/31
skipping to change at page 58, line 45 skipping to change at page 58, line 45
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-02 (work in progress), January 2015. mmusic-trickle-ice-02 (work in progress), January 2015.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-03 (work in progress), Message", draft-ietf-avtext-lrr-04 (work in progress),
July 2016. April 2017.
Appendix A. Design Considerations Appendix A. Design Considerations
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 specified by 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
 End of changes. 50 change blocks. 
139 lines changed or deleted 143 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/