Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
draft-ietf-mmusic-mux-exclusive-04

Abstract

This document defines a new SDP media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 17, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. SDP rtcp-mux-only Attribute
• 4. SDP Offer/Answer Procedures
• 4.1. General
• 4.2. Generating the Initial SDP Offer
• 4.3. Generating the Answer
• 4.4. Offerer Processing of the SDP Answer
• 4.5. Modifying the Session
• 5. Update to RFC 5761
• 5.1. General
• 5.2. Update to 4th paragraph of section 5.1.1
• 5.3. Update to 2nd paragraph of section 5.1.3
• 6. ICE Considerations
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgments
• 10. Change Log
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Author's Address

1. Introduction

[RFC5761] defines how to multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing. [RFC5761] also defines an Session Description Protocol (SDP) [RFC4566] attribute, 'rtcp-mux' that can be used by entities to indicate support, and negotiate usage of, RTP/RTCP multiplexing.

As defined in [RFC5761], if the peer endpoint does not support RTP/RTCP multiplexing, both endpoints should use separate ports for sending and receiving of RTCP (referred to as fallback to usage of separate ports for RTP and RTCP).

Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not implement separation of RTP and RTCP. For those applications, this document defines an SDP attribute to signal intent to require multiplexing.

This document defines a new SDP media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

The document also describes the Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when indicating exclusive support of RTP/RTCP multiplexing.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. SDP rtcp-mux-only Attribute

This section defines a new SDP media-level attribute, 'rtcp-mux-only'.

       Name: rtcp-mux-only

       Value: N/A

       Usage Level: media

       Charset Dependent: no

       Syntax:

           rtcp-mux-only

       Example:

           a=rtcp-mux-only
           
           	

In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to indicate exclusive support of RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line).

In an SDP answer, the 'rtcp-mux-only' attribute indicates that the answerer supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line).

The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media.

The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-mux-only' attribute is 'NORMAL', which means that the attribute can be associated with an individual media description, even if the media description is multiplexed with other media descriptions [I-D.ietf-mmusic-sdp-bundle-negotiation] with which the attribute is not associated.

The 'rtcp-mux-only' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC5576]).

The SDP offer/answer [RFC3264] procedures associated with the attribute are defined in Section 4

4. SDP Offer/Answer Procedures

4.1. General

This section defines the SDP offer/answer [RFC3264] procedures for indicating exclusive support of, and negotiating usage of, RTP/RTCP multiplexing.

The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines).

4.2. Generating the Initial SDP Offer

When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line).

In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761].

If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an SDP media description ("m=" line), and if the offerer also associates an SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP.

NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing.

4.3. Generating the Answer

When an answerer receives an offer that contains an SDP 'rtcp-mux-only' attribute, associated with an RTP-based SDP media description ("m=" line), if the answerer accepts the usage of RTP/RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' attribute with the corresponding SDP media description ("m=") in the associated answer. If the answerer does not accept the usage of RTP/RTCP multiplexing, the answerer MUST either reject the SDP media description ("m=") by setting the port value to zero in the associated answer, or reject the whole offer, following the procedures in [RFC3264].

In addition, if the answerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer, and if the corresponding "m=" line in the associated offer contained an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate an SDP 'rtcp-mux' attribute with the same "m=" line, following the procedures in [RFC5761].

4.4. Offerer Processing of the SDP Answer

If an offerer associated an SDP 'rtcp-mux-only' attribute with an RTP-based SDP media description ("m=" line) in an offer, and if the corresponding SDP media description ("m=" line) in the associated answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP-based media. If the corresponding SDP media description ("m=" line) in the associated answer does not contain an SDP 'rtcp-mux-only' attribute, nor an SDP 'rtcp-mux' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media, or send a new offer without associating an SDP 'rtcp-mux-only' attribute with the SDP media description ("m=" line).

NOTE: This document does not mandate specific actions on how to 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 order to terminate the RTP media.

4.5. Modifying the Session

When an offerer sends a subsequent offer, if the offerer and answerer have previously negotiated usage of exclusive RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with the corresponding SDP media description ("m=" line).

In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MAY also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761].

If the offerer does not associate the attributes with the corresponding SDP media description ("m=" line) it is an indication that the offerer no longer wants to use RTP/RTCP multiplexing, and instead MUST fallback to usage of separate ports for RTP and RTCP once the offer has been accepted by the answerer.

When an offerer sends a subsequent offer, if the offerer and answerer have not previously negotiated usage of RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, following the procedures in Section 4.2. The offerer MUST process the associated answer following the procedures in Section 4.4.

NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use-case that mandates it.

5. Update to RFC 5761

5.1. General

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 not able to send and receive RTCP on separate ports, and that the offerer shall terminate the affected streams if the answerer does not indicate support of RTP/RTCP multiplexing. It also clarifies that, when the offerer is not able to send and receive RTCP on separate ports, the offerer will not provide an SDP 'candidate' attribute for RTCP, nor will the offerer provide a fallback port for RTCP (using the SDP 'rtcp' attribute).

5.2. Update to 4th paragraph of section 5.1.1

OLD TEXT:

   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,
   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
   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"
   attribute.

   
NEW TEXT:

   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,
   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
   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"
   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
   MUST disable the media streams associated with the attribute. The
   mechanism for indicating that the offerer is not able to send and 
   receive RTCP on a separate port is outside the scope of this 
   specification.   
      
                

5.3. Update to 2nd paragraph of section 5.1.3

OLD TEXT:
                                
   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
   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
   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 is desired.
        
            
NEW TEXT:
                                
   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
   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
   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 is desired. However, if the offerer 
   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:" lines 
   for RTCP, and the offerer MUST NOT provide a fallback port for RTCP using 
   the "a=rtcp:" line.
        
                

6. ICE Considerations

As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not as such imply exclusive support of RTP/RTCP multiplexing. RTCP candidates would not be provided also in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/RTCP multiplexing. This document defines such mechanism using the SDP 'rtcp-mux-only' attributes.

7. Security Considerations

This document does not introduce new security considerations in additions to those specified in [RFC3605] and [RFC5761].

8. IANA Considerations

This document updates the "Session Description Protocol Parameters" 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 level attributes.

    Attribute name: rtcp-mux-only
    Type of attribute: media-level
    Subject to charset: no
    Purpose: Indicate exclusive support of RTP/RTCP multiplexing
    Appropriate Values:
    Contact name: Christer Holmberg
    Category: NORMAL
    
    
			

9. Acknowledgments

Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas Frankkila and Martin Thomson for their comments and input on the document.

10. Change Log

[RFC EDITOR NOTE: Please remove this section when publishing]

Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03

• Editorial changes based on comments from Martin Thomson.
• Change of attribute name.
• RFC 5761 updates added.

Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02

• Minor editorial fix.

Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01

• Mux category and source-specific applicability added.

Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00

• Defined new SDP attribute for indicating rtcp-mux-exclusive.
• Updates to RFC 5761 removed.
• IANA considerations added.

Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03

• Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00.

Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02

• Intended status changed to "Standards track".

Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01

• Clarified that the SDP rtcp attribute may contain the optional IP address part.

Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00

• Additional updates to Section 5.1.1 of RFC 5761.
• ICE considerations added.

11. References

11.1. Normative References

11.2. Informative References

Author's Address