Network streaming media protocol - RTSP protocol

Network streaming media protocol - RTSP protocol

RTSP (Real-Time Stream Protocol) is a text-based multimedia playback control protocol, belonging to the application layer. RTSP works in client mode and provides operations such as play, pause, rewind, and forward for streaming media. The standard is specified by IETF, and the corresponding protocol is RFC2326.

As an application layer protocol, RTSP provides an extensible framework that makes it possible to control and broadcast streaming media on demand. It is mainly used to control the transmission of data with real-time characteristics, but it is not used to transmit streaming media data. Instead, it must rely on the services provided by the lower layer transmission protocol (such as RTP/RTCP) to complete the transmission of streaming media data. RTSP is responsible for defining specific control information, operation methods, status codes, and describing the interactive operations with RTP. The RTSP media service protocol framework is as follows:

To play RTSP media streams, the client needs to know the URL of the media source. The RTSP URL format is generally as follows:

  1.  rtsp://host[:port]/[abs_path]/content_name
  • host: a valid domain name or IP address;
  • port: port number, the default is 554. If it is the default, you can leave it blank, otherwise it must be specified.

For example, a complete RTSP URL can be written as:

  1.  rtsp://192.168.1.67:554/test

For example, the RTSP address format of the commonly used Hikvision network cameras on the market is:

  1.  rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream

Example:

  1.  rtsp://admin:[email protected]:554/h264/ch1/main/av_stream
  2.  rtsp://admin:[email protected]/mpeg4/ch1/sub/av_stream

RTSP message

After having a general understanding of the use of the RTSP protocol, let's take a look at the RTSP message structure.

RTSP is a text-based protocol that uses CRLF (Carriage Return Line Feed) as the end of each line. Its advantage is that it is easy to add custom parameters during use and also convenient for packet capture analysis. From the perspective of message transmission direction, RTSP messages are divided into two categories: request messages and response messages. Request messages refer to requests sent from the client to the server (there are also a small number of requests sent from the server to the client), and response messages refer to responses from the server to the client.

Common methods and functions of RTSP request messages:

A basic RTSP interaction process is as follows, C represents the client and S represents the server.

First, the client connects to the streaming server and sends an RTSP description request (DESCRIBE request). The server responds (DESCRIBE response) through an SDP (Session Description Protocol) description. The feedback information includes the number of streams, media type, and other information. The client analyzes the SDP description and sends an RTSP connection establishment request (SETUP request) for each stream in the session. This command tells the server the port used to receive media data. After the server responds to the request (SETUP response) and establishes a connection, it starts to transmit the media stream (RTP packet) to the client. During the playback process, the client can also send requests to the server to control fast forward, fast rewind, and pause, etc. Finally, the client can send a termination request (TEARDOWN request) to end the streaming session.

Let's take a closer look at the working process of RTSP through a specific message example:

(1) OPTIONS

The OPTIONS request is a request from the client to the server to ask for available methods. The request and response examples are as follows:

  1.  C- > S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 1
  3.  Require: implicit-play
  4.  Proxy-Require: gzipped-messages 
  5.   
  6.  S- > C: RTSP/1.0 200 OK
  7.  CSeq: 1
  8.  Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

(2) DESCRIBE

The client requests a media resource description from the server, and the server responds to the client's request in the SDP (Session Description Protocol) format. The resource description lists the media streams of the requested media and their related information. Typically, audio and video are transmitted as one media stream each. The following is an example:

  1.  C- > S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 2 
  3.   
  4.  S- > C: RTSP/1.0 200 OK
  5.  CSeq: 2
  6.  Content-Base: rtsp://example.com/media.mp4
  7.  Content-Type: application/sdp
  8.  Content-Length: 460 
  9.   
  10.  m = video 0 RTP/AVP 96
  11.  a = control :streamid = 0  
  12.  a = range :npt = 0 -7.741000
  13.  a = length :npt = 7 .741000
  14.  a = rtpmap :96 MP4V-ES/5544
  15.  a = mimetype :string;"video/MP4V-ES"
  16.  a = AvgBitRate :integer;304018
  17.  a = StreamName :string;"hinted video track"
  18.  m = audio 0 RTP/AVP 97
  19.  a = control :streamid = 1  
  20.  a = range :npt = 0 -7.712000
  21.  a = length :npt = 7 .712000
  22.  a = rtpmap :97 mpeg4-generic/32000/2
  23.  a = mimetype :string;"audio/mpeg4-generic"
  24.  a = AvgBitRate : integer; 65790
  25.  a = StreamName :string;"hinted audio track"

