draft-ietf-mmusic-mux-exclusive-07.txt   draft-ietf-mmusic-mux-exclusive-08.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5761 (if approved) June 10, 2016 Updates: 5761 (if approved) June 22, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2016 Expires: December 24, 2016
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
draft-ietf-mmusic-mux-exclusive-07 draft-ietf-mmusic-mux-exclusive-08.txt
Abstract Abstract
This document defines a new SDP media-level attribute, 'rtcp-mux- This document defines a new SDP media-level attribute, 'rtcp-mux-
only', that can be used by an endpoint to indicate exclusive support only', that can be used by an endpoint to indicate exclusive support
of RTP/RTCP multiplexing. The document also updates RFC 5761, by of RTP/RTCP multiplexing. The document also updates RFC 5761, by
clarifying that an offerer can use a mechanism to indicate that it is clarifying that an offerer can use a mechanism to indicate that it is
not able to send and receive RTCP on separate ports. not able to send and receive RTCP on separate ports.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 12, 2016. This Internet-Draft will expire on December 24, 2016.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3
4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4
4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5
4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 5 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 5
4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 5
5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 6 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 6
5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 7 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 7
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC5761] defines how to multiplex RTP and RTCP on a single IP [RFC5761] defines how to multiplex RTP and RTCP on a single IP
address and port, referred to as RTP/RTCP multiplexing. [RFC5761] address and port, referred to as RTP/RTCP multiplexing. [RFC5761]
also defines an Session Description Protocol (SDP) [RFC4566] also defines an Session Description Protocol (SDP) [RFC4566]
attribute, 'rtcp-mux' that can be used by entities to indicate attribute, 'rtcp-mux' that can be used by entities to indicate
support, and negotiate usage of, RTP/RTCP multiplexing. support, and negotiate usage of, RTP/RTCP multiplexing.
As defined in [RFC5761], if the peer endpoint does not support RTP/ As defined in [RFC5761], if the peer endpoint does not support RTP/
RTCP multiplexing, both endpoints should use separate ports for RTCP multiplexing, both endpoints should use separate ports for
sending and receiving of RTCP (referred to as fallback to usage of sending and receiving of RTCP (referred to as fallback to usage of
separate ports for RTP and RTCP). separate ports for RTP and RTCP).
Some newer applications that do not require backward compatibility Some newer applications that do not require backward compatibility
with peers that cannot multiplex RTCP might choose to not implement with peers that cannot multiplex RTCP might choose to not implement
separation of RTP and RTCP. For those applications, this document separation of RTP and RTCP. Examples of such applications are W3C
defines an SDP attribute to signal intent to require multiplexing. WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required
to interoperate with non-WEBRTC clients. For such applications, this
document defines an SDP attribute to signal intent to require
multiplexing. The use of this attribute in SDP offers [RFC3264] by
entities that ever need to interoperate with peers that do not
support RTC/RTCP multiplexing may harm interoperability.
This document defines a new SDP media-level attribute, 'rtcp-mux- This document defines a new SDP media-level attribute, 'rtcp-mux-
only', that can be used by an endpoint to indicate exclusive support only', that can be used by an endpoint to indicate exclusive support
of RTP/RTCP multiplexing. The document also updates RFC 5761, by of RTP/RTCP multiplexing. The document also updates RFC 5761, by
clarifying that an offerer can use a mechanism to indicate that it is clarifying that an offerer can use a mechanism to indicate that it is
not able to send and receive RTCP on separate ports. not able to send and receive RTCP on separate ports.
The document also describes the Interactive Connectivity The document also describes the Interactive Connectivity
Establishment (ICE) [RFC5245] considerations when indicating Establishment (ICE) [RFC5245] considerations when indicating
exclusive support of RTP/RTCP multiplexing. exclusive support of RTP/RTCP multiplexing.
skipping to change at page 6, line 31 skipping to change at page 6, line 25
instead MUST fallback to usage of separate ports for RTP and RTCP instead MUST fallback to usage of separate ports for RTP and RTCP
once the offer has been accepted by the answerer. once the offer has been accepted by the answerer.
When an offerer sends a subsequent offer, if the offerer and answerer When an offerer sends a subsequent offer, if the offerer and answerer
have not previously negotiated usage of RTP/RTCP multiplexing for the have not previously negotiated usage of RTP/RTCP multiplexing for the
media associated with an RTP-based SDP media description ("m=" line), media associated with an RTP-based SDP media description ("m=" line),
the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, the offerer MAY indicate exclusive support of RTP/RTCP multiplexing,
following the procedures in Section 4.2. The offerer MUST process following the procedures in Section 4.2. The offerer MUST process
the associated answer following the procedures in Section 4.4. the associated answer following the procedures in Section 4.4.
NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP It is RECOMMENDED to not switch between usage of RTP/RTCP
multiplexing and usage of separate ports for RTP and RTCP in a multiplexing and usage of separate ports for RTP and RTCP in a
subsequent offer, unless there is a use-case that mandates it. subsequent offer, unless there is a use-case that mandates it.
5. Update to RFC 5761 5. Update to RFC 5761
5.1. General 5.1. General
This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by
clarifying that an offerer can use a mechanism to indicate that it is clarifying that an offerer can use a mechanism to indicate that it is
not able to send and receive RTCP on separate ports, and that the not able to send and receive RTCP on separate ports, and that the
skipping to change at page 9, line 12 skipping to change at page 9, line 12
This document updates the "Session Description Protocol Parameters" This document updates the "Session Description Protocol Parameters"
registry as specified in Section 8.2.2 of [RFC4566]. Specifically, registry as specified in Section 8.2.2 of [RFC4566]. Specifically,
it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media
level attributes. level attributes.
Attribute name: rtcp-mux-only Attribute name: rtcp-mux-only
Type of attribute: media-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: Indicate exclusive support of RTP/RTCP multiplexing Purpose: Indicate exclusive support of RTP/RTCP multiplexing
Appropriate Values: N/A Appropriate Values: N/A
Contact name: Christer Holmberg (christert.holmberg@ericsson.com) Contact name: Christer Holmberg (christer.holmberg@ericsson.com)
Mux Category: IDENTICAL Mux Category: IDENTICAL
9. Acknowledgments 9. Acknowledgments
Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas
Frankkila and Martin Thomson for their comments and input on the Frankkila and Martin Thomson for their comments and input on the
document. document.
10. Change Log 10. 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-rtcp-mux-exclusive-07
o Comments from Ben Campbell.
o - Additional text regarding applications for which the mechanism
is suitable.
o - Removal of pre-RFC5378 disclaimer.
o - Editorial fixes.
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06
o - Editorial fix. o - Editorial fix.
o - Addition of pre-RFC5378 disclaimer. o - Addition of pre-RFC5378 disclaimer.
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05
o Editorial fix. o Editorial fix.
skipping to change at page 11, line 46 skipping to change at page 12, line 9
[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-12 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016. (work in progress), January 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-30 (work in progress), June 2016. negotiation-31 (work in progress), June 2016.
[W3C.WD-webrtc-20120209]
Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc-
20120209, February 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 15 change blocks. 
26 lines changed or deleted 38 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/