Open
Bug 1713128
Opened 3 years ago
Updated 2 months ago
Support FQDN in remote ICE candidates
Categories
(Core :: WebRTC: Networking, enhancement, P3)
Core
WebRTC: Networking
Tracking
()
NEW
People
(Reporter: bwc, Unassigned)
Details
Some deployments use an FQDN instead of an IP address in their ICE candidates. I think it makes sense to implement this by delegating DNS lookups to the necko UDP code, much like we did in bug 1416220. This could result in extra candidate pairs on machines that have an IPv6 address, because we do not know ahead of time whether the remote candidate will be IPv4 or IPv6, meaning we need to pair it with both our IPv4 and IPv6 local candidates.
On the plus side, this might allow us to get rid of NrIceResolver, provided we either:
- Stop supporting non-e10s mode, including in gtest (ie; we can get rid of the raw-socket-io-based NrSocket), or
- Find a way to make both the UDP and TCP cases work on non-e10s using the same necko classes that we use for the e10s case.
Comment 1•2 months ago
|
||
It would be great to address this given FQDNs in remote host ICE candidates are working nicely in any major browser I could find except Firefox.
You need to log in
before you can comment on or make changes to this bug.
Description
•