The "SIP protocol support" module is a mysterious part of the UTM where you can only look and see 3 basic parameters.
Everything that's going on under the hood is undocumented but thankfully just works wonderfully as long as your device operates within ports 5060 to 5080. Port 5061 can even be TLS.
Sadly though, sometimes you get stuck with a VoIP provider where the developer just decided to pull a nonstandard port out of their hindquarters and hard code it into their devices. More on this below.
While SIP works well with this mysterious UTM module it's worth noting that not only is it undocumented but it is unlogged (at least I've never been able to find a log file that records the activity it magically allows). On rare occasion I have seen SIP ports being blocked by the firewall in the firewall log but turning SIP on and off or rebooting the UTM has always cleared it up.
Now for my problem: Enter phone.com (who is the service provider for a component being placed on a network I manage) who just decided to arbitrarily use port 6060 as the secondary SIP port on a new entry gate controller being installed at a client's site. This probably seemed cool to them because 6060 was 1000 higher than 5060. Fail!
Because they decided to do things their way, ignore the established SIP standard of port 5060 through 5080 (which the UTM SIP module adheres to), and make the ports they chose hard coded (non-editable), coupled with the fact that Sophos decided to make the interface non-customizable, I am left with no choice but to be the solution since I can't change phone.com's poor decision and I can't change the UTM SIP module either.
After combing through the UTM community looking for a solution, I thought for a moment that I might have hit pay dirt when a commenter in another thread believed that he can add the nonstandard port to a service definition group you probably never heard of, VoIP Protocols. As you can see below I have tried their suggestion but it does not work. Presumably because the SIP module's underlying code simply doesn't recognize this port as something it should do something with.
Even after restarting the UTM just to ensure that the port I added to the VoIP Protocols service definition group would be recognized by the SIP module this port is still being rejected by the firewall.
My understanding is that simply adding this port to a firewall rule for the device will not give us all the cool SIP stuff offered by the SIP module like QoS and hence will not actually work.
So my questions are these:
1. To assist in debugging, can anyone tell me if any of the SIP module traffic is actually logged anywhere? Even if it is only accessible via CLI. If not, is there a way to enable it to log?
2. Can anyone tell me if there is a way to add this port so that it will be recognized by the SIP module (since the above method fails) or do you all agree that the SIP module In all likelihood simply doesn't support this port and can't be customized to do so?
3. Failing a solution that works in 2 above, I can find nothing that shows how to manually configure SIP clients so they work successfully (probably because you shouldn't need to). Can anyone offer up a solution to make a SIP device work on a non-standard port through manual entries on the UTM, be it in the firewall rules or anywhere else needed?
Thank you for taking the time to read my post and I await your responses in hope of a solution.
This thread was automatically locked due to age.
