[jitsi-dev] Standalone RTCP termination


#1

On the roadmap call this week, during George's simulcast/rtcp termination
update I brought up the idea of being able to turn on rtcp termination
independently of simulcast. Since the webrtc specifically states that rtcp
from multiple peers is not handled well (see
https://code.google.com/p/chromium/issues/detail?id=521045#c11), I was
worried we may be seeing worse-than-expected behavior due to forwarding all
of the individual reports.

We did some tests today: comparing a set of clients in a call via jitsi
videobridge with and without rtcp termination (the old schemes, we
used HighestQualityRTCPTerminationStrategy) and observed a noticeable
difference in quality. It was not a very systematic test, but from
watching the stats the difference seemed pretty observable: whereas with
pure rtcp forwarding, send bitrate would immediately drop to near-0 when
even the slightest incident occurred, with the termination enabled we
stayed at much higher bitrates overall, and did not react anywhere near as
drastically as it did with pure forwarding.

I'd still like to dig deeper into the tx code to see how receiving multiple
reports are handled to get a firmer idea of what specific issues it might
be causing, but maybe this anecdotal experience is enough to open a
discussion about being able to turn on rtcp termination independently of
simulcast?

-brian