Water Mark
Aug 27, 2020 | view(s) | people thought this was helpful

Overview

Introducing Cisco Webex Calling

Imagine being able to leverage enterprise-grade cloud calling, mobility, and PBX features, along with Cisco Webex Teams for messaging and meetings and calling from a Webex Calling soft client or Cisco device. That's exactly what Webex Calling has to offer you.

Webex Calling provides the following benefits:

  • Calling subscriptions for telephony users and common areas

  • Webex Teams access for every user

  • Public Switch Telephony Network (PSTN) access to let your users dial numbers outside the organization. The service is provided through an existing enterprise infrastructure (local gateway without on-premises IP PBX or with existing Unified CM call environment)

Webex Calling supports the following features. For more information, see the Configure Webex Calling Features chapter.

Table 1. Admin Configurable Features

Feature

Description

Auto Attendant

You can add greetings, set up menus, and route calls to an answering service, a hunt group, a voicemail box, or a real person. You can create a 24-hour schedule or provide different options when your business is open or closed. You can even route calls based on caller ID attributes to create VIP lists or handle calls from certain area codes differently.

Call Queue

You can set up a call queue so that when incoming calls can't be answered, callers are provided with an automated answer, comfort messages, and music on hold until someone can answer their call.

Call Pickup

You can enhance teamwork and collaboration by creating a call pickup group so users can answer each others calls. When you add users to a call pickup group and a group member is away or busy, another member can answer their calls.

Call Park

You can turn on call park so that users can put a call on hold and pick it up from another phone.

Hunt Group

You may want to set up hunt groups in the following scenarios:

  • A Sales team that wants sequential routing. An incoming call rings one phone, but if there's no answer, the call goes to the next agent in the list.

  • A Support team that wants phones to ring all at once so that the first available agent can take the call.

Paging Group

You can create a paging group so that users can send an audio message to a person, a department, or a team. When someone sends a message to a paging group, the message plays on all devices in the group.

Receptionist Client

Help support the needs of your front-office personnel by providing them with a full set of call control options, large-scale line monitoring, call queuing, multiple directory options and views, Outlook integration, and more.

Users can configure the following features in https://settings.webex.com, which cross-launches into the Calling User Portal.

Table 2. User Configurable Features

Feature

Description

Anonymous Call Rejection

Users can reject incoming calls with blocked caller ID's.

Business Continuity

If users' phones are not connected to the network for any reason (such as power outage, network issues, and so on), users can forward incoming calls to a specific phone number.

Call Forwarding

Users can forward incoming calls to another phone.

Call Forwarding Selective

Users can forward calls at specific times from specific callers. This setting will take precedence over Call Forwarding.

Call Notify

Users can send themselves an email when they receive a call according to predefined criteria such as phone number or date and time.

Call Waiting

Users can allow answering of additional incoming calls.

Do Not Disturb

Users can temporarily let all calls to go directly to voicemail.

Office Anywhere

Users can use their selected phones ("Locations") as an extension of their business phone number and dial plan.

Priority Alert

Users can ring their phones with a distinctive ring when predefined criteria are met, such as phone number or date and time.

Remote Office

Users can make calls from a remote phone and have it appear from their business line. In addition, any incoming calls to their business line will ring on this remote phone.

Selective Call Acceptance

Users can accept calls at specific times from specific callers.

Selective Call Rejection

Users can reject calls at specific times from specific callers.

Sequential Ring

Ring up to 5 devices one after another for incoming calls.

Simultaneous Ring

Ring users' and others (“call recipients“) numbers at the same time for incoming calls.

Provisioning Services, Devices, and Users in Control Hub, Cross-Launch to Detailed Configuration in Calling Admin Portal

