< draft-ietf-mmusic-rfc8843bis-05.txt   draft-ietf-mmusic-rfc8843bis-06.txt >
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 8843 (if approved) H. Alvestrand Obsoletes: 8843 (if approved) H. Alvestrand
Updates: 3264, 5888, 7941 (if approved) Google Updates: 3264, 5888, 7941 (if approved) Google
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: 10 March 2022 Cisco Expires: 21 May 2022 Cisco
6 September 2021 17 November 2021
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-rfc8843bis-05 draft-ietf-mmusic-rfc8843bis-06
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension called 'BUNDLE'. The extension can be Grouping Framework extension called 'BUNDLE'. The extension can be
used with the SDP offer/answer mechanism to negotiate the usage of a used 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 1, line 48 skipping to change at page 1, line 48
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 10 March 2022. This Internet-Draft will expire on 21 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 8 skipping to change at page 3, line 8
7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11
7.2. Generating the Initial BUNDLE Offer . . . . . . . . . . . 12 7.2. Generating the Initial BUNDLE Offer . . . . . . . . . . . 12
7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13 7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13
7.2.2. Example: Initial BUNDLE Offer . . . . . . . . . . . . 14 7.2.2. Example: Initial BUNDLE Offer . . . . . . . . . . . . 14
7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 15 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 15
7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 17 7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 17
7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17 7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17
7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18
7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19
7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20
7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 21 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20
7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21 7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22
7.5.1. Adding a Media Description to a BUNDLE Group . . . . 23 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22
7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23
7.5.3. Disabling a Media Description in a BUNDLE Group . . . 24 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23
7.6. SIP Considerations . . . . . . . . . . . . . . . . . . . 24 7.6. 3PCC Considerations . . . . . . . . . . . . . . . . . . . 24
8. Protocol Identification . . . . . . . . . . . . . . . . . . . 25 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24
8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25
9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 26 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 27 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26
9.2. Associating RTP/RTCP Streams with the Correct SDP Media 9.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . . 27 Description . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33
9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33
10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36
12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 37 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 37
13.1. Original Text from RFC 3264, Section 5.1, 2nd 13.1. Original Text from RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 13.2. New Text Replacing RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
13.3. Original Text from RFC 3264, Section 8.4, 6th 13.3. Original Text from RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
13.4. New Text Replacing RFC 3264, Section 8.4, 6th 13.4. New Text Replacing RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 39 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 39
14.1. Original Text from RFC 5888, Section 9.2, 3rd 14.1. Original Text from RFC 5888, Section 9.2, 3rd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39
14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39
15. RTP/RTCP Extensions for identification-tag Transport . . . . 39 15. RTP/RTCP Extensions for identification-tag Transport . . . . 39
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 41 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43
17. Security Considerations . . . . . . . . . . . . . . . . . . . 43 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44
18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 46 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 46
skipping to change at page 6, line 44 skipping to change at page 6, line 44
to only one "m=" section in an offer or answer. to only one "m=" section in an offer or answer.
Offerer BUNDLE-tag: The first identification-tag in a given SDP Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
Answerer BUNDLE-tag: The first identification-tag in a given SDP Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
Suggested offerer-tagged "m=" section: The bundled "m=" section Suggested offerer-tagged "m=" section: The bundled "m=" section
identified by the offerer BUNDLE-tag in an initial BUNDLE identified by the offerer BUNDLE-tag in an initial BUNDLE
offer, before a BUNDLE group has been negotiated. Offer, before a BUNDLE group has been negotiated.
Offerer-tagged "m=" section: The bundled "m=" section identified Offerer-tagged "m=" section: The bundled "m=" section identified
by the offerer BUNDLE-tag in a subsequent offer. The "m=" by the offerer BUNDLE-tag in a subsequent offer. The "m="
section contains characteristics (offerer BUNDLE address:port section contains characteristics (offerer BUNDLE address:port
and offerer BUNDLE attributes) that are applied to each "m=" and offerer BUNDLE attributes) that are applied to each "m="
section within the BUNDLE group. section within the BUNDLE group.
Answerer-tagged "m=" section: The bundled "m=" section identified Answerer-tagged "m=" section: The bundled "m=" section identified
by the answerer BUNDLE-tag in an answer (initial BUNDLE answer by the answerer BUNDLE-tag in an answer (initial BUNDLE answer
or subsequent). The "m=" section contains characteristics or subsequent). The "m=" section contains characteristics
skipping to change at page 7, line 50 skipping to change at page 7, line 50
Bundled "m=" section: An "m=" section, whose identification-tag Bundled "m=" section: An "m=" section, whose identification-tag
is placed in an SDP 'group:BUNDLE' attribute identification-tag is placed in an SDP 'group:BUNDLE' attribute identification-tag
list in an offer or answer. list in an offer or answer.
Bundle-only "m=" section: A bundled "m=" section that contains an Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute. SDP 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial BUNDLE offer: The first offer, within an SDP session Initial BUNDLE Offer: The first offer, within an SDP session
(e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP),
in which the offerer indicates that it wants to negotiate a in which the offerer indicates that it wants to negotiate a
given BUNDLE group. given BUNDLE group.
Initial BUNDLE answer: The answer to an initial BUNDLE offer in Initial BUNDLE answer: The answer to an initial BUNDLE Offer in
which the offerer indicates that it wants to negotiate a BUNDLE which the offerer indicates that it wants to negotiate a BUNDLE
group, and the answerer accepts the creation of the BUNDLE group, and the answerer accepts the creation of the BUNDLE
group. The BUNDLE group is created once the answerer sends the group. The BUNDLE group is created once the answerer sends the
initial BUNDLE answer. initial BUNDLE answer.
Subsequent offer: An offer that contains a BUNDLE group that has Subsequent offer: An offer that contains a BUNDLE group that has
been created as part of a previous offer/answer exchange. been created as part of a previous offer/answer exchange.
Subsequent answer: An answer to a subsequent offer. Subsequent answer: An answer to a subsequent offer.
skipping to change at page 11, line 37 skipping to change at page 11, line 37
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [RFC8859] for associating the SDP bandwidth ("b=") line with in [RFC8859] for associating the SDP bandwidth ("b=") line with
bundled "m=" sections. bundled "m=" sections.
7.1.3. Attributes ("a=") 7.1.3. Attributes ("a=")
An offerer and answerer MUST include SDP attributes in every bundled An offerer and answerer MUST include SDP attributes in every bundled
"m=" section where applicable, following the normal offer/answer "m=" section where applicable, following the normal offer/answer
procedures for each attribute, with the following exceptions: procedures for each attribute, with the following exceptions:
* In the initial BUNDLE offer, the offerer MUST NOT include * In the initial BUNDLE Offer, the offerer MUST NOT include
IDENTICAL and TRANSPORT multiplexing category SDP attributes IDENTICAL and TRANSPORT multiplexing category SDP attributes
(BUNDLE attributes) in bundle-only "m=" sections. The offerer (BUNDLE attributes) in bundle-only "m=" sections. The offerer
MUST include such attributes in all other bundled "m=" sections. MUST include such attributes in all other bundled "m=" sections.
In the initial BUNDLE offer, each bundled "m=" line can contain a In the initial BUNDLE Offer, each bundled "m=" line can contain a
different set of BUNDLE attributes and attribute values. Once the different set of BUNDLE attributes and attribute values. Once the
offerer-tagged "m=" section has been selected, the BUNDLE offerer-tagged "m=" section has been selected, the BUNDLE
attributes contained in the offerer-tagged "m=" section will apply attributes contained in the offerer-tagged "m=" section will apply
to each bundled "m=" section within the BUNDLE group. to each bundled "m=" section within the BUNDLE group.
* In a subsequent offer, or in an answer (initial or subsequent), * In a subsequent offer, or in an answer (initial or subsequent),
the offerer and answerer MUST include IDENTICAL and TRANSPORT the offerer and answerer MUST include IDENTICAL and TRANSPORT
multiplexing category SDP attributes (BUNDLE attributes) only in multiplexing category SDP attributes (BUNDLE attributes) only in
the tagged "m=" section (offerer-tagged "m=" section or answerer- the tagged "m=" section (offerer-tagged "m=" section or answerer-
tagged "m=" section). The offerer and answerer MUST NOT include tagged "m=" section). The offerer and answerer MUST NOT include
such attributes in any other bundled "m=" section. The BUNDLE such attributes in any other bundled "m=" section. The BUNDLE
attributes contained in the tagged "m=" section will apply to each attributes contained in the tagged "m=" section will apply to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
* In an offer (initial BUNDLE offer or subsequent), or in an answer * In an offer (initial BUNDLE Offer or subsequent), or in an answer
(initial BUNDLE answer or subsequent), the offerer and answerer (initial BUNDLE answer or subsequent), the offerer and answerer
MUST include SDP attributes from categories other than IDENTICAL MUST include SDP attributes from categories other than IDENTICAL
and TRANSPORT in each bundled "m=" section that a given attribute and TRANSPORT in each bundled "m=" section that a given attribute
applies to. Each bundled "m=" line can contain a different set of applies to. Each bundled "m=" line can contain a different set of
such attributes, and attribute values, as such attributes only such attributes, and attribute values, as such attributes only
apply to the given bundled "m=" section in which they are apply to the given bundled "m=" section in which they are
included. included.
NOTE: A consequence of the rules above is that media-specific NOTE: A consequence of the rules above is that media-specific
IDENTICAL and TRANSPORT multiplexing category SDP attributes that are IDENTICAL and TRANSPORT multiplexing category SDP attributes that are
skipping to change at page 12, line 40 skipping to change at page 12, line 40
within the BUNDLE group does describe RTP-based media). within the BUNDLE group does describe RTP-based media).
7.2. Generating the Initial BUNDLE Offer 7.2. Generating the Initial BUNDLE Offer
The procedures in this section apply to the first offer, within an The procedures in this section apply to the first offer, within an
SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry
SDP), in which the offerer indicates that it wants to negotiate a SDP), in which the offerer indicates that it wants to negotiate a
given BUNDLE group. This could occur in the initial offer, or in a given BUNDLE group. This could occur in the initial offer, or in a
subsequent offer, of the SDP session. subsequent offer, of the SDP session.
When an offerer generates an initial BUNDLE offer, in order to When an offerer generates an initial BUNDLE Offer, in order to
negotiate a BUNDLE group, it MUST: negotiate a BUNDLE group, it MUST:
* Assign a unique address:port to each bundled "m=" section, * Assign a unique address:port to each bundled "m=" section,
following the procedures in [RFC3264], excluding any bundle-only following the procedures in [RFC3264], excluding any bundle-only
"m=" sections (see below); "m=" sections (see below);
* Pick a bundled "m=" section as the suggested offerer-tagged "m=" * Pick a bundled "m=" section as the suggested offerer-tagged "m="
(Section 7.2.1); (Section 7.2.1);
* Include SDP attributes in the bundled "m=" sections following the * Include SDP attributes in the bundled "m=" sections following the
skipping to change at page 13, line 32 skipping to change at page 13, line 32
* Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m="
section, and section, and
* Assign a zero port value to the "m=" section. * Assign a zero port value to the "m=" section.
NOTE: If the offerer assigns a zero port value to a bundled "m=" NOTE: If the offerer assigns a zero port value to a bundled "m="
section, but does not include an SDP 'bundle-only' attribute in the section, but does not include an SDP 'bundle-only' attribute in the
"m=" section, it is an indication that the offerer wants to disable "m=" section, it is an indication that the offerer wants to disable
the "m=" section (Section 7.5.3). the "m=" section (Section 7.5.3).
Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. Sections 7.2.2 and 18.1 show an example of an initial BUNDLE Offer.
7.2.1. Suggesting the Offerer-Tagged 'm=' Section 7.2.1. Suggesting the Offerer-Tagged 'm=' Section
In the initial BUNDLE offer, the bundled "m=" section indicated by In the initial BUNDLE Offer, the bundled "m=" section indicated by
the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section.
The address:port combination associated with the "m=" section will be The address:port combination associated with the "m=" section will be
used by the offerer for sending and receiving bundled media if the used by the offerer for sending and receiving bundled media if the
answerer selects the "m=" section as the offerer-tagged "m=" section answerer selects the "m=" section as the offerer-tagged "m=" section
(Section 7.3.1). In addition, if the answerer selects the "m=" (Section 7.3.1). In addition, if the answerer selects the "m="
section as the offerer-tagged "m=" section, the BUNDLE attributes section as the offerer-tagged "m=" section, the BUNDLE attributes
included in the "m=" section will be applied to each "m=" section included in the "m=" section will be applied to each "m=" section
within the negotiated BUNDLE group. within the negotiated BUNDLE group.
The offerer MUST NOT suggest a bundle-only "m=" section as the The offerer MUST NOT suggest a bundle-only "m=" section as the
offerer-tagged "m=" section. offerer-tagged "m=" section.
It is RECOMMENDED that the suggested offerer-tagged "m=" section be a It is RECOMMENDED that the suggested offerer-tagged "m=" section be a
bundled "m=" section that the offerer believes is unlikely that the bundled "m=" section that the offerer believes is unlikely that the
answerer will reject or move out of the BUNDLE group. How such answerer will reject or move out of the BUNDLE group. How such
assumption is made is outside the scope of this document. assumption is made is outside the scope of this document.
7.2.2. Example: Initial BUNDLE Offer 7.2.2. Example: Initial BUNDLE Offer
The following example shows an initial BUNDLE offer. The offer The following example shows an initial BUNDLE Offer. The offer
includes two "m=" sections in the offer and suggests that both "m=" includes two "m=" sections in the offer and suggests that both "m="
sections are included in a BUNDLE group. The audio "m=" section is sections are included in a BUNDLE group. The audio "m=" section is
the suggested offerer-tagged "m=" section, indicated by placing the the suggested offerer-tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (offerer BUNDLE- identification-tag associated with the "m=" section (offerer BUNDLE-
tag) first in the SDP group:BUNDLE attribute identification-id list. tag) first in the SDP group:BUNDLE attribute identification-id list.
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
skipping to change at page 14, line 40 skipping to change at page 14, line 40
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
The following example shows an initial BUNDLE offer. The offer The following example shows an initial BUNDLE Offer. The offer
includes two "m=" sections in the offer and suggests that both "m=" includes two "m=" sections in the offer and suggests that both "m="
sections are included in a BUNDLE group. The offerer includes an SDP sections are included in a BUNDLE group. The offerer includes an SDP
'bundle-only' attribute in the video "m=" section, to request that 'bundle-only' attribute in the video "m=" section, to request that
the answerer accepts the "m=" section only if the answerer supports the answerer accepts the "m=" section only if the answerer supports
the BUNDLE extension and if the answerer keeps the "m=" section the BUNDLE extension and if the answerer keeps the "m=" section
within the associated BUNDLE group. The audio "m=" section is the within the associated BUNDLE group. The audio "m=" section is the
suggested offerer-tagged "m=" section, indicated by placing the suggested offerer-tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (offerer BUNDLE- identification-tag associated with the "m=" section (offerer BUNDLE-
tag) first in the SDP group:BUNDLE attribute identification-id list. tag) first in the SDP group:BUNDLE attribute identification-id list.
skipping to change at page 15, line 37 skipping to change at page 15, line 37
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:
* The answerer is only allowed to include a BUNDLE group in an * 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
be created in the corresponding initial BUNDLE offer; be created in the corresponding initial BUNDLE Offer;
* The answerer is only allowed to include a BUNDLE group in a * The answerer is only allowed to include a BUNDLE group in a
subsequent answer if the corresponding subsequent offer contains a subsequent answer if the corresponding subsequent offer contains a
previously negotiated BUNDLE group; previously negotiated BUNDLE group;
* The answerer is only allowed to include a bundled "m=" section in * The answerer is only allowed to include a bundled "m=" section in
an answer if the "m=" section was indicated as bundled in the an answer if the "m=" section was indicated as bundled in the
corresponding offer; and corresponding offer; and
* The answerer is only allowed to include a bundled "m=" section in * The answerer is only allowed to include a bundled "m=" section in
skipping to change at page 21, line 16 skipping to change at page 21, line 7
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 (for the answer was indicated as bundled in the corresponding offer (for the
same BUNDLE group). If there is no mismatch, the offerer MUST apply same BUNDLE group). If there is no mismatch, the offerer MUST apply
the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the
offerer-tagged "m=" section (selected by the answerer; see offerer-tagged "m=" section (selected by the answerer; see
Section 7.3.1) to each bundled "m=" section within the BUNDLE group. Section 7.3.1) to each bundled "m=" section within the BUNDLE group.
NOTE: As the answerer might reject one or more bundled "m=" sections NOTE: As the answerer might reject one or more bundled "m=" sections
in an initial BUNDLE offer, or move a bundled "m=" section out of a in an initial BUNDLE Offer, or move a bundled "m=" section out of a
BUNDLE group, a given bundled "m=" section in the offer might not be BUNDLE group, a given bundled "m=" section in the offer might not be
indicated as bundled in the corresponding answer. indicated as bundled in the corresponding answer.
If the answer does not contain a BUNDLE group, the offerer MUST If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer. process the answer as a normal answer.
7.4.1. RFC 8843 Considerations 7.4.1. RFC 8843 Considerations
In RFC 8843, instead of assigning the answerer BUNDLE address:port to In RFC 8843, instead of assigning the answerer BUNDLE address:port to
each "m=" section within the BUNDLE group when generating the SDP each "m=" section within the BUNDLE group when generating the SDP
skipping to change at page 24, line 36 skipping to change at page 24, line 14
* MUST NOT assign an SDP 'bundle-only' attribute to the "m=" * MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
For the other bundled "m=" sections within the BUNDLE group, the For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in Section 7.5. offerer follows the procedures in Section 7.5.
Section 18.5 shows an example of an offer and answer for disabling an Section 18.5 shows an example of an offer and answer for disabling an
"m=" section within a BUNDLE group. "m=" section within a BUNDLE group.
7.6. SIP Considerations 7.6. 3PCC Considerations
In some 3rd Party Call Control (3PCC) scenarios a new session will be
established between an endpoint that is currently part of an ongoing
session and an endpoint that is currently not part of an ongoing
session. The endpoint that is part of a session will generate a
subsequent SDP Offer that will be forwarded to the other endpoint by
a 3PCC controller. The endpoint that is not part of a session will
process the Offer as an initial SDP Offer.
The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent
Client (UAC) to send a re-INVITE request without an SDP body Client (UAC) to send a re-INVITE request without an SDP body
(sometimes referred to as an empty re-INVITE). In such cases, the (sometimes referred to as an empty re-INVITE). In such cases, the
User Agent Server (UAS) will include an SDP Offer in the associated User Agent Server (UAS) will include an SDP Offer in the associated
200 OK response. This is typically used for 3rd Party Call Control 200 (OK) response. If the UAS is a part of an ongoing SIP session,
(3PCC) scenarios. From a BUNDLE perspective, such SDP Offer SHOULD it will include a subsequent offer in the 200 (OK) response. The
be generated using the procedures defined in Section 7.2. offer will be received by a 3PCC controller (UAC) and then forwarded
to another User Agent (UA). If the UA is not part of an ongoing SIP
session, it will process the offer as an initial SDP Offer.
When the BUNDLE mechanism is used, an initial BUNDLE Offer is
constructed using different rules than subsequent BUNDLE Offers, and
it cannot be assumed that a UA is able to correctly process a
subsequent BUNDLE Offer as an initial BUNDLE Offer. Therefore, the
3PCC controller SHOULD rewrite the subsequent BUNDLE Offer into a
valid initial BUNDLE Offer, following the procedures in Section 7.2,
before it forwards the BUNDLE Offer to a UA. In the rewritten BUNDLE
Offer the 3PCC controller will set the port value to zero (and
include an SDP 'bundle-only' attribute) for each "m=" section within
the BUNDLE group, excluding the offerer-tagged "m=" section.
8. Protocol Identification 8. Protocol Identification
Each "m=" section within a BUNDLE group MUST use the same transport- Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different upper-layer layer protocol. If bundled "m=" sections use different upper-layer
protocols on top of the transport-layer protocol, there MUST exist a protocols on top of the transport-layer protocol, there MUST exist a
publicly available specification that describes how a mechanism publicly available specification that describes how a mechanism
associates received data with the correct protocol for this associates received data with the correct protocol for this
particular protocol combination. particular protocol combination.
skipping to change at page 33, line 33 skipping to change at page 33, line 27
negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media.
RTP/RTCP multiplexing only applies to RTP-based media. However, as RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 7.1.3, within an offer or answer the SDP 'rtcp- described in Section 7.1.3, within an offer or answer the SDP 'rtcp-
mux' and SDP 'rtcp-mux-only' attributes might be included in a mux' and SDP 'rtcp-mux-only' attributes might be included in a
bundled "m=" section for non-RTP-based media (if such "m=" section is bundled "m=" section for non-RTP-based media (if such "m=" section is
the offerer-tagged "m=" section or answerer-tagged "m=" section). the offerer-tagged "m=" section or answerer-tagged "m=" section).
9.3.1.1. Generating the Initial BUNDLE Offer 9.3.1.1. Generating the Initial BUNDLE Offer
When an offerer generates an initial BUNDLE offer, if the offer When an offerer generates an initial BUNDLE Offer, if the offer
contains one or more bundled "m=" sections for RTP-based media (or, contains one or more bundled "m=" sections for RTP-based media (or,
if there is a chance that "m=" sections for RTP-based media will if there is a chance that "m=" sections for RTP-based media will
later be added to the BUNDLE group), the offerer MUST include an SDP later be added to the BUNDLE group), the offerer MUST include an SDP
'rtcp-mux' attribute [RFC5761] in each bundled "m=" section 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section
(excluding any bundle-only "m=" sections). In addition, the offerer (excluding any bundle-only "m=" sections). In addition, the offerer
MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more
bundled "m=" sections for RTP-based media. bundled "m=" sections for RTP-based media.
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
depends on whether the offerer supports fallback to usage of a depends on whether the offerer supports fallback to usage of a
skipping to change at page 34, line 4 skipping to change at page 33, line 46
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
depends on whether the offerer supports fallback to usage of a depends on whether the offerer supports fallback to usage of a
separate port for RTCP in case the answerer moves one or more "m=" separate port for RTCP in case the answerer moves one or more "m="
sections for RTP-based media out of the BUNDLE group in the answer. sections for RTP-based media out of the BUNDLE group in the answer.
NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the
bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' bundled "m=" sections, but does not include an SDP 'rtcp-mux-only'
attribute, the offerer can also include an SDP 'rtcp' attribute attribute, the offerer can also include an SDP 'rtcp' attribute
[RFC3605] in one or more RTP-based bundled "m=" sections in order to [RFC3605] in one or more RTP-based bundled "m=" sections in order to
provide a fallback port for RTCP, as described in [RFC5761]. provide a fallback port for RTCP, as described in [RFC5761].
However, the fallback port will only be applied to "m=" sections for However, the fallback port will only be applied to "m=" sections for
RTP-based media that are moved out of the BUNDLE group by the RTP-based media that are moved out of the BUNDLE group by the
answerer. answerer.
In the initial BUNDLE offer, the address:port combination for RTCP In the initial BUNDLE Offer, the address:port combination for RTCP
MUST be unique in each bundled "m=" section for RTP-based media MUST be unique in each bundled "m=" section for RTP-based media
(excluding a bundle-only "m=" section), similar to RTP. (excluding a bundle-only "m=" section), similar to RTP.
9.3.1.2. Generating the SDP Answer 9.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer supports RTP- When an answerer generates an answer, if the answerer supports RTP-
based media, and if a bundled "m=" section in the corresponding offer based media, and if a bundled "m=" section in the corresponding offer
contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage
of RTP/RTCP multiplexing, even if there currently are no bundled "m=" of RTP/RTCP multiplexing, even if there currently are no bundled "m="
sections for RTP-based media within the BUNDLE group. The answerer sections for RTP-based media within the BUNDLE group. The answerer
MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m="
section, following the procedures for BUNDLE attributes section, following the procedures for BUNDLE attributes
(Section 7.1.3). In addition, if the "m=" section that is selected (Section 7.1.3). In addition, if the "m=" section that is selected
as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only'
attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute
in the answerer-tagged "m=" section. in the answerer-tagged "m=" section.
In an initial BUNDLE offer, if the suggested offerer-tagged "m=" In an initial BUNDLE Offer, if the suggested offerer-tagged "m="
section contained an SDP 'rtcp-mux-only' attribute, the "m=" section section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
was for RTP-based media. If the answerer does not accept the "m=" was for RTP-based media. If the answerer does not accept the "m="
section in the created BUNDLE group, and moves the "m=" section out section in the created BUNDLE group, and moves the "m=" section out
of the BUNDLE group (Section 7.3.2), the answerer MUST include the of the BUNDLE group (Section 7.3.2), the answerer MUST include the
attribute in the moved "m=" section and enable RTP/RTCP multiplexing attribute in the moved "m=" section and enable RTP/RTCP multiplexing
for the media associated with the "m=" section. If the answerer for the media associated with the "m=" section. If the answerer
rejects the "m=" section (Section 7.3.3) the answerer MUST NOT rejects the "m=" section (Section 7.3.3) the answerer MUST NOT
include the attribute. include the attribute.
The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled
skipping to change at page 35, line 41 skipping to change at page 35, line 28
defined in [RFC8839], also apply to the usage of ICE with BUNDLE, defined in [RFC8839], also apply to the usage of ICE with BUNDLE,
with the following exceptions: with the following exceptions:
* When the BUNDLE transport has been established, ICE connectivity * When the BUNDLE transport has been established, ICE connectivity
checks and keepalives only need to be performed for the BUNDLE checks and keepalives 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.
* The generic SDP attribute offer/answer considerations * The generic SDP attribute offer/answer considerations
(Section 7.1.3) also apply to ICE-related attributes. Therefore, (Section 7.1.3) also apply to ICE-related attributes. Therefore,
when an offerer sends an initial BUNDLE offer (in order to when an offerer sends an initial BUNDLE Offer (in order to
negotiate a BUNDLE group), the offerer includes ICE-related media- negotiate a BUNDLE group), the offerer includes ICE-related media-
level attributes in each bundled "m=" section (excluding any level attributes in each bundled "m=" section (excluding any
bundle-only "m=" sections), and each "m=" section MUST contain bundle-only "m=" sections), and each "m=" section MUST contain
unique ICE properties. When an answerer generates an answer unique ICE properties. When an answerer generates an answer
(initial BUNDLE answer or subsequent) that contains a BUNDLE (initial BUNDLE answer or subsequent) that contains a BUNDLE
group, and when an offerer sends a subsequent offer that contains group, and when an offerer sends a subsequent offer that contains
a BUNDLE group, ICE-related media-level attributes are only a BUNDLE group, ICE-related media-level attributes are only
included in the tagged "m=" section (suggested offerer-tagged "m=" included in the tagged "m=" section (suggested offerer-tagged "m="
section or answerer-tagged "m=" section), and the ICE properties section or answerer-tagged "m=" section), and the ICE properties
are applied to each bundled "m=" section within the BUNDLE group. are applied to each bundled "m=" section within the BUNDLE group.
skipping to change at page 36, line 29 skipping to change at page 36, line 18
candidate pairs, they form the BUNDLE transport. candidate pairs, they form the BUNDLE transport.
Support and usage of the ICE mechanism together with the BUNDLE Support and usage of the ICE mechanism together with the BUNDLE
extension is OPTIONAL, and the procedures in this section only apply extension is OPTIONAL, and the procedures in this section only apply
when the ICE mechanism is used. Note that applications might mandate when the ICE mechanism is used. Note that applications might mandate
usage of the ICE mechanism even if the BUNDLE extension is not used. usage of the ICE mechanism even if the BUNDLE extension is not used.
NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and
answerer might assign a port value of '9' and an IPv4 address of answerer might assign a port value of '9' and an IPv4 address of
'0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m="
sections in the initial BUNDLE offer. The offerer and answerer will sections in the initial BUNDLE Offer. The offerer and answerer will
follow the normal procedures for generating the offers and answers, follow the normal procedures for generating the offers and answers,
including picking a bundled "m=" section as the suggested offerer- including picking a bundled "m=" section as the suggested offerer-
tagged "m=" section, selecting the tagged "m=" sections, etc. The tagged "m=" section, selecting the tagged "m=" sections, etc. The
only difference is that media cannot be sent until one or more only difference is that media cannot be sent until one or more
candidates have been provided. Once a BUNDLE group has been candidates have been provided. Once a BUNDLE group has been
negotiated, trickled candidates associated with a bundled "m=" negotiated, trickled candidates associated with a bundled "m="
section will be applied to all bundled "m=" sections within the section will be applied to all bundled "m=" sections within the
BUNDLE group. BUNDLE group.
11. DTLS Considerations 11. DTLS Considerations
skipping to change at page 44, line 43 skipping to change at page 44, line 37
"Options for Securing RTP Sessions" [RFC7201], for example, SRTP "Options for Securing RTP Sessions" [RFC7201], for example, SRTP
[RFC3711] can provide the necessary security functions of ensuring [RFC3711] can provide the necessary security functions of ensuring
the integrity and source authenticity. the integrity and source authenticity.
18. Examples 18. Examples
18.1. Example: Tagged "m=" Section Selections 18.1. Example: Tagged "m=" Section Selections
The example below shows: The example below shows:
* An initial BUNDLE offer, in which the offerer wants to negotiate a * 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.
* An initial BUNDLE answer, in which the answerer accepts the * An initial BUNDLE answer, in which the answerer accepts the
creation of the BUNDLE group, selects the audio "m=" section in creation of the BUNDLE group, selects the audio "m=" section in
the offer as the offerer-tagged "m=" section, selects the audio the offer as the offerer-tagged "m=" section, selects the audio
"m=" section in the answer as the answerer-tagged "m=" section, "m=" section in the answer as the answerer-tagged "m=" section,
and assigns the answerer BUNDLE address:port to that "m=" section. and assigns the answerer BUNDLE address:port to that "m=" section.
SDP Offer (1) SDP Offer (1)
skipping to change at page 46, line 9 skipping to change at page 46, line 9
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=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 Group Rejected 18.2. Example: BUNDLE Group Rejected
The example below shows: The example below shows:
* An initial BUNDLE offer, in which the offerer wants to negotiate a * 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.
* An initial BUNDLE answer, in which the answerer rejects the * An initial BUNDLE answer, in which the answerer rejects the
creation of the BUNDLE group, generates a normal answer, and creation of the BUNDLE group, generates a normal answer, and
assigns a unique address:port to each "m=" section in the answer. assigns a unique address:port to each "m=" section in the answer.
SDP Offer (1) SDP Offer (1)
v=0 v=0
 End of changes. 33 change blocks. 
42 lines changed or deleted 62 lines changed or added

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