If the X-bit of the RTP Header is 1, "must" append a Variable Length header extension after the possible CSRC list of the RTP Header. The header extension contains 16-bit length fields that provide the number of 32-bit characters in the extended header except the first 4 bytes (So 0 is valid ). A maximum of one extension header can be appended to the RTP Header. In order to allow multiple interoperability for independent testing of different header extensions, or to allow a specific implementation of additional header extensions, the header 16 bits of the header extension are reserved as differentiated identifiers or parameters. The 16-bit format will be defined by the policy specifications used by specific implementations. The RTP specification does not define any header extensions.
6. RTP control protocol-RTCP
The RTP Control Protocol (RTCP) periodically sends control packets to all participants in the session, using the same distribution mechanism as the data packets. The lower-layer protocol must provide multiple workers for data packets and control packets, for example, using different UDP ports. RTCP provides four functions:
(1) The basic function is to provide feedback on the quality of data transmission. This is part of RTP as a transport protocol and is associated with traffic and congestion control for other transport protocols (see section 10th for congestion control requirements. Feedback can be directly used for adaptive coding []. The experiment of IP multicast also shows that it is the key to get feedback information from the receiver to diagnose transmission faults. Sending receiving feedback to all members enables "observers" to assess whether the problem is local or global. Similar to the IP multicast distribution mechanism, some entities, such as network service providers that do not join sessions, receive feedback and act as third-party monitors for network fault diagnosis. The feedback feature is provided through the RTCP transmitter and receiver report, as described in Section 6.4.
(2) RTCP carries a persistent transport layer identifier for each RTP source, known as a regular name or cname. For details, see Section 6.5.1. Because SSRC may change in case of a conflict or program restart, the receiver requires the cname to track each member. The receiver may also use cname to associate multiple data streams from the same Member in a series of related RTP sessions, such as synchronous speech and image. Inter-media synchronization also requires that the data sender include NTP and RTP timestamps in its RTCP package.
(3) The first two functions require all members to send RTCP packets. Therefore, the speed must be controlled so that the number of RTP session members can be expanded to a large number. By sending a control package to all members, each member can independently observe the number of members in the session. This number is used to calculate the packet sending rate. For details, see section 6.2.
(4) The fourth optional function is to transmit a small amount of session control information, such as the member ID displayed on the user interface. This is most likely to play a role in "loose control" sessions. In a "loose control" session, a member can join or quit the session without passing through the qualification control and parameter negotiation. RTCP is a convenient way to contact all Members, but do not expect it to support all the control information transfer requirements required by a specific application. This may require a high-level session control protocol out of the scope of this document.
Functions 1-3 should be used in all environments, especially IP Multicast Environments. The RTP Application Designer "should" avoid using the unicast mode only, which will make the number of Members not scalable. In the case of a one-way link similar to the receiver feedback that is not feasible, the sender and receiver "may" independently control the transmission of RTCP (as described in section 6.2 ).
Informal annotation: In the multicast routing mode called source-specific multicast (SSM), each channel (Source Address, group address pair) has only one sender, in addition, the receiver (except the channel source) cannot use multicast to contact other channel members. In this section, we recommend that you simply disable the receiver RTCP in section 6.2 to adapt to the SSM. In the future, RTCP will be adjusted for SSM to maintain receiver feedback.
6.1 RTCP Message format
This specification defines multiple RTCP message formats to carry different control information:
SR: The Sender report, which describes the sending and receiving statistics of active senders.
Rr: receiver report, which describes the inactive transmitter member or used together with the SR to describe the receipt statistics of the active Transmitter
Sdes: source description, including cname
Bye: indicates that participation is terminated.
APP: Application-related functions
Each RTCP packet starts with a Fixed Header similar to the RTP data packet, followed by a structured unit. It may have different lengths depending on the packet type, but it is always terminated at a 32-bit boundary. Alignment requirements and length fields enable the RTCP package to "stack ". Multiple RTCP packages can be spliced into a composite RTCP package without any interval and sent in a lower-layer protocol (such as UDP. The number of independent RTCP packages is not explicitly given in the composite package, because the underlying protocol provides an overall length to indicate the end of the composite package.
Each RTCP single package in a composite package can be processed independently without considering the order of packages or Package Combinations. However, to implement certain protocol functions, add the following restrictions:
-Receive statistics (Sr or RR) should be sent as long as the bandwidth limit permits, to maximize the resolution of statistics. Therefore, each periodically sent RTCP package must contain a report package.
-The new receiver needs to receive a source cname as quickly as possible to identify the source and start related media for purposes such as lip-sync. Therefore, each composite RTCP package must also include the sdes cname unless the composite RTCP package is split and partially encrypted as described in section 9.1.
-You must limit the number of possible types of the first package in the composite package to increase the number of common bits in the first word, you can also increase the possibility of successfully verifying the validity of the RTCP package to distinguish the mistaken RTP package or other irrelevant packages.
Therefore, all RTCP packages must be transmitted in a composite package containing at least two single packages, with the following recommended formats:
Encrypted Prefix: When and only when the composite package is encrypted according to section 9.1, a random 32-bit prefix is added to each RTCP composite package. If encryption requires filling, fill in the "must" to add to the last package of the composite package.
Sr or RR: The first RTCP package in the composite package must be a report package for header verification described in Appendix A.2. Even if no data is sent or received, an empty RR package is "required" or another unique package in the composite package is a bye package.
Additional RR: if the number of reported receiving statistical sources exceeds the maximum 31 allowed for one Sr/RR package, the additional RR package "should" follow the original report package.
Sdes: each composite RTCP package "must" include an sdes package containing cname items, unless otherwise specified in section 9.1. If the application requires a bandwidth limit (see section 6.3.9), you can provide other source descriptions.
Bye or app: Other RTCP package types, including those defined in the future, can be in any order, except that bye should be the last package for a given SSRC/CSRC. The same package type can appear more than once.
To properly estimate the RTCP bandwidth of each parameter (see section 6.2), An RTP participant "should" send only one composite RTCP packet at each report interval, unless the RTCP package is partially encrypted according to section 9.1. If the number of sources is too large to put all the required RR into a single RTCP package without exceeding the maximum transmission unit (MTU) in the network path ), then, each interval "should" only add a portion of the MTU to the composite package. This subset should be selected cyclically at multiple intervals to report all sources.
It is recommended that the converter and mixer combine an independent RTCP packet forwarded from multiple sources into a composite packet to distribute packet overload whenever possible (see section 7th ). Figure 1 shows an example of an RTCP composite package that may be generated by a mixer. If the total length of a composite package is the MTU of the operating network, it should be split into multiple shorter composite packages for transmission in the lower-Layer Protocol Independent packages. This does not damage the RTCP bandwidth estimation because each composite package represents at least one different participant. Note that each composite package "must" Start with an SR or RR package.
An Implementation "should" ignore RTCP packages that cannot recognize the type. Other RTCP package types may be registered to IANA as described in section 15th.
If encrypted: Random 32-bit integer
|
| [--------- Packet --------] [---------- packet ----------] [-packet-]
|
| Receiver chunk
V reports item
--------------------------------------------------------------------
R [SR # sendinfo # Site1 # Site2] [sdes # cname Phone # cname loc] [bye # Why]
--------------------------------------------------------------------
|
| <----------------------- Compound packet -----------------------> |
| <-------------------------- UDP packet -------------------------> |
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound Packet
6.2 RTP Transmission Interval
RTP is designed to allow an application to automatically expand the session size from a small number of participants to thousands. For example, the data traffic in an audio conference is self-restricted. Because only one or two people speak at the same time, the multicast data rate on any given link remains unchanged relative to the number of participants. However, traffic control is not self-restricted. If each participant sends a receiving report at a constant rate, the control information traffic will linearly increase with the number of participants. Therefore, you must dynamically calculate the RTCP packet transmission interval to reduce the transmission rate.
For each session, assume that the data traffic depends on the total limit shared by the participant, called "session bandwidth. This bandwidth may be retained by the network. If it is not retained, it may be dependent on other constraints of the environment to set the "reasonable" maximum bandwidth for this session, which is the session bandwidth. The session bandwidth may be selected based on the price of the session or the knowledge of available network bandwidth. This is irrelevant to Media Encoding to some extent, but the session bandwidth may limit the encoding selection. The session bandwidth is often the sum of the Nominal nominal bandwidth of the active sender. For teleconference audio, this number is generally the bandwidth of a sender. For layered encodings, each layer is an independent RTP session with its own session bandwidth parameters.
The session bandwidth parameter is expected to be provided when a session management application is called by a media application. However, the media application can set a default value based on the data bandwidth of a single sender. The application can also force bandwidth restrictions based on multicast range rules or other standards. All participants must use the same session bandwidth value to calculate the same RTCP interval.
Bandwidth computing for control and data traffic includes low-layer transmission and network protocols (such as UDP and IP addresses) Because resource reservation systems need to know them. The application also expects to know which of these protocols are used. Link Layer headers are excluded from computing because messages are encapsulated with different link layer headers during transmission.
The control traffic should be limited to a known small proportion of the total session bandwidth: Small is to avoid compromising the ability to transmit data; it is known that the traffic can be controlled when the protocol bandwidth specification is reserved for resources, and each participant can calculate the bandwidth shared by himself. The traffic control bandwidth is the part of the session bandwidth except the data traffic. It is recommended that the proportion of the session bandwidth occupied by RTCP be fixed at 5%. We recommend that 1/4 of the RTCP bandwidth be used to send data to the participants so that new participants can receive the cname from the sender more quickly in a session containing a large number of receivers but a small number of senders. When the percentage of the sender in all participants exceeds 1/4, the sender shall obtain the RTCP bandwidth of the corresponding proportion. Although these values and other constants are not important in the interval calculation, all participants in the session "must" use the same value to calculate the same interval. Therefore, in a specific policy, these constants "should" be fixed.
A policy "yes" specifies that controlling the traffic bandwidth is an independent parameter of the session, rather than a strict proportion of the session bandwidth. The independent parameters enable the rate adaptive application to set the RTCP bandwidth to be consistent with the "typical" data bandwidth that is smaller than the maximum bandwidth specified by the session bandwidth parameter.
The policy also "can" further stipulate that the control traffic bandwidth is divided into two independent session parameters for active data transmitters and other participants: we call these two parameters S and R. According to the "1/4 RTCP bandwidth allocated to the data transmitter" recommendation, the default values of these two parameters are 1.25% and 3.75%, respectively. When the ratio of the transmitter exceeds S/(S + r), the sender obtains the ratio in (S + r. Use two parameters to make the following possible: Set the RTCP bandwidth of a non-data transmitter to 0 for a specific session, and keep the RTCP bandwidth of the Data Transmitter not 0. The RTCP receiving report is completely disabled, the sender report is still sent to enable inter-media synchronization. We do not recommend that you disable RTCP to receive reports because the list of features starting from section 6th requires them. However, this may be appropriate in the following situations: Systems on one-way links, or sessions that do not need to receive quality or feedback, or there are other ways to avoid congested sessions.
The calculated RTCP packet-compliant transmission interval also "should" have a lower bound to avoid unexpected traffic spikes that exceed the allowed bandwidth when the number of participants is small and the traffic is not smooth. This also prevents the report interval from becoming too small during partial network transient and delays the adjustment after network recovery. A latency "should" be enforced between application startup and sending of the first RTCP package, so that there is time to receive the Russian RTCP package from other participants, therefore, the report interval tends to the correct value more quickly. This delay can be set to half the minimum interval to notify new participants of the input faster. The "recommended" value for a fixed minimum interval is 5 seconds.
One implementation can reduce the minimum RTCP interval to suit the session bandwidth parameter. The following restrictions apply:
-For multicast sessions, only the active data transmitter can use a smaller minimum value to calculate the transmission interval that conforms to the RTCP packet.
-For unicast sessions, the inactive data transmitter can also use a smaller value. The latency before sending the first composite RTCP package can be "0.
-For all sessions, when calculating the participant timeout interval (see Section 6.3.5), the fixed minimum value above should be used, in this way, those implementations that do not use smaller values will not be considered timeout by other participants too early.
-If the value is smaller (in seconds), the "recommended" value is 360 divided by the session bandwidth (unit: kb/s ). This value is less than 5 seconds when the bandwidth exceeds 72kb/s.
The algorithms described in section 6.3 and appendix A.7 comply with the objectives proposed in this section. This algorithm calculates the interval between sending RTCP composite packets and allocates the permitted traffic control bandwidth among all participants. This allows applications to quickly respond to small sessions such as identifying all participants and automatically adjust to larger sessions. This algorithm has the following features:
-The calculated RTCP package interval increases linearly with the number of group members. This linearity makes the total control traffic of all members constant.
-The actual RTCP packet interval is selected within the range of [0.5, 1.5] To avoid unexpected synchronization of all participants [20]. The latency of the first RTCP package after joining the session is a random value within the range of [0, 0.5] times of the minimum RTCP interval.
-Calculate the average size of the composite RTCP package, including all sent and received packages, to automatically adapt to the changes in the amount of information under control.
-Since the calculated interval depends on the observed number of group members, there may be an unwanted startup effect: adding a quit session to a new user or adding multiple users to a new session at the same time. These new users are not correctly estimating the group size at the beginning, so their RTCP transmission interval is very short. This problem is obvious when multiple users join the session at the same time. To handle this situation, an algorithm called "timer reconsideration" is applied. This algorithm implements a simple back-off mechanism that prevents users from sending RTCP packets when the group size increases.
-When the user leaves the session and times out in Bye mode, the group size decreases, so the calculated interval should be reduced. The "reverse reconsideration" algorithm allows members to reduce their intervals more quickly to respond to the decrease in group size.
-The bye package is different from other RTCP packages. When a user leaves the group and wants to send a bye package, it can send the package before the next RTCP package. However, bye packet transmission follows a compensation algorithm to avoid the flooding of Bye packets when a large number of Members leave the session at the same time.
This algorithm can be used for sessions that allow all participants to send data. In this case, the session bandwidth parameter is the bandwidth of a single sender multiplied by the total number of participants, and the RTCP bandwidth accounts for 5% of the total.
The details of this algorithm are provided later. Appendix A.7 provides a demonstration implementation.
6.2.1 maintenance of the number of session members
The calculation of the rtcp packet interval depends on the estimation of the number of sites participating in the session. New sites are counted when they are heard and "should" create corresponding entries for each new site in the table indexed by the SSRC or CSRC identifier (see section 8.2) to track them. The new entry "yes" is considered invalid until multiple packets containing the new SSRC are received (see Appendix A.1) or a seds rtcp package containing the cname of the corresponding SSRC is received. When an RTCP bye packet is received, the corresponding SSRC entry "can" be deleted, unless some scattered packets arrive and this entry is re-created. Additionally, "should" mark the entry to receive bye and delete it after appropriate delay.
One participant "can" mark another site as inactive, or delete an entry if it is invalid, if RTP or RTCP packets are not received within several RTCP reporting intervals ("recommended" 5 S. This provides some robustness for packet loss. All sites must use the same multiplier and calculate the RTCP Reporting Interval such as the big point. This timeout can work properly. Therefore, the specific policy "should" fix this multiplier.
For sessions involving a large number of Members, it is not feasible to maintain a table that stores SSRC identifiers and corresponding State information. One implementation can use SSRC sampling (sampling) as described in [21] to reduce storage requirements. One implementation can use other similar algorithms. A key requirement is that such an algorithm "should not" roughly underestimate the group size, but "can" overestimate.
6.3 rules for sending and receiving RTCP packets
This section describes how to handle RTCP packet rules after sending and receiving. The implementation of a multi-play environment or multi-point unicast environment must comply with section 6.2. In this way, you can use the algorithms defined in this section to meet those requirements, or you can use other algorithms with the same performance or efficiency. An Implementation restricted to two-party unicast "should" still use the RTCP Transmission Interval random value to avoid synchronization of unexpected multi-instance operations, but "may" ignore 6.3.3, the "timer reconsideration" and "reverse reconsideration" algorithms in sections 6.3.6 and 6.3.7.
To implement these rules, a session participant must maintain the following status information:
TP: the time when the RTCP package was last sent;
TC: current time;
TN: The next scheduled time when the RTCP package is sent;
Pmembers: the total number of session members estimated at the most one calculation of TN;
Members: the latest estimate of the total number of session members;
Senders: the latest estimate of the total number of transmitters in a session;
Trcp_bw: The target RTCP bandwidth, which is the total bandwidth used by the RTCP package of all members in this session, in bytes per second. This is a specified proportion of the "session bandwidth" provided to the application at startup.
We_sent: a tag. It is true if the application has sent data from the previous two RTCP reports.
Avg_rtpc_size: Average size of all RTCP composite packages sent and received by the participant, in bytes. This dimension contains the Low-layer transport and network-layer protocol headers (such as UDP and IP addresses), as described in section 6.2.
Initial: a tag. It is true if an application has not sent the first RTCP package.
Most of these Rules use the "calculated interval" during packet transmission ". This interval is described in the following sections.
6.3.1 calculating the RTCP Transmission Interval
To maintain scalability, The average interval between packets of session participants should be expanded with the scale of the group. This interval is calculated as the calcutated interval ). It has some parts of the State described above for export. The calculated interval t is determined by the following method:
1. If the number of senders is less than or equal to 25% of the total number, the interval t depends on whether the participant is a transmitter (based on the variable we_sent ). For the transmitter (we_sent is true), constant C is set to mean RTCP package size (avg_rtcp_size) divided by 25% RTCP bandwidth (rtcp_bw), constant N is set to the number of senders. If we_sent is false, constant C is set to mean RTCP package size divided by 75% RTCP bandwidth. Constant N is set to the number of receivers (total number of members minus the number of receivers ). If the number of senders exceeds 25%, the sender and receiver work together: constant C is set to average RTCP package size divided by the total RTCP bandwidth, n is set to the total number of members. As described in section 6.2, An RTP policy "yes" specifies that the RTCP bandwidth is directed to the transmitter and receiver respectively by two independent parameters (S and R. In this case, the ratio of 25% is S/(S + r), and the ratio of 75% is R/(S + r ). Note that if R is 0, the ratio of the sender cannot exceed S/(S + r). Therefore, Division by 0 must be avoided.
2. if the participant has not sent the first RTCP package (the variable initial is true), the constant tmin is set to 2.5 seconds; otherwise, the variable is set to 5 seconds.
3. The final calculated interval TD is set to max (tmin, N * C ).
4. The calculated interval t is set to a random value that is evenly distributed between [0.5, 1.5] times of TD.
5. t divided by E-3/2 = 1.21828 to compensate because the average RTCP bandwidth calculated by the timer reconsideration algorithm is less than the expected average.
The intervals T produced by the above process are random, but at least 25% of the RTCP bandwidth is allocated to the transmitter on average. If the number of transmitters accounts for more than 1/4 of the total, in an average sense, the above process allocates equal bandwidth among all participants.
6.3.2 Initialization
Once a session is added, the participant initializes the following values: TP is 0, TC is 0, senders is 0, pmembers is 1, members is 1, we_send is false, rtcp_bw is the proportion specified in the session bandwidth, initial is true, avg_rtcp_size is the possible size of the first RTCP package that will be constructed later by the application. Next, calculate T, and set the first packet to Tn = t at the time point. This means that a transmission timer is set to timeout at the time point T. Note that an application "can" implement this timer in any way it wants.
The participants add their own SSRC to the member table.
6.3.3 receive an RTP or non-bye RTCP package
When an RTP or RTCP package is received from a participant who does not have its SSRC in the member table, SSRC is added to this table, the parameter members is updated once the participant passes verification as described in section 6.2.1. Perform the same process for each CSRC in the verified RTP packet.
When an RTP packet is received from a participant whose SSRC does not exist in the sender table, SSRC is added to this table and the senders value is updated.
For each received RTCP package, avg_rtcp_size is updated as follows:
Avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
In the preceding formula, packet_size is the size of the RTCP package just received.
6.3.4 receive an RTCP bye package
In addition to the scenario described in 6.3.7, if you receive an RTCP bye package, check the SSRC of the package according to the member table. If yes, delete the entry from the table and update the members value. Check according to the transmitter table. If yes, delete the entry from the table and update the senders value.
To make the RTCP packet transmission rate more adaptive to the changes in the group size, when receiving a bye packet that will cause members to be smaller than pmembers, "Should" execute the following "reverse reconsideration" algorithm:
-The tn value is updated according to the following formula:
Tn = TC + (members/pmembers) * (Tn-TC)
-The TP value is updated according to the following formula:
TP = tc-(members/pmembers) * (TC-TP ).
-The next RTCP package is rescheduled to tn at the sending time point, which is earlier than the scheduled time point.
-Set the value of pmembers to equal to members.
This algorithm does not prevent the following situations: when most rather than all participants leave a large session at the same time, the premature timeout calculated will temporarily reduce the estimated group size to 0 incorrectly. This algorithm does not make the estimation return to the correct value more quickly. This situation is rare and has no adverse consequences. Therefore, this issue is considered unnecessary.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
