draft-ietf-mmusic-sdp-bundle-negotiation-52.txt   draft-ietf-mmusic-sdp-bundle-negotiation-53.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264,7941 (if approved) H. Alvestrand Updates: 3264,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: November 25, 2018 C. Jennings Expires: March 24, 2019 C. Jennings
Cisco Cisco
May 24, 2018 September 20, 2018
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-52.txt draft-ietf-mmusic-sdp-bundle-negotiation-53.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 transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 25, 2018. This Internet-Draft will expire on March 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 4, line 11 skipping to change at page 4, line 11
17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42 17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42
17.3. Example: Offerer Adds a Media Description to a BUNDLE 17.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.4. Example: Offerer Moves a Media Description Out of a 17.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
17.5. Example: Offerer Disables a Media Description Within a 17.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
20.1. Normative References . . . . . . . . . . . . . . . . . . 61 20.1. Normative References . . . . . . . . . . . . . . . . . . 62
20.2. Informative References . . . . . . . . . . . . . . . . . 64 20.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 66
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
1.1. Background 1.1. Background
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
the establishment of multimedia communication sessions, if separate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media transports (5-tuples) are negotiated for each individual media
stream, each transport consumes additional resources (especially when stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE) [RFC8445] is used). For
[I-D.ietf-ice-rfc5245bis] is used). For this reason, it is this reason, it is attractive to use a single transport for multiple
attractive to use a single transport for multiple media streams. media streams.
1.2. BUNDLE Mechanism 1.2. BUNDLE Mechanism
This specification defines a way to use a single transport (BUNDLE This specification defines a way to use a single transport (BUNDLE
transport) for sending and receiving media (bundled media) described transport) for sending and receiving media (bundled media) described
by multiple SDP media descriptions ("m=" sections). The address:port by multiple SDP media descriptions ("m=" sections). The address:port
combination used by an endpoint for sending and receiving bundled combination used by an endpoint for sending and receiving bundled
media is referred to as the BUNDLE address:port. The set of SDP media is referred to as the BUNDLE address:port. The set of SDP
attributes that are applied to each "m=" section within a BUNDLE attributes that are applied to each "m=" section within a BUNDLE
group is referred to as BUNDLE attributes. The same BUNDLE transport group is referred to as BUNDLE attributes. The same BUNDLE transport
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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 which "m=" sections will become part of a BUNDLE group. to negotiate which "m=" sections will become part of a BUNDLE group.
In addition, the offerer and answerer [RFC3264] use the BUNDLE In addition, the offerer and answerer [RFC3264] use the BUNDLE
extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE
address:port and answerer BUNDLE address:port) and the set of BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE
attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) attributes (offerer BUNDLE attributes and answerer BUNDLE attributes)
that will be applied to each "m=" section within the BUNDLE group. that will be applied to each "m=" section within the BUNDLE group.
The use of a BUNDLE transport allows the usage of a single set of The use of a BUNDLE transport allows the usage of a single set of
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE) [RFC8445] candidates for
[I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. the whole BUNDLE group.
A given BUNDLE address:port MUST only be associated with a single A given BUNDLE address:port MUST only be associated with a single
BUNDLE group. If an SDP offer or answer contains multiple BUNDLE BUNDLE group. If an SDP offer or answer contains multiple BUNDLE
groups, the procedures in this specification apply to each group groups, the procedures in this specification apply to each group
independently. All RTP-based bundled media associated with a given independently. All RTP-based bundled media associated with a given
BUNDLE group belong to a single RTP session [RFC3550]. BUNDLE 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 assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
skipping to change at page 10, line 33 skipping to change at page 10, line 33
SDP parameters and characteristics (including those associated with a SDP parameters and characteristics (including those associated with a
BUNDLE group) apply. Hence, if an offerer generates an offer in BUNDLE group) apply. Hence, if an offerer generates an offer in
order to negotiate a BUNDLE group, and the answerer rejects the order to negotiate a BUNDLE group, and the answerer rejects the
offer, the BUNDLE group is not created. offer, the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section. Section 9 "m=" line proto value assigned to a bundled "m=" section. Section 9
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 10 defines additional considerations for only' attribute. Section 10 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE) [RFC8445]
[I-D.ietf-ice-rfc5245bis] mechanism. mechanism.
Offers and answers can contain multiple BUNDLE groups. The 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.
7.1. Generic SDP Considerations 7.1. Generic SDP Considerations
This section describes generic restrictions associated with the usage This section describes generic restrictions associated with the usage
of SDP parameters within a BUNDLE group. It also describes how to of SDP parameters within a BUNDLE group. It also describes how to
calculate a value for the whole BUNDLE group, when parameter and calculate a value for the whole BUNDLE group, when parameter and
skipping to change at page 14, line 21 skipping to change at page 14, line 21
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
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=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
7.3. Generating the SDP Answer 7.3. Generating the SDP Answer
When an answerer generates an answer (initial BUNDLE answer or When an answerer generates an answer (initial BUNDLE answer or
subsequent) that contains a BUNDLE group the following general SDP subsequent) that contains a BUNDLE group the following general SDP
grouping framework restrictions, defined in [RFC5888], also apply to grouping framework restrictions, defined in [RFC5888], also apply to
the BUNDLE group: the BUNDLE group:
o The answerer is only allowed to include a BUNDLE group in an o The answerer is only allowed to include a BUNDLE group in an
initial BUNDLE answer if the offerer requested the BUNDLE group to initial BUNDLE answer if the offerer requested the BUNDLE group to
skipping to change at page 19, line 19 skipping to change at page 19, line 19
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
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 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
7.4. Offerer Processing of the SDP Answer 7.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=" section in the group, the offerer MUST check that any bundled "m=" section 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 apply the properties (BUNDLE is no mismatch, the offerer MUST apply the properties (BUNDLE
address:port, BUNDLE attributes etc) of the offerer tagged "m=" address:port, BUNDLE attributes etc) of the offerer tagged "m="
section (selected by the answerer [Section 7.3.1]) to each bundled section (selected by the answerer [Section 7.3.1]) to each bundled
"m=" section within the BUNDLE group. "m=" section within the BUNDLE group.
skipping to change at page 32, line 22 skipping to change at page 32, line 22
When an offerer generates a subsequent offer, the offerer MUST When an offerer generates a subsequent offer, the offerer MUST
include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" include an SDP 'rtcp-mux' attribute in the offerer tagged "m="
section, following the procedures for IDENTICAL multiplexing category section, following the procedures for IDENTICAL multiplexing category
attributes in Section 7.1.3. attributes in Section 7.1.3.
10. ICE Considerations 10. 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 [RFC8445].
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 the BUNDLE transport has been established, ICE connectivity o When the BUNDLE transport has been established, ICE connectivity
checks and keep-alives only need to be performed for the BUNDLE checks and keep-alives only need to be performed for the BUNDLE
transport, instead of per individual bundled "m=" section within transport, instead of per individual bundled "m=" section within
the BUNDLE group. the BUNDLE group.
skipping to change at page 42, line 10 skipping to change at page 42, line 10
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
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=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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
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 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
17.2. Example: BUNDLE Group Rejected 17.2. Example: BUNDLE Group Rejected
The example below shows: The example below shows:
o An initial BUNDLE offer, in which the offerer wants to negotiate a o An initial BUNDLE offer, in which the offerer wants to negotiate a
BUNDLE group, and indicates the audio m= section as the suggested BUNDLE group, and indicates the audio m= section as the suggested
offerer tagged "m=" section. offerer tagged "m=" section.
o An initial BUNDLE answer, in which the answerer rejects the o An initial BUNDLE answer, in which the answerer rejects the
skipping to change at page 44, line 21 skipping to change at page 44, line 21
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
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=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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
skipping to change at page 45, line 35 skipping to change at page 45, line 35
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 8 97 m=audio 0 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only a=bundle-only
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 0 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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 10000 RTP/AVP 66 m=video 10000 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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only a=bundle-only
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 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer, in which the offerer removes a "m=" section o A subsequent offer, in which the offerer removes a "m=" section
(video), indicated by the "zen" identification-tag, from a (video), indicated by the "zen" identification-tag, from a
previously negotiated BUNDLE group, indicates one of the bundled previously negotiated BUNDLE group, indicates one of the bundled
"m=" sections (audio) remaining in the BUNDLE group as the offerer "m=" sections (audio) remaining in the BUNDLE group as the offerer
tagged "m=" section and assigns the offerer BUNDLE address:port to tagged "m=" section and assigns the offerer BUNDLE address:port to
skipping to change at page 47, line 21 skipping to change at page 47, line 21
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
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 0 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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)
v=0 v=0
skipping to change at page 47, line 51 skipping to change at page 47, line 51
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
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 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
17.5. Example: Offerer Disables a Media Description Within a BUNDLE 17.5. Example: Offerer Disables a Media Description Within a BUNDLE
Group Group
skipping to change at page 49, line 5 skipping to change at page 49, line 5
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
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 0 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
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 0 RTP/AVP 32 m=video 0 RTP/AVP 32
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
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
18. Acknowledgements 18. 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 similar alternatives proposed by Harald Alvestrand and is based on similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
skipping to change at page 50, line 41 skipping to change at page 50, line 41
Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Linda Dunbar for performing the Gen-ART review.
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-52
o Editorial fix: colon added to exmap attribute examples.
o Reference updates.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51
o Changes based on IESG reviews. o Changes based on IESG reviews.
o - Clarification of 'initial offer' terminology. o - Clarification of 'initial offer' terminology.
o - Merging of tagged m- section selection sections. o - Merging of tagged m- section selection sections.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
skipping to change at page 63, line 23 skipping to change at page 63, line 34
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
[I-D.ietf-ice-rfc5245bis] [RFC8445] 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", RFC 8445,
rfc5245bis-20 (work in progress), March 2018. DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), December 2016. (work in progress), February 2018.
[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-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in
progress), April 2018. progress), June 2018.
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Trickle ICE", Session Initiation Protocol (SIP) Usage for Incremental
draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), Provisioning of Candidates for the Interactive
February 2018. Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018.
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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
 End of changes. 41 change blocks. 
51 lines changed or deleted 58 lines changed or added

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