Cisco Webex Control Hub (https://admin.webex.com) is a management portal that integrates with Webex Calling to streamline your orders and configuration, and centralize your management of the bundled offer—Webex Calling, Webex Teams, and Webex Meetings.

Control Hub is the central point for provisioning all services, devices, and users. You can do first time setup of your calling service, register MPP phones to the cloud (using MAC address), configure users by associating devices, adding numbers, services, calling features, and so on. Also, from Control Hub, you can cross-launch to the Calling Admin Portal for more detailed configuration of features, devices, and users. Provisioning of any additional services (Webex Meetings or Teams) also happens in Control Hub.

The Calling Admin Portal provides customers with access to advanced configuration of calling features as well as a quick view about service assurance. Service assurances provides call quality metrics across multiple locations within their business units by indicating whether the calls are good, fair, or poor quality. Receiving immediate feedback about call quality enables partners and customer administrators to offer the highest quality of services to their customers.

User Experience

Users have access to the following interfaces:

Take a Tour of Cisco Webex Control Hub

Control Hub is your single go-to, web-based interface for managing your organization, managing your users, assigning services, analyzing adoption trends and call quality, and more.

To get your organization up and running, we recommend that you invite a few users to join Webex Teams by entering their email addresses in the Control Hub. Encourage people to use the services you provide, including calling, and to give you feedback about their experience. When you're ready, you can always add more users.


We recommend that you use the latest desktop version of Google Chrome or Mozilla Firefox to access Control Hub. Browsers on mobile devices and other desktop browsers may produce unexpected results.

Use the information presented below as a high-level summary of what to expect when getting your organization set up with services. For more detailed information, see the individual chapters for step-by-step instructions.

Get Started

After your partner creates your account, you'll receive a welcome email. Click the Getting Started link in the email, using Chrome or Firefox to access Control Hub. The link automatically signs you in with your administrator email address. Next, you'll be prompted to create your administrator password.

First Time Wizard for Trials

If your partner has registered you for a trial, the setup wizard automatically starts after you sign in to Control Hub. The wizard walks you through the basic settings to get your organization up and running with Cisco Webex Calling, among other services. You can set up and review your Calling settings before finishing the wizard walkthrough.

Review Your Settings

When Control Hub loads, you can review your settings.

Add Users

Now that you have set up your services, you're ready to add people from your company directory. Go to Users and click Manage Users.

If you use Microsoft Active Directory, we recommend that you enable Directory Synchronization first and then decide how you want to add users. Click Next and follow the instructions to set up Cisco Directory Connector.

Set Up Single Sign On (SSO)

Webex Teams uses basic authentication. You can choose to set up SSO so that users authenticate with your Enterprise Identity Provider using their Enterprise credentials, rather than a separate password stored and managed in Webex.

Go to Settings, scroll to Authentication, click Modify, and then select Integrate a 3rd-party identity provider.

Assign Services to Users

You must assign services to the users that you've added so that people can start using Webex Teams.

Go to Users, click Manage Users, select Export and import users with a CSV file, and then click Export.

In the file you download, simply add True for the services that you want to assign to each of your users.

Import the completed file, click Add and remove services, and then click Submit. You're now ready to configure calling features, register devices that can be shared in a common place, and register and associate devices with users.

Empower Your Users

Now that you've added users and they've been assigned services, they can start using their supported Multiplatform Phones (MPPs) for Webex Calling and Webex Teams for messaging and meetings. Encourage them to use Cisco Webex Settings as a one-stop shop for the access.

Role of the Local Gateway

The local gateway is an enterprise or partner-managed edge device for Public Switch Telephony Network (PSTN) interworking and legacy public branch exchange (PBX) interworking (including Unified CM).

You can use Cisco Webex Control Hub to assign a local gateway to a location, after which Control Hub provides parameters that you can configure on the CUBE. These steps register the local gateway with the cloud, and then PSTN service is provided through the gateway to Webex Calling users in a specific location.

To specify and order a Local Gateway, read the Local Gateway ordering guide.

Supported Local Gateway Deployments for Webex Calling

The following basic deployments are supported:

The local gateway can be deployed standalone or in deployments where integration into Cisco Unified Communications Manager is required.

Local Gateway Deployments Without On-Premises IP PBX

Standalone Local Gateway Deployments

This figure shows a Webex Calling deployment without any existing IP PBX and is applicable to a single location or a multi-location deployment.

For all calls that do not match your Webex Calling destinations, Webex Calling sends those calls to the local gateway that is assigned to the location for processing. The local gateway routes all calls that are coming from Webex Calling to the PSTN and in the other direction, PSTN to Webex Calling.

The PSTN gateway can be a dedicated platform or coresident with the local gateway. As in the following figure, we recommend the dedicated PSTN gateway variant of this deployment; it may be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

Coresident Local Gateway Deployment

The local gateway can be IP based, connecting to an ITSP using a SIP trunk, or TDM based using an ISDN or analog circuit. The following figure shows a Webex Calling deployment where the local gateway is coresident with the PSTN GW/SBC.

Local Gateway Deployments With On-Premises Unified CM PBX

Integrations with Unified CM are required in the following cases:

  • Webex Calling-enabled locations are added to an existing Cisco UC deployment where Unified CM is deployed as the on-premises call control solution

  • Direct dialing between phones registered to Unified CM and phones in Webex Calling locations is required.

This figure shows a Webex Calling deployment where the customer has an existing Unified CM IP PBX.

BroadCloud sends calls that do not match the customer’s Webex Calling destinations to the local gateway. This includes PSTN numbers and Unified CM internal extensions, which BroadCloud cannot see. The local gateway routes all calls that are coming from BroadCloud to Unified CM and vice versa. Unified CM then routes incoming calls to local destinations or to the PSTN as per the existing dial plan. The Unified CM dial plan normalizes numbers as +E.164. The PSTN gateway may be a dedicated one or co-resident with the local gateway.

Dedicated PSTN Gateway

The dedicated PSTN gateway variant of this deployment as shown in this diagram is the recommended option and may be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

Coresident PSTN Gateway

This figure shows a Webex Calling deployment with a Unified CM where the local gateway is coresident with the PSTN gateway/SBC.

BroadCloud routes all calls that do not match the customer’s Webex Calling destinations to the local gateway that is assigned to the location. This includes PSTN destinations and on-net calls towards Unified CM internal extensions. The local gateway routes all calls to Unified CM. Unified CM then routes calls to locally-registered phones or to the PSTN through the local gateway, which has PSTN/SBC functionality co-located.

Call Routing Considerations

Calls From Webex Calling to Unified CM

The Webex Calling routing logic works like this: if the number that is dialed on a Webex Calling endpoint cannot be routed to any other destination within the same customer in BroadCloud, then the call is sent to the local gateway for further processing. All off-net (outside of BroadCloud) calls are sent to the local gateway.

For a Webex Calling deployment without integration into an existing Unified CM, any off-net call is considered a PSTN call. When combined with Unified CM, an off-net call can still be an on-net call to any destination hosted on Unified CM or a real off-net call to a PSTN destination. The distinction between the latter two call types is determined by the Unified CM and depends on the enterprise dial plan that is provisioned on Unified CM.

The following figure shows a Webex Calling user dialing a national number in the US.

Unified CM now based on the configured dial plan routes the call to a locally registered endpoint on which the called destination is provisioned as directory number. For this the Unified CM dial plan needs to support routing of +E.164 numbers.

Calls From Unified CM to Webex Calling

To enable call routing from Unified CM to Webex Calling on Unified CM a set of routes need to be provisioned to define the set of +E.164 and enterprise numbering plan addresses in Webex Calling.

With these routes in place both the call scenarios shown in the following figure are possible.

If a caller in the PSTN calls a DID number that is assigned to a Webex Calling device, then the call is handed off to the enterprise through the enterprise’s PSTN gateway and then hits Unified CM. The called address of that call matches one of the Webex Calling routes that is provisioned in Unified CM and the call is sent to the local gateway. (The called address must be in +E.164 format when sent to the local gateway.) The BroadCloud routing logic then makes sure that the call is sent to the intended Webex Calling device, based on DID assignment.

Also, calls originating from Unified CM registered endpoints, targeted at destinations in Webex Calling, are subject to the dial plan that is provisioned on Unified CM. Typically, this dial plan allows the users to use common enterprise dialing habits to place calls. These habits do not necessarily only include +E.164 dialing. Any dialing habit other than +E.164 must be normalized to +E.164 before the calls is sent to the local gateway to allow for correct routing in BroadCloud.

Class of Service (CoS)

Implementing tight class of service restrictions is always recommend for various reasons including avoiding call loops and preventing toll fraud. In the context of integrating Webex Calling Local Gateway with Unified CM class of service we need to consider class of service for:

  • Devices registered with Unified CM

  • Calls coming into Unified CM from the PSTN

  • Calls coming into Unified CM from BroadCloud

Devices registered with Unified CM

Adding the Webex Calling destinations as a new class of destinations to an existing CoS setup is pretty straight forward: permission to call to Webex Calling destinations typically is equivalent to the permission to call on-premise (including inter-site) destinations.

If an enterprise dial-plan already implements an “(abbreviated) on-net inter-site” permission then there already is a partition provisioned on Unified CM which we can use and provision all the known on-net Webex Calling destinations in the same partition.

Otherwise, the concept of “(abbreviated) on-net inter-site” permission does not exist yet, then a new partition (for example “onNetRemote”) needs to be provisioned, the Webex Calling destinations are added to this partition, and finally this new partition needs to be added to the appropriate calling search spaces.

Calls coming into Unified CM from the PSTN

Adding the Webex Calling destinations as a new class of destinations to an existing CoS setup is pretty straight forward: permission to call to Webex Calling destinations typically is equivalent to the permission to call on-premise (including inter-site) destinations.

If an enterprise dial-plan already implements an “(abbreviated) on-net inter-site” permission then there already is a partition provisioned on Unified CM which we can use and provision all the known on-net Webex Calling destinations in the same partition.

Otherwise, the concept of “(abbreviated) on-net inter-site” permission does not exist yet, then a new partition (for example “onNetRemote”) needs to be provisioned, the Webex Calling destinations are added to this partition, and finally this new partition needs to be added to the appropriate calling search spaces.

Calls coming into Unified CM from BroadCloud

Calls coming in from the PSTN need access to all Webex Calling destinations. This requires adding the above partition holding all Webex Calling destinations to the calling search space used for incoming calls on the PSTN trunk. The access to Webex Calling destinations comes in addition to the already existing access.

While for calls from the PSTN access to Unified CM DIDs and Webex Calling DIDs is required calls originating in Webex Calling need access to Unified CM DIDs and PSTN destinations.

Figure 1. Differentiated CoS for calls from PSTN and Webex Calling

This figure compares these two different classes of service for calls from PSTN and BroadCloud. The figure also shows that if the PSTN gateway functionality is collocated with the Local Gateway, then two trunks are required from the combined PSTN GW and Local Gateway to Unified CM: one for calls originating in the PSTN and one for calls originating in BroadCloud. This is driven by the requirement to apply differentiated calling search spaces per traffic type. With two incoming trunks on Unified CM this can easily be achieved by configuring the required calling search space for incoming calls on each trunk

Dial Plan Integration

This guide assumes an existing installation that is based on best current practices in the “Preferred Architecture for Cisco Collaboration On-Premises Deployments, CVD.” The latest version is available at https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-implementation-design.

The recommended dial plan design follows the design approach that is documented in the Dial Plan chapter of the latest version of the Cisco Collaboration System SRND available at https://www.cisco.com/go/ucsrnd.

Figure 2. Recommended Dial Plan

This figure shows an overview of the recommended dial plan design. Key characteristics of this dial plan design include:

  • All directory numbers that are configured on Unified CM are in +E.164 format.

  • All directory numbers reside the same partition (DN) and are marked urgent.

  • Core routing is based on +E.164.

  • All non-+E.164 dialing habits (for example, abbreviated intrasite dialing and PSTN dialing using common dialing habits) are normalized (globalized) to +E.164 using dialing normalization translation patterns.

  • Dialing normalization translation patterns use translation pattern calling search space inheritance; they have the “Use Originator's Calling Search Space” option set.

  • Class of service is implemented using site and class of service-specific calling search spaces.

  • PSTN access capabilities (for example access to international PSTN destinations) are implemented by adding partitions with the respective +E.164 route patterns to the calling search space defining class of service.

Reachability to BroadCloud

Figure 3. Adding BroadCloud destination to the dial plan

To add reachability for BroadCloud destinations to this dial plan, a partition representing all BroadCloud destinations must be created (“BroadCloud”) and a +E.164 route pattern for each DID range in BroadCloud is added to this partition. This route pattern references a route list with only one member: the route group with the SIP trunk to the Local Gateway for calls to BroadCloud. Because all dialed destinations are normalized to +E.164 either using dialing normalization translation patterns for calls originating from Unified CM registered endpoints or inbound called party transformations for calls originating from the PSTN this single set of +E.164 route patterns is enough to achieve reachability for destinations in BroadCloud independent of the dialing habit used.

If, for example, a user dials “914085550165”, then the dialing normalization translation pattern in partition “UStoE164” normalizes this dial string to “+14085550165” which then matches the route pattern for a BroadCloud destination in partition “BroadCloud.” The Unified CM ultimately sends the call to the local gateway.

Add Abbreviated Intersite Dialing

Figure 4. Adding Abbreviated Intersite Dialing

The recommended way to add abbreviated intersite dialing to the reference dial plan is to add dialing normalization translation patterns for all sites under the enterprise numbering plan to a dedicated partition (“ESN”, Enterprise Significant Numbers). These translation patterns intercept dial strings in the format of the enterprise numbering plan and normalize the dialed string to +E.164.

To add enterprise abbreviated dialing to BroadCloud destinations, you add the respective dialing normalization translation pattern for the BroadCloud location to the “BroadCloud” partition (for example “8101XX” in the diagram). After normalization, the call again is sent to BroadCloud after matching the route pattern in the “BroadCloud” partition.

We do not recommend adding the abbreviated dialing normalization translation pattern for BroadCloud calls to the “ESN” partition, because this configuration may create undesired call routing loops.

Difference between Webex Calling for Service Providers and Value Added Resellers

There are two separate calling offers that leverage the same Webex Calling platform. One offer is for service providers (SPs) and their customers while the other offer is for value added resellers (VARs) and their customers. For the most part, the offers are identical and as such, we refer to them generically as Webex Calling. However, there are a couple differences and where we need to call out those differences, we'll make sure you know whether they apply to SPs or VARs.

While both offers are administered in Control Hub with cross-launches into the Calling Admin Portal, here are some key differences.

SPs can brand their calling portals and apps and must bundle and provide their own PSTN services to their customers or leverage a local gateway deployment. SPs must also provide their own Tier 1 support.

VARs, on the other hand, use the branding provided by Cisco. VARs are not regulated service providers and cannot provide PSTN service. PSTN service must be leveraged through an enterprise local gateway deployment. VARs can also provide their own Tier 1 support or use Cisco's. Both calling offers provide service assurance through media quality metrics and can bundle Webex Teams and Meetings together with their calling applications.

Protocol Handlers for Calling

Cisco Webex Calling registers the following protocol handlers with the operating system to enable click-to-call functionality from web browsers or other application. The following protocols start an audio or video call in Webex Teams when it's the default calling application on Mac or Windows:

  • CLICKTOCALL: or CLICKTOCALL://

  • SIP: or SIP://

  • TEL: or TEL://

  • WEBEXTEL: or WEBEXTEL://

Protocol Handlers for Windows

Other apps can register for the protocol handlers before the Webex Teams app. In Windows 10, the system window to ask users to select which app to use to launch the call. The user preference can be remembered if the user checks Always use this app.

If users need to reset the default calling app settings so that they can pick Webex Teams, you can instruct them to change the protocol associations for Webex Teams in Windows 10:

  1. Open the Default app settings system settings, click Set defaults by app,and then choose Webex Teams.

  2. For each protocol, choose Webex Teams.

Protocol Handlers for Mac

On Mac OS, if other apps registered to the calling protocols before Webex Teams, users must configure their Webex Teams apps to be the default calling option.

In Webex Teams for Mac, users can confirm that Webex Teams is selected for the Start calls with setting under general preferences. They can also check Always connect to Microsoft Outlook if they want to make calls in Webex Teams when they click an Outlook contact's number.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Prepare Your Environment for Webex Calling

Prepare Your Environment Configure Webex Calling for Your Organization Configure Local Gateway for PSTN Access (VARs only) Cofigure UCM Configure Webex Calling Features Configure and Manage Users Configure and Manage Devices

Requirements for Calling

Licensing

Webex Calling is available through the Cisco Collaboration Flex Plan. You must purchase an Enterprise Agreement (EA) plan (for all users, including 50% Workspaces devices) or a Named User (NU) plan (some or all users).

Webex Calling provides three license types ("Station Types")

  • Enterprise—These licenses provide a full feature set for your entire organization. This offer includes unified communications (Webex Calling), mobility (desktop and mobile clients with support for multiple devices), team collaboration in Webex, and the option to bundle meetings with up to 1000 participants per meeting.

  • Basic—Choose this option if your users need limited features without mobility or unified communications. They'll still get a full-featured voice offer but are limited to a single device per user.


    Basic licenses are only available if you have a Named User subscription. Basic licenses are not supported for Enterprise Agreement subscriptions.

  • Workspaces (also known as Common Area)—Choose this option if you're looking for basic dial-tone with a limited set of calling features appropriate for areas such as break rooms, lobbies, and conference rooms.

This documentation later shows you how to use Control Hub to manage these license distributions across locations in your organization.

Bandwidth Requirements

Each device in a video call requires up to 2 Mbps. Each device in an audio call requires 100 kbps. Phones at idle need minimal bandwidth.

Local Gateway for PSTN

Both Value Added Resellers (VARs) and Service Providers (SPs) can provide PSTN access to Webex Calling organizations. Local gateway is currently the only option to provide on-premises PSTN access. The local gateway can be deployed standalone or in deployments where integration into Cisco Unified Communications Manager is required. The local gateway requirements follow.

Supported Devices

Webex Calling supports Cisco Multiplatform (MPP) IP Phones . As an administrator, you can register the following phones to the cloud. See the following Help articles for more information:

Table 1. Supported Devices

Device Category

Device Type

Basic

  • Cisco IP Phone 6800 Series with Multiplatform Firmware

  • Cisco IP Phone 7800 Series with Multiplatform Firmware

Analog Telephony Adapters

Cisco ATA 191 and 192 with Multiplatform Firmware

Conference

  • Cisco IP Conference Phone 7832 with Multiplatform Firmware

  • Cisco IP Conference Phone 8832 with Multiplatform Firmware

Advanced

  • Cisco IP DECT 6800 Series with Multiplatform Firmware

  • Cisco IP Phone 8800 Series with Multiplatform Firmware

Accessories

Key Expansion Modules

Cisco Webex Room, Board, and Desk Devices are supported as devices in a Workspace that you create in Control Hub. See "Cisco Webex Room, Board, and Desk Devices" in Supported Devices for Webex Calling for more information. However, you can provide these devices with PSTN service by enabling Webex Calling for the Workspace.

Firewall

Meet the firewall requirements that are documented in Port Reference Information for Cisco Webex Calling.

Local Gateway Requirements for Webex Calling

General Prerequisites

Before you configure a local gateway for Cisco Webex Calling, ensure that you

    • Have a basic knowledge of VoIP principles

    • Have a basic working knowledge of Cisco IOS-XE and IOS-XE voice concepts

    • Have a basic understanding of Session Initiation Protocol (SIP)

    • Have a basic understanding of Cisco Unified Communications Manager (Unified CM) if your deployment model includes Unified CM

    More details can be found in the Cisco Unified Border Element (CUBE) Enterprise Configuration Guide at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html

Hardware and Software Requirements for Local Gateway

Make sure your deployment has one or more of the local gateways (Cisco CUBE (for IP-based connectivity) or Cisco IOS Gateway (for TDM-based connectivity)) that are in Table 1 of the Local Gateway for Webex Calling Ordering Guide. Additionally, make sure the platform is running a supported IOS-XE release as per the Local Gateway Configuration Guide.

Certificate and Security Requirements for Local Gateway

Webex Calling requires secure signaling and media. The CUBE local gateway performs the encryption, and a mutual TLS connection must be established outbound to the cloud with the following steps:

  • The CUBE must be updated with the CA root bundle from Cisco PKI

  • A set of SIP digest credentials from Control Hub are used to configure the CUBE (the steps are part of the configuration that follows)

  • CA root bundle validates presented certificate

  • Prompted for credentials (SIP digest provided)

  • The cloud identifies which local gateway is securely registered

Firewall and NAT Traversal Requirements for Local Gateway

In most cases, the local gateway and endpoints can reside in the internal customer network, using private IP addresses with NAT. The enterprise firewall must allow outbound traffic (SIP, RTP/UDP, HTTP) to specific IP addresses/ports, covered in Port Reference Information.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Configure Cisco Webex Calling for Your Organization

Before you begin

If you’re trying to set up a customer in Canada, additional steps are necessary. For more information, contact Partner HelpDesk.

1

Click the Getting Started link in the Welcome email you receive.


 

Your administrator email address is automatically used to sign in to Control Hub, where you'll be prompted to create your administrator password. After you sign in, the setup wizard automatically starts.

2

Review and accept the terms of service.

3

Review your plan and then click Get Started.

4

Select the country that your data center should map to, and enter the customer contact and customer address information.

5

Click Next: Default Location.

6

Choose from the following options:

  • Click Save and Close if you’re a partner administrator and you want the customer administrator to complete the provisioning of Webex Calling.
  • Fill out the necessary location information. After you create the location in the wizard, you can create more locations later.

 

The country of the default location is set as the contract country that was selected by the partner and can't be changed. You can create other locations in different countries later but keep in mind that they'll be hosted in the regional data center that corresponds to the contract country you selected earlier in this procedure. For example, you can have one location in the United States and one in the United Kingdom.


 

After you complete the setup wizard make sure you add a main number to the location you create.

7

(Optional) Toggle on Skype for Business if this integration is required, and then click Next.


 

When enabled, this location-wide setting converts all existing Calling apps into Calling for S4B. This app can run alongside Skype for Business for Windows and provides integrated PSTN calling abilities.

8

Select Next.

9

Enter an available Cisco Webex SIP address and click Next.

10

Select Finish.

Before you begin

To create a new location, prepare the following information:

  • Location address

  • Desired phone numbers (optional)

1

From the customer view in https://admin.webex.com, go to Services > Calling > Locations, and then click Add Location.

Keep in mind that new locations will be hosted in the regional data center that corresponds to the contract country you selected using the First-Time Setup Wizard.

2

Configure the settings of the location:

  • Location Name—Enter a unique name to identify the location.
  • Country—Choose a country to tie the location to. For example, you can create one location (headquarters) in the United States and another (branch) in the United Kingdom. The country that you choose determines the address fields that follow. The ones documented here use the U.S. address convention as an example.
  • Language—Choose the language for the location.
  • Address—Enter the location's main mailing address.
  • City—Enter a city for this location.
  • State—From the drop-down, choose a state.
  • ZIP/Postal Code—Enter the ZIP or postal code.Phone Number—Enter the phone number at which the location's main contact can be reached.
3

(Optional) Toggle on Skype for Business if your users at this location want to continue to collaborate using the Microsoft Skype for Business desktop app. Users will be able to make and receive phone calls from outside their organization as well as leverage the advanced calling features that the Webex Calling S4B app offers. Users must download and install the Webex Calling S4B app so that when they initiate or receive a PSTN call on their Microsoft Skype app, they're cross-launched into the Webex Calling S4B app.


 

This is the only time that you can opt in or out of the Skype for Business integration with the Webex Calling app. After the location is created, you no longer have the option to change this setting.

4

Click Save and then choose whether you want to add numbers now or later.

5

If you clicked Add Now, choose one of the following options:

  • Cloud Connected PSTN —Choose this option if you're looking for a cloud solution that doesn't require a significant investment in local hardware and then select a CCP provider of your choice.


     

    Only providers that support your location's country are displayed.

    If you see the option to Order numbers now under a provider listed, we recommend that you choose that option so that you can reap the benefits of integrated CCP. This way, you can order your numbers right here in Control Hub. If you choose this option, go here for more information and next steps.

    Keep in mind that if you decide not to order your numbers now, subsequent changes to your PSTN provider may be limited.

  • Local Gateway—You can choose this option if you want to keep your current PSTN provider or you want to connect non-cloud sites with cloud sites and have a common dial plan (hybrid option). If you have multiple locations, you may not want to go all cloud, all at once.
6

Choose whether you want to activate the numbers now or later.

7

Enter Phone Numbers as comma-separated values, and then click Validate.

Numbers are added for the specific location. Valid entries move to the Validated Numbers field, and invalid entries remain in the Add Numbers field accompanied by an error message.

Depending on the location's country, the numbers are formatted according to local dialing requirements. For example, if a country code is required, you can enter numbers with or without the code and the code is prepended.

8

Click Save.

What to do next

After you create a location, you can enable emergency 911 services for that location. See RedSky Emergency 911 Service for Webex Calling for more information.

When you created your customer organization in Control Hub, the first location you created automatically becomes the default location. Users that you add to your organization are assigned to this default location, unless you specify otherwise. You can make any subsequent location the default location but keep in mind that you cannot delete the default location.

Before you begin


Get a list of the users and workspaces associated with a location: Go to Services > Numbers and from the drop-down menu, select the location to be deleted. You must delete those users and workspaces before you delete the location.

Keep in mind that any numbers associated with this location will be released back to your PSTN provider; you'll no longer own those numbers.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Location, and then select the location you want to delete.

2

Click More beside the location name, choose Delete Location, and confirm that you want to delete that location.

It typically takes a couple of minutes for the location to be permanently deleted but it could take up to an hour. You can check the status by clicking More beside the location name and selecting Deletion Status.

You can change your PSTN setup as well as the name, time zone, and language of a location after it's been created. Keep in mind though that the new language only applies to new users and devices. Existing users and devices continue to use the old language.


For existing locations, you can enable emergency 911 services. See RedSky Emergency 911 Service for Webex Calling for more information.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Locations, and then select the location you want to update.

If you see a Caution symbol next to a location, it means you haven't configured a telephone number for that location yet. Users won't be able to make or receive any calls until that number is configured.

2

(Optional) Under PSTN Connection, select either Cloud Connected PSTN or Local Gateway, depending on which one you've already configured. Click Edit to change that configuration, and then acknowledge the associated risks by selecting Continue. Then, choose one of the following options and click Save:

  • Cloud Connected PSTN —Choose this option if you're looking for a cloud solution that doesn't require a significant investment in local hardware and then select a CCP provider of your choice.


     

    Only providers that support your location's country are displayed.

    If you see the option to Order numbers now under a provider listed, we recommend that you choose that option so that you can reap the benefits of integrated CCP. This way, you can order your numbers right here in Control Hub. If you choose this option, go here for more information and next steps.

  • Local Gateway—Choose this option if you want to keep your current PSTN provider or you want to connect non-cloud sites with cloud sites and have a common dial plan (hybrid option). If you have multiple locations, you may not want to go all cloud, all at once.

     

    This option is only available to value added resellers.

3

Select the Main Number at which the location's main contact can be reached.

4

Select the Voicemail Number that users can call to check their voicemail for this location.

5

(Optional) Click the pencil icon at the top of the Location page to change the Location Name, Time Zone, or Language as needed, and then click Save.

These settings are also available in the first-time setup wizard. As you change your dial plan, the example numbers in Control Hub update to show these changes.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Service Settings, and then scroll to Internal Dialing.

2

Configure the following optional dialing preferences, as needed:

  • Location Routing Prefix Length—We recommend this setting if you have multiple locations. You can enter a length of 2-7 digits. If you have multiple locations with the same extension, users must dial a prefix when calling between locations. For example, if you have multiple stores, all with the extension 1000, you can configure a routing prefix for each store. If one store has a prefix of 888, you'd dial 8881000 to reach that store.
  • Steering Digit in Routing Prefix—You can set a value here regardless of whether you use location routing prefixes.
  • Internal Extension Length—You can enter 2-6 digits and the default is 2.

     

    After you increase your extension length, existing speed dials to internal extensions are not automatically updated.

3

Specify internal dialing for specific locations. Go to Services > Call > Locations, select a location, scroll to Dialing, and then change internal and external dialing as needed:

  • Internal Dialing—Specify the routing prefix that users at other locations need to dial in order to contact someone at this location. The routing prefix of each location must be unique. We recommend that the prefix length matches the length set at the organization level but it must be between 2-7 digits long.
  • External Dialing—You can choose an outbound dial digit that users must dial to reach an outside line. The default is None and you can leave it if you don't require this dialing habit. If you do decide to use this feature, we recommend that you use a different number from your organization's steering digit.

Impact to users:

  • Users must restart their phones in order for changes in dialing preferences to take effect.

  • User extensions should not start with the same number as the location's steering digit.

If you're a value added resellers, you can use these steps to start local gateway configuration in Cisco Webex Control Hub. When this gateway is registered to the cloud, you can use it on one or more of your Cisco Webex Calling locations to provide routing towards an enterprise PSTN service provider.


A location that has a local gateway can't be deleted when the local gateway is being used for other locations.

Before you begin

  • Create any locations and specific settings and numbers to each one. Locations must exist before you can add a local gateway.

  • Understand the local gateway requirements for Webex Calling.

  • You cannot assign more than one gateway to a location, but you can assign the same gateway to multiple locations.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Locations, and then select the location you want to add a local gateway to.

2

Under PSTN Connection, select Cloud Connected PSTN, click Edit, and then acknowledge the associated risks by selecting Continue.

3

Select Local Gateway, click Manage, and then click Create New Local Gateway from the drop-down list.

4

Enter a name to identify the gateway in Control Hub and then save your changes by clicking the check mark.

You're presented with the relevant parameters that you'll need to configure on the local gateway. You'll also generate a set of SIP digest credentials to secure the local gateway.

5

Note the local gateway info that appears on the screen (Registrar Domain, Trunk Group OTG/DTG, Line/Port, Outbound Proxy Address).


 

We recommend that you copy the parameter information from Control Hub and paste it into a local text file or document so you can refer to it when you're ready to configure the on-premises local gateway.

6

Click Retrieve Username and Reset Password to generate a new set of authentication credentials to use on the on-premises local gateway.


 

If you lose the credentials, you must regenerate them from the gateway configuration screen in Control Hub. We recommend that you copy these credentials from Control Hub and paste them into a local text file or document so you can refer to them when you're ready to configure the on-premises local gateway.

What to do next

You must take the configuration information that Control Hub generated and map the parameters into the local gateway (for example, on a Cisco CUBE that sits on the premises). This article walks you through this process. As a reference, see the following diagram for an example of how the Control Hub configuration information (on the left) maps onto parameters in the CUBE (on the right):

After you successfully complete the configuration on the gateway itself, you can return to Services > Call > Locations in Control Hub and the gateway that you created will be listed in the location card that you assigned it to with a green dot to the left of the name. This status indicates that the gateway is securely registered to the calling cloud and is serving as the active PSTN gateway for the location.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Numbers.

A table appears that shows numbers and corresponding information for all locations. You can click the All Locations drop-down and choose a location if you want to filter on a specific one. The table includes information like who the number is Assigned To and its Status.

2

(Optional) Next to a number entry, under Actions, click , and then choose one of the following options:

  • Edit—For active numbers that are currently assigned to a user or a place. Click this option to open the Calling Admin Portal, where you can make further changes.

  • Activate—For numbers in Inactive status, this option is available once a Webex Calling ported number that was submitted with an order is completed. After you activate the number, the number shows as Active when it's ready to use.

  • Delete—For numbers in Inactive status and that aren't currently assigned to a user or a place, this option is available.

3

(Optional) Click Add Numbers, fill in the required information to add at least one new number to a location, and then click Save.


 

Valid entries move to the Validated Numbers field while invalid entries remain in the Add Numbers field accompanied by an error message.

Numbers must follow E.164 format for all countries, except the United States can also follow the National format.

Depending on the location's country, the numbers are formatted according to local dialing requirements. For example, if a country code is required, you can enter numbers with or without the code and the code is prepended.

4

(Optional) Activate numbers in bulk. You can filter your list of numbers based on a specific location or status or both. Click Inactive to see only the numbers that are in an inactive state. You can activate 500 numbers at a time by selecting Activate Numbers at the top of your list and then confirm your intent by clicking Activate in the dialog box that opens.

1

From the customer view in https://admin.webex.com, select the building icon .

2

Select the Subscriptions tab, and then click Purchase Now.

An email is sent to your partner letting them know that you're interested in converting to a paid subscription.

You can use Control Hub to set the priority of available calling options that users see in Webex Teams. You can also enable them for single click-to-call.

1

From the customer view in https://admin.webex.com, go to Services, and then click Client Settings on the Calling card.

2

Drag and drop calling options that you want users to see to the Available Call Options field, and then rearrange them in the priority order that you want for your users.

Other options that are hidden for users appear in the Hidden Call Options field, as shown in this example screenshot:

3

Toggle on Enable Single Click-to-Call if you want users to be able to make a call with the first call option that you configured in the previous step.


 

The changes may take up to 24 hours to appear in Webex Teams. You can advise your users to restart their apps to pick up on these changes more quickly.

You can control what calling application opens when users make PSTN calls. After you configure this setting at the organization level, you can override this setting for specific users.


Only choose the organization-wide option if you're ready to migrate your entire organization.

Before you begin

  • Your organization must have the correct subscriptions for the calling behavior you choose.

  • Users must have valid phone numbers. If the numbers are invalid, Webex Teams still sends the number to the calling app that you select, but the call from that app will fail.

From the customer view in https://admin.webex.com, go to Settings, scroll to Calling Behavior, and then choose one of the following: .

  • Calling in Webex Teams—Select this option if you want users to make calls directly in Webex Teams using Webex Calling.
  • Webex Calling app—Select this option if your organization has a subscription to Cisco Webex Calling and you want to allow users to make PSTN calls using the Webex Calling app. When users make PSTN calls in Webex Teams, the Webex Calling app is used to make the call.

A message appears that indicates that the calling behavior is updated. Users are now able to make PSTN calls from Webex Teams or the Webex Calling app.

Users must have the corresponding application installed to make PSTN calls from Webex Teams. Make sure you let people know what choice you make and if another app is used to make PSTN calls.


 

You can change this setting at the user level if certain people need to use different calling behavior. Go to Users and under Settings, select Calling Behavior. You can make your choice and then click Save.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Configure Local Gateway on IOS-XE for Webex Calling

After you configure Webex Calling for your organization, you must then configure local gateways using their respective CLI interfaces. The trunk between the local gateway and the Webex cloud is always secured using SIP TLS transport and SRTP for media between Local gateway and the Webex Calling Access SBC.

Use this task flow to configure local gateways for your Webex Calling deployment. The steps that follow are performed on the CLI interface itself. The trunk between the local gateway and Webex Calling is always secured using SIP TLS transport and SRTP for media between Local gateway and the Webex Calling Access SBC.

Before you begin

  • Meet the local gateway requirements for Webex Calling.

  • Create a local gateway in Control Hub.

  • The configuration guidelines provided in this document assume that a dedicated local gateway platform is in place with no existing voice configuration. If an existing PSTN gateway or CUBE enterprise deployment is being modified to also use the local gateway function for Webex Calling, pay careful attention to the configuration applied and make sure existing call flows and functionality are not interrupted as a result of changes that you make.

  Command or Action Purpose
1

Parameter Mapping Between Cisco Webex Control Hub and Cisco Unified Border Element

Use this table as a reference for the parameters that come from Control Hub and where they map onto the local gateway.

2

Perform Reference Platform Configuration

Implement these steps as a common global configuration for the local gateway. The configuration includes baseline platform configuration and a trust pool update.

3

Register Local Gateway to Webex Calling

4

Choose one, depending on your deployment:

Call Routing on the local gateway is based on the Webex Calling deployment option that you chose. This section assumes that IP PSTN termination is on the same platform as the local gateway. The configuration that follows is for one of these options on the local gateway:

  • The local gateway deployment option without an on-premises IP PBX. The local gateway and IP PSTN CUBE are coresident.

  • The local gateway deployment option within an existing Unified CM environment. The local gateway and IP PSTN CUBE are coresident.

Table 1. Parameter Mapping Between Cisco Webex Control Hub and Local Gateway

Control Hub

Local Gateway

Registrar Domain:

Control Hub should parse the domain from the LinePort that is received from UCAPI.

example.com

registrar

example.com

Trunk Group OTG/DTG

sip profiles:

rule <rule-number> request ANY sip-header

From modify ">" ";otg=otgDtgId>"

Line/Port

user@example.com

number: user

Outbound Proxy

outbound proxy (DNS name – SRV of the Access SBC)

SIP Username

username

SIP Password

password

Before you begin

  • Ensure that baseline platform configuration such as NTPs, ACLs, enable passwords, primary password, IP routing, IP Addresses, and so on are configured according to your organization's policies and procedures.

  • Latest of IOS-XE 16.12 or IOS-XE 17.3 required for all LGW deployments.

1

Ensure that any layer 3 interfaces have valid and routable IP addresses assigned:

interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling
 ip address 192.168.43.197 255.255.255.0
2

You must preconfigure a master key for the password using the commands shown below before it can be used in the credentials and shared secrets. Type 6 passwords are encrypted using AES cypher and user-defined master key.


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes
3

Configure IP Name Server to enable DNS lookup and ensure it is reachable by pinging it:


LocalGateway#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#ip name-server 8.8.8.8
LocalGateway(config)#end
4

Enable TLS 1.2 Exclusivity and a default Dummy Trustpoint:

  1. Create a dummy PKI Trustpoint and call it dummyTp

  2. Assign the trustpoint as the default signaling trustpoint under sip-ua

  3. cn-san-validate server is needed to ensure that the local gateway establishes the connection only if the outbound proxy configured on the tenant 200 (described later) matches with CN-SAN list received from the server.

  4. The crypto trustpoint is needed for TLS to work even though a local client certificate (for example, mTLS) is not required for the connection to be set up.

  5. Disable TLS v1.0 and v1.1 by enabling v1.2 exclusivity.

  6. Set tcp-retry count to 1000 (5 msec multiples = 5 seconds).

  7. (IOS-XE 17.3.2 and later) Set timers connection establish tls <wait-timer in sec>. Range is between 5 and 20 seconds and the default is 20 seconds. (LGW takes 20 seconds to detect the TLS connection failure before it attempts to establish a connection to the next available Webex Calling Access SBC. This CLI allows the admin to change the value to accommodate network conditions and detect connection failures with the Access SBC much faster).


LocalGateway#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#
LocalGateway(config)#crypto pki trustpoint dummyTp
LocalGateway(ca-trustpoint)# revocation-check crl
LocalGateway(ca-trustpoint)#exit

LocalGateway(config)#sip-ua
LocalGateway(config-sip-ua)# crypto signaling default trustpoint dummyTp cn-san-validate server

LocalGateway(config-sip-ua)# transport tcp tls v1.2
LocalGateway(config-sip-ua)# tcp-retry 1000
LocalGateway(config-sip-ua)#end
5

Update Local Gateway Trustpool:

The default trustpool bundle does not include the “DigiCert Root CA” certificate needed for validating the server side certificate during TLS connection establishment to Webex Calling.

The trustpool bundle must be updated by downloading the latest “Cisco Trusted Core Root Bundle” from http://www.cisco.com/security/pki/.

  1. Check if the DigiCert Room CA certificate exists:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
  2. If it doesn't exist, update as follows:

    
    LocalGateway#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    LocalGateway(config)#crypto pki trustpool import clean url 
    http://www.cisco.com/security/pki/trs/ios_core.p7b
    Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b
    Loading http://www.cisco.com/security/pki/trs/ios_core.p7b 
    % PEM files import succeeded.
    LocalGateway(config)#end
    
  1. Verify:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    

Before you begin

Ensure that you completed the steps in Control Hub to create a location and add a local gateway. In the example local gateway shown here, the information was obtained from Control Hub.

1

Enter these commands to turn on the local gateway application (see the Port Reference Information for Cisco Webex Calling for the latest IP subnets that need to be added to the trust list):

LocalGateway#configure terminal
LocalGateway(config)#voice service voip
LocalGateway(conf-voi-serv)#ip address trusted list
LocalGateway(cfg-iptrust-list)#ipv4 x.x.x.x y.y.y.y
LocalGateway(cfg-iptrust-list)#exit
LocalGateway(conf-voi-serv)#allow-connections sip to sip
LocalGateway(conf-voi-serv)#media statistics
LocalGateway(conf-voi-serv)#media bulk-stats
LocalGateway(conf-voi-serv)#no supplementary-service sip refer
LocalGateway(conf-voi-serv)#no supplementary-service sip handle-replaces
LocalGateway(conf-voi-serv)# fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

LocalGateway(conf-serv-stun)#stun
LocalGateway(conf-serv-stun)#stun flowdata agent-id 1 boot-count 4
LocalGateway(conf-serv-stun)#stun flowdata shared-secret 0 Password123$

LocalGateway(conf-serv-stun)#sip

   LocalGateway(conf-serv-sip)#g729 annexb-all
   LocalGateway(conf-serv-sip)#early-offer forced
   LocalGateway(conf-serv-sip)#end

Explanation of commands:

Toll-Fraud Prevention
Device(config)# voice service voip
Device(config-voi-serv)# ip address trusted list
Device(cfg-iptrust-list)# ipv4 x.x.x.x y.y.y.y
  • Explicitly enables the source IP addresses of entities from which the local gateway expects legitimate VoIP calls, such as Webex Calling peers, Unified CM nodes, IP PSTN.

  • By default, LGW blocks all incoming VoIP call setups from IP addresses not in its trusted list. IP Addresses from dial-peers with “session target ip” or Server Group are trusted by default and need not be populated here.

  • IP addresses in this list need to match the IP subnets according to the regional Webex Calling data center the customer is connected to. For more information, see Port Reference Information for Webex Calling.


     

    If your LGW is behind a firewall with restricted cone NAT, you may prefer to disable the IP address trusted list on the Webex Calling-facing interface. This is because the firewall already protects you from unsolicited inbound VoIP. This action would reduce your longer term configuration overhead, because we cannot guarantee that the addresses of the Webex Calling peers will remain fixed, and you would need to configure your firewall for the peers in any case.

  • Other IP addresses may need to be configured on other interfaces; for example, your Unified CM addresses may need to be added to the inward-facing interfaces.

  • IP addresses must match the IP of hosts the outbound-proxy resolves to in tenant 200

  • See https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.html for more information.

Media
voice service voip
 media statistics 
 media bulk-stats 
  • Media Statistics enables media monitoring on the local gateway.

  • Media bulk-stats enables the control plane to poll the data plane for bulk call statistics.

SIP-to-SIP Basic Functionality
allow-connections sip to sip
Supplementary Services
 no supplementary-service sip refer
 no supplementary-service sip handle-replaces

Disables REFER and replaces dialog ID in Replaces header with the peer dialog ID.

See https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html#wp2876138889 for more information.

Fax Protocol
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

Enables T.38 for fax transport, though the fac traffic will not be encrypted.

Enable Global STUN
stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
  • When a call is forwarded back to a Webex Calling user (for example, both the called and calling parties are Webex Calling subscribers and have the media anchored at the Webex Calling SBC), the media cannot flow to the local gateway as the pinhole isn't open.

  • The STUN bindings feature on the local gateway allows locally generated STUN requests to be sent over the negotiated media path. This helps in opening up the pinhole in the firewall.

  • STUN password is a prerequisite for the local gateway to send STUN messages out. IOS/IOS-XE based firewalls can be configured to check for this password and open pinholes dynamically (for example, without explicit in-out rules). But for the local gateway deployment case, the firewall is statically configured to open pinholes in and out based on the Webex Calling SBC sub nets. As such, the firewall should just treat this as any inbound UDP packet which will trigger the pinhole opening without explicitly looking at the packet contents.

G729
sip
  g729 annexb-all

Allows all variants of G729.

SIP
early-offer forced

Forces the local gateway to send the SDP information in the initial INVITE message instead of waiting for acknowledgement from the neighboring peer.

2

Configure “SIP Profile 200”.

LocalGateway(config)# voice class sip-profiles 200
LocalGateway (config-class)# rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1"
LocalGateway (config-class)# rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
LocalGateway (config-class)# rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 20 request ANY sip-header From modify ">" ";otg=hussain2572_lgu>"
LocalGateway (config-class)# rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

These rules are

Explanation of commands:

  • rule 9 ensures the header is listed as “SIP-Req-URI” and not “SIP-Req-URL”

    This converts between SIP URIs and SIP URLs, because Webex Calling doesn't support SIP URIs in the request/response messages, but needs them for SRV queries, e.g. _sips._tcp.<outbound-proxy>.
  • rule 20 modifies the From header to include the Trunk Group OTG/DTG parameter from Control Hub to uniquely identify a LGW site within an enterprise.

  • This SIP Profile will be applied to voice class tenant 200 (discussed later) for all traffic facing Webex Calling.

3

Configure Codec Profile, STUN definition, and SRTP Crypto suite.

LocalGateway(config)# voice class codec 99
LocalGateway(config-class)# codec preference 1 g711ulaw
LocalGateway(config-class)# codec preference 2 g711alaw 
LocalGateway(config-class)# exit
LocalGateway(config)# voice class srtp-crypto 200
LocalGateway(config-class)# crypto 1 AES_CM_128_HMAC_SHA1_80
LocalGateway(config-class)# exit
LocalGateway(config)# voice class stun-usage 200
LocalGateway(config-class)# stun usage firewall-traversal flowdata
LocalGateway(config-class)# exit

Explanation of commands:

  • Voice class codec 99: Allows both g711 (mu and a-law) codecs for sessions. Is applied to all the dial-peers.

  • Voice class srtp-crypto 200: Specifies SHA1_80 as the only SRTP cipher-suite that's offered by local gateway in the SDP in offer and answer. Webex Calling only supports SHA1_80.

  • Will be applied to voice class tenant 200 (discussed later) facing Webex Calling.

  • Voice class stun-usage 200: Defines STUN usage. Is applied to all Webex Calling-facing (2XX tag) dial-peers to avoid no way audio when a Unified CM phone forwards the call to another Webex Calling phone.


 

In cases where media is anchored at the ITSP SBC and the Local Gateway is behind a NAT and waiting for the inbound media stream from ITSP, this command may be applied on ITSP facing dial-peers.

4

Map Control Hub parameters to local gateway configuration:

Webex Calling is added as a tenant within the local gateway. The configuration required to register the local gateway is defined under voice class tenant 200. You must obtain the elements of that configuration from the local gateway administration page within the Control Hub as shown in this screenshot. This is an example to display what fields map to the respective local gateway CLI.

Tenant 200 is then applied to all the Webex Calling facing dial-peers (2xx tag) within the local gateway configuration. The voice class tenant feature allows for grouping and configuring of SIP trunk parameters otherwise done under voice service voip and sip-ua. When a tenant is configured and applied under a dial-peer, the IOS-XE configurations are applied in the following order of preference:

  • Dial-peer configuration

  • Tenant configuration

  • Global configuration (voice service voip / sip-ua)

5

Configure voice class tenant 200 to enable Trunk Registration from LGW to Webex Calling based on the parameters you've obtained from Control Hub:


 

The command line and parameters below are examples only. You must use the parameters for your own deployment.

LocalGateway(config)#voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls 
  url sips 
  error-passthru
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 200 
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com  
  privacy-policy passthru

Explanation of commands:

voice class tenant 200

A local gateway's multitenant feature enables specific global configurations for multiple tenants on SIP trunks that allow differentiated services for tenants.

registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

Registrar server for the Local gateway with the registration set to refresh every two minutes (50% of 240 seconds). For more information, see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1687622014.

credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks

Credentials for Trunk Registration challenge. For more information, see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp3153621104.

authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks
authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

Authentication challenge for calls. For more information, see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462.

no remote-party-id

Disable SIP Remote-Party-ID (RPID) header as Webex Calling supports PAI, which is enabled using CIO asserted-id pai (see below).

sip-server dns:40462196.cisco-bcld.com
Webex Calling servers. For more information, see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462
connection-reuse

To use the same persistent connection for registration and call processing.

srtp-crypto 200

Specifies SHA1_80 as defined in voice class srtp-crypto 200.

session transport tcp tls
Sets transport to TLS
url sips

SRV query has to be SIPs as supported by the access SBC; all other messages are changed to SIP by sip-profile 200.

error-passthru

SIP error response pass-thru functionality

asserted-id pai

Turns on PAI processing in local gateway.

bind control source-interface GigabitEthernet0/0/1

Signaling source interface facing Webex Calling.

bind media source-interface GigabitEthernet0/0/1

Media source interface facing Webex Calling.

no pass-thru content custom-sdp

Default command under tenant.

sip-profiles 200

Changes SIPS to SIP and modify Line/Port for INVITE and REGISTER messages as defined in voice class sip-profiles 200.

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

Webex Calling Access SBC. For more information, see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-o1.html#wp3297755699.

privacy-policy passthru

Transparently pass across privacy header values from incoming to the outgoing leg.

After tenant 200 is defined within the local gateway and a SIP VoIP dial-peer is configured, the gateway then initiates a TLS connection towards Webex Calling, at which point the Access SBC presents its certificate to the local gateway. The local gateway validates the Webex Calling Access SBC certificate using the CA root bundle updated earlier. A persistent TLS session is established between the local gateway and Webex Calling Access SBC. The Local gateway then sends a REGISTER to the Access SBC which is challenged. Registration AOR is number@domain. The number is taken from credentials “number” parameter and domain from the “registrar dns:<fqdn>”. When the Registration is challenged, the username, password and realm parameters from credentials are used to build the header and sip-profile 200 converts SIPS URL back to SIP. Registration is successful once 200 OK is received from the Access SBC.

The following configuration on the local gateway is required for this deployment option:

  1. Voice class tenants—First we will create additional tenants for dial-peers facing ITSP similar to tenant 200 that we created for Webex Calling facing dial-peers.

  2. Voice class URIs—Patterns defining host IP addresses/ports for various trunks terminating on Local Gateway: Webex Calling to LGW; and PSTN SIP trunk termination on LGW.

  3. Outbound dial-peers—To route outbound call legs from LGW to ITSP SIP trunk and Webex Calling.

  4. Voice class DPG—Target outbound dial-peers invoked from an inbound dial-peer.

  5. Inbound dial-peers—To accept inbound call legs from ITSP and Webex Calling.

Configuration in this section can be used for either partner-hosted local gateway setup, as shown below, or local customer site gateway.

1

Configure the following voice class tenants:

  1. Voice class tenant 100 is applied on all OUTBOUND dial-peers facing IP PSTN.

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Voice class tenant 300 is applied on all INBOUND dial-peers from IP PSTN.

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

Configure the following voice class URI:

  1. Define ITSP’s host IP address:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Define pattern to uniquely identify a local gateway site within an Enterprise based on Control Hub's TrunkGroup OTG/DTG parameter:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    Local gateway doesn't currently support underscore "_" in the match pattern. As a workaround, we use dot "." (match any) to match the "_".

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
3

Configure the following outbound dial peers:

  1. Outbound dial-peer toward IP PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad

    Explanation of Commands:

    dial-peer voice 101 voip
     description Outgoing dial-peer to PSTN
    

    Defines a VOIP dial-peer with a tag of 101 and a meaningful description is given for ease of management and troubleshooting.

    destination-pattern BAD.BAD

    Digit pattern that allows selection of this dial-peer. However, we will invoke this outgoing dial-peer directly from the inbound dial-peer using DPG statements and that bypasses the digit pattern match criteria. As a result, we're using an arbitrary pattern based on alphanumeric digits allowed by the destination-pattern CLI.

    session protocol sipv2

    Specifies that this dial-peer will be handling SIP call legs.

    session target ipv4:192.168.80.13

    Indicates the destination’s target IPv4 address where this call leg will be sent. In this case, ITSP’s IP address.

    voice-class codec 99

    Indicates codec preference list 99 to be used for this dial-peer.

    dtmf-relay rtp-nte

    Defines RTP-NTE (RFC2833) as the DTMF capability expected on this call leg.

    voice-class sip tenant 100

    The dial-peer will inherit all the parameters from Tenant 100 unless that same parameter is defined under the dial-peer itself.

    no vad

    Disables voice activity detection.

  2. Outbound dial-peer towards Webex Calling (This dial-peer will be updated to serve as Inbound dial-peer from Webex Calling as well later in the configuration guide).

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Explanation of commands:

    dial-peer voice 200201 voip
         description Inbound/Outbound Webex Calling

    Defines a VOIP dial-peer with a tag of 200201 and a meaningful description is given for ease of management and troubleshooting

    session target sip-server

    Indicates that the global SIP server is the destination for calls from this dial peer. Webex Calling server defined in tenant 200 is inherited for this dial-peer.

    voice-class stun-usage 200

    The STUN bindings feature on the local gateway allows locally generated STUN requests to be sent over the negotiated media path. This helps in opening up the pinhole in the firewall.

    no voice-class sip localhost

    Disables substitution of the DNS localhost name in place of the physical IP address in the From, Call-ID, and Remote-Party-ID headers of outgoing messages.

    voice-class sip tenant 200

    The dial-peer inherits all the parameters from Tenant 200 (LGW <--> Webex Calling Trunk) unless that same parameter is defined under the dial-peer itself.

    srtp

    SRTP is enabled for this call leg.

    no vad

    Disables voice activity detection.

4

Configure the following dial-peer groups (DPG):

  1. Defines dial-peer group 100. Outbound dial-peer 101 is the target for any incoming dial-peer invoking dial-peer group 100. We will apply DPG 100 to incoming dial-peer 200201 for Webex Calling --> LGW --> PSTN path.

    voice class dpg 100
     description Incoming WxC(DP200201) to IP PSTN(DP101)
     dial-peer 101 preference 1
    
  2. Define dial-peer group 200 with outbound dial-peer 200201 as the target for PSTN --> LGW --> Webex Calling path. DPG 200 will be applied to incoming dial-peer 100 defined later.

    voice class dpg 200
     description Incoming IP PSTN(DP100) to Webex Calling(DP200201)
     dial-peer 200201 preference 1
    
5

Configure the following Inbound dial-peers:

  1. Inbound dial-peer for incoming IP PSTN call legs:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 200
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Explanation of Commands

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

    Defines a VOIP dial-peer with a tag of 100 and a meaningful description is given for ease of management and troubleshooting.

    session protocol sipv2

    Specifies that this dial-peer will be handling SIP call legs.

    incoming uri via 100

    All incoming traffic from IP PSTN to LocalGW is matched on the incoming VIA header’s host IP address defined in voice class URI 100 SIP to match based on source IP (ITSP’s) address.

    destination dpg 200

    With the destination dpg 200, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination Dial-peer group 200, which is dial-peer 200201.

    voice-class sip tenant 300

    The dial-peer will inherit all the parameters from Tenant 300 unless that same parameter is defined under the dial-peer itself.

    no vad

    Disables voice activity detection.

  2. Inbound dial-peer for incoming Webex Calling call legs:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 150
     destination dpg 100
     incoming uri request 200
     

    Explanation of Commands

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling

    Updates a VOIP dial-peer with a tag of 200201 and a meaningful description is given for ease of management and troubleshooting.

    incoming uri request 200

    All incoming traffic from Webex Calling to LGW can be matched on the unique dtg pattern in the request URI, uniquely identifying the local gateway site within an Enterprise and in the Webex Calling ecosystem.

    destination dpg 100

    With the destination dpg 100, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination Dial-peer group 100, which is dial-peer 101.

    max-conn 150

    Restricts the number of concurrent calls to 150 between the LGW and Webex Calling, assuming a single dial-peer facing Webex Calling for both inbound and outbound calls as defined in this guide. For more details on concurrent call limits involving local gateway, visit https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

PSTN to Webex Calling

All incoming IP PSTN call legs on the local gateway are matched on dial-peer 100 as it defines a match criteria for the VIA header with the IP PSTN’s IP address. Outbound dial-peer selection is dictated by DPG 200 that directly invokes outgoing dial-peer 200201, which has the Webex Calling server listed as the target destination.

Webex Calling to PSTN

All incoming Webex Calling call legs on the local gateway are matched on dial-peer 200201 as it meets a match criteria for the REQUEST URI header pattern with the TrunkGroup OTG/DTG parameter, unique to this local gateway deployment. Outbound dial-peer selection is dictated by DPG 100 that directly invokes outgoing dial-peer 101, which has the IP PSTN IP address listed as the target destination.

For this deployment option, the following configuration on the local gateway is required:

  1. Voice class tenants—You must create additional tenants for dial-peers facing Unified CM and ITSP, similar to tenant 200 that we created for Webex Calling facing dial-peers.

  2. Voice class URIs—Patterns defining host IP addresses/ports for various trunks terminating on the LGW: from Unified CM to LGW for PSTN destinations; Unified CM to LGW for Webex Calling destinations; Webex Calling to LGW; and PSTN SIP trunk termination on LGW.

  3. Voice class server-group—Target IP addresses/ports for outbound trunks from LGW to Unified CM, LGW to Webex Calling, and LGW to PSTN SIP trunk.

  4. Outbound dial-peers—To route outbound call legs from LGW to Unified CM, ITSP SIP trunk, and/or Webex Calling.

  5. Voice class DPG—Target outbound dial-peer(s) invoked from an inbound dial-peer.

  6. Inbound dial-peers —To accept inbound call legs from Unified CM, ITSP, and/or Webex Calling.

1

Configure the following voice class tenants:

  1. Voice class tenant 100 is applied on all outbound dial-peers facing Unified CM and IP PSTN:

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Voice class tenant 300 will be applied on all inbound dial-peers from Unified CM and IP PSTN:

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

Configure the following voice class URIs:

  1. Defines ITSP’s host IP address:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Define pattern to uniquely identify a local gateway site within an Enterprise based on Control Hub's TrunkGroup OTG/DTG parameter:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    The local gateway doesn't currently support underscore "_" in the match pattern. As a workaround, we use dot "." (match any) to match the "_".

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
  3. Defines Unified CM signaling VIA port for the Webex Calling trunk:

    voice class uri 300 sip
     pattern :5065
    
  4. Defines CUCM source signaling IP and VIA port for PSTN trunk:

    voice class uri 302 sip
     pattern 192.168.80.60:5060
    
3

Configure the following voice class server-groups:

  1. Defines Unified CM trunk’s target host IP address and port number for Unified CM Group 1 (5 nodes). Unified CM uses port 5065 for inbound traffic on the Webex Calling trunk (Webex Calling <-> LGW --> Unified CM).

    voice class server-group 301
     ipv4 192.168.80.60 port 5065
    
  2. Defines Unified CM trunk’s target host IP address and port number for Unified CM Group 2 if applicable:

    voice class server-group 303
     ipv4 192.168.80.60 port 5065
    
  3. Defines Unified CM trunk’s target host IP address for Unified CM Group 1 (5 nodes). Unified CM uses default port 5060 for inbound traffic on the PSTN trunk. With no port number specified, default 5060 is used. (PSTN <-> LGW --> Unified CM)

    voice class server-group 305
     ipv4 192.168.80.60
    
  4. Defines Unified CM trunk’s target host IP address for Unified CM Group 2, if applicable.

    voice class server-group 307 
     ipv4 192.168.80.60
    
4

Configure the following outbound dial-peers:

  1. Outbound dial-peer towards IP PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Explanation of commands

    dial-peer voice 101 voip
    description Outgoing dial-peer to PSTN

    Defines a VOIP dial-peer with a tag of 101 and a meaningful description is given for ease of management and troubleshooting.

    destination-pattern BAD.BAD

    Digit pattern that will allow selection of this dial-peer. However, we will invoke this outgoing dial-peer directly from the inbound dial-peer using DPG statements and that bypasses the digit pattern match criteria. As a result, we're using an arbitrary pattern based on alphanumeric digits allowed by the destination-pattern CLI.

    session protocol sipv2

    Specifies that this dial-peer will be handling SIP call legs.

    session target ipv4:192.168.80.13

    Indicates the destination’s target IPv4 address where this call leg will be send. (In this case, ITSP’s IP address.)

    voice-class codec 99

    Indicates codec preference list 99 to be used for this dial-peer.

    voice-class sip tenant 100

    The dial-peer will inherit all the parameters from Tenant 100 unless that same parameter is defined under the dial-peer itself.

  2. Outbound dial-peer towards Webex Calling (This dial-peer will be updated to serve as Inbound dial-peer from Webex Calling as well later in the configuration guide.):

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Explanation of commands

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling

    Defines a VOIP dial-peer with a tag of 200201 and a meaningful description is given for ease of management and troubleshooting.

    session target sip-server

    Indicates that the global SIP server is the destination for calls from this dial peer. Webex Calling server defined in tenant 200 will be inherited for this dial-peer.

    voice-class stun-usage 200

    The STUN bindings feature on the LGW allows locally generated STUN requests to be sent over the negotiated media path. This helps in opening up the pinhole in the firewall.

    no voice-class sip localhost

    Disables subsititution of the DNS localhost name in place of the physical IP address in the From, Call-ID, and Remote-Party-ID headers of outgoing messages.

    voice-class sip tenant 200

    The dial-peer inherits all the parameters from Tenant 200 (LGW <--> Webex Calling Trunk) unless that same parameter is defined under the dial-peer itself.

    srtp

    SRTP is enabled for this call leg.

  3. Outbound dial-peer toward Unified CM's Webex Calling Trunk:

    dial-peer voice 301 voip
     description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 301
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Explanation of Commands

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling – Nodes 1 to 5

    Defines a VOIP dial-peer with a tag of 301 and a meaningful description is given for ease of management and troubleshooting.

    session server-group 301

    Instead of session target IP in the dial-peer, we are pointing to a Destination Server Group (server-group 301 for dial-peer 301) to define multiple target UCM nodes though the example only shows a single node.

    Server Group in Outbound Dial Peer

    With multiple dial-peers in the DPG and multiple servers in the dial-peer server group, we can achieve random distribution of calls over all Unified CM call processing subscribers or hunt based on a defined preference. Each server group can have up to five servers (IPv4/v6 with or without port). A second dial-peer and second server group is only required if more than five call processing subscribers are used.

    See https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html for more information.

  4. Second outbound dial-peer toward Unified CM's Webex Calling Trunk if you have more than 5 Unified CM nodes:

    dial-peer voice 303 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from Webex Calling - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 303
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
  5. Outbound dial-peer toward Unified CM's PSTN trunk:

    dial-peer voice 305 voip
     description Outgoing dial-peer to CUCM-Group-1 
    for inbound from PSTN - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 305
     voice-class codec 99 
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
  6. Second outbound dial-peer toward Unified CM’s PSTN Trunk if you have more than 5 Unified CM nodes:

    dial-peer voice 307 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from PSTN - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 307
     voice-class codec 99  
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
5

Configure the following DPG:

  1. Defines DPG 100. Outbound dial-peer 101 is the target for any incoming dial-peer invoking dial-peer group 100. We will apply DPG 100 to incoming dial-peer 302 defined later for the Unified CM --> LGW --> PSTN path:

    voice class dpg 100
     dial-peer 101 preference 1
    
  2. Define DPG 200 with outbound dial-peer 200201 as the target for Unified CM --> LGW --> Webex Calling path:

    voice class dpg 200
     dial-peer 200201 preference 1
    
  3. Define DPG 300 for outbound dial-peers 301 or 303 for the Webex Calling --> LGW --> Unified CM path:

    voice class dpg 300
     dial-peer 301 preference 1
     dial-peer 303 preference 1
    
  4. Define DPG 302 for outbound dial-peers 305 or 307 for the PSTN --> LGW --> Unified CM path:

    voice class dpg 302
     dial-peer 305 preference 1
     dial-peer 307 preference 1
    
6

Configure the following inbound dial-peers:

  1. Inbound dial-peer for incoming IP PSTN call legs:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 302
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Explanation of Commands

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

    Defines a VOIP dial-peer with a tag of 100 and a meaningful description is given for ease of management and troubleshooting.

    session protocol sipv2

    Specifies that this dial-peer will be handling SIP call legs.

    incoming uri via 100

    All incoming traffic from IP PSTN to LGW is matched on the incoming VIA header’s host IP address defined in voice class URI 100 SIP to match based on source IP (ITSP’s) address.

    destination dpg 302

    With the destination DPG 302, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination DPG 302, which can be either dial-peer 305 or dial-peer 307.

    voice-class sip tenant 300

    The dial-peer will inherit all the parameters from Tenant 300 unless that same parameter is defined under the dial-peer itself.

  2. Inbound dial-peer for incoming Webex Calling call legs:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 150
     destination dpg 300
     incoming uri request 200
     

    Explanation of Commands

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling

    Updates a VOIP dial-peer with a tag of 200201 and a meaningful description is given for ease of management and troubleshooting.

    incoming uri request 200

    All incoming traffic from Webex Calling to LGW can be matched on the unique dtg pattern in the request URI, uniquely identifying a local gateway site within an Enterprise and in the Webex Calling ecosystem.

    destination dpg 300

    With the destination DPG 300, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination DPG 300, which can be either dial-peer 301 or dial-peer 303.

    max-conn 150

    Restricts the number of concurrent calls to 150 between the LGW and Webex Calling assuming a single dial-peer facing Webex Calling for both inbound and outbound calls as defined in this guide. For more details about concurrent call limits involving local gateway, visit https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

  3. Inbound dial-peer for incoming Unified CM call legs with Webex Calling as the destination:

    dial-peer voice 300 voip
     description Incoming dial-peer from CUCM for Webex Calling
     session protocol sipv2
     destination dpg 200
     incoming uri via 300
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Explanation of Commands

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

    Defines a VOIP dial-peer with a tag of 300 and a meaningful description is given for ease of management and troubleshooting.

    incoming uri via 300

    All incoming traffic from Unified CM to LGW is matched on the via source port (5065), defined in voice class URI 300 SIP.

    destination dpg 200

    With the destination DPG 200, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination DPG 200, which will be dial-peer 200201.

    voice-class sip tenant 300

    The dial-peer will inherit all the parameters from Tenant 300 unless that same parameter is defined under the dial-peer itself.

  4. Inbound dial-peer for incoming Unified CM call legs with PSTN as the destination:

    dial-peer voice 302 voip
     description Incoming dial-peer from CUCM for PSTN
     session protocol sipv2
     destination dpg 100
     incoming uri via 302
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Explanation of Commands

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

    Defines a VOIP dial-peer with a tag of 302 and a meaningful description is given for ease of management and troubleshooting.

    incoming uri via 302

    All incoming traffic from Unified CM to LGW for a PSTN destination is matched on the Unified CM source signaling IP address and VIA port defined in voice class URI 302 SIP. Standard SIP port 5060 is used.

    destination dpg 100

    With the destination DPG 100, IOS-XE by passes the classic outbound dial-peer matching criteria and straight away proceeds to setup the outgoing call leg using dial-peers defined within destination DPG 100, which will be dial-peer 101.

    voice-class sip tenant 300

    The dial-peer will inherit all the parameters from Tenant 300 unless that same parameter is defined under the dial-peer itself.

IP PSTN to Unified CM PSTN Trunk

Webex Calling Platform to Unified CM Webex Calling Trunk

Unified CM PSTN Trunk to IP PSTN

Unified CM Webex Calling Trunk to Webex Calling Platform

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Implement CUBE High Availability as Local Gateway

Local Gateway (LGW) is the only option to provide on-premises PSTN access for Cisco Webex Calling customers. The objective of this document is to assist you in building a Local Gateway configuration using CUBE high availability, active/standby CUBEs for stateful failover of active calls.

Fundamentals

Prerequisites

Before you deploy CUBE HA as a local gateway for Webex Calling, make sure you have an in-depth understanding of the following concepts:

The configuration guidelines provided in this article assume a dedicated local gateway platform with no existing voice configuration. If an existing CUBE enterprise deployment is being modified to also utilize the local gateway function for Cisco Webex Calling, pay close attention to the configuration applied to ensure existing call flows and functionalities are not interrupted and make sure you're adhering to CUBE HA design requirements.

Hardware and Software Components

CUBE HA as local gateway requires IOS-XE version 16.12.2 or later and is supported on the following platforms:

  • ISR4000 series—4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)

  • CSR1000 series—vCUBE (1, 2, and 4 vCPU configurations)


