I'm trying to understand the exact problem with NAT and SIP and have seen many different explanations. Here's what I've gathered so far:
1) SIP User agent is both initiating and accepting calls, therefore unless the NAT/firewall is configured to accept incoming traffic on this port it cannot work - this makes sense but sounds more firewall and port mapping
2) SIP messages contain IP addresses (that can be private) in the body which requires NAT traversal - if this is the case
3) it's not a problem with SIP but with RTP, whose parameters that are included in the SDP as part of the SIP message body that include private IP addresses
4) something to do with UDP vs. TCP?
When a call is done with SIP the calling endpoing does not know the endpoint the call must reach i.e. the endpoint's IP.
It only knows the IP address of the SIP server.
So the INVITE goes to the SIP server and SIP servers "knows" where/how to reach the called endpoints.
The idea is that the SIP messages contain SDP data that contain the information needed so that eventually the phones will be able to set up a session and users will be able to start talking.
These data include IP, port, codecs and other parameters.
So if one of the phones is behind NAT the phone will report as its IP e.g. IP_X which is its private IP and the other endpoint can not reach that IP; the public IP is unknown at that point.
All of your assumptions are correct.
In SIP, you can split it into 2 main problems: signaling and media.
The signaling runs in SIP over either TCP or UDP, and the connection can open from both directions, as calls can be dialed or accepted by user agents.
The media runs over RTP (and RTCP), which is usually done over UDP (unless you're trying to achieve NAT traversal), and then it might go over TCP). The ports and addresses here are allocated dynamically, need to go both ways and run on multiple sessions (=multiple sockets and connections).
To achieve NAT traversal, you will usually use multiple techniques: STUN, TURN, ICE, HTTP tunneling and even an SBC.
NAT traversal for SIP requires external support from servers - usually not the SIP server - that are dedicated for the job.
I'll disagree mildly with Tsahi Levent-Levi's answer.
The problem is that the IP address you put in your Via, Contact, From/To headers, SDP, etc., must be globally routable. If you're behind a NAT you'll obviously need to put in your external IP address.
Implementing ICE, using STUN, etc., allows you to do this automatically, but you can always solve the program manually.
In particular, by inspecting your machine's routing table you can tell whether or not the machine you're calling is behind a NAT or not (by virtue of knowing that work machines are behind this VPN NAT here, and local machines are on this subnet, and everything else runs through your router's NAT). With that information you may find out a NAT's far-side/external address somehow (STUN gives this automatically, but your internet router may have a static address, or you could contact an HTTP server capable of returning your external address, or ...). Once you have that far-side/external address, you can put the address where necessary - your Contact header, SDP c= headers, and the like.
There is a whitepaper by Eyeball Networks that clearly explains the NAT & firewall traversal problem for voip and the STUN, TURN, ICE solution. There are also a couple of great diagrams on how SIP P2P and SIP TURN calls are achieved at http://www.eyeball.com/voip-solutions/stun-turn-ice.htm
Related
ISPs tend to block all inbound traffic. What if I keep the socket alive after the initial handshake with a remote server, and the protocol doesn't impose any limit on how long the socket can be kept open. Can the server send traffic towards me without needing the client to first send a request? I read somewhere that's how push servers work. But I'm confused how this is possible. Isn't the socket just a resource allocated by the two endpoints (client and server)? How is my ISP supposed to know anything about the opened connections to not drop inbound traffic in the middle?
ISPs tend to block all inbound traffic.
This is not generally true. It is usually the case though, that NAT (Network Address Translation) is involved to map multiple internal IP addresses to a single public visible IP address. Due to how NAT works it will implicitly block inbound traffic, since it cannot find a matching NAT state.
NAT is done almost always at the home router and it might additionally be done at the ISP (CGNAT - Carrier Grade NAT).
How is my ISP supposed to know anything about the opened connections to not drop inbound traffic in the middle?
The ISP (in case of CGNAT) and your home router have a state table which match internal connections (before NAT) to the rewritten ones (after NAT). If data arrive from the internet it will try to map these against the state table and rewrite the packets back. If no state exists the packet is discarded.
What if I keep the socket alive after the initial handshake with a remote server, and the protocol doesn't impose any limit on how long the socket can be kept open. Can the server send traffic towards me without needing the client to first send a request?
Even if the port is actually blocked for connections initiated from the outside it is usually possible to initiate arbitrary connections from the inside. Ones these are established it is possible to send any data back. This is achieved by a technique similar to NAT but without the actual address translation - a stateful firewall.
The request and response pattern you mention is actually more specific to protocols like HTTP, but other protocols like SSH, WebSockets etc don't use this approach anyway.
Both with NAT and with stateful firewalls you have to make sure that the stat is not deleted. States are deleted after some (device specific) timeout of inactivity and once this is done no inbound data will be forwarded. The state is kept open by either sending actual application data or using TCP keep alive (which is a heartbeat without application data).
I'm in the process of making a multiplayer game, where the players' movements are sent over the network and their positions are stored in the server. I've been told that UDP would be best since it doesn't rely on constant connection and it won't matter if the client misses a packet. The clients could be on any router, not necessarily within the server's LAN.
Is it possible to set up a server that the clients can connect to that will send all of them periodic updates of the positions of nearby objects/players?
I don't want to have to send packets to each individual client, and I heard multicasting can solve this problem, but every example I've seen only sends packets over a local network. Can I multicast past routers, and if so, how can I do that in Java? (And explain it to me like I have no idea what I'm doing, which is mostly true)
Ex.
Server has IP address 71.10.200.133
Client A has IP address 38.49.339.293
Client B has IP address 37.28.487.388
...
Client Z has IP address 43.38.382.949
Client A sends an update about the player's position to Server
Server sends update to B-Z without iterating a packet to each individual client. How do I accomplish this (if it's possible)?
Multicasts will traverse a router if and only if the router allows it. Unless you're in control of all the routers between you and your clients, the answer to your question is 'no'.
Multicast packets are broadcasts, thus they reach each node on that subnet. For you to send a multicast packet out on the web is not an effecient nor smart way of sending data.
For LAN based traffic:
Multicast is fine
But, for internet traffic I would suggest making a:
UDPClient
or
TCPClient
for internet based traffic and possibly multicast for LAN based (to mix things up a bit).
For internet traffic: Keep in mind, clients will need to initiate the connection first since most routers (household) have a firewall blocking all NEW outside-to-in traffic. So create a socket to listen over a designated port/ports for any incoming connections and from there on use which ever method of packet broadcasting/sending you like
You do also have the option of using Multicast proxies or Layer 2 VPNs if you have the capabilities. L2TP, https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol
A layer 2 VPN would relay unicast and multicast packets.
That would basically allow you to control the routers as EJP suggested above.
This questions also 3 year old so you've probably already figured a way to do it by now.
I'm on the client side. There're multiple network interfaces. How can I let different processes use different network interfaces to communicate? Since I want to connect to the same server, routing seems not working here. Also, connect() doesn't have arguments to specify local address or interface as bind() does.
If your goal is to increase bandwidth to the server by using multiple network interfaces in parallel, then that's probably not something you can (or should) do at the application level. Instead, you should study up on Link Aggregation and then configure your computer and networking stack to use that. Once that is working properly, you will get the parallelization-speedup you want automatically, without the client application having to do anything special to enable it.
"The bind() system call is frequently misunderstood. It is used to
bind to a particular IP address. Only packets destined to that IP
address will be received, and any transmitted packets will carry that
IP address as their source. bind() does not control anything about the
routing of transmitted packets. So for example, if you bound to the IP
address of eth0 but you send a packet to a destination where the
kernel's best route goes out eth1, it will happily send the packet out
eth1 with the source IP address of eth0. This is perfectly valid for
TCP/IP, where packets can traverse unrelated networks on their way to
the destination."
More info e.g. here.
That's why you probably misunderstand bind() call.
The appropriate way to bind to physical topology (to some specific interface) is to use SO_BINDTODEVICE socket option. This is done by setsockopt() call.
Source Policy Routing might be helpful.
Try the following steps:
Use iptables to give packets from different process with different marks.
Use iproute2 to route packets with different marks to different table.
In different table, set the default route to different uplink.
The whole process require certain amount of understanding about linux networking.
Here is an example shows how to route all traffic for a user through one specific uplink: http://www.niftiestsoftware.com/2011/08/28/making-all-network-traffic-for-a-linux-user-use-a-specific-network-interface/
You could try follow similar approach by running different process with different user and route traffic from one user to one uplink.
Also you could let processes communicate with the server with different port and mark the traffic by port.
I've read tons of questions about this all over the web, and can't seem to find a solid answer. If I have an iPhone that's running on cellular data and another iOS device on wifi (in two separate locations), is it possible for them to send data to each other directly without sending it first to a web server, then retrieving it? Are the only options sending and receiving from a server/Apple's iCloud? What if I knew the devices' ip addresses? Note that the iPhone has WiFi disabled.
I'm not looking to put this in the app store, it is for personal use. I know NSNotificationCenter isn't an option.
Using the gamekit framework you can send data between two iOS devices. It is easy to implement. Other than that I don't think there is any other way to send data between two iOS devices.
Actually, it IS possible. You may want to google for something called "UDP hole punching" or "TCP hole punching".
The main approach in short: Assuming you got something like a relay server, that is some server in the internet that is publicly addressable from every private LAN that is connected to the www. No you have your two clients A and B in (different) private LANs, with some Network address translation (NAT) going on, that want to establish a peer to peer connection.
First of all both will tell the server their IP address and the port they have in their own LAN. In the UDP or TCP packet, the server will find the public address and port of the device (or the NAT (router)). So the server knows the private and the public IP address as well as the ports.
If now A wants to communicate with B, it asks the server for help. The server will send a message to B that A wants to communicate with her telling her A's public and private IP and port. A gets back B's public and private information and port.
Now here is where the magic happens. Both clients now send packets out to establish a connection simultaneously to the private and public addresses of the other party and thus punching a whole in their NATs such that incoming connections will not be blocked. Even if one party's connection establishing packets will arrive before this whole is created, the other's packets will get through to such that a connection can be created.
Beware of some NATs that scan the data for IP addresses and translate them as well, but if you encrypt your data or change the appearance of the address (complement, ...) you will be fine.
Now the master question, how can the server communicate with one of the clients without an active connection. Well in this case you can use "connection reversal" and apple's "push notifications". Use the "push notifications" (pn) to tell a client behind a NAT that there is something of interest going on and that it should contact the server. Once it has done that the connection is active and can be used in the previous described fashion.
I hope this helps some people that get to this problem although the post is quite old!
You can only use direct IP address communications if the IP address are publicly reachable IP addresses accessible over the internet, and they are static (enough) so that they are not changing on you regularly as devices get assigned to addresses dynamically. In many (most) cases, that won't be true because your devices will be assigned their IP address dynamically and those addresses are frequently going to be self-assigned IP addresses that aren't publicly addressable.
As others have commented, using Apple-provided mechanisms like iCloud are probably the easiest options. If that's not something you'd like to entertain, there are probably ways to make use of a dynamic DNS service like DynDNS to manage the actual IP addresses of your devices. With something like that you might be able to use a direct IP connection between devices based on a named DNS lookup. You'd probably have to jump through some hoops to make that happen though and I'm not sure you'd want to go to that extent.
I think that Bluetooth would be a good option for you
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.