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.
Related
I am trying to make video calls with WebRTC and Janus. I am able to make calls using the video call demo page supplied by Janus as well as through an iOS app - this is all working perfectly fine.
However, when inspecting the network flow through both wireshark and chrome://webrtc-internals/ the connection does not seem to be directly to the public IP of the other device. Instead the data is directed to my Janus signaling server. It seems that the IP of the remoteIceCandidate is equal to the IP of my signaling server - shouldn't this should be equal to the public IP of device 2?
Is this correct behavior or not? If so, why is the remote IP not equal to the public IP of device 2? If not, what am I doing wrong?
This is correct behavior and a mistake on my part. The Janus video call plugin documentation says the following:
The idea is to provide a similar service as the well known AppRTC demo (https://apprtc.appspot.com), but with the media flowing through a server rather than being peer-to-peer.
Therefore, the media data is supposed to go to the server instead of over a peer-to-peer connection.
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.
so i started to work in this summer and the first task they have given to me is to use wireshark to understand why an application that uses webRTC doesn't use the turn server.
Can you guys help me out, to understand which steps should i do to understand better where is the problem.
I already run the wireshark and only get protocols STUN, that bind to a UDP connection.
TURN is a STUN extension so you will only see STUN packets in Wireshark.
You can easily test WebRTC+TURN in isolation using this sample from the WebRTC project. Remove the default stun server and add the url and credentials for your own TURN server.
Fire up wireshark, start capturing.
Click the "gather candidates" button on that page. You should see candidates with host type at least. You should, if the browser can reach the TURN server usually also see candidates with a srflx type.
If the TURN server is working and your credentials are valid, then you will get candidates with type relay. But you probably wouldn't be asking then.
Now go back to wireshark. Set the display filter to 'stun'. You should see some packets sent to the ip address of the TURN server. Right-click on one of them, 'follow' and 'udp stream'. That should show you all the packets between the browser and the TURN server.
You should be seeing binding requests (message_type=0x01) as well as binding success responses (message_type=0x101) from the server. If you don't see those, your turn server is not responding or something is blocking the client. You will also not get srflx candidates on the candidate gathering demo page.
You should also see packets wireshark interprets as 'allocate request udp' (the message type is 0x101). These are the important ones for TURN.
You should see an error from the TURN server with a message type 0x113 and an error code 401 (unauthorized) because in the first packets, there is no username attribute. In response to those the browser will start sending allocate requests that contain both a username and a message-integrity.
If things go well, those should be answered with an allocate success response (message type=0x103) indicating a xor-relayed-address.
If not and you see more 401 errors that usually means your username and password is wrong.
You might also find the articles on using wireshark to reverse-engineer Amazon Mayday and Whatsapp on WebRTChacks useful -- both use Wireshark.
The WebRTC project has some notes on Wireshark, too.
I am trying to get a browser client to connect with my C++ linux application using WebRTC. So my environment is not the typical triangle WebRTC where 2 browsers setup a WebRTC call thru a server. Instead, the browser client side is typical, but my application is acting as the server and the remote client, so it does the signalling and also streams the SRTP media using gstreamer.
I am successful up to a point. I have successfully exchanged the ice candidates and the offer/answer SDP exchange is also successful. The browser ICE connection state successfully goes to "checking" and at that point I am stuck.
Question: Is the server or remote browser involved in the ice checking operations? That is, does the browser do the ICE checking with the STUN server or with the actual candidate address from the remote end. That would then imply that my C++ application has to be involved in that checking process.
Thanks,
-Andres
your server needs to respond to STUN binding requests at least which are sent as part of ICE.
If your server always has a public IP, using ice-lite (see RFC 5245) will make your life a lot easier.
So the problem I am having is that the WebSocket connection is working on my KurentoMediaServer, but no data is getting transferred (empty remote URLs). I know that this is because my KurentoMediaServer is running behind a NAT (google compute server), but the STUN/TURN server that I am using does not seem to be working.
This is what my WebRtcEndpoint.conf.ini looks like:
; Only IP address are supported, not domain names for addresses
; You have to find a valid stun server. You can check if it works
; using this tool:
; http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
stunServerAddress=173.194.66.127
stunServerPort=19302
; turnURL gives the necessary info to configure TURN for WebRTC.
; 'address' must be an IP (not a domain).
; 'transport' is optional (UDP by default).
turnURL=test%40gmail.com:testpassword#66.228.45.110:3478
I have tested this opening all my ports temporarily to see if that was the issue, but it was not. Also test%40gmail.com is my numb TURN registered username and testpassword is my password.
I should also mention that I have my KurentoMediaServer and Application (java server) running behind the same NAT, but I have my webpage running on a separate network. Is there something I need to do with Kurento-Utils.js in order for my webpage to run a separate NAT from my app and kurento media server?
The STUN server you've entered is not working, and the TURN server yields a possible authentication error with those credentials, though it returns some srflx candidates (remember TURN servers are also STUN servers)
When facing an issue like this, the first thing is to check the STUN and TURN servers using this very useful test page.
You should
Look for a valid STUN server
Disable the TURN configuration in you KMS config file, to single out the failure to one server or the other
Make sure everything is working using STUN
Test your TURN server using the test page
Enable TURN and make sure your TURN server is working with Kurento