The show commands and logs in this article are based on a minimum software release of Cisco IOS-XE 16.12.2 implemented on a vCUBE (CSR1000v).

Reference Material

Here are some detailed CUBE HA configuration guides for various platforms:

Webex Calling Solution Overview

Cisco Webex Calling is a collaboration offering that provides multi-tenant cloud-based alternative to on-premise PBX phone service with two PSTN options for customers:

  • Cloud Connected PSTN Provider

  • Local Gateway

The Local Gateway deployment (represented below) is the focus of this article. Local gateway is the Bring Your Own PSTN option for Cisco Webex Calling by providing connectivity to a customer-owned PSTN service. It also provides connectivity to an on-premises IP PBX deployment such as Cisco Unified CM. All communication to and from the cloud is secured using TLS transport for SIP and SRTP for media.

The figure below displays a Webex Calling deployment without any existing IP PBX and is applicable to a single or a multi-site deployment. Configuration outlined in this article is based on this deployment.

Layer 2 Box-to-Box Redundancy

CUBE HA layer 2 box-to-box redundancy uses the Redundancy Group (RG) infrastructure protocol to form an active/standby pair of routers. This pair share the same virtual IP address (VIP) across their respective interfaces and continually exchange status messages. CUBE session information is check-pointed across the pair of routers enabling the standby router to take all CUBE call processing responsibilities over immediately if the active router goes out of service, resulting in stateful preservation of signaling and media.


