3.2 RTCP Details
RTCP packets SHOULD be sent on every RTP session. Failure to do so can result in loss of functionality on the remote end, because channel statistics such as loss rate and jitter are not communicated, and possibly termination of the session by time-out, if silence suppression is enabled and there is a long period of silence, as specified in section 3.1 of this document or [RFC3550] section 6.3.5.
When there is more than one stream in the same RTP session, this protocol MUST only send RTCP packets using the lowest SSRC in the SSRC range. The packet and octet counts SHOULD be the sum of packet and octet counts of all streams in the RTP session.
The RTCP SDES PRIV extension for media quality, as specified in section 2.2.10.1, works as follows:<40>
The m and q bits are initialized to zero (0) at the start of the call.
With every RTCP report an audio host, which is not a mixer, sends an SDES PRIV extension for media quality to the remote host or mixer with the RTCP report.
If the host detects that the media quality state is good or bad, it SHOULD update the m and q bits by setting m to 1, and q to 0 (good) or 1 (bad) and SHOULD send the updated media quality PRIV extension to the remote Host.
If the mixer receives the SDES private extension from any host, it SHOULD send the SDES private extension for the host to all the other hosts with the regular RTCP reports.
If the mixer detects a quality state on behalf of a source, it SHOULD combine those bits with the extension received from that host or, if the host hasn't sent an extension, build a new extension with the detected bits. Failure to do so can result in loss of functionality on the remote end because the media quality information is not available at the remote host.
To prevent SDES broadcast flooding from mixer, because it can receive an RTCP PRIV extension for media quality from the same host every few seconds with every RTCP report coming from that host, a mixer SHOULD do the following:
If the m or q bits have not changed for a host, the mixer SHOULD send the RTCP PRIV extension for media quality, which contains media quality information for this host, to other hosts every 30 seconds.
If the m or q bits have changed for a host and the mixer has sent RTCP PRIV extension for media quality for this host to another host in the last 10 seconds, the mixer SHOULD NOT send the RTCP PRIV extension for media quality to the other host. After the 10 seconds, the mixer SHOULD send the latest m and q bits. During these 10 seconds, the mixer can receive RTCP PRIV extension for media quality from the same host.
The bandwidth estimation, as specified in section 2.2.11.1, works as follows:
One host sends a pair of packets to another host, back to back.
The receiver calculates the bandwidth on the link, based on the reception times and packet sizes.
The receiver combines multiple measurements to arrive at a bandwidth estimate that is communicated back to the sender through an extension to the RTCP report.
To accelerate bandwidth estimation, the session starts in a "packet pair fast" RTCP sending rate. Once enough RTCP packet pairs have been sent, or the receiver has successfully estimated the bandwidth, the session changes to the "normal" RTCP sending rate. A high-level overview of this behavior is illustrated in the following diagram. Detailed specifications of the states, transitions, and actions are given in sections 3.2.1 to 3.2.7.
Figure 3: Behavior of packet pair bandwidth acceleration
There is a similar pattern for packet train bandwidth estimation. The sender starts sending packet train in a "fast" packet train sending rate (one packet train in one second). Once enough RTCP packet trains have been sent, the session changes to the "normal" packet train sending rate. In "normal" RTCP send rate, packet train SHOULD NOT be sent more than once every 5 seconds. A high-level overview of this behavior is illustrated in the following diagram. Detailed specifications of the states, transitions, and actions are given in sections 3.2.1 to 3.2.7.
Figure 4: Behavior of packet train bandwidth acceleration
If RTCP packet pairs or packet trains are not sent as specified in this document, the receiver cannot send a bandwidth estimate back. Bandwidth estimates MUST be sent through the profile extension. Failure to do so can result in reduced functionality on the remote end for features that need a bandwidth estimate. RTCP packet pairs and packet trains MUST be correctly received and parsed, but MAY not be used by the bandwidth calculation algorithm.
A packet loss notification extension SHOULD be sent when video packet loss is detected, and MUST be received and parsed correctly, but the receiver MAY decide not to take any action in response to the notification.
A video source request extension SHOULD be sent when a receiver wants to watch a specific video source with the video parameters in the message. A video source request extension is configured by the method specified in [MS-SDPEXT] section 3.1.5.30.
When the video source request extension is not configured, a video preference extension, as specified in section 2.2.11.3, SHOULD<41> be sent to the video source when the video receiver prefers to receive a different video resolution. It MUST be received and parsed correctly, but the video source can decide not to take any action in response to this notification. This extension SHOULD be sent at least 10 times for a specific resolution to ensure that the preference is not lost on the wire. The received video preference SHOULD be mapped to the closest resolution in the video capabilities negotiated through SDP extensions for audio and video, as described in [MS-SDPEXT] section 3.1.5.25.
Policy server bandwidth policy SHOULD be sent through the policy server bandwidth extension. Failure to do so can result in reduced functionality on the remote end for features that need the policy server bandwidth policy.<42> If a host receives this bandwidth policy as described in [MS-TURNBWM] section 2, it MUST send this to the remote host. This extension SHOULD be sent at least 5 times for a specific bandwidth to ensure that this profile extension is not lost on the wire.
TURN server bandwidth policy SHOULD be sent through the TURN server bandwidth extension. Failure to do so can result in reduced functionality on the remote end for features that need the TURN server bandwidth policy<43>. If a host receives this bandwidth policy, as described in [MS-TURN] section 2.2.2.9, it MUST send this to the remote host. This extension SHOULD be sent at least 5 times for a specific bandwidth to ensure that this profile extension is not lost on the wire.
Audio healer profile specific extension SHOULD be sent from the host receiving audio to the host sending audio in every report if the metric is available. Failure to do so can result in reduced FEC functionality on the send side under packet loss.<44> It MUST be parsed correctly, but the audio source can decide not to take any action in response to this report.
Receiver-side bandwidth limit SHOULD be sent through the receiver-side bandwidth limit extension. Failure to do so can result in reduced functionality on the remote end for features that need the receiver-side bandwidth limit<45>. It MUST be received and parsed correctly for audio, video and Application sharing profiles. The host SHOULD NOT send the stream more than this limit to the receiver for application sharing profile. This extension SHOULD be sent at least five times for a specific bandwidth to ensure that this profile extension is not lost on the wire.
The peer info exchange extension SHOULD be sent from the host to the remote host in every RTCP packet after the session starts until receiving a bandwidth estimation extension containing a positive bandwidth value from the remote host.
A packet train packet extension MUST be sent in an RTCP packet train packet. An RTCP packet train packet MUST contain one and only one packet train packet extension.
A padding extension MUST be used to pad an RTCP packet pair packet or an RTCP packet train packet to a specific size.
Dominant Speaker History notification message SHOULD be sent through RTCP feedback message every time the dominant speaker changes in the mixer. When there isn’t any dominant speaker, SOURCE_NONE (0xFFFFFFFF) SHOULD be sent as the dominant speaker MSI. When a new RTP session joins the mixer, a DSH notification MUST be sent to keep this new session’s dominant speaker state up to date.<46>