After investigating the code logic related to packet retransmission in WebRTC, I found that the bandwidth limitation for retransmission on the sender side is completely independent. Additionally, the maximum bandwidth for retransmission is also equal to the target rate (which is the same as the REMB bandwidth reported by Homer). This means that theoretically, the maximum actual bandwidth sent by the sender could be twice the target rate.
Since our server (SFU) uses REMB to report the bandwidth to the sender, this poses a challenge for evaluating the REMB bandwidth. To provide a more accurate estimation, it may be necessary to evaluate the bandwidth used by retransmitted packets (lost packets) on the server side and subtract it from the reported REMB bandwidth given to the sender. Another option is to consider stopping the server from sending NACK (Negative Acknowledgment) when there is a significant change in network bandwidth.
Do you have any better suggestions for this issue? Thank you.
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4a4a2bbc-1542-4276-b610-87d3d62f7992n%40googlegroups.com.