I'm trying to make a video chat application based in http://www.html5rocks.com/en/tutorials/webrtc/basics/
It works well in the same network,
but when I try other networks have the following problem:
If i invite other user, only the other user can see the streaming
If he invites me, only he can see the streaming
I think the problem is in iceservers,
I'm using [{'url':'stun:stun.l.google.com:19302'}]
Any ideas on how can I solve this issue?
According to the same article that you mention:
If UDP fails, ICE tries TCP: first HTTP, then HTTPS. If direct connection fails—in particular, because of enterprise NAT traversal and firewalls—ICE uses an intermediary (relay) TURN server. In other words, ICE will first use STUN with UDP to directly connect peers and, if that fails, will fall back to a TURN relay server.
If I'm not mistaken, you use only STUN server. In this case if direct connection is not possible, and without TURN server, which acts as a relay, it's not possible to establish two-way connection.
Check out this article about how to set up your own TURN server, and about all this STUN and TURN stuff: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/
I solve the problem creating my own server STUN/TURN, now is working two-way connection.
Alaershov thank you for your help.
Related
We are doing some research regarding the behavior of Web RTC with the list of STUN/TURN servers provided. I cannot find any documentation so I am doing some tests but I hope someone can provide a clear explanation.
Following the documentation (https://developer.mozilla.org/en-US/docs/Web/API/RTCIceServer/urls) we can provide any number of servers.
But how does the RTCPeerConnection choose the server to use?
Does it try the first one and if it fails try the second one until one works?
Should all the servers be up and running or is the connection able to skip an unreachable server?
If the first server is able to conclude the negociation, does it still try with the remaining servers?
Does it simply change the list of candidates?
To provide more context, we have a working WebRTC application using the Google Stun Servers (stun.l.google.com:19302) however we are migrating on our own STUN servers. We have an API that returns the list of STUN servers to use however based on the behavior we might provide a different list.
Thanks for your help
But how does the RTCPeerConnection choose the server to use?
The RTCPeerConnection doesn't choose a server it choose a pair of ICE candidates. A ICE candidate is generated by contacting the servers.
Does it try the first one and if it fails try the second one until one works?
It contacts them all (this process is called gathering). Your WebRTC implementation may stop gathering when a connection is established.
Should all the servers be up and running or is the connection able to skip an unreachable server?
It is ok for a server to be down. Trickle ICE allows connectivity checks to proceed if all of them are not working.
If the first server is able to conclude the negociation, does it still try with the remaining servers?
Two WebRTC Agents don't communicate through a STUN server, this question has a little more nuance. In the connectivity chapter of WebRTC for the Curious check out how ICE goes through steps.
Does it simply change the list of candidates?
Yea! For each STUN server you may have another candidate. This depends on the behavior of your NAT. You could be behind a NAT configuration that only gives you one mapping. Unlikely but still possible!
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'm trying to set up a cost-effective home security camera site where I can login and view the stream with very low latency. WebRTC seemed like a great solution to get very low latency and keep the connection peer to peer.
I am looking to view this from a mobile device and as a client device I am often behind a symmetric NAT. Since I know the static public IP the camera is behind and control that network I believe I should be able to create a peer connection for video without the need for a turn server I am struggling to figure out how to manage the ICE portion in this case. When I try to connect with just STUN video does not work.
Given my control of the serving peer's network, should this be possible without TURN? If so is there a way for me to sidestep/implement ICE to establish video with my known server peer IP and configuration? Or is there a better technology to use altogether that would allow very low latency?
Knowing the IP address of the camera isn't going to help you any. Since you are dealing with a symmetric NAT, the NAT device is going to bind every IP:port from inside the network reaching to an IP:port in the external network.
This means that if you pin-hole the data via a STUN server, the NAT device won't be impressed enough by that feat to let you connect into the internal network from any other machine other than that STUN server.
Which leads to the fact that you'll probably need a TURN server...
That said, you might have some issues with how you've set up the STUN server and its configuration.
An easy and rather cheap approach can be to use Twilio NAT traversal service - https://www.twilio.com/stun-turn
I have followed the tutorials on http://www.html5rocks.com/en/tutorials/webrtc/basics as well as watch some of the videos but I am so confused. I was able to get 2 peerConnections working on a single page but I have no Idea how build on this to actually allow users on different machines/networks or what ever to actually connect.
From what I can see it involves using socket io and I have found plenty full frameworks and apps doing it but I am struggling to understand it.
Can any one point me to any tutorials that would help me to go from this rtcPeerConnection to communicating with other instances
Any help is greatly appreciated
To allow 2 users establish p2p connection, one of the peer should send "description" (ip address, port, etc) to second peer. Second peer sets it as remote description using setRemoteDescription method of RTCPeerConnection. Second peer invokes createAnswer and sends its localDescription to first peer.
When both peers know about each other, connection can be established. I think that tutorial mentioned by you in first link is comprehensive.
To allow 2 peers exchange "descriptions" you can use any hand-written signalling server. For example client can poll web-server using http.
I don't quite know how to search this in google:
"client to client websocket connections"
"browser to browser websockets"
"websockets without a server"
Haha, is there a way for someone on a webpage in the browser to communicate directly to another person on a web page in the browser, without touching the server?
I am very familiar with socket.io, but that requires all clients emit messages to the server, which can broadcast them to the other connected clients. I am not familiar with the details of web sockets though, so maybe there's a way to communicate without sending messages through the server.
Is this possible? I just want to know the scope of web socket functionality, the limits you can take them too, etc.
Not Web Sockets, but four years later and now we've got browser-to-browser communication!
http://www.webrtc.org/
There are JS libraries built around it to make it easier (e.g. https://simplewebrtc.com/). However, it does still require a server to orchestrate connections.
I know this question is ancient, but it showed up in Google when I searched so it likely will for others!
This is not possible, you have to have the server in the middle.
For an application to accept connections, it has to have a server port open and listening for incoming requests. You cannot have a server socket exposed from a browser. I dont know if you can expose a server socket from within an applet. But even if you could, you would need to know the IP address of the other client for establishing a peer to peer connection.
Well, technically when you broadcast, the client emits to the server, the server broadcasts to everyone. I don't think with the current architecture of the web peer to peer connections like this is possible.
But it is possible that a client send a message to server specifying another client ID, and the server sending it to the other clients using sessions.
The moment you have a client listening for websockets (which you have to do in other to communicate), it becomes a server.