draft-ietf-mmusic-sdp-bundle-negotiation-33.txt   draft-ietf-mmusic-sdp-bundle-negotiation-34.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: April 10, 2017 C. Jennings Expires: April 22, 2017 C. Jennings
Cisco Cisco
October 7, 2016 October 19, 2016
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-33.txt draft-ietf-mmusic-sdp-bundle-negotiation-34.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 address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, specified by multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 April 10, 2017. This Internet-Draft will expire on April 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 24 skipping to change at page 3, line 24
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 21 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 21 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 24 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 24
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 25 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 26
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 25 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 26 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 27
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 26 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 27
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 13.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 27 13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 28
13.4. New text replacing section 8.2 (2nd paragraph) of RFC 13.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 27 13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 28
13.6. New text replacing section 8.4 (6th paragraph) of RFC 13.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14. RTP/RTCP extensions for identification-tag transport . . . . 28 14. RTP/RTCP extensions for identification-tag transport . . . . 29
14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 29 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 30
14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 29 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 30
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 30 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 31
15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 30 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 31
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 31 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 32
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 31 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Example: Bundle Address Selection . . . . . . . . . . . 32 17.1. Example: Bundle Address Selection . . . . . . . . . . . 33
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 34 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 35
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 35 Group . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38
17.5. Example: Offerer Disables A Media Description Within A 17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 39 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 40
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 41 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
20.1. Normative References . . . . . . . . . . . . . . . . . . 48 20.1. Normative References . . . . . . . . . . . . . . . . . . 50
20.2. Informative References . . . . . . . . . . . . . . . . . 50 20.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Design Considerations . . . . . . . . . . . . . . . 51 Appendix A. Design Considerations . . . . . . . . . . . . . . . 52
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 51 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 53
A.2. Usage of port number value zero . . . . . . . . . . . . . 53 A.2. Usage of port number value zero . . . . . . . . . . . . . 54
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 53 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 54
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 54 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 55
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 54 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 55
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 54 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
When multimedia communications are established, each 5-tuple reserved When multimedia communications are established, each 5-tuple reserved
for an individual media stream consume additional resources for an individual media stream consume additional resources
(especially when Interactive Connectivity Establishment (ICE) (especially when Interactive Connectivity Establishment (ICE)
[RFC5245] is used). For this reason, it is attractive to use a [RFC5245] is used). For this reason, it is attractive to use a
5-tuple for multiple media streams. 5-tuple for multiple media streams.
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
skipping to change at page 21, line 21 skipping to change at page 21, line 21
will use for RTP and RTCP by using the SDP 'ssrc' attribute will use for RTP and RTCP by using the SDP 'ssrc' attribute
[RFC5576]. To allow for proper association with this mechanism, the [RFC5576]. To allow for proper association with this mechanism, the
'ssrc' attribute needs to be associated with each "m=" line that 'ssrc' attribute needs to be associated with each "m=" line that
shares a payload type with any other "m=" line in the same bundle. shares a payload type with any other "m=" line in the same bundle.
As the SSRC values will be carried inside the RTP/RTCP packets, the As the SSRC values will be carried inside the RTP/RTCP packets, the
offerer and answerer can then use that information to associate offerer and answerer can then use that information to associate
received RTP packets with the correct "m=" line. However, an offerer received RTP packets with the correct "m=" line. However, an offerer
will not know which SSRC values the answerer will use until it has will not know which SSRC values the answerer will use until it has
received the answer providing that information. Due to this, before received the answer providing that information. Due to this, before
the offerer has received the answer, the offerer will not be able to the offerer has received the answer, the offerer will not be able to
associate received RTP/RTCP packets with the correct "m=" line using associate received RTP packets with the correct "m=" line using the
the SSRC values. SSRC values. In addition, the SSRC value can change during the
session, and values that were not provided using the SDP 'ssrc'
attribute may be used.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP packets with the correct "m=" line, an offerer and
and answerer using the BUNDLE extension MUST support the mechanism answerer using the BUNDLE extension MUST support the mechanism
defined in Section 14, where the remote endpoint inserts the defined in Section 14, where the remote endpoint inserts the
identification-tag associated with an "m=" line in RTP and RTCP identification-tag associated with an "m=" line in RTP and RTCP
packets associated with that "m=" line. packets associated with that "m=" line.
Once an offerer or answerer recieves an RTP/RTCP packet carrying an
identification-tag and an SSRC value, it associates the SSRC value
with the "m=" line associated with the identification-tag. Later,
when an offerer or answerer receives an RTP or RTCP packet that does
not carry the identification-tag, it can associate the packet with
the correct "m=" line using the SSRC value. Note that multiple SSRC
values may end up being associated with the same "m=" line.
If an offerer or answerer is not able to associate an RTP packet with
the correct "m=" line using the SSRC value, the offerer or answerer
can check whether the association can be done using the payload type
value (in case the payload type value is unique for a given "m=" line
within the BUNDLE group), or using other appropriate mechanisms.
After all appropriate mechanisms supported by the offerer or answerer
have been tried, if it is not possible to associate a packet with the
correct "m=" line, the packet SHOULD be dropped after having been
processed as received by the RTCP layer.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based media specified by the multiplexing [RFC5761] for the RTP-based media specified by the
BUNDLE group. BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for sending all RTP packets and the RTCP combination will be used for sending all RTP packets and the RTCP
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
the packets towards the BUNDLE address of the other endpoint. The the packets towards the BUNDLE address of the other endpoint. The
skipping to change at page 22, line 8 skipping to change at page 22, line 30
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' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP
multiplexing for RTP-based media specified by a BUNDLE group. multiplexing for RTP-based media specified by a BUNDLE group.
The procedures in this section only apply to RTP-based "m=" lines. The procedures in this section only apply to RTP-based "m=" lines.
10.3.1.1. Generating the Initial SDP Offer 10.3.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST
associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based "m=" line in the offer, including a bundle-only "m=" line.
bundled RTP-based "m=" line in the offer. The offerer MUST associate In addition, the offerer MUST associate an SDP 'rtcp-mux-only'
an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle-
the offerer associates a 'rtcp-mux-only' attribute with an "m=" line, only "m=" line, and MAY associated an SDP 'rtcp-mux-only' attribute
the offerer may also associate a 'rtcp-mux' attribute with the same with other bundled RTP-based "m=" lines.
"m=" line, as described in [I-D.ietf-mmusic-mux-exclusive].
NOTE: Within a BUNDLE group, the offerer can associate the SDP 'rtcp- NOTE: Whether the offerer associates an SDP 'rtcp-mux-only' attribute
mux' attribute with some of the RTP-based "m=" lines, while it with a bundled "m=" line or not depends on whether the offerer
associates the SDP 'rtcp-mux-only' attribute to other RTP-based "m=" supports fallback to usage of a separate port for RTCP in case the
lines, depending on whether the offerer supports fallback to usage of answerer does not include the "m=" line in the BUNDLE group.
a separate port for RTCP in case the answerer does not include the
"m=" line in the BUNDLE group.
NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with an NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with a
"m=" line, the offerer can also associate an SDP 'rtcp' attribute bundled "m=" line, but does not associate an SDP 'rtcp-mux-only'
[RFC3605] with a bundled "m=" line, excluding a bundle-only "m=" attribute with the "m=" line, the offerer can also associate an SDP
line, in order to provide a fallback port for RTCP, as described in 'rtcp' attribute [RFC3605] with the "m=" line in order to provide a
[RFC5761]. However, the fallback port will only be used in case the fallback port for RTCP, as described in [RFC5761]. However, the
answerer does not include the "m=" line in the BUNDLE group in the fallback port will only be used in case the answerer does not include
associated answer. the "m=" line in the BUNDLE group.
In the initial offer, the address:port combination for RTCP MUST be In the initial offer, the address:port combination for RTCP MUST be
unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' unique in each bundled RTP-based "m=" line (excluding a bundle-only
"m=" line), similar to RTP. "m=" line), similar to RTP.
10.3.1.2. Generating the SDP Answer 10.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer accepts one or When an answerer generates an answer, if the answerer accepts one or
more RTP-based "m=" lines within a BUNDLE group, the answerer MUST more RTP-based "m=" lines within a BUNDLE group, the answerer MUST
enable usage of RTP/RTCP multiplexing. The answerer MUST associate enable usage of RTP/RTCP multiplexing. The answerer MUST associate
an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the
answer. In addition, if an "m=" line in the corresponding offer answer. In addition, if an "m=" line in the corresponding offer
contained an SDP "rtcp-mux-only" attribute, the answerer MUST also contained an SDP "rtcp-mux-only" attribute, the answerer MUST
associate an SDP "rtcp-mux-only" attribute with the "m=" line in the associate an SDP "rtcp-mux-only" attribute with the "m=" line in the
answer. answer.
If an RTP-based "m=" line in the corresponding offer did not contain If an RTP-based "m=" line in the corresponding offer did not contain
an SDP "rtcp-mux" attribute or an SDP "rtcp-mux-only" attribute, the an SDP 'rtcp-mux' attribute, the answerer MUST NOT include the "m="
answerer MUST NOT include the "m=" line within a BUNDLE group in the line within a BUNDLE group in the answer.
answer.
If an RTP-based "m=" line in the corresponding offer contained an SDP If an RTP-based "m=" line in the corresponding offer contained an SDP
"rtcp-mux-only" attribute, and if the answerer moves the "m=" line "rtcp-mux-only" attribute, and if the answerer moves the "m=" line
out of the BUNDLE group in the answer Section 8.3.3, the answerer out of the BUNDLE group in the answer Section 8.3.3, the answerer
MUST still either enable RTP/RTCP multiplexing for the media MUST still either enable RTP/RTCP multiplexing for the media
associated with the "m=" line, or reject the "m=" line Section 8.3.4. associated with the "m=" line, or reject the "m=" line Section 8.3.4.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any The answerer MUST NOT associate an SDP 'rtcp' attribute with any
bundled "m=" line in the answer. The answerer will use the port bundled "m=" line in the answer. The answerer will use the port
value of the selected offerer BUNDLE address for sending RTP and RTCP value of the selected offerer BUNDLE address for sending RTP and RTCP
skipping to change at page 23, line 34 skipping to change at page 24, line 7
[RFC5761]. The offerer will use the port value associated with the [RFC5761]. The offerer will use the port value associated with the
answerer BUNDLE address for sending RTP and RTCP packets associated answerer BUNDLE address for sending RTP and RTCP packets associated
with each RTP-based bundled "m=" line towards the answerer. with each RTP-based bundled "m=" line towards the answerer.
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines
that the answerer included in the BUNDLE group. that the answerer included in the BUNDLE group.
10.3.1.4. Modifying the Session 10.3.1.4. Modifying the Session
When an offerer generates a subsequent offer, it MUST associate an When an offerer generates a subsequent offer, for each RTP-based "m="
SDP 'rtcp-mux' attribute or an SDP 'rtcp-mux-only' attribute with line that was previously added to the BUNDLE group the offerer MUST
each RTP-based bundled "m=" line within the BUNDLE group (including associate an SDP 'rtcp-mux' attribute and an SDP 'rtcp-mux-only'
any bundled RTP-based "m=" line that the offerer wants to add to the attribute with the "m=" line in the same way it was previously done,
BUNDLE group), unless the offerer wants to disable or remove the "m=" unless the offerer wants to disable or remove the "m=" line from the
line from the BUNDLE group. BUNDLE group.
If the offerer wants to add a bundled RTP-based "m=" line to the
BUNDLE group, it associates an SDP 'rtcp-mux' attribute and an SDP
'rtcp-mux-only' attribute with the "m=" line using the procedures in
[Section 10.3.1.1].
11. ICE Considerations 11. ICE Considerations
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [I-D.ietf-ice-rfc5245bis]. mechanism [I-D.ietf-ice-rfc5245bis].
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
skipping to change at page 28, line 30 skipping to change at page 29, line 14
14. RTP/RTCP extensions for identification-tag transport 14. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" lines within SDP Offers and Answers, using the tags with "m=" lines within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" line. an "m=" line.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension [RFC7914], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
The SDES item and RTP SDES header extension make it possible for a The SDES item and RTP SDES header extension make it possible for a
receiver to associate received RTCP- and RTP packets with a specific receiver to associate received RTCP- and RTP packets with a specific
"m=" line, with which the receiver has associated an identification- "m=" line, with which the receiver has associated an identification-
tag, even if those "m=" lines are part of the same RTP session. The tag, even if those "m=" lines are part of the same RTP session. The
RTP SDES header extension also ensures that the media recipient gets RTP SDES header extension also ensures that the media recipient gets
the identification-tag upon receipt of the first decodable media and the identification-tag upon receipt of the first decodable media and
is able to associate the media with the correct application. is able to associate the media with the correct application.
skipping to change at page 29, line 47 skipping to change at page 30, line 29
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
14.2. RTP SDES Header Extension For MID 14.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
two-byte header [RFC7914]. The identification-tag payload is UTF-8 two-byte header [RFC7941]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that the set of The identification-tag is not zero terminated. Note, that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC5285]. next 32-bit boundary using zero bytes [RFC5285].
As the identification-tag is included in either an RTCP SDES item or As the identification-tag is included in either an RTCP SDES item or
an RTP SDES header extension, or both, there should be some an RTP SDES header extension, or both, there should be some
consideration about the packet expansion caused by the consideration about the packet expansion caused by the
identification-tag. To avoid Maximum Transmission Unit (MTU) issues identification-tag. To avoid Maximum Transmission Unit (MTU) issues
skipping to change at page 41, line 9 skipping to change at page 42, line 9
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.
19. Change Log 19. 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-33
o Editorial changes based on comments from Eric Rescorla and Cullen
Jennings:
o - Changes regarding usage of RTP/RTCP multiplexing attributes.
o - Additional text regarding associating RTP/RTCP packets with SDP
m- lines.
o - Reference correction.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32
o Editorial changes based on comments from Eric Rescorla and Cullen o Editorial changes based on comments from Eric Rescorla and Cullen
Jennings: Jennings:
o - Justification for mechanism added to Introduction. o - Justification for mechanism added to Introduction.
o - Clarify that the order of m- lines in the group:BUNDLE attribute o - Clarify that the order of m- lines in the group:BUNDLE attribute
does not have to be the same as the order in which the m- lines does not have to be the same as the order in which the m- lines
are listed in the SDP. are listed in the SDP.
skipping to change at page 50, line 5 skipping to change at page 51, line 20
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Header Extension for the RTP Control Protocol (RTCP)
August 2016, <http://www.rfc-editor.org/info/rfc7914>. Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-04 (work in progress), June 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14
 End of changes. 27 change blocks. 
82 lines changed or deleted 116 lines changed or added

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