Redundancy
A SBC forms a Single Point of Failure (SPOF). Unless a redundant SBC is deployed it will lead to reduced availability.
Multi-Tenancy
A SBC is designed to provide functions for a single tenant (company). Even if the SBC is virtualized, every SBC instance has its own customer data that needs to be managed with every modification.
Controlled Media Path
The connection via the SBC increases the transmission path and delay. If a SBC is hosted in a public cloud, there is no quality guarantee of media traffic.
Full Control and Management
A SBC is a separate network element that has its own management environment. Automation of real-time orders can therefore be a real challenge.
Security
There are security threats especially when a SBC is managed by a third party.
Delay in Handling Porting Orders
In the Netherlands, number porting is carried out real-time and on-demand within 15 minutes. If a number porting order is implemented for the retention of a telephone number, 3 domains must be managed separately. The number porting will have to be done manually in different domains, such as the SBC. This leads to increased downtime for a customer.
Coherent Telecom Settings
Country specific telecom settings, such as filtering, CLIP / CLIR, number normalization, over-usage management and forwards are influenced by the SBC, which may result in deviations in the telecom functions between Microsoft platform and legacy telecom domains.
Customer Self Service
Migration to Microsoft Teams requires frequent adjustments to settings, numbers and reports. Because the control of the SBC cannot be fully automated, it will be a real challenge to offer customers self-service.
Third Party Equipment
Because the SBC is a third-party network element, additional tests and maintenance will have to be scheduled for adjustments and upgrades.