(3) SETUP

The SETUP request determines how the specific media stream is transmitted and must be sent before the PLAY request. The SETUP request contains the URL of the media stream and the port used by the client to receive RTP data (audio or video) and the port used to receive RTCP data (meta information). The server's reply usually contains a confirmation of the client's request parameters and will supplement the missing parts, such as the sending port selected by the server. Each media stream must first be configured through a SETUP request before sending a PLAY request.

  1.  C- > S: SETUP rtsp://example.com/media.mp4/ streamid = 0 RTSP/1.0
  2.  CSeq: 3
  3.  Transport: RTP/AVP;unicast; client_port = 8000 -8001 
  4.   
  5.  S- > C: RTSP/1.0 200 OK
  6.  CSeq: 3
  7.  Transport: RTP/AVP;unicast; client_port = 8000 -8001; server_port = 9000 -9001; ssrc = 1234ABCD  
  8.  Session: 12345678

(4) PLAY

The client plays one or all media streams through a PLAY request. The PLAY request can be sent once or multiple times. When sent once, the URL is the address containing all media streams. When sent multiple times, the URL carried in each request only contains one corresponding media stream. The PLAY request can specify the playback range. If not specified, the media stream is played from the beginning to the end. If the media stream is paused during playback, the playback of the stream can be restarted at the pause point.

  1.  C- > S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 4
  3.  Range: npt = 5 -20
  4.  Session: 12345678 
  5.   
  6.  S- > C: RTSP/1.0 200 OK
  7.  CSeq: 4
  8.  Session: 12345678
  9.  RTP-Info: url = rtsp ://example.com/media.mp4/ streamid = 0 ; seq = 9810092 ; rtptime = 3450012  

(5) PAUSE

A PAUSE request will pause one or all media streams, which can be resumed later with a PLAY request. The PAUSE request carries the URL of the requested media stream. If the parameter range exists, it indicates where to pause. If the parameter does not exist, the pause takes effect immediately, and the duration of the pause is indefinite.

  1.  C- > S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 5
  3.  Session: 12345678 
  4.   
  5.  S- > C: RTSP/1.0 200 OK
  6.  CSeq: 5
  7.  Session: 12345678

(6) TEARDOWN

End session request, which stops all media streams and releases related session data on the server.

  1.  C- > S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 8
  3.  Session: 12345678 
  4.   
  5.  S- > C: RTSP/1.0 200 OK
  6.  CSeq: 8

(7) GET_PARAMETER

Retrieve the parameter value in the specified URI data. GET_PARAMETER without a message body can be used to test whether the server or client is accessible (similar to the ping function).

  1.  S- > C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 9
  3.  Content-Type: text/parameters
  4.  Session: 12345678
  5.  Content-Length: 15 
  6.   
  7.  packets_received
  8.  jitter 
  9.   
  10.  C- > S: RTSP/1.0 200 OK
  11.  CSeq: 9
  12.  Content-Length: 46
  13.  Content-Type: text/parameters 
  14.   
  15.  packets_received: 10
  16.  Jitter: 0.3838

(8) SET_PARAMETER

Used to set the parameters of the specified media stream.

  1.  C- > S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 10
  3.  Content-length: 20
  4.  Content-type: text/parameters 
  5.   
  6.  barparam: barstuff 
  7.   
  8.  S- > C: RTSP/1.0 451 Invalid Parameter
  9.  CSeq: 10
  10.  Content-length: 10
  11.  Content-type: text/parameters 
  12.   
  13.  barparam

(9) REDIRECT

Redirect request is used by the server to inform the client of the new service address. The client needs to re-initiate a request to this new address. The redirect request may contain a Range parameter to indicate the time when the redirection takes effect. If the client needs to initiate a request to the new service address, it must first tear down the current session and then set up a new session to the specified new host.

  1.  S- > C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 11
  3.  Location: rtsp://bigserver.com:8001
  4.  Range: clock = 19960213T143205  

(10) ANNOUNCE

