I am trying to test Linphone in public network with both clients are
behind NAT and my sip server is having public IP. All my SIP
signalling with SIP server is working fine but end to end Linphone
clients are not able to receive voice packets for communication.
Please suggest what is the approach to get this scenario working.
P.S: I have also enabled STUN, ICE still not working.
Related
I am trying to setup peer to peer networking and am trying to understand how this works.
Normally in Client to Server connection, I will connect to the server IP and port. Behind the scenes, it will create a client socket bound to a local port at the local ip, and the packet is sent to the router. The router will then NAT the local port and the local socket, to the client public ip and a different public client socket with a destination for the server IP and port.
When the server responds, the router then DENATs the public client ip and public client port back to the local ip and local port, and the packet arrives at the computer.
In a Peer to Peer networking, I may have the peer's public IP, but it is shared by many machines and the router hasn't allowed a connection yet, so there isn't a open port I can send the data to.
There was then an option that both peers contact a server. That opens a port on the router. Then the peers send packets to each other's client port.
However, usually the router will only accept packets from the same IP the request was made to, so the two peers cannot reuse the server's connection.
How do the two peers talk to each other in this scenario ?
Peer-to-peer networking works exactly the same way as client/server networking. Only one of the peers will become a server and the other a client.
Normally in a peer-to-peer app like bittorrent all peers are also servers but of course for any individual connection one machine must take the role of the client. However a single peer may have multiple connections. So for any single peer some of the connections to it will be server sockets and some will be client sockets.
How this works with NAT is exactly the same as a client/server architecture. You must configure your router to NAT back to your peer application in order for others to connect to it. If not then your peer can only connect to other peers but other peers cannot connect to you. For example, if your bittorrent client is generally acting slow, not managing to get a lot of connections and not managing to finish downloading some torrents this often signifies that you have not configured your router's port forwarding back to your PC for your bittorrent client.
For the use-case of non-expert users (consumers) there are several ways to get around NAT automatically without requiring your users to configure their routers. The most widely used method is UPnP (Universal Plug and Play). However a lot of more expert users who can configure their own routers often disable UPnP because it is a fairly well known DDoS target. So if you do decide to use UPnP you should make it optional for more advanced users to disable it if they don't want to use it.
For cases where you need a guaranteed connection regardless of router configuration then your app cannot be 100% peer-to-peer. You'd need a relay server that acts as a server to both peers that will forward the packet form the sending client peer to the receiving client peer. Of course, the disadvantage of this is that you now have a fixed cost of maintaining a server to support your app just like traditional client/server systems but in this case you're using peer-to-peer to reduce server costs, not eliminate the server.
One example of this "hybrid" approach is cryptocurrencies like Bitcoin and Ethereum. They need a core group of servers to exist in order to work. However, for these protocols the servers run the same software as the clients - they're all just nodes. The only difference is that you don't shut down the servers whereas most people quit their bitcoin wallet once they've done using it (unless they're mining). Another example that is similar is the TOR network. There is a set of core TOR nodes that act as the "server" part of the network ensuring that the network always exist.
You said it yourself: "peers send packets to each other's client port". Therefore, the router will "accept packets from the same IP the request was made to".
Say, Alice is behind router A and Bob is behind router B.
Having learned their public endpoints from a server, Alice will send UDP packets to Bob's public IP, and Bob will send UDP packets to Alice's.
Having seen Alice talk to Bob's IP, router A will accept UDP packets from Bob.
Having seen Bob talk to Alice, router B will accept UDP packets from her as well.
That is, some initial packets might be rejected as coming from the blue, but after both parties have initiated communication on their side, routers will have no reason to block what follows.
In terms of Symmetric NAT Traversal using STUN 2003, by sending a packet to Bob, Alice is creating a door for Bob in A. On the other side, by sending a packet to Alice, Bob is creating a door for Alice in B.
The trick in UDP hole punching seems to be for the routers to reuse the same NAT tunnel for different IPs - so that the port discovered by a server is the same as the port reused for direct communication.
We can talk with different IPs from a normal UDP socket (by skipping connect and using sendto), so it's kind of logical that a tunneled socket would be able to do the same.
I have many SIP servers, but none of them have an external network. Can I use a server with an external network to proxy many SIP servers without an external network
Yep, you can.
Try using opensips or asterisk as a proxy to redirect calls to nat endpoints. What you’re trying to do is basically how sip providers work
Example: Proxy example
User A is your NAT SIP Servers, Proxy is NAT/External SIP Server and B is PSTN
Gateway or PSTN/SIP Provider
In case you have no idea how to get started, here is a useful article, it covers devices but we can consider that devices and servers are endpoints, so the article is for you:
Using SIP Devices behind NAT
This is called a SBC Session-Border-Controller.
Have a nice day.
I was implementing a sip client for android and i installed Asterisk SIP server(installed in windows 2003 server).Testing with JITSI client.But problem is "able to communicate when both clients are in LAN" Where as if i try to call a client from out side the LAN or through wifi, I'm able get the call but not able to hear the voice on both sides.
-I have enabled ports 5060 in fire walls too
port 5060 is for SIP Messages communication only. The media (audio) is going through RTP packets, which go through their own ports.
Check out in your asterisk rtp.conf file the RTP port-range (if I am not mistaken the port-range is 10000-20000 by default).
You have to also open that port range in your firewall settings.
Update:
it will always work in the LAN, because that port range is enabled by default in Asterisk. It won't work if any of the devices is outside of the LAN (and the port range is not opened in the firewall), because the ports defined in the SDP bodies won't be accessible.
I am trying a server to get data "www.example.com" with the port "xxxx" and my ip is "192.168.10.6". The server has to send the response to my app through port "yyyy". I sent a request to the server, but the sever sends the response to the ip "203.146.0.9" port "yyyy". And the server shows the log as "Connection rejected by 203.146.0.9:yyyy(port)".
I am very much beginner to the network programming. According to my knowledge the server sends the response to my DNS/router. Which not accepts the communication on that port.
My iPhone app listens the port of the device and not the dns port. How to make my app to listen the DNS port or else how to make the DNS to forward the response comes from the particular server to my local iP.
I gone through some post and some specified the "Bonjour". But I have no idea about that. Can anyone please help me by pointing out such example or documentation to clear this issue?
Short answer: you can't
Long answer:
Whenever you connect to a server through your iPhone, the phone forwards the request to the carrier's router via 3G or GPRS or some other protocol, which forwards the connection to the destination server. On the receiving end, the server sees the router's IP address, not the phone's. Actually, the phone's IP address only exists on the carrier's router, and nowhere else on the internet. You cannot create a public server from an iPhone (only maybe on a local WiFi connection, or if the carrier assigns the phone a public routable IP address). Therefore, you cannot initiate a connection from your server to some iPhone. If you want two way communication, you can however use the iPhone to connect to the server and on the server side, use that channel to send data to the iPhone. NAT may be another solution, but once again, it requires special provisions from your carrier, which may be an option for you, but usually not your clients having iPhones.
Hey I'm trying to get a CFStream connection going over 3G. I can get it working over wifi using the host name, but when I try to connect directly to the ip address it fails.
Is there a guide out there on how to connect over 3G?
Thanks
ASH
You can use NAT traversal in some cases. This is not a guaranteed method and depends on the type of NAT so you will still need a relay server if you want to guarantee connectivity.
A general rule is if both clients are behind symmetric NATs then a relay server is required.
If only one NAT is symmetric then STUN, ICE, methods can be helpful in establishing P2P connections.
The following might help you:
Interactive Connectivity Establishment see en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
PJNATH Open source project for NAT traversal in SIP/VoIP solutions see PJSIP.ORG
When you are connected to 3G then you are usually behind a router that implements some 'NAT' scheme. This means that your iPhone gets a private internal IP address on the inside (the 3G network) and a shared 'real' public IP address on the outside (the Internet).
This is all fine when you are just a client connecting to services on the Internet, but it will fail horribly when you try to connect to other clients in the same situation.
There is no simple solution for this. Programs like Skype work around this problem by using intermediate servers with public IP addresses that can relay network traffic between hosts behind such 'NATted' networks.