Real-time Streaming protocol RTSP (Realtimestreamingprotocol)

Real-time Streaming protocol RTSP (Realtimestreamingprotocol) is proposed by RealNetworks and Netscape, which defines how a one-to-many application can efficiently transfer multimedia data over an IP network. RTSP is on the architecture of RTP and RTCP, which uses TCP or RTP to complete data transfer. HTTP transmits HTML compared to RTSP, while RTP transmits multimedia data. HTTP requests are sent by the client, the server responds, and when the RTSP is used, both the client and the server can make requests, that is, the RTSP can be two-way.

6.3 RTSP Protocol
Real-time Streaming Protocol (RTSP) is an application-level protocol, which controls the transmission of real-time data. RTSP provides an extensible framework for the control and on-demand of real-time data, such as audio and video. The data source includes the field data and the data stored in the clip. The purpose of this protocol is to control multiple data sending connections, to provide a way for selecting the sending channel, such as UDP, multicast UDP and TCP, and to provide a method for choosing based on RTP forwarding mechanism.
6.3.1 Introduction
6.3.1.1 Purpose
Real-time Streaming Protocol (RTSP) establishes and controls continuous streaming media for one or several times. Although it is possible to cross a continuous media stream with a control flow, it usually does not send a continuous stream itself. In other words, RTSP acts as a network remote control of a multimedia server. The RTSP connection is not bound to a transport layer connection, such as TCP. During a RTSP connection, RTSP users can turn on or off multiple reliable transport connections to the server to issue RTSP requests. In addition, connectionless transport protocols, such as UDP, can be used. RTSP flow-controlled streams may use RTP, but RTSP operations do not depend on the transport mechanism used to carry continuous media. Real-time Streaming protocol is similar to http/1.1 in syntax and operation, so the extension mechanism of HTTP can mostly join RTSP. The actions supported by the Protocol are as follows:
To retrieve media from the media server:
Users can submit a demo description via HTTP or another method. If the demo is multicast, the demo contains the multicast addresses and ports for continuous media. If the demo is only sent to the user through a single broadcast, the user should provide the destination address for security.
Media server invited to the meeting:
Media servers can be invited to participate in ongoing meetings, or to play back the media, or to record a portion, or all of them. This pattern is useful in distributed education applications where several parties can rotate the remote control button.
Add media to ready-made lectures:
If the server tells the user to get additional media content, it is particularly useful for live lectures. Like in http/1.1, RTSP requests can be handled by proxies, channels, and caches.
　
6.3.1.2 protocol Features
The RTSP features are as follows:
Scalability:
New methods and parameters are easily added to the RTSP.
Easy to resolve:
RTSP can be resolved by a standard HTTP or mime desorption.
Safety:
RTSP uses the Web page security mechanism.
Independent of transmission:
RTSP can use Unreliable Datagram Protocol (UDP), Reliable Datagram Protocol (RDP), and reliable streaming protocols to achieve application-level reliability.
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 level.
Recording Device Control:
The protocol controls recording and playback devices.
The flow control begins to separate from the meeting:
Only the Meeting initialization protocol is required or can be used to create a unique meeting identification number. In special cases, SIP or H.323
Can be used to invite a server to join.
Suitable for professional applications:
With SMPTE, RTSP supports frame-level precision, allowing remote digital editing
Demo Description Neutrality:
The protocol does not impose special demonstrations or meta files, and can transmit the type of format used; however, the demo description must contain at least one rtsp URI.
Agent and 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 wisely uses the HTTP concept to make the structure reusable now. The structure includes the Internet Content Selection platform (PICS). Since controlling continuous media requires server state in most cases, RTSP not only adds methods to HTTP.
Appropriate server control:
If the user starts a stream, he must also be able to stop a stream.
Transmission coordination;
Before the actual processing of continuous media flow, users can coordinate the transmission method.
Performance Coordination:
If the basic features are not valid, there must be some cleanup mechanism for the user to decide which method is not in effect. This allows the user to present a suitable user interface.
6.3.1.3 Extension RTSP
Because not all media servers have the same functionality, it is necessary for the media server to support different request sets. RTSP can be extended in three ways, here to sort by size:
Expands with a new parameter. If the user needs to reject the notification, and the method extension does not support it, the corresponding tag is added to the required section.
Add a new method. If the recipient of the message does not understand the request, returns a 501 error code (not yet implemented), and the sender should not try this method again. Users can use the options method to query the methods supported by the server. The server uses a common response header to list the supported methods.
Defines a new version of the protocol that allows all parts to be changed. (except the protocol version number location)
6.3.1.4 operation mode
Each demo and media stream can be identified by RTSP URLs. The demo consists of the entire demo and media properties defined by the demo description file. This file is available to users using HTTP or other means, and it is not necessary to keep it on the media server.
To illustrate, suppose the demo description describes multiple demos, each of which maintains a common timeline. To simplify the description, and without losing generality, assume that the demo description does contain such a demo. Demonstrates that you can include multiple media streams. In addition to media parameters, network destination addresses and ports also need to be determined. There are several modes of operation that are distinguished:
Unicast:
Sends the media to the RTSP request source with the user-selected port number.
Multicast, server Select Address:
The media server chooses the multicast address and the port, which is the common way of live broadcast or quasi-VOD.
Multicast, user Select Address:
If the server joins an ongoing multicast meeting, the multicast address, port, and key are described by the meeting.
6.3.1.5 RTSP State
RTSP controls the flow sent through a separate protocol, regardless of the control channel. For example, RTSP control can be connected through TCP, and data flow through UDP. Therefore, the data will continue to be sent even if the media server does not receive the request. During the connection lifetime, a single media stream can be controlled by issuing requests in different TCP connection sequences. Therefore, the server needs to maintain the connection state that can contact flow and RTSP requests. Many of the methods in RTSP are not state-dependent, but the following methods play an important role in defining the allocation and application of server flow resources:
SETUP:
Let the server allocate resources to the stream and start the RTSP connection.
Play and record:
Launches the data transfer for the setup allocation stream.
PAUSE:
Temporarily stops the stream without releasing the server resources.
Teardown:
Frees the resource of the stream, rtsp the connection to stop.
The RTSP method that identifies the state uses the connector segment to identify the RTSP connection, and in response to the setup request, the server connects
The connection identification is generated.
　
6.3.1.6 relationships with other protocols
RTSP is functionally overlapping with HTTP, and HTTP interaction is reflected in the initial contact with the stream content through the Web page. The current protocol specification is designed to allow for different delivery points between the Web server and the implementation RTSP Media server. For example, a demo description can be retrieved via HTTP and RTSP, which reduces the return of a browser, and allows independent RTSP servers and users to not rely entirely on HTTP.
However, the essential difference between RTSP and HTTP is that data is sent in different protocols. HTTP is the asymmetric protocol, the user makes a request, the server responds. In RTSP, media users and servers can make requests and their requests are stateless, and the parameters can still be set to control media flow for a long time after the request has been confirmed. There are at least two benefits to reusing HTTP functionality, namely security and proxy. Requirements are very close, and using HTTP functionality on caching, proxy, and authorization is valuable.
When most real-time media use RTP as a transport protocol, RTSP is not bound to RTP. The RTSP hypothesis exists that the presentation description format can represent static and temporary properties of demonstrations that contain 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, using the UTF-8 encoding scheme. The line is interrupted by CRLF, but the receiver itself can interpret the CR and LF as a row terminator. text-based protocols make it easier to add optional parameters in a self-describing way. Due to the low number of parameters and the frequency of commands, the processing efficiency is not noticed. If you look closely, text protocols can easily be used in scripting languages such as TCL, Visual Basic, and Perl to implement research prototypes.
The 10646 character set avoids sensitive character set switching, but is not visible to the application. RTCP also uses this coding scheme. ISO 8859-1 characters with significant bits are represented as 100001x 10xxxxxx. RTSP information can be carried by any low-level transport protocol.
The request includes the method, the object on which the method is acting, and the parameters that further describe the method. Methods can also be designed to require little or no state maintenance on the server side. When an information body is contained in information, the length of the information body is determined by the following factors:
Regardless of whether an entity header appears in the information, the response information that does not include the body of the message is always ended with the first and empty lines after the first paragraph.
If the content length header is present, the value is in bytes, representing the length of the message body. If the first segment does not appear, the value is zero.
The server closes the connection.
Note: RTSP does not currently support http/1.1 "block" transfer encoding and requires a content-length header. If the return moderate demo description length, even if the dynamic generation, so that block transfer coding is not necessary, the server should be able to determine its length. If there is an entity, the rule ensures that the behavior is reasonable, even if the length of the content must be there and the length is not explicitly given.
The request information from the user to the server side includes the method used by the source, the source identity, and the protocol version used in the first line. RTSP defines an additional status code without defining any HTTP code.
6.3.4 Entities
The request and response information transmits entities, such as the entity header file and the question body, and some responses only include the entity headers, if the request method or the response state encoding limit is not used. Here, depending on who sent the entity, who receives the entity, the sender and receiver can refer to the user and the server, respectively.
Entity headers define entity-body optional meta information, such as no entity body, which refers to the resource that is requested for identification. The extended header mechanism allows you to define additional entity headers without changing the protocol, but these segments do not assume that the receiver is recognizable. Unrecognized headers should be ignored by the receiver and forwarded by the agent.
6.3.5 Connection
RTSP requests can be transmitted in several different ways:
1. A persistent transmission connection for multiple request/response transmissions.
2. Each request/response transmits a connection.
3, no connection mode.
The transport connection type is defined by the RTSP URI. For the "RTSP" scenario, a continuous connection is required, while the "RTSPU" scheme calls RTSP requests for delivery without establishing a connection.
Unlike HTTP,RTSP, the media server is allowed to send requests to media users. However, this is supported only on a persistent connection, otherwise the media server does not have a reliable way to reach the user, which is the only way to request that the user be uploaded from the media server through a firewall.
6.3.6 method definition
A method token represents a method that is executed on a resource, which is case-sensitive. The new method can be defined in the future, but it cannot begin with $.
Some firewall designs and other environments may require the server to insert RTSP methods and stream data. Because inserts make the client and server operations complex and impose additional overhead, you should avoid doing this unless you need to. Inserting binary data is only available when RTSP is transmitted over TCP. Stream data (such as RTP packets) is encapsulated with an ASCII dollar symbol followed by a byte channel identifier followed by the length of the encapsulated binary data, two-byte integers. Stream data Tight