6 ms·
Excellent article, and sections "NAT Problems" and "NAT Solutions" are a good starter on that topic. Except even third-choice solution is not always feasible.
by francescovv 3y ago
Excellent article, and sections "NAT Problems" and "NAT Solutions" are a good starter on that topic.
Except even third-choice solution is not always feasible. Reserving fixed RTP/UDP port range is not possible with carrier-grade NAT, which is quite common with residential ISPs and nearly-universal with cell ISPs.
Fourth-choice would be to reserve port range on a personal server (which would run B2BUA, asterisk in OP's case; or an RTP proxy), and force calls, including media, from/to SIP handsets to go via that.
- astrobe_ 3y agoOne often sees the STUN, TURN or ICE protocols around SIP-based VoIP, I believed they were supposed to help solve those issues?
- deno 3y agoYes, Asterisk can poke holes in NAT on its own just fine. I was surprised how pessimistic the article is on this. I have systems running for months and years behind NAT with no issue. You might have to disable direct media (endpoint/disable_direct_media_on_nat). Also, this is just uptime related tip not NAT, you must explicitly set registration/max_retries to a huge number otherwise Asterisk just gives up permanently at some point. It’s a really weird default.
- singpolyma3 3y agoAre you doing calls to/from other sip URIs that are also behind NAT, or just using your trunk and internal extensions?
- deno 3y agoTrunk and internal, and I usually put all the phones in their own VLAN w/o direct Internet access. I don’t really see a use for dialing arbitrary SIP URIs. If I need to add a remote phone I’ll just connect it directly with a network tunnel.
- numpad0 3y agoThey don't always work... The idea is if you send UDP packets to destination so arranged by middleman(STUN) or to a proxy so arranged by middleman(TURN) as an outgoing traffic, your Wi-Fi should be smart enough to set up a temporary NAT entry to allow responses to reach your $LOCAL_IP:$PORT. In reality, the Wi-Fi may have short memory or may be dying behind a refrigerator covered in dust and not able to handle all necessary combinations and ranges of addresses and ports, resulting in various partial failures such as one-way audio or missing participant in a group call. Fifth-choice option is to just encapsulate everything into a VPN, preferably L2 VPN over HTTPS to a server on a global IP. If it isn't working, there must be no Internet.
- remram 3y agoWhy would that be more reliable than TURN? If your router "forgets" about established streams half-way, your VPN will not stay connected either.
- astrobe_ 3y agoUDP is unreliable transport by specification, so I guess that if a network equipment such as a router cannot cope with the general workload, it would probably sacrifice UDP first without a second thought.
- remram 3y agoIf you don't have any evidence, guessing that routers/modems prioritize IP packets based on the next protocol sounds like a conspiracy theory.
- astrobe_ 3y agoHuh? It's an obvious thing to do. If you have to drop a packet because your queues are full, any engineer with an IQ over 50 will pick the victim from the UDP packets, because the sender expects it might happen, and also because it won't necessary cause a retransmission - e.g. an RTP packet.
- jeroenhd 3y agoAll of the NAT problems would instantly to away with IPv6, but with adoption still at a meager 50% I suppose you'll need a PBX of some kind to receive at least half the calls. For those stuck behind CGNAT, there are guides online for how to set up a VPN to a cheap VPS and forward all network traffic to your network so you can have almost-real connectivity at home. If you're content with 50mbps, you can even use Oracle's Always Free tier.