I’ve previously written about REMB, or receiver estimated maximum bitrate, and its effect on video quality. While this provides periodic feedback from receivers to Asterisk and a mechanism to set the video bitrate of a sender it does not allow a sender to have any feedback about the packets it is sending to Asterisk. To help with this Asterisk now includes receiver support for the transport-cc draft.
Normally when an endpoint (such as a WebRTC client or Asterisk itself) receives RTP packets it also sends an RTCP receiver report with some general information about what it has received. This can be used by a sender to control its video encoding but does not provide a level of granularity about the packets and also does not take into account RTP streams that may go over the same transport. The transport-cc draft provides this information by having an additional transport wide sequence number that are embedded in RTP packets and also an RTCP feedback message that includes information at a per-packet level about the traffic.
Asterisk when used with PJSIP will now negotiate this extension in SDP and keep track of the packets as they are received. At a 1 second interval it produces the RTCP feedback message which provides to the remote side which packets were not received, the delay between them, and if they have a small or large delta. Using this information the remote side can better determine using a congestion control algorithm how frequently it can send packets, whether it can burst packets, and better scale the bitrate up and down. This is used in addition to REMB where REMB acts as a maximum and transport-cc can drop the bitrate below it if need be. In practice we’ve seen this keep video bitrates higher and when problems do occur the video bitrate is only dropped for a short period of time before increasing back up.
This functionality is available on the latest release of Asterisk 16 when the “webrtc” option is used on an endpoint in PJSIP. If you already use this option then you only need to upgrade.