Real-Time Streaming Protocol: Difference between revisions

Revision as of 17:36, 23 September 2024

Latest revision as of 18:52, 21 August 2025

(9 intermediate revisions by 6 users not shown)

Line 3:

{{Multiple issues|

{{refimprovemore citations needed|date=September 2013}}

{{Copy edit|date=September 2024}}

}}

Line 26:

}}

The '''Real-Time Streaming Protocol''' ('''RTSP''') is an [[Application_layerApplication layer |application-level]] network [[communications protocol |protocol]] designed for [[multiplexing]] and [[Network_packetNetwork packet#MPEG_packetized_streamMPEG packetized stream |packetizing]] [[multimedia]] transport streams (such as [[interactive media]], [[video]] and [[Digital_audioDigital audio |audio]]) over a suitable [[Transport_layer|transport protocol]].
RTSP is used in entertainment and communications systems to control [[streaming media]] [[Web server |serverservers]]s.
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]]).

== History ==

RTSP was developed by [[RealNetworks]], [[Netscape]]<ref name="Inc.1998">{{cite book|author=InfoWorld Media Group, Inc.|title=InfoWorld|url=https://books.google.com/books?id=DFEEAAAAMBAJ&pg=PA18|date=2 March 1998|publisher=InfoWorld Media Group, Inc.|page=18|issn=0199-6649}}</ref> and [[Columbia University]].<ref name="Osso1999">{{cite book|author=Rafael Osso|title=Handbook of Emerging Communications Technologies: The Next Decade|url=https://books.google.com/books?id=5fms2DW7mMUC&pg=PA42|year=1999|publisher=CRC Press|isbn=978-1-4200-4962-6|page=42}}</ref> 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.<ref>{{Cite news|last1=Rao|first1=Anup|last2=Lanphier|first2=Rob|title=Real Time Streaming Protocol (RTSP)|url=https://tools.ietf.org/html/draft-rao-rtsp-00.html|access-date=2021-02-23|newspaper=Ietf Datatracker|language=en}}</ref><ref>"RTSP prime" [[Henning Schulzrinne]], [[Columbia University]](http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) December 1996</ref> 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.<ref>{{Cite news|last1=Schulzrinne|first1=Henning|author-link=Henning Schulzrinne|last2=Rao|first2=Anup|last3=Lanphier|first3=Rob|date=1997-02-24|title=Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)|url=https://tools.ietf.org/html/draft-ietf-mmusic-rtsp-01.html|access-date=2021-02-23|newspaper=Ietf Datatracker|language=en}}</ref><ref>{{Cite news|last1=Schulzrinne|first1=Henning|author-link=Henning Schulzrinne|last2=Rao|first2=Anup|last3=Lanphier|first3=Rob|date=1998-01-15|title=Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)|url=https://tools.ietf.org/html/draft-ietf-mmusic-rtsp-08.html|access-date=2021-02-23|newspaper=Ietf Datatracker|language=en}}</ref> The [[Proposed Standard]] for RTSP was published as RFC 2326 in 1998.<ref name=":0">RFC 2326, ''Real Time Streaming Protocol (RTSP)'', IETF, 1998</ref><br>

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.<ref>{{Cite journal|last1=Schulzrinne|first1=Henning|last2=Rao|first2=Anup|last3=Lanphier|first3=Rob|last4=Westerlund|first4=Magnus|last5=Stiemerling|first5=Martin|editor-first1=M |editor-last1=Stiemerling |date=December 2016|title=Real-Time Streaming Protocol Version 2.0|url=https://tools.ietf.org/html/rfc7826.html|access-date=2021-02-23|website=tools.ietf.org|doi=10.17487/RFC7826 |language=en|doi-access=free}}</ref><br>

RTSP was developed by [[RealNetworks]], [[Netscape]] and [[Columbia University]].<ref name="Inc.1998">{{Cite book

{{IPstack}}

| author = InfoWorld Media Group, Inc.

| date = 2 March 1998

| issn = 0199-6649

| page = 18

| publisher = InfoWorld Media Group, Inc.

| title = InfoWorld

| url = https://books.google.com/books?id=DFEEAAAAMBAJ&pg=PA18

}}

</ref><ref name="Osso1999">

{{Cite book

| author = Rafael Osso

| isbn = 978-1-4200-4962-6

| page = 42

| publisher = CRC Press

| title = Handbook of Emerging Communications Technologies: The Next Decade

| url = https://books.google.com/books?id=5fms2DW7mMUC&pg=PA42

| year = 1999

}}

</ref>

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.<ref>

{{Cite news

| first1 = Anup

| first2 = Rob

| language = en

| last1 = Rao

| last2 = Lanphier

| newspaper = Ietf Datatracker

| title = Real Time Streaming Protocol (RTSP)

| url = https://tools.ietf.org/html/draft-rao-rtsp-00.html|access-date=2021-02-23

}}

</ref><ref>

{{Cite web

| author = [[Henning Schulzrinne]]

| date = December 1996

| publisher = [[Columbia University]]

| title = RTSP prime

| url = http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps

}}

</ref>

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.<ref>

{{Cite news

| access-date = 2021-02-23

| author-link = Henning Schulzrinne

| date = 1997-02-24

| first1 = Henning

| first2 = Anup

| first3 = Rob

| language = en

| last1 = Schulzrinne

| last2 = Rao

| last3 = Lanphier

| newspaper = Ietf Datatracker

| title = Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)

| url = https://tools.ietf.org/html/draft-ietf-mmusic-rtsp-01.html

}}

</ref><ref>

{{Cite news

| access-date = 2021-02-23

| author-link = Henning Schulzrinne

| date = 1998-01-15

| first1 = Henning

| first2 = Anup

| first3 = Rob

| language = en

| last1 = Schulzrinne

| last2 = Rao

| last3 = Lanphier

| newspaper = Ietf Datatracker

| title = Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)

| url = https://tools.ietf.org/html/draft-ietf-mmusic-rtsp-08.html

}}</ref>

The [[Proposed Standard]] for RTSP was published as RFC 2326 in 1998.{{Ref RFC|2326}}

RTSP 2.0 was published as RFC 7826 in 2016 as a replacement of RTSP 1.0.

Version 2.0 is based on version 1.0 but is not backwards compatible other than in the basic version negotiation mechanism, and remains a Proposed Standard.{{Ref RFC|7826}}

{{Internet protocol suite}}

== RTP ==

{{main|Real-time Transport Protocol}}

{{Main

|Real-time Transport Protocol

}}

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 [[RTCP|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 server|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).

While similar in some ways to [[HTTP]], RTSP defines control sequences useful in controlling multimedia playback. While HTTP is [[stateless server|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 request]]s, like the OPTIONS request, are also available. The default transport layer [[port number]] is 554<ref name=":0" /> for both [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]], the latter being rarely used for the control requests.

Presented here are the basic RTSP requests. Some typical [[HTTP request]]s, like the OPTIONS request, are also available. The default transport layer [[port number]] is 554{{Ref RFC|2326}} for both [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]], the latter being rarely used for the control requests.

=== OPTIONS ===

: An OPTIONS request returns the request types the server will accept.

<pre>

Line 57 ⟶ 141:

=== DESCRIBE ===

: A DESCRIBE request includes an RTSP [[Uniform Resource Locator|URL]] <nowiki>(rtsp://...)</nowiki>, 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.

: A DESCRIBE request includes an RTSP [[URL]] <nowiki>(rtsp://...)</nowiki>, 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.

<pre>

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0

Line 87 ⟶ 172:

=== 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 [[Real-time Transport Protocol|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.

: 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 [[Real-time Transport Protocol|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.

<pre>

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0

Line 97 ⟶ 183:

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

Line 110 ⟶ 194:

Session: 12345678

</pre>

=== 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.

<pre>

Line 125 ⟶ 211:

=== 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.

<pre>

Line 137 ⟶ 224:

=== 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.

: 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 that describes the states of the request and refers to the new resource, and a Location header.

<pre>

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0

Line 149 ⟶ 237:

=== 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.

Line 176 ⟶ 265:

=== TEARDOWN ===

: A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session-related data on the server.

<pre>

Line 187 ⟶ 277:

=== 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").

<pre>

Line 208 ⟶ 299:

=== SET_PARAMETER ===

: This method requests to set the value of a parameter for a presentation or stream specified by the URI.

<pre>

Line 226 ⟶ 318:

=== 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.

<pre>

Line 235 ⟶ 328:

=== 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.

: 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.

<pre>

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0

Line 263 ⟶ 357:

== RTSP over HTTP ==

RTSP over HTTP was defined by Apple in 1999<ref>{{Cite web |date=2013-05-01 |title=Developer - QuickTime - Letters from the Ice Floe |url=https://developer.apple.com/quicktime/icefloe/dispatch028.html |access-date=2024-09-22 |archive-url=https://web.archive.org/web/20130501053040/https://developer.apple.com/quicktime/icefloe/dispatch028.html |archive-date=2013-05-01 }}</ref> and [https://web.archive.org/web/20240215060448/https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf]. 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.

Line 268 ⟶ 363:

== 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.

* '''RTSPS URL (using the rtsps:// URL)''' - This method uses a [[Transport_Layer_SecurityTransport Layer Security|TLS]] Socket (default of Port 322) to establish an encrypted connection between the RTSP client and the RTSP Server.<br>Video and Audio can then sent in one of two ways

** '''TCP Video/Audio''' - The RTP Video and Audio is sent interleaved with the RTSP Commands over the already encrypted [[Transport_Layer_SecurityTransport Layer Security|TLS]] Connection

** '''UDP and Multicast-UDP Video/Audio''' - the RTP Video and Audio is encrypted using the [[Secure_RealSecure Real-time_Transport_Protocoltime Transport Protocol|Secure RTP (SRTP)]] protocol and sent in parallel to the RTSPS [[Transport_Layer_SecurityTransport Layer Security|TLS]] connection

* '''RTSP over HTTPS''' - this method 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 encrypted HTTPS connections. It uses Port 443 by default.

IANA have reserved the rtsps:// URL prefix and Port 322 for RTSPS.<ref>{{cite web | url=https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=rtsp | title=Service Name and Transport Protocol Port Number Registry }}</ref> 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,<ref>{{cite web | url=https://www.ipcamlive.com/secure-rtsp-streaming | title=Secure RTSP streaming - SRTP/RTSPS }}</ref> [[FFmpeg]], [[GStreamer]], MediaMTX,<ref>[https://github.com/bluenviron/mediamtx MediaMTX]</ref> Ant Media Server<ref>[https://github.com/ant-media/Ant-Media-Server Ant Media Server Community]</ref> and SharpRTSP.<ref>{{cite web | url=https://github.com/ngraziano/SharpRTSP | title=Ngraziano/SharpRTSP | website=[[GitHub]] }}</ref>

==Rate adaptation==

RTSP using RTP and RTCP allows for the implementation of rate adaptation.<ref>{{citation |volume=40 |pages=161–168 |doi=10.1007/978-3-642-12630-7_19 |chapter = Rate Adaptation Techniques for WebTV|series = Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering|year = 2010|last1 = Santos|first1 = Hugo|last2=Cruz |first2=Rui Santos |last3=Nunes |first3=Mário Serafim |title=User Centric Media |isbn=978-3-642-12629-1 }}</ref>

Line 286 ⟶ 382:

===Server===

* [[Ant Media Server]]: The Community version<ref>{{Citation |title=ant-media/Ant-Media-Server |date=2024-12-12 |url=https://github.com/ant-media/Ant-Media-Server |access-date=2024-12-13 |publisher=Ant Media}}</ref> version supports pulling from RTSP/S sources and can live stream using HLS or record in MP4. [https://antmedia.io/docs/get-started/enterprise-and-community-edition/#community-edition--enterprise-edition The Enterprise version] can convert RTSP to WebRTC with approximately 200-500ms end-to-end latency.

* [[Darwin Streaming Server]]: Open-sourced version of QuickTime Streaming Server maintained by Apple.

* [[GStreamer]] based RTSP Server and client.

Line 298 ⟶ 396:

* [[VideoLAN]]: Open source media player and streaming server.

* [[Windows Media Services]]: Microsoft streaming server previously included with [[Windows Server]] that uses RTSP modified with [http://msdn.microsoft.com/en-us/library/cc245238.aspx Windows Media extensions]

* [[Wowza Media Server|Wowza Streaming Engine]]: Multi-format streaming server for RTSP/RTP, [[Real-Time Messaging Protocol|RTMP]], [[MPEG TS|MPEG-TS]], ICY, HTTP ([[HTTP Live Streaming]], [[Adaptive_bitrate_streamingAdaptive bitrate streaming#Adobe_Dynamic_Streaming_for_FlashAdobe Dynamic Streaming for Flash|HTTP Dynamic Streaming]], [[Microsoft Smooth Streaming|Smooth Streaming]], [[Adaptive bitrate streaming#MPEG-DASH|MPEG-DASH]]), [[WebRTC]]

* [[YouTube]] implemented a [[mobile web]] front end in June 2007 which serves video through this protocol.<ref>{{cite web |title=YouTube Mobile A Bust! (Getting 3GP/RTSP to work on WM5) |url=https://chrisduke.tv/youtube-mobile-a-bust |website=Chris Duke |access-date=29 May 2021 |date=2007-06-23}}</ref>

Many [[Closed-circuit television|CCTV]] / Security cameras, often called [[IP camera]]s, support RTSP streaming too, especially those with [[ONVIF]] profiles G, S, T.

===Client===

* [[Astra_(software)|Astra]]

* [[Astra (software)|Astra]]

* [[cURL]] (beginning with version 7.20.0—9 February 2010<ref>[http://curl.haxx.se/changes.html cURL — Changes<!-- Bot generated title -->]</ref>)

* [[FFmpeg]]<ref>{{cite web|url=http://ffmpeg.org/ffmpeg.html#rtsp|title=FFmpeg Documentation|at=Section 20.19|date=September 11, 2012|publisher=The FFmpeg project|access-date=2012-09-11}}</ref>

Line 325 ⟶ 424:

==References==

{{Reflist|30em}}

==External links==

* {{cite web |url=http://www.rtsp.org |archive-url=https://web.archive.org/web/20070306002838/http://www.rtsp.org/ |archive-date=2007-03-06 |title=Real Time Streaming Protocol Information and Updates}}, a central information repository about RTSP.

* {{cite web |url=https://developer.apple.com/quicktime/icefloe/dispatch028.html |archive-url=https://web.archive.org/web/20130501053040/https://developer.apple.com/quicktime/icefloe/dispatch028.html |archive-date=2013-05-01 |title=Tunnelling RTSP and RTP through HTTP}}, A standard solution to help RTSP work through firewalls and web proxies