SipXcom with AWS and SIP ALG issue

128 views
Skip to first unread message

Tommy Laino

unread,
Sep 24, 2020, 9:10:23 AM9/24/20
to sipxcom-users
I've been running a few SipXcom instances in AWS on ec2 instances for sometime. They've been rock solid for the most part. As Covid took its toll, a few of these instances are moving from their offices into home based workers. Seemed simple enough from my end, some minor port forwarding or VPN configs and phones registered with no issues.

Then came the complaints from only certain home workers. After some digging I realized it was a SIP ALG issue tied with Verizon FiOS service. However, in the newest Verizon routers, SIP ALG is not able to be disabled. I've been having fits trying to get these remote workers up and running. Does anyone have any suggestions on how to get this working or any type of workaround aside from replacing everyone's home router?

Thanks in advance

Gerald Drouillard

unread,
Sep 24, 2020, 9:44:37 AM9/24/20
to sipxcom-users
Maybe change the transport to TCP will work 
VPN


--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/CACCT1oCUsgs0mvpt05q86X_ae6qqLf_FkH_0CRveT%3DyMOiA_Aw%40mail.gmail.com.

Todd Hodgen

unread,
Sep 24, 2020, 12:51:43 PM9/24/20
to Tommy Laino, sipxcom-users

How about setting up VPN and having them log into the system via VPN?   That should bypass the SIP ALG issue.

--

Tommy Laino

unread,
Sep 24, 2020, 1:38:43 PM9/24/20
to Todd Hodgen, sipxcom-users
I've tried the Yealink phone with OVPN access. It connects fine but the same issues remain. I'm assuming because it still routes through the Verizon router

Jim Gill

unread,
Sep 24, 2020, 2:40:05 PM9/24/20
to sipxcom-users
On the OpenVPN Server ->  Tunnel Settings ->  Redirect IPv4 Gateway -> Force all client-generated IPv4 traffic through the tunnel  is checked (true).  They will be complaining about lag when posting to Instagram but the phone should work. 

Charles Chalekson

unread,
Oct 21, 2020, 1:18:20 PM10/21/20
to sipxcom-users
I am having occasional similar issues where calls get dropped and losing voice connection [using Bria mobile iOS].  Seems to happen mostly when a worker is using their soft phone place the call, starts ok, but then audio is lost.  With one employee that let me look at their router, ALG is turned off.  On the network router the PBX uses, SIP signaling [5060] is using TCP and Media [30000-31000] is using UDP.  Would changing the media to TCP help at all?  Also any recommended settings changes to the employees router?

Louisa Voice

unread,
Oct 22, 2020, 5:54:02 AM10/22/20
to sipxcom-users
I would add a firewall rule to the home router that allows UDP port 30000-31000 traffic from the public IP address of your network router -the Bria mobile client by default has SIP keep-alives enabled, keeping the 5060 firewall port open. To work around the SIP spammers, I'd also suggest using another port than 5060 for SIP signaling between Bria and your network router.

In the northeast region, SIP ALG is purvasive. The Verizon Wireless (i.e. data over cellular) network has SIP ALG enabled by default, as does the FIOS router as well as the Sagemcom and D-link wireless routers on the cable side.  I've looked closely at the Verizon Wireless SIP ALG implementation, and it seems to append a 32 character UID to the extension in the Contact header, e.g. Contact: <sip:202-a643334f6bbe87...@10.20.2.18:5075. The Bria client registers with Sipxcom and can place outgoing calls, access voicemail etc. But for incoming external and internal calls, they go directly to voicemail as I suspect the Sipxcom registrar is looking for an extension, not extension+ 32 character UID. We are looking at ways to have the SBC strip out the 32 character UID in the contact header before sending the REGISTER request to Sipxcom. Until then VPN is a good friend - either build a standalone Openvpn server on Unix, or use Softether on Windows - both work with Openvpn Iphone and Android clients. Pfsense also has a built-in Openvpn server that can be leveraged.

Charles Chalekson

unread,
Oct 23, 2020, 10:06:39 AM10/23/20
to sipxcom-users
Thanks I'll give it a go.  If I change the port for SIP signaling on the Bria to something other than 5060, do I have to do anything else other than forward that to the office router LAN IP?  e.g, do you have to change ports or settings within sipxcom itself?

Louisa Voice

unread,
Nov 6, 2020, 3:44:57 PM11/6/20
to sipxcom-users
Hi Charles - no, if you change the port number in Bria, that port number will be tracked in the Sipxcom registrar - i.e. when you display the extension registrations, the extension assigned to Bria should have the port number in the registrar.

On a related matter, I have made progress on the origin of the extension+32 character UID that appears in the registrar. It is not SIP ALG that is generating this but a new version of Bria 6 just deployed to save on mobile phone battery life. One of the complaints about Bria 5 and earlier versions is that the application must always be on to receive and process invites, which drains the battery rather quickly. In Bria 6 when the Iphone or Android mobile phone goes to sleep, Bria sends a registration packet with extension + 32 character UID to Sipxcom and shows up in the Registrar. When an incoming call to that extension is issue, Sipxcom issues an Invite to a Counterpath notification server, who then wakes up the Bria client to process the incoming invite - this process significantly saves on battery life. At the moment, this power-saving strategy only works when Bria is assigned a public IP address (data over cellular) - it does not work at the moment when the Bria client resides behind a firewall. Incoming calls work about 50 percent of the time - when working, the invite comes into the extension, and then one sees an invite with extension+32 character UID send to the Counterpath notification server. The notification server responses with a 100 trying, and then Sipxcom issues a 180 ringing to the notification server. The notification server then wakes up Bria for the incoming call. When not working, Sipxcom never issues the 180 rings back to the Counterpath notification server. Any ideas on where to look to resolve this issue is appreciated. Pcaps are available if you reach out to me offline.
Reply all
Reply to author
Forward
0 new messages