Check pointing is limited to connected calls with media packets. Calls in transit are not check pointed (for example, a trying or ringing state).

In this article, CUBE HA will refer to CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundancy for stateful call preservation

As of IOS-XE 16.12.2, CUBE HA can be deployed as Local Gateway for Cisco Webex Calling deployments and we'll cover design considerations and configurations in this article. This figure displays a typical CUBE HA setup as Local Gateway for a Cisco Webex Calling deployment.

Redundancy Group Infra Component

The Redundancy Group (RG) Infra component provides the box-to-box communication infrastructure support between the two CUBEs and negotiates the final stable redundancy state. This component also provides:

  • An HSRP-like protocol that negotiates the final redundancy state for each router by exchanging keepalive and hello messages between the two CUBEs (via the control interface)—GigabitEthernet3 in the figure above.

  • A transport mechanism for checkpointing the signaling and media state for each call from the active to the standby router (via the data interface)—GigabitEthernet3 in the figure above.

  • Configuration and management of the Virtual IP (VIP) interface for the traffic interfaces (multiple traffic interfaces can be configured using the same RG group) – GigabitEthernet 1 and 2 are considered traffic interfaces.

This RG component has to be specifically configured to support voice B2B HA.

Virtual IP (VIP) Address Management for Both Signaling and Media

