Real-time flow protocols RTSP (RealTimeStreamingProtocol) is made by RealNetworks and Netscape, which defines how a multimedia data is transmitted efficiently through IP networks. RTSP is located on the RTP and RTCP on the architecture, which uses TCP or RTP to complete data transmission. HTTP transmits HTML compared to RTSP, while RTP is transmitted is multimedia data. The HTTP request is issued by the client, and the server responds; when using RTSP, both the client and the server can issue a request, that is, the RTSP can be two-way.
6.3 RTSP Protocol Real Time Flow Protocol (RTSP) is the application level protocol to control the transmission of real-time data. RTSP provides an extensible framework that makes real-time data, controlled by audio and video, on-demand. The data source includes field data and data stored in the clip. The protocol is an object of controlling multiple data transmission connections, providing a transmission channel, such as UDP, multicast UDP, providing a way, and provides a method based on RTP-based transmission mechanism. 6.3.1 Introduction 6.3.1.1 Destination Real Time Flow Protocol (RTSP) Establishes and controls a continuous stream of continuous streams synchronized by one or time. Although continuous media streams and control flow intersect, usually it does not send continuous streams. In other words, RTSP acts as a network remote control of a multimedia server. The RTSP connection is not bound to the transport layer connection, such as TCP. During the RTSP connection, the RTSP user can turn off or off multiple reliable transfer connections to the server to issue RTSP requests. In addition, you can use no connection transport protocol, such as UDP. The RTSP stream control flows may be used to RTP, but the RTSP operation does not depend on the transmission mechanism for carrying continuous media. The real-time flow protocol is similar to HTTP / 1.1 in syntax and operation, so the HTTP expansion mechanism can be added to RTSP. The operations supported by the protocol are as follows: Search media from the media server: Users can submit a presentation description via HTTP or other methods. If the demo is multicast, the demo includes multicast addresses and ports for continuous media. If the presentation is sent to the user only by unicast, the user should provide the destination address for security. Media Server Invitation Enters a meeting: Media servers can be invited to participate in the positive meeting, or play back the media, or record some of them, or all. This model is useful in distributed education applications, and several conferences can be turned by remote control buttons. Add the media to the ready-made lecture: If the server tells the user to get additional media content, it is especially useful for the on-site lectures. Similar to HTTP / 1.1, the RTSP request can be processed by proxy, channels and cache. 6.3.1.2 Protocol Features The RTSP features are as follows: Scalability: The new methods and parameters are easy to join RTSP. Easy to analyze: RTSP can be parsed by standard HTTP or MIME desirators. Security: RTSP uses a web security mechanism. Independent: RTSP can use Unreliable Data Raising Protocol (UDP), Reliable Data Ravel Protocol (RDP), if the application level is reliable, you can use Reliable Stream Agreement. Multi-server support: Each stream can be placed on different servers, and the user automatically creates several concurrent control connections with different servers, and the media is synchronized in the transport layer. Record device control: The protocol controls the record and playback devices. Flow control and conference start separation: Only the meeting initialization protocol is required, or can be used to create a unique meeting identification number. In particular, SIP or H.323 can be used to invite server access. Suitable for professional applications: Time label via SMPTE, RTSP supports frame level accuracy, allowing remote digital editing demonstrations Neutral: The protocol does not have a special demonstration or metafile, can transmit the format type used; however, the presentation describes at least one RTSP URI. Agent and firewall friendly: The protocol can be processed by the application and transport layer firewall. The firewall needs to understand the setup method to open a "gap" for the UDP media stream. HTTP friendly: Here, RTSP is wise to use HTTP concept, so that the current structure can be reused. The structure includes an Internet Content Select Platform (PICS).
The RTSP is not only to the HTTP to add a method not only to the HTTP in most cases. Appropriate server control: If the user starts a stream, he must also stop a stream. Transfer coordination; before the actual processing of continuous media flow, the user can coordinate the transmission method. Performance Coordination: If the basic feature is invalid, there must be some cleaning mechanism to make the user decide that the method did not take effect. This allows users to propose suitable user interfaces. 6.3.1.3 Extending RTSP This is necessary to support different request sets because all media servers have the same function. RTSP can be extended in three ways, here to change the size: extension with new parameters. If the user needs to refuse notice, the method extension does not support, and the corresponding tag is added to the requirements. Join new methods. If the information recipient does not understand the request, return 501 error code (not implemented), the sender should not try this method again. Users can use the Options method to query the method of server support. The server uses a public response header to list the method of support. Define a new version protocol to allow all parts to be changed. (In addition to the protocol version number location) 6.3.1.4 Operating mode Each presentation and media stream can be identified using RTSP URL. The entire presentation with the media attribute is defined by the presentation description file. Use HTTP or otherwise users to get this file, it is not necessary to save on the media server. For explanation, it is assumed that the presentation describes a plurality of demonstrations, each of which maintains a common time axis. To simplify the description, and if you do not lose general, assume that the presentation describes the presentation. The presentation can contain multiple media streams. In addition to media parameters, network destination addresses and ports need to be decided. The following is different from several modes: unicast: Send the media to the RTSP request source with the port number selected by the user. Multicast, server selection address: Media server selects multicast addresses and ports, which is the way live broadcast or varies. Multicast, user selecting addresses: If the server adds the ongoing multicast conference, multicast address, port, and key are given by the conference description. 6.3.1.5 RTSP Status RTSP Control is independent of the stream transmitted by a separate protocol. For example, RTSP control can be connected via TCP, and the data stream is adopted by UDP. Therefore, the data will continue to send even if the media server does not receive requests. In the connection life, a single media stream can be controlled by different TCP connection sequences. Therefore, the server needs to maintain the connection status of the connection stream with the RTSP request. Many methods are independent of the state in the RTSP, but the following methods are important to define the allocation and application of the server flow resource: setup: Let the server give the stream allocation resource, start the RTSP connection. Play and Record: Start the data transfer of the SETUP allocation stream. Pause: Temporary stop stream without releasing server resources. TEARDOWN: Releases the resource of the stream, the RTSP connection stops. The RTSP method of the identity state uses the connection header to identify the RTSP connection, to respond to the SETUP request, the server connection generates the connection ID. 6.3.1.6 The relationship with other protocols is functionally overlap with HTTP, and the HTTP interaction is embodied in the initial contact with the stream content through the web page. The current protocol specification is to allow different transfer points between web servers and implementation RTSP media servers. For example, the demo description can be retrieved by HTTP and RTSP, which reduces the round trip delivery of the browser, and allows the independent RTSP server and the user to rely on HTTP. However, the essential difference between RTSP and HTTP is that the data is transmitted in different protocols. HTTP is an asymmetric agreement, the user issues a request, and the server responds.
In RTSP, media users and servers can issue requests, and their requests are stateless; they can set parameters for a long time after the request is confirmed, and the media stream can be controlled. The HTTP function is reused, at least two aspects, the security and proxy. It is very close to the HTTP function in cache, proxy, and authorization. When most real-time media use RTP as a transfer protocol, the RTSP is not bound to the RTP. RTSP assumes that there is a demo description format indicates a static and temporary property that contains several media streams. 6.3.2 Protocol parameters 6.3.3 RTSP information RTSP is a text-based protocol, using the ISO 10646 character set, using the UTF-8 coding scheme. The row is interrupted in CRLF, but the recipient itself can explain CR and LF to a row terminator. The text-based protocol is made easier to increase optional parameters in the self-description. Due to the number of parameters and the frequency of commands, the processing efficiency is not paying attention. If you carefully study, the text agreement is easy to implement research prototypes in scripting languages (such as: TCL, Visual Basic and Perl). 10646 Character Set Avoid sensitive character set switching, but it is invisible to applications. RTCP also uses this coding scheme. ISO 8859-1 characters with important sense bits indicate such as 10001x 10xxxxxx.. RTSP information can be carried by any low-level transport protocol. The request includes a method, method acting on the objects thereon and the parameters of the further description. The method can also be designed to require only small or no status maintenance on the server side. When the information body is included in the information, the information body length has the following factors: regardless of whether the entity head segment occurs in the information, the response information does not include the information of the information, and the first and space lines are at the end of the first and space lines. If the content length header appears, its value is based on byte, indicates the length of the information body. If the header is not appeared, its value is zero. The server is turned off. Note: RTSP currently does not support HTTP / 1.1 "block" transmission coding, requiring content length head. If you return an appropriate demo description length, even if it is dynamically generated, the block transmission coding is not necessary, the server should also determine its length. If there is an entity, even if there must be content length, and the length is not explicitly given, the rules ensure reasonable behavior. The request information from the user to the server includes the method, source ID, and the protocol version used in the first line. RTSP defines additional status code without defining any HTTP code. 6.3.4 Entity If an unqualified method or a response state encoding limit, request and response information can be transmitted, the entity consists of the physical header file and the test, and some responses only include the entity head. Here, depending on who sends an entity, who receives the entity, senders and recipients can refer to users and servers, respectively. The physical head defines the substantial optional elevational information, such as the resource that does not have a solid body, refers to the request identified. The extended head mechanism allows the additional entity header to be defined without changing the protocol, but these segments cannot assume that the recipient can identify. The unrecognizable head should be ignored by the recipient, and let the agent forward. 6.3.5 Connecting RTSP requests can be transmitted in several different ways: 1, persistent transmission connections for multiple request / response transmission. 2, each request / response transmission one connection. 3, no connection mode. The transmission connection type is defined by the RTSP URI. For the "RTSP" scenario, you need to continuous connection; and the "RTSPU" scheme calls the RTSP request to send without establishing a connection. Unlike HTTP, RTSP allows media servers to send requests to media users. However, this is only supported when persistent connections, otherwise the media server does not have a reliable way to reach the user, which is also the only way to pass the firewall from the media server to the user. 6.3.6 Method Defining Method Instructions Represents the method executed on the resource, which is case sensitive. The new method can be defined in the future, but cannot start with $.
