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