I am in the process of configuring a TURN server to work with SimpleRTC on CentOS6(I think).
This is the first time I am building webrtc services on centos. I have successfully installed this service on Ubuntu 64 bit Amazon EC2 instance. Unfortunately centos installation is a bit different, and I am slightly lost.
I have the Turn service installed and running. When navigating to my ip and listening port in the url, I see that my turn service is listening on that ip and port with this message from turnserver running -v flag.
445: IPv4. tcp or tls connected to: 173.57.xxx.xx:55676
445: IPv4. tcp or tls connected to: 173.57.xxx.xx:55677
The HTML of the page displays this message...
TURN Server
I am fairly certain that turnserver is setup properly because of this, but I think the ice connections are somehow screwed up.
Here is my ICE config.
This configuration resides in... latest.js, simplewebrtc.bundle.js, and simplewebrtc.js
{iceServers:[{url:"stun:stun.l.google.com:19302"},
{
'url': 'turn:mrturn#23.235.xxx.xxx:5349?transport=udp',
'credential': 'xxxxx'/*,
'username': 'mrturn:xxxxx'*/
},
{
'url': 'turn:mrturn#23.235.xxx.xxx:5349?transport=tcp',
'credential': 'xxxx'/*,
'username': 'mrturn:xxxx'*/
}]}
I have tried quite a few things here, but I cannot get the turn server to give any indication as to why this is not connecting. Obviously it would need to try and connect for some debugging to occur via turn server command line, but I just can't get there.
If anyone has any advice as to why this connection is not working please let me know. I will tip in bitcoin to any answer that resolves this issue.
Make sure the ports are open on your server (both TCP and UDP)
TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and
"turns" for TLS.
So maybe try
{iceServers:[{url:"stun:stun.l.google.com:19302"},
{
'url': 'turns:mrturn#23.235.xxx.xxx:5349?transport=udp',
'credential': 'xxxxx'/*,
'username': 'mrturn:xxxxx'*/
},
{
'url': 'turns:mrturn#23.235.xxx.xxx:5349?transport=tcp',
'credential': 'xxxx'/*,
'username': 'mrturn:xxxx'*/
}]}
If that doesn't work, maybe you can try to have the TURN server listen on 3478 (its default port).
hope this helps
Also the RFC5766-TURN-server group is a great place for questions regarding this project and usually answer pretty fast
late, but try to put your turn service conf # first position in the iceServers arr, as noted here: https://bloggeek.me/popexpert-interview/
Related
I have a regular MySQL server running with XAMPP at port 3306 and accessible by my internet ip aswell my local ip (127.0.0.1), the ports are forwarded in my router. An account set up to be accessed from any IP, Everything works fine.
I'm trying to make this same server be accessible by AirVPN DNS address. So I've followed AirVPN instructions to remove the forwarded ports in my router and forward a new port at their VPN with a random number (lets go with 1111) with local port as 3306 and DNS named as xxx.airdns.org
So I open MySQL with XAMPP under port 3306, nothing changed in config file. I run the AirVPN port checker over 1111 and it signals as open. I also try at other sites that checks ports and signals open at xxx.airdns.org:1111
Though when I try to make a connection as usual it returns error (10060): Can't connect to MySQL server on 'xxx.airdns.org' (10060)
Resolutions I've tried:
Switch port values in MySQL config files matching with the ports open in AirVPN
bound address to VPN adapter bind-address="10.6.114.48"
repeated the options above in all different kind of port combinations and addresses
Disabled Firewall on Ethernet adapter of VPN as described here
I couldn't achieve success in this task. I'm looking for some enlightment so I can understand the process.
EDIT:
The connection is set only to TCP protocol. A port check done through airVPN and is registered at XAMPP & FIREWALL logs as accepted connections. Though trying to connect from a client I got no log from Xampp or Firewall, it gets timed out.
Sorry for "answer" type not just comment, but i dont have enough reputation here :)
Maybe the protocol ( TCP/UDP ) is your issue.
If you use UDP on your airVPN better check forwarding on your router - most of them
by default sets TCP only. Otherwise maybe change to TCP on your airVPN.
ISP provider often filter this protocol.
Issue: Consider that you can't connect to a service running "behind" some VPN server from a machine that's connected to that very same VPN service.
Solution: Connect from another machine to test your service properly.
I have a Symfony 4 application running on 1und1 on a package called "1&1 Unlimited Plus". The SMTP config looks like this:
MAILER_URL=smtp://smtp.1and1.com?username=****&password=******
and it works fine. I also have a development copy of this application on my local dev server with same config. This dev copy can send emails, too.
Since the databases on "1&1 Unlimited Plus" are limited to 1GB, I ordered another cloud server from Ionos. With the same config I am not able to send emails. I got this error in dev.log:
Exception occurred while flushing email queue: Connection could not be established with host smtp.1and1.com [Connection timed out #110]
Ping on smtp.1and1.com works, it reveals the same IP like if I ping on my dev server. On this cloud server I have running:
Plesk Onyx
Ubuntu 18.04.2 LTS‬
DNS turned off. I have just an A-record on the origin server to the IP of cloud server. NO MX-records set.
I checked the firewall rules. No outgoing limits found, just incoming. I added TCP 25 to incoming rules but I dont know if it is necessary.
I tried another ports but then I got this:
Exception occurred while flushing email queue: Expected response code 220 but got an empty response []
More config:
swiftmailer:
url: '%env(MAILER_URL)%'
spool: { type: 'memory' }
Any idea whats wrong?
I found the solution. Ionos closes the outgoing port 25 per default. This is nothing I can find or change in admin area, only technical support can open this port.
In case of not turning the Firewall off:
after pinging the IP the Request time out will appears,
but after turning off the firewall it will reply.
Why?
I am using Mysql with Java, the question not related with java but maybe java programmers get something like this issues with sharing the database.
Your firewall will block access to port 3306 (default port for MySQL). To get it to work without turning the firewall off, you will have to configure the firewall to let connections to port 3306 (other whatever port is configured in your my.cnf) through.
I'm a bit confused about HTML5 Websockets. I've looked at numerous tutorials out there and a lot of them have different variations of connecting using different ports. What do these ports mean?
Adobe for instance, uses this:
new WebSocket('ws://localhost:1740');
Then another tutorial has this where no ports are required:
new WebSocket("ws://www.websockets.org");
And finally a third tutorial has a port, but it's completely different:
new WebSocket("ws://localhost:8080/echo");
My question would be, why do these vary? How do I know which ports to connect to? Also, I've attempted to do my own connection:
var ws = new WebSocket("ws://test.ontarget-network.com/");
But I get the following error: Unexpected response code: 200
I've tested around and tried connecting to various other "ports" (not knowing what I'm doing obviously, typing in random numbers) and this error would disappear, however, my code
ws.onopen = function(){
alert("Connection Established");
};
would not execute.
I'm trying to fully understand HTML5's Websockets API so I can experiment and create more dynamic applications. Thanks for the help.
The server should have an endpoint that accepts WebSocket connections. So, if that endpoint is /echo you would want to connect to:
ws://localhost:8080/echo/websocket
You will get the Unexpected response code: 200 error if you exclude the /websocket suffix after the endpoint. I was having the same confusion and this link cleared things up a bit for me.
The following comes from the latest WebSocket draft:
By default the WebSocket protocol uses port 80 for regular WebSocket
connections and port 443 for WebSocket connections tunneled over TLS
[RFC2818].
Really though, you should be able to use any valid port not in use. As long as clients are trying to connect to the same port that the server-side script opens for the socket connection, you should be fine.
A quick note on ports:
Port 80 is the HTTP port.
Port 8080 is the alternate HTTP port.
Port 443 is the HTTPS (i.e., HTTP with TLS) port.
Port 1740 in the Adobe code seems like some random port not already in use by other services.
For a full list of preset ports, please see the following:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
As for your "Unexpected response code: 200" error, I'm guessing that the WebSocket URL you're using on the client side is not pointing to a valid server-side script, but that's hard to comment on without more info.
I had the same issue, But to survive with
Unexpected response code: 200
You need to have either server-side script to handle the web socket, or you can use Node.js to build a you server script.
for the sake of education you can try to biuld your own websocket sever script.
Actually there is something else... You can not open a connection to every port since there is a list of blocked ports in every browser. I remember seeing the full list of ports in 'The tangled Web' from Michal Zalewski; however, I think a quick google will show this also.
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.