ICE-TCP doesn't work on FireFox (Only Chromium) #2125
Comments
|
This is because you are using a advertising a private address |
|
This was just an example. We have candidate with public address, sorry for the confusion. I still tried to add the |
|
Hey @maeln I wasn't able to reproduce this. I launched a EC2 instance in AWS and am running the diff --git a/examples/ice-tcp/main.go b/examples/ice-tcp/main.go
index 5f26156..dc3419b 100644
--- a/examples/ice-tcp/main.go
+++ b/examples/ice-tcp/main.go
@@ -42,6 +42,8 @@ func doSignaling(w http.ResponseWriter, r *http.Request) {
tcpMux := webrtc.NewICETCPMux(nil, tcpListener, 8)
settingEngine.SetICETCPMux(tcpMux)
+ settingEngine.SetNAT1To1IPs([]string{"18.216.219.191"}, webrtc.ICECandidateTypeHost)
+
api := webrtc.NewAPI(webrtc.WithSettingEngine(settingEngine))
if peerConnection, err = api.NewPeerConnection(webrtc.Configuration{}); err != nil {
panic(err)You can access the demo at http://18.216.219.191:8080/ |
|
Hello @Sean-Der ! I tried your demo on my home internet connection and on my phone 4g connection and with both I get : I recorded the communication with tcpdump, here are the captures (filtered to only the communication between the EC2 instance and me): Something interesting is that the STUN communication do seems to work because I see some I also saved the I realize that I failed to mention it but I did most of these test under MacOS with no change to the default firewall parameters. I will work with my colleague to try to provide a minimal example of a client-server that replicate the issue. |
Sean-Der
changed the title
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Resolves pion/webrtc#2125 Resolves pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Resolves pion/webrtc#2125 Resolves pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Resolves pion/webrtc#2125 Resolves pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Resolves pion/webrtc#2125 Resolves pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Relates to pion/webrtc#2125 Relates to pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Relates to pion/webrtc#2125 Relates to pion/webrtc#1356
TCPMux before would create one internal connection per ufrag. This could cause remote IPv6 traffic to be dispatched to a local IPv4 handler (or the inverse). The ice.Agent would then discard the traffic since a candidate pair must be the same IP version. This commit now creates two connections per ufrag. When requesting a connection for a ufrag the user must specify if they want IPv4 or IPv6. Relates to pion/webrtc#2125 Relates to pion/webrtc#1356
|
With FireFox I am not able to connect when Pion is the controlled agent.
If FireFox sent another Binding Request everything would go to connected, not sure why it doesn't. I have attached the pcap here. You can reproduce at http://18.216.219.191:8080/ it is just running https://github.com/pion/webrtc/tree/master/examples/ice-tcp I filed a bug with FireFox, waiting to hear back. https://bugzilla.mozilla.org/show_bug.cgi?id=1756460 |
A controlled Agent would discard incoming Binding Requests if it didn't cause the pair to be selected. For UDP Candidate this would be interpreted as packet loss. For TCP Candidates not responding with a Binding Success could be interpreted as a failure. Firefox's ICE Agent would disconnect TCP Candidates because of this behavior. Resolves to pion/webrtc#2125 Resolves to pion/webrtc#1356 See https://bugzilla.mozilla.org/show_bug.cgi?id=1756460
A controlled Agent would discard incoming Binding Requests if it didn't cause the pair to be selected. For UDP Candidate this would be interpreted as packet loss. For TCP Candidates not responding with a Binding Success could be interpreted as a failure. Firefox's ICE Agent would disconnect TCP Candidates because of this behavior. Resolves to pion/webrtc#2125 Resolves to pion/webrtc#1356 See https://bugzilla.mozilla.org/show_bug.cgi?id=1756460
A controlled Agent would discard incoming Binding Requests if it didn't cause the pair to be selected. For UDP Candidate this would be interpreted as packet loss. For TCP Candidates not responding with a Binding Success could be interpreted as a failure. Firefox's ICE Agent would disconnect TCP Candidates because of this behavior. Resolves to pion/webrtc#2125 Resolves to pion/webrtc#1356 See https://bugzilla.mozilla.org/show_bug.cgi?id=1756460
|
ICE-TCP now works on FireFox. Getting this to work required fixing two distinct issues. Make TCPMux IPv6 AwareThe TCPMux before would create one virtual candidate, and then pass all traffic through it. Don't drop Binding Requests in Controlled AgentA controlled Agent would discard incoming Binding Requests if it didn't Firefox's ICE Agent would correctly disconnect TCP Candidates because of this The controlled Agent now correctly responds with a Binding Success message. To test these behaviors I created https://github.com/Sean-Der/ice-tcp-test. It provides a Pion WebRTC server that supports IPv4/IPv6 ICE-TCP. You can then connect to it as an offerer or answer. If anyone is trying to reproduce issues this would be a good place to start. |
Your environment.
What did you do?
We are streaming a single video (VP8) stream from a server using WebRTC with Pion. This server has a public address and can be reached on the internet. For this reason, we send
hosttype candidate to our client. We don't have a TURN or STUN server as of right now.Some client are in restricted network that block UDP. For this reason, we wan't to be able to propose TCP candidate to our client.
For this reason we added the following configuration to our server:
The main consumer/client is a Unity application running on a phone. It is using the Unity package for WebRTC which is based on Google's
libwebrtc. This client, for testing purposes, will filter out all non-TCP candidate (and we have our own protocol to exchange candidate).After adding the previously mentioned line to the server, our client does receive TCP candidate. For example, this is a candidate that we receive :
When the server are in the same local network (10.1.0.0/24 in the pcap file), it works. The server send the candidate, the client add them, a connection is made and completed and the video stream start and is displayed correctly. The only issue is that when the client disconnect, the server seem to still try to write to a pipe and display a lot of I/O error.
On the other end, when we try connecting through the internet (the server being hosted on a cloud service and the client using a home internet connection), the state of the ICE connection stays at "Checking" and the server never start to send video frame to the client.
There is no firewall that would block TCP (or UDP) between the client and the server.
What did you expect?
We expected the connection to be completed and video frame to be sent, no matter the network and the protocol used. As of now TCP+Internet does not seem to work.
UDP+Internet is working.
Our Findings
After looking further, we notice something in the packet capture:
After adding the ICE candidate sent by the server, the client send a STUN
Binding Requestto the Pion-based server. The server never seem to answer this request. But right after, the server do sendBinding Requestto the client, and the client respond. After this, the connection seems established and the video start streaming.As you will be able to see, when not on the same local-network, this doesn't happen. The client still send a request first, the serve still ignore it, but the server never send a
Request Bindingto the client.For this reason, we are supposing an issue with the STUN protocol.
Using two Pion peer
We also have a Pion-based peer/client. So we tried to make the server only serve TCP candidate by removing
webrtc.NetworkTypeUDP4&webrtc.NetworkTypeUDP6from thesetNetworkTypesin the setting engine.When this is the case, both peer refuse to connect to one another, even when they are in the same local-network (or even on the same machine.
Here is the logs with ice tracing info. For the server :
And here is the log for the client:
Faithfully yours,
Maël
The text was updated successfully, but these errors were encountered: