As the number of Service Providers offering VoIP services is expanding, competition between them is rapidly increasing and causing them to differentiate themselves from each other by seeking additional services to offer their customers.

Figure 1 describes a typical IP-Centrex network in which business organizations use centralized services offered by the IP-Centrex application from the service-provider instead of deploying their own IP-PBX.

Service provider’s offer IP-Centrex services to SOHOs, SMBs and Enterprises for which they are required to guarantee fault tolerance solutions. This is expected by customers as well as the government, in order to provide telephony services that are constantly available.
 


Figure 1

Businesses have the freedom to connect to the IP-Centrex service with their legacy equipment, legacy PBXs and phones, replacing all the old legacy equipment with a pure IP infrastructure of IP-phones. An alternative is to combine both approaches and create a mixed infrastructure by maintaining the legacy equipment in order to reduce the migration to VoIP cost while expanding their infrastructure with IP-phones..


Figure 2 displays an IP-Centrex network in which each site has a different infrastructure:

• Site A: Legacy equipment (PBX & Phones)
• Site B: Mixed Legacy & VoIP equipment (IP-Phones)
• Site C: Pure VoIP infrastructure without legacy equipment

Figure 2

All three infrastructure types require the availability and reliability for their telephony services to employees working in the same site as well as for external telephone destinations.

Figure 3

describes the mechanism via which voice services are available to employees. The VoIP equipment registers in the IP-Centrex application, allowing an IP-phone’s registration to be conducted via the IP-phone and in the case of a legacy phone the registration will be done via the Media Gateway to which the legacy phone is connected. After the VoIP equipment has completed it’s registration in the IP-Centrex application, it creates calls to internal destinations in the business as well as to external destinations. Connectivity to the WAN is necessary in both cases, via the IP-Centrex application and the WAN.

Placing phone calls requires WAN connectivity not only for external calls but also for calls in the same site, as all calls must be created via the IP-Centrex which is located remotely at the service provider site over the WAN.

The implication of this requirement is that if the IP-Centrex application is down or the WAN connectivity to the IP-Centrex application is not working the employees/customers in the site connected to the IP-Centrex services will be unable to place any calls.

A situation in which a service-provider cannot guarantee telephony connectivity and the ability to place emergency calls is unacceptable by the government and customers, thereby motivating service providers to seek solutions that will enhance the reliability and availability of their services.

Figure 3

describes the traditional registration of the IP-phones & VoIP Media Gateways into the IP-Centrex application on the service provider site over the WAN. At this point we observe that if the WAN connectivity is disconnected, IP-phones will not be able to create any calls and the site will be disconnected from service.

Figure 3

Figure 4 details a solution to overcome the WAN disconnection problem as described above, by offering a mechanism for local registration on the local site to guarantee the ability to place calls in the event of WAN disconnection.

The solution requires the installation of a media gateway running a Stand-Alone-Survivability user agent at every branch office or IP-Centrex serviced site for survivability guaranteeing continuous IP-Centrex services. The IP-phone registration to the IP-Centrex is done via the Stand-Alone-Survivability user agent that copies the registration to its internal tables and runs a keep alive process with the IP-Centrex application. As the Stand-Alone-Survivability agent indicates that it has no connectivity with the centralized application it will take over and perform all the phone call routing while checking if the connectivity with the centralized application is back. Once the connectivity has been returned all the routing will be done by the centralized application.

This mechanism solves the connectivity problem for internal calls since the routing will be done by the local proxy, but the issue regarding external calls remains, as the connectivity with the WAN is disconnected. An extension of this solution also solves the external calls disconnection by the media-gateway since it has connectivity with the PSTN network using E1/T1 or FXO trunk interfaces according to the required capacity at each site. The media gateway platform provides the PSTN connectivity in the case of an IP network failure, and offers PSTN connectivity at regular times for least-cost routing.

Figure 4

Figure 5 describes the solution for internal calls in the site.
The solution is based on having the phones register via the Stand-Alone-Survivability user agent in the Media Gateway. In the event of WAN disconnection all calls are routed via the routing table in the Media-Gateway that was built by the registrations described above eliminating the requirement for WAN connectivity to the central application.

Figure 5

Figure 6 describes the case in which calls must be placed out of site.
The solution described in figure 5 is insufficient since it does not provide a connectivity solution for calls out of site. In the local calls out of site, connectivity is not mandatory but for out of site calls an alternative to the WAN network is required.
The trunk interfaces on the Media Gateway provide PSTN connectivity alternative for inter-site calls survivability.



Figure 6

Utilizing AudioCodes Mediant 1000, Service Providers can offer their IP-Centrex customers guaranteed connectivity and ability to place calls, not only within their site but also to any external destination by using the combination of the Stand-Alone-Survivability user agent running on the MGW together with the trunking PSTN interfaces providing redundant network connectivity via the PSTN.