Easydarwin Open Source Community streaming video course: Streaming media Transmission Control Protocol (RTSP RTP SDP) Detailed RTSP

Video courses and related documents code address: https://github.com/EasyDarwin/Course#course-3

Introduction to streaming Media Transport protocol I. RTSP protocol introduction What is RTSP?

The RTSP protocol works as a client server, such as pause/resume, back, forward, etc. It is a multimedia playback control protocol used to enable users to control the playback of real-time data downloaded from the Internet.
Therefore, RTSP is also known as "Internet Recorder Remote Control protocol."

RTSP (Real-time Stream Protocol) is a text-based application layer protocol, and the RTSP protocol is similar to the HTTP protocol in syntax and some message parameters. is an application-level protocol in the TCP/IP protocol system submitted by Columbia University, Netscape and RealNetworks for the IETF RFC standard. The corresponding RFC number is 2326, which can be searched here for the RfC Editor

This protocol defines how a one-to-many application can efficiently transmit multimedia data over an IP network. RTSP is architecture-based on RTP and RTCP, and it uses TCP or RTP to complete the data transfer.
RTSP is used to establish the transmission of the control media stream, which plays the role of "Network remote control" for multimedia services. Although it is sometimes possible to interleave the RTSP control information with the media data stream , the general condition of RTSP itself is not used to transmit media stream data. The transmission of media data can be done through protocols such as RTP/RTCP.

This protocol is used in the C/S model and is a text-based protocol for establishing and negotiating real-time streaming sessions on the client and server sides.

Network system

RTSP是类似http的应用层协议，一个典型的流媒体框架网络体系可参考

A basic RTSP operation process:

• First, the client connects to the streaming server and sends an RTSP description command (DESCRIBE).
• The streaming server uses an SDP description to make feedback, including information such as the number of streams, the type of media, and so on.
• The client then parses the SDP description and sends an RTSP Setup command (SETUP) for each stream in the session, and the RTSP Setup command tells the server that the client is using the port to receive the media data. After the streaming media connection is established,
• When the client sends a play command (play), the server begins to transfer the media stream (RTP packet) to the client on UDP. The client can also send commands to the server to control fast forward, rewind, and pause during playback.
• Finally, the client can send a terminate command (Teradown) to end the streaming session

sequenceDiagram客户端->>服务器:DESCRIBE200OK (SDP)客户端->>服务器:SETUP200OK客户端->>服务器:PLAY服务器->>客户端: (RTP包)

Protocol Features

• Extensibility: New methods and parameters are easily added to RTSP.
• Easy to parse: RTSP can be parsed by a standard HTTP or MIME parser.
• Security: RTSP uses a web security mechanism.
• Independent of transmission: RTSP can use unreliable Datagram Protocol (EDP), Reliable Datagram Protocol (RDP); For application-level reliability, you can use a reliable streaming protocol.
• Multi-server support: Each stream can be placed on different servers, the client automatically establishes several concurrent control connections with different servers, and media synchronization is performed at the transport layer.
• Recording Device control: The protocol controls the recording and playback devices.
• Flow control begins separation from meeting: requires only a meeting initialization protocol, or can be used to create a unique meeting identification number. In special cases, you can invite a server to join by using SIP or an.
• Suitable for professional applications: with SMPTE time scales, RTSP supports frame-level accuracy, allowing remote digital editing.
• Demo Description Neutral: The protocol does not impose special demonstrations or meta-files, which can be transmitted using the format type; However, the presentation description must include at least one RTSP URL.
• Agent-to-firewall-friendly: protocols can be handled by the application and transport layer firewalls. The firewall needs to understand the Setup method and open a "notch" for the UDP media stream.
• HTTP friendly: Here, RTSP uses the HTTP concept wisely, making the structure reusable now. The structure includes the Internet Content Selection platform (PICS). Because the server state is required in most cases to control continuous media, RTSP does not just add methods to HTFP.
• Proper server control: If a user starts a stream, a stream must also be stopped.
• Transport coordination: The user can coordinate the transfer method before actually processing the continuous media stream.
• Performance coordination: If the basic features are invalid, there must be a cleanup mechanism to let the user decide which method is not in effect. This allows the user to propose a suitable user interface.

RTSP protocol differs from HTTP protocol

