Author/source: unknown
Real-time transport protocols RTP and RTCP
RTP (Real-time Transport Protocol) is a transport protocol for multimedia data streams on the Internet. RTP is defined as working in the case of one-to-one or one-to-many transmission, with the purpose of providing time information and realizing stream synchronization. RTP usually uses UDP to transmit data, but RTP can also work on other protocols such as TCP or ATM. When an application starts an RTP session, it will use two ports: one for RTP and one for RTCP. RTP itself does not provide a reliable transmission mechanism for sequentially transmitting data packets, nor does it provide flow control or congestion control. It relies on RTCP to provide these services. Usually RTP algorithm is not implemented as an independent network layer, but as a part of application code. Real-time transmission control protocol RTCP Rtcp (Real-time transmission control protocol) and RTP jointly provide traffic control and congestion control services. During the RTP session, each participant regularly transmits RTCP packets. RTCP packets contain statistics such as the number of packets sent and the number of packets lost. Therefore, the server can use this information to dynamically change the transmission rate and even change the payload type. When RTP and RTCP are used together, they can optimize the transmission efficiency with effective feedback and minimum overhead, so they are especially suitable for transmitting real-time data on the Internet.
6.2. 1 RTP data transmission protocol
RTP provides end-to-end network transmission function, which is suitable for transmitting real-time data such as video, audio and simulation data through multicast and on-demand. RTP does not involve real-time services such as resource reservation and quality assurance, while RTCP extends data transmission to allow monitoring data transmission, providing minimal control and identification functions. RTP and RTCP are designed as independent transport layer and network layer.
2. 1. 1 RTP fixed head
The RTP header format is as follows:
-
|V=2|P|X| CC |M| PT | serial number |
-
time scale
-
Synchronous source identification (SSRC)
-
| Role Recognition (CSRC) |
|....|
-
The first 12 octet appears in each RTP packet, while the CSRC identification list only appears when the mixer is inserted.
2. 1.2 multi-channel RTP connection
In order to make the protocol work effectively, the number of multiplexing points should be minimized. In RTP, multiplexing is provided by defining the destination transmission address (network address and port number) of RTP connection. For example, in a teleconference where audio and video are encoded separately, each media is transmitted in a separate RTP connection and has its own destination transmission address. The goal is not to put audio and video in a single RTP connection, but to demultiplex according to the load type of SSRC segment. Using the same SSRC for different load types will bring several problems:
If the load type is switched during the connection, it is impossible to determine which old value will be replaced by the new value.
SSRC is define as a space for identifying a single time and sequence numb. If the media clock rate is different and different sequence number spaces are needed to explain which load type has packet loss, the cross-multiplexing load type will need different time spaces.
RTCP sending and receiving reports can only describe the time sequence and sequence number space of each SSRC, without carrying payload type segments.
RTP Mixer cannot merge incompatible media streams into one stream.
Carrying multiple media in RTP connection will prevent several things: using different network paths or network resource allocation; Accept a subset of media.
Using different SSRC for each medium, but using the same RTP connection to send can avoid the first three problems, but can't avoid the last two problems.
2.1.3 Modification of RTP header specific settings
It can be considered that all the application classes supported by RTP in the current RTP header are complete and have the required function set. However, in order to keep the ALF design principle, you can cut the title by changing or adding settings, and still allow irrelevant monitoring and recording tools to work. Tag bit and payload type segment carry specific setting information, but because many applications need them, otherwise, another 32-bit word will be added to accommodate them, so allocation in fixed headers is allowed. Octal containing these segments can be redefined by setting to meet different requirements, such as using more or less tag bits. If there is a flag bit, because the independent monitor can observe the relationship between the packet loss mode and the flag bit, we can locate the most important bit in octal.
Information required by other special payload formats (video coding) should be carried in the payload part of the data packet. Can appear at the beginning, always at the beginning of the loading section, or indicated in the reserved value of the data pattern. If the special application class needs additional functions of independent loading format, the setting of application operation should define additional fixed segments to follow the existing fixed head SSRC. These applications will be able to access additional segments quickly and directly, and at the same time, settings independent of monitors and recorders can still handle RTP packets by only interpreting them to start 12 octets. If it is confirmed that additional functions are required for all settings, then the new RTP should explicitly modify the fixed header.
6.2.2 Real-time Transport Protocol Control Protocol-RTCP
RTCP protocol sends control data packets to all connectors periodically, and applies the same distribution mechanism as data packets. Low-level protocols provide multiplexing of data and control packets, such as using a separate UDP port number. RTCP performs the following four functions:
Mainly to provide quality feedback of data release. As a part of RTP transport protocol, it is related to the flow and blocking control of other transport protocols. Feedback plays a direct role in adaptive coding control, but the experience of IP multicast shows that receiving feedback from the sender is very important for diagnosing transmission errors. By sending reception feedback reports to all participants, problem observers can evaluate whether these problems are local or global. Publishing mechanisms such as IP multicast enable network service providers to receive feedback information and act as third-party monitors to diagnose network problems. The feedback function is reported by RTCP sender and receiver.
RTCP carries the persistent transport layer identification of RTP source called canonical name (CNAME). If a conflict is found or the program restarts, because the identification of SSRC can be changed, the receiver needs CNAME to track the participants. The receiver also needs CNAME to contact several data streams given in the relevant RTP connection.
The first two functions require all participants to send RTCP packets, so the rate must be controlled in order to extend RTP to a large number. Let each participant send control packets to other participants, and then observe the number of participants independently. This quantizer calculates the rate at which packets are sent.
The fourth optional function is to transmit minimal connection control information, such as participant identification. It is most likely to be used in "loosely controlled" connections, in which participants can freely enter or leave without member control or parameter coordination. RTCP acts as a convenient channel for all participants, but it does not have to support all the control communication requirements of the application. Advanced connection control protocols are beyond the scope of this book.
When RTP is applied to IP multicast, the first three functions are necessary and recommended for all cases. RTP application designers must avoid using the mechanism that only works in unicast mode, which will lead to the inability to scale up.
RTCP packet format
Several RTCP packet types carrying different control information are defined as follows:
Service request:
Send a report to count the sending and receiving of the current active sender.
RR:
Receive reports, and inactive senders receive statistics.
SDES:
Source descriptors, including CNAME.
Goodbye:
Means the end.
Application:
Apply specific functions.
Similar to RTP packets, each RTCP packet starts with a fixed part, followed by a variable-length structural element, but ends with a 32-bit boundary. A length segment containing scheduling requirements and fixed parts, so that RTCP packets can be stacked. There is no need to insert any separator to connect Togo RTCP packets to form RTCP combined packets, which are sent in a single packet in a low-level protocol. There is no explicit count of individual RTCP packets in the combined packet because a lower layer protocol is needed to provide the total length to determine the end of the combined packet.
Each RTCP packet in the combined packet can be processed independently, and there is no need to combine the packets in sequence. However, in order to realize the protocol function, the following constraints are imposed:
As long as the bandwidth allows, the reception statistics (in the form of SR or RR) should be sent frequently, so the combined RTCP packet sent every cycle should include the report packet.
New recipients need to receive CNAME, determine the source as soon as possible, and start to contact the media for synchronization, so each package should contain SDES·CNAME.
What appears in front of the combined packet is the number of packet types, and its growth should be limited to increasing the number of constant bits to improve the probability of successfully identifying RTCP packets as RTP packets with wrong addresses or other irrelevant packets.
Therefore, all RTCP packets must be sent in the form of a combination of at least two packets, and the suggested format is as follows:
Encryption prefix:
Only when the combined packet is encrypted will a 32-bit random number be added for each combined packet transmission.
SR or RR:
The first RTCP packet in the combined packet must always report the packet, so as to facilitate the confirmation of the header. Even if no data is sent or received, an empty RR should be sent, even if the RTCP packet in the combined packet is BYE.
Additional RR:
If the number of reporting statistics sources exceeds 3 1, there should be additional RR packets after the initial reporting packet.
SDES:
SDES packages containing CNAME items must be included in each RTCP package. Other source descriptors are optional according to the needs of the application, but are limited by bandwidth.
Bye bye or APP:
Other RTCP packet types can be arranged in any order, except that BYE should be sent as the last packet, and these packet types can appear multiple times.
It is recommended that converters or mixers combine a single RTCP packet from multiple sources. If the total length of the combined packet exceeds the maximum transmission unit of the network path, it can be divided into several shorter combined packets and sent as a single packet using the lower layer protocol. Please note that each combined package must start with an SR or RR package. Other RTCP package types can be registered with the Internet Assigned Numbers Authority (iana).
6.2.2.2 RTCP transmission interval
RTP is designed to allow applications to expand automatically, and the number of connections can range from several to thousands. For example, audio conferencing, data traffic is limited, because only one or two people speak at the same time; For multicast, the data rate of a given connection is still constant, regardless of the number of connections, but the control flow has no inherent restrictions. If each participant sends and receives reports at a fixed rate, the control flow will increase linearly with the number of participants, so the rate must be reduced proportionally.
Once the address is confirmed as valid, if it is later marked as invalid, the status of the address should be maintained, and the address should continue to be included in the total number of addresses enjoying RTCP bandwidth for 30 minutes to ensure that typical network partitions can be scanned. Please note that this is still more than five times the maximum RTCP reporting interval.
In addition to the required CNAME, the specification also defines several source descriptors, such as NAME and email address. This is also a way to define a new application-specific RTCP packet type. Attention should be paid to allocating control bandwidth to additional information, because this will reduce the rate of receiving reports and CNAME transmission, and damage the performance of the protocol. It is suggested that the RTCP bandwidth allocated to a single participant for carrying additional information should not exceed 20%. Nor does it mean that all SDES projects are included in every application.
6.2.2.3 Sender and Receiver Reports
RTP receivers use RTCP report packets to provide reception quality feedback, and the report packets adopt one of two formats depending on whether the receiver is a transmitter or not. Except for the packet type code, the only difference between the sender report and the receiver report is that the sender report contains a 20-byte sender information segment. If an address sends a packet during the last or previous reporting interval, it will send out an SR; Otherwise, RR is issued; Both SR and RR may not have or include multiple received report blocks. Publishing reports are not applicable to active sources listed in the CSRC list, and each receiving report block provides statistics of data received from special sources. Because at most 3 1 received report blocks can be embedded in SR or RR packets,
The difference between the cumulative number of packets lost gives the number of packets lost in the interval, while the difference between the last serial number of the received extension gives the expected number of packets sent in the interval, and the ratio of the two is equal to the percentage of packets lost in the interval. If two reports are continuous, the ratio should be equal to the missing part; Otherwise, it won't wait. The number of packets lost per second, green, can be obtained by dividing the NTP time scale difference by the lost part.
From the sender information, the third-party monitor can calculate the average data rate of the load and the average packet rate of the unreceived data interval, and the ratio of the two gives the average load size. If it is assumed that packet loss is independent of packet size, the number of packets received by a specific receiver gives the apparent traffic received by that receiver.
6.2.2.4 sdes: source description RTCP package
SDES packet is a three-layer structure, which consists of a header and a data block. There may be no data block, or there may be multiple data blocks, and the component describes the source indicated by the data block. The project is described as follows:
Version (v), padding (p), length:
As described in the SR package.
Package type (PT):
8 bits, including the constant 202, are used to identify RTCP SDES packets.
Source count (SC):
5 bits, the number of SSRC/CSRC blocks contained in the SDES packet, and a value of zero is valid but meaningless.
The content of the source descriptor is as follows:
CNAME: standard terminal identification SDES project
CNAME identity attributes are as follows:
In case of conflict or program restart, because randomly assigned SSRC identifiers may change, CNAME entries are needed to provide binding from SSRC identifiers to source identifiers that are still constant.
Like the SSRC flag, the CNAME flag should be unique among all participants in an RTP connection.
In order to provide a set of bindings between multimedia tools used by participants in related RTP connections, CNAME should be fixed as the participant.
In order to facilitate third-party monitoring, CNAME should be suitable for procedures or personnel to locate sources.
Name: user name SDES project
This is the real name used to describe the source, such as "John Doe, Bit Recycler, MegaCorp", but it can be in any form that users want. For an application such as a conference, this name may be the most appropriate form to display the list of participants, and it will be the most frequently sent item besides CNAME. Settings can establish such priorities. At least during the connection, the name value should remain the same. It should not be the only dependency between all participants in the connection.
E-mail: e-mail address SDES project
RFC822 specifies the format of e-mail addresses, such as "John. Doe@megacorp.com\ "。 E-mail still wants to remain unchanged during the connection.
Phone: phone number SDES entry
The phone number should have a plus sign, not an international access code. For example, "+19085551212" is the telephone number in the United States.
LOC: user geographic location SDES project
Depending on the application, this item has different levels of detail. For conferencing applications, a string like "Murray Hill, New Jersey" is enough. However, for active marking systems, such as "Room 2A244, at & amp； T BL MH "may apply. Details are left to the implementer or user, but the format and content can be indicated by setting. During the connection, except for the mobile host, the LOC value should remain unchanged.
Tool: application or tool name SDES project
A string representing the name and version of the application that generated the stream, such as "videotool 1.2". This information is useful for debugging, similar to the SMTP header of the mail or mail system version. The tool values remain unchanged during the connection process.
Note: Notification/Status SDES entry
The recommended syntax for this project is as follows, but these or other grammars can be clearly defined in the settings. The NOTE item is designed to describe the conversion information of the current state of the source, such as "on the phone, is it ok?" T talk\ ",or used to convey the topic of conversation in lectures. It should only be used to carry abnormal information and should not be included in all participants, because it will slow down the speed of receiving reports and sending CNAME, thus damaging the performance of the protocol. Under special circumstances, it should not be used as an item of user profile, and it is not automatically generated.
When it is active, because note items are very important for display, the transmission rate of other non-CNAME items (such as names) will decrease, resulting in note items occupying part of RTCP bandwidth. If the conversion information is not activated, the note item will continue to be sent several times at the same speed, but the receiver will receive a string notification with zero string length. However, if a small multiple repetition or an interval of about 20-30 RTCP is not received, the receiver should also consider the note item invalid.
PRIV: entrance of private extension SDES
This item is used to define an experimental or application-specific SDES extension, which includes a prefix consisting of long string pairs, followed by a string value that fills the rest of the item and carries the required information. The prefix length segment is 8 bits. The prefix string is the name chosen by the person who defines the PRIV item, and only corresponds to other PRIV items received by the application. Application implementers can choose to use the application name and add an additional subtype identifier if necessary. In addition, it is suggested that others choose names according to the entities they represent, and then coordinate the use of names within the entities.
Please note that the prefix takes up some space, with a total length of 255 octets, so the prefix should be as short as possible. The device and the limited RTCP bandwidth should not be overloaded, and its purpose is not to meet all control communication requirements of all applications. SDES PRIV prefix is not registered in IANA. If some forms of PRIV items prove to be universal, IANA should assign them a formal SDES item type, so that the prefix is no longer needed. This simplifies the application and improves the transmission efficiency.
Goodbye in 6.2.2.5: Disconnect RTCP package.
If the mixer receives the BYE packet, the mixer forwards the BYE packet without changing the SSRC/CSRC identifier. If the mixer is turned off, it should also send out a BYE packet listing all the sources it processes, not just its own SSRC identifier. As an option, the BYE packet can include an 8-bit octal count followed by many octal texts indicating the reason for leaving, such as "camera failure" or "RTP loop detected". Strings have the same encoding, as described by SDES. If the string fills the packet to the lower 32-bit boundary, the string will not end in null; Otherwise, the BYE packet will be filled with empty octets.
6.2.2.6 application: defines the RTCP package of the application.
APP packages are used to develop new applications and experiments with new features, and there is no need to register package type values. Application packages with unrecognized names should be ignored. After testing, if it is determined that it is widely used, it is suggested to redefine each APP package without registering subtypes and name segments with IANA.
Real-time streaming protocol RTSP
RTSP(RealTimeStreamingProtocol) is composed of RealNetworks and Netscape***, which defines how one-to-many applications can effectively transmit multimedia data through IP networks. RTSP is higher than RTP and RTCP in architecture, and it uses TCP or RTP to complete data transmission. Compared with RTSP, HTTP transmits HTML while RTP transmits multimedia data. HTTP request is sent by the client, and the server responds; When using RTSP, both the client and the server can make requests, that is, RTSP can be bidirectional.
6.3 RTSP protocol
Real-time streaming protocol (RTSP) is an application layer protocol that controls real-time data transmission. RTSP provides an extensible framework, which makes it possible to control and order real-time data, such as audio and video. The data source include field data and data stored in clip. The purpose of this protocol is to control multiple data transmission connections, provide a way to select transmission channels, such as UDP, multicast UDP and TCP, and provide a way to select transmission mechanisms based on RTP.
6.3. 1 Introduction
6.3. 1. 1 purpose
Real-time streaming protocol (RTSP) establishes and controls one or more time-synchronized continuous streaming media. Although it is possible for a continuous media stream to traverse the control stream, it usually does not send the continuous stream itself. In other words, RTSP acts as the network remote controller of the multimedia server. RTSP connections are not bound to transport layer connections, such as TCP. During the RTSP connection, RTSP users can open or close multiple reliable transmission connections to the server to issue RTSP requests. In addition, a connectionless transport protocol such as UDP can be used. RTP can be used for RTSP flow control, but RTSP operation does not depend on the transmission mechanism for transmitting continuous media. Real-time streaming protocol is similar to HTTP/ 1. 1 in syntax and operation, so RTSP can be added to most extension mechanisms of HTTP. The operations supported by this protocol are as follows:
To retrieve media from a media server:
Users can submit presentation descriptions through HTTP or other methods. If the presentation is multicast, the presentation includes the multicast address and port of continuous media. If the presentation is only sent to the user by unicast, the user should provide the destination address for security reasons.
Media servers invited to the meeting:
The media server can be invited to attend an ongoing meeting, or play back the media, or record part or all of the content. This mode is very useful in the application of distributed education. In the meeting, several parties can take turns to press the remote control button.
Add media to a ready-made lecture:
This is especially useful for live lectures if the server tells users that additional media content is available. Similar to HTTP/ 1. 1, RTSP requests can be handled through proxies, channels and caches.
6.3. 1.2 protocol features
The characteristics of RTSP are as follows:
Scalability:
New methods and parameters can be easily added to RTSP.
Easy to parse:
RTSP can be parsed by standard HTTP or MIME parsers.
Security:
RTSP uses web page security mechanism.
Transmission independent:
RTSP can use Unreliable Datagram Protocol (UDP) and Reliable Datagram Protocol (RDP). In order to achieve application-level reliability, reliable streaming protocols can be used.
Multi-server support:
Each stream can be placed on a different server, and the client automatically establishes several concurrent control connections with different servers, and media synchronization is carried out at the transport layer.
Recording device control:
This protocol can control recording and playback devices.
Separation of flow control and conference start;
Only the conference initialization protocol is needed, or it can be used to create a unique conference identification number. Under special circumstances, SIP or H.323
Can be used to invite servers to join.
Suitable for professional applications:
Through SMPTE timescale, RTSP supports frame-level accuracy and allows remote digital editing.
Presentation description neutral:
The protocol does not impose special presentations or metafiles, and can transmit the used format types; However, the presentation description must contain at least one RTSP URI.
Proxy and firewall friendliness:
Protocols can be handled by applications and transport layer firewalls. Firewall needs to know the setting method and open a "gap" for UDP media stream.
HTTP friendly:
Here, RTSP wisely adopted the concept of HTTP, so that the current structure can be reused. The structure includes Internet Content Selection Platform (PICS). Because in most cases, controlling continuous media requires server state, RTSP does not just add methods to HTTP.
Appropriate server control:
If a user starts a stream, he must or can stop a stream.
Transmission coordination;
Before the continuous media stream is actually processed, users can coordinate the transmission methods.
Performance coordination:
If the basic features are invalid, there must be some cleaning mechanism for users to decide which method is invalid. This allows the user to present an appropriate user interface.
6.3. 1.3 Extended RTSP
Because not all media servers have the same function, it is necessary for media servers to support different request sets. RTSP can be extended in the following three ways, here in order of size:
Extend with new parameters. If the user needs to reject the notification, but the method extension does not support it, the corresponding tag is added to the required segment.
Add a new method. If the information receiver does not understand the request and returns the error code 50 1 (not yet implemented), 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.
Define a new version of the agreement, allowing all parts to be changed. (Except for the position of protocol version number)
6.3. 1.4 operation mode
Each presentation and media stream can be identified by RTSP URL. The entire presentation and media properties of the presentation are defined by the presentation description file. Users can get the file by using HTTP or other means without saving it on the media server.
For example, suppose the presentation description describes multiple presentations, and each presentation maintains a common * * * timeline. For the sake of simplicity and generality, it is assumed that the description of the demonstration does contain such a demonstration. A presentation can contain multiple media streams. In addition to the media parameters, it is also necessary to determine the network destination address and port. Several modes of operation are distinguished as follows:
Unicast:
Use the port number selected by the user to send the media to the RTSP request source.
Multicast, server chooses address:
The media server chooses multicast address and port, which is a common way of live broadcast or quasi-on-demand.
Multicast, user-selected address:
If the server joins an ongoing multicast conference, the multicast address, port and key are given by the conference description.
RTSP status
RTSP controls the traffic sent through a separate protocol, regardless of the control channel. For example, RTSP control can be connected through TCP, while data flow is through UDP. Therefore, even if the media server does not receive the request, the data will continue to be sent. During the lifetime of a connection, a single media stream can be controlled by issuing requests in different TCP connection orders. Therefore, the server needs to maintain the connection state that can contact streams and 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:
Settings:
Let the server allocate resources to the stream and start RTSP connection.
Play and record:
Start setting up data transmission of distribution stream.
Pause:
Temporarily stop the stream without releasing server resources.
Dismantle:
Release the resources of the stream, and the RTSP connection stops.
The RTSP method for identifying the state uses the connection header to identify the RTSP connection. In response to the setup request, the server connects
And then generate a connection identifier.
6.3. 1.6 Relationship with other agreements
RTSP overlaps with HTTP in function, and the interaction with HTTP is reflected in that the initial contact with streaming media content is through web pages. The current protocol specification aims to allow different delivery points between web servers and RTSP media servers. For example, presentation descriptions can be retrieved through HTTP and RTSP, which reduces the round-trip delivery of browsers and allows independent RTSP servers and users not to rely entirely on HTTP.
However, the essential difference between RTSP and HTTP is that data transmission is carried out in different protocols. HTTP is an asymmetric protocol. The user sends a request and the server responds. In RTSP, both media users and servers can make requests, and their requests are stateless. For a long time after requesting confirmation, you can still set parameters to control the media stream. Reusing HTTP functions has advantages in at least two aspects, namely, security and proxy. The requirements are very close, so it is very valuable to use HTTP function in caching, proxy and authorization.
When most real-time media use RTP as the transmission protocol, RTSP is not bound by RTP. RTSP assumes that there is a representation description format, which can represent the static and temporary properties of representations containing several media streams.
protocol parameter
RTSP information
RTSP is a text-based protocol, which adopts UTF 8 coding scheme and ISO 10646 character set. The line is interrupted by CRLF, but the receiver itself can interpret CR and LF as line terminators. Text-based protocols make it easier to add optional parameters in a self-describing way. Because the number of parameters and the frequency of commands are low, the processing efficiency is not noticed. If carefully studied, text protocols can be easily prototyped in scripting languages such as Tcl, Visual Basic and Perl.
The 10646 character set avoids switching sensitive character sets, but it is used to say invisible. RTCP also adopts this coding scheme. The signified 108859-1symbol is10001x10xxxxxxxxx. Any low-level transport protocol can carry RTSP information.
The request includes the method, the object that the method acts on, and the parameters that further describe the method. This method can also be designed to require little or no state maintenance on the server side. When the information body is included in the information, the length of the information body is determined by the following factors:
No matter whether the entity title appears in the message or not, the response message excluding the message body always ends with the first line and blank line after the title.
If the content length header appears, its value is in bytes, indicating the length of the information body. If the title does not appear, its value is zero.
The server closed the connection.
Note: RTSP currently does not support HTTP/ 1. 1 "block" transmission coding, and requires a content length header. If a moderate representation description length is returned, the server should be able to determine its length, even if it is dynamically generated, and make block transmission coding unnecessary. If there is an entity, even if there must be a content length, and the length is not clearly given, the rule can ensure that the behavior is reasonable.
The request information from the user to the server includes the method adopted by the source, the source identification and the protocol version used in the first line. RTSP defines additional status codes, but does not define any HTTP codes.
6.3.4 Entities
If it is not limited by the request method or response status code, the request and response information can be transmitted to the entity, which consists of entity header files and test questions, and some responses only contain entity headers. Here, according to who sends the entity and who receives the entity, the sender and the receiver can refer to the user and the server respectively.
The entity header defines the optional meta-information of the entity. If there is no entity, it refers to the resource requested to be identified. The extended header mechanism allows additional entity header segments to be defined without changing the protocol, but these segments cannot be considered recognizable by the receiver. Unrecognized headers should be ignored by the receiver and forwarded by the proxy.
connect
RTSP requests can be sent in several different ways:
1, persistent transmission connection, used for multiple request/response transmission.
2. Each request/response transmits a connection.
3. Connectionless mode.
The transport connection type is defined by RTSP URI. For "rtsp" scheme, continuous connection is required; "rtspu" scheme calls RTSP request sending without establishing connection.
Unlike HTTP, RTSP allows media servers to send requests to media users. However, this is only supported if the connection is persistent, otherwise the media server has no reliable way to reach the user, which is the only way to transmit the request from the media server to the user through the firewall.
Method definition
The method tag indicates the method executed on the resource, which is case-sensitive. You can define new methods in the future, but you can't start with $.
Some firewall designs and their relationships
References:
/
This website has a download method.
You can go and have a look.