Deployment Scenarios for the Local Gateway
Webex Local Gateways can be deployed in different configurations to adapt to the needs of individual customers, depending on several factors. Does the Local Gateway and the PSTN connection share the same physical or virtual hardware? Does the site contain an IP PBX such as Cisco Unified Communications Manager? Is the Local Gateway hosted offsite from the customer through a service provider (SP) or value-added reseller (VAR)? Each of these factors will be address in the following scenarios. The two biggest factors you should you consider when deploying a Local Gateway are who owns the PSTN gateway and what is your desired throughput of the site PSTN connection?
The first scenario to consider is a company that uses all Webex endpoints but wishes to use its local PSTN’s circuits. If the customer doesn’t already have a device to handle the connection to the PSTN, a single router supporting Local Gateway and PSTN services is a good solution. The router or edge device will supply the Local Gateway functionality as well as the connection to the PSTN. In this scenario, the Webex dial plan routes all non-Webex calls to the trunk pointing to the Local Gateway. The Local Gateway configuration provides the secure connection to the Webex cloud and contains dial-peers, which route calls to the PSTN. Figure 24-4 illustrates a single site deployment for Webex Calling where the PSTN connection and Local Gateway are co-located.
FIGURE 24.4 Single Site Deployment with Local Gateway and PSTN Connection Co-located
The second scenario separates the Local Gateway function from the PSTN gateway using separate routers. The most common reason for this deployment type is to increase capacity. The Local Gateway handles all calls to and from the Webex cloud. Any call not destined for Webex is passed to the PSTN gateway. The PSTN gateway uses similar logic to send any calls not designated for the PSTN to the Local Gateway. This simplifies the configuration of each device and allows higher call capacity through each router. Figure 24-5 illustrates a single site deployment for Webex Calling where the PSTN connection and Local Gateway use dedicated routers for each service. This is the recommended deployment option for Webex Calling when an IP PBX is not being used.
FIGURE 24.5 Single-Site Deployment with Dedicated Local Gateway and PSTN Connections
Another reason to use this deployment model would be if the customer does not control the PSTN device. The customer configures the Local Gateway to hand off all incoming calls from Webex to the PSTN device. Similarly, the PSTN device sends all incoming calls to the Local Gateway.
Adding Cisco Unified Communications Manager to the customer site creates a new scenario because it changes the configuration a bit. In this case, the customer will want the calls from Webex to go to Cisco Unified Communications Manager since there will be an existing dial plan for both on-premises endpoints and the PSTN. Similar to the example of a location with a single router providing both Local Gateway and PSTN functions, the same type of router configuration can be used in this environment. The largest drawback would be the router’s capacity to handle sufficient traffic for Cisco Unified Communications Manager, Webex, and PSTN.
When calls are made from a Webex endpoint, any call not matching the Webex dial plan would be routed to the Local Gateway. The Local Gateway would pass the call to the Cisco Unified Communications Manager. The Cisco Unified Communications Manager dial plan would be leveraged to send calls to either a Cisco Unified Communications Manager–controlled endpoints or routed back the Local Gateway/PSTN device to hand the calls off to the PSTN.
Inbound calls to Webex from the PSTN would route to the PSTN gateway function of the router and onward to the Cisco Unified Communications Manager. The dial plan of the Cisco Unified Communications Manager will be used to determine if the call should be routed to a locally registered device or to a Webex-registered device. When the call is destined for a Webex-registered device, the Cisco Unified Communications Manager will route the call to the Local Gateway function of the router, which forwards the call to the Webex cloud, which will in turn route to the endpoint or phone. Figure 24-6 illustrates a single-site deployment for Webex Calling where the PSTN connection and Local Gateway are co-located on the same router and Cisco Unified Communications Manager is used for on-premises call control.
FIGURE 24.6 Cisco Unified Communications Manager with Co-located PSTN Gateway/SBC and Local Gateway
As you might have guessed, the forth scenario deals with using Cisco Unified Communications Manager and a dedicated router for the PSTN gateway function and Local Gateway function. This is the recommended option for Webex Calling using Cisco Unified Communications Manager. You will benefit from increased call capacity and more granule call control. This scenario is best suited for customers that have an existing on-premises call control solution that utilizes high call volume. The call flow for this scenario remains the same as the previously discussed scenario using a Cisco Unified Communications Manager, as shown next. Figure 24-7 illustrates a single-site deployment for Webex Calling where dedicated routers are used for the PSTN connection and Local Gateway, and Cisco Unified Communications Manager is used for on-premises call control.
FIGURE 24.7 Cisco Unified Communications Manager with dedicated PSTN Gateway/SBC and Local Gateway
Webex > Local Gateway > Cisco Unified Communications Manager > PSTN Gateway
PSTN Gateway > Cisco Unified Communications Manager > Local Gateway > Webex
Any of the scenarios outlined previously are acceptable deployments. However, when planning for future expansion or growth, it is recommended that you separate the Local Gateway and PSTN gateway functions to gain the highest capacity. In addition, the ownership of the devices (customer vs. PSTN provider) might play a role in the decision.
This brings us to the next scenario. Only one Local Gateway needs to be configured for each organization, but multiple Local Gateways can be configured as well by creating multiple locations in the Webex Control Hub. There are a couple rules that should be followed when creating multiple locations:
You cannot assign multiple Local Gateways to a single location. Only one Local Gateway can be assigned per locations.
You can assign a single Local Gateway to multiple locations.
Picture an organization that has three locations configured: Washington, DC, New York, NY, and London, UK. Washington and London have a Local Gateway assigned to them. New York simply uses the same Local Gateway as Washington. If a device registered to New York needs to place a call out the PSTN, the call will traverse from the New York location to Webex, back to Washington, then out the Local Gateway to the PSTN. This is how two or more locations can use the same Local Gateway. However, New York cannot use both the Washington and London local gateways because of the second rule outlined previously. Figure 24-8 illustrates how multiple Local Gateways can be used over multiple locations.
FIGURE 24.8 Call Routing Across Multiple Local Gateways
There is one final scenario you need to understand. Endpoints registered to the Webex Control Hub will communicate directly with Webex in the cloud. They do not have to route calls through the Local Gateway first. That connection is over the Internet, just as you would connect to a website like Cisco.com. In this manner, these endpoints do not have to be co-located with the Local Gateway. Therefore, partners can provide Local Gateway services hosted within their own data centers on behalf of their customers. This could be an official SP or a VAR. In fact, many Cisco VAR partners offer this type of service today. Figure 24-9 illustrates how customers can use the on-premises PSTN Webex Calling option through a hosted Local Gateway within a Cisco Partner environment.
FIGURE 24.9 Partner Hosted Local Gateways