Article directory
Preface
This section mainly explains the RTSP protocol and analyzes the protocol through wireshark packet capture.
1. RTSP builds live broadcast on demand by yourself
Test tool: VLC
Data source: file or local camera
Test function: RTSP live broadcast on demand
Playback address: rtsp://127.0.0.1:554/test
Server: Push streaming
Client: Pull streaming
1. The data source is video file
Refer to the picture below in my previous blog " Common Tools for Audio and Video Development "
2. The data source is the camera
①. Build RTSP streaming media server
<1>, click Media -> Stream
<2>, select the capture device, for the video device we select the built-in camera of the laptop, electric shock streaming
<3>, click Next
<4>, select RTSP for the new target, click Add
<5> , modify the path, and click the next
<6>, select Video - H.264 + MP3 (TS) for the configuration file, click the next
<7>, click stream
<8>, you can see the progress bar starts to move, like this The RTSP streaming media server has been set up and is currently being pushed.
②. Client streaming
<1>, open another VLC media player, select media -> open network streaming
<2>, change the network URL to: rtsp://:8554/test2, click play
<3>, the left side of the picture below is the server Push streaming, on the right is the client pulling the stream
The above two examples implement the RTSP live on demand function when the data sources are files and cameras respectively.
2. Introduction to RTSP protocol
RTSP (Real Time Streaming Protocol), RFC2326, real-time streaming protocol, is an application layer protocol in the TCP/IP protocol system. It is an IETF RFC standard submitted by Columbia University, Netscape and RealNetworks. This protocol defines how one-to-many applications can efficiently transmit multimedia data over IP networks . RTSP is a multimedia streaming protocol used to control audio or video , and allows simultaneous control of multiple streaming requirements.
RTSP is architecturally located on top of RTP and RTCP, and uses TCP or UDP to complete data transmission.
HTTP Compared with RTSP, HTTP requests are issued by the client and the server responds; when using RTSP, both the client and the server can issue requests, that is, RTSP can be bidirectional.
Live Streaming Session Protocol
- SDP (Session Description Protocol) Session Description Protocol
- RTP (Real-time Transfer Protocol) Realtime Transfer Protocol: audio and video streaming
RTSP is a text-based protocol that uses the ISO10646 character set and the UTF-8 encoding scheme .
The line is interrupted by CRLF (\r\n:10,13:0x0A,0x0D), including message type, message header, message body and message length. However, the receiver itself can interpret CR and LF as line terminators . The text-based protocol makes it easier to add optional parameters in a self-describing manner, and SDP is used as the description language in the interface.
RTSP is an application-level protocol that controls the sending of real-time data.
RTSP provides an extensible framework that enables controlled on-demand streaming of real-time data, such as audio and video. Data sources include live data and data stored in clips. The purpose of this protocol is to control multiple data sending connections, provide a way to select a sending channel, such as UDP, multicast UDP and TCP, and provide a method to select a sending mechanism based on RTP.
RTSP protocol supports:
- Retrieve media from media server
- Media server invitation to conference
- Add media to ready-made lectures
3. Hand-shred RTSP protocol
Since we want to analyze the RTSP protocol, we first capture the corresponding packets, and then analyze the RTSP protocol based on the packets.
1. Wireshark packet capture
①.Build environment
Virtual machine ( 192.168.137.128 ): Use VLC to push
the Windows host ( 192.168.167.176 ): Use VLC to pull the stream
②、Wireshark packet capture
Select the network card of the virtual machine.
You can see some of the captured messages as follows:
2. RTSP interaction process
Suppose we now want to send a request to an RTSP server to obtain data. The basic process is as follows:
①、OPTIONS
- C -> S: The client sends OPTIONS to the server to request available methods.
- S -> C: The server replies to the client, and the message contains the currently available methods.
②、DESCRIBE
- C -> S: The client requests the media description file from the server .
- S -> C: The server replies to the client sdp file, which tells the client what audio and video streams the server has and what attributes it has, such as codec information, frame rate, etc.
Here is a brief analysis of the SDP text. The complete information is as follows:
- (v): 0 //Indicates the version of the protocol
- (o):- 16771609170375560276 16771609170375560276 IN IP4 lpvm //Six parameters related to the session owner
- The first parameter: Indicates the name of the session initiator. This parameter does not need to be filled in. If it is filled in, it must be consistent with the content of the from header in the SIP message.
- Second parameter: session identifier of the calling party
- The third parameter: the version of the calling party's session. When the session data changes, the version number is incremented.
- The fourth parameter: defines the network type, IN represents the Internet network type, currently only this network type is defined
- The fifth parameter: address type, currently supports two address types: IPV4 and IPV6
- The sixth parameter: Address: Indicates the IP address of the session initiator. This address is the IP address of the signaling plane. It is assigned to the mobile phone when the signaling PDP is activated.
- (s): Unnamed //Indicates the title of this session, or the name of the session
- (i): N/A //Description of session
- (c): IN IP4 0.0.0.0 //Line c contains information about the connection established for the multimedia session, which indicates the IP address used by the real media stream.
- The first parameter is the network type, currently only the INTERNET network type is defined. Represented by "IN"
- The second parameter is the address type. Currently, two address types are supported: IPV4 and IPV6
- The third parameter is the address, which is the IP address used by the multimedia stream.
- (t): 0 0 //Indicates the start time and end time of the session
- (m): audio 0 RTP/AVP 14 //The m line, also known as the media line, describes the media type supported by the sender and other information
- The first parameter is the media name: indicating the supported audio type.
- The second parameter is the port number, indicating that the UE sends the audio stream on the local port 0.
- The third parameter is the transmission protocol, usually RTP/AVP protocol.
- Parameters four to seven are the numbers of the four payload types supported.
- (a): rtpmap:14 MPA/90000/2 //a is the attribute line of the behavioral media, expressed in the form of attribute name: attribute value.
- The format is: a=rtpmap:<payload type><encoding name>
③、SETUP
Prepare channels for audio and video data transmission
- C -> S: The client initiates a connection establishment request to the server, requests to establish a session connection, and prepares to start receiving audio and video data. The request information describes whether the audio and video data packets are expected to be transmitted based on UDP or TCP, and specifies the RTP, RTCP port, and Is it unicast or multicast and other information!
- S -> C: After receiving the client's request, the server determines the port for sending control data and the port for audio and video data according to the port number requested by the client!
④、PLAY
- C -> S: The client requests the server to play media.
- S -> C: The server replies to the client with 200 OK! Then start sending data through the port specified in SETUP!
⑤、TEARDOWN
- C -> S: When ending playback, the client initiates an end request to the server.
- S -> C: After receiving the message, the server sends 200 OK to the client, and then disconnects.
Steps ③ and ④ are required! Step ① As long as the server and client agree on which methods are available, the option request does not need to be made. Step 2. If we have other ways to obtain the media initialization description information (such as http request, etc.), we do not need to complete it through the describe request in rtsp.
上述的流程基本涵盖了 RTSP 的流程，当然，RTSP 除此之外，还有 PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER 等参数。
3. Agreement format
All operations in RTSP are completed through the message response mechanism of the server and client. The messages include requests and responses . RTSP is a symmetric protocol, and both the client and the server can send and respond to requests.
RTSP is a text-based protocol that uses UTF-8 encoding (RFC2279) and ISO10646 character sequences, using the universal message format defined by RFC882. Each statement line is terminated by CRLF (\r\n) . RTSP messages include requests and responses.
①.Request message
The request message consists of the request line, various header fields in the header line, and the body entity. The format of the request message is as follows:
- Methods : including OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, etc.
- URL : The address of the receiver, for example: rtsp://192.168.137.128:8554/test
- RTSP version : generally RTSP/1.0
- CRLF : The CRLF after each line represents carriage return and line feed, which requires corresponding parsing on the receiving end. The last message header needs to have two CRLFs.
- Entity body : The message body is optional, and some request messages do not include a message body.
②.Response message
The starting line of the response message is the status line. The format of the RTSP response message is as follows:
- Status code : It is a numerical value used to indicate the execution result of the request message, such as 200 indicating success.
- Phrase : The textual explanation corresponding to the status code
4. Method definition
注： P----演示， S----流， C----用户端， S----服务器端
| method | direction | object | Require | meaning |
|---|---|---|---|---|
| DESCRIBE | C -> S | P，S | recommend | Checks the description of a presentation or media object, also allowing you to specify a user-understood description format using a receiving header. DESCRIBE's Reply-Response Composition Media RTSP Initial Phase |
| ANNOUNCE | C -> S S->C |
P，S | Optional | When sent from the user to the server, ANNOUNCE sends the presentation or media object description identified by the request URL to the server; conversely, ANNOUNCE updates the connection description in real time. If new media streams are added to the demo, the entire demo description is sent again, not just the attached components, allowing components to be removed |
| GET_PARAMETER | C -> S S->C |
P，S | Optional | The GET_PARAMETER request checks the parameter values of the demo and media specified in the URL. GET_PARAMETER may be used to test the user's connectivity to the server when there is no entity |
| OPTIONS | C -> S S -> C |
P，S | Require | OPTIONS requests can be issued at any time. If the user intends to try a non-standard request, it will not affect the server status. |
| PAUSE | C -> S | P，S | recommend | A PAUSE request causes a temporary interruption in stream delivery. If the request URL names a stream, only playback and recording are stopped; if the request URL names a presentation or stream group, all currently active stream delivery in the presentation or group is stopped. After resuming playback or recording, synchronization must be maintained. After being paused for the period specified by the connection header timeout parameter in the SETUP message, server resources are reserved, although the server may close the connection and release the resources. |
| PLAY | C -> S | P，S | Require | PLAY tells the server to start sending data using the mechanism specified by SETUP; the client cannot issue a PLAY request until some SETUP requests are successfully responded to. The PLAY request sets the normal playback time to the beginning of the specified range and sends streaming data until the end of the range. PLAY requests can be queued. The server queues PLAY requests and executes them sequentially. |
| RECORD | C -> S | P，S | Optional | This method initializes the media data recording range according to the demonstration description, and the time scale reflects the start and end times; if no time range is given, the start and end times provided by the demonstration description are used. If the connection has been started, recording starts immediately. The server data request URL or other URL determines whether to store the recorded data; if the server does not use a URL request, the response should be 201 (Create) and include an entity describing the request status and referencing the new resource. Position header. Media servers that support live presentation recording must support the clock range format, the smpte format is meaningless |
| REDIRECT | S -> C | P，S | Optional | A redirect request informs the client to connect to another server address. It contains mandatory header addresses to instruct the client to issue a URL request; it may also include parameter ranges to indicate when the redirect will take effect. If the client wants to continue sending or receiving URL media, the client must send a TEARDOWN request to the current connection and a SETUP request to the new connection to the specified host. |
| SETUP | C -> S | P，S | Optional | A SETUP request to a URL specifies the transport mechanism used for streaming media. The client issues a SETUP request for 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 This State". In order to get through the firewall, the client must specify the transport parameters, even if there is no effect on these parameters |
| SET_PARAMETER | C -> S S -> C |
P，S | Require | This method requests the setting of parameter values for the demo or URL specified stream. Requests should only contain a single parameter, allowing the client to decide why a particular request failed. If the request contains multiple parameters, all parameters can be successfully set, and the server must only act on this request. The server must allow parameters to be set to the same value repeatedly, but not change the parameter value. Note: Media streaming parameters must be set using the SETUP command. It is helpful for firewalls to limit setup transfer parameters to SETUP. Divide parameters into regular arrangements, resulting in more meaningful error indications |
| TEARDOWN | C -> S | P，S | Require | TEARDOWN requests to stop sending the given URL stream and release related resources. If the URL is this demo URL, any RTSP connection identifiers are no longer valid. Unless all transport parameters are defined in the connection description, a SETUP request must be issued before the connection can be played again |
5. Status
RTSP State Machine
RTSP controls the flow of data sent over a separate protocol, independent of the control channel. For example, RTSP control can be over a TCP connection and data flow over UDP. Therefore, data will continue to be sent even if the media server does not receive the request. During the connection lifetime, individual media streams can be controlled by issuing requests in different TCP connection sequences. Therefore, the server needs to maintain a connection state communication stream with RTSP requests. Many methods in RTSP have nothing to do with state, but the following methods play an important role in defining the allocation and application of server stream resources:
- SETUP: Let the server allocate resources to the stream and start the RTSP connection
- PLAY and RECORD: Start the data transmission of the SETUP distribution stream
- PAUSE: Temporarily stops the stream without releasing server resources
- TEARDOWN: Release the resources of the stream and the RTSP connection stops.
The RTSP method of identifying status uses the connection header field to identify the RTSP connection. In response to the SETUP request, the server connection generates the connection identification.
4. RTSP and HTTP
The real-time streaming protocol is similar to HTTP/1.1 in syntax and operation, so most extension mechanisms of HTTP can be added to RTSP. However, RTSP is still different from HTTP in many important aspects:
- RTSP introduces a number of new methods and has a different protocol identifier
- In most cases, the RTSP server needs to remain in its default state, as opposed to HTTP's stateless
- In RTSP, both the client and the server can make requests
- In most cases, data is transmitted by different protocols
- RTSP uses ISO 10646 (UTF-8) instead of ISO 8859-1, consistent with the current international standard HTML
- URL requests always include absolute URLs. For compatibility with past bugs, HTTP/1.1 only transmits the absolute path during the request and puts the hostname in an additional header field
My qq: 2442391036, welcome to communicate!