RFC 7850 PROPOSED STANDARD RTP · SDP · REGISTRY

Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles

Seven new SDP names for carrying RTP media over TCP, plain, SRTP, DTLS-SRTP or TLS.

On rfc-editor.org ↗
PUBLISHED
April 2016
AUTHORS
S. Nandakumar
STREAM
IETF
NEW PROTO VALUES
7
FRAMING
RFC 4571
REGISTRY
proto subregistry of SDP Parameters
DOI
10.17487/RFC7850

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                     S. Nandakumar
Request for Comments: 7850                             Cisco Systems Inc
Category: Standards Track                                     April 2016
ISSN: 2070-1721


              Registering Values of the SDP 'proto' Field
     for Transporting RTP Media over TCP under Various RTP Profiles

Abstract

   The Real-time Transport Protocol (RTP) specification establishes a
   registry of profile names for use by higher-level control protocols,
   such as the Session Description Protocol (SDP), to refer to the
   transport methods.  This specification describes the following new
   SDP transport protocol identifiers for transporting RTP Media over
   TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF',
   'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and
   'TCP/TLS/RTP/AVPF'.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7850.

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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Identifiers  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  TCP/RTP/AVPF Transport Realization  . . . . . . . . . . .   3
     3.2.  TCP/RTP/SAVP Transport Realization  . . . . . . . . . . .   3
     3.3.  TCP/RTP/SAVPF Transport Realization . . . . . . . . . . .   3
     3.4.  TCP/DTLS/RTP/SAVP Transport Realization . . . . . . . . .   3
     3.5.  TCP/DTLS/RTP/SAVPF Transport Realization  . . . . . . . .   4
     3.6.  TCP/TLS/RTP/AVP Transport Realization . . . . . . . . . .   4
     3.7.  TCP/TLS/RTP/AVPF Transport Realization  . . . . . . . . .   4
   4.  ICE Considerations  . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Overview

   The Real-time Transport Protocol (RTP) provides end-to-end network
   transport functions suitable for applications transmitting real-time
   data such as audio or video over multicast or unicast network
   services.  The data transport is augmented by the RTP Control
   Protocol (RTCP) to allow monitoring of the data delivery in a manner
   scalable to large multicast networks and to provide minimal control
   and identification functionality.

   "SDP: Session Description Protocol" [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.  "TCP-Based Media Transport in the Session Description
   Protocol (SDP)" [RFC4145] specifies a general mechanism for
   describing media transport over TCP using SDP with [RFC4571] defining
   a method for framing RTP and RTCP packets [RFC3550] onto a
   connection-oriented transport (such as TCP).  "Connection-Oriented
   Media Transport over the Transport Layer Security (TLS) Protocol in
   the Session Description Protocol (SDP)" [RFC4572] extends [RFC4145]
   for describing TCP-based media streams that are protected using TLS
   [RFC5246].

   This specification describes additional SDP transport protocol
   identifiers for transporting RTP media over TCP as defined in
   Section 3.

2.  Terminology

   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 RFC 2119 [RFC2119].

3.  Protocol Identifiers

   The "m=" line in SDP specifies, among other items, the transport
   protocol (identified via the "proto" field) to be used for the media
   in the session.  See Section 5.14 (Media Descriptions) of SDP
   [RFC4566] for a discussion on transport protocol identifiers.

   The following is the format for an "m=" line, as specified in
   [RFC4566]:

             m=<media> <port> <proto> <fmt> ...

3.1.  TCP/RTP/AVPF Transport Realization

   The TCP/RTP/AVPF transport describes RTP media with RTCP-based
   feedback [RFC4585] over TCP.

   The RTP/AVPF stream over TCP is realized using the framing method
   defined in [RFC4571].

3.2.  TCP/RTP/SAVP Transport Realization

   The TCP/RTP/SAVP transport describes Secure RTP (SRTP) media
   [RFC3711] over TCP.

   The RTP/SAVP stream over TCP is realized using the framing method
   defined in [RFC4571].

3.3.  TCP/RTP/SAVPF Transport Realization

   The TCP/RTP/SAVPF transport describes Secure RTP media with RTCP-
   based feedback [RFC5124] over TCP.

   The RTP/SAVPF stream over TCP is realized using the framing method
   defined in [RFC4571].

3.4.  TCP/DTLS/RTP/SAVP Transport Realization

   The TCP/DTLS/RTP/SAVP transport describes Secure RTP media [RFC3711]
   using Datagram Transport Layer Security SRTP (DTLS-SRTP) [RFC5764]
   over TCP.

   RTP/SAVP using DTLS-based key establishment is realized according to
   the procedures defined in [RFC5764].  Also, the framing specified in
   [RFC4571] is used to transport DTLS-SRTP packets over TCP.

3.5.  TCP/DTLS/RTP/SAVPF Transport Realization

   The TCP/DTLS/RTP/SAVPF transport describes Secure RTP media with
   RTCP-based feedback [RFC5124] using DTLS-SRTP over TCP.

   RTP/SAVPF using DTLS-based key establishment is realized according to
   the procedures defined in [RFC5764].  Also, the framing specified in
   [RFC4571] is used to transport DTLS-SRTP packets over TCP.

3.6.  TCP/TLS/RTP/AVP Transport Realization

   The TCP/TLS/RTP/AVP transport describes RTP Media on top of TLS over
   TCP.

   RTP/AVP packets are framed using the procedures from [RFC4571] and
   are transported as application data messages over the TLS association
   setup using the procedures from [RFC4572].

3.7.  TCP/TLS/RTP/AVPF Transport Realization

   The TCP/TLS/RTP/AVPF transport describes RTP media with RTCP-based
   feedback [RFC5124] on top of TLS over TCP.

   RTP/AVPF packets are framed using the procedures from [RFC4571] and
   are transported as application data messages over the TLS association
   setup using the procedures from [RFC4572].

4.  ICE Considerations

   When procedures from [RFC6544] are used to set up Interactive
   Connectivity Establishment (ICE) [RFC5245] candidates for a TCP
   transport, the framing mechanism from [RFC4571] MUST be used for
   framing Session Traversal Utilities for NAT (STUN) packets (for
   keepalives and consent checks), as defined in Section 3 of [RFC6544].

5.  IANA Considerations

   This specification describes the following new SDP transport protocol
   identifiers: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF',
   'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and
   'TCP/TLS/RTP/AVPF', as defined in Section 3.  These values have been
   registered by the IANA under the "proto" subregistry in the "Session
   Description Protocol (SDP) Parameters" registry.

   +--------+---------------------+-----------+
   | Type   | SDP Name            | Reference |
   +--------+---------------------+-----------+
   | proto  | TCP/RTP/AVPF        | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/RTP/SAVP        | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/RTP/SAVPF       | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/DTLS/RTP/SAVP   | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/DTLS/RTP/SAVPF  | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/TLS/RTP/AVP     | RFC 7850  |
   |        |                     |           |
   | proto  | TCP/TLS/RTP/AVPF    | RFC 7850  |
   +--------+---------------------+-----------+

6.  Security Considerations

   The new "proto" identifiers registered by this document in the SDP
   parameters registry maintained by IANA are primarily for use by the
   offer/answer model of the Session Description Protocol [RFC3264] for
   the negotiation and establishment of RTP-based media over the TCP
   transport.  This specification doesn't introduce any additional
   security considerations beyond those specified by the individual
   transport protocols identified in the "proto" identifiers and those
   detailed in Section 7 of [RFC4566].

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
              and RTP Control Protocol (RTCP) Packets over Connection-
              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
              2006, <http://www.rfc-editor.org/info/rfc4571>.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572,
              DOI 10.17487/RFC4572, July 2006,
              <http://www.rfc-editor.org/info/rfc4572>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764,
              DOI 10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
              March 2012, <http://www.rfc-editor.org/info/rfc6544>.

7.2.  Informative References

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <http://www.rfc-editor.org/info/rfc5124>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

Acknowledgements

   The author would like to thank Cullen Jennings, Alissa Cooper, Justin
   Uberti, Mo Zanaty, Christer Holmberg, Jonathan Lennox, Flemming
   Andreason, Roni Even, Ben Campbell, and Bo Burman for their reviews
   and suggested improvements.

   The author would also like to thank Adam Montville for the SecDir
   review, Meral Shirazipour for the Gen-ART review, and Sarah Banks for
   the OPS-Dir review.

Author's Address

   Suhas Nandakumar
   Cisco Systems Inc
   707 Tasman Drive
   San Jose, CA  95134
   United States

   Email: snandaku@cisco.com

AI ELI5

On this page
PROBLEMSDP uses the proto field of an m= line to name the transport for a media stream, but no identifiers existed for several ways of sending RTP over TCP.
MECHANISMThe RFC defines and registers seven proto values, such as TCP/RTP/SAVPF and TCP/TLS/RTP/AVP. Each says which RTP profile and security layer is used over TCP, with RFC 4571 framing.
WHY IT MATTERSThe values are registered by IANA in the proto subregistry of the SDP Parameters registry. They add no new security considerations beyond those of the transports they name.

§1Overview

The Real-time Transport Protocol (RTP) carries real-time data such as audio or video, and the RTP Control Protocol (RTCP) monitors delivery. The Session Description Protocol (SDP, RFC 4566) describes multimedia sessions. RFC 4145 describes media over TCP in SDP, RFC 4571 defines how to frame RTP and RTCP packets on a connection-oriented transport such as TCP, and RFC 4572 adds TLS protection.

This RFC adds more SDP transport protocol identifiers for RTP media over TCP.

There are already some ways to send calls over a TCP connection. This RFC adds more names so everyone can say exactly which way they mean.

§2The SDP m= Line and the proto Field

In SDP, the m= line describes a media stream, and its proto field names the transport protocol to use. The format is m=<media> <port> <proto> <fmt> ....

The RFC does not change this line. It only defines new values for the proto field.

A call setup message has a line that says what kind of thing is sent and how. The how part is the one that gets new names.

§3The Seven New Identifiers

Each identifier combines TCP, an optional security layer and an RTP profile. All use the framing from RFC 4571.

  • TCP/RTP/AVPF: RTP media with RTCP-based feedback (RFC 4585) over TCP.
  • TCP/RTP/SAVP: Secure RTP (RFC 3711) over TCP.
  • TCP/RTP/SAVPF: Secure RTP with RTCP-based feedback (RFC 5124) over TCP.
  • TCP/DTLS/RTP/SAVP and TCP/DTLS/RTP/SAVPF: Secure RTP, without and with feedback, using DTLS-SRTP key establishment (RFC 5764) over TCP. DTLS-SRTP packets are framed as in RFC 4571.
  • TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF: RTP media, without and with feedback, on top of TLS over TCP. Framed packets travel as application data messages over the TLS association set up as in RFC 4572.

Each name is like a recipe label: the kind of box, with or without a lock, and whether the receiver can send notes back about how it is going.

THE SEVEN PROTO VALUES (RFC 7850, SECTION 3)
proto valueSecurity layerRTCP feedback
TCP/RTP/AVPFNoneYes
TCP/RTP/SAVPSRTPNo
TCP/RTP/SAVPFSRTPYes
TCP/DTLS/RTP/SAVPDTLS-SRTPNo
TCP/DTLS/RTP/SAVPFDTLS-SRTPYes
TCP/TLS/RTP/AVPTLSNo
TCP/TLS/RTP/AVPFTLSYes

§4ICE and TCP Candidates

When the procedures of RFC 6544 are used to set up Interactive Connectivity Establishment (ICE, RFC 5245) candidates for a TCP transport, the framing from RFC 4571 MUST be used for STUN packets, which carry keepalives and consent checks.

When computers test which path works, even their little check messages must be packed in the same envelope format as the call data.

§5IANA Registration

IANA registered all seven values in the proto subregistry of the Session Description Protocol (SDP) Parameters registry, each with RFC 7850 as the reference.

The Security Considerations section says the identifiers are mainly for the offer/answer model (RFC 3264) when negotiating RTP over TCP. The RFC adds no security considerations beyond those of the transports the identifiers name and those in Section 7 of RFC 4566.

The names went into the official list, and since they only name things that already exist, they bring no new dangers.

§6References