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
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.