IntroductionWhen your network is congested and some of the packets are lost you need a mechanism to recover them. If we ignore signal processing tricks (like stretching the previous and next audio packets in the jitter buffer) there are two alternatives:
- Forward error correction: in each packet you add some extra information about the previous ones in case they are lost and you need to reconstruct them (flexfec is the new format to do this in WebRTC ).
- Retransmissions: the sender will resend the packets usually after the receiver requests that with a negative acknowledgement message (NACK) indicating which packets were lost.
These mechanisms can be combined depending on the network conditions and can also be tuned for specific cases like scalable video as described in . In Chrome the retransmissions are implemented for both audio and video but by default it is only enabled for video.
Disclaimer: Please report any mistake/inaccuracy in this post and I will fix it asap for future reference. BTW this post is not about rtx "encapsulation" vs the legacy way of sending retransmissions but I'm happy to talk about that in twitter :)
Implementation in the RTP Receiver Side
The RTP receiver side is the one requesting the retransmission sending a NACK RTCP packet when it detects a missing packet.
But... should I request for retransmissions immediately after detecting a gap in the sequence numbers? Google implementation does that plus also have a periodic timer to keep requesting them.
And... for how long should I keep requesting the retransmission? Chrome keeps requesting the retransmission of a specific packet unless the sequence number is "more than 10000 old", the number of missing packets in the list is larger than 1000, you asked for the same packet 10 times already or you have a new decodable full frame (no packet is missing for any other frame it depends on).
This is the Google implementation of WebRTC (and the same code is copied into Firefox and Safari) transcribed as pseudocode:
Implementation in the RTP Sender Side
The RTP sender side is the one receiving the retransmission requests (NACKs) and resending the lost packets if possible.
The main question here is if I should obey all the retransmission requests or not. The way this is implemented in Google's WebRTC implementation right now is this one:
- Keep a copy of the packets sent in the last 1000 msecs (the "history").
- When a NACK is received try to send the packets requests if we still have them in the history.
- But... (rtp_sender.cc)
- Ignore the request if the packet has been resent in the last RTT msecs.
- Ignore the request if we are sending too many retransmissions. There is a rate limiter (retransmission_rate_limiter) that is apparently configured to the whole channel bandwidth estimation.
- If pacing is enabled insert this packet in the queue with normal priority.
Hope you enjoyed this post, it made me feel even more grateful to Google for implementing and opensourcing the webrtc.org codebase.
You can follow me in Twitter if you are interested in Real Time Communications.