Hi
I manage a bunch of different SIP trunks (bunches of channels for in/out calls, coming and going from SBCs) from different providers. Generally when it comes to authentication, there are two methods:
- We give the provider our SBC IP addresses and if there are inbound phone numbers (DDIs), a priority list for inbound calls. They allow calls to and from these IP addresses without further authentication.
- They provide us a username and password and we setup additional config on our SBCs to cause a challenge request and then follow up with usually a user/account name, realm (something set by them) and a password. We aso have to give a priority list of IPs for inbound DDIs, although know there are other ways to do this.
Anyway, my question is does anyone see any pitfalls of using either?
Personally, I find the 1st method easier to setup but limiting in that I can’t just push calls from anywhere without authorising it first. The 2nd method is more complex to setup but once done, their end will allow a call from anywhere.
I guess the second is less secure at their end because I can lockdown my firewall ACL to block everything except them, but they have to allow anything with the right user/realm/password.
I’m thinking the u/P method was originally build with individual handsets anywhere on the internet in mind, rather than trunks between SBCs. It would make more sense so that you didn’t have to amend ACLs when throwing out handsets or apps left right and centre.
Whereas the IP authentication evolved for more fixed/infrastructure SIP trunking like SBCs to SBCs?
Thanks
You must log in or register to comment.
I don’t see how IP based authentication on a SBC/PBX has any issue at all really?
How often are you changing your SBC/PBX IP address? I would think hardly ever? Also, throw a load balancer in the mix as the authenticating IP and any change of IP address is resolved. However none of this affects where you are pushing calls from, as that is a question for the connection between your handsets and PBX/SBC. It should be invisible to the trunk as a geographical matter.
The issue of authenticating handsets in this way is kind of moot as I am never ever going to authenticate a trunk directly to a handset.
Companies sometimes failover to other internet circuits. Some companies don’t own their IP space and can’t do BGP to keep their public IP’s when circuits go down.
Some SDWAN solutions can help with this as an alternative.
That’s my question really, why is failover not being handled internally using internal networking like SDWAN. The only real point of failure should be the load optimisers or firewall, everything else should be invisible to the trunk.
I can understand failure at the load optimisers or firewall level being a problem, but there’s always a single point of failure somewhere.
Some SIP trunk providers only allow you to use 2 authorised IP addresses. In some cases we have over 10 SBCs for one customer but if we wanted to use the same trunk across all SBCS we’d either need to pay for the same trunk 5 times over or keep changing the IP.
From my point of view, as a VoIP provider, we usually only use IP address auth between our SBCs and other providers. Could be over the internet or L3VPN/MPLS. In this case, we protect inbound traffic with ACLs to only allow these authorized IP addresses to reach the SBCs.
And as for customers, we provide SIP credentials and SIP proxy + registrar. The goal is for them to be autonomous and register the SIP trunk from anywhere they’d like. This way, we avoid the tickets asking us to change our side of the config because they changed their IP address for example.
I don’t see any pitfalls for either of these methods, for me the use-case is different. And thus each have pros & cons.