On 2022-01-11, Chris Cappuccio <ch...@nmedia.net> wrote: > Atticus [grobe...@gmail.com] wrote: >> It isn't just SIP. You will need to set up NAT traversal and make sure RTP >> traffic can pass as well. Setting up a STUN server and configuring the >> clients to use it should aid in the NAT portion. The RTP traffic should be
Sometime STUN can be used to optimise things (getting call media direct between endpoints rather than going via a PBX) but it adds complication and is hardly ever _needed_. >> fine as long as pf is being stateful. If the phones register over SIP fine, >> but have no audio, then the RTP traffic isn't getting where it should. IMO, >> it makes more sense to use an on-site PBX so you only have to deal with >> traffic to/from the one host, but that doesn't sound like an option for you. >> > > Using Asterisk as a SIP server and media gateway, on a public IP with phones > behind NAT, you can get NAT traversal via RFC 3581+symmetric RTP (sip.conf > nat=yes) without STUN and without a firewall SIP ALG. > > Freeswitch and also Kamailio + rtpproxy can do similar. These gateways are > all capable of symmetric RTP, and have been since forever. > > If you are connecting phones inside of your NAT to an outside SIP provider, > or PBX device, make sure the PBX has a public IP (not behind another NAT > itself) and has symmetric RTP enabled. Most end-user-facing SIP providers (rather than wholesale providers) seem pretty capable of handling client devices or PBXs behind NAT. Generally getting this to work natively requires that whoever is configuring it understands how the protocols work, and software that allows things like sending RTP back to the IP that a SIP message was received from, and sending SIP keepalives back to the source port that it received requests from (frequent enough to avoid them timing out). It's not hard, but is often not something that techs from a telco will do. Another way to do things is to use VPNs and bypass firewalls/NAT that way.