B2B HA relies on VIP to achieve redundancy. The VIP and associated physical interfaces on both CUBEs in the CUBE HA pair must reside on the same LAN subnet. Configuration of the VIP and binding of the VIP interface to a particular voice application (SIP) are mandatory for voice B2B HA support. External devices such as Unified CM, Webex Calling access SBC, service provider, or proxy, use VIP as the destination IP address for the calls traversing through the CUBE HA routers. Hence, from a Webex Calling point of view, the CUBE HA pairs acts as a single local gateway.

The call signaling and RTP session information of established calls are checkpointed from the active router to the standby router. When the Active router goes down, the Standby router takes over, and continues to forward the RTP stream that was previously routed by the first router.

Calls in a transient state at the time of failover will not be preserved post-switchover. For example, calls that aren't fully established yet or are in the process of being modified with a transfer or hold function. Established calls may be disconnected post-switchover.

The following requirements exist for using CUBE HA as a local gateway for stateful failover of calls:

  • CUBE HA cannot have TDM or analog interfaces co-located

  • Gig1 and Gig2 are referred to as traffic (SIP/RTP) interfaces and Gig3 is Redundancy Group (RG) Control/data interface

  • No more than 2 CUBE HA pairs can be placed in the same layer 2 domain, one with group id 1 and the other with group id 2. If configuring 2 HA pairs with the same group id, RG Control/Data interfaces needs to belong to different layer 2 domains (vlan, separate switch)

  • Port channel is supported for both RG Control/data and traffic interfaces

  • All signaling/media is sourced from/to the Virtual IP Address

  • Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby

  • Lower address for all the interfaces (Gig1, Gig2, Gig3) should be on the same platform

  • Redundancy Interface Identifier, rii should be unique to a pair/interface combination on the same Layer 2

  • Configuration on both the CUBEs must be identical including physical configuration and must be running on the same type of platform and IOS-XE version

  • Loopback interfaces cannot be used as bind as they are always up

  • Multiple traffic (SIP/RTP) interfaces (Gig1, Gig2) require interface tracking to be configured

  • CUBE-HA is not supported over a crossover cable connection for the RG-control/data link (Gig3)

  • Both platforms must be identical and be connected via a physical Switch across all likewise interfaces for CUBE HA to work, i.e. GE0/0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on.

  • Cannot have WAN terminated on CUBEs directly or Data HA on either side

  • Both Active/Standby must be in the same data center

  • It is mandatory to use separate L3 interface for redundancy (RG Control/data, Gig3). i.e interface used for traffic cannot be used for HA keepalives and checkpointing

  • Upon failover, the previously active CUBE goes through a reload by design, preserving signaling and media

