Real-Time Streaming Protocol

Last updated
Real Time Streaming Protocol
Communication protocol
AbbreviationRTSP
Purpose Internet streaming
Developer(s) RealNetworks, Netscape, Columbia University
IntroductionApril 1998;26 years ago (1998-04)
OSI layer Application layer (7)
Port(s)
  • 554/TCP
  • 554/UDP
RFC(s) RFC   2326, 7826

The Real-Time Streaming Protocol (RTSP) is an application-level network protocol designed for multiplexing and packetizing multimedia transport streams (such as interactive media, video and audio) over a suitable transport protocol. RTSP is used in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between endpoints. Clients of media servers issue commands such as play, record and pause, to facilitate real-time control of the media streaming from the server to a client (video on demand) or from a client to the server (voice recording).

Contents

History

RTSP was developed by RealNetworks, Netscape [1] and Columbia University. [2] The first draft was submitted to IETF in October 1996 by Netscape and Progressive Networks, after which Henning Schulzrinne from Columbia University submitted "RTSP՚" ("RTSP prime") in December 1996. [3] [4] The two drafts were merged for standardization by the Multiparty Multimedia Session Control Working Group (MMUSIC WG) of the Internet Engineering Task Force (IETF) and further drafts were published by the working group. [5] [6] The Proposed Standard for RTSP was published as RFC 2326 in 1998. [7]
RTSP 2.0 published as RFC 7826 in 2016 as a replacement of RTSP 1.0. RTSP 2.0 is based on RTSP 1.0 but is not backwards compatible other than in the basic version negotiation mechanism, and remains a Proposed Standard. [8]

RTP

The transmission of streaming data itself is not a task of RTSP. Most RTSP servers use the Real-time Transport Protocol (RTP) in conjunction with Real-time Control Protocol (RTCP) for media stream delivery. However, some vendors implement proprietary transport protocols. The RTSP server software from RealNetworks, for example, also used RealNetworks' proprietary Real Data Transport (RDT).

Protocol directives

While similar in some ways to HTTP, RTSP defines control sequences useful in controlling multimedia playback. While HTTP is stateless, RTSP has a state; an identifier is used when needed to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection and, while most RTSP control messages are sent by the client to the server, some commands travel in the other direction (i.e. from server to client).

Presented here are the basic RTSP requests. Some typical HTTP requests, like the OPTIONS request, are also available. The default transport layer port number is 554 [7] for both TCP and UDP, the latter being rarely used for the control requests.

OPTIONS

An OPTIONS request returns the request types the server will accept.
C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 1        Require: implicit-play        Proxy-Require: gzipped-messages  S->C:  RTSP/1.0 200 OK        CSeq: 1        Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

DESCRIBE

A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can be handled. This reply includes the presentation description, typically in Session Description Protocol (SDP) format. Among other things, the presentation description lists the media streams controlled with the aggregate URL. In the typical case, there is one media stream each for audio and video streams. The media stream URLs are either obtained directly from the SDP control fields or they are obtained by appending the SDP control field to the aggregate URL.
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 2  S->C: RTSP/1.0 200 OK       CSeq: 2       Content-Base: rtsp://example.com/media.mp4       Content-Type: application/sdp       Content-Length: 460        m=video 0 RTP/AVP 96       a=control:streamid=0       a=range:npt=0-7.741000       a=length:npt=7.741000       a=rtpmap:96 MP4V-ES/5544       a=mimetype:string;"video/MP4V-ES"       a=AvgBitRate:integer;304018       a=StreamName:string;"hinted video track"       m=audio 0 RTP/AVP 97       a=control:streamid=1       a=range:npt=0-7.712000       a=length:npt=7.712000       a=rtpmap:97 mpeg4-generic/32000/2       a=mimetype:string;"audio/mpeg4-generic"       a=AvgBitRate:integer;65790       a=StreamName:string;"hinted audio track"

SETUP

A SETUP request specifies how a single media stream must be transported. This must be done before a PLAY request is sent. The request contains the media stream URL and a transport specifier. This specifier typically includes a local port for receiving RTP data (audio or video), and another for RTCP data (meta information). The server reply usually confirms the chosen parameters, and fills in the missing parts, such as the server's chosen ports. Each media stream must be configured using SETUP before an aggregate play request may be sent.
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0       CSeq: 3       Transport: RTP/AVP;unicast;client_port=8000-8001  S->C: RTSP/1.0 200 OK       CSeq: 3       Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD       Session: 12345678  C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0       CSeq: 3       Transport: RTP/AVP;unicast;client_port=8002-8003       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 3       Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD       Session: 12345678

