| RTP (Real-timetransportprotocol) is a transmission protocol for multimedia data streams on the Internet. RTP is defined to work during one-to-one or one-to-many transmission. It aims to provide time information and implement 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 a RTP session, two ports are used: one for RTP and the other for RTCP. RTP itself does not provide a reliable transmission mechanism for transmitting data packets in sequence, nor does it provide traffic control or congestion control. It relies on RTCP to provide these services. Generally, the RTP algorithm is not implemented as an independent network layer, but as part of the application code. Real-time transmission control protocol RTCP. RTCP (Real-timetransportcontrolprotocol) and RTP provide traffic control and congestion control services. During the RTP session, each participant periodically transmits the RTCP package. The RTCP package contains statistics such as the number of sent data packets and the number of lost data packets. Therefore, the server can use this information to dynamically change the transmission rate or even the payload type. RTP and RTCP can be used together to optimize transmission efficiency with effective feedback and minimal overhead. Therefore, RTP is particularly suitable for transmitting real-time online data. 6.2.2 RTP control protocol-RTCP
The RTCP protocol sends the control package cycle to all connectors, and the distribution mechanism of the application and the data packet is the same. The low-Layer Protocol provides the reuse of data and control packets, such as using a separate UDP port number. RTCP performs the following four functions:
It mainly provides quality feedback on data publishing. It is part of the RTP transmission protocol and is related to the stream and blocking control of other transmission protocols. Feedback directly applies to adaptive encoding control, but the experience of IP multicast shows that it is important to diagnose sending errors when feedback is received from the sender. Send a receiving feedback report to all participants to allow the problem observer to estimate whether the problem is local or global. Publishing mechanisms such as IP multicast allow network service providers and groups to receive feedback and act as third-party monitors to diagnose network problems. The feedback function is reported by the RTCP sender and receiver.
RTCP carries the RTP source persistent transport layer identifier known as the canonical name (cname. In the event of a conflict or Program Restart, since the SSRC identifier can be changed, the recipient needs a cname to track the participants. The receiver also needs to connect the cname with several data streams specified in the relevant RTP connection.
The first two features require all participants to send RTCP packets. Therefore, the rate must be controlled to scale RTP To a large number. Each participant is allowed to send a control package to other participants to observe the number of participants independently. This number of terms calculate the packet sending rate.
The fourth optional function is to transmit the minimum connection control information, such as participant identification. It is most likely to be used in a "loose control" connection where participants enter or leave freely without member control or parameter coordination. RTCP acts as a convenient channel to all participants, however, it does not need to support all control communication requirements of applications. The advanced Connection Control Protocol is beyond the scope of this book.
When using RTP in IP multicast scenarios, the first three features are required. We recommend that you use them in all scenarios. RTP Application designers must avoid using a mechanism that only works in Unicast mode, which will lead to scalability.
6.2.2.1 RTCP package format
The following defines several RTCP Package Types carrying different control information:
SR:
Send reports. Statistics on sending and receiving of current active senders are displayed.
Rr:
Receive reports, statistics on inactive senders.
Sdes:
Source description, including cname.
Bye:
End.
APP:
Apply specific functions.
Similar to RTP data packets, each RTCP packet starts with a fixed part, followed by a variable-length structure element, but ends with a 32-bit border. Includes arrangement requirements and fixed part length segments to enable the RTCP package to stack. You do not need to insert any separator to connect the Togo RTCP package to form an RTCP package and send it out with a single package as a low-level protocol. Because the low-level protocol provides the overall length to determine the end of the package combination, no single RTCP package is explicitly counted in the combination package.
Each RTCP package in the package can be processed independently without the need to follow the package combination sequence. However, the Protocol function is not executed and the following constraints are imposed:
Receiving statistics (in Sr or RR) should be sent frequently. As long as the bandwidth permits, the RTCP package sent in each cycle should contain a report package.
The new receiver needs to receive the cname, identify the source as soon as possible, and contact the media for synchronization. Therefore, each package should contain the sdes cname.
The number of packages that appear before the combination package is the number of packages. The increase should be limited to increase the number of common digits and increase the probability of successfully confirming that the RTCP package is correct for RTP packets or other irrelevant packets.
Therefore, all RTCP packages must be sent in a combination of at least two packages. the recommended format is as follows:
Encryption Prefix ):
Only when the combination package is encrypted, a 32-bit random number is added for each combination package to send.
Sr or RR:
The first RTCP package in the combination package must always be a report package for header validation. Even if no data is sent and no data is received, an empty RR is sent, which means the RTCP package in the package is bye.
Additional RR:
If the number of statistical sources exceeds 31, additional RR packages should be added after the initial report package.
Sdes:
The sdes package containing the cname item must be included in each combined RTCP package. If required by the application, other source descriptions are optional, but restricted by bandwidth.
Bye or app:
Other RTCP package types can be arranged in any order, except that bye should be sent as the last package. The package type can appear more than once.
It is recommended that the converter or mixer combine a single RTCP package from multiple sources. For example, if the overall length of a package exceeds the maximum transmission unit of the network path, the package can be divided into multiple shorter packages and sent as a single package in the form of a Low-layer protocol. Note that each package must start with an SR or RR package. The additional RTCP package type can be registered at Internet Assigned Numbers Authority (IANA.
6.2.2.2 RTCP Transmission Interval
RTP is designed to allow automatic application scaling. The number of connections can range from several to thousands. For example, in an audio conference, data traffic is limited internally because only one or two people speak at the same time. For multicast, the data rate of a given connection is still constant, independent of the number of connections, however, traffic control is not limited internally. If each participant sends a receipt report at a fixed rate, the control traffic will linearly increase with the number of participants. Therefore, the rate must decrease proportionally.
Once the address is confirmed to be valid, if it is marked as inactive, the address status should be retained and the address should be included in the total number of shared RTCP bandwidth addresses. The time should ensure that the typical network partition can be scanned, it is recommended to be 30 minutes. Note that this is still five times the maximum RTCP report interval.
This specification defines several source descriptions except the required cname, such as name (person name) and email (email address ). It also defines the RTCP package type for the new feature. Attention should be paid to allocating control bandwidth to additional information because it will reduce the rate of receiving reports and sending cname, compromising protocol performance. It is recommended that the RTCP bandwidth allocated to a single participant for carrying additional information not exceed 20%. It does not intentionally include all sdes in each application.
6.2.2.3 sender and receiver report
The RTP receiver uses the RTCP report package to provide quality feedback. The report package uses either of the two formats based on whether the receiver is the sender or not. In addition to the package 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 data packets during the last or previous report interval, the SR will be published; otherwise, the RR will be issued; the SR and RR may not or contain multiple receiving report blocks. The release report is not the source of the function column on the CSRC list. Each receiving report block provides statistics on the data received from a special source. Since up to 31 receiving report blocks can be embedded in the SR or RR package,
The progressive count difference of lost packets indicates the number of dropped packets during the interval, and the difference in the last serial number of received extensions indicates the number of packets to be sent during the interval. The ratio of the two is equal to the percentage of packet loss during the interval. If the two reports are continuous, the ratio should be equal to the loss segment; otherwise, it will not wait. Packet Loss per second can be obtained by dividing the NTP time difference by the loss part.
Based on the sender information, a third-party monitor can calculate the average packet rate between the average load data rate and the average packet rate without receiving data. The ratio of the two shows the average load size. If the packet loss is not related to the packet size, the number of packets received by the special recipient gives the apparent traffic received by the recipient.
6.2.2.4 sdes: source description RTCP package
The sdes package is a three-tier structure consisting of a header and a data block. There can be no or multiple data blocks. The component describes the source indicated by the block. Description:
Version (V), fill (P), length:
As described in the SR package.
Package Type (PT ):
8 bits, containing a constant of 202, identifies the RTCP sdes package.
Source count (SC ):
The number of SSRC/CSRC blocks in the sdes package. The value 0 is valid, but it makes no sense.
The source description is as follows:
Cname: sdes entry for standard terminal identity
The cname attributes are as follows:
In the event of a conflict or restart of the program, because the randomly assigned ssrc id may change, the cname item must be provided to bind the source ID from the ssrc id to the constant.
Like the SSRC identifier, the cname identifier must be unique among all the participants of the RTP connection.
To provide a set of cross-multimedia tools used by a participant in the RTP connection, the cname should be fixed as the participant.
To facilitate third-party monitoring, cname should be suitable for programs or personnel to locate the source.
Name: User Name sdes item
This is the real name used to describe the source, such as "John Doe, bit recycler, comment Corp", but the user wants any form. For applications such as meetings, this name may be the most suitable form for displaying the List of participants. It will be the most frequently sent item except the cname. You can set this priority level. The name value remains constant at least during the connection. It should not be the only dependency among all connected participants.
Email: email address sdes entry
The mail address format is specified by rfc822, such as "John.Doe@megacorp.com ". During the connection, emails still want to be constant.
Phone: telephone number sdes
The telephone number should carry a plus sign instead of the international access code. For example, "+ 1 908 555 1212" indicates the American phone number.
Loc: The sdes entry of the user's geographic location.
Depending on the application, this item has different degrees of detail. For meeting Applications, strings such as "Murray Hill, New Jersey" are enough. However, for the activity tag system, strings such as "room 2a244, at&t bl mh" may be applicable. The details are left to the implementation or user, but the format and content can be set with instructions. During the connection, the LOC value is expected to remain as a constant except for moving the host.
Tool: application or tool name sdes item
Is a string that indicates the name and version of the application that generates the stream, such as "videotool 1.2 ". This part of information is useful for debugging, similar to the mail or mail system version SMTP header. The tool value remains constant during the connection.
Note: Notification/status sdes item
The recommended syntax for this item is described below, but these or other syntaxes can be explicitly defined in the settings. The note item is intended to describe the Transition Information of the current state of the source, such as "on the phone, can't talk", or the topic used to transmit the conversation during the lecture. It should only be used to carry exception information and should not be included in all participants, because it will reduce the speed of receiving reports and sending cname, thus compromising the performance of the Protocol. In special circumstances, it should not be used as a project for setting files for users, nor is it automatically generated.
Note items are very important to display when they are active, and the transmission rate of other non-cname items (such as name) will decrease. As a result, note items occupy part of RTCP bandwidth. If the transition information is inactive, the note item continues to be sent several times at the same speed, but notifies the recipient with a string of zero length. However, if you do not receive a duplicate of a small multiple or an RTCP interval of about 20-30, the recipient should also consider that the note item is inactive.
Priv: dedicated extension sdes item
This item is used to define the lab or application-specific sdes extension. It includes a prefix consisting of long string pairs, followed by a string value that fills the other part of the item and carries the required information. The prefix length is 8 bits. A prefix string is the name selected by the person who defines the priv item. It uniquely corresponds to other priv items received by the application. The application implementer can select the application name, and add a child type ID if necessary. In addition, it is recommended that others select names based on the entities they represent, and then coordinate the use of names within the entities.
Note that prefix consumes some space with a total length of 255 octal items. Therefore, the prefix should be as short as possible. The bandwidth of this device and the restricted RTCP should not be overloaded, and its purpose is not to meet all control communication requirements of all applications. The sdes priv prefix is not registered in IANA. If it is confirmed that some forms of priv items are universal, IANA should assign it a formal sdes item type, so that the prefix is no longer needed. This simplifies the application and improves the transmission efficiency.
6.2.2.5 bye: disconnect the RTCP package
If the mixer receives a bye packet, the mixer forwards the bye packet without changing the SSRC/CSRC identifier. If the mixer is off, it should also issue a bye package to list all the sources it handles, not just its own SSRC identifier. As an option, the bye package can contain an 8-bit octal counter followed by many octal texts, indicating the reason for leaving, such as "camera malfunction" or "RTP loop detected ". The string has the same encoding, as described in sdes. If the string padding package reaches the bottom 32-bit boundary, the string will not end with an empty string; otherwise, the bye package will be filled with an empty octal array.
6.2.2.6 app: Define the RTCP package of the application
The app package is used to develop new applications and new features. You do not need to register the package type value. Apps with unrecognized names should be ignored. After the test, if it is determined that the application is widely used, we recommend that you redefine each app package without registering the subtype and name segment with IANA. |
