I'm developing a simple app that uses webrtc for transmitting real-time video in one direction (one sender and one receiver). It uses socket.io and node.js for the signalling.
At this moment, it's albe to transmit real-time video when the sender and receiver are in the same net (the server is already online), but if I use mobile net or if the peers are connected in different wifis it doesn´t work.
Actually, I make a test using public library's wifi and my home wifi and when the sender was in the public wifi it worked.
The message I get in firefox when it fails is :
ICE failed, see about:webrtc for more details
As I've read, webrtc uses STUN/TURN servers to solve problems with net's NATS. I have introduced urls from a STUN and a TURN server but it seems it had no effect.
This is the way I'm 'using' the STUN/TURN servers:
var configuration = { iceServers: [
{
urls: "turn:numb.viagenie.ca",
username: "xxxxxxxx#hotmail.com",
credential: "********"
},
{
urls: "stun:stun.callwithus.com"
}
]};
var pc = new RTCPeerConnection(configuration);
For both sides the same and it seems the servers are up.
So, my final question is, I need to do something else to make sure webrtc is using STUN/Turn servers when it's needed?
Or, do you know any other possible cause for this behaviour?
Everything you know can help a lot, because i couldn't find how to use those servers.
if you need more information, please ask for it.
T
Yes, you need to listen to pc.onicecandidate and send each candidate over your signaling channel to the other side, where you call pc.addIceCandidate with it like this, if using adapter.js:
pc.addIceCandidate(candidate).catch(e => console.log(e))
or like this if not (older syntax):
pc.addIceCandidate(new RTCIceCandidate(candidate)).catch(e => console.log(e))
You can also dump the ICE candidates to see if your settings work (srflx = stun, relay = turn):
var PC = window.RTCPeerConnection || window.webkitRTCPeerConnection;
var server = { urls: "stun:stun.l.google.com:19302" };
var pc = new PC({ iceServers: [server] });
pc.onicecandidate = e => e.candidate && console.log(e.candidate.candidate);
pc.createDataChannel("dummy");
pc.createOffer().then(d => pc.setLocalDescription(d)).catch(e => console.log(e));
You can modify that snippet to include your turn server.
console logs of failed comunication
That's an example of what I get in the console. It seems srflx and relay are used, but at some point I get a null candidate, the error on screenshot is because of i'm trying to log a 'candidate' property of a null object.
Finally, the problem was solved.
It seems that Turn server wasn't working fine. I made a trial account on xyrsis and changed the stun and turn servers and it was solved.
Thank you all.
Related
I am using a puppeteer plugin that opens a webserver when I need to manually solve a captcha. The below code works in development, but I can't figure out an approach to get it to work in production.
I am deploying this app on render.com, and as far as I know, I can only listen to one port.
const app = express();
app.listen(process.env.PORT || "3000");
// I eventually get a link like this
// http://localhost:3001/?targetId=68C3007E851659A5D54CD6E023022C91
puppeteer.use(
PortalPlugin({
// This is a typical configuration when hosting behind a secured reverse proxy
webPortalConfig: {
listenOpts: {
port: 3001,
},
baseUrl: "http://localhost:3001",
},
})
);
I've tried making the port the same on both servers but as expected I kept getting the "port already in use" error. I've also tried pointing the base url to my render.com URL, but it times out when I navigate to the url supplied by the plugin.
I am using Ratchet WebSocket in a Windows-based server project that is entirely working in an insecure environment. That is to say that when I navigate my browser to http://www.example.com and connect to the websocket server using ws:// on port 8686 everything works spectacularly.
The server doesn't run through IIS - but instead is executed via php.exe in command prompt like this.
php wsocket-server.php [...parameters...]
However, if run the Ratchet Server and try to connect from https://www.example.com using wss:// the browser simply will not connect to the websocket server, despite the fact that the server starts up fine and the insecure site and connect via ws://
Now, I realize I need to utilize some additional code to include my SSL documentation. This is the relevant code I have in place:
use Ratchet\Server\IoServer;
use Ratchet\Http\HttpServer;
use Ratchet\WebSocket\WsServer;
$websocket_server = new WsServer();
if ($site_secure){
//RUN WSS (SECURE) SERVER
$options = [
'local_cert' => 'c:\inetpub\ssl\2c6fa1928847451c.crt',
'local_pk' => 'c:\inetpub\ssl\2c6fa1928847451c.key',
'allow_self_signed' => true,
'verify_peer' => false
];
$loop = React\EventLoop\Factory::create();
$websocket_server->enableKeepAlive($loop);
$app = new HttpServer($websocket_server);
$insecure_websockets = new \React\Socket\Server('0.0.0.0:'.$port, $loop);
$secure_websockets = new \React\Socket\SecureServer($insecure_websockets , $loop, $options);
$secure_websockets_server = new \Ratchet\Server\IoServer($app, $secure_websockets, $loop);
$secure_websockets_server->run();
}else{
//RUN WS (INSECURE) SERVER
$http_server = new HttpServer($websocket_server);
$server = IoServer::factory($http_server, $port);
$websocket->log ("Initializing ".(($site_secure) ? "Secure " : "Insecure ")."Server ($port)");
$server->run();
}
What I have tried
I have ensured the correct ports are all open in the windows firewall.
I have ensured nothing else is listening on the port using netstat
I have tried using nginx, on a minimal level. I'd prefer to NOT use this method if possible, and was having some initial problems with it starting up so I did not dedicate 100% to it at this time. Ideally, I'd like to use Ratchet's native abilities.
I have searched other similar posts both here and elsewhere, such as this.
I have tried a number of different ports, even the same 8686 as I use in the insecure connection
I am hoping someone can lend me an assist with an issue that has been driving me crazy for 2 weeks. At this point I feel like I'm just trying things to try them and I may be coding myself in circles.
Thank you in advance.
A browser is never going to connect to anything running on port 465. Especially not a WebSocket.
Establishing a WebSocket connection is specified in terms of the Fetch standard. As such, the specific exclusion of this port is found within the latter:
A port is a bad port if it is listed in the first column of the following table.
Port
Typical service
…
…
465
submission
…
…
Now, why are some ports blacklisted? This is a protection against cross-protocol scripting attacks, as once demonstrated (warning: NSFW links) against Firefox and against Safari. Port 465 has been (and still sometimes is) used for SMTP over (pure) TLS, so in this case, an XPS attack might trick a browser into sending mail on the user’s behalf. Blocking those ports is meant to prevent it. Of course, all bets are off when a service runs on a non-standard port.
To make the service available in a browser, all you need to do is change the port number.
Architectute
A webPage uses RTCPeerConnection to create a connection. It uses a STUN and a TURN server in its configuration. It creates an offer and sends the Offer to the remote client only after all the candidates have been gathered
if(pc.iceGatheringState === "complete"){
const resp = await fetch("REMOTE URL", {
method: "post",
body: JSON.stringify({
offer: btoa(JSON.stringify(pc.localDescription)),
}),
});
const sdp = await resp.text();
pc.setRemoteDescription(
new RTCSessionDescription(JSON.parse(atob(sdp)))
).catch((e) => console.log(e));
}
A remote (GO) server uses a REST API to accept the offer and respond with the answer. The answer is sent only after all the candidates have been gathered on the remote peer. I.e. after the "" candidate has been received
The remote server has a local RTP stream which is being sent to the host. The host adds a transceiver before it sends the offer
pc.addTransceiver("video", { direction: "recvonly" });
When an onTrack event is received, the stream is added to a variable and ONLY set as srcObject of the <video> component when the iceConnectionState changes to connected
Issue
The above setup works perfectly in case of a local network. Both, the host and the peer chose a host candidate and the video plays perfectly.
When using a remote connection, both, in case of a STUN (srflx) candidate and a TURN(relay) candidate, the video does not play.
chrome://webrtc-internals clearly shows the the Transport has chosen the right candidates but there is no traffic on the local candidate chosen.
I can see using the UDP dump on the remote peer that the video stream is being sent perfectly.
Debug Info
On remote network, using a srflex candidate, the nack and pli counts are very high compared to a local network
For approx 15 sec of video
pliCount:
local: 5
remote: 221
nackCount:
local: 7
remote: 2577
That sounds like packet loss to me. There are a few things that could be causing it.
Can you try lowering the bitrate of what you are sending? See if congestion is causing it.
Can you trying lowering the MTU? If you are forwarding packets from FFMPEG try appending pkt_size to the URL like this
we just upgraded Akka.Net to 1.1.3 from 1.0.7 and noticed that remoting HOCON had a few new properties such that the following works on Azure, but doesn't on private dedicated servers (say a GoDaddy box):
akka {
actor { provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote"" }
remote {
helios.tcp {
port = 0
hostname = 0.0.0.0
dns-use-ipv6 = false
public-hostname = localhost
enforce-ip-family = true
}
}
}
And the following works well on dedicated servers, but not on Azure:
akka {
actor {
provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote""
}
remote {
helios.tcp {
port = 0
hostname = 0.0.0.0
dns-use-ipv6 = false
public-hostname = localhost
enforce-ip-family = false
}
}
}
From the documentation in the change logs that I found, it appears that enforce-ip-family is a setting which when set to TRUE would allow forcing a client to use IPv6 by setting dns-use-ipv6 to true.
Is this a correct interpretation on my part? Is there some documentation regarding these settings that we could read?
Also, let's say that I wanted to use IPv6 on Azure, what would the server configuration be? Is this even something that I could control?
I also noticed something with the new version that I hadn't noticed before, overnight, I started getting these exceptions:
Tried to associate with unreachable remote address
[akka.tcp://TestActorSystem#localhost:51675]. Address is now gated for
5000 ms, all messages to this address will be delivered to dead
letters. Reason: [No connection could be made because the target
machine actively refused it.
We hadn't seen these errors before and it really doesn't look like there's a specific reason on this before the first one started. Has anyone else experienced this? Could any one shed some light on what I could do to gracefully resolve this situation? A critical piece of functionality stopped working because of this issue and we're trying to figure out how to best address it.
Please pardon my lack of expertise on Akka 1.1.3 but I think I had it all figured out until I inadvertently upgraded the nuget package and had a rude awakening :)
Thank You,
Anup
I am trying to setup a peer to peer connection for WebRTC application. I have read the forums and discussion groups which lead me to the point that STUN/TURN servers are required for the same. Here are the details:
I downloaded the open source implementation of the STUN/TURN server from https://code.google.com/p/rfc5766-turn-server/
Installed the server on my local Mac OS X machine and turned on the server on localhost:3478
When I tested the server using the client scripts, I was able to get back the remote address from the server.
However, when I try to hit the server from my JavaScript code while creating a peer to peer connection, it is not hitting the server itself.
Below is the code which I am using :
function createPeerConnection() {
var pc_config = {'iceServers': [{'url':'turn:127.0.0.1:3478', 'credential':'Apple123'}]};
try {
// Create an RTCPeerConnection via the polyfill (adapter.js).
pc = new webkitRTCPeerConnection(pc_config);
pc.onicecandidate = gotLocalCandidate;
trace("Created RTCPeerConnnection with config:\n" + " \"" +JSON.stringify(pc_config) + "\".");
} catch (e) {
trace("Failed to create PeerConnection, exception: " + e.message);
alert("Cannot create RTCPeerConnection object; WebRTC is not supported by this browser.");
return;
}
pc.onconnecting = onSessionConnecting;
pc.onopen = onSessionOpened;
pc.onaddstream = onRemoteStreamAdded;
pc.onremovestream = onRemoteStreamRemoved;
}
Appreciate any guidance in this matter as I am completely stuck at this point.
One more question: How to setup a peer to peer connection for WebRTC application where both peer A and B are present on an internal network? Is STUN/TURN servers required then?
First, TURN servers are something that are used only if failing to setup an p2p connection directly. About 86% of all calls can be made without relaying via a TURN server (according to this slide, which I by the way recomend to get a better understanding of TURN (from slide 44)).
TURN server should be outside your network since the purpose of it is to relay the stream when not possible to do so in other way.
I would recomend you to start with the case where both A and B are on the same network. Then you do not need to worry about using STUN/TURN. It's enough complicated as it is.