Key Takeaways
- TWCC stands for Transport-Wide Congestion Control.
- The sender numbers every packet across all streams; the receiver reports back when each one arrived.
- From the timing the sender estimates bandwidth and raises or lowers video bitrate before congestion causes loss.
- It is negotiated in SDP as the transport-cc feedback and a header extension.
What Is TWCC?
TWCC is short for Transport-Wide Congestion Control, the method most WebRTC apps - video calls, live streaming, voice - use to work out how much bandwidth is available and send just under it. Without it, a call would either waste the connection or overload it and freeze.
How TWCC Works
- The sender adds a transport-wide sequence number to every RTP packet, counting across audio and video together.
- The receiver records when each packet arrived and sends this back in compact RTCP transport-cc feedback messages, typically many times a second.
- The sender compares send times with arrival times. Growing delay between packets signals a queue building on the path - congestion is starting.
- The bandwidth estimator lowers or raises the target bitrate, and the encoder adapts video resolution and frame rate to match.
Because the decision runs on the sender, which knows exactly what it sent, TWCC reacts faster and more precisely than older receiver-side estimates such as REMB.
Where You Meet It
TWCC is enabled by default in modern browsers' WebRTC stacks and in most media servers. You see it in SDP as a=rtcp-fb:* transport-cc and a transport-wide-cc header extension. For a business it matters whenever a support chat escalates to a voice or video call - see our guide to escalating chat to voice, video and co-browsing.
Frequently Asked Questions
What is the full form of TWCC?
How does TWCC work in WebRTC?
What is the difference between TWCC and REMB?
How do I check whether TWCC is enabled?
Free plan, no credit card required.