Real-time stream protocol RTSP (realtimestreamingprotocol)

Real-time stream protocol RTSP (realtimestreamingprotocol) is jointly proposed by RealNetworks and Netscape. This Protocol defines how one-to-multiple applications can effectively transmit multimedia data over an IP network. RTSP is located on RTP and RTCP in the architecture. It uses TCP or RTP for data transmission. Compared with RTSP, HTTP transmits HTML, while RTP transmits multimedia data. HTTP requests are sent by the client and the server responds. When RTSP is used, both the client and server can send requests, that is, RTSP can be bidirectional.

6.3 RTSP Protocol
Real-time stream protocol (RTSP) is an application-level protocol that controls the transmission of real-time data. RTSP provides an extensible framework that makes real-time data, such as audio and video, controlled and on-demand, possible. Data sources include on-site data and stored in editing. This protocol is used to control multiple data transmission connections. It provides a channel for selection of transmission channels, such as UDP, multicast UDP, and TCP, and provides a method for choosing the RTP-based transmission mechanism.
6.3.1 Introduction
6.3.1.1 Purpose
The real-time stream protocol (RTSP) establishes and controls one or more time-synced continuous streaming media. Although it is possible that a continuous media stream and a control flow may cross, it does not send a continuous stream itself. In other words, RTSP acts as the network remote control for multimedia servers. The RTSP connection is not bound to a transport layer connection, such as TCP. During the RTSP connection, RTSP users can enable or disable multiple reliable transmission connections to the server to send RTSP requests. In addition, you can use a connectionless transport protocol, such as UDP. RTSP stream control may use RTP, but RTSP operations do not depend on the transmission mechanism used to carry continuous media. The real-time stream protocol is similar to HTTP/1.1 in terms of syntax and operation. Therefore, most HTTP extension mechanisms can be added to RTSP. The protocol supports the following operations:
Retrieve media from the Media Server:
You can submit a demo description through HTTP or other methods. If the demonstration is multicast, the demonstration contains the multicast address and port used for continuous media. If the demonstration is only sent to the user through a single broadcast, the user shall provide the destination address for security purposes.
Media Server invited to the meeting:
A Media Server can be invited to an ongoing meeting, play back the media, or record part or all of it. This mode is very useful in distributed education applications. In meetings, you can take turns to press the remote control button.
Add media to off-the-shelf lectures:
It is particularly useful for on-site lectures if the server tells users that they can obtain additional media content. For example, in HTTP/1.1, RTSP requests can be processed by agents, channels, and caches.
　
6.3.1.2 protocol features
The RTSP features are as follows:
Scalability:
The new method and parameters can be easily added to RTSP.
Easy to resolve:
RTSP can be parsed by standard HTTP or mime delmiters.
Security:
RTSP uses the webpage security mechanism.
Independent from transmission:
RTSP can use unreliable Datagram Protocol (UDP) and reliable Datagram Protocol (RDP). To achieve application-level reliability, you can use reliable stream protocol.
Multi-server support:
Each stream can be placed on different servers. The user end automatically establishes several concurrent control connections with different servers, and media synchronization is executed at the transport layer.
Record Device Control:
Protocol control records and playback devices.
Separation of traffic control and meeting initiation:
Only the Conference Initialization Protocol is required, or a unique conference id can be created. In special cases, sip or H.323
Can be used to invite servers to the meeting.
Suitable for professional applications:
With SMPTE time scales, RTSP supports frame-level precision and remote digital editing.
Demonstration description neutral:
The Protocol does not impose a special demo or Metafile, and the format type can be transferred; however, the demo description must contain at least one RTSP Uri.
Proxy and firewall friendly:
Protocols can be processed by application and transport layer firewalls. The firewall must understand the setup method and open a "gap" for UDP media streams ".
HTTP friendly:
Here, RTSP uses the HTTP concept wisely so that the current structure can be reused. The structure includes the Internet Content Selection platform (PICs ). In most cases, the server status is required to control continuous media. RTSP not only adds methods to HTTP.
Proper Server Control:
If a user starts a stream, the user must or can stop a stream.
Transmission coordination;
You can coordinate the transmission method before processing a continuous media stream.
Performance coordination:
If the basic features are invalid, you must have some cleanup mechanisms for the user to decide whether the method does not take effect. This allows the user to propose a suitable user interface.
6.3.1.3 extended RTSP
Since not all media servers share the same functions, it is necessary for media servers to support different request sets. RTSP can be expanded in the following three ways:
Extension with new parameters. If the user needs to reject the notification, but the method extension is not supported, the corresponding tag is added to the required segment.
Add a new method. If the message recipient does not understand the request and returns the 501 error code (not implemented yet), the sender should not try this method again. You can use the Options method to query methods supported by the server. The server uses public response headers to list supported methods.
Define the new version protocol and allow changes to all parts. (Except for the Protocol version number)
6.3.1.4 Operation Mode
Each demo and media stream can be identified by rtsp url. The entire demo and media attributes composed of the demo are defined by the demo description file. You can use HTTP or other methods to obtain this file, and it is not necessary to save it on the Media Server.
For illustration, assume that the demo description describes multiple demos, each of which maintains a common timeline. To simplify the description without being general, it is assumed that the demo description does include such a demo. The demo can contain multiple media streams. In addition to media parameters, the network destination address and port must also be determined. The following describes several operation modes:
Unicast:
Send the media to the RTSP request source using the selected port number.
Multicast, server selection address:
The Media Server selects the multicast address and port, which is a common method for live broadcast or quasi-Vod.
Multicast:
If the server is added to an ongoing multicast meeting, the multicast address, port, and key are provided by the meeting description.
6.3.1.5 RTSP status
RTSP controls the streams sent through a separate protocol and is irrelevant to the control channel. For example, the RTSP control can be connected over TCP, while the data stream is over UDP. Therefore, even if the media server does not receive the request, the data will continue to be sent. During the connection life cycle, a single media stream can be controlled by sending requests in different TCP connection sequence. Therefore, the server must maintain the connection status between the connection stream and the RTSP request. Many methods in RTSP are irrelevant to the status, 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 allocation stream.
Pause:
Stop the stream temporarily without releasing server resources.
Teardown:
Releases streaming resources. The RTSP connection is stopped.
The RTSP method for identifying the Status uses the connection header segment to identify the RTSP connection. In response to the SETUP Request, the server is connected
Generate a connection ID.
　
6.3.1.6 relationship with other Protocols
The RTSP function overlaps with HTTP, and the interaction with HTTP is reflected in the initial contact with the stream content through the web page. The purpose of the current protocol specification is to allow different transfer points between the webpage server and the RTSP Media Server. For example, the demo description can be retrieved through HTTP and RTSP, which reduces the browser's round-trip transmission and allows the independent RTSP server and users to rely entirely on HTTP.
However, the essential difference between RTSP and HTTP is that data is sent using different protocols. HTTP is an asymmetric protocol. When a user sends a request, the server responds. In RTSP, both the media user and the server can send requests and their requests are stateless. After the request is confirmed, you can still set parameters to control the media stream for a long time. Reusing HTTP functions has at least two advantages: security and proxy. The requirements are very similar. It is valuable to use HTTP functions in cache, proxy, and authorization.
When most real-time media use RTP as the transmission protocol, RTSP is not bound to RTP. The RTSP assumes that the demo description format can represent the static and temporary attributes of the demo containing several media streams.
　
6.3.2 protocol parameters
　
6.3.3 RTSP Information
RTSP is a text-based protocol that uses the ISO 10646 Character Set and UTF-8 encoding scheme. The line is interrupted with a CRLF, but the receiver can interpret the CR and LF line terminator. Text-based protocols make it easier to add optional parameters in self-description mode. Because the number of parameters and the frequency of commands are low, the processing efficiency is not noticed. After careful research, the text protocol can easily be prototyped by scripting languages (such as TCL, Visual Basic, and Perl.
The 10646 Character Set prevents Sensitive Character Set switching, but is invisible to applications. RTCP also adopts this encoding scheme. The ISO 8859-1 character with significant bits, for example, 1271x 10xxxxxx .. RTSP information can be carried through any low-layer transmission protocol.
Requests include methods, objects on which methods act, and parameters for further describing methods. The method can also be designed to require only a small number of or no State maintenance on the server side. When the information body is contained in the information, the length of the information body is determined by the following factors:
No matter whether the object header segment appears in the information, the response information that does not include the information body always ends with the first and empty rows after the header segment.
If the Content Length header segment appears, its value is in bytes, indicating the length of the information body. If no header segment exists, its value is zero.
The server closes the connection.
Note: RTSP currently does not support HTTP/1.1 "Block" Transmission Encoding and requires a Content Length header. If the length of the description is returned in a moderate manner, even if the block transfer encoding is generated dynamically, the server should be able to determine the length. If there is an entity, even if there must be a content length, and the length is not explicitly given, the rule can ensure reasonable behavior.
The request information from the user to the server includes the method, source ID, and Protocol version used by the source in the first line. RTSP defines the additional status code without defining any HTTP code.
6.3.4 entity
If the request method or response status code is not restricted, the request and response information can be transmitted to the entity. The entity consists of the entity header file and the question body. Some responses only include the entity header. Here, based on who sends the entity and who receives the entity, the sender and receiver can respectively refer to the user and server.
The object header defines the optional metadata of the Object Body. If no object body exists, it indicates the resource identified by the request. The extension header mechanism allows you to define additional entity header segments without changing the protocol, but these segments cannot be assumed that the receiver can recognize them. The unidentifiable header segment should be ignored by the receiver and forwarded by the proxy.
6.3.5 connection
RTSP requests can be transmitted in several different ways:
1. Persistent transmission connection, used for transmission of multiple requests/responses.
2. Each request/response transmits a connection.
3. No connection mode.
The transmission connection type is defined by RTSP Uri. For the "RTSP" scheme, continuous connection is required. For the "rtspu" scheme, call the RTSP request to send, instead of establishing a connection.
Unlike HTTP, RTSP allows media servers to send requests to media users. However, this is only supported during persistent connections. Otherwise, the media server does not reach the user reliably, which is the only way to send requests from the media server to the user through the firewall.
6.3.6 method definition
The method mark indicates the method executed on the resource. It is case sensitive. The new method can be defined in the future, but cannot start with $.
Some firewall designs and other environments may require the server to insert RTSP methods and stream data. As insertion will complicate client and server operations and impose additional overhead, this should be avoided unless necessary. Binary data insertion is only available when RTSP is transmitted over TCP. Stream data (such as RTP packets) is encapsulated with an ASCII circle symbol, followed by a one-byte channel identifier, followed by the length of the encapsulated binary data, two-byte integer. Tight Stream Data