Guys, Thanks for the quick response and advice...always helpful as usual On Tue, Jan 11, 2022 at 8:07 AM Stuart Henderson <stu.li...@spacehopper.org> wrote:
> 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. > > >
