draft-ietf-mmusic-mux-exclusive-11.txt   draft-ietf-mmusic-mux-exclusive-12.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5761 (if approved) February 17, 2017 Updates: 5761 (if approved) May 5, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: August 21, 2017 Expires: November 6, 2017
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
draft-ietf-mmusic-mux-exclusive-11.txt draft-ietf-mmusic-mux-exclusive-12.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 August 21, 2017. This Internet-Draft will expire on November 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 2, line 22 skipping to change at page 2, line 22
4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5
4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5
4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6
4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6
5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7
5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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/
skipping to change at page 3, line 19 skipping to change at page 3, line 19
is preferred is where an endpoint is connected to a radio interface, is preferred is where an endpoint is connected to a radio interface,
and wants to use different bearers (possibly with different quality and wants to use different bearers (possibly with different quality
characteristics) for RTP and RTCP. Another example is where the one characteristics) for RTP and RTCP. Another example is where the one
endpoint is acting as a gateway to a network where RTP/RTCP endpoint is acting as a gateway to a network where RTP/RTCP
multiplexing cannot be used. In such case there endpoint may prefer multiplexing cannot be used. In such case there endpoint may prefer
non-multiplexing also towards the other network. Otherwise the non-multiplexing also towards the other network. Otherwise the
endpoint would have to perform de-multiplexing of RTP and RTCP. endpoint would have to perform de-multiplexing of RTP and RTCP.
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 [RFC5761], 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.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 30 skipping to change at page 4, line 30
In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute
to indicate exclusive support of RTP/RTCP multiplexing for the RTP- to indicate exclusive support of RTP/RTCP multiplexing for the RTP-
based media associated with the SDP media description ("m=" line). based media associated with the SDP media description ("m=" line).
In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that
the answerer supports, and accepts usage of, RTP/RTCP multiplexing the answerer supports, and accepts usage of, RTP/RTCP multiplexing
for the RTP-based media associated with the SDP media description for the RTP-based media associated with the SDP media description
("m=" line). ("m=" line).
The usage of the 'rtcp-mux-only' attribue in an SDP answer is The usage of the 'rtcp-mux-only' attribute in an SDP answer is
forbidden. forbidden.
The usage of the SDP 'rtcp-mux-only' attribute is only defined for The usage of the SDP 'rtcp-mux-only' attribute is only defined for
RTP-based media. RTP-based media.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-
mux-only' attribute is 'IDENTICAL', which means that the attribute, mux-only' attribute is 'IDENTICAL', which means that the attribute,
if used within a BUNDLE group if used within a BUNDLE group
[I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all
multiplexed RTP-based media descriptions within the BUNDLE group. multiplexed RTP-based media descriptions within the BUNDLE group.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
the associated answer following the procedures in Section 4.4. the associated answer following the procedures in Section 4.4.
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 [RFC5761], 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
offerer shall terminate the affected streams if the answerer does not offerer shall terminate the affected streams if the answerer does not
indicate support of RTP/RTCP multiplexing. It also clarifies that, indicate support of RTP/RTCP multiplexing. It also clarifies that,
when the offerer is not able to send and receive RTCP on separate when the offerer is not able to send and receive RTCP on separate
ports, the offerer will not provide an SDP 'candidate' attribute for ports, the offerer will not provide an SDP 'candidate' attribute for
RTCP, nor will the offerer provide a fallback port for RTCP (using RTCP, nor will the offerer provide a fallback port for RTCP (using
the SDP 'rtcp' attribute). the SDP 'rtcp' attribute).
5.2. Update to 4th paragraph of section 5.1.1 5.2. Update to 4th paragraph of section 5.1.1
NOTE: [RFC8035] also updates section 5.1.1 of [RFC5761]. While the
paragraph updated in this document is not updated by [RFC8035], the
location of the paragraph within section 5.1.1 is moved.
OLD TEXT: OLD 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 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.
skipping to change at page 9, line 30 skipping to change at page 10, line 25
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. Thanks to Francis Dupont for the genart review. 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-11
o Clarification note added to RFF 5761 update section.
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10
o Changes based on comments from Ekr: o Changes based on comments from Ekr:
o - 'rtcp-mux-only' attribute only defined for SDP offers o - 'rtcp-mux-only' attribute only defined for SDP offers
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09
o Changes based on IESG review comments from Alexey Melnikov and o Changes based on IESG review comments from Alexey Melnikov and
Mirja Kuhlewind: Mirja Kuhlewind:
skipping to change at page 12, line 10 skipping to change at page 13, line 10
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/
Answer Clarifications for RTP/RTCP Multiplexing",
RFC 8035, DOI 10.17487/RFC8035, November 2016,
<http://www.rfc-editor.org/info/rfc8035>.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 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-36 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
 End of changes. 12 change blocks. 
15 lines changed or deleted 28 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/