draft-ietf-mmusic-sdp-bundle-negotiation-20.txt   draft-ietf-mmusic-sdp-bundle-negotiation-21.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: December 14, 2015 C. Jennings Expires: December 17, 2015 C. Jennings
Cisco Cisco
June 12, 2015 June 15, 2015
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-20.txt draft-ietf-mmusic-sdp-bundle-negotiation-21.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, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 14, 2015. This Internet-Draft will expire on December 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 16 skipping to change at page 3, line 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 18 Description . . . . . . . . . . . . . . . . . . . . . . 18
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 19 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 17, line 5 skipping to change at page 17, line 5
of the transport-layer protocol, there MUST exist a publicly of the transport-layer protocol, there MUST exist a publicly
available specification which describes a mechanism, for this available specification which describes a mechanism, for this
particular protocol combination, how to associate a received packet particular protocol combination, how to associate a received packet
with the correct protocol. with the correct protocol.
In addition, if a received packet can be associated with more than In addition, if a received packet can be associated with more than
one bundled "m=" line, there MUST exist a publicly available one bundled "m=" line, there MUST exist a publicly available
specification which describes a mechanism for associating the specification which describes a mechanism for associating the
received packet with the correct "m=" line. received packet with the correct "m=" line.
This document describes a mechanism to identify the protocol of a
received packet among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but does
not describe how to identify different protocols transported on DTLS.
While the mechanism is generally applicable to other protocols and
transport-layers protocols, any such use requires further
specification around how to multiplex multiple protocols on a given
transport-layer protocols, and how to associate received packets with
the correct protocols.
9.2. STUN, DTLS, SRTP 9.2. STUN, DTLS, SRTP
Section 5.1.2 of [RFC5764] describes a mechanism to identify the Section 5.1.2 of [RFC5764] describes a mechanism to identify the
protocol of a received packet among the STUN, Datagram Transport protocol of a received packet among the STUN, Datagram Transport
Layer Security (DTLS) and SRTP protocols (in any combination). If an Layer Security (DTLS) and SRTP protocols (in any combination). If an
offer or answer includes bundled "m=" lines that represent these offer or answer includes bundled "m=" lines that represent these
protocols, the offerer or answerer MUST support the mechanism protocols, the offerer or answerer MUST support the mechanism
described in [RFC5764], and no explicit negotiation is required in described in [RFC5764], and no explicit negotiation is required in
order to indicate support and usage of the mechanism. order to indicate support and usage of the mechanism.
skipping to change at page 24, line 30 skipping to change at page 24, line 32
o There can only be one DTLS association [RFC6347] associated with o There can only be one DTLS association [RFC6347] associated with
the BUNDLE group; the BUNDLE group;
o Each usage of the DTLS association within the BUNDLE group MUST o Each usage of the DTLS association within the BUNDLE group MUST
use the same mechanism for determining which endpoints (the use the same mechanism for determining which endpoints (the
offerer or answerer) becomes DTLS client and DTLS server; and offerer or answerer) becomes DTLS client and DTLS server; and
o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include
the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
[RFC5764], The client MUST include the extension even if the usage [RFC5764], The client MUST include the extension even if the usage
of DTLS-SRTP is not negotiated as part of the session. of DTLS-SRTP is not negotiated as part of the multimedia session
(e.g. SIP session [RFC3261].
NOTE: The inclusion of the 'use_srtp' extension during the initial NOTE: The inclusion of the 'use_srtp' extension during the initial
DTLS handshake ensures that a DTLS renegotiation will not be required DTLS handshake ensures that a DTLS renegotiation will not be required
in order to include the extension, in case DTLS-SRTP encrypted media in order to include the extension, in case DTLS-SRTP encrypted media
is added to the BUNDLE group later during the session. is added to the BUNDLE group later during the multimedia session.
13. Update to RFC 3264 13. Update to RFC 3264
13.1. General 13.1. General
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 8.2 (Removing a Media Stream). o Section 8.2 (Removing a Media Stream).
skipping to change at page 38, line 35 skipping to change at page 38, line 35
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-18 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
o - Clarification based on comment from James Guballa.
o - Clarification based on comment from Flemming Andreasen
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19
o - DTLS Considerations section added. o - DTLS Considerations section added.
o - BUNDLE semantics added to the IANA Considerations o - BUNDLE semantics added to the IANA Considerations
o - Changes based on WGLC comments from Adam Roach o - Changes based on WGLC comments from Adam Roach
o -- http://www.ietf.org/mail-archive/web/mmusic/current/ o -- http://www.ietf.org/mail-archive/web/mmusic/current/
msg14673.html msg14673.html
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18
o - Changes based on agreements at IETF#92 o - Changes based on agreements at IETF#92
o -- BAS Offer removed, based on agreement at IETF#92. o -- BAS Offer removed, based on agreement at IETF#92.
o -- Procedures regarding usage of SDP "b=" line is replaced with a o -- Procedures regarding usage of SDP "b=" line is replaced with a
reference to to draft-ietf-mmusic-sdp-mux-attributes. reference to to draft-ietf-mmusic-sdp-mux-attributes.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
o - Editorial changes based on comments from Magnus Westerlund. o - Editorial changes based on comments from Magnus Westerlund.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
 End of changes. 11 change blocks. 
9 lines changed or deleted 26 lines changed or added

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