1. RTSP introduced several new methods, such as describe, PLAY, SETUP and so on, and there are different protocol identifiers, rtsp for RTSP 1.0,http for HTTP 1.1;
2. HTTP is a stateless protocol, while RTSP maintains state for each session;
3. The client and server side of the RTSP protocol can send request requests, whereas in the HTTPF protocol, only the client can send request requests.
4. In the RTSP protocol, the load data is generally transmitted by means of an out-of-band (except for interleaving), and through the RTP protocol in different channels to transmit load data. The payload data of the HTTP protocol is transmitted in-band, for example, the requested Web page data is carried in the body of the message being responded to.
5. Use ISO 10646 (UTF-8) instead of ISO 8859-1 to match the internationalization of the current HTML;
6. RTSP contains an absolute URI when using a URI request. Because of the backward compatibility problem caused by historical reasons, http/1.1 only contains the absolute path in the request, and puts the hostname into a separate header domain;

II. the message structure of RTSP the syntax structure of RTSP URL

An end user is the first step to watch the streaming media business by entering the URL address in the player, while for mobile streaming media on the RTSP protocol, the URL is generally written as follows:

A URL link starting with "RTSP" or "RTSPU" is used to specify that the RTSP protocol is currently in use. The syntax structure of the RTSP URL is as follows:

