Closed
Bug 1264674
Opened 9 years ago
Closed 9 years ago
WebRTC: Firefox does not check candidates in private networks using TURN
Categories
(Core :: WebRTC: Networking, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1259842
People
(Reporter: matthias.schertler, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160411042519
Steps to reproduce:
I have a scenario with endpoints in different private networks with no routing in between. For making WebRTC calls possible between that networks, there are transfer networks containing TURN servers.
It looks like this is not working, when the TURN servers are in private networks like 10.x.x.x or 192.168.x.x or 172.16.x.x. If the TURN servers have adresses that are not private like 11.x.x.x. everything works fine.
The actual flow when starting a call is like follows:
1. Firefox creates allocations on the TURN server and returns RELAY candidates in the 10.x.x.x network.
2. Firefox receives the remote SDP containing RELAY candidates in the 192.168.x.x network.
Actual results:
3. Firefox doesn't create permissions on the TURN server for the remote RELAY candidates. It also doesn't do ICE checks for the remote RELAY candidates. So ICE must fail.
(If the TURN server has a "public" address like 11.x.x.x Firefox creates the permissions, does checks and the call works)
Expected results:
3. Firefox should create permissions on the TURN server and do checks for all remote candidates. There should be no optimizations based on assumptions if the remote candidates are likely to work or not.
Reporter | ||
Comment 1•9 years ago
|
||
Short version: Firefox only checks public IP addresses using TURN.
This optimization causes problems in scenarios in which the remote TURN server is not in the public internet but in a private network. I recommend removing that optimization form your ICE logic.
Updated•9 years ago
|
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Comment 3•9 years ago
|
||
Yes it is a dupe of bug 1259842
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(drno)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•