draft-ietf-mmusic-sdp-bundle-negotiation-34.txt   draft-ietf-mmusic-sdp-bundle-negotiation-35.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 22, 2017 C. Jennings Expires: April 28, 2017 C. Jennings
Cisco Cisco
October 19, 2016 October 25, 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-34.txt draft-ietf-mmusic-sdp-bundle-negotiation-35.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 22, 2017. This Internet-Draft will expire on April 28, 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 22 skipping to change at page 3, line 22
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16
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 Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . 26 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 26
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 20, line 40 skipping to change at page 20, line 40
session, in order for a given payload type value to be used inside session, in order for a given payload type value to be used inside
more than one bundled "m=" line, all codecs associated with the more than one bundled "m=" line, all codecs associated with the
payload type number MUST share an identical codec configuration. payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values must be identical for all codecs that use the same
payload type value. payload type value.
10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description
There are multiple mechanisms that can be used by an endpoint in As described in [RFC3550], RTP/RTCP packets are associated with RTP
order to associate received RTP/RTCP packets with a bundled "m=" streams. Each RTP stream is identified by an SSRC value, and each
line. Such mechanisms include using the payload type value carried RTP/RTCP packet carries an SSRC value that is used to associate the
inside the RTP packets, the SSRC values carried inside the RTP packet with the correct RTP stream (an RTCP packet can carry multiple
packets, and other "m=" line specific information carried inside the SSRC values, and might therefore be associated with multiple RTP
RTP packets. streams).
As all RTP/RTCP packets associated with a BUNDLE group are received In order to be able to process received RTP/RTCP packets correctly it
(and sent) using single address:port combinations, the local must be possible to associate an RTP stream with the correct "m="
address:port combination cannot be used to associate received RTP line, as the "m=" line and SDP attributes associated with the "m="
packets with the correct "m=" line. line contain information needed to process the packets.
As described in [Section 10.1.1], the same payload type value might As all RTP streams associated with a BUNDLE group are using the same
be used inside RTP packets described by multiple "m=" lines. In such address:port combination for sending and receiving RTP/RTCP packets,
cases, the payload type value cannot be used to associate received the local address:port combination cannot be used to associate an RTP
RTP packets with the correct "m=" line. stream with the correct "m=" line. In addition, multiple RTP streams
might be associated with the same "m=" line.
Also, as described in [Section 10.1.1], the same payload type value
might be used by multiple RTP streams, in which case the payload type
value cannot be used to associate an RTP stream with the correct "m="
line.
An offerer and answerer can inform each other which SSRC values they An offerer and answerer can inform each other which SSRC values they
will use for RTP and RTCP by using the SDP 'ssrc' attribute will use for an RTP stream by using the SDP 'ssrc' attribute
[RFC5576]. To allow for proper association with this mechanism, the [RFC5576]. However, an offerer will not know which SSRC values the
'ssrc' attribute needs to be associated with each "m=" line that answerer will use until the offerer has received the answer providing
shares a payload type with any other "m=" line in the same bundle. that information. Due to this, before the offerer has received the
As the SSRC values will be carried inside the RTP/RTCP packets, the answer, the offerer will not be able to associate an RTP stream with
offerer and answerer can then use that information to associate the correct "m=" line using the SSRC value associated with the RTP
received RTP packets with the correct "m=" line. However, an offerer stream. In addition, the offerer and answerer may start using new
will not know which SSRC values the answerer will use until it has SSRC values mid-session, without informing each other using the SDP
received the answer providing that information. Due to this, before 'ssrc' attribute.
the offerer has received the answer, the offerer will not be able to
associate received RTP packets with the correct "m=" line using the
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 packets with the correct "m=" line, an offerer and an RTP stream with the correct "m=" line, the offerer and answerer
answerer using the BUNDLE extension MUST support the mechanism using the BUNDLE extension MUST support the mechanism defined in
defined in Section 14, where the remote endpoint inserts the Section 14, where the offerer and answerer insert the identification-
identification-tag associated with an "m=" line in RTP and RTCP tag (provided by the remote peer) associated with an "m=" line in RTP
packets associated with that "m=" line. and RTCP packets associated with a BUNDLE group.
Once an offerer or answerer recieves an RTP/RTCP packet carrying an Once an offerer or answerer recieve an RTP/RTCP packet carrying an
identification-tag and an SSRC value, it associates the SSRC value identification-tag and an SSRC value (an RTCP packet might carry
with the "m=" line associated with the identification-tag. Later, multiple identification-tags and SSRC values), it creates a mapping
when an offerer or answerer receives an RTP or RTCP packet that does between the SSRC value and the identification-tag, in order to
not carry the identification-tag, it can associate the packet with associate the RTP stream with the "m=" line associated with the
the correct "m=" line using the SSRC value. Note that multiple SSRC identification-tag. Note that the mapping might change mid-session
values may end up being associated with the same "m=" line. if, for a given SSRC value, a different identification-tag is
provided in an RTP/RTCP packet.
If an offerer or answerer is not able to associate an RTP packet with If an offerer and answerer is not able to associate an RTP stream
the correct "m=" line using the SSRC value, the offerer or answerer with an "m=" line (using the mechanisms described in this section, or
can check whether the association can be done using the payload type using other appropriate mechanism, e.g, based on the payload type
value (in case the payload type value is unique for a given "m=" line value if it is unique to a single a€œm=a€ line),
within the BUNDLE group), or using other appropriate mechanisms. it MUST either drop the RTP/RTCP packets associated with the RTP
After all appropriate mechanisms supported by the offerer or answerer stream, or process them in an application specific manner, once non-
have been tried, if it is not possible to associate a packet with the stream specific processing (e.g., related to congestion control) of
correct "m=" line, the packet SHOULD be dropped after having been the packets have occurred. Note that RTCP packets might be
processed as received by the RTCP layer. associated with multiple RTP streams.
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
skipping to change at page 42, 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-34
o RTP streams, instead of RTP packets, are associated with m- lines.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33
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 - Changes regarding usage of RTP/RTCP multiplexing attributes. o - Changes regarding usage of RTP/RTCP multiplexing attributes.
o - Additional text regarding associating RTP/RTCP packets with SDP o - Additional text regarding associating RTP/RTCP packets with SDP
m- lines. m- lines.
 End of changes. 14 change blocks. 
55 lines changed or deleted 61 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/