I have developed a WebRTC based application along with Kurento-Media-Server.
Problems with this application is:
It works but only on open network (i.e. if run on a network without firewall).
When in firewall it runs sometimes (once out of 10 attempts).
I have tried several things with the firewall, I have disabled all kind of incoming/outgoing traffic. I have created a port-forwarding for my application as well as Kurento-media server.
I am not sure how much useful this information might be but I am deploying my
application on the same physical box along with Kurento-Media-Server. I have configured google's STUN server on my client.js, I have also configured same STUN servers on kurento using code. I haven't configured TURN server.
Just confirming this, signaling server can be behind firewall along with rest of the application, correct?
I am not sure what to look for now, any help in this area would be great.
EDIT-1
From this link I learned that my current network on which my isn't working it has issues with plain websocket connection, it doesn't allow it, it only allows secure Websocket connections.
EDIT-2
Image of netscan:
In my phone network where my app works fine I see all greens in Websocket's "plain" column.
EDIT-3 Solved
Finally found the problem, We were using a router for testing and development and I found that the router had issues, I used LAN cable on the same router and everything worked fine. Calls from application were working just fine. Firewall related details help in configuring the firewall later on.
Based on your problem description it seems all the UDP traffic is not open in your firewall. WebRTC media run on UDP ports.As you mentioned it works one out of 10 times whch means only few UDP ports are open in your firewall.You are lucky when traffic comes via tose ports.You can open port-range in your firewall and configure the same in kurento-media-server config.Your job should be done.
Even if you configure TURN server you need to open certain ports for outgoing and incoming UDP traffic.For TURN server default port is 3478 or 8443 for sending data towards it but for incoming traffic you need to configure port-range on your TURN server and open those ports in your firewall. Always remember TURN server is assured way to connect but it's always costly.
Related
I'm hosting a video call site on Heroku here. My coturn server is Docker-containerized and runs locally behind a router. I opened all the needed ports (3478, 40000-65535) so that I am sure that the corturn server works over the Internet because I checked it using Trickle ICE.
Everything is fine except the video is not transferred when two devices are not on the same network. Any help?
Are you sure your code is using the TURN server?
You need to pass the iceServers list with the TURN URL and correct credentials. See for example https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setConfiguration
Then when you start the ICE gathering, you should see in coturn's log whether the Allocate Request was correctly handled and a XOR-RELAYED-ADDRESS returned.
But you can also see it on the client side (the laptop where the browser runs) by launching a tool like Wireshark and selecting stun as filter.
In addition, when the call is up, check in chrome://webrtc-internals whether ICE gathering has provided relay candidates.
I currently have the following network setup and would like to be able to make WebRTC calls between the two clients in different networks.
I enabled IPv4 forwarding on the openSuse Leap 15.2 server and both devices have either 192.168.2.1 or 192.168.4.1 as their default gateway. The web application as well as the signaling service are both hosted on this server as well.
With the Firewall disabled the call works as suspected, but with the Firewall on the call no longer works. I thought about hosting a Coturn STUN/TURN server on this server, as I've read that you should provision one, if you run into troubles with a firewall.
Is a setup like this doable with lets say Coturn and what would the configuration look like for a scenario like this?
I ended up solving it as I describe in my GitHub issue for this matter.
I'm currently having intermittent issues with Safari loading web pages due to it's disagreements with my default DNS addresses. I can use custom DNS with no issues, aside from my VoIP application not connecting when I do switch my DNS. I've managed to identify the specific ports that are connecting to another set of specific ports and IP for the VoIP application, and I want to adjust my settings somewhere so that I can route those specific addresses.
Currently, to identify the addresses for the app, I type sudo lsof -n -I TCP in terminal and I can identify the app is using the following below:
TCP 10.5.9.151:50036->xxx.xxx.x.xxx:https
TCP 10.5.9.151:50094->192.168.5.173:5448
TCP 10.5.9.151:50093->xxx.xxx.x.xxx:https
TCP 10.5.9.151:50095->192.168.5.173:5448
TCP 10.5.9.151:50098->192.168.5.173:5448
TCP 10.5.9.151:50099->192.168.5.173:5448
TCP 10.5.9.151:50100->192.168.5.173:5448
By default, three DNS addresses are loading in my preferences, all of them private/local network. If I manually add those three DNS addresses after manually adding Cloudflare's DNS, the VoIP will not connect. If I rearrange so that the Cloudflare DNS is last on the list, Safari reverts back to intermittent connection and the VoIP works fine.
I don't have this issue with Chrome, but I'd prefer to remain on Safari. If I have to go without the VoIP application, though it's handy to see who's calling as the phone is out of view in my normal workflow, it's not the end of the world. I'm marginally familiar with Terminal, but I don't know how to modify my hostfile without risking botching my computers network connection. Would be nice if there's a GUI solution that's free. I tried Core Tunnel but I kept getting connection refused messages, likely because of poor configuration on my part.
I have a webcam chat room application (so it's many-to-many video sharing) using WebRTC and a mediasoup server.
I am having problems with SOME of my users not being able to get an incoming video feeds to work. It's a difficult problem because I can't reproduce it at all, and I can't easily "remote-debug" the problem since most of my users are very non-technical. So far the only thing I can tell for certain is that it seems to be network-related, not browser-related, as I have had bug reports from people using Firefox, Chrome, Safari, and Edge. I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible. I just don't know what the exact problem is yet so I'm feeling around in the dark.
So, I'm trying solutions. I don't think(?) I have a TURN server set up but from what I have read, it seems like adding one certainly can't hurt, and could help with my situation.
I don't fully understand the entire WebRTC protocol or RFC 7118 (this stuff is really complicated!) or exactly what/where/how a TURN server fits into the bigger picture. It would help, right? A lot of Googling has led to no clear answers. Would love some help! Thank you!
WebRTC tries everything it can do to make a p2p connection, but there are times that it will fail. The turn server acts as a last resort so that the peers can both connect through the turn server. Obviously this is not a p2p connection, so there will be extra latency, and you will have to make sure that your turn server has enough bandwidth to cover all of the connections you expect.
TL;DR, If you need 100% connection rates, you should have a turn server.
I believe AWS has a ready made instance you can spin up, or if you could use this open source coturn server https://github.com/coturn/coturn
On a debugging note... Check your ice candidates type. You should see host and srflx if you only have a STUN server, but if you have a TURN server you will also see relay. You can replicate this issue by discarding the ice candidates that have host and srflx types.
I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible
That is websocket. The media traffic runs over UDP typically and mediasoup uses random ports. A TURN server which is configured on udp port 443 may help in some cases.
The other problem is UDP being blocked which is easy to reproduce with a local firewall.. Mediasoup supports something called ice-tcp which will allow media to run over a TCP connection. You should check if your mediasoup installation uses ice-tcp. If it does not, a TURN server with TURN/TCP will help.
A website prodecotech.com is hosted by Bluehost
Out of the blue last week my entire office could not access prodecotech.com the connection would time out.
However this is only the situation from one of our internet connections. If I switch over to a guest connection, or use a mobile connection, the website loads fine. The website also loads perfectly fine for ATT and BlueHost tech support.
Our network is configured as follows.
We have a 50MB Dedicated Fiber Connection from an ATT Managed Router. The managed router has 2 ports in use. 1 Port going to OUR router for Data traffic and 1 Port going to OUR switch for VOIP Traffic.
If I connect a laptop to OUR router managing data traffic and try to access prodecotech.com, I get the same results, the connection times out.
If I connect a laptop to the switch managing VOIP traffic, prodecotech.com loads fine.
If I use our guest wifi which is through Comcast, the website loads fine as well.
So the problem is isolated to the Data Portion of my network.
There has been no configuration changes on our router or the managed ATT router.
I thought perhaps somehow our IP got blacklisted by BlueHost, but BlueHost says this is not the case.
ATT support is able to reach the website through their managed router.
I'm utterly stumped.
Additionally, I also cannot access the FTP or CPANEL Server Status for this hosting, both time out as well.
TRACERT has been giving me the following results consistently:
Any Ideas?
In my case, it was due to the wrong MTU(maximum transmission unit) in the router's network configuration. When I changed MTU to 1452 it started working fine.
You should contact your service provider and ask for appropriate configuration settings.