Thanks to both of you for the valued information. Much appreciated. @Atticus This was rather short notice.I wasn't aware that they had gone ahead with the service installation. Unfortunately in this case there's no on-site PBX. Understandable given the current work-from-home situation. The provider (Bell) is installing a dry-loop that should fix the issue in this case @Chris Thanks for identifying some additional solutions. I'll have to find a suitable solution for a separate client installation in the next 2 weeks. They will also use softphones and will not have any on-site PBX. On a separate note, I looked at all the logs but couldn't see any attempted/dropped SIP traffic from the softphones from any of the internal users or Bell techs during the morning testing. Shouldn't there be some traffic?
On Tue, Jan 11, 2022 at 1:18 AM 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 > > 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. >