Configure Redundancy on Both CUBEs

You must configure layer 2 box-to-box redundancy on both CUBEs intended to be used in an HA pair to bring up virtual IPs.

1

Configure interface tracking at a global level to track the status of the interface.

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit
VCUBE-1#conf t
VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#exit
VCUBE-2#conf t
VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#exit

Track CLI is used in RG to track the voice traffic interface state so that the active route will quite its active role after the traffic interface is down.

2

Configure an RG for use with VoIP HA under the application redundancy sub-mode.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit
VCUBE-1(config)#redundancy
VCUBE-1(config-red)#application redundancy
VCUBE-1(config-red-app)#group 1
VCUBE-1(config-red-app-grp)#name LocalGateway-HA
VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-1(config-red-app-grp)#timers delay 30 reload 60
VCUBE-1(config-red-app-grp)#track 1 shutdown
VCUBE-1(config-red-app-grp)#track 2 shutdown
VCUBE-1(config-red-app-grp)#exit
VCUBE-1(config-red-app)#protocol 1
VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#exit
VCUBE-1(config-red-app)#exit
VCUBE-1(config-red)#exit
VCUBE-1(config)#
VCUBE-2(config)#redundancy
VCUBE-2(config-red)#application redundancy
VCUBE-2(config-red-app)#group 1
VCUBE-2(config-red-app-grp)#name LocalGateway-HA
VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-2(config-red-app-grp)#timers delay 30 reload 60
VCUBE-2(config-red-app-grp)#track 1 shutdown
VCUBE-2(config-red-app-grp)#track 2 shutdown
VCUBE-2(config-red-app-grp)#exit
VCUBE-2(config-red-app)#protocol 1
VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#exit
VCUBE-2(config-red-app)#exit
VCUBE-2(config-red)#exit
VCUBE-2(config)#

Here's an explanation of the fields used in this configuration:

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • Delay timer which is the amount of time to delay RG group’s initialization and role negotiation after the interface comes up – Default 30 seconds. Range is 0-10000 seconds

    • Reload—This is the amount of time to delay RG group initialization and role-negotiation after a reload – Default 60 seconds. Range is 0-10000 seconds

    • Default timers are recommended, though these timers may be adjusted to accommodate any additional network convergence delay that may occur during bootup/reload of the routers, in order to guarantee that the RG protocol negotiation takes place after routing in the network has converged to a stable point. For example, if it is seen after failover that it takes up to 20 sec for the new STANDBY to see the first RG HELLO packet from the new ACTIVE, then the timers should be adjusted to ‘timers delay 60 reload 120’ to factor in this delay.

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • Hellotime— Interval between successive hello messages – Default 3 seconds. Range is 250 milliseconds-254 seconds

    • Holdtime—The interval between the receipt of a Hello message and the presumption that the sending router has failed. This duration has to be greater than the hello-time – Default 10 seconds. Range is 750 milliseconds-255 seconds

      We recommend that you configure the holdtime timer to be at least 3 times the value of the hellotime timer.

3

Enable box-to-box redundancy for the CUBE application. Configure the RG from the previous step under voice service voip. This enables the CUBE application to control the redundancy process.

voice service voip
   redundancy-group 1
   exit
VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-1(config-voi-serv)# exit
VCUBE-2(config)#voice service voip
VCUBE-2(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-2(config-voi-serv)# exit

redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. We'll reload the platforms after all the configuration has been applied.

4

Configure the Gig1 and Gig2 interfaces with their respective virtual IPs as shown below and apply the redundancy interface identifier (rii)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redundancy rii 1
VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-1(config)#
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redundancy rii 2
VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redundancy rii 1
VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-2(config-if)# exit
VCUBE-2(config)#
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redundancy rii 2
VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-v(config-if)# exit

Here's an explanation of the fields used in this configuration:

  • redundancy rii—Configures the redundancy interface identifier for the redundancy group. Required for generating a Virtual MAC (VMAC) address. The same rii ID value must be used on the interface of each router (ACTIVE/STANDBY) that has the same VIP.


     

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. Configure the RG group, as well as the VIP assigned to this physical interface.


     

    It is mandatory to use a separate interface for redundancy, that is, the interface used for voice traffic cannot be used as control and data interface specified in Step 2 above. In this example, Gigabit interface 3 is used for RG control/data

5

Save the configuration of the first CUBE and reload it.

The platform to reload last is always the Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

After VCUBE-1 boots up completely, save the configuration of VCUBE-2 and reload it.

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
6

Verify that the box-to-box configuration is working as expected. Relevant output is highlighted in bold.

We reloaded VCUBE-2 last and as per the design considerations; the platform to reload last will always be Standby.


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

Configure a Local Gateway on Both CUBEs

In our example configuration, we're using the following information from Control Hub to build the Local Gateway configuration on both the platforms, VCUBE-1 and VCUBE-2. The username and password for this setup are as follows:

  • Username: Hussain1076_LGU

  • Password: lOV12MEaZx

1

Ensure that a configuration key is created for the password, with the commands shown below, before it can be used in the credentials or shared secrets. Type 6 passwords are encrypted using AES cipher and this user-defined configuration key.


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

Here is the Local Gateway configuration that will apply to both platforms based on the Control Hub parameters displayed above, save and reload. SIP Digest credentials from Control Hub are highlighted in bold.


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

To display the show command output, we've reloaded VCUBE-2 followed by VCUBE-1, making VCUBE-1 the standby CUBE and VCUBE-2 the active CUBE

2

At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex Calling access SBC. Take a look at the output of the following show commands.

show redundancy application group 1

show sip-ua-register status


VCUBE-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#

VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1

3

Now enable the following debugs on VCUBE-1


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

Simulate failover by issuing the following command on the active LGW, VCUBE-2 in this case.


VCUBE-2#redundancy application reload group 1 self

Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenario as well besides the CLI listed above

  • When the ACTIVE router reloads

  • When the ACTIVE router power cycles

  • When any RG configured interface of the ACTIVE router is shutdown for which tracking is enabled

5

Check to see if VCUBE-1 has registered with Webex Calling access SBC. VCUBE-2 would have reloaded by now.


VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 is now the active LGW.

6

Look at the relevant debug log on VCUBE-1 sending a SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0
Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0
Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0
Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0
Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Configure Unified CM for Webex Calling

You may required an integration with Unified CM if Webex Calling-enabled locations are added to an existing deployment where Unified CM is the on-premises call control solution and if you require direct dialing between phones registered to Unified CM and phones in Webex Calling locations.

Configure SIP Trunk Security Profile for Trunk to Local Gateway

In cases where Local Gateway and PSTN gateway reside on the same device, Unified CM must be enabled to differentiate between two different traffic types (calls from Webex and from the PSTN) that are originating from the same device and apply differentiated class for service to these call types. This differentiated call treatment is achieved by provisioning two trunks between Unified CM and the combined local gateway and PSTN gateway device which requires different SIP listening ports for the two trunks.

Create a dedicated SIP Trunk Security Profile for the Local Gateway trunk with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex SIP Trunk Security Profile
Incoming Port Needs to match port used in local gateway config for traffic to/from Webex: 5065

Configure SIP Profile for the Local Gateway Trunk

Create a dedicated SIP Profile for the Local Gateway trunk with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex SIP Profile
Enable OPTIONS Ping to monitor destination status for Trunks with Service Type “None (Default)” Checked

Create a Calling Search Space for Calls From Webex

Create a calling search space for calls originating from Webex with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex Calling Search Space
Selected Partitions

DN (+E.164 directory numbers)

ESN (abbreviated inter-site dialling)

PSTNInternational (PSTN access)

onNetRemote (GDPR learned destinations)


 

The last partition onNetRemote is only used in a multi-cluster environment where routing information is exchanged between Unified CM clusters using Intercluster Lookup Service (ILS) or Global Dialplan Replication (GDPR).

Configure a SIP Trunk To and From Webex

Create a SIP trunk for the calls to and from Webex via the Local Gateway with the following settings:

Setting Value
Device Information
DeviceName A unique name, such as Webex
Description Meaningful description, such as Webex SIP Trunk
Run On All Active Unified CM Nodes Checked
Inbound Calls
Calling Search Space The previously defined calling search space: Webex
AAR Calling Search Space A calling search space with only access to PSTN route patterns: PSTNReroute
SIP Information
Destination Address IP address of the Local Gateway CUBE
Destination Port 5060
SIP Trunk Security Profile Previously defined: Webex
SIP Profile Previously defined: Webex

Configure Route Group for Webex

Create a route group with the following settings:

Setting Value
Route Group Information
Route Group Name A unique name, such as Webex
Selected Devices The previously configured SIP trunk: Webex

Configure Route List for Webex

Create a route list with the following settings:

Setting Value
Route List Information
Name A unique name, such as RL_Webex
Description Meaningful description, such as Route list for Webex
Run On All Active Unified CM Nodes Checked
Route List Member Information
Selected Groups Only the previously defined route group: Webex

Create a Partition for Webex Destinations

Create a partition for the Webex destinations with the following settings:

Setting Value
Route List Information
Name Unique name, such as Webex
Description Meaningful description, such as Webex Partition

What to do next

Make sure to add this partition to all calling search spaces that should have access to Webex destinations. You must add this partition specifically to the calling search space that is used as the inbound calling search space on PSTN trunks, so that calls from the PSTN to Webex can be routed.

Configure Route Patterns for Webex Destinations

Configure route patterns for each DID range on Webex with the following settings:

Setting Value
Route Pattern Full +E.164 pattern for the DID range in Webex with the leading “\”. For example: \+140855501XX
Route Partition Webex
Gateway/Route List RL_Webex
Urgent Priority Checked

Configure Abbreviated Intersite Dialing Normalization for Webex

If abbreviated inter-site dialing is required to Webex, then configure dialing normalization patterns for each ESN range on Webex with the following settings:

Setting Value
Translation Pattern ESN pattern for the ESN range in Webex. For example: 80121XX
Partition Webex
Description Meaningful description, such as Webex Normalization Pattern
Use Originator's Calling Search Space Checked
Urgent Priority Checked
Do Not Wait For Interdigit Timeout On Subsequent Hops Checked
Called Party Transformation Mask Mask to normalize the number to +E.164. For example: +140855501XX
Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Set Up Your Webex Calling Features

Create and Manage Auto Attendants

Ensure that calls are answered and that callers' needs are met. You can add greetings, set up menus, and route calls to an answering service, a hunt group, a voicemail box, or a real person. You can create a 24-hour schedule or provide different options when your business is open or closed.

For information about how to create and manage Auto Attendants, see Manage Auto Attendants in Cisco Webex Control Hub.

Set up a Hunt Group

Hunt groups can route incoming calls to a group of users or workspaces. You can even configure a pattern to route to a whole group.

For more information on how to set up a Hunt Group, see Hunt Groups in Cisco Webex Control Hub.

Create a Receptionist Client

Help support the needs of your front-office personnel. You can set up users as telephone attendants so that they can screen all incoming calls to certain people within your organization.

For information about how to set up and view your receptionist clients, see Receptionist Clients in Cisco Webex Control Hub.

Configure a Paging Group

Group Paging allows a user to place a one-way call or group page to up to 75 target users and workspaces by dialing a number or extension assigned to a specific paging group.

For information about how to set up and edit Paging Groups, see Configure a Paging Group in Cisco Webex Control Hub.

Create a Call Queue

You can set up a call queue so that when customers' calls can't be answered, they're provided with an automated answer, comfort messages, and music on hold until someone can answer their call.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Features.

2

Click New Feature and then choose Call Queue.

3

Enter a Pilot Number and then indicate whether you own the number, if it's been provided to you by your partner, or if you want to port the number over.

4

If you're porting a number over, you must enter the billing number associated with your current service provider as well as the billing number associated with your new service provider.

5

Click Save.

What to do next

You can configure the calling feature further by selecting the call queue instance from Services > Calling > Features. You're brought to Advanced Services in the Calling Admin Portal, where you can complete your configuration. For more information, see Configuring Call Queues.

Set Up Call Pickup

You can enhance teamwork and collaboration by creating a call pickup group so users can answer each others calls. When you add users to a call pickup group and a group member is away or busy, another member can answer their calls.

For information about how to set up a call pickup group, see Call Pickup in Cisco Webex Control Hub.

Set Up Call Park

Call park allows a defined group of users to park calls against other available members of a call park group. Parked calls can be picked up by other members of the group on their phone.

For more information about how to set up call park, see Call Park in Cisco Webex Control Hub.

Allow Users to Barge in to Other People's Phone Calls

1

From the customer view in https://admin.webex.com, go to Users, and then select the user you want to modify.

2

Select Calling, go to Advanced Call Settings, and then select Barge In.

3

Turn on Barge In, choose whether you want the phone to play a sound when someone barges into a call, and then click Save.

Turn on Hoteling for a Webex Calling User

Hoteling consists of two features: Hoteling Host and Hoteling Guest. These features work together to allow you to designate specific phones (hosts) that users (guests) can temporarily sign into and use as their own phone. When a guest signs in to a host phone, their user profile is automatically transferred to the device. The host device becomes the user’s primary device for a specified period of time.

The steps presented here can be followed to configure a user as a hoteling guest. For information about the host phone, see Configure Host Phone.

1

From the customer view in https://admin.webex.com, go to Users and then select the user you want to modify.

2

Select Calling, choose Advanced Call Settings, and click Hoteling.

3

Turn on Hoteling, and then click Save.

Prevent Someone from Monitoring a User's Line Status

1

From the customer view in https://admin.webex.com, go to Users, and select the user you want to modify.

2

Select Calling and then go to Privacy.

3

Choose the appropriate Auto Attendant Privacy settings for this user.

4

Check the Enable Privacy check box. You can then decide whether to block everyone by leaving the Search user by name field empty or choose who can monitor this user's line status.

Using the executive example above, you'd search for the name of their administrative assistant.

5

Click Save.

Allow a User to See the Line Status on Someone Else's Phone or on a Call Park Extension

The maximum number of monitored lines is 50 but you should consider bandwidth. The maximum may also be determined by the number of line buttons on the user's phone.

1

From the customer view in https://admin.webex.com, go to Users, and select the user you want to modify.

2

Select Calling, choose Advanced Call Settings, and then go to Monitoring.

3

Choose from the following:

  • Add Monitored Line
  • Add Call Park Extension
4

Choose whether you want this user to be notified about parked calls, search for the person or call park extension to be monitored, and then click Save.


 

The monitored lines list in Control Hub corresponds with the order of monitored lines that show on the user’s device. You can re-order the list of monitored lines at anytime.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Configure and Manage Your Webex Calling Users

You must add each and every user in Cisco Webex Control Hub in order for them to take advantage of Webex Calling services. The number of users you need to add will determine how you add them in Control Hub, whether you manually add each user by email address or add multiple users using a CSV file. The choice is yours.

You may get an error if you're trying to add users who used their e-mail address to create a trial account. Have the users delete their organization first before adding them to your organization.


If you have an Active Directory and use Cisco Directory Connector when you manually add people in Control Hub, you must also add them to your Active Directory.

Cisco Webex Contact Center doesn't support Active directory.


When adding users, first and last names must not include extended ascii characters or the following characters %, #, <, >, \, /,", and have a maximum length of 30 characters.

1

From the customer view in https://admin.webex.com go to Users, and then click Manage Users.

2

Select Manually Add or Modify Users.

3

(Optional) If you automatically send welcome emails, then click Next.

4

Choose one and click Next:

  • Select Email address, and enter up to 25 email addresses.
  • Select Names and Email addresses, and then enter up to 25 names and email addresses.

 

You can add users who are available to convert to your organization.

5

License assignment:

  • If you have an active license template, licenses are assigned automatically for new users and you can review the license summary.
  • Select the services to assign. If you have multiple subscriptions, choose a subscription from the list.


 

If you’re assigning licenses for Cisco Webex Contact Center, select Webex Teams, then Customer Care with the Premium and Standard Agent option. To add a supervisor, select both Premium and Supervisor options. A user is treated as an agent unless you make them a supervisor.

6

Content management:

  • If global access is selected for your enterprise content management, then content management is automatically assigned to users.
  • Choose a content management option for each user.

7

Click Save.

  • An email is sent to each person with an invite to join.

  • In Control Hub, people appear in an invite pending state until they sign in for the first time. Licenses are assigned after the user signs in the first time or if you use Cisco Directory Connector with a claimed domain, the licenses are assigned when users are created.

8

(Optional) If you added Calling to the user, assign a location, phone number, and extension.

9

Review the summary page of records processed, and click Finish.

What to do next

You can assign administrative privileges to people in your organization.

Before you begin

If you have more than one CSV file for your organization, then upload one file and once that task has completed, you can upload the next file.


Some spreadsheet editors remove the + sign from cells when the .csv is opened. We suggest you use a text editor to make .csv updates. If you use a spreadsheet editor make sure to set the cell format to text, and add back any + signs that were removed.

1

From the customer view in https://admin.webex.com, go to Users, click Manage Users and choose CSV Add or Modify Users.

2

Click Export to download the file and you can enter user information in a new line in the CSV file.

  • To assign a service, add TRUE in that service's column, and to exclude a service, add FALSE. The User ID/Email (Required) column is the only required field. If you have specific directory and external numbers for each new user, then include the leading + for external numbers without other characters,

    If you have an active license template, leave all the service columns blank and the template is automatically assigned for the new user in that row.


     

    You can't assign enterprise content management permissions to users using the license template, see Enable Content Management for Users in Cisco Webex Control Hub for details.

  • To assign a location, enter the the name in the Location column. If you leave this field blank, the user is assigned to the default location.

  • If you’re adding users as supervisors for Cisco Webex Contact Center, then you must Add Users Manually. You can only assign Standard and Premium roles with a CSV.

 

When entering a user's name, make sure to include their last name, otherwise you may run into issues.

3

Click Import, select your file, and click Open.

4

Choose either Add services only or Add and remove services.

If you have an active license template, choose Add services only.

5

Click Submit.

The CSV file is uploaded and your task is created. You can close the browser or this window and your task continues to run. To review the progress of your task, see Manage Tasks in Cisco Webex Control Hub.

As an administrator with full privileges, you can edit specific service details for individual users in Cisco Webex Control Hub.

1

From the customer view in https://admin.webex.com go to Users.

2

Select a user and click Services > Edit.

3

If you have multiple subscriptions, choose a subscription from the list.

4

Select the services to add or remove, and click Save.

Before you begin

If you have more than one CSV file for your organization, then upload one file and once that task has completed, you can upload the next file.

You can’t delete users or change the location assigned to a user with the CSV template.


Some spreadsheet editors remove the + sign from cells when the .csv is opened. We suggest you use a text editor to make .csv updates. If you use a spreadsheet editor make sure to set the cell format to text, and add back any + signs that were removed.

1

From the customer view in https://admin.webex.com, go to Users, click Manage Users, and choose CSV Add or Modify User.

2

(Optional) If you automatically send welcome emails, then click Next.

3

Click Export to download the file. You can edit the downloaded file (exported_users.csv) in any of the following ways:

  • To modify existing users, you can update any column except User ID/Email (Required), and Location. For example, if you change User ID/Email this creates a new user.

  • To assign a location, enter the the name in the Location column. If you leave this field blank, the user is assigned to the default location.

  • To assign a service, add TRUE in that service's column, and to exclude a service, add FALSE.

  • When you have multiple subscriptions, you can use the subscription ID in the column header to identify the service you want to add. For example, if you have two subscriptions with the same service, you can specify a service from a specific subscription to apply to the user.

4

Enter a value in the Calling Behavior column if you want to change the way calls happen for specific users. You can enter one of the following options and see Set Up Cisco Webex Calling Behavior for more information on each setting:

  • USE_ORG_SETTINGS—Enter this string to use the organization-wide setting.

  • NATIVE_WEBEX_TEAMS_CALLING—Enter this string to use the Calling in Webex Teams option.

  • CALL_WITH_APP_REGISTERED_FOR_WEBEXCALLTEL—Enter this string to use the Webex Calling app option.

5

Enter a Caller ID Number, Caller ID First Name, and Caller ID Last name. If you leave the Caller ID Number, Caller ID First Name, and Caller ID Last name columns blank, then what is in the First Name, Last Name and Phone Number column will show when the user makes a call. If you leave the Caller ID Number blank then the Location Main Number shows when the user makes a call.


 

The Caller ID First Name and Caller ID Last Name columns can’t contain special characters. If a Caller Caller ID First Name or Caller ID Last Name contains a special character, then a simplified version of the name is used.

6

After you save the CSV file, click Import, select the file you made changes to, and then click Open.

7

Choose either Add services only or Add and remove services, and click Submit.

The CSV file is uploaded and your task is created. You can close the browser or this window and your task continues to run. To review the progress of your task, see Manage Tasks in Cisco Webex Control Hub.

If you don't suppress admin invite emails, new users receive activation emails.

You can assign numbers, extensions, or both to people's devices at any time. Assigned extensions show up on phone displays.

You can also configure alternate numbers so that multiple phone numbers ring the same phone. You can specify different ring tones for each number to help distinguish between which lines are being called.

1

From the customer view in https://admin.webex.com, go to Users, and then choose the person you want to assign a number to.

2

Select Calling and then click Add Number.

3

Choose a phone number from the list of available numbers. You also have the option of assigning an extension.

4

Click Save.

5

(Optional) Configure alternate numbers for this user.

1

From the customer view in https://admin.webex.com, go to Users, filter the Status column to display people with an Invite Pending status.

2

Under Actions, for a person with an Invite Pending status, select more > Resend Invitation.

If your organization uses directory synchronization, the delete option is not available in Control Hub, and you must delete user accounts from your Active Directory. Then, the Cisco Directory Connector updates your organizations user list when it synchronizes the user account information.

From the customer view in https://admin.webex.com, go to Users, click the more button, and then click Delete User.

The user can no longer sign in to your Webex site, all their assigned Webex services are removed, and they are removed from any spaces or teams that they were participating in. Any content that they created in spaces is not deleted, and the content is subject to the retention policy that each space owner has implemented.

You can set up a customer administrator with different privilege levels. They can be full administrators, support administrators, read-only administrators or compliance officers. With full administrator privileges, you can assign one or more roles to any user in your organization.


Anyone assigned the user and device administrator or device administrator role will not be able to administer Webex Calling.

In Control Hub, you can learn about different privilege levels and set up a customer administrator. Customer administrators can be full administrators, support administrators, user and device administrators, device administrators, read-only administrators, or compliance officers. With full administrator privileges, you can assign one or more roles to any user in your organization.

You’ll always want to have more than one administrator for an organization. It’s a best practice and will always allow you to make administrative changes if one of the administrators isn't available.

Users within your organization can be assigned specific administrative roles to determine what they can see and have access to in Control Hub. When you assign specific administrative roles, you streamline responsibilities and make it easier to hold administrators accountable. Compliance officers can look for specific people in your company, find content they've shared, or search through a specific space and then generate a report of their findings.


1

From the customer view in https://admin.webex.com, go to Users, and choose a user.

2

Under Roles and Security click Administrator Roles or Service Access.

3

Select a role to assign to that user.

4

Select Save.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Configure and Manage Webex Calling Devices

As an administrator, you can assign devices to Users or Workspaces in Webex Control Hub. You have the choice of providing the MAC address of a device or generating an activation code that must then be manually entered on the device itself.

With Cisco Webex Control Hub, you can assign devices to users for personal usage and then register those devices to the cloud.

The devices listed here support Webex Calling. While all of these devices can be registered using a MAC address, only the following subset can be registered using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851, 6861, 6871)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832