PLAY

A PLAY request will cause one or all media streams to be played. Play requests can be stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all media streams), or a single media stream URL (to play only that stream). A range can be specified. If no range is specified, the stream is played from the beginning and plays to the end, or, if the stream is paused, it is resumed at the point it was paused.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 4       Range: npt=5-20       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 4       Session: 12345678       RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE

A PAUSE request temporarily halts one or all media streams, so it can later be resumed with a PLAY request. The request contains an aggregate or media stream URL. A range parameter on a PAUSE request specifies when to pause. When the range parameter is omitted, the pause occurs immediately and indefinitely.
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 5       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 5       Session: 12345678

RECORD

This method initiates recording a range of media data according to the presentation description. The timestamp reflects the start and end time(UTC). If no time range is given, use the start or end time provided in the presentation description. If the session has already started, commence recording immediately. The server decides whether to store the recorded data under the request URI or another URI. If the server does not use the request URI, the response should be 201 and contain an entity which describes the states of the request and refers to the new resource, and a Location header.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 6       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 6       Session: 12345678

ANNOUNCE

The ANNOUNCE method serves two purposes:

When sent from client to server, ANNOUNCE posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, ANNOUNCE updates the session description in real time. If a new media stream is added to a presentation (e.g., during a live presentation), the whole presentation description should be sent again, rather than just the additional components, so that components can be deleted.
<span class="plainlinks"> C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 7       Date: 23 Jan 1997 15:35:06 GMT       Session: 12345678       Content-Type: application/sdp       Content-Length: 332        v=0       o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4       s=SDP Seminar       i=A Seminar on the session description protocol       u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps       e=mjh@isi.edu (Mark Handley)       c=IN IP4 224.2.17.12/127       t=2873397496 2873404696       a=recvonly       m=audio 3456 RTP/AVP 0       m=video 2232 RTP/AVP 31  S->C: RTSP/1.0 200 OK       CSeq: 7 </span>

TEARDOWN

A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session-related data on the server.
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 8       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 8

GET_PARAMETER

The GET_PARAMETER request retrieves the value of a parameter of a presentation or stream specified in the URI. The content of the reply and response is left to the implementation. GET_PARAMETER with no entity body may be used to test client or server liveness ("ping").
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 9       Content-Type: text/parameters       Session: 12345678       Content-Length: 15        packets_received       jitter  C->S: RTSP/1.0 200 OK       CSeq: 9       Content-Length: 46       Content-Type: text/parameters        packets_received: 10       jitter: 0.3838

SET_PARAMETER

This method requests to set the value of a parameter for a presentation or stream specified by the URI.
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 10       Content-length: 20       Content-type: text/parameters        barparam: barstuff  S->C: RTSP/1.0 451 Invalid Parameter       CSeq: 10       Content-length: 10       Content-type: text/parameters        barparam

REDIRECT

A REDIRECT request informs the client that it must connect to another server location. It contains the mandatory header Location, which indicates that the client should issue requests for that URL. It may contain the parameter Range, which indicates when the redirection takes effect. If the client wants to continue to send or receive media for this URI, the client MUST issue a TEARDOWN request for the current session and a SETUP for the new session at the designated host.
S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 11       Location: rtsp://bigserver.com:8001       Range: clock=19960213T143205Z-

Embedded (Interleaved) Binary Data

Certain firewall designs and other circumstances may force a server to interleave RTSP methods and stream data. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead. Interleaved binary data SHOULD only be used if RTSP is carried over TCP. Stream data such as RTP packets is encapsulated by an ASCII dollar sign (24 hexadecimal), followed by a one-byte channel identifier, followed by the length of the encapsulated binary data as a binary, two-byte integer in network byte order. The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers. Each $ block contains exactly one upper-layer protocol data unit, e.g., one RTP packet.
C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 3       Transport: RTP/AVP/TCP;interleaved=0-1  S->C: RTSP/1.0 200 OK       CSeq: 3       Date: 05 Jun 1997 18:57:18 GMT       Transport: RTP/AVP/TCP;interleaved=0-1       Session: 12345678  C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 4       Session: 12345678  S->C: RTSP/1.0 200 OK       CSeq: 4       Session: 12345678       Date: 05 Jun 1997 18:59:15 GMT       RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234  S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

