I've run A&A's SIP service over a number of ISP routers. I only remember having to change router settings once - I think it might have been Plusnet maybe a decade ago. STUN should handle the case where the local IP is not the same as the public IP, which is the case for domestic NAT and for CGNAT.
In the case of A&A, having IPv6 should avoid NAT altogether, and that is what A&A recommend: they effectively say they don't really support their SIP service unless there's Proper Internet (which they provide to their customers, of course).
The VPN service is for other things that using their VOIP service - for example, inbound connections to machines on the network. For SIP you could also use it for inbound SIP trunks to your PABX - ie rather than your client talking to A&A's server, an A&A customer hosts a SIP PABX on their network and allows clients to connect to it. For that you need incoming public IPs.
Plusnet made a one time charge of £5 for a fixed IP address. Dynamic DNS services can be an alternative. Voip clients don't have to be behind a fixed adddress as they register with a server using a DNS name.
Sip clients establish a connection to a Sip server by registering. The clients can be behind Nat. They keep reregistering maybe every minute.
I use three different Sip providers. They are the same in that respect. I use a Gigaset N300 Dect base station and Gigaset Dect phones. The N300 can register with several different providers at the same time.
We've just had our fibre lit up, and went with Zen, as we already had ADSL from them as a backup for <undesirable rodent> Media, who have been unable to deliver a reliable cable service for the 12 months we've been here.
Can't fault Zen, upgraded the contract with no penalty, even kept the same static IP on the fibre as we had on ADSL. Not quite so impressed with the physical install by City Fibre. First crew gave up, supposedly because they needed a crane to get over some trees. Second crew managed without one, but pointed out the first crew hadn't put up a long enough drop from the pole to reach the wall box, which is probably why they scarpered. Luckly they could move the wall box and got it working, though I don't like how the flimsy fibre cable (~4mm jacketed) is nailed to the wall, and a good breeze will probably bring down the drop cable, along with a few branches of the tree it's wrapped around.
Download speed is top notch, rock solid 100MBps (that's Bytes...) downloading a 35GB game on Steam. Ping isn't much better than cable / ADSL. Haven't been able to get anywhere near Gbit upload speeds though. With a fast laptop straight in to the Zen router (FritxBox) gets ~450Mbps. By the time it's been through our firewall, internal router and a couple of switches the best we see on the PC is about 60Mbps up, so not much better than cable was (download on the same PC gets the full Gbit speed). Need to figure out where the bottleneck is, probably some MTU or window size issue internally, as the physical is all Gbit. Another job to do, and I already spend half my working time looking at TCP traces and comms dumps :(
Anyway, looking forward to a chat with VM when the contract comes up for renewal. Hopefully we can keep a cable service as a backup, but dropping it down to the lowest (cheapest) tier, just out of spite for them screwing loyal customers with an annual inflation+4% cost increase. Intrestingly they recently increased our service to 1Gbit "for free", probably knowing we'd be looking at fibre very soon. Wonder if they were hoping to slam us into the higher price tier at renewal?
So now we have three bits of wet string that can supply broadband - copper pair, co-ax cable and fibre. We want to keep two of those live, as internet is essential, but are they likely to deprecicate the coax and copper lines, and insist all future broadband is fibre only? Time will tell...
What about IPv6 then?. While futzing about on the new Zen router, I noticed it showed some IPv6 addresses, a /64, presumably for the WAN link, and a /48. Nice, I thought, as we've been using Hurricane Electric to give us an IPv6 /48. Quick call to Zen confirmed thay yes, IPv6 was live on our service, so started to see if I could get it working - much better to have a fast direct link than a tunneled one. Then the nightmares returned from when I set ip all up in the first place. IPv6 is an over-complicated, unreliable, incompatible abortion of a protocol. With IPv4 you configure your address, some static routes, and NAT if you want it, and off you go. With IPv6 you have to hope some SLACC or DHCPv6 gets you an address, and if you're lucky you catch a Router advertisment and get a default route. If you want to have static routes to private networks you need to configure addresses carefully, as the auto ones may change. Then you have to configure your /48 prefix on all internal systems (and if you change ISP you need to change it, and all the corresponding firewall rules). It's all do-able, but a right-royal pain in the arse. In the end I decided IPv6 was more trouble than it's worth, and instead of switching to an ISP-supplied IPv6 connection I ripped it all out, removed all the AAAA records from the DNS and dropped the HE tunnel. Funny how everything still works just fine.
IPv6 must be one of the worst technical innovations of recent times (I don't count twitter/facebook/etc. as either technical or innovations). Had they just added a few bytes to the IPv4 address range, and kept everything else the same, by now the new protocol would likely be in universal use, but instead they had to make it complicated and incompatible, and as a result unreliable, insecure and (still) poorly supported.
[snip] The slowest that VM do now is 50Mb at a cost of £42/m - which is still steep compared with most ISP broadband over CityFibre!
For the record they increase annually by RPI+3.9% against CPI+3.9% for most other ISPs. Mine went up from £36 to £42 in July as RPI is usually around 2-2.2% higher than CPI!!
Most ISPs now support IPv6 and around half the traffic to the more popular web sites uses it. VoIP works perfectly well over IPv6 and there are so many addresses that there is no excuse for any kind of NAT. John
SIP wasn't designed to work behind NAT. There are various kludges in SIP implementations to cope with it, and at least one in SIP itself. Not setting up those kludges properly is the biggest reason for getting one way, or no way audio, and calls that drop after 32 seconds.
The kludge in SIP itself is rport, which tells the other end to ignore what it is being told about the initial signalling address, and just reply to wherever the request appears to have come from.
The cleanest operation tends to happen when the user agents are either told, or work out, what their public address is and send that in the protocol.
Other old kludges, are pretending rport was used even when it was not, ignoring contact headers and using the de facto signalling address, and assuming media goes to where it comes from, rather than where the signalling says it goes (only one side can use this tactic).
For WebRTC, there is ICE, which seems to be that the user agent makes guesses as to the possible correct address for media, and the other side tries them in turn, stopping if it finds one that works. That can sometimes result in very slow starts.
They are newer, and at least WhatsApp's protocol in not published. However one of the ways they are made to work is by going through a public server, which is, itself, not-natted.
I suspect, also, that ICE came from the tactics they used.
They were designed, from the start, to work with over a consumer oriented web browsing service, whereas SIP was designed to work on the internet.
It is a horrible mess. I support VoIP phones in half a dozen countries with hundreds of numbers. Some phones, such as the Gigaset cordless phones work remarkably well behind NAT. Many others need a bit of help. This usually means setting up tunnels so that the phone can have a public IP address (either IPv4 or IPv6). I have found the A&A service to be more reliable than several alternatives that I tried. I don't (yet) use it myself, but their low-cost L2TP tunnel service would solve a lot of VoIP problems. Many phones have L2TP tunnel support, although some are rather flaky and there are firewalling issues to consider. I once accidentally left a VoIP phone open to the internet and within a few hours there were multiple simultaneous calls to eastern Europe. Fortunately, the A&A fraud detection algorithm spotted this and shut down the number! John
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.