draft-ietf-mmusic-sdp-bundle-negotiation-21.txt   draft-ietf-mmusic-sdp-bundle-negotiation-22.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 17, 2015 C. Jennings Expires: December 18, 2015 C. Jennings
Cisco Cisco
June 15, 2015 June 16, 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-21.txt draft-ietf-mmusic-sdp-bundle-negotiation-22.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 17, 2015. This Internet-Draft will expire on December 18, 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 16, line 43 skipping to change at page 16, line 43
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
9.1. General 9.1. General
Each "m=" line within a BUNDLE group MUST use the same transport- Each "m=" line within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" lines use different protocols on top layer protocol. If bundled "m=" lines use different protocols on top
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 data
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 data can be associated with more than one
one bundled "m=" line, there MUST exist a publicly available 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 data with the correct "m=" line.
This document describes a mechanism to identify the protocol of a This document describes a mechanism to identify the protocol of
received packet among the STUN, DTLS and SRTP protocols (in any received data among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but does combination), when UDP is used as transport-layer protocol, but does
not describe how to identify different protocols transported on DTLS. not describe how to identify different protocols transported on DTLS.
While the mechanism is generally applicable to other protocols and While the mechanism is generally applicable to other protocols and
transport-layers protocols, any such use requires further transport-layers protocols, any such use requires further
specification around how to multiplex multiple protocols on a given specification around how to multiplex multiple protocols on a given
transport-layer protocols, and how to associate received packets with transport-layer protocols, and how to associate received data with
the correct protocols. 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
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-21
o - Correct based on comment from Paul Kyzivat
o -- 'received packets' replaced with 'received data'
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
o - Clarification based on comment from James Guballa. o - Clarification based on comment from James Guballa
o - Clarification based on comment from Flemming Andreasen o - Clarification based on comment from Flemming Andreasen
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 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
 End of changes. 11 change blocks. 
12 lines changed or deleted 18 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/