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.
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 am just experimenting with my phone system and I'm wondering how both endpoints know they are on the same LAN, I have both endpoints breaking out to the cloud phone system with two separate public IP addresses, I've segmented them off from each other with a firewall so they can't see each other however every time I attempt a call between the two end points the call is setup as a peer to peer call and attempts to traverse the local LAN via RTP through the firewall, the firewall blocks the RTP communication and the call has no audio.
I am just wondering how both endpoints are realizing they are behind the same firewall/router since they are both registering with the cloud system from different public IP addresses, I wanted the call to be bridged in the cloud and not traverse the local LAN but somehow both endpoints only attempt the call over the LAN every single time and no idea how they're realising they're on the same LAN.
Anyone else encountered this before?
SIP endpoints don't have to know they are on the same LAN. They just make best use of the IP addresses you provide.
Your INVITE request will provide more insight, but from what you write my guess is that you use public IP addresses for your contact/request URI and local IP addresses in your SDP offer. The local IP addresses are probably routable through the firewall.
With ICE and STUN endpoints may select the best IPs for media traffic - but for that to work the RTP/STUN packets should be able to traverse the firewall in your LAN.
Attempts to communicate directly may mean that LAN uses IPs from public ranges or endpoints a SIP proxy were not smart enough to detect NAT in front of your LAN.
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.
I currently have issues with SIP User Agents behind a symmetric NAT connecting to my SIP client, which is an IVR voice service.
I read that Asterisk has a solution for this in the sip.conf, where I can set attribute
nat=yes
and this will ignore the IP and Port in the SIP headers and use the one for the SIP request and also waits for an incoming RTP stream to reply to.
I'd like to make use of this feature as we already have an Asterix server installed for AIX requests.
What would be the minimum configuration required for Asterix to act as the man in the middle on a new port as 5060 will still be used to connect directly to the SIP client? I don't care about authentication etc. I just need the Asterix to act as a SIP relay.
Thanks
K
You may also need to have "canreinvite=no" in the [general] section of your sip.conf.
That setting keeps Asterisk in the call path, otherwise voice traffic may be sent directly from one endpoint to the other.
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.