We ran into an issue where the Polycom HDX endpoints degraded with poor call quality. When various endpoints connected to the RMX 2000 bridge and one of the participants pushed content via People+Content, everything seemed OK. However, once the token holder stopped pushing content, many of the participants’ call rates (not all, though) dropped considerably, in most cases by half. As an example, an endpoint that initiated a call request at 1024 Kbps dropped to 512 Kbps. This was enough that the older HDX 4000 and 8000 Model A and B units would downgrade to a standard definition video feed. In some cases, this halving would repeat such that the call rate was reduced to 128 Kbps.
No matter how long the participant remain in the call after the call rate was reduced, it never increased back to the original initiated call rate. The only way to correct the issue was to have the participant disconnect and dial back into the conference bridge.
The IP networks as well as the T1 and DS3 circuits were not saturated, and aside from the occasional packet being dropped, there were no issues with bandwidth or latency jitter.
We first started noticing the poor call quality with version 3.1.6 of the Polycom software. Even after upgrading to version 3.1.7, the problem persisted. The issue never occurred in point-to-point calls, even when pushing content.
After some research, it appears the algorithm used by the Dynamic Bandwidth option in the HDX model systems might have been altered in such a way that it is far too aggressive. We always had issues when the content token holder stopped pushing content in a conference call. It’s possible a packet or two may be dropped in the process of stopping the content and this was enough to kick down the bit rates on those participants that happened to lose a packet. It didn’t matter if the endpoint was at the distant site, or on the LAN. Any packet loss would cause the Dynamic Bandwidth option to kick in and reduce the bit rate. Somehow the RMX 2000 bridge has a role in this issue, but I’m not exactly sure how or why because we only noticed the issues when dialed into the RMX 2000 bridge.
While the Dynamic Bandwidth might be useful in a network that has no QoS or bandwidth congestion, it’s quite annoying if the packet loss is temporary and not long lasting. In our case, we were running conferences across DS3 circuits and LAN’s that were nowhere near saturated, and still the participants were being dropped to much lower bit rates, resulting in poor call quality.
Disabling the Dynamic Bandwidth option on each of the endpoints corrected the issue. It appears the algorithm is either far too aggressive or doesn’t play well with the RMX bridge only when pushing content via People+Content.