For a WebRTC peer connection between a mobile client and a media server, would we need a TURN server if the media-server has a public IP and is not sitting behind a NAT?
Related
I normally use a private ip address (with a custom port number) to SSH connect to my server for a remote development. Although I mostly use a private ip address, the port is forwarded properly and I am able to SSH in to the server with the public ip address.
(tested with mobile network hotspot)
Now I am in the local library using the their internet (with my laptop), the connection gets refused and even fails the simple ping test.
Would this be because the library's network is blocking such connection for the security purposes? If so, is there anything that I could do? Or should I just use a mobile hotspot?
In the WebRTC signalling process, I have to find my own public IP address with my port by doing a request to a STUN server. But does it really need to be this complex?
Couldn't I just send a request to the router of my subnet and get its IP address and the port it opened for me? Or even better, I store directly my public address in my computer and the router notifies me whenever it changes. The browser would give an API to get this public address directly. No need to use a STUN server. Why don't we do this instead?
Thank you for your help.
These are all great questions.
Couldn't I just send a request to the router of my subnet and get its IP address and the port it opened for me?
There's an old protocol called uPnP that will dynamically open a port mapping for you - provided the router supports it. A lot of routers used to support it. Not sure how standard it is now.
Even if routers were intelligent and there was a standard signaling mechanism in place, STUN (or something equivalent for STUN is still needed) for the following scenario.
Carrier NAT is when your ISP is sharing a public IP address with multiple routers. That is, your router's public IP address as configured by the ISP when it starts, is really just another private IP address. Upstream, there's a "bigger router" that is sharing the public IPv4 address with multiple other customers. That is, your PC might think it's IP address is 192.16.1.2, and your router reports that it's own IP address is 10.0.0.2. And the actual public IP address, 1.2.3.4, is shared with other customers. STUN solves this problem because the outbound packet to the public STUN server will go through both NATs - creating port mappings along the way.
Or even better, I store directly my public address in my computer and the router notifies me whenever it changes
Because establishing an effective P2P/WebRTC connection is more than knowing your public IP Address. It also involves knowing what "port" to use as well. While most routers will attempt to preserve the local port of the socket the client PC is using in the mapping (e.g. 10.0.0.2:9876 maps to 1.2.3.4:9876). This isn't always the case - another node could be using port 9876 on your network and/or many NATs just pick a randomly available port for the mapping. At the end of the day, you have to signal to the other side of your P2P/WebRTC connection "which IP" and "which port" to use.
The browser would give an API to get this public address directly.
There are plenty of sites such as whatismyipaddress.com that will tell you your IP address. But if there's a HTTP proxy server involved (explicitly configured on the PC or silently deployed on the network), the web service will only see the proxy IP address. Further HTTP(S) is a TCP based protocol. STUN and WebRTC are UDP based.
I understand the purpose of STUN and TURN servers and their use in WebRTC, but I don't fully get:
If I as a WebRTC client have already logged in to use the WebRTC service, wouldn't this service already have my public IP address? Why does it need to be found a second time by the STUN server?
Short answer: Because Proxies and NATs.
Lots of reasons:
The web server knows your public IP address for the established TCP connection, but for the subsequent P2P communications over UDP, it doesn't know how your local NAT will map the port (or which port its using).
You could be on a network in which all HTTP/HTTPS traffic goes over a proxy. Hence, the WebRTC service only knows the address of your proxy.
The WebRTC service itself could have a front end load balancer. Hence, it only knows the IP address of the load balancer.
The two endpoints attempting to do a WebRTC session may actually be behind the same NAT. Hence, the public IP address isn't as useful.
But the primary reason is around port prediction as discussed in #1 above. Address exchange over ICE or WebRTC involves not just exchanging IP Addresses, but also, UDP ports as well. Even if the web server knows the client's actual IP address, the web server can not infer what UDP port it will use for media traffic.
I have a WebRTC MCU (kurento) running on a public IP address
serving some clients that only send or only receive audio
So every clients is directly connected with MCU (not with each other ) that has a public IP address .
Q1: Is there still a necessity to use STUN and TURN for NAT traversal ?? if so Why ??
Q2: Is there any hack in WebRTC in browser that would remove the need for STUN and TURN ?
In my opinion : most of client-server architectures do not have any difficulty with clients behind NAT .What's the difference here with webrtc?
Yes ICE is absolutely must for WebRTC.
Q1: Is there still a necessity to use STUN and TURN for NAT traversal
?? if so Why ??
For your scenario you don't need to use STUN or TURN. Let me explain why.
Every client that are in private network is under some kind of NAT which has a public IP address. Outside world doesn't know this client's private IP address and even if they knew they can't connect with the client without knowing that public IP address. STUN server is used to gather this public IP address.
So if your server wants to initiates the connection then it needs the client to send its NAT's public IP. Client will use STUN server to know its public IP and send it to the server. But if client initiates the connection then there is no need to know the NAT's public IP. Client can send packets to the public server to initiate the connection. Server can know the cilents public IP from the clients packet and then they can connect. So no need for STUN.
Your server is doing TURN's role in this scenario. So you don't need TURN server.
Q2: Is there any hack in WebRTC in browser that would remove the need for STUN and TURN ?
There is no hack. Depending on scenarios TURN/STUN is used. For your scenario you don't need. If you wanted to make client-client connection then you would have needed STUN server.
ICE is mandatory
but using any stun and turn server is not.
since you are connecting to a server on a public port, you NEVER need to use a TURN server, but depending the kind of NAT/Firewall your clients are behind, you might need a STUN server
you do not need to modify the browsers at all. The application decides wether to use a stun server or not. if you pass an empty "iceservers" parameter to your peerconnection object at creation, the ICE UA in your browser will only generate host (local) candidates.
I'm getting start WCF soap web service. Trying to implement a flexible, hot-plug featured, interoperable web service.
A device consumes server service (predefined IP address) which means registering to server, and then service asks device returning all configuration information of a device. Service remotely control those registered devices later.
Network Architecture
Please see the diagram below. A Server-side service is listening on 80 port. We had a router (Router B) which connects to the Server, and set NAT table 220.120.20.209:80 mapping to 192.168.0.3:80. 220.120.20.209 is a public IP.
Two Clients connect to a router (Router A) and have private IP addresses relatively(170.15.40.1/ 170.15.40.2) . Clients host a service (called DeviceService) listening on 80 port. And we didn't set NAT on Router A. 68.250.250.1 is a public IP.
Operation
(Request a Registration) Client sends (request) a message to a Service.
(Response) Service response a message.
(Get Config from Devices) Service consumes client through calling like http: //clientsIP:80/DeviceService.
Operation 1, 2 is working to me. To my understanding, incoming ip address of client#1 is 68.250.250.1 (I'm using RemoteEndpointMessageProperty to get the caller's address).
My question is "operation 3 is not working". Server can't access Client's private IP because of a Router/firewall.Only did Server get is 68.250.250.1. How can I solve this kind of problem? the problem have to do with Network Architecture?
I googled all day long found nothing to do with my problem. But I found websocket thing. Websocket is capable of full-duplex communication over Tcp. Does that mean once a client built a connection with a Server, Server can do operation 3 (Get Config from Devices) anytime even under my network architecture?
Updated 2014/4/24
Thanks a lot to #vtortola. After studying those references , I am still confused that if it's possible to allow call a self-host service from client during a callback session?
Try to elaborate what I thought
Clients will have a self-host service at first. e.g. Providing Configuration Service
Let the Client drive the interaction first, and built a bi-direction channel between Client and Server.
Client requests, and Server response. At the same time, Server triggers the callback procedure.
Server requests "Providing Configuration" message to client via channel during the period callback is fired.
It won't work that way if Router A is doing NAT. RouterA has only an TCP 80 port. Even if you forward it to Client#1, then Client#2 won't work. And I assume RouterA is doing NAT because the client IP addresses are private, so it is translating them to a public IP address.
I think you are messing two concepts. NAT (Network Address Translation) is about IP addresses, it has nothing to do with ports. With NAT you allow your client private IP addresses be translated to the public IP address and therefore get into the internet. Port Forwarding is a technique that allows to map a TCP or UDP port in the public interface of the router to a particular local IP address. Router B is doing NAT to allow the Server communicate with internet through the public interface, and port forwarding to allow hosts in internet to access Server's TCP 80 port, by accessing its TCP 80 port.
Let the Client drive the interaction. In operation #3, the client should send the device configuration after getting the server response in #2.
If you need the server to lead some of the interactions, you must then use a duplex WCF service. WebSocket is one of the duplex WCF bindings. But again, the channel must be established from client to server first.
A Beginner's Guide to Duplex WCF
Duplex Service in WCF
WCF and WebSockets