The changes in 5c4c9d5 caused problems because we'd end up creating new identical pairs. For example, if an existing pair, 0-0, exists as local: 192.168.1.33:5445, remote: 192.168.1.33:63461. Then, after processing a new offer another remote candidate would be added for 192.168.1.33:63461, call this pair 0-1. When determining which pair an incoming binding request belonged too we'd then identify 0-1 instead of 0-0(because max_by_key) returns the last value on ties. In Chrome this would work correctly, but in Firefox connectivity would be lost.
Ultimately adding a new remote candidate that is exactly the same as one that's already part of a viable pair is redundant, so we resolve this issue by simply skipping such candidates.
The changes in
5c4c9d5caused problems because we'd end up creating new identical pairs. For example, if an existing pair,0-0, exists as local: 192.168.1.33:5445, remote: 192.168.1.33:63461. Then, after processing a new offer another remote candidate would be added for 192.168.1.33:63461, call this pair0-1. When determining which pair an incoming binding request belonged too we'd then identify0-1instead of0-0(becausemax_by_key) returns the last value on ties. In Chrome this would work correctly, but in Firefox connectivity would be lost.Ultimately adding a new remote candidate that is exactly the same as one that's already part of a viable pair is redundant, so we resolve this issue by simply skipping such candidates.