draft-ietf-mmusic-rfc8843bis-02.txt   draft-ietf-mmusic-rfc8843bis-03.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: 9 December 2021 Cisco Expires: 25 December 2021 Cisco
7 June 2021 23 June 2021
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-rfc8843bis-02 draft-ietf-mmusic-rfc8843bis-03
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 9 December 2021. This Internet-Draft will expire on 25 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 2, line 51 skipping to change at page 2, line 51
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 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 . . . . . . . . . . . . . . . . 15
7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 16 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 . . . . . . . . . . . . . . . . . 18 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19
7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 19 7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20
7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 21 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22
7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22 7.5.1. Adding a Media Description to a BUNDLE Group . . . . 23
7.5.2. Moving a Media Description Out of a BUNDLE Group . . 22 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23
7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 24
8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24 7.6. SIP Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 24 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 25
9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 26
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 27
9.2. Associating RTP/RTCP Streams with the Correct SDP Media 9.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . . 26 Description . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 32 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33
9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 32 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33
10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36
12. RTP Header Extensions Consideration . . . . . . . . . . . . . 36 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . . . . . . 36
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd
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 . . . . . . . . . . . . . . . . . . . . . . . 37
13.4. New Text Replacing RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38
14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 38 13.4. New Text Replacing RFC 3264, Section 8.4, 6th
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . . . . . 38 Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39
15. RTP/RTCP Extensions for identification-tag Transport . . . . 38 15. RTP/RTCP Extensions for identification-tag Transport . . . . 39
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 41
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 40 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 40 16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 41 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 41 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 42 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43
17. Security Considerations . . . . . . . . . . . . . . . . . . . 42 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 43 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.1. Example: Tagged "m=" Section Selections . . . . . . . . 43 18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44
18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 45 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 46
18.3. Example: Offerer Adds a Media Description to a BUNDLE 18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 46 Group . . . . . . . . . . . . . . . . . . . . . . . . . 47
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 . . . . . . . . . . . . . . . . . . . . . . . . . 48 Group . . . . . . . . . . . . . . . . . . . . . . . . . 49
18.5. Example: Offerer Disables a Media Description within a 18.5. Example: Offerer Disables a Media Description within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 50 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 51
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
19.1. Normative References . . . . . . . . . . . . . . . . . . 52 19.1. Normative References . . . . . . . . . . . . . . . . . . 53
19.2. Informative References . . . . . . . . . . . . . . . . . 54 19.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Design Considerations . . . . . . . . . . . . . . . 56 Appendix A. Design Considerations . . . . . . . . . . . . . . . 57
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 56 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 57
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 58 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 59
A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 58 A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 59
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 59 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 60
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 59 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 60
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 59 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 60
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 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
"m=" sections in the offer and suggests that both "m=" sections are
included in a BUNDLE group. The offerer includes an SDP 'bundle-
only' attribute in the video "m=" section, to request that the
answerer accepts the "m=" section only if the answerer supports the
BUNDLE extension and if the answerer keeps the "m=" section within
the associated BUNDLE group. The audio "m=" section is the suggested
offerer-tagged "m=" section, indicated by placing the identification-
tag associated with the "m=" section (offerer BUNDLE-tag) first in
the SDP group:BUNDLE attribute identification-id list.
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.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;
skipping to change at page 19, line 32 skipping to change at page 20, line 13
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 7.3.5. RFC 8843 Considerations
In RFC 8843, instead of assigning the offerer BUNDLE address:port to In RFC 8843, instead of assigning the offerer BUNDLE address:port to
each "m=" section within the BUNDLE group when modifying the session each "m=" section within the BUNDLE group when modifying the session
(Section 7.5), the offerer only assigned the offerer BUNDLE (Section 7.5), the offerer only assigned the offerer BUNDLE
address:port to the offerer-tagged "m=" section. For every other address:port to the offerer-tagged "m=" section. For every other
"m=" section within the BUNDLE group, the offerer included an SDP "m=" section within the BUNDLE group, the offerer included an SDP
'bundle-only' attribute in, and assigned a zero port value to, the 'bundle-only' attribute in, and assigned a zero port value to, the
"m=" section. In order to be backward compatible with offerers that "m=" section. The way an answerer compliant to this specification
implement RFC 8843, an answerer SHOULD accept such offers. The processes such offer is considered an implementation issue (e.g.,
example below shows such offer: based on whether the answerer needs to be backward compatible with
RFC 8843 compliant offerers), and is outside the scope of this
specification. The example below shows such SDP Offer:
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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at page 21, line 8 skipping to change at page 21, line 26
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 answer each "m=" section within the BUNDLE group when generating the SDP
(Section 7.3), the answerer only assigned the answerer BUNDLE Answer (Section 7.3), the answerer only assigned the answerer BUNDLE
address:port to the answerer-tagged "m=" section. For every other address:port to the answerer-tagged "m=" section. For every other
"m=" section within the BUNDLE group, the answerer included an SDP "m=" section within the BUNDLE group, the answerer included an SDP
'bundle-only' attribute in, and assigned a zero port value to, the 'bundle-only' attribute in, and assigned a zero port value to, the
"m=" section. In order to be backward compatible with answerers that "m=" section. The way an offerer compliant to this specification
implement RFC 8843, an offerer SHOULD accept such answers. The processes such SDP Answer is considered an implementation issue
example below shows such answer: (e.g., based on whether the answerer needs to be backward compatible
with RFC 8843 compliant offerers), and is outside the scope of this
specification. The example below shows such SDP Answer:
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at page 24, line 5 skipping to change at page 24, line 36
* 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
The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent
Client (UAC) to send a re-INVITE request without an SDP body
(sometimes referred to as an empty re-INVITE). In such cases, the
User Agent Server (UAS) will include an SDP Offer in the associated
200 OK response. This is typically used for 3rd Party Call Control
(3PCC) scenarios. From a BUNDLE perspective, such SDP Offer SHOULD
be generated using the procedures defined in Section 7.2.
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.
In addition, if received data can be associated with more than one In addition, if received data can be associated with more than one
 End of changes. 23 change blocks. 
68 lines changed or deleted 119 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/