RTSP over HTTP

RTSP over HTTP was defined by Apple in 1999 [9] and . It interleaves the RTP Video and Audio data into the RTSP Command Connection (as defined in RFC2326), and then sends the RTSP Command Connection via a pair of HTTP connections, one is a long running GET connection and the other is a long running POST connection.

This method is also used in the ONVIF IP Camera standard and can be combined with HTTPS for secure and encrypted video and audio.

RTSP Encryption and RTSPS

There are several different methods for encrypting RTSP command messages and the RTP Video and Audio data.

RTSP 2.0 (RFC7826) defines several methods for encryption and introduces a new rtsps:// URL and many of these have been incorporated into RFC2326 RTSP 1.0 Clients and Servers.

IANA have reserved the rtsps:// URL prefix and Port 322 for RTSPS. [10] As of September 2024, RTSP over HTTPS has been implemented in several ONVIF IP Cameras and RTSPS (using the rtsps:// URL) has been implemented by Axis and Bosch CCTV Cameras, [11] FFmpeg, GStreamer, MediaMTX, [12] Ant Media Server [13] and SharpRTSP. [14]

Rate adaptation

RTSP using RTP and RTCP allows for the implementation of rate adaptation. [15]

Implementations

Server

Many CCTV / Security cameras, often called IP cameras, support RTSP streaming too, especially those with ONVIF profiles G, S, T.

Client

Related Research Articles

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

The Session Description Protocol (SDP) is a format for describing multimedia communication sessions for the purposes of announcement and invitation. Its predominant use is in support of streaming media applications, such as voice over IP (VoIP) and video conferencing. SDP does not deliver any media streams itself but is used between endpoints for negotiation of network metrics, media types, and other associated properties. The set of properties and parameters is called a session profile.

Helix DNA was a project to produce computer software that can play audio and video media in various formats and aid in creating such media. It was intended as a largely free and open-source digital media framework compatible with numerous operating systems and processors and it was started by RealNetworks, which contributed much of the code. The Helix Community was an open collaborative effort to develop and extend the Helix DNA platform. The Helix Project has been discontinued.

<span class="mw-page-title-main">Universal Plug and Play</span> Set of networking protocols

Universal Plug and Play (UPnP) is a set of networking protocols on the Internet Protocol (IP) that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices.

Digital storage media command and control (DSM-CC) is a toolkit for developing control channels associated with MPEG-1 and MPEG-2 streams. It is defined in part 6 of the MPEG-2 standard and uses a client/server model connected via an underlying network.

The RTP Control Protocol (RTCP) is a binary-encoded out-of-band signaling protocol that functions alongside the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.

Media Resource Control Protocol (MRCP) is a communication protocol used by speech servers to provide various services to their clients. MRCP relies on another protocol, such as Real Time Streaming Protocol (RTSP) or Session Initiation Protocol (SIP) for establishing a control session and audio streams between the client and the server.

Real Data Transport (RDT) is a proprietary transport protocol for the actual audio-video data, developed by RealNetworks in the 1990s. It is commonly used in companion with a control protocol for streaming media like the IETF's Real Time Streaming Protocol (RTSP).

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

A back-to-back user agent (B2BUA) is a logical network element in Session Initiation Protocol (SIP) applications. SIP is a signaling protocol for managing multimedia Voice over Internet Protocol (VoIP) telephone calls. A back-to-back user agent operates between both end points of a communications session and divides the communication channel into two call legs, and mediates all SIP signaling between the endpoints of the session, from establishment to termination. As all control messages for each call flow through the B2BUA, a service provider may implement value-added features available during the call.

SDES for Media Streams is a way to negotiate the key for Secure Real-time Transport Protocol. It has been proposed for standardization to the IETF in July 2006

The Real-time Transport Protocol (RTP) specifies a general-purpose data format and network protocol for transmitting digital media streams on Internet Protocol (IP) networks. The details of media encoding, such as signal sampling rate, frame size and timing, are specified in an RTP payload format. The format parameters of the RTP payload are typically communicated between transmission endpoints with the Session Description Protocol (SDP), but other protocols, such as the Extensible Messaging and Presence Protocol (XMPP) may be used.

