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:

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

  • dVNico@alien.topBEnglish
    1·
    11 months ago

    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.