Bitrate-capping of relayed WebRTC connections does not respond to route changes |
||
Issue descriptionThe host process caps the bitrate of relayed connections ( issue 857287 and issue 880462 ). But it only determines the connection type when the connection is first made (on ICE-connected state). This is a problem if the connection starts out relayed and later changes to STUN (for example), or vice versa. Instead, we should hook into the OnRouteChanged() state, then apply a cap of 100Mbps (== x-google-max-bitrate from SDP) for direct/stun connections, or the correct relay cap for relayed connections. This issue was seen when testing a host which was patched to delay signaling some ICE candidates. But there's no reason it couldn't happen in the wild.
,
Nov 9
WebRTC doesn't seem to propagate the NetworkRouteChanged event to applications. The PeerConnection state notifications aren't enough for this. It looks like the only way to do this is by polling GetStats() regularly. Then extract the selected local/remote candidate IDs and look up their types, as we do in WebrtcTransport::OnStatsDelivered(). It's easy enough to do, but polling the stats feels ugly. Though we do stats-side polling on the client-side anyway... :)
,
Today
(9 hours ago)
|
||
►
Sign in to add a comment |
||
Comment 1 by jamiewa...@chromium.org
, Oct 2Owner: lambroslambrou@chromium.org
Status: Assigned (was: Untriaged)