draft-ietf-mmusic-mux-exclusive-08.txt   draft-ietf-mmusic-mux-exclusive-09.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5761 (if approved) June 22, 2016 Updates: 5761 (if approved) July 18, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 24, 2016 Expires: January 19, 2017
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
draft-ietf-mmusic-mux-exclusive-08.txt draft-ietf-mmusic-mux-exclusive-09.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 24, 2016. This Internet-Draft will expire on January 19, 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 5, line 44 skipping to change at page 5, line 44
'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP
multiplexing procedures [RFC5761] to the associated RTP-based media. multiplexing procedures [RFC5761] to the associated RTP-based media.
If the corresponding SDP media description ("m=" line) in the If the corresponding SDP media description ("m=" line) in the
associated answer does not contain an SDP 'rtcp-mux-only' attribute, associated answer does not contain an SDP 'rtcp-mux-only' attribute,
nor an SDP 'rtcp-mux' attribute, the offerer MUST either take nor an SDP 'rtcp-mux' attribute, the offerer MUST either take
appropriate actions in order to disable the associated RTP-based appropriate actions in order to disable the associated RTP-based
media, or send a new offer without associating an SDP 'rtcp-mux-only' media, or send a new offer without associating an SDP 'rtcp-mux-only'
attribute with the SDP media description ("m=" line). attribute with the SDP media description ("m=" line).
NOTE: This document does not mandate specific actions on how to NOTE: This document does not mandate specific actions on how to
terminate the RTP media. The offerer might e.g. send a new offer, terminate the RTP media. The offerer might e.g. send a new offer
where the port value of the SDP media description is set to zero, in where the port value of the SDP media description is set to zero in
order to terminate the RTP media. order to terminate the RTP media.
4.5. Modifying the Session 4.5. Modifying the Session
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 previously negotiated usage of exclusive RTP/RTCP multiplexing have previously negotiated usage of exclusive RTP/RTCP multiplexing
for the media associated with an RTP-based SDP media description for the media associated with an RTP-based SDP media description
("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with
the corresponding SDP media description ("m=" line). the corresponding SDP media description ("m=" line).
skipping to change at page 7, line 19 skipping to change at page 7, line 19
usual port-selection rules (either the port pair, or a signalled port usual port-selection rules (either the port pair, or a signalled port
if the "a=rtcp:" attribute [10] is also included). This will occur if the "a=rtcp:" attribute [10] is also included). This will occur
when talking to a peer that does not understand the "a=rtcp-mux" when talking to a peer that does not understand the "a=rtcp-mux"
attribute. attribute.
NEW TEXT: NEW TEXT:
If the answer does not contain an "a=rtcp-mux" attribute, the offerer If the answer does not contain an "a=rtcp-mux" attribute, the offerer
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, MUST NOT multiplex RTP and RTCP packets on a single port. Instead,
it should send and receive RTCP on a port allocated according to the it should send and receive RTCP on a port allocated according to the
usual port-selection rules (either the port pair, or a signalled port usual port-selection rules (either the port pair, or a signaled port
if the "a=rtcp:" attribute [10] is also included). This will occur if the "a=rtcp:" attribute [10] is also included). This will occur
when talking to a peer that does not understand the "a=rtcp-mux" when talking to a peer that does not understand the "a=rtcp-mux"
attribute. However, if the offerer indicated in the offer that it is attribute. However, if the offerer indicated in the offer that it is
not able to send and receive RTCP on a separate port, the offerer not able to send and receive RTCP on a separate port, the offerer
MUST disable the media streams associated with the attribute. The MUST disable the media streams associated with the attribute. The
mechanism for indicating that the offerer is not able to send and mechanism for indicating that the offerer is not able to send and
receive RTCP on a separate port is outside the scope of this receive RTCP on a separate port is outside the scope of this
specification. specification.
5.3. Update to 2nd paragraph of section 5.1.3 5.3. Update to 2nd paragraph of section 5.1.3
skipping to change at page 8, line 24 skipping to change at page 8, line 24
NEW TEXT: NEW TEXT:
If it is desired to use both ICE and multiplexed RTP and RTCP, the If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
fallback port for RTCP in the case that the answerer does not support fallback port for RTCP in the case that the answerer does not support
RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing. This MUST be done for each media where
RTP and RTCP multiplexing is desired. However, if the offerer RTP and RTCP multiplexing is desired. However, if the offerer
indicates in the offer that it is not able to send and receive RTCP indicates in the offer that it is not able to send and receive RTCP
on a separate port, the offerer MUST NOT include "a=candidiate:" on a separate port, the offerer MUST NOT include "a=candidate:"
lines for RTCP, and the offerer MUST NOT provide a fallback port for lines for RTCP, and the offerer MUST NOT provide a fallback port for
RTCP using the "a=rtcp:" line. RTCP using the "a=rtcp:" line.
6. ICE Considerations 6. ICE Considerations
As defined in [RFC5245], if an entity is aware that the remote peer As defined in [RFC5245], if an entity is aware that the remote peer
supports, and is willing to use, RTP/RTCP multiplexing, the entity supports, and is willing to use, RTP/RTCP multiplexing, the entity
will only provide RTP candidates (component ID 1). However, only will only provide RTP candidates (component ID 1). However, only
providing RTP candidates does not as such imply exclusive support of providing RTP candidates does not as such imply exclusive support of
RTP/RTCP multiplexing. RTCP candidates would not be provided also in RTP/RTCP multiplexing. RTCP candidates would not be provided also in
skipping to change at page 9, line 19 skipping to change at page 9, line 19
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 (christer.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. Thanks to Francis Dupont for the genart review.
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-08
o Editorial changes based on genart comments from Francis Dupont.
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07
o Comments from Ben Campbell. o Comments from Ben Campbell.
o - Additional text regarding applications for which the mechanism o - Additional text regarding applications for which the mechanism
is suitable. is suitable.
o - Removal of pre-RFC5378 disclaimer. o - Removal of pre-RFC5378 disclaimer.
o - Editorial fixes. o - Editorial fixes.
 End of changes. 9 change blocks. 
9 lines changed or deleted 13 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/