With regards to DECT devices, only DECT base devices (not DECT handsets) are available for assignment in Control Hub. After you assign a base unit to a user, you must then manually pair a DECT handset to that base unit. For more information, see Connect the Handset to the Base Station.

1

From the customer view in https://admin.webex.com, go to Devices and then click Add Device.


 
You can also add a phone to a user in the user's profile. See how in Manage a Device for a User section.
2

Choose Existing User, enter the phone's owner, either part of the username or the user's real name, choose the user from the results, and then click Next.

3

Choose the device from the drop-down list, and then click Next.

4

Choose one of the following options and then click Save:

  • By Activation Code—Choose this option if you want to generate an activation code that you can share with the device owner. The 16-digit activation code must be manually entered onto the device itself.

     

    Multiplatform phones must have a firmware load of 11.2.3MSR1 or later to display the activation code screen. If phone firmware needs to be updated, point users to https://upgrade.cisco.com/MPP_upgrade.html.

  • By MAC Address—Choose this option if you know the MAC address of the device. A phone's MAC address must be a unique entry. If you enter a MAC address for a phone that's already registered or you make a mistake when you enter the number, an error message appears.

 

Limitations may apply when using third-party devices.

If you chose to generate an activation code for the device but you haven't yet used that code, the status of that device reads as Activating in the assigned user's Devices section in Control Hub and the main Devices list in the Calling Admin Portal. The activating device doesn't appear in the main Devices window in Control Hub until the device is successfully activated. Keep in mind it may take up to 10 minutes for device status to be updated in Control Hub.

When people are at work, they get together in lots of places like lunch rooms, lobbies, and conference rooms. You can set up shared Cisco Webex devices in these Workspaces, add services, and then watch the collaboration happen.

The key principle of a Workspaces device is that it is not assigned to a specific user, but rather a physical location, allowing for shared usage.

The devices listed here support Webex Calling. While all of these devices can be registered using a MAC address, only the following subset can be registered using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832

1

From the customer view in https://admin.webex.com, go to Workspaces, and then click Add Workspace.

2

Enter a name for the workspace (such as the name of the physical room), select room type and add capacity. Then click Next.

3

Choose Cisco IP Phone and then click Next.

4

Select the device type from the drop-down list, choose whether you want to register the phone with an activation code or a MAC address, and then click Next. Keep in mind that if you choose to register the device using an activation code, the code is emailed to the designated administrator for the location.

For Webex Calling, you can only add one shared phone to a Workspace.

For Cisco IP Conference Phone 7832, some softkeys may not be available. If you need a full set of softkeys, we recommend that you assign this phone to a user instead.

5

Assign a Location and Phone Number (determined by the location that you choose), and then click Save. You also have the option of assigning an extension.

When people are at work, they get together in lots of workspaces like lunch rooms, lobbies, and conference rooms. You can set up shared Cisco Webex devices in these Workspaces, add services, and then watch the collaboration happen.

The key principle of a Workspaces device is that it is not assigned to a specific user, but rather a physical location, allowing for shared usage.

The devices listed here support Webex Calling.

1

From the customer view in https://admin.webex.com, go to Workspaces, and then click Add Workspace.

2

Enter a name for the workspace (such as the name of the physical room), select room type and add capacity. Then click Next.

3

Choose Other Cisco Webex Device and then click Next.

Other Cisco Webex Devices include Cisco Webex Room or Desk device, including Cisco Webex Board.

4

Choose one of the following options:

  • Free Calling—Users can only make Webex or Webex Session Initiation Protocol (SIP) calls using a SIP address (for example, username@example.calls.webex.com).
  • Cisco Webex Calling—In addition to being able to make and receive Webex and SIP calls, people in this Workspace can use the device to make and receive phone calls from within the Webex Calling numbering plan. For example, you can call your coworker Giacomo Edwards by dialing his phone number 555-555-5555, his extension 5555, or his SIP address gedwards@example.webex.com but you can also call your local pizzeria.
5

Activate the device by using the code provided. You can copy, email, or print the activation code.

If you have several devices that you need to assign to users and places, you can populate a CSV file with the required information and activate those devices in just a couple of easy steps.

The devices listed here support Webex Calling. While all of these devices can be registered using a MAC address, only the following subset can be registered using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832

1

From the customer view in https://admin.webex.com, go to Devices, click Add Device, and then choose whether you're adding the device to a user or a place.

2

Select Import/upload CSV file.

3

Choose one of the following options:

  • Export user attributes—You can get a list of all of the users in your organization and their associated attributes so you don't have to manually look up each user.
  • Download CSV template—You can use a template that we've come up with and then enter information such as usernames, type (indicate whether it's a user or a place), MAC addresses, and device models. Here are a few things to keep in mind:
    • For the Username column of the CSV file, make sure you enter the user's email address, not their user ID or their name. You can also insert a Place name in this column.

    • We recommend that you limit the number of devices to 1000 per CSV file. If you need to add more than that, use a second CSV file.

    • If you enter a place that doesn't yet exist, the place is automatically created for you.

    • If you leave the MAC address column blank, an activation code is generated and must be entered on the device itself.

4

If the MAC address has been left blank, you can choose where the activation code gets sent:

  • Provide a link—The activation code gets added to a CSV file that you can then download.
  • Email activation code—If the device is for a place, the activation code gets sent to you, as the administrator. If the device is for a user, the activation code is emailed to the user.
5

Import the populated CSV file.

6

Click Submit.

You're presented with a status update as devices become activated.

 

Multiplatform devices must be running a firmware load of 11.2.3MSR1 or later in order for users to be able to enter the activation code on their device. For information about how to upgrade phone firmware, see this article.

You can add, remove, reboot, check activation, or create a new activation code for the devices assigned to users within your organization. This can be helpful to view and manage from the users screen, when needed.

1

From the customer view in https://admin.webex.com, go to Users.

2

Select the user to modify and scroll down to Devices.

3

To add a device to this user, click Add Device.


 
If the user is already assigned a device, and you would like to add another device, click the More Options icon next to Devices and click Add Device.
4

To modify an existing device, select the device name.

Here you can view and edit device settings, delete the device, reboot the device, or create a new activation code for the device, if applicable. For more information about configuring phone settings, see Configure and Update Phone Settings.

Devices can be added and managed directly from a workspace profile. Workspace devices can include ATA devices, like fax machines. You can also set up a workspace device as a Hoteling Host. For more information about hoteling, see Hoteling in Cisco Webex Control Hub.

1

From the customer view in https://admin.webex.com, go to Workspaces.

2

Select the workspace to modify and go to the Devices tile.

3

To add a device, click Add Device.

4

To modify an existing device, select the device name.

Here you can view and edit device settings, delete the device, reboot the device, and enable the device to be used as a Hoteling Host. For more information about configuring phone settings, see Configure and Update Phone Settings.

You can add lines to a user's primary device and reorder how the lines appear. This is also referred to as shared line appearance, which allows users to receive and place calls to and from another user's extension, using their own phone. An example of this is an executive assistant who wants to be able to make and receive calls from the boss's line. Shared line appearances can also be another instance of the primary user's line.

Additional lines can be added to a workspace phone, but a workspace phone cannot be added as a shared line.

1

From the customer view in https://admin.webex.com, go to Users or Workspaces (depending on where the device to modify is assigned).