<span class="mw-page-title-main">GPAC Project on Advanced Content</span>

GPAC Project on Advanced Content is an open-source multimedia framework focused on modularity and standards compliance. GPAC was created as an implementation of the MPEG-4 Systems standard written in ANSI C and later extended in Streaming Media. GPAC provides tools to process, inspect, package, stream, media playback and interact with media content. Such content can be any combination of audio, video, subtitles, metadata, encrypted media, rendering and ECMAScript.

HTTP Live Streaming is an HTTP-based adaptive bitrate streaming communications protocol developed by Apple Inc. and released in 2009. Support for the protocol is widespread in media players, web browsers, mobile devices, and streaming media servers. As of 2022, an annual video industry survey has consistently found it to be the most popular streaming format.

The Helix Universal Media Server was a product developed by RealNetworks and originates from the first streaming media server originally developed by Progressive Networks in 1994. It supported a variety of streaming media delivery transports including MPEG-DASH RTMP (flash), RTSP (standard), HTTP Live Streaming (HLS), Microsoft Silverlight and HTTP Progressive Download enabling mobile phone OS and PC OS media client delivery.

Adaptive bitrate streaming is a technique used in streaming multimedia over computer networks.

Sirannon is a free, open-source, media server and client. The goal is to aid in video research and experimental streaming. Sirannon allows the programmer to create a wide variety of media-handling components such as streaming, reading, writing, packetizing. By organizing these components in a workflow the programmer can create many applications such as a media server, media proxy or video tool. Sirannon was introduced at the ACM multimedia conference in October 2009 under its former name xStreamer.

Wowza Streaming Engine is a unified streaming media server software developed by Wowza. The server is used for streaming of live and on-demand video, audio, and rich Internet applications over IP networks to desktop, laptop, and tablet computers, mobile devices, IPTV set-top boxes, internet-connected TV sets, game consoles, and other network-connected devices. The server is a Java application deployable on most operating systems.

Unreal Media Server is a streaming server software created by Unreal Streaming Technologies.

References

  1. ↑ InfoWorld Media Group, Inc. (2 March 1998). InfoWorld. InfoWorld Media Group, Inc. p. 18. ISSN   0199-6649.
  2. ↑ Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. p. 42. ISBN   978-1-4200-4962-6.
  3. ↑ Rao, Anup; Lanphier, Rob. "Real Time Streaming Protocol (RTSP)". Ietf Datatracker. Retrieved 2021-02-23.
  4. ↑ "RTSP prime" Henning Schulzrinne, Columbia University(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) December 1996
  5. ↑ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1997-02-24). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)". Ietf Datatracker. Retrieved 2021-02-23.
  6. ↑ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1998-01-15). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)". Ietf Datatracker. Retrieved 2021-02-23.
  7. 1 2 RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998
  8. ↑ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob; Westerlund, Magnus; Stiemerling, Martin (December 2016). Stiemerling, M (ed.). "Real-Time Streaming Protocol Version 2.0". tools.ietf.org. doi: 10.17487/RFC7826 . Retrieved 2021-02-23.
  9. ↑ "Developer - QuickTime - Letters from the Ice Floe". 2013-05-01. Archived from the original on 2013-05-01. Retrieved 2024-09-22.
  10. ↑ "Service Name and Transport Protocol Port Number Registry".
  11. ↑ "Secure RTSP streaming - SRTP/RTSPS".
  12. ↑ MediaMTX
  13. ↑ Ant Media Server Community
  14. ↑ "Ngraziano/SharpRTSP". GitHub .
  15. ↑ Santos, Hugo; Cruz, Rui Santos; Nunes, Mário Serafim (2010), "Rate Adaptation Techniques for WebTV", User Centric Media, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 40, pp. 161–168, doi:10.1007/978-3-642-12630-7_19, ISBN   978-3-642-12629-1
  16. ↑ ant-media/Ant-Media-Server, Ant Media, 2024-12-12, retrieved 2024-12-13
  17. ↑ "YouTube Mobile A Bust! (Getting 3GP/RTSP to work on WM5)". Chris Duke. 2007-06-23. Retrieved 29 May 2021.
  18. ↑ cURL — Changes
  19. ↑ "FFmpeg Documentation". The FFmpeg project. September 11, 2012. Section 20.19. Retrieved 2012-09-11.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.