The ANNOUNCE request has two purposes: (1) C->S: the client publishes the media information description specified by the URL to the server; (2) S->C: real-time update of the conversation description. If a new media stream is added to the media representation, such as during a live broadcast, the entire media representation description must be resent, rather than just the new part.

  1.  C- > S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 7
  3.  Date: 23 Jan 1997 15:35:06 GMT
  4.  Session: 12345678
  5.  Content-Type: application/sdp
  6.  Content-Length: 332 
  7.   
  8.  v = 0  
  9.  o = mhandley 2890844526 2890845468 IN IP4 126.16.64.4
  10.  s = SDP Seminar
  11.  i = A Seminar on the session description protocol
  12.  u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps​
  13.  e = mjh @isi.edu (Mark Handley)
  14.  c = IN IP4 224.2.17.12/127
  15.  t = 2873397496 2873404696
  16.  a = recvonly  
  17.  m = audio 3456 RTP/AVP 0
  18.  m = video 2232 RTP/AVP 31 
  19.   
  20.  S- > C: RTSP/1.0 200 OK
  21.  CSeq: 7

(11) RECORD

Request to record a specified range of media data. The request can specify the start and end timestamps of the recording. If the time range is not specified, the start and end times in the presentation description are used. In this case, if the session has already started, the recording operation is started immediately.

  1.  C- > S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
  2.  CSeq: 6
  3.  Session: 12345678 
  4.   
  5.  S- > C: RTSP/1.0 200 OK
  6.  CSeq: 6
  7.  Session: 12345678

The above is an introduction to the commonly used commands and examples in RTSP. Finally, let's take a look at an actual RTSP command interaction process, which is obtained by pulling and playing the video stream of the Hikvision camera through a PC and capturing the client data through Wireshark:

  1.  OPTIONS rtsp://10.3.8.202:554 RTSP/1.0
  2.  CSeq: 2
  3.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22) 
  4.   
  5.  RTSP/1.0 200 OK
  6.  CSeq: 2
  7.  Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER
  8.  Date: Mon, Jan 29 2018 16:56:47 GMT 
  9.   
  10.  DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0
  11.  CSeq: 3
  12.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  13.  Accept: application/sdp 
  14.   
  15.  RTSP/1.0 401 Unauthorized
  16.  CSeq: 3
  17.  WWW-Authenticate: Digest realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , stale = "FALSE"  
  18.  Date: Mon, Jan 29 2018 16:56:47 GMT 
  19.   
  20.  DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0
  21.  CSeq: 4
  22.  Authorization: Digest username = "admin" , realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , uri = "rtsp://10.3.8.202:554" , response = "3fc4b15d7a923fc36f32897e3cee69aa"  
  23.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  24.  Accept: application/sdp 
  25.   
  26.  RTSP/1.0 200 OK
  27.  CSeq: 4
  28.  Content-Type: application/sdp
  29.  Content-Base: rtsp://10.3.8.202:554/
  30.  Content-Length: 551 
  31.   
  32.  v = 0  
  33.  o =- 1517245007527432 1517245007527432 IN IP4 10.3.8.202
  34.  s = Media Presentation
  35.  e = NONE  
  36.  b = AS :5050
  37.  t = 0 0
  38.  a = control :rtsp://10.3.8.202:554/
  39.  m = video 0 RTP/AVP 96
  40.  c = IN IP4 0.0.0.0
  41.  b = AS :5000
  42.  a = recvonly  
  43.  a = x -dimensions:2048,1536
  44.  a = control :rtsp://10.3.8.202:554/ trackID = 1  
  45.  a = rtpmap :96 H264/90000
  46.  a = fmtp :96 profile-level-id = 420029 ; packetization-mode = 1 ; sprop-parameter-sets = Z00AMp2oCAAwabgICAoAAAMAAgAAAwBlCA ==, aO48gA ==
  47.  a = Media_header :MEDIAINFO = 494D4B4801020000040000010000000000000000000000000000000000000000000000000000000 ;
  48.  a = appversion :1.0 
  49.   
  50.  SETUP rtsp://10.3.8.202:554/ trackID = 1 RTSP/1.0
  51.  CSeq: 5
  52.  Authorization: Digest username = "admin" , realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , uri = "rtsp://10.3.8.202:554/" , response = "ddfbf3e268ae954979407369a104a620"  
  53.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  54.  Transport: RTP/AVP;unicast; client_port = 57844 -57845 
  55.   
  56.  RTSP/1.0 200 OK
  57.  CSeq: 5
  58.  Session: 1273222592; timeout = 60  
  59.  Transport: RTP/AVP;unicast; client_port = 57844 -57845; server_port = 8218 -8219; ssrc = 5181c73a ; mode = "play"  
  60.  Date: Mon, Jan 29 2018 16:56:47 GMT 
  61.   
  62.  PLAY rtsp://10.3.8.202:554/ RTSP/1.0
  63.  CSeq: 6
  64.  Authorization: Digest username = "admin" , realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , uri = "rtsp://10.3.8.202:554/" , response = "b5abf0b230de4b49d6c6d42569f88e91"  
  65.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  66.  Session: 1273222592
  67.  Range : npt = 0.000- 
  68.   
  69.  RTSP/1.0 200 OK
  70.  CSeq: 6
  71.  Session: 1273222592
  72.  RTP-Info: url = rtsp ://10.3.8.202:554/ trackID = 1 ; seq = 65373 ; rtptime = 3566398668  
  73.  Date: Mon, Jan 29 2018 16:56:47 GMT 
  74.   
  75.  GET_PARAMETER rtsp://10.3.8.202:554/ RTSP/1.0
  76.  CSeq: 7
  77.  Authorization: Digest username = "admin" , realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , uri = "rtsp://10.3.8.202:554/" , response = "bb2309dcd083b25991c13e165673687b"  
  78.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  79.  Session: 1273222592 
  80.   
  81.  RTSP/1.0 200 OK
  82.  CSeq: 7
  83.  Date: Mon, Jan 29 2018 16:56:47 GMT 
  84.   
  85.  TEARDOWN rtsp://10.3.8.202:554/ RTSP/1.0
  86.  CSeq: 8
  87.  Authorization: Digest username = "admin" , realm = "IP Camera(10789)" , nonce = "6b9a455aec675b8db81a9ceb802e4eb8" , uri = "rtsp://10.3.8.202:554/" , response = "e08a15c27d3daac14fd4b4bcab424a5e"  
  88.  User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
  89.  Session: 1273222592 
  90.   
  91.  RTSP/1.0 200 OK
  92.  CSeq: 8
  93.  Session: 1273222592
  94.  Date: Mon, Jan 29 2018 16:57:03 GMT

