this post was submitted on 09 Nov 2023
1 points (100.0% liked)
VoIP
1 readers
1 users here now
Rules
-
Be civil. Disagreements of varying intensities will happen, but particularly vitriolic attacks will be pruned from the discussion.
-
Do not promote or advertise for any business, service or product unless responding to a specific request for recommendations. This includes recommending a user change providers when they have not indicated they are interested in doing so.
-
Do not send private messages to users, or invite users to send you a private message, for the purpose of promoting or advertising a business, service or product.
-
Do not invite, encourage, or seek help with engaging in unethical or fraudulent activity relating to VoIP, such as call spoofing, robocalling and autodialers, or fraudulent STIR/SHAKEN attestation.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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.