RFC 7850

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

πŸ“… published April 2016, from ietf

RFC 7850 πŸ’– Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles

okay bestie, here's the title block so you know what you're looking at πŸŽ€

  • Series: Internet Engineering Task Force (IETF) 🌸
  • Number and title: RFC 7850, Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles ✨
  • Author: S. Nandakumar, Cisco Systems Inc πŸ’…
  • Category: Standards Track πŸ”₯
  • Date: April 2016 πŸ¦‹
  • ISSN: 2070-1721 🧚
  • Obsoletes or updates: the title block doesn't list anything it obsoletes or updates πŸ™ˆ

Abstract

okay so the Real-time Transport Protocol (RTP) has a registry of profile names that higher-level control protocols, like the Session Description Protocol (SDP), use to refer to transport methods πŸ“‹. This spec adds seven brand new SDP transport protocol identifiers for sending 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 πŸ’œ main character energy!!

Status of This Memo

this is an Internet Standards Track document πŸ”₯

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫢. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) βœ…. If you want more deets on Internet Standards, check Section 2 of RFC 5741 πŸ“š.

for the current status of this doc, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7850 🌈

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Β©οΈπŸŽ€

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication πŸ“œ. Please actually read these, bestie, because they explain your rights and restrictions for this document πŸ™. Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 ✨

okay so RTP gives you end-to-end transport for real-time stuff like audio or video, whether you're multicasting or unicasting πŸŽ§πŸ“Ή. RTP Control Protocol (RTCP) sits alongside it so you can keep an eye on delivery in a way that still scales to huge multicast networks, plus it does minimal control and identification πŸ‘€.

"SDP: Session Description Protocol" [RFC4566] is the general-purpose format for describing multimedia sessions in announcements or invitations πŸ“¨. "TCP-Based Media Transport in the Session Description Protocol (SDP)" [RFC4145] is the generic way to describe media transport over TCP using SDP, and [RFC4571] defines how to frame RTP and RTCP packets [RFC3550] onto a connection-oriented transport like TCP 🧡. "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572] extends [RFC4145] to describe TCP-based media streams that are protected with TLS [RFC5246] πŸ”.

this spec adds more SDP transport protocol identifiers for sending RTP media over TCP, as defined in Section 3 πŸ¦‹.

2. Terminology πŸ“–

so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] πŸ€“. These are the words that do the heavy lifting, so don't skip them πŸ’….

3. Protocol Identifiers πŸŽ€

the "m=" line in SDP tells you, among other things, which transport protocol (the one in the "proto" field) gets used for the media in the session 🎬. For a deep dive on transport protocol identifiers, see Section 5.14 (Media Descriptions) of SDP [RFC4566] πŸ“š.

this is the format of 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 gets 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 gets 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 gets 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 with DTLS-based key establishment gets 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 with DTLS-based key establishment gets 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 get framed using the procedures from [RFC4571], and they're carried as application data messages over the TLS association set up with 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 get framed using the procedures from [RFC4571], and they're carried as application data messages over the TLS association set up with the procedures from [RFC4572] πŸ’«.

4. ICE Considerations 🧊

when the 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] 🚨. this part is not optional, periodt πŸ’….

7.2. Informative References ✨

Okay bestie, these are the background reads the spec points to for extra context πŸ“šπŸ€“. Each entry keeps its tag, authors, title, series, number, DOI, date, and link.


Acknowledgements ✨

The author wants to thank the whole squad for their reviews and suggested improvements πŸŒˆπŸ’–: Cullen Jennings, Alissa Cooper, Justin Uberti, Mo Zanaty, Christer Holmberg, Jonathan Lennox, Flemming Andreason, Roni Even, Ben Campbell, and Bo Burman. 🫢

The author also gives a big shoutout to Adam Montville for the SecDir review, Meral Shirazipour for the Gen-ART review, and Sarah Banks for the OPS-Dir review. πŸ‘‘πŸ˜­


Author's Address πŸŽ€

Here's where to find the author πŸ’…

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

Email: snandaku@cisco.com
πŸ“¦ where this page comes from