The existing rule regards a candidate pair as not receiving if it does
not receive any data packet, connectivity check, or connectivity check
response for a timeout period since the last receipt of any packet
above. A backup candidate pair typically sends connectivity checks at a
slow pace to preserve the battery life, and the existing rule however
declares receiving timeout for backup candidate pairs as a side effect.
This is a result of the conflicting value of the receiving timeout
period and the longer default connectivity check interval for backup
candidate pairs.
The new rule regards any candidate pair that has its last connectivity
check acknowledged by a response as receiving.
Bug: webrtc:9145
Change-Id: Ie0171fd83aca3d6a0a465885be32f0854856be7f
Reviewed-on: https://webrtc-review.googlesource.com/69784
Commit-Queue: Qingsi Wang <qingsi@google.com>
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22892}
f82644c9c7