draft-ietf-mmusic-rfc8843bis-01.txt   draft-ietf-mmusic-rfc8843bis-02.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: 6 December 2021 Cisco Expires: 9 December 2021 Cisco
4 June 2021 7 June 2021
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-rfc8843bis-01 draft-ietf-mmusic-rfc8843bis-02
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 6 December 2021. This Internet-Draft will expire on 9 December 2021.
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 3, line 6 skipping to change at page 3, line 6
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 SDP 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 SDP Offer . . . . . . . . . . . . . 14
7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14
7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 16 7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 16
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 . . . . . . . . . . . . . . . . . 18
7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 19
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 20 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20
7.5.1. Adding a Media Description to a BUNDLE Group . . . . 21 7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21
7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 21
7.5.3. Disabling a Media Description in a BUNDLE Group . . . 22 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22
8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 22
8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 23 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23
9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 24
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . . . 24 Description . . . . . . . . . . . . . . . . . . . . . . . 26
9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 32
9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 31 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 32
10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. RTP Header Extensions Consideration . . . . . . . . . . . . . 35 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 36
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 35 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 36
13.1. Original Text from RFC 3264, Section 5.1, 2nd 13.1. Original Text from RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 35
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37
13.3. Original Text from RFC 3264, Section 8.4, 6th 13.3. Original Text from RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37
13.4. New Text Replacing RFC 3264, Section 8.4, 6th 13.4. New Text Replacing RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 36 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 37 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 38
14.1. Original Text from RFC 5888, Section 9.2, 3rd 14.1. Original Text from RFC 5888, Section 9.2, 3rd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 14.2. New Text Replacing RFC 5888, Section 9.2, 3rd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
15. RTP/RTCP Extensions for identification-tag Transport . . . . 37 15. RTP/RTCP Extensions for identification-tag Transport . . . . 38
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 38 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 39 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 40
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 39 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 40
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 40 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 41
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 40 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 41
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 41 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 42
17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 17. Security Considerations . . . . . . . . . . . . . . . . . . . 42
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 42 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 43
18.1. Example: Tagged "m=" Section Selections . . . . . . . . 42 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 43
18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 44 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 45
18.3. Example: Offerer Adds a Media Description to a BUNDLE 18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 Group . . . . . . . . . . . . . . . . . . . . . . . . . 46
18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 47 Group . . . . . . . . . . . . . . . . . . . . . . . . . 48
18.5. Example: Offerer Disables a Media Description within a 18.5. Example: Offerer Disables a Media Description within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 49 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 50
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19.1. Normative References . . . . . . . . . . . . . . . . . . 51 19.1. Normative References . . . . . . . . . . . . . . . . . . 52
19.2. Informative References . . . . . . . . . . . . . . . . . 53 19.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Design Considerations . . . . . . . . . . . . . . . 55 Appendix A. Design Considerations . . . . . . . . . . . . . . . 56
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 55 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 56
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 57 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 58
A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 57 A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 58
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 58 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 59
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 58 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 59
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 58 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 59
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
1.1. Background 1.1. Background
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
the establishment of multimedia communication sessions, if separate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media transports (5-tuples) are negotiated for each individual media
stream, each transport consumes additional resources (especially when stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE) [RFC8445] is used). For Interactive Connectivity Establishment (ICE) [RFC8445] is used). For
skipping to change at page 16, line 16 skipping to change at page 16, line 16
remove SDP attributes, or modify SDP attribute values in a subsequent remove SDP attributes, or modify SDP attribute values in a subsequent
answer. Changes to the answerer BUNDLE address:port and the answerer answer. Changes to the answerer BUNDLE address:port and the answerer
BUNDLE attributes will be applied to each bundled "m=" section within BUNDLE attributes will be applied to each bundled "m=" section within
the BUNDLE group. the BUNDLE group.
NOTE: If a bundled "m=" section in an offer contains a zero port NOTE: If a bundled "m=" section in an offer contains a zero port
value, but the "m=" section does not contain an SDP 'bundle-only' value, but the "m=" section does not contain an SDP 'bundle-only'
attribute, it is an indication that the offerer wants to disable the attribute, it is an indication that the offerer wants to disable the
"m=" section (Section 7.5.3). "m=" section (Section 7.5.3).
NOTE: In RFC 8843, instead of assigning the offerer BUNDLE
address:port to each "m=" section within the BUNDLE group when
modifying the session (Section 7.5), the offerer only assigned the
offerer BUNDLE address:port to the offerer-tagged "m=" section. For
every other "m=" section within the BUNDLE group, the offerer
included an SDP 'bundle-only' attribute in, and assigned a zero port
value to, the "m=" section. In order to be backward compatible with
offerers that implement that version of the specification, an
answerer SHOULD accept such offers.
7.3.1. Answerer Selection of Tagged 'm=' Sections 7.3.1. Answerer Selection of Tagged 'm=' Sections
When selecting the offerer-tagged "m=" section, the answerer MUST When selecting the offerer-tagged "m=" section, the answerer MUST
first check whether the "m=" section fulfills the following criteria first check whether the "m=" section fulfills the following criteria
Section 7.2.1: Section 7.2.1:
* The answerer will not move the "m=" section out of the BUNDLE * The answerer will not move the "m=" section out of the BUNDLE
group (Section 7.3.2); group (Section 7.3.2);
* The answerer will not reject the "m=" section (Section 7.3.3); and * The answerer will not reject the "m=" section (Section 7.3.3); and
skipping to change at page 19, line 36 skipping to change at page 19, line 24
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
7.3.5. RFC 8843 Considerations
In RFC 8843, instead of assigning the offerer BUNDLE address:port to
each "m=" section within the BUNDLE group when modifying the session
(Section 7.5), the offerer only assigned the offerer BUNDLE
address:port to the offerer-tagged "m=" section. For every other
"m=" section within the BUNDLE group, the offerer included an SDP
'bundle-only' attribute in, and assigned a zero port value to, the
"m=" section. In order to be backward compatible with offerers that
implement RFC 8843, an answerer SHOULD accept such offers. The
example below shows such offer:
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=bundle-only
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
7.4. Offerer Processing of the SDP Answer 7.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" section in the group, the offerer MUST check that any bundled "m=" section in the
answer was indicated as bundled in the corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST apply the properties (BUNDLE is no mismatch, the offerer MUST apply the properties (BUNDLE
address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" address:port, BUNDLE attributes, etc.) of the offerer-tagged "m="
section (selected by the answerer; see Section 7.3.1) to each bundled section (selected by the answerer; see Section 7.3.1) to each bundled
"m=" section within the BUNDLE group. "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.
NOTE: In RFC 8843, instead of assigning the answerer BUNDLE 7.4.1. RFC 8843 Considerations
address:port to each "m=" section within the BUNDLE group when
generating the answer (Section 7.3), the answerer only assigned the In RFC 8843, instead of assigning the answerer BUNDLE address:port to
answerer BUNDLE address:port to the answerer-tagged "m=" section. each "m=" section within the BUNDLE group when generating the answer
For every other "m=" section within the BUNDLE group, the answerer (Section 7.3), the answerer only assigned the answerer BUNDLE
included an SDP 'bundle-only' attribute in, and assigned a zero port address:port to the answerer-tagged "m=" section. For every other
value to, the "m=" section. In order to be backward compatible with "m=" section within the BUNDLE group, the answerer included an SDP
answerers that implement that version of the specification, an 'bundle-only' attribute in, and assigned a zero port value to, the
offerer SHOULD accept such answers. "m=" section. In order to be backward compatible with answerers that
implement RFC 8843, an offerer SHOULD accept such answers. The
example below shows such answer:
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32
b=AS:1000
a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
7.5. Modifying the Session 7.5. Modifying the Session
When a BUNDLE group has been previously negotiated, and an offerer When a BUNDLE group has been previously negotiated, and an offerer
generates a subsequent offer, the offerer MUST: generates a subsequent offer, the offerer MUST:
* Pick one bundled "m=" section as the offerer-tagged "m=" section. * Pick one bundled "m=" section as the offerer-tagged "m=" section.
The offerer can pick either the "m=" section that was previously The offerer can pick either the "m=" section that was previously
selected by the answerer as the offerer-tagged "m=" section or selected by the answerer as the offerer-tagged "m=" section or
another bundled "m=" section within the BUNDLE group; another bundled "m=" section within the BUNDLE group;
 End of changes. 17 change blocks. 
76 lines changed or deleted 129 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/