Interesting, one evening I was logged to a VPS via ssh and I noticed that my IP there was different to that given by speedtest.net.

You managed to avoid their exorbitant £10 per month charge for a static IP.

They certainly push the aspect of using VOIP on their website so it should work.

Tim

It’s worth also directly testing with a soft phone client on a laptop or pc. This eliminates any added complication with the ATA as it’s straight VoIP endpoint to provider. In fact leave the ATA disconnected if testing to the same VoIP provider in this way.

Using a laptop / PC soft client means you can check
1) connection behind the WRT. This takes the ATA out of the loop
2) direct laptop wired network connection to the ONT by setting the pppoe client connection on the laptop. This takes the WRT out of the loop

Soft phone client testing means you can more easily flip between port5060 and another VoIP provider for further testing.

In reply to a post by TimJ:

Thanks you for all your replies, Very useful.

The current situation is that searching the openWRT forum I found a post about similar symptoms and their fix was to install nf-natfiler-extra kernel modules, I have now done this, it remins to be seen if it has fixed the problem.

Port5060 have come back saying that VOIP "should" work through the double NAT of my router and CGNAT, but it is not guaranteed. They have suggested as a test connecting the SPA122 directly to Airband PPoE feed, this would show if the problem is my router or CGNAT.

Thanks for the links , I may well resort to studying and understanding the protocol and using tcpdump on the router.

As said try also with a soft phone connected (and with another VOIP service on a trial basis). This way you can connect directly from the Airband ONT port removing your router and ATA from the equation to simplify fault finding

As said try also with a soft phone connected (and with another VOIP service on a trial basis). This way you can connect directly from the Airband ONT port removing your router and ATA from the equation to simplify fault finding

Thank you for your suggestions, they are appreciated.

The problem is very intermittent so to be meaningful any test has to be for weeks, and thus has to be compatible with maintaining both incoming landline and full house Wi-Fi.

The initial VOIP setup was using Airband supplied router, this quickly showed the incoming call problem and after a few days we went back to just the landline. I then setup the openWRT router and went back to VOIP. We had about 10 days error free use, but then 3 days with around 50% unconnected calls. ( we get around 3-4 calls per day). Since installing the Nathelper-extra package we have had 3 days of error free service. We also have had 3 evening of buffering free iPlayer/Netflix. After 3 days is this significant?.

If the problem is not fixed I plan as a temporary test I plan to try using the SPA122 as the router. This would eliminate my router.

The Airband fibre comes through the wall and terminated in one of These, I assume this is the same as an ONT, then a cat5e to the router. Would it work if I put a gigabit switch in this line and connected both the router and the SPA122 or slaptop with softphone? I wonder if Airband supports multiple sessions?

I am also concerned about oddities around the public IP. Tarka-the-otter reports IP address changing with time, In late Dec I definitely saw that the external IP when logged into a VPS using ssh showed as 1 different to that shown by speedtest.net.

The last 3 days I have had a script running checking the public IP using both ssh (port 22) and https (port 443), both have remained the same and constant.

That sounds quite positive with the Nathelper-extra patch applied. Three days error free is good, but if there are likely periodic NAT address updates in the carrier network, you may not see the change (and hence suffer a potential VoIP issue) unless testing over a longer term. I would want least a week or longer to deem it reliable and if you can push more calls through, even test calls inbound from your own mobiles to push the service.

The Genexis device you linked to is indeed an ONT (aka ONU). It will require a router (or PC) directly connected to its ethernet port to establish a PPPoE authenticated session back to the Airband access concentrator. You can't just connect a switch directly from the ONT (unless that switch is routing/Layer 3 capable but I digress) and then router and SPA etc hanging off the switch.

Either you need an actual router, a PC or another device (like your SPA) that is able to run a PPPoE client first in line. This is effectively your gateway. Then either the same (or separate device) to route/share/distribute the service from the LAN side to all the other devices inside your network. Hope that makes sense.

I don't know too much about how Airband backhaul their network - there are old press articles floating about which suggest they use a mixture a wireless towers - so its certainly not fibre all the way back. There may be more to these intermittent issues than just CGNAT.

Edited by Pheasant (Mon 29-Mar-21 22:06:28)

Thanks for your comprehensive reply.

It has now been 4 days and counting, so I am hopeful, but time will tell.

During the initial meetings Airband said that their "cabinet" would be located at the local pub and there would be a Microwave backhaul. This was to speed up installation,but their plan was eventually to move to a Fibre backhaul.

however they installed their "cabinet" immediately adjacent to an openreach FTTC cabinet, and the installation engineer told me we were one of the very few area that had entirely a fibre backhaul.

A traceroute looks like this.

tim@tim-Linux:~$ traceroute 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
1 OpenWrt.lan (192.168.1.1) 2.478 ms 2.613 ms 2.850 ms
2 10.247.254.1 (10.247.254.1) 9.715 ms 10.939 ms 10.184 ms
3 10.255.255.153 (10.255.255.153) 13.569 ms 14.015 ms 14.009 ms
4 asr1.lr1.thn.air-band.net (185.130.156.78) 13.238 ms 13.511 ms 13.494 ms
5 195.66.225.238 (195.66.225.238) 32.174 ms 32.482 ms 32.959 ms
6 dns9.quad9.net (9.9.9.9) 14.197 ms !X 7.860 ms !X 9.646 ms !X

No worries. 🤞that kernel patch on the WRT has done the job.

Trace route looks absolutely fine. Just an extra hop than what I’m seeing on my setups. Looks like you did the test over WiFi, not that it matters. Looks good.

Well after 4 good days we had another incoming call fail. Usually things correct themselves, but this time it left no dialing tone and incoming calls getting number unavailable. The lights on the SPA122 appeared to show that it was stuch in aloop rebooting. The router log showed that theethernet going to it was continuously going up/down. A power cycle sorted it out.

My monitoring of the public IP and traceroutes did not show any signs of change.
I raised a ticket with Airband, but except for an automated reply nothing, so as expected.

I think my options are, (sorry just thinking out loud)

1) Give up with VOIP and just keep the copper landline, and put up with the cost of £12.60 per month
2) Do we really need to maintain a landline number? It used to be essential due to poor mobile coverage, but we have both recently updated mobiles, and now have reliable WiFi calling.
3) Airband advertise VOIP as an advantage so ask them who they recommend and how to set it up.
4) Tell Airband that we cannot get VOIP to work reliably, VOIP supplier suggest changing to static IP, try to avoid being charged for it. This would also have other advantages.
5) As a test connect the SPA122 directly to the Airband feed and also use it as the house router. This would either clear or implicate the router, but i am now sure what the next stage would be.
6) Try replacing the SPA122 with a softphone on one or both mobiles. If this worked it might be a permanent solution.

Other thoughts I have had are are to run Asterisk on the router or to to create a VPN between the SPA122 and my VPS thus bypassing Airband. But I am not sure that I am technically up to either and that they would probably just complicate the issue and make things worse.

I think that I am leaning toward 4 and or 6.

Thoughts welcome.

In reply to a post by TimJ:

The lights on the SPA122 appeared to show that it was stuch in aloop rebooting. The router log showed that theethernet going to it was continuously going up/down. A power cycle sorted it out.

To me that suggests you have internal network issues going on - the SPA itself with the reboot loop. Also the flapping Ethernet port on the router needs checking. Neither of those sounds good.

The flipping port on the router was due to the SPA reboot loop. But I agree it does suggest a problem with the SPA, but this was immediately after the failed call, so which is cause and which is effect?

Points to using the softphone in place of the SPA, it is also very easy to do.