SIP trunks, to reap their full benefits require centralized WAN architectures: Companies that implement SIP trunks find it necessary to overhaul their WAN architecture to move from a fairly decentralized communications model to a significantly more centralized one.
While organizations can use SIP trunks, SBCs, and communications session managers separately, these components perform a wide range of complementary functions and should be integrated. Organizations that are deploying collaboration should consider the integration of SIP trunks, SBCs and session managers as integral to their enterprise communications strategies. This means that the dial plan across the SIP trunks, SBCs and session managers need to be managed centrally and in real-time … a non-trivial requirement.
A centralized SIP trunking environment is not static. Real-time collaboration services and features are frequently modified on a going-forward basis (very different from the data world). An example would be changing routing instructions for toll-free calls, or handling exploding demand for HD videoconferencing (100%+ growth/year). Depending on the change order, the change may require CPE modification too.
Today, SIP trunk service/feature modification processes are not well automated by service providers. All SIP trunk SPs have impediments in process (i.e. order - test/validate with network and CPE – release), resulting in delays and added costs.
Maintaining resilience across a geographically dispersed enterprise footprint is also a key challenge for SIP trunks. When deploying SIP trunks, multiple aggregation points are required to maintain local direct inward dialing (DID) for consumer-centric business operations. This resilience means multiple configuration tasks must be completed (both primary and secondary aggregation points, and central and local access points) during the provisioning and MACD processes.