2

Select the user or workspace to modify and scroll to Devices.

3

Select the device where you would like to add or modify the shared lines and scroll to Phone Users and Settings.

The users and places that appear on this phone are listed in order of appearance.

4

To add or remove users or places from this phone, select Configure Lines.

5

To remove a line, click the Trash icon.


 
The primary user on line 1 cannot be removed.
6

To add a shared line appearance, click the Plus icon.


 
Add the lines in the order in which you want them to appear. To reorder the line appearance, delete and add to the list in the order you want them to appear.
7

Enter the name or phone number and select from the options that appear and click Save.

You can configure the ports on an Analog Telephone Adaptor (ATA) device assigned to a user in Control Hub. Currently, the two configurations for ATA devices available are for devices with 2 ports and devices with 24 ports.

1

From the customer view in https://admin.webex.com, go to Users.

2

Select the user to modify and scroll to Devices.

3

Select the device where you would like to add or modify.

4

Under Users on this Device, click Configure Ports.

5

To add a shared port configuration, click the Plus icon.

6

Enter the name or phone number and select from the options that appear and then click Save.


 
Only workspaces without devices appear in the lookup.
7

If the device requires T.38 fax compression, check the box in the T.38 column or override user-level compression options, and then click Save.


 
A workspace can have an ATA. This is useful for fax machines.

You can add phone numbers to desk and room devices in your customer organization at any time, whether you're in the middle of a trial or have been converted to a paid subscription.


We've increased the number of telephone numbers you can add in Control Hub from 250 to 1000.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Numbers then click Add Numbers.

2

Specify the Location and Number Type. If you're porting numbers over, enter both your current and new billing numbers.

3

Then, click Save.

You can see a list of PSTN numbers that your organization has ordered. With this information you can see unused numbers that are available, and the numbers that have been ordered that will soon become available.

From the customer view in https://admin.webex.com, go to Services > Calling > PSTN Orders.

You're brought to the Calling Admin Portal, where you'll see the orders that have been submitted and completed. If you have an order ID handy, you can enter it as a parameter and get details about a specific order, otherwise you'll get a summary of all orders.
Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Adoption Trends and Usage Reports for Cisco Webex Calling

You have a number of reports at your fingertips that can help you assess how Webex Calling services are being used, how often they're being used. You can also get a quick visual of the media quality for your location.

View Calling Reports

You have access to various reports in Cisco Webex Control Hub that include details about activation and usage for Webex Teams and Meetings.

When you access Calling data from Cisco Webex Control Hub, you're brought to the Calling Admin Portal. You can use this information to evaluate how Webex Calling services are being used in your organization and how often people are using those services.

From the customer view in https://admin.webex.com, go to Analytics and then select Webex Calling.

You're automatically brought to the Calling Admin Portal, where you can analyze and evaluate call usage and quality. For information about the reports available for specific calling features, see Calling Admin Portal - Reports. For information about call activity, see Calling Admin Portal - Analytics.

Assess the Media Quality of Your Locations

Get a location-by-location view of the media quality for your Calling location. Media quality is based on an aggregation of the mean opinion scores (MOS) for calls in a specific location to and from the customer, from Cisco MPP phones, and the Calling soft client. Possible values are as follows:

  • Good—> 3.2

  • Fair—2.7 to 3.2

  • Poor—<2.7

  • No Data Available—No calls have been made or received for the location in the time period selected.

1

From the customer view in https://admin.webex.com, go to Analytics, and then select Webex Calling.

You're brought to the Calling Admin Portal.

2

Go to the Dashboard and scroll to Service Assurance to see the overall health of your organization.

If you want to open the CScan tool to verify latency, bandwidth, and ports, click Network Readiness Test.

What to do next

If the location shows a rating of Poor, this indicates that there may be an issue with media quality on one of your locations. Common causes are not enough bandwidth or traffic congestion. If the issues persist, go to the customer view in https://admin.webex.com, click your admin username, and then click Feedback to open a case.

Run the CSCAN Tool

You can use the Cisco SCAN tool to check latency, bandwidth, and ports.

Go to https://cscan.webex.com/, pick your server, and then click RUN TEST.

Water Mark
Aug 27, 2020| view(s) | people thought this was helpful

Port Reference Information for Cisco Webex Calling

Here is a list of the addresses, ports, and protocols used for connecting your phones and gateways to Cisco Webex Calling from any of the following regions: Production (includes North America, EMEA, Australia, and Japan) and Beta. You must make these ports available for specific traffic to flow through your network. You'll notice that local gateway configuration is now also available to Service Providers.

A correctly configured firewall is essential for a successful calling deployment. We require ports for signaling, media, network connectivity, and local gateway and because Webex Calling is a global service, we recommend that you leave all of the ports listed below open.

Not all firewall configurations need ports to be open but if you're running inside-to-outside rules, you should open ports to allow the protocols required for service out. As long as you deploy NAT, define reasonable binding periods, and avoid manipulating SIP on the NAT device, you shouldn't need to open ports inbound on the firewall.


If a router or firewall is SIP Aware, meaning it has SIP Application Layer Gateway (ALG) or something similar enabled, we recommend that you turn off this functionality to maintain correct operation of service. See the relevant manufacturer's documentation for information about how to disable SIP ALG on specific devices.

Date

We've Made the Following Changes to this Article

December 23, 2020

Added new Application Configuration IP addresses to the port reference images.

December 22, 2020

Updated the Application Configuration row in the tables to include the following IP addresses: 135.84.171.154 and 135.84.172.154.

Hid the network diagrams until these IP addresses can be added there as well.

December 11, 2020

Updated the Device configuration and firmware management (Cisco devices) and the Application configuration rows for the supported Canadian domains.

October 16, 2020

Updated the call signaling and media entries with the following IP addresses:

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

September 23, 2020

Under CScan, replaced 199.59.64.156 with 199.59.64.197.

August 14, 2020

Added more IP addresses to support the introduction of data centers in Canada:

Call signaling to Webex Calling (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

August 12, 2020

Added more IP addresses to support the introduction of data centers in Canada:

  • Call media to Webex Calling (SRTP)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

  • Call signaling to publicly addressed endpoints (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

  • Device configuration and firmware management (Cisco devices)—135.84.173.155,135.84.174.155

  • Device time synchronization—135.84.173.152, 135.84.174.152

  • Application configuration—135.84.173.154,135.84.174.154

July 22, 2020

Added the following IP address to support the introduction of data centers in Canada: 135.84.173.146

June 9, 2020

We made the following changes to the CScan entry:
  • Corrected one of the IP addresses—changed 199.59.67.156 to 199.59.64.156

  • New features required new ports as well as UDP—19560-19760

March 11, 2020

We added the following domain and IP addresses to application configuration:

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

We updated the following domains with additional IP addresses to device configuration and firmware management:

  • cisco.broadcloud.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

February 27, 2020

We added the following domain and ports to device configuration and firmware management:

cloudupgrader.webex.com—443, 6970

Table 1. Webex Calling (Production)

Connection purpose

Source addresses

Source ports

Protocol

Destination addresses

Destination ports

Call signaling to Webex Calling (SIP TLS)

Local Gateway external (NIC) 8000-65535

TCP

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

8934

Devices

5060-5080

Applications

Ephemeral (OS dependent)

Call media to Webex Calling (SRTP)

Local Gateway external NIC

8000-48000

UDP

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

19560-65535

Devices

19560-19660

Applications

Ephemeral

Call signaling to PSTN gateway (SIP TLS) Local Gateway internal NIC 8000-65535 TCP Your ITSP PSTN GW or Unified CM Depends on PSTN option (for example, typically 5060 or 5061 for Unified CM)
Call media to PSTN gateway (SRTP) Local Gateway internal NIC

8000-48000

UDP Your ITSP PSTN GW or Unified CM Depends on PSTN option (for example, typically 5060 or 5061 for Unified CM)

Call signaling to publicly addressed endpoints (SIP TLS)

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

Ephemeral

TCP

Endpoint IP

8934

Device configuration and firmware management (Cisco devices)

Webex Calling devices

Ephemeral

TCP

3.20.185.219

3.130.87.169

35.172.26.181

52.86.172.220

72.163.10.134

85.119.56.128/26

85.119.56.198

85.119.57.128/26

85.119.57.198

135.84.169.186

135.84.170.186

135.84.173.155

135.84.174.155

173.37.149.125

199.59.64.143

199.59.65.228

199.59.66.228

199.59.67.143

*Domains:

  • ntp-ca.bcld.webex.com

  • cisco-ca.bcld.webex.com

  • dms-ca.bcld.webex.com

  • cisco-ca.bcld.webex.com

  • acodes-ca.bcld.webex.com

  • cisco-jp.bcld.webex.com

  • cisco.broadcloud.com.au

  • cisco.broadcloud.eu

  • webapps.cisco.com

  • activate.cisco.com

  • activation.webex.com

  • cisco.sipflash.com

80, 443

**cloudupgrader.webex.com

**443, 6970

Device time synchronization (NTP)

Webex Calling devices

51494

UDP

85.119.56.128/26

85.119.57.128/26

135.84.169.154

135.84.170.154

135.84.173.152

135.84.174.152

199.59.64.152

199.59.65.181

199.59.66.181

199.59.67.152

123

Device name resolution

Webex Calling devices

Ephemeral

UDP and TCP

Host-defined

53

Application configuration

Webex Calling applications

Ephemeral

TCP

64.68.99.6

64.68.100.6

85.119.56.128/26

85.119.57.128/26

128.177.36.138

128.177.14.181

135.84.169.150

135.84.171.154

135.84.172.154

135.84.174.154

135.84.173.154

135.84.169.185

135.84.170.185

199.59.64.140

199.59.67.140

Domains:

  • client-ca.bcld.webex.com

  • apps-ca.bcld.webex.com

  • imp-ca.bcld.webex.com

  • wrscl01-ca.bcld.webex.com

  • wrscl01-ca.bcld.webex.com

  • client-jp.bcld.webex.com

  • jp.bcld.webex.com

  • idbroker.webex.com

80, 443, 1081, 2208, 8443, 5222, 5280-5281, 52644-52645

Application time synchronization

Webex Calling applications

123

UDP

Host-defined

123

Application name resolution

Webex Calling applications

Ephemeral

UDP and TCP

Host-defined

53

CScan

Webex Calling applications

Ephemeral

UDP and TCP

135.84.169.183

135.84.173.146

185.115.196.0/25

199.59.65.243

199.59.64.197

8934 and 80, 443, 19569-19760

† CUBE media port range is configurable with rtp-port range

*When a phone connects to a network for the first time or after a factory reset, if there are no DHCP options set up, it contacts a device activation server for zero touch provisioning. New phones use activate.cisco.com instead of webapps.cisco.com for provisioning. Phones with firmware release prior to 11.2(1), continue to use webapps.cisco.com. We recommend that you allow both domains through your firewall.

**You need to enable cloudupgrader.webex.com and the 443, 6970 ports only when migrating from Enterprise phones (Cisco Unified CM) to Webex Calling. Go to upgrade.cisco.com for more information.

Table 2. Webex Calling (Production)

Connection purpose

Source addresses

Source ports

Protocol

Destination addresses

Destination ports

Call signaling to Webex Calling (SIP TLS)

Local Gateway external NIC

8000-65535

TCP

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

128.177.14.0/25

128.177.36.0/26

8934

Devices

5060-5080

Applications

Ephemeral (OS dependent)

Call media to Webex Calling (SRTP)

Local Gateway external NIC

8000-48000

UDP

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

128.177.14.0/25

128.177.36.0/26

19560-65535

Devices

19560-19660

Applications

Ephemeral

Call signaling to PSTN gateway (SIP TLS)

Local Gateway internal NIC

8000-65535

TCP

Your ITSP, PSTN GW, or Unified CM

Depends on PSTN option, eg. Unified CM typically 5060 or 5061

Call media to PSTN gateway (SRTP)

Local Gateway internal NIC

8000-48000

UDP

Your ITSP, PSTN GW, or Unified CM

Depends on PSTN option

Call signaling to publicly addressed endpoints (SIP TLS)

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

135.84.173.0/25

135.84.174.0/25

139.177.64.0/24

139.177.65.0/24

139.177.66.0/24

139.177.67.0/24

139.177.68.0/24

139.177.69.0/24

139.177.70.0/24

139.177.71.0/24

139.177.72.0/24

139.177.73.0/24

185.115.196.0/25

185.115.197.0/25

199.19.197.0/24

199.19.199.0/24

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

Ephemeral

TCP

Endpoint IP

8934

Device configuration and firmware management (Cisco devices)

Webex Calling devices

Ephemeral

TCP

3.130.87.169,

3.20.185.219

35.172.26.181,

52.86.172.220

72.163.10.134

85.119.56.198

85.119.57.198

135.84.169.186

135.84.170.186

135.84.173.155

135.84.174.155

173.37.149.125

199.59.64.143

199.59.65.228

199.59.66.228

199.59.67.143

*Domains:

  • ntp-ca.bcld.webex.com

  • cisco-ca.bcld.webex.com

  • dms-ca.bcld.webex.com

  • cisco-ca.bcld.webex.com

  • acodes-ca.bcld.webex.com

  • cisco-jp.bcld.webex.com

  • cisco.broadcloud.eu

  • cisco. broadcloud.com.au

  • cisco.sipflash.com

  • webapps.cisco.com

  • activate.cisco.com
  • activation.webex.com

80, 443

**cloudupgrader.webex.com

**443, 6970

Device time synchronization (NTP)

Webex Calling devices

51494

UDP

85.119.56.218

85.119.57.218

135.84.169.154

135.84.170.154

135.84.173.152

135.84.174.152

199.59.64.152

199.59.65.181

199.59.66.181

199.59.67.152

123

Device name resolution

Webex Calling devices

Ephemeral

UDP and TCP

Host-defined

53

Application configuration

Webex Calling applications

Ephemeral

TCP

64.68.99.6

64.68.100.6

85.119.56.197

85.119.57.197

128.177.36.138

128.177.14.181

135.84.169.150

135.84.171.154

135.84.172.154

135.84.173.154

135.84.174.154

135.84.169.185

135.84.170.185

199.59.64.140

199.59.67.140

Domains:

  • client-ca.bcld.webex.com

  • apps-ca.bcld.webex.com

  • imp-ca.bcld.webex.com

  • wrscl01-ca.bcld.webex.com

  • wrscl01-ca.bcld.webex.com

  • client-jp.bcld.webex.com

  • jp.bcld.webex.com

  • idbroker.webex.com

80, 443

Application time synchronization

Webex Calling applications

123

UDP

Host-defined

123

Application name resolution

Webex Calling applications

Ephemeral

UDP and TCP

Host-defined

53

CScan

Webex Calling applications

Ephemeral

UDP and TCP

135.84.169.183

135.84.173.146

185.115.196.129

199.59.65.243

199.59.64.197

8934 and 80, 443, 19560-19760

† CUBE media port range is configurable with rtp-port range

*When a phone connects to a network for the first time or after a factory reset, if there are no DHCP options set up, it contacts a device activation server for zero touch provisioning. New phones activate.cisco.com instead of webapps.cisco.com for provisioning. Phones with firmware release prior to 11.2(1), continue to use webapps.cisco.com. We recommend that you allow both domains through your firewall.

**You need to enable cloudupgrader.webex.com and the 443, 6970 ports only when migrating from Enterprise phones (Cisco Unified CM) to Webex Calling. Go to upgrade.cisco.com for more information.

Was this article helpful?

Related Articles

Recently Viewed

×