Rtsp_url = ("RTSP:" | " RTSPU: ")"//"host [": "Port"]/[abs_path]/content_name

host: Can be a valid domain name or IP address.

Port: Port number, for the RTSP protocol, the default port number is 554. This entry can be omitted when we confirm that the port number provided by the streaming server is 554
Note: When the port number used by the HMS Server is 554, we can write the on-demand link without specifying the port number, but when using a non-554 port, be sure to specify the appropriate port in the RTSP URL.

Abs_path: for the media stream resource identification in Rtspserver, see the video resource naming in the next section.

The rtspurl is used to identify the Rtspserver media stream resource, can identify a single media streaming resource, or can be labeled
A collection of multiple media streaming resources.

The message structure of RTSP

RTSP is a text-based protocol that uses CRLF as the Terminator for a line. The advantage of using a text-based protocol is that we can add custom parameters at any time during the use process, or we can easily capture the protocol packets and analyze them intuitively.

RTSP has two types of messages: Request messages and response messages . A request message is a request message sent from a customer to the server, and a response message is an answer from the server to the customer.
Since RTSP is body-oriented (text-oriented), each field in the message is a number of ASCII strings, so the length of each field is indeterminate.
The RTSP message consists of three parts: the start line, the first row, and the entity body . In the request message, the start line is the request line.

The structure of the RTSP request message is as shown

Figure 2 Structure of the RTSP request message

The methods for RTSP request messages include options, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, Get_parameter, and Set_parameter.

A request message (a requests messages) can be initiated either by the client to the server or by the server to the client. The syntax structure of the request message is as follows:
>

Request = Request-line

  *(  general-header   | request-header | entity-header)      CRLF      [message-body]

1. Request Line

The syntax structure of the first line of the request message is as follows:

Request-Line    =   Method 空格 Request-URI 空格 RTSP-Version CRLF

The first word that appears in the message line is the signaling flag that is used. The information currently available is as follows:

  Method      =   “DESCRIBE”           |   “ANNOUNCE”          |   “GET_PARAMETER”          |   “OPTIONS”          |   “PAUSE”          |   “PLAY”          |   “RECORD”          |   “REDIRECT”          |   “SETUP”          |   “SET_PARAMETER”          |   “TEARDOWN”

Example:

DESCRIBE rtsp://211.94.164.227/3.3gp rtsp/1.0

2. Request Header Fields

In the message header, in addition to the first line of content, there are some requirements to provide additional information. Some of them are for sure, and we'll go over the meanings of several fields that are often used in the following sections.

  Request-header      =   Accept              |   Accept-Encoding              |   Accept-Language              |   Authorization              |   From              |   If-Modified-Since              |   Range              |   Referer              |   User-Agent

Response message

The start line of the response message is the status line, andthe structure of the RTSP response message is shown

Figure 3 Structure of the RTSP response message

The syntax structure of the response message is as follows:

Response = Status-line
* (General-header
| Response-header
| Entity-header)
CRLF
[Message-body]

1. Status-line

The first line of the response message is the status line (Status-line), separated by a space between each element. In addition to the final CRLF, there should be no CR or LF in the middle of this line. Its syntax is formatted as follows,

Status-line = rtsp-version space Status-code space Reason-phrase CRLF

The status code (STATUS-CODE) is a three-digit integer that describes the result of the receiver's execution of the received request message

The first digit of the status-code specifies the type of reply message, in total 5 categories:
-[] 1xx:informational– request received, continue processing
-[] 2xx:success– request was successfully received, parsed and accepted
-[] 3xx:redirection– requires more action to complete the request
-[] 4xx:client error– Request message contains syntax error or cannot be executed effectively
-[] 5xx:server error– server response failed, unable to process the correct valid request message

The status codes we often encounter when dealing with problems are as follows:

Status-code	=
.	|
.	|
.	|

2. Response Header Fields

In the domain of the response message, there is some additional information that cannot be placed in the status-line and that needs to be transmitted to the requestor.

 Response-header    =   Location              |   Proxy-Authenticate              |   Public              |   Retry-After              |   Server              |   Vary              |   WWW-Authenticate

The main methods of RTSP are:

Method	direction	Object	Requirements	meaning
DESCRIBE	C->s	P,s	Recommended	Examines the description of a presentation or media object, and also allows you to specify a descriptive format that the user understands by using the receive header. Describe reply-Response composition Media RTSP initial stage
Announce	C->s s->c	P,s	Options available	When sent from the user to the server, announce sends a presentation or media Object description that requests URL recognition to the server, whereas announce updates the connection description in real time. As new media streams are added to the demo, the entire presentation description is sent again, not just the add-ons, so that the components can be deleted
Get_parameter	C->s s->c	P,s	Options available	The Get_parameter request checks the Rul specified presentation with the media parameter values. When there is no physical body, get_parameter may be used to test the connectivity of the user to the server
OPTIONS	C->s s->c	P,s	Requirements	Options requests can be made at any time, such as when a user intends to try non-standard requests and does not affect server status
PAUSE	C->s	P,s	Recommended	The pause request causes the stream to send a temporary interrupt. If the request URL names a stream, only playback and records are stopped, such as a request URL named a demo or stream group, the presentation or all currently active stream sends in the group are stopped. After resuming playback or recording, you must maintain synchronization. After the connection timeout parameter is paused during the setup message, the server resource is booked, even though the server may shut down and free resources
PLAY	C->s	P,s	Requirements	Play tells the server to start sending data with the mechanism specified by Setup, until some setup requests are successfully answered and the client can post the play request. The play request sets the normal playback time to the beginning of the specified range, sending the stream data until the end of the range. Play requests can be queued, the server queues the play requests, executes sequentially
RECORD	C->s	P,s	Options available	The method initializes the media data record range according to the presentation description, and the time scale reflects the start and end times, or, if no time range is given, the start and end times provided by the demo description. If the connection is started, immediately begins recording, the server data request URL or other URL determines whether the recorded data is stored, such as the server does not use a URL request, the response should be 201 (created), and contains the entity and location header that describes the request status and references the new resource. Media server that supports live demo recording must support clock range format, and SMPTE format is meaningless
REDIRECT	S->c	P,s	Options available	The redirect request notifies the client to connect to another server address. It contains a mandatory header address that instructs the client to publish a URL request, or it may include a parameter range to indicate when the redirect takes effect. If the client wants to continue sending or receiving the URL media, the client must send a teardown request to the current connection and send the setup request to the specified master new connection
SETUP	C->s	S	Requirements	The setup request for the URL specifies the transport mechanism for streaming media. The client publishes a setup request to the stream being played to change the transport parameters allowed by the server. If this is not allowed, the response error is "455 Method not Valid in". In order to pass through the firewall, the client must indicate the transmission parameters, even if there is no effect on these parameters
Set_parameter	C->s s->c	P,s	Options available	The request sets a presentation or URL to specify a parameter value for the stream. The request should contain only a single parameter, allowing the client to determine why a particular request failed. If the request contains more than one parameter, all parameters can be set successfully and the server must function only for that request. The server must allow the parameter to be set to the same value repeatedly, but not to change the parameter value. Note: The media stream transfer parameters must be set with the Setup command. Restricting set transport parameters to setup is advantageous for firewalls. Divide the parameters into regular permutations, resulting in more meaningful error indications
TEARDOWN	C->s	P,s	Requirements	Teardown requests to stop a given URL stream from being sent, freeing related resources. If the URL is this demo URL, any RTSP connection ID is no longer valid. The setup request must be published before the connection can be played again unless the full transport parameter is defined by the connection description

Note: P-Demo, C-client, S-Server, S. (object bar)-Flow

Signaling refers to the actions that are specified in Request-uri that need to be done by the receiver. Signaling (the method) is case sensitive and cannot start with the character "$" and must be a marker. RTSP Important Header field parameters

1. Accept:
   Used to specify the type of media description information that the client can accept. Like what:
   ACCEPT:APPLICATION/RTSL, application/sdp;level=2

2. Bandwidth:
   Used to describe the bandwidth values available to the client.

3. CSEQ:
   Specifies the sequence number of the RTSP request response pair and must include this header field in each request or response. For each request message containing a given sequence number, there will be a response message with the same sequence number.
4. Rang:
   Lets you specify a time range that you can use with SMPTE, NTP, or clock time cells.
5. Session:
   The Session header field identifies an RTSP session. Session ID is selected by the server in the response of Setup, when the client receives the session ID, the session ID will be included in the subsequent action request message to the session.
6. Transport:
   The Transport header field contains a list of transfer options that the client can accept, including transport protocols, address ports, TTL, and so on. The server side also returns the specific options that are actually selected through this header field. Such as:
   Transport:rtp/avp;multicast;ttl=127;mode= "PLAY",
   Rtp/avp;unicast;client_port=3456-3457;mode= "PLAY"

Simple RTSP message interaction process

C represents the RTSP client, s represents the RTSP server

The first step: querying the server-side available methods

C->s OPTION Request//Ask S which methods are available

S->c OPTION Response//s The public header field of the response information includes all available methods provided

Step two: Get Media description Information

C->s DESCRIBE Request//Requires media description information provided by S

S->c DESCRIBE Response//s responds to media description information, typically SDP information

Step three: Establish the RTSP session

C->s Setup request//list acceptable transfer options through the Transport header field, requesting S to establish a session

S->c Setup Response//s to establish a session, return the selected specific Transfer option through the Transport header field and return the established session ID;

Fourth step: Request to start transmitting data

C->s PLAY Request//c requests S to start sending data

S->c PLAY Response//s Back the information that should be requested

Fifth step: Data transfer in playback

S->c send streaming media data//Transmit data via RTP protocol

Sixth step: Close the session, exit

C->s Eardown Request//C requests Close session

S->c TEARDOWN response//s back should request

The above process is only a standard, friendly RTSP process, but the actual requirements do not necessarily follow this process.
The third and fourth steps are required! The first step is that if the server and the client agree on what methods are available, the option request may not. The second step, if we have other ways to get the media initialization description information (such as HTTP requests, etc.), then we do not need to pass the describe request in RTSP to complete.

Sample Request response for RTSP

 其中C是客户端，S是服务端。

OPTIONS

  C->S:       OPTION request //询问S有哪些方法可用  S->C:       OPTION response //S回应信息中包括提供的所有可用方法

* Client-to-server *

OPTIONS rtsp://218.207.101.236:554/mobile/3/67a451e937422331 rtsp/1.0
Cseq:1

Service-side response to options: (the server's response information will list the methods provided in the public field.) ）

rtsp/1.0 OK
server:pvss/1.4.8 (build/20090111; Platform/win32; Release/starvalley; )
Cseq:1
Public:describe, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, announce, RECORD

DESCRIBE

  C->S:      DESCRIBE request //要求得到S提供的媒体初始化描述信息  S->C:      DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

Client-to-server request example: (the client sends a describe to the servers to obtain the media description information specified by the URI, typically the SDP information.) The client specifies the type of media information that the client can accept through the accept header. ）

DESCRIBE RTSP://218.207.101.236:554/MOBILE/3/67A451E937422331/8JH5QPU5GWS07UGN.SDP rtsp/1.0
Cseq:2

Service side response to describe: (server response URI Specifies the description of the media)

RTSP/1.0 200 OK  Server: PVSS/1.4.8 (Build/20090111; Platform/Win32; Release/StarValley; )  Cseq: 2  Content-length: 421  Date: Mon, 03 Aug 2009 08:21:33 GMT  Expires: Mon, 03 Aug 2009 08:21:33 GMT  Content-Type: application/sdp  x-Accept-Retransmit: our-retransmit  x-Accept-Dynamic-Rate: 1  Content-Base: rtsp://218.207.101.236:554/mobile/3/67A451E937422331/8jH5QPU5GWS07Ugn.sdp/  v=0  o=MediaBox 127992 137813 IN IP4 0.0.0.0  s=RTSP Session  i=Starv Box Live Cast  c=IN IP4 218.207.101.236  t=0 0  a=range:npt=now-  a=control:*  m=video 0 RTP/AVP 96  b=AS:20  a=rtpmap:96 MP4V-ES/1000  a=fmtp:96 profile-level-id=8; config=000001b008000001b5090000010000000120008440fa282c2090a31f; decode_buf=12586  a=range:npt=now-  a=framerate:5  a=framesize:96 176-144  a=cliprect:0,0,144,176  a=control:trackID=1  

For more information

Email:[email protected]

WEB:www.EasyDarwin.org

Copyright? Easydarwin.org 2012-2016

Easydarwin Open Source Community streaming video course: Streaming media Transmission Control Protocol (RTSP RTP SDP) Detailed RTSP