I setup turnserver 3.2.5.9 for WebRTC
I'd like to do this.
Client-A-->(TCP)-->TURN-->(UDP)-->TURN-->(TCP)-->Client-B
I have tow problems each Client-A and B ,both in different private network each other.
For the Client-A's issue.
The TURN server responds candidates for host srfix relay.
I'd like have a relay candidate as tcp.
However,I only can have udp .
How can I have a relay candidate as tcp.
For the Client-B's issue.
The TURN server responds only host.
So, the Client-B can't have any access to the TURN server.
FW policy, which Client-B is placed, is strict that it isn't allow to use UDP.
However, I think It should access to the TURN server by TCP.
Does anyone know how to tell the TURN server about Clients' Global IPs and TCP ports in both cases.
Here is turnserver.conf
listening-port=80
listening-ip=my-server-global-ip
external-ip=my-server-global-ip
lt-cred-mech
userdb=/opt/turnserver/etc/turnuserdb.conf
realm=my.server.domain
stale-nonce
no-udp
no-stun
Here is Response from Trickle ICE tool at the Client-A
Time Component Type Foundation Protocol Address Port Priority
0.015 1 host 2508812977 udp 10.2.1.17 53175 126 | 32542 | 255
0.059 1 srflx 3607399481 udp Client-Global-ip 53175 100 | 32542 | 255
0.086 1 relay 1628315121 udp my-server-global-ip 54043 1 | 32542 | 255
0.116 1 host 3674902081 tcp 10.2.1.17 9 90 | 32542 | 255
39.827 Done
39.833
Here is Response from Trickle ICE tool at the Client-B
0.012 1 host 1197209968 udp 192.168.95.131 60019 126 | 30 | 255
39.819 Done
39.823
WebRTC does not support allocation of TCP relay candidates.
Note that you can still have TURN/TCP candidates which use TCP between the client and the TURN server, those will have a local type preference of 1 which you can see in the trickle ice tool output.
You need to re-configure TURN server with TCP protocol option. Kurento and Wowza support TCP protocol for WebRTC.
Related
I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
but the TURN server running on the server.
here is what shows when I check lsof -i :3478
turnserve 999 root 15u IPv4 446811411 0t0 TCP domain.com:stun (LISTEN)
turnserve 999 root 23u IPv4 446811417 0t0 TCP domain:stun (LISTEN)
turnserve 999 root 24u IPv4 446810998 0t0 UDP domain.com:stun
turnserve 999 root 25u IPv4 446810999 0t0 UDP domain.com:stun
when I check STUN in Trickle ICE it throws an errors
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN server address is incompatible.
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN allocate request timed out.
what's going wrong in this.
Thank you
I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn't get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.
STUN technically requires being hosted on a device with two IP addresses and two ports. It's typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.
The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server's primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.
The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.
Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn't very or useful to connectivity establishment.
I'm surprised Trickle ICE is giving you an error. I didn't think WebRTC ever used the changer-request attribute. I just did a Wireshark trace of a Trickle ICE session to stunserver.stunprotocol.org. I don't see the webrtc client setting the change-request attribute in either of the two binding requests it makes.
More details in RFC 5780 Section 3.2
In macOS, I just do so:
> brew install stuntman
when it done
> stunclient stunserver.stunprotocol.org
Binding test: success
Local address: 198.18.0.1:54898
Mapped address: 210.0.158.130:56750
To specify port, just like this:
> stunclient stunserver.stunprotocol.org 3478
Binding test: success
Local address: 198.18.0.1:63061
Mapped address: 210.0.158.130:37126
Have fun!
I have two clients communicating over webrtc. (Client A writen in js, Client B in Python with aiortc). Now it happens that Client A wants to connect from a mobile Network thus it requires a turn-relay connection.
I have already setup a turn server which seems to do his job. But only approx 50% of the connections succeed now. I already found out when they succeed and when they fail:
SDP relay information in case of success:
Offer Client A
a=candidate:3 2 UDP 92217086 172.31.16.8 59986 typ relay raddr 172.31.16.8 rport 59986
Response Client B
a=candidate:11 1 UDP 92086015 172.31.16.8 49910 typ relay raddr 172.31.16.8 rport 49910
SDP relay information in case of failure:
Offer Client A
a=candidate:7 1 UDP 92151551 172.31.16.8 49871 typ relay raddr 172.31.16.8 rport 49871
Response Client B
a=candidate:5820bb1602563a80c76891a80be14933 1 udp 16777215 18.185.84.96 53279 typ relay raddr 172.31.1.103 rport 49244
The important difference is the IP address shown in the Response from Client B, in the successfull scenario it is the IP adress of the net in which Client B is, in the failing scenario it is the IP address of the turnserver (18.185.84.96).
Actually I do not understand why it sometimes gives the IP of the turnserver and the other times not, and what it means that the IP address of the turnserver is not possible to use...
Anyone any ideas, on where to start looking for the issue?
It seems like our turn server was missconfigured.
I can not tell what was misconfigured, because sadly I have no access to the configuration of the turn server.
But I tested by deploying some turn servers on my local machine and they behaved similar when they where not correctly configured. By looking into the logs of thos turn servers I saw 401 Unauthorized popping up all the time. So I changed the configuration, until the authorization was working. With this config we deployed a new server which is now working.
Some words on the configuration for people also having troubles with that on the first run, those are the configurations we put into /etc/turnserver.conf and passed it when starting the server with turnserver -v -c /etc/turnserver.conf:
listening-port=<port>
alt-listening-port=<port>
listening-ip=<listening-ip>
external-ip=<external-ip>
realm=<realm>
fingerprint
lt-cred-mech
user=<user:pw>
bofore coming to that configuration we made some errors, maybe they are obious to experienced people but they were not to us:
we had the use-auth-secret in the config file, this should not be enabled when using user
we had the issue that the turn server was usable in firefox but not in chrome or others, (not possible to gather relay candidates), this was do to realm not beeing configured in the config
Lets assume Host X has a UDP Socket running on Port 1337.
Now Host Y and Z both send a UDP Packet to port 1337 of Host X.
Are the packets going to be de-muxed?
UDP is a transfer protocol with no guarantees of delivery and doesn't have much of an implementation.
When both host Y an Z send a UDP packet to port 1337, and assuming both packets arrive, the application listening on port 1337 decides what happens with those packages. The application can choose which packet to demux, to demux both or to demux neither.
Hope this clears things up
I'm in a hurry at the moment.
My Question is, is there a way to forward UDP to TCP port?
I need this for hosting a game server for my friends, I want to
host Counter-Strike server for example, but it uses UDP (User Datagram Protocol) for server port, but NGROK only supports TCP (Transmission Control Protocl) & HTTP (HyperText Transfer Protocol).
I tried this while ago..
ngrok tcp 127.0.0.1:27015
and as usually it will start :
ngrok by #inconshreveable (Ctrl+C to quit)
Session Status online
Account Soricy Infinitive (Plan: Free)
Version 2.2.8
Region United States (us)
Web Interface http://127.0.0.1:4040
Forwarding tcp://0.tcp.ngrok.io:18833 -> 127.0.0.1:27015
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
But fails to connect to 0.tcp.ngrok.io:18833 in the game, and displays that there is no UDP configured on the server side.
Is there any way I could do this differently? UDP=>TCP?
Checkout DatagramTunnneler (on github). It is an open-source c++ program which simply listens to UDP traffic and forwards it to a TCP endpoint of your choice. On that TCP endpoint another instance of the DatagramTunneler publishes the UDP data back onto a UDP channel.
Disclaimer: I wrote that tool.
One way is to copy the "raw" udp Payload and create a new TCP packet with the raw payload. But you need to set the same data of the other layer except the udp layer. Also: You need a clean configuration of the tcp layer.
I want to test stun client/server and the send udp traffic from server side to client side.
I run stun client in a local machine, I get the following result.1.
Lenovo-Z50-70:~/iop-bb$ stun -v my_stun_server
STUN client version 0.96
Opened port 22948 with fd 3
Opened port 22949 with fd 4
Encoding stun message:
Encoding ChangeRequest: 0
About to send msg of len 28 to 212.227.107.179:3478
Encoding stun message:
Encoding ChangeRequest: 4
About to send msg of len 28 to 212.227.107.179:3478
Encoding stun message:
Encoding ChangeRequest: 2
About to send msg of len 28 to 212.227.107.179:3478
Received stun message: 88 bytes
MappedAddress = 41.224.250.29:22948
SourceAddress = 212.227.107.179:3478
ChangedAddress = 127.0.0.1:3479
XorMappedAddress = 41.224.250.29:22948
ServerName = Vovida.org 0.96
Received message of type 257 id=1
On the server side, I execute the following, echo "hello" | nc -w1 -u 41.224.250.29 22944.
But, in the client side I didn't receive the packet.
Any suggestion?
You would need to match the port on both sides and do a hole punching step after obtaining your public ip and port.
You ran a stun client listening on local port 22948 to the server (listening on port 3478). From that port you sent a stun binding request request to your server.
The server responded back with a response indicating that your public ip:port was
41.224.250.29 22948.
So now you know that your local ip (e.g. 192.168.1.2) maps to 41.224.250.29 and your local port 22948 maps to the public port 22948.
You could in theory start communicating between client port 22948 and server 3478, but 3478 is already in use by the server. You need to do a hole punching step using the same port you obtained from the STUN response.
The hole punching step with your other service goes like this. Client sends from port 22948 to server (port 9876 for example).
echo "hello there" | nc -p 22948 server 9876
The server could respond:
echo "I see you" | nc -p 9876 41.224.250.29 22948
On the server side, I execute the following, echo "hello" | nc -w1 -u 41.224.250.29 22944
Does this received any packet prior from that client or using the address "41.224.250.29 22944"? If not, client end NAT will not allow this incoming traffic unless it's a full-cone NAT. It's also important that client is using a socket which is ready to receive any packet from that external source. Basically, you have to make sure that binding is there for that external source.