ICE Failed #90
Comments
|
Which browser? I still get a lot of ICE failure in Firefox. |
|
I've been using Chrome primarily. Though I tried on FF and got the same results. |
|
Did you set any client side ICE servers? I am guessing you need to set a STUN and a TURN server so that the server can communicate through your NAT. The media could very well "make it" to the server but sending it back, it could be getting blocked by your network set up. |
|
I did set a Google STUN server, and my public IP in the config file Is there more I should do? Forgive me because I'm a newbie to WebRTC. |
|
Yeah, sometimes STUN is not enough and you have to use a TURN server(depending on your NAT settings). There are public TURN servers available for testing from viagenie. Try using one of those as well to see if you still do not get a feed. |
|
Oh ok. |
|
The echotest.js in the demo pages show you how to set iceServers in the javascript client API wrapper. Add |
|
Well I gave it a try and I'm still getting the same results. When I disable my home firewall, I can connect, but even with the turn server, I still have a failing connection. Here's the log: Here's what I added to the echotest.js |
|
Interesting...Do other webrtc solutions work from your home network? Apprtc.appspot.com perhaps which has its own turn servers and just sets up a peer connection(you will have to have somebody on the other end and not just try against your self because the host candidate will be chosen and not a relay one)? It has to do with the firewall obviously and a TURN server should help with that |
|
You know, I'm not 100% certain if I've tried webRTC from my home since I switched out some networking gear. TimeWarner cable did some upgrades that made me swap out my modem/router. I've since come into work and echo is working...so yeah good times. I'm gonna head home and try again with Apprtc.appspot.com and see what happens. |
|
Good luck and let me know whats up! |
|
Ok so I can make a successful webRTC echo test when I disable my firewall. Otherwise the Turn servers don't seem to help. Here's about output of what I get now that my firewall is disabled. I was able to use Apprtc.appspot.com from my home network. |
|
On two computers inside the same network or with one computer outside your network? Using it one the same computer or between two computers on the same network is a useless test as the ICE candidate used would be the host one and definitely not one gathered through stun or turn(and thus the traffic would never leave your network). |
|
TURN servers help if they're reachable: if your firewall filters the ports the TURN server listens on, then they cannot help you either. That's why most deployments use 80 and 443, both UDP and TCP/TLS, as ports for their TURN servers, to maximize che changes of getting through. |
|
Right you are. Yeah I thought you were going to say that. It was the same computer on the same network so it's not a good test. I can get a WiFi hotspot from work and test using Apprtc.appspot.com on Monday. On a related front, I was doing some tests of my company's webRTC implementation (OpenTok) from my home network. The other participant was on the work network. Long story short, the results were mixed when I had the firewall enabled. Sometimes it worked and sometimes not. Really just odd behavior. |
|
Thank you for the inclusion of that point @lminiero. So I need to try an ICE server on 443? Looks like this company has Turn servers available as a service. http://xirsys.com/guide/ All this maybe a good thing because my router is standard issue from the cable company which many people in our area are getting. The "enabled firewall" doesn't really explain what it's doing when it's "enabled". |
|
It's definitely useful if you can try one. Otherwise, you may try deploying one yourself, there's a popular open source tool you can use for the purpose, just for testing maybe: https://code.google.com/p/rfc5766-turn-server/ configuring it is easy and there are several guides around. As a side note, also have a look at the admin interface in Janus (admin.html in the demos). It will display sessions and related handles. Look for the handle associated to your echo test, and check what the admin has to say with respect to candidates, ICE, DTLS etc. |
|
So this morning I was able to successfully connect with a coworker via Apprtc.appspot.com from my home network, yet echo test was still failing. My coworker was able to connect to echo test from our work network via http/https. I am using some Turn servers in the client side code via Xirsys.com @lminiero in regards to your suggestion about the admin portal. I'm seeing all sorts of interesting data when I have a failing test, though I'm not sure what all to make of it. Here's the part on DTLS, which appears to be failing I'm not sure about what to make of the local / remote candidates Another thought, how do I know if the Xirsys Turn servers are being used properly? |
|
The two most relevant bits to look for are the ICE state (and possible the candidates Janus is aware of) and the DTLS state. The former tells you whether a "channel" was correctly established, while the latter if a DTLS handshake was succeeded on top of that. In your case it's ICE that is likely failing due to too restrictive network settings that can't be mitigated by the setup you're making use of. You only pasted the candidates so I don't know what's the ICE state. I can see that the only remote (browser) candidates available to Janus are a private address (useless) and a couple of relay (TURN) addresses. The fact that relay addresses are available should imply that the browser managed o contact the TURN server and ask for relay functionality, and so that they should help establishing a connection. Not sure what's not working in your case. Try capturing some dumps using Wireshark to see what's happening there (e.g., connectivity checks in any direction). IIRC you said that you specified a public IP in the Janus config: if Janus is deployed on a publicly reachable machine, that setting is not needed, so try removing it. |
|
Thank you @lminiero that's very helpful. I'll take another look and gather more data. |
|
Here's the full output from the admin screen |
|
The ICE state is connected, so connectivity shouldn't be the issue. Have you verified that it's like that in chrome://webrtc-internals (Chrome) or about:webrtc (Firefox)? What doesn't seem to be working is the DTLS handshake, which is still on "trying". You'll have to do the Wireshark capture I mentioned and check, using the DTLS filter, if any handshake message is actually there or not. Try capturing on both the server and client side. |
|
So I know this much. I can complete a echo test on my home network with the firewall enabled when going over plain http. Whenever, I switch to DTLS, it fails. Of course all that is supported by As far as I can tell Wireshark is showing DTLS handshake. Correct me if I'm wrong. Chrome Internals is reporting a failure on the ice servers when connecting via https And showing succcess when connecting via http Taking all this in....my guess is that my IceServers via Xirsys are the likely suspect? Lastly, on passing in iceServers in the echotest.js file, should I only pass in one, even though Xirsys gives me two, and the example shows an array being passed? |
|
You can pass two. When you say HTTP vs. HTTPS, do you mean accessing the demos using HTTP/HTTPS, or do you mean something different? |
|
Yes, I'm testing use the echo test demo. In particular I'm testing using long polling. Like the example code. So when I run the test via |
|
Not sure it's related, that's just the signalling transport. The only difference with respect to WebRTC should be that with HTTPS you don't have to always accept permissions as they're remembered. For what concerns DTLS, from the Wireshark snippet you pasted the DTLS handshake starts but doesn't completes. 104.236.15.218 (Janus?) sends a Hello, the private address 192.168.0.7 (your browser?) then sends its Hello and more info, first trying some retransmits as there's no answer, then sending the grouped messages separately in case the message is lost for fragmentation. If that's all the messages you see, 104.236.15.218 never sends a message back. Have you done a trace on both the client and server sides? Just to verify whether such messages are actually sent/received on both sides. |
|
This is what I got when I ran tshark on the server (104.XXX) |
|
Yep, if you can't see them on the client side that looks like it. |
|
Any advice on where to go next? |
|
Not sure, as far as Janus is concerned it looks like it's doing the right thing, retransmitting the DTLS message as it should. You shoud check it you have any firewalls in place that may interfere with this behaviour. What's weird is that bidirectional communication should be available, as in theory, since ICE succeeded and DTLS was started, connectivity checks worked in both directions. Have you looked at some dumps that include both the ICE exchange (STUN messages) followed by the DTLS setup on both sides to see if this is actually the case? |
|
Another thing that comes to mind is that this may be related to fragmentation. I see the DTLS packets sent by Janus are quite large (~1800) which may have them discarded since they're larger than the MTU (~1500). Are you using the default certificate and keys that come with the code, or did you generate some on your own? If so, how did you create them? In case, try with the default certificate to see if things work for you instead. |
|
@lminiero that's a good idea about the certificates. I'm using our domain specific certs. How, they were generated, I don't know, as they were created before starting this job. I'll try the default certs. |
|
OMG! Looks like the default certs are working. I don't freaking believe it. I never would have thought the certs were incorrect because we've been using them on our various servers without incident. Looking at the file size there's quite a difference. It does appear our certificate chain include the root certificate, so maybe that would reduce the file size enough? |
|
The certificates are not incorrect, just too large. You never had issues as you never used them on UDP, I guess, but just on TCP, e.g. for HTTPS. AFAIK the DTLS implementation in openssl should take care of fragmenting too large packets when retransmitting too many times (by default more messages are grouped as you can see from your dump) but not sure what triggers it. If you can manage to reduce your certificates somehow it would definitely help. |
|
Looks like this bug ticket incorporates this issue. |
|
This seems to refer to the usage of DTLS to transfer data, though, and not to the handshake. This should be the issue to look at: |
|
Looks like it was patched a while ago. I was on 1.01f (the default Ubuntu Package). Just changed the build to download an compile the latest patch (OpenSSL 1.0.1j 15 Oct 2014) |
|
The latest build of OpenSSL did not help. |
|
Generate a shorter certificate just for DTLS, as no verification is involved as of now. Yuo can still keep your certifiates for HTTPS and other services in your application. Closing the issue as it doesn't seem Janus related, feel free to reopen in case you find more information. |
|
I tried to use a CSR under 2048 but the authority wouldn't allow it. Thank you for the help. I do very much appreciate it. This is a great project. |
|
What was the solution here? I ran into this over the weekend and I absolutely could not resolve it. I tried setting STUN & TURN Servers, but consistently ran into ICE Failed messages. |
|
looks, solution is never found for it on this forum. We are facing the exact problem but with alpine docker. We are doing it on AWS, so ensure aws firewall rules are fine. Above issue, has nothing to do with firewall, instead looks like either some build environment issue or something else. |
|
Hello nswarnkar, |
|
Hi,
I made it available at :
https://github.com/nswarnkar/janus_docker
Hope you find no issues :)
…On Thu, May 4, 2017 at 7:50 PM, dejanp777 ***@***.***> wrote:
Hello nswarnkar,
Please provide dockerfile and dependent stuff for me too.
Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AS757kDT_IVBWRkB3hSpnLXfwB4w-l1qks5r2d68gaJpZM4C7QPZ>
.
|
|
Hi Team I am Thiru Dec 07 07:00:27 ip-172-31-18-114 sudo[55457]: [WSS-0x7f377c0097a0] Destroying WebSocket client |
|
I am new into this Janus set up what ever meethico provide installation guide I will follow it working fine. when we trying to connect andriod to janus using ws://localhost:8188 onside video is open but second side is not open . there is no error also . would you please help me |
I'm having some problems with the echo test. The server is deployed to a public IP on DigitalOcean, and the ssl cert is installed and configured. Yesterday at work all seemed to work fine but after I got home either I changed a config or there's a networking situation that I don't understand. The local video renders but the remote video fails.
Here's what Janus logs:
Below are some screenshots
The text was updated successfully, but these errors were encountered: