Any way to have remote extensions register alternative to port forwarding?

[thetelcoguy (telcoguy)]

For one of my PBXAct (FreePBX) setups there are two internet connections;
One is the main connection - a fast cable connection with static IP.
Sometimes this cable connection goes out, so that is why this setup has a backup SIM (LTE) internet connection which auto failovers in case the cable connection goes out.

The problem is that the LTE connection doesn’t have it’s own public IP address (no dynamic and no static IP address); the way it works is that the SIM card is under the ISP’s network and it’s sort of like a “node” on their network and they assign it a private IP address from their subnet. So this means that I cannot do any port forwarding for the LTE connection (since it’s as a private IP on the ISP’s network and doesn’t have a public IP of any kind) which means in the event the main cable connection goes out, remote extensions cannot register to the PBX (since no port forwarding works on the SIM card connection due to ISP restriction!).

So I was thinking - is there any way to have a sort of “proxy” where the remote phones “register to”, and the PBX “sends/funnels” the traffic to/from these remote extensions in a way where no port forwarding is required? Like a SBC or something that links the connection from the PBX to the remote phones, so that it works without need for port forwarding. Like how TeamViewer works - when the client computer you’re connecting to has TeamViewer application open, you can enter the ID/password and connect without need for port forwarding since the application opened the port (it reached out to TeamViewer’s proxy/server). Also for those who want to host a website but don’t have their own public IP (it’s more common for ISPs to limit handing out of public IPs so their users get a ‘private IP’ on the ISP’s subnet instead of their own public IP), there are “proxy” services like cloudflared where you install it on the machine and it funnels out/sends out the traffic to the server thus eliminating need for port forwarding… I am looking for this type of solution but for SIP + RTP ports on the PBX. Like a service you can install which “connects” the requests.

Keep in mind that DDNS is irrelevant in this scenario since the backup SIM connection doesn’t have it’s own public IP so even if you try to connect to the PBX with DDNS, it’s useless since no ports are/can be forwarded through the SIM connection.

I’m sure someone has thought of something like this!!

[david55]

A SIP proxy would have the the same problems as Asterisk has. It might have more, as it might lack the options that Asterisk has for coping with user agents that don’t know their real address (force rport, symmetric RTP, and rewrite contact). I’m not sure how many proxies support ICE, which is another way of getting round this sort of problem for media. I suspect most of them would rely on being a signalling only proxy, and therefore push the problem back onto Asterisk.

You really need to understand the details of the operator’s NAT processing to know what is possible. They must be adding some temporary forwarding rules for some things to work at all, although, I suppose they could implement all the common UDP based services (e.g. DNS, and NTP) themselves, and only forward TCP, which would probably leave you with a TCP based VPN as the only choice. The problem with TCP for voice, is that it waits for retransmission of lost packets, so everything else gets delayed behind that.

[david55]

@david55

I suppose they could implement all the common UDP based services (e.g. DNS, and NTP) themselves

However, the expected common UDP services include streaming media, so I think they need to handle extended periods of dynamically added port forwarding.

I also wonder about, so called VPN, privacy services. I think they have to use UDP and presumably keep a sufficient level of traffic to avoid dynamic rules timing out. Of course they need their own dynamic rules, but is possible their implementation is more benign, or better documented.

Using a mobile push service might also help, even if using Androids (which allow you to prevent apps from sleeping), as they will result in a registration just before the start of the call, meaning that the dynamic rules, for the response to the registration, may still be live for the INVITE.

There are various options that you can use to ensure that there is a continuous background level of traffic on signalling and media paths, which may stop dynamic rules timing out. (The only weakness I can think of there is that true silence can result in extended periods with no RTP.)