This is weird to me. The reason these modules exist is to help these protocols run, and they generally don’t work well (or at all) without them.
But if you’re seeing problems and they are resolved by disabling them, then you might want to try this approach instead.
uci set firewall.@defaults[0].auto_helper='0'
uci commit firewall
Then restart the router or Gargoyle firewall.
This is assuming running a recent version of 1.15 of course.
SIP ALG
Moderator: Moderators
Re: SIP ALG
https://lantisproject.com/downloads/gargoylebuilds for the latest releases
Please be respectful when posting. I do this in my free time on a volunteer basis.
https://lantisproject.com/blog
Please be respectful when posting. I do this in my free time on a volunteer basis.
https://lantisproject.com/blog
Re: SIP ALG
I don't know what's going on here. Yesterday, it would work when connecting directly to the WAN side of the Gargoyle router (running 1.15.X (Built 20260105-1130 git@faed9d8a)) but not reliably on the LAN side. Today, the phone was also struggling to even connect to the server when connected to the LAN side. Timeouts and retries. But eventually, it would connect and seems to stay that way now. It's an old phone running Android 8.0, so maybe that's not as good as it should be. Currently, those helper modules are enabled.
Re: SIP ALG
Make sure your SIP registration timeout is no more than 180s (120-150s might be safer).
Using TCP (or better TLS) connections instead of UDP connections, where supported by devices and the VoIP provider, can often also be more reliable on good quality (i.e. sufficient bandwidth and no packet loss) networks.
A couple of traps I know of with SIP setups if multiple SIP devices are involved:
Using TCP (or better TLS) connections instead of UDP connections, where supported by devices and the VoIP provider, can often also be more reliable on good quality (i.e. sufficient bandwidth and no packet loss) networks.
A couple of traps I know of with SIP setups if multiple SIP devices are involved:
- have each device connect to a different "extension" (most VoIP providers don't support multiple connections to a single "extension" so multiple extensions and ring groups are usually required)
- have each device use different source port numbers (default is usually the same as the destination port number but this doesn't work reliably with multiple devices connecting through NAT)