draft-ietf-mmusic-sdp-bundle-negotiation-41.txt   draft-ietf-mmusic-sdp-bundle-negotiation-42.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: May 31, 2018 C. Jennings Expires: June 2, 2018 C. Jennings
Cisco Cisco
November 27, 2017 November 29, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-41.txt draft-ietf-mmusic-sdp-bundle-negotiation-42.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 31, 2018. This Internet-Draft will expire on June 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14
8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 18
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 21 Description . . . . . . . . . . . . . . . . . . . . . . 21
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 33 14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 33
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 33
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 33
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33 14.6. New text replacing section 8.2 (2nd paragraph) of RFC
14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 33
14.8. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. RTP/RTCP extensions for identification-tag transport . . . . 34 15. RTP/RTCP extensions for identification-tag transport . . . . 34
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38
17. Security Considerations . . . . . . . . . . . . . . . . . . . 37 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41
18.3. Example: Offerer Adds A Media Description To A BUNDLE 18.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.4. Example: Offerer Moves A Media Description Out Of A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44
18.5. Example: Offerer Disables A Media Description Within A 18.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
21.1. Normative References . . . . . . . . . . . . . . . . . . 58 21.1. Normative References . . . . . . . . . . . . . . . . . . 58
21.2. Informative References . . . . . . . . . . . . . . . . . 60 21.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Design Considerations . . . . . . . . . . . . . . . 61 Appendix A. Design Considerations . . . . . . . . . . . . . . . 61
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 62
A.2. Usage of port number value zero . . . . . . . . . . . . . 63 A.2. Usage of port number value zero . . . . . . . . . . . . . 63
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 63 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 63
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 64 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
When multimedia communications are established, each transport When multimedia communications are established, each transport
skipping to change at page 14, line 7 skipping to change at page 14, line 7
and receiving bundled media [Section 8.2.1]. The answerer MUST check and receiving bundled media [Section 8.2.1]. The answerer MUST check
whether that "m=" section fulfils the following criteria: whether that "m=" section fulfils the following criteria:
o The answerer will not move the "m=" section out of the BUNDLE o The answerer will not move the "m=" section out of the BUNDLE
group [Section 8.3.3]; and group [Section 8.3.3]; and
o The answerer will not reject the "m=" section [Section 8.3.4]; and o The answerer will not reject the "m=" section [Section 8.3.4]; and
o The "m=" section does not contain a zero port value. o The "m=" section does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the suggested offerer BUNDLE address as the offerer BUNDLE address. the suggested offerer BUNDLE address.
In the answer, the answerer BUNDLE-tag represents the "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
select the next identification-tag in the identification-tag list, pick the next identification-tag in the identification-tag list in
and perform the same criteria check for the "m=" section associated the offer, and perform the same criteria check for the "m=" section
with that identification-tag. If there are no more identification- represented by that identification-tag. If there are no more
tags in the identification-tag list, the answerer MUST NOT create the identification-tags in the identification-tag list, the answerer MUST
BUNDLE group. In addition, unless the answerer rejects the whole NOT create the BUNDLE group. Unless the answerer rejects the whole
offer, the answerer MUST apply the answerer procedures for moving an offer, the answerer MUST apply the answerer procedures for moving an
"m=" section out of a BUNDLE group [Section 8.3.3] to each bundled "m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an
"m=" section within a BUNDLE group [Section 8.3.4] to every bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 18.1] shows an example of an offerer BUNDLE address [Section 18.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address 8.3.2. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself (answerer When the answerer selects a BUNDLE address for itself (answerer
BUNDLE address), the answerer MUST assign the answerer BUNDLE address BUNDLE address), the answerer MUST assign the answerer BUNDLE address
to the "m=" section represented by the answerer BUNDLE-tag (i.e., the to the "m=" section that contains the selected offerer BUNDLE address
"m=" section in the corresponding offer that contains the selected in the corresponding offer. The answerer BUNDLE-tag represents that
offerer BUNDLE address). To every other bundled "m=" section the "m=" section in the answer. To every other bundled "m=" section the
answerer MUST assign a zero port value and include an SDP 'bundle- answerer MUST assign a zero port value and include an SDP 'bundle-
only' attribute. only' attribute.
The answerer MUST NOT assign an answerer BUNDLE address to an "m=" The answerer MUST NOT assign an answerer BUNDLE address to an "m="
section that is not within the BUNDLE group, or to an "m=" section section that is not within the BUNDLE group, or to an "m=" section
that is within another BUNDLE group. that is within another BUNDLE group.
[Section 18.1] shows an example of an answerer BUNDLE address [Section 18.1] shows an example of an answerer BUNDLE address
selection. selection.
skipping to change at page 17, line 22 skipping to change at page 17, line 22
8.5. Modifying the Session 8.5. Modifying the Session
When an offerer generates a subsequent offer (i.e., a BUNDLE group When an offerer generates a subsequent offer (i.e., a BUNDLE group
has previously been negotiated), it MUST assign the previously has previously been negotiated), it MUST assign the previously
selected offer BUNDLE address [Section 8.3.1], or a new suggested selected offer BUNDLE address [Section 8.3.1], or a new suggested
offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section
within the BUNDLE group. within the BUNDLE group.
The offerer MUST NOT assign an offerer BUNDLE address (previously The offerer MUST NOT assign an offerer BUNDLE address (previously
negotiated or suggested new) to a bundled "m=" section if: selected [Section 8.3.1] or new suggested [Section 8.5.1]) to a
bundled "m=" section if:
o The offerer wants to move the bundled "m=" section out of the o The offerer wants to move the bundled "m=" section out of the
BUNDLE group [Section 8.5.3]; or BUNDLE group [Section 8.5.3]; or
o The offerer wants to disable the bundled "m=" section o The offerer wants to disable the bundled "m=" section
[Section 8.5.4]. [Section 8.5.4].
To every other "m=" section within the BUNDLE group, the offerer MUST To every other "m=" section within the BUNDLE group, the offerer MUST
assign a zero port value and an SDP 'bundle-only' attribute. assign a zero port value and an SDP 'bundle-only' attribute.
skipping to change at page 32, line 11 skipping to change at page 32, line 11
specification, the identifier used for a given extension MUST specification, the identifier used for a given extension MUST
identify the same extension across all the bundled media identify the same extension across all the bundled media
descriptions. descriptions.
14. Update to RFC 3264 14. Update to RFC 3264
This section replaces the text of the following sections of RFC 3264: This section replaces the text of the following sections of RFC 3264:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
o Section 6 (Generating the Answer).
o Section 8.2 (Removing a Media Stream). o Section 8.2 (Removing a Media Stream).
o Section 8.4 (Putting a Unicast Media Stream on Hold). o Section 8.4 (Putting a Unicast Media Stream on Hold).
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
skipping to change at page 33, line 5 skipping to change at page 33, line 5
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer by default indicates the offerer. A port number of zero in the offer by default indicates
that the stream is offered but MUST NOT be used, but an extension that the stream is offered but MUST NOT be used, but an extension
mechanism might specify different semantics for the usage of a zero mechanism might specify different semantics for the usage of a zero
port value. Furthermore, existing streams can be terminated by port value. Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero by default indicates that the media stream is not wanted. zero by default indicates that the media stream is not wanted.
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 14.3. Original text of section 6 (4th paragraph) of RFC 3264
An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least
one MUST be present, as specified by SDP.
14.4. New text replacing section 6 (4th paragraph) of RFC 3264
An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. A port number of zero in
the answer by default indicates that the offered stream is rejected,
but an extension mechanism might specify different semantics for the
usage of a zero port value. If a stream is rejected, any media
formats listed are ignored. At least one MUST be present, as
specified by SDP.
14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST be marked with port A stream that is offered with a port of zero MUST be marked with port
zero in the answer. Like the offer, the answer MAY omit all zero in the answer. Like the offer, the answer MAY omit all
attributes present previously, and MAY list just a single media attributes present previously, and MAY list just a single media
format from amongst those in the offer. format from amongst those in the offer.
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 14.6. New text replacing section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST by default be A stream that is offered with a port of zero MUST by default be
marked with port zero in the answer, unless an extension mechanism, marked with port zero in the answer, unless an extension mechanism,
which specifies semantics for the usage of a non-zero port value, is which specifies semantics for the usage of a non-zero port value, is
used. If the stream is marked with port zero in the answer, the used. If the stream is marked with port zero in the answer, the
answer MAY omit all attributes present previously, and MAY list just answer MAY omit all attributes present previously, and MAY list just
a single media format from amongst those in the offer." a single media format from amongst those in the offer."
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 14.7. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent to the peer. RTP nor RTCP should be sent to the peer.
14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 14.8. New text replacing section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
skipping to change at page 48, line 30 skipping to change at page 48, line 30
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
20. Change Log 20. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41
o Update to section 6 o RFC 3264:
o https://github.com/cdh4u/draft-sdp-bundle/pull/47
o Editorial clarification on BUNDLE address selection:
o https://github.com/cdh4u/draft-sdp-bundle/pull/46
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40
o Editorial changes and technical restrictions in order to make the o Editorial changes and technical restrictions in order to make the
specification more understandable: specification more understandable:
o https://github.com/cdh4u/draft-sdp-bundle/pull/45 o https://github.com/cdh4u/draft-sdp-bundle/pull/45
o - BUNDLE address is only assigned to m- section represented by o - BUNDLE address is only assigned to m- section represented by
BUNDLE-tag. BUNDLE-tag.
 End of changes. 22 change blocks. 
31 lines changed or deleted 66 lines changed or added

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