We are building a little web-application based on WebRTC. Everything was fine as we could connect pretty much everyone either by STUN or TURN.
During the past weeks, we suddenly stopped getting success from all connections based on STUN (so pretty much every connections). We didn't touch anything, it just stopped working. That is weird because "host" (local) or "relay" (TURN) work fine so I don't think it has to do with the code managing the WebRTC call.
I'm doing the tests by selecting only the ICE candidates marked as "srflx" (STUN) to pass the ICE gathering. I tested "host"-only and "relay"-only with success.
Everything seems fine and "onaddstream" is even fired, but I just seem to not get any valid remote stream to display.
We are using some Xirsys ICE servers and a few public google stun servers. I already tried playing with the server list I give to the API, but the problem seems linked to the STUN itself, not the servers (this, or every STUN server I give isn't working ...)
I was wondering if something major changed in the WebRTC API recently or if I am even able to force-STUN on the same computer (would be weird as I can force-TURN).
Related
Our WebRTC app works in every environment until one user turns on a VPN.
The error we're getting is a failed ICE candidate.
We have tried leveraging TURNs along with STUNs, both public and private, still no success.
Any ideas?
Is your TURN server accessiable over TCP? In your ICE Servers list you should have two entries turn:turn-server.com?protocol=tcp and turns:turn-server.com?protocol=tcp. If you don't specify the protocol it will use UDP.
VPNs cause a few different issues with WebRTC. If it is connectivity there isn't much you can do. I have seen a few VPNs that by default have a very low MTU, it may be configurable.
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 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.
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
I am coding a mac app, which will be a server that serve files to each user's mobile device.
The issues with this of course are getting the actual ip/port of the server host, as it will usually be inside of a home network. If the ip/port changes, its no big as i plan to send that info to a middle-man-server first, and have my mobile app get the info from there.
I have tried upnp with https://code.google.com/p/tcmportmapper/ but even though I know my router supports upnp, the library does not work as intended.
I even tried running a TURN server on my amazon ec2 instance, but i had a very hard time figuring how what message to communicate with it to get the info i need.
I've been since last night experimenting with google's libjingle, but am having a hard time even getting the provided ios example to run.
Any advice on getting this seemingly difficult task accomplished?
The port of your app will not change. The IP change could be handled by posting your servers IP to a web service every hour or whatever time period you want.
Server should run a URL http://your-web-service.com/serverip.php?ip=your-updated-ip and then have your serverip.php handle the rest (put it into a mySQL db or something)
When your client start it should ask your site for the IP and then connect to your server with that.
This is a pretty common way of handling this type of things.