< draft-ietf-mmusic-rfc8843bis-04.txt   draft-ietf-mmusic-rfc8843bis-05.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: 5 January 2022 Cisco Expires: 10 March 2022 Cisco
4 July 2021 6 September 2021
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-rfc8843bis-04 draft-ietf-mmusic-rfc8843bis-05
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 5 January 2022. This Internet-Draft will expire on 10 March 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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9
7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10
7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11
7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11 7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11
7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11 7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11
7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11
7.2. Generating the Initial SDP 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 SDP 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 . . . . . . . . . . 21
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 . . . . 23
skipping to change at page 6, line 14 skipping to change at page 6, line 14
* updates [RFC5888] by allowing an SDP 'group' attribute to contain * updates [RFC5888] by allowing an SDP 'group' attribute to contain
an identification-tag that identifies an "m=" section with the an identification-tag that identifies an "m=" section with the
port value set to zero. port value set to zero.
1.4. Changes from RFC 8843 1.4. Changes from RFC 8843
When RFC 8843 and [RFC8829] were published an inconsistency between When RFC 8843 and [RFC8829] were published an inconsistency between
the specifications was identified. The procedures regarding the specifications was identified. The procedures regarding
assigning the port value to a bundled "m=" section in an answer assigning the port value to a bundled "m=" section in an answer
(initial or subsequent) and a subsequent offer were inconsistent. At (initial or subsequent) and a subsequent offer were inconsistent.
the IETF 110 meeting it was agreed to publish new versions of the This specification removes the inconsistency by aligning the port
RFCs, in which the inconsistency is removed. This specification value assignment procedure with the procedure in RFC 8829.
removes the inconsistency by aligning the port value assignment
procedure with the procedure in RFC 8829.
In addition, this document implements the following erratas: 6431, In addition, this document implements the following erratas: 6431,
6437 6437
2. Terminology 2. Terminology
"m=" section: SDP bodies contain one or more media descriptions, "m=" section: SDP bodies contain one or more media descriptions,
referred to as "m=" sections. Each "m=" section is represented referred to as "m=" sections. Each "m=" section is represented
by an SDP "m=" line and zero or more SDP attributes associated by an SDP "m=" line and zero or more SDP attributes associated
with the "m=" line. A local address:port combination is with the "m=" line. A local address:port combination is
skipping to change at page 12, line 5 skipping to change at page 12, line 5
* 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 of 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
skipping to change at page 12, line 32 skipping to change at page 12, line 32
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
applicable only to some of the bundled "m=" sections within the applicable only to some of the bundled "m=" sections within the
BUNDLE group might appear in the tagged "m=" section for which they BUNDLE group might appear in the tagged "m=" section for which they
are not applicable. For instance, the tagged "m=" section might are not applicable. For instance, the tagged "m=" section might
contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section
does not describe RTP-based media (but another bundled "m=" section does not describe RTP-based media (but another bundled "m=" section
within the BUNDLE group does describe RTP-based media). within the BUNDLE group does describe RTP-based media).
7.2. Generating the Initial SDP 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:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
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 SDP Offer 7.2.2. Example: Initial BUNDLE Offer
The example shows an initial BUNDLE offer. The offer includes two The following example shows an initial BUNDLE offer. The offer
"m=" sections in the offer and suggests that both "m=" sections are includes two "m=" sections in the offer and suggests that both "m="
included in a BUNDLE group. The audio "m=" section is the suggested sections are included in a BUNDLE group. The audio "m=" section is
offerer-tagged "m=" section, indicated by placing the identification- the suggested offerer-tagged "m=" section, indicated by placing the
tag associated with the "m=" section (offerer BUNDLE-tag) first in identification-tag associated with the "m=" section (offerer BUNDLE-
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
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
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 example shows an initial BUNDLE offer. The offer includes two The following example shows an initial BUNDLE offer. The offer
"m=" sections in the offer and suggests that both "m=" sections are includes two "m=" sections in the offer and suggests that both "m="
included in a BUNDLE group. The offerer includes an SDP 'bundle- sections are included in a BUNDLE group. The offerer includes an SDP
only' attribute in the video "m=" section, to request that the 'bundle-only' attribute in the video "m=" section, to request that
answerer accepts the "m=" section only if the answerer supports the the answerer accepts the "m=" section only if the answerer supports
BUNDLE extension and if the answerer keeps the "m=" section within the BUNDLE extension and if the answerer keeps the "m=" section
the associated BUNDLE group. The audio "m=" section is the suggested within the associated BUNDLE group. The audio "m=" section is the
offerer-tagged "m=" section, indicated by placing the identification- suggested offerer-tagged "m=" section, indicated by placing the
tag associated with the "m=" section (offerer BUNDLE-tag) first in identification-tag associated with the "m=" section (offerer BUNDLE-
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
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
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
skipping to change at page 17, line 29 skipping to change at page 17, line 29
the "m=" section as the offerer-tagged "m=" section and MUST also the "m=" section as the offerer-tagged "m=" section and MUST also
mark the corresponding "m=" section in the answer as the answerer- mark the corresponding "m=" section in the answer as the answerer-
tagged "m=" section. In the answer, the answerer BUNDLE-tag tagged "m=" section. In the answer, the answerer BUNDLE-tag
indicates the answerer-tagged "m=" section. indicates the answerer-tagged "m=" section.
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
pick the next identification-tag in the identification-tag list in pick the next identification-tag in the identification-tag list in
the offer and perform the same criteria check for the "m=" section the offer and perform the same criteria check for the "m=" section
indicated by that identification-tag. If there are no more indicated by that identification-tag. If there are no more
identification-tags in the identification-tag list, the answerer MUST identification-tags in the identification-tag list, the answerer MUST
NOT create the BUNDLE group. Unless the answerer rejects the whole NOT create the BUNDLE group. In addition, unless the answerer
offer, the answerer MUST apply the answerer procedures for moving an rejects the whole offer, the answerer MUST apply the answerer
"m=" section out of a BUNDLE group (Section 7.3.2) or rejecting an procedures for moving an "m=" section out of a BUNDLE group
"m=" section within a BUNDLE group (Section 7.3.3) to every bundled (Section 7.3.2) or rejecting an "m=" section within a BUNDLE group
"m=" section in the offer when creating the answer. (Section 7.3.3) to every bundled "m=" section in the offer when
creating the answer.
Section 18.1 shows an example of an offerer BUNDLE address:port Section 18.1 shows an example of an offerer BUNDLE address:port
selection. selection.
Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m="
section selection. section selection.
7.3.2. Moving a Media Description Out of a BUNDLE Group 7.3.2. Moving a Media Description Out of a BUNDLE Group
When an answerer generates the answer, if the answerer wants to move When an answerer generates the answer, if the answerer wants to move
skipping to change at page 18, line 43 skipping to change at page 18, line 43
answerer wants to move an "m=" section from one BUNDLE group to answerer wants to move an "m=" section from one BUNDLE group to
another, it MUST first move the "m=" section out of the current another, it MUST first move the "m=" section out of the current
BUNDLE group and then generate an offer where the "m=" section is BUNDLE group and then generate an offer where the "m=" section is
added to another BUNDLE group (Section 7.5.1). added to another BUNDLE group (Section 7.5.1).
7.3.3. Rejecting a Media Description in a BUNDLE Group 7.3.3. Rejecting a Media Description in a BUNDLE Group
When an answerer wants to reject a bundled "m=" section in an answer, When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check the following criterion: it MUST first check the following criterion:
* In the corresponding offer, the "m=" section is the offerer-tagged * In the corresponding offer (subsequent), the "m=" section is the
"m=" section. offerer-tagged "m=" section.
If the criterion above is fulfilled, the answerer cannot reject the If the criterion above is fulfilled, the answerer cannot reject the
"m=" section in the answer. The answerer can reject the whole offer, "m=" section in the answer. The answerer can reject the whole offer,
reject each bundled "m=" section within the BUNDLE group, or keep the reject each bundled "m=" section within the BUNDLE group, or keep the
"m=" section within the BUNDLE group in the answer and later create "m=" section within the BUNDLE group in the answer and later create
an offer where the "m=" section is disabled within the BUNDLE group an offer where the "m=" section is disabled within the BUNDLE group
(Section 7.5.3). (Section 7.5.3).
When an answerer generates an answer, in which it rejects a bundled When an answerer generates an answer, in which it rejects a bundled
"m=" section, the answerer: "m=" section, the answerer:
skipping to change at page 21, line 9 skipping to change at page 21, line 9
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
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 (for the
is no mismatch, the offerer MUST apply the properties (BUNDLE same BUNDLE group). If there is no mismatch, the offerer MUST apply
address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the
section (selected by the answerer; see Section 7.3.1) to each bundled offerer-tagged "m=" section (selected by the answerer; see
"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
skipping to change at page 23, line 27 skipping to change at page 23, line 27
7.5.1. Adding a Media Description to a BUNDLE Group 7.5.1. Adding a Media Description to a BUNDLE Group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer, in which it wants to
add a bundled "m=" section to a previously negotiated BUNDLE group, add a bundled "m=" section to a previously negotiated BUNDLE group,
the offerer follows the procedures in Section 7.5. The offerer picks the offerer follows the procedures in Section 7.5. The offerer picks
either the added "m=" section or an "m=" section previously added to either the added "m=" section or an "m=" section previously added to
the BUNDLE group as the offerer-tagged "m=" section. the BUNDLE group as the offerer-tagged "m=" section.
NOTE: As described in Section 7.3.2, the answerer cannot move the NOTE: As described in Section 7.3.2, the answerer cannot move the
added "m=" section out of the BUNDLE group in its answer. If the added "m=" section out of the BUNDLE group in its answer. If the
answer wants to move the "m=" section out of the BUNDLE group, it answerer wants to move the "m=" section out of the BUNDLE group, it
will have to first accept it into the BUNDLE group in the answer, and will have to first accept it into the BUNDLE group in the answer, and
then send a subsequent offer where the "m=" section is moved out of then send a subsequent offer where the "m=" section is moved out of
the BUNDLE group (Section 7.5.2). the BUNDLE group (Section 7.5.2).
7.5.2. Moving a Media Description Out of a BUNDLE Group 7.5.2. Moving a Media Description Out of a BUNDLE Group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer, in which it wants to
remove a bundled "m=" section from a BUNDLE group, the offerer: remove a bundled "m=" section from a BUNDLE group, the offerer:
* MUST assign a unique address:port to the "m=" section; * MUST assign a unique address:port to the "m=" section;
skipping to change at page 26, line 32 skipping to change at page 26, line 32
* A specific payload type value can be used in multiple bundled "m=" * A specific payload type value can be used in multiple bundled "m="
sections only if each codec associated with the payload type sections only if each codec associated with the payload type
number shares an identical codec configuration (Section 9.1.1). number shares an identical codec configuration (Section 9.1.1).
* The proto value in each bundled RTP-based "m=" section MUST be * The proto value in each bundled RTP-based "m=" section MUST be
identical (e.g., RTP/AVPF). identical (e.g., RTP/AVPF).
* The RTP MID header extension MUST be enabled, by including an SDP * The RTP MID header extension MUST be enabled, by including an SDP
'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-
hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section hdrext:sdes:mid' URI value defined in this specification, in each
in every offer and answer. bundled RTP-based "m=" section in every offer and answer.
* A given SSRC MUST NOT transmit RTP packets using payload types * A given SSRC MUST NOT transmit RTP packets using payload types
that originate from different bundled "m=" sections. that originate from different bundled "m=" sections.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap, RTP and RTCP fail to function. Even if done in with time overlap, RTP and RTCP fail to function. Even if done in
proper sequence, this causes RTP timestamp rate switching issues proper sequence, this causes RTP timestamp rate switching issues
[RFC7160]. However, once an SSRC has left the RTP session (by [RFC7160]. However, once an SSRC has left the RTP session (by
sending an RTCP BYE packet), that SSRC can be reused by another sending an RTCP BYE packet), that SSRC can be reused by another
skipping to change at page 28, line 39 skipping to change at page 28, line 39
to ensure unique payload type values, it will be impossible to to ensure unique payload type values, it will be impossible to
associate the RTP stream using that payload type value to a associate the RTP stream using that payload type value to a
particular "m=" section. Note that when using the payload type to particular "m=" section. Note that when using the payload type to
associate RTP streams with "m=" sections, an RTP stream, identified associate RTP streams with "m=" sections, an RTP stream, identified
by its SSRC, will be mapped to an "m=" section when the first packet by its SSRC, will be mapped to an "m=" section when the first packet
of that RTP stream is received, and the mapping will not be changed of that RTP stream is received, and the mapping will not be changed
even if the payload type used by that RTP stream changes. In other even if the payload type used by that RTP stream changes. In other
words, the SSRC cannot "move" to a different "m=" section simply by words, the SSRC cannot "move" to a different "m=" section simply by
changing the payload type. changing the payload type.
Applications can implement RTP stacks in many different ways. The Applications can implement RTP stacks in different ways. The
algorithm below details one way that RTP streams can be associated algorithm below details one way that RTP streams can be associated
with "m=" sections, but it is not meant to be prescriptive about with "m=" sections, but it is not meant to be prescriptive about
exactly how an RTP stack needs to be implemented. Applications MAY exactly how an RTP stack needs to be implemented. Applications MAY
use any algorithm that achieves equivalent results to those described use any algorithm that achieves equivalent results to those described
in the algorithm below. in the algorithm below.
To prepare to associate RTP streams with the correct "m=" section, To prepare to associate RTP streams with the correct "m=" section,
the following steps MUST be followed for each BUNDLE group: the following steps MUST be followed for each BUNDLE group:
* Construct a table mapping a MID to an "m=" section for each "m=" * Construct a table mapping a MID to an "m=" section for each "m="
skipping to change at page 29, line 35 skipping to change at page 29, line 35
their configurations are changed, the tables above MUST also be their configurations are changed, the tables above MUST also be
updated. updated.
When an RTP packet is received, it MUST be delivered to the RTP When an RTP packet is received, it MUST be delivered to the RTP
stream corresponding to its SSRC. That RTP stream MUST then be stream corresponding to its SSRC. That RTP stream MUST then be
associated with the correct "m=" section within a BUNDLE group, for associated with the correct "m=" section within a BUNDLE group, for
additional processing, according to the following steps: additional processing, according to the following steps:
* If the MID associated with the RTP stream is not in the table * If the MID associated with the RTP stream is not in the table
mapping a MID to an "m=" section, then the RTP stream is not mapping a MID to an "m=" section, then the RTP stream is not
decoded and the payload data is discarded. decoded, and the payload data is discarded.
* If the packet has a MID, and the packet's extended sequence number * If the packet has a MID, and the packet's extended sequence number
is greater than that of the last MID update, as discussed in is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the MID associated with the RTP [RFC7941], Section 4.2.6, update the MID associated with the RTP
stream to match the MID carried in the RTP packet, and then update stream to match the MID carried in the RTP packet, and then update
the mapping tables to include an entry that maps the SSRC of that the mapping tables to include an entry that maps the SSRC of that
RTP stream to the "m=" section for that MID. RTP stream to the "m=" section for that MID.
* If the SSRC of the RTP stream is in the incoming SSRC mapping * If the SSRC of the RTP stream is in the incoming SSRC mapping
table, check that the payload type used by the RTP stream matches table, check that the payload type used by the RTP stream matches
a payload type included on the matching "m=" section. If so, a payload type included on the matching "m=" section. If so,
associate the RTP stream with that "m=" section. Otherwise, the associate the RTP stream with that "m=" section. Otherwise, the
RTP stream is not decoded and the payload data is discarded. RTP stream is not decoded, and the payload data is discarded.
* If the payload type used by the RTP stream is in the payload type * If the payload type used by the RTP stream is in the payload type
table, update the incoming SSRC mapping table to include an entry table, update the incoming SSRC mapping table to include an entry
that maps the RTP stream's SSRC to the "m=" section for that that maps the RTP stream's SSRC to the "m=" section for that
payload type. Associate the RTP stream with the corresponding payload type. Associate the RTP stream with the corresponding
"m=" section. "m=" section.
* Otherwise, mark the RTP stream as "not for decoding" and discard * Otherwise, mark the RTP stream as "not for decoding" and discard
the payload. the payload.
skipping to change at page 33, line 31 skipping to change at page 33, line 31
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' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to
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 SDP 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.
skipping to change at page 34, line 29 skipping to change at page 34, line 29
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; thus, 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 the answerer MUST move the section in the created BUNDLE group, and moves the "m=" section out
"m=" section out of the BUNDLE group (Section 7.3.2); 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; or reject the "m=" for the media associated with the "m=" section. If the answerer
section (Section 7.3.3). rejects the "m=" section (Section 7.3.3) the answerer MUST NOT
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
"m=" section in the answer. The answerer will use the port value of "m=" section in the answer. The answerer will use the port value of
the offerer-tagged "m=" section sending RTP and RTCP packets the offerer-tagged "m=" section sending RTP and RTCP packets
associated with RTP-based bundled media towards the offerer. associated with RTP-based bundled media 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 exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer MUST
include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" include an SDP 'rtcp-mux' attribute in the answerer-tagged "m="
section. It is not possible to disable RTP/RTCP multiplexing within section. It is not possible to disable RTP/RTCP multiplexing within
skipping to change at page 41, line 50 skipping to change at page 41, line 50
do take into account that some single characters when UTF-8 encoded do take into account that some single characters when UTF-8 encoded
will result in multiple octets. The identification-tag MUST NOT will result in multiple octets. The identification-tag MUST NOT
contain any user information, and applications SHALL avoid generating contain any user information, and applications SHALL avoid generating
the identification-tag using a pattern that enables user or the identification-tag using a pattern that enables user or
application identification. application identification.
16. IANA Considerations 16. IANA Considerations
16.1. New SDES Item 16.1. New SDES Item
This document adds the MID SDES item to the IANA "RTP SDES Item This document updates the MID SDES item to the IANA "RTP SDES Item
Types" registry as follows: Types" registry as follows:
Value: 15 Value: 15
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFC XXXX Reference: RFC XXXX
16.2. New RTP SDES Header Extension URI 16.2. New RTP SDES Header Extension URI
This document defines a new extension URI in the RTP SDES Compact This document updates the extension URI in the RTP SDES Compact
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
Reference: RFC XXXX Reference: RFC XXXX
skipping to change at page 42, line 38 skipping to change at page 42, line 38
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description ("m=" section) in the SDP used to negotiate the media description ("m=" section) in the SDP used to negotiate the
media. media.
The purpose of the extension is for the offerer to be able to The purpose of the extension is for the offerer to be able to
associate received multiplexed RTP-based media before the offerer associate received multiplexed RTP-based media before the offerer
receives the associated answer. receives the associated answer.
16.3. New SDP Attribute 16.3. New SDP Attribute
This document defines a new SDP media-level attribute, 'bundle-only', This document updates the SDP media-level attribute, 'bundle-only',
according to the following data: according to the following data:
Attribute name: bundle-only Attribute name: bundle-only
Type of attribute: media Type of attribute: media
Subject to charset: No Subject to charset: No
Purpose: Request a media description to be accepted in the answer Purpose: Request a media description to be accepted in the answer
only if kept within a BUNDLE group by the answerer. only if kept within a BUNDLE group by the answerer.
skipping to change at page 43, line 12 skipping to change at page 43, line 12
Contact name: IESG Contact name: IESG
Contact e-mail: iesg@ietf.org Contact e-mail: iesg@ietf.org
Reference: RFC XXXX Reference: RFC XXXX
Mux category: NORMAL Mux category: NORMAL
16.4. New SDP Group Semantics 16.4. New SDP Group Semantics
This document registers the following semantics with IANA in the This document updates the following semantics in the "Semantics for
"Semantics for the 'group' SDP Attribute" subregistry (under the the 'group' SDP Attribute" subregistry (under the "Session
"Session Description Protocol (SDP) Parameters" registry): Description Protocol (SDP) Parameters" registry):
+================+========+==============+===========+ +================+========+==============+===========+
| Semantics | Token | Mux Category | Reference | | Semantics | Token | Mux Category | Reference |
+================+========+==============+===========+ +================+========+==============+===========+
| Media bundling | BUNDLE | NORMAL | RFC XXXX | | Media bundling | BUNDLE | NORMAL | RFC XXXX |
+----------------+--------+--------------+-----------+ +----------------+--------+--------------+-----------+
Table 1 Table 1
17. Security Considerations 17. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. BUNDLE does not change which information, to the BUNDLE extension. BUNDLE does not change which information,
e.g., RTP streams, flows over the network, with the exception of the e.g., RTP streams, flows over the network, except for the usage of
usage of the MID SDES item as discussed below. Primarily, it changes the MID SDES item as discussed below. Primarily, it changes which
which addresses and ports, and thus in which (RTP) sessions, the addresses and ports, and thus in which (RTP) sessions, the
information flows to. This affects the security contexts being used information flows to. This affects the security contexts being used
and can cause previously separated information flows to share the and can cause previously separated information flows to share the
same security context. This has very little impact on the same security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases performance of the security mechanism of the RTP sessions. In cases
where one would have applied different security policies on the where one would have applied different security policies on the
different RTP streams being bundled, or where the parties having different RTP streams being bundled, or where the parties having
access to the security contexts would have differed between the RTP access to the security contexts would have differed between the RTP
streams, additional analysis of the implications are needed before streams, additional analysis of the implications are needed before
selecting to apply BUNDLE. selecting to apply BUNDLE.
The identification-tag, independent of transport, RTCP SDES packet, The identification-tag, independent of transport, RTCP SDES packet,
or RTP header extension, can expose the value to parties beyond the or RTP header extension, can expose the value to parties beyond the
signaling chain. Therefore, the identification-tag values MUST be signaling chain. Therefore, the identification-tag values MUST be
generated in a fashion that does not leak user information, e.g., generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes randomly or using a per-bundle group counter, and SHOULD be 3 bytes
or less to allow them to efficiently fit into the MID RTP header or fewer to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for extension. Note that if implementations use different methods for
generating identification-tags, this could enable fingerprinting of generating identification-tags, this could enable fingerprinting of
the implementation making it vulnerable to targeted attacks. The the implementation making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included identification-tag is exposed on the RTP stream level when included
in the RTP header extensions; however, what it reveals of the RTP in the RTP header extensions; however, what it reveals of the RTP
media stream structure of the endpoint and application was already media stream structure of the endpoint and application was already
possible to deduce from the RTP streams without the MID SDES header possible to deduce from the RTP streams without the MID SDES header
extensions. As the identification-tag is also used to route the extensions. As the identification-tag is also used to route the
media stream to the right application functionality, it is important media stream to the right application functionality, it is important
that the value received is the one intended by the sender; thus, that the value received is the one intended by the sender; thus,
skipping to change at page 55, line 46 skipping to change at page 55, line 46
Protocol (SDP) Attributes When Multiplexing", RFC 8859, Protocol (SDP) Attributes When Multiplexing", RFC 8859,
DOI 10.17487/RFC8859, January 2021, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>. <https://www.rfc-editor.org/info/rfc8859>.
19.2. Informative References 19.2. Informative References
[LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. [LLR-RTCP] 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", Work in Progress, Internet-Draft, draft-ietf- Message", Work in Progress, Internet-Draft, draft-ietf-
avtext-lrr-07, 2 July 2017, avtext-lrr-07, 2 July 2017,
<https://tools.ietf.org/html/draft-ietf-avtext-lrr-07>. <https://datatracker.ietf.org/doc/html/draft-ietf-avtext-
lrr-07>.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
DOI 10.17487/RFC2543, March 1999, DOI 10.17487/RFC2543, March 1999,
<https://www.rfc-editor.org/info/rfc2543>. <https://www.rfc-editor.org/info/rfc2543>.
[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,
skipping to change at page 59, line 43 skipping to change at page 59, line 43
happen to the ICE candidates associated with the "m=" section, as happen to the ICE candidates associated with the "m=" section, as
they are also used for the BUNDLE address:port. they are also used for the BUNDLE address:port.
A.3. B2BUA and Proxy Interoperability A.3. B2BUA and Proxy Interoperability
Some back-to-back user agents may be configured in a mode where if Some back-to-back user agents may be configured in a mode where if
the incoming call leg contains an SDP attribute the B2BUA does not the incoming call leg contains an SDP attribute the B2BUA does not
understand, the B2BUA still generates that SDP attribute in the Offer understand, the B2BUA still generates that SDP attribute in the Offer
for the outgoing call leg. Consider a B2BUA that did not understand for the outgoing call leg. Consider a B2BUA that did not understand
the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way. the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further, assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this case, if the where it did not see any RTCP for 5 minutes. In this case, if the
B2BUA received an Offer like: B2BUA received an Offer like:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
 End of changes. 30 change blocks. 
66 lines changed or deleted 67 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/