<<:  Unveiling the mystery of MPLS, do you know all this?

>>:  In the 5G era, virtual operators “disappear”

Recommend

Actual combat: Can you believe it? Two VRRP hot standby gateways were installed in the operator's central computer room at the same time, but they fought with each other and caused the entire network to explode!

The case shared in this issue is related to VRRP ...

CloudCone: KVM monthly payment starts at $1.99, Los Angeles data center, supports PayPal/Alipay

CloudCone's [2021 Flash Sale] event is still ...

ChangeIP: High-security VPS monthly payment starts at $2.39, unlimited traffic VPS annual payment starts at $19.2, optional Los Angeles/Denver/Chicago/Netherlands data centers

ChangeIP is a site under Sharktech's data cen...

5G commercial use is still not good enough in the past two years? Is 5G really useless?

[[420040]] Before we knew it, 5G has been officia...

Interview Frequent: Talk about everything about HTTP caching

Speed, speed, and speed. If a website wants to pr...

What will the university of the future look like? The informatization construction of colleges and universities has given birth to a new university model

[51CTO.com original article] In late summer 2017,...

Under the 5G trend | A comparison of deployment between China and the United States

At present, 5G communication technology has cause...

What is the difference between a wireless access point and a wireless router?

[[183847]] There is a distinct difference between...

5G is here, and so is mainstream adoption for industrial IoT startups

Making machines communicate with humans is the be...

Four major trends in China's Internet development

On April 20, 1994, China gained full access to th...

Inventory: Top 10 WiFi Industry Events in 2016

As we all know, WiFi has penetrated into various ...

Starting next year, your home router should be upgraded to Wi-Fi 6!

This article is reproduced from Leiphone.com. If ...

Website built by Alibaba Cloud, fool-proof way to prohibit foreign IP access

1. Introduction The solution is suitable for tech...

Is it necessary to activate a 5G package to use the 5G network? The Ministry of Industry and Information Technology has responded, and users are applauding

Two years ago, 5G was still far away from us; two...

When Private LTE Is Better Than Wi-Fi

While cellular technology is often thought of as ...