Webex Calling Lab v4

First Published: 2020-08-07

Last Modified: 2022-06-14

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
© 2022 Cisco Systems, Inc. All rights reserved.
 CONTENTS

CHAPTER 1 About 1
Limitations 1
Requirements 1
About This Solution 2
Topology 2
Session Users for Webex 2

CHAPTER 2 Getting Started 5

Get Started 5

CHAPTER 3 Scenarios 7

Cisco Webex Control Hub Organization Verification 7

Control Hub Timeout 8
Webex Calling - Initial Setup 9
Adding a Telephone Number and Assigning to a Location 9
Enabling Users for Webex Calling and License Assignment 11
Device Overrides - Device Configuration from Control Hub 11
Configuring a Multiplatform Phone using Global Discovery Service 12
Configuring a Multiplatform Phone Using Bulk Activation Code 13
Configure Webex Calling for Room Devices 15
Call Recording Using Dubber Go 16
Configuring Call Recording 18
Using Webex App for Calling 18
Configuring Calling Features 18
Customer-Level Settings 18
Webex Calling Feature Access Codes 19

Webex Calling Lab v4

iii
Contents

Adding New Calling Features 19

Configuring Call Queues 19
Configuring Call Park Extensions and Call Park Group 20
Configuring a Shared Voicemail Box 21
Configuring Hunt Group 21
Configuring Auto Attendant 22
Configure Call Pickup 23
Configuring Virtual Extension 24
Configuring Receptionist Clients 25
Signing in to Calling User Portal 25
Testing Calling Features 26
Testing Auto Attendant, Hunt Group, and Call Queue 26
Test Call Pickup 27
Testing Call Park 27
Configuring Webex Calling Internal Dial Plans 28
Testing Calls between dCloud and London Location 30
Configuring CUBE High Availability (HA) 30
CUBE HA Design Considerations and Restrictions 32
CUBE HA as LGW Configuration Steps 33
Active / Standby Show Command Verification 39
Deploying Local Gateway for PSTN Calling 42
Local Gateway Hardware and Software Requirements 42
Local Gateway Onboarding Process 43
Creating Local Gateway 43
Local Gateway Configuration 45
Local Gateway Certificate Configuration and Verification 47
Configuring SIP Profile 51
Active / Standby and Registration Show Command Verification 60
Call Routing Configuration 65
Local Gateway Testing 67
Call from PSTN to MPP/Webex Teams App 67
Call from MPP/Webex App to PSTN 67
Local Gateway Voice Translation to Remove Steering Digit ‘9’ for External Calls 68
Local Gateway Debugging 69

Webex Calling Lab v4

iv
 Contents

CHAPTER 4 Appendix 71

Full Local Gateway Configuration 71

CHAPTER 5 What's Next? 77

What’s Next? 77

Webex Calling Lab v4

v
Contents

Webex Calling Lab v4

vi
 CHAPTER 1
About
• Limitations, on page 1
• Requirements, on page 1
• About This Solution, on page 2
• Topology, on page 2
• Session Users for Webex, on page 2

Limitations
To meet the specified requirements of this lab, these scenarios are intended to demonstrate one way to configure
Cisco® Webex Control Hub solutions. There are various ways this can be accomplished, depending on the
situation and the customer's goals/requirements. Please ensure that you consult all current official Cisco
documentation before proceeding with a design or installation. This lab is primarily intended to be a learning
tool and may not necessarily follow best practice recommendation at all times, in order to convey specific
information.

Requirements
The table below outlines the requirements for this preconfigured demonstration.

Required Optional

Cisco AnyConnect Client None

Laptop
Cisco Multiplatform Phone (MPP) (for
Cisco Webex Calling)
Cisco Endpoint (for Cisco Webex Calling)
Alternatively, you can use desktop or
mobile calling clients, such as Webex

Webex Calling Lab v4

1
 About
About This Solution

About This Solution

This hands-on lab will help participants understand the overall architecture and various building blocks of
the Webex Calling solution, including Call Recording using Dubber. Participants will start by enabling an
organization and its associated users for Webex Calling in the Control Hub portal, onboard endpoints (using
Global Discovery Service [GDS] and bulk activation codes) and Room Systems, and configure / test various
calling features offered by the Cisco Webex Calling platform. Subsequently, internal and external dialing
options will be configured along with the premises-based PSTN option available for Webex Calling, CUBE
HA as Local Gateway.

Topology
This demonstration includes several server virtual machines. Most of the servers are fully configurable using
the administrative-level account. Administrative account details are included in the lab guide steps, where
relevant, and in the server details table.

Session Users for Webex

The following table contains details on preconfigured users available for your session.

Internal Deployment
User Name User ID Password Endpoint Devices
Extension Model

Anita Perez aperez dCloud123! Receptionist Client 6017 Cloud

Webex Calling Lab v4

2
About
Session Users for Webex

Internal Deployment
User Name User ID Password Endpoint Devices
Extension Model

Charles Holland cholland dCloud123! Webex Devices or 6018 Cloud

Webex
Taylor Bard tbard dCloud123! Webex Devices or 6021 Cloud
Webex
Rebekah Barretta rbarretta dCloud123! Webex Devices or 6022 Cloud
Webex
Kellie Melby kmelby dCloud123! Webex Devices or 6023 Cloud
Webex
Stefan Mauk smauk dCloud123! Webex Devices or 6024 Cloud
Webex
Eric Steele esteele dCloud123! Webex Devices or 5001 Cloud
Webex

Webex Calling Lab v4

3
 About
Session Users for Webex

Webex Calling Lab v4

4
 CHAPTER 2
Getting Started
• Get Started, on page 5

Get Started
Follow the steps to schedule a session of the content and configure your presentation environment.

Procedure

Step 1 Initiate your dCloud session. [Show Me How] (Skip if you are in a proctored environment.)
Note It can take up to 45 minutes for your session to become active.

Step 2 Click View to open the active session. (Skip if you are in a proctored environment.)
Step 3 If you are connecting directly to the session from a stand-alone laptop or other device, install and access Cisco
AnyConnect on your laptop, using the AnyConnect credentials in the Cisco dCloud UI. [Show Me How]
• Recommended method: Use Cisco AnyConnect [Show Me How] and local laptop RDP client. [Show
Me How]
• Windows Users: It is recommended to use some version of Remote Desktop Manager to save the
connections to each virtual machine. An example of a manager is the Microsoft Remote Desktop
Connection Manager, which can be found at
https://www.microsoft.com/en-us/download/details.aspx?id=44989.

• Mac Users: It is recommended to use the Microsoft Remote Desktop (MRD) [ ] or CoRD [ ]
applications to connect to the virtual machines. MRD can be downloaded for free from the Mac App
Store. CoRD can be downloaded free at http://cord.sourceforge.net/. Both application gives you the
capability to save the connections for each virtual machine.
Caution DO NOT use the Microsoft remote desktop client that comes with your Mac. It will have
security issues connecting to the AD1 and Mail1 virtual machines.

Step 4 The lab uses desk phones loaded with Multiplatform Phone (MPP) firmware. If no MPP phone is available,
Cisco Webex can be used.

Webex Calling Lab v4

5
 Getting Started
Get Started

Step 5 After confirming the devices have the correct firmware and are not in a factory reset state, perform a factory
reset on each device before starting the lab. (Skip if you are in a proctored environment.)
Note For best results, use the Chrome web browser.

Step 6 In order to run this lab, you need some information from the Session Details tab on your dCloud dashboard
session page. Obtain the Collaboration Edge domain information. Each session has a unique domain. The
image below is only an example.
Important Do not use the information in the image below for your session. It is highly recommended to take
note of your information now so that you can refer to it throughout the lab.
Session Details Tab Example

Webex Calling Lab v4

6
 CHAPTER 3
Scenarios
• Cisco Webex Control Hub Organization Verification, on page 7
• Webex Calling - Initial Setup, on page 9
• Enabling Users for Webex Calling and License Assignment, on page 11
• Device Overrides - Device Configuration from Control Hub, on page 11
• Configuring a Multiplatform Phone using Global Discovery Service, on page 12
• Configuring a Multiplatform Phone Using Bulk Activation Code, on page 13
• Configure Webex Calling for Room Devices, on page 15
• Call Recording Using Dubber Go, on page 16
• Using Webex App for Calling, on page 18
• Configuring CUBE High Availability (HA), on page 30
• Deploying Local Gateway for PSTN Calling, on page 42

Cisco Webex Control Hub Organization Verification

Value Proposition: Cisco Webex Control Hub is a web-based, intuitive, single-pane-of-glass management
portal that enables you to provision, administer, and manage Cisco Webex services and Webex Hybrid Services,
such as Hybrid Call Service, Hybrid Calendar Service, Hybrid Directory Service, and Video Mesh.
In this scenario, you will verify the initial administrator account. The trial has already been started for you
and the users have already been created.
Charles Holland, the org administrator, has his password already set to dCloudZZZZ! The steps to create a
customer trial can be found at https://collaborationhelp.cisco.com/article/en-us/npv2y12.

Note The ZZZZ portion of the password is the last four digits of our Session ID found in your sessions's Details
tab.

You will now verify the initial automation scripts ran properly to create your trial and set Charles' password.

Procedure

Step 1 If not already connected, use Cisco AnyConnect to VPN into your lab session. The login credentials will be
provided by your proctor or displayed on the Session Details tab for your active session.

Webex Calling Lab v4

7
 Scenarios
Control Hub Timeout

Step 2 Create an RDP connection to Workstation 1 (198.18.1.36) and log in as dcloud\cholland with password
dCloud123! Alternatively, you can connect from your Session page by clicking WKST1.

Step 3 Open Microsoft Outlook using the icon in the taskbar [ ].

Step 4 For profile name, enter Charles and click OK.
Step 5 In the Inbox, you should see a couple of emails. The one in particular we are looking for at this stage has the
subject line Welcome to Cisco Webex Trial and possibly one that has the subject of Your password was
updated. If you receive an email with the subject WEBEX LAB WARNING, read the email to see if there
were any issues with the spin up of the lab. If so, you might need to contact Support or spin up a new session.
Step 6 Open Chrome web browser to https://admin.webex.com and enter cholland@cbXXX.dc-YY.com. Click
Sign In.
Important Remember to replace XXX and YY with your session information.

Step 7 Enter dCloudZZZZ! as the password and click Sign In again.

Step 8 Click Accept if prompted for Terms of Service.
You have now logged into the Cisco Webex Control Hub. This is where you will spend the bulk of your time
configuring your organization. This portal is where you will configure your Webex services. The Overview
page in Webex Control Hub highlights all the important information that helps you manage Webex services
for your organization.
You can use this information to take action when you find a problem. This gives you a quick access to the
following:
• All Webex services and their status
• Number of devices created and the ability to quickly add a device
• Users added and the state of their account as well as the ability to convert any users not in the organization
already
• Hybrid services configured and their status
• Important links that administrators may want to be aware of
• Quick links

As you can see, the Overview page is designed to give the Admin quick access to the most-used areas of the
control hub.
In the lab, you will cover a lot of topics within Control Hub; however, not everything available will be covered.
We do the best to cover the latest and most used services. For more guides in covering Control Hub, go here.
From that link you can go through topics not covered in this guide. Since the lab is yours and you have full
administrative control, you should be able to try out most of the different configuration topics listed on those
pages, even though they are not listed in this guide.

Control Hub Timeout

To make things easier in the lab, you can now set a Timeout for the Control Hub login. The default login
timeout for Control Hub is 20 minutes, which will be increased to 12 hours for this lab.

Webex Calling Lab v4

8
 Scenarios
Webex Calling - Initial Setup

Procedure

Step 1 Navigate to Organization Settings and scroll down to Idle Timeouts.

Step 2 Under the Webex Control Idle Timeout section, change the Control Hub timeout drop-down menu to 12
Hours. Changing the setting outside of a lab environment is not recommended.

Webex Calling - Initial Setup

Imagine being able to leverage enterprise-grade cloud calling, mobility, and PBX features, along with Webex
for messaging, meetings, and calling. That's exactly what Webex Calling has to offer, along with a smooth
transition to the cloud for customers with users on existing on-premises PBX infrastructures.
For more information on Webex Calling configuration, see the help article at
https://help.webex.com/en-us/32gfts/Webex-Calling-Configuration-Workflow.

Adding a Telephone Number and Assigning to a Location

Procedure

Step 1 On Workstation 1, open the Webex Control Hub (https://admin.webex.com). Under Services in the left-hand
menu, select Calling.
Note If not logged in already into Control Hub, use cholland@cbXXX.dc-YY.com and password
dCloudZZZZ! The ZZZZ portion of the password is the last four digits of our Session ID found
in your sessions's Details tab.
Right now, no telephone numbers (TNs) have been configured for the lab. One main Telephone Number is
required for calling to work for each location. Since this is a lab and you don't have any real working public
TNs, you will be configuring one fake TN to get things going. A real customer would purchase real TNs from
a provider and add them to the organization.

Step 2 Click the Locations tab. Click the pre-defined location dCloud. In the fly-out window, select Manage.

Webex Calling Lab v4

9
 Scenarios
Adding a Telephone Number and Assigning to a Location

Step 3 On the Connection Type page, select Premises-based PSTN and click Next.
Step 4 Select None from the drop-down and check the box to confirm you are changing the call routing to PSTN.
Click Next.
Note If you don't see the Save option, select None again from the drop-down.

Step 5 Click Add Numbers.

Step 6 Choose the dCloud location and click Next.
In this lab, all the Webex orgs are created in the United States (US), so in the next steps you will need to add
one fake 10-digit US number.

Step 7 Toggle on Activate Numbers Later.

Step 8 In the Enter phone numbers separated by commas box, add one unique number starting with 417555 and
a random string of four numbers at the end (for example, 417555XXXX). Press Enter/Return on your keyboard
after entering the number. Click Save followed by Close.
Note Replace XXXX with any random numbers.

Step 9 At the top of the page, click Locations and select the dCloud location.
Step 10 While on the same fly-out window, select Main Number and choose the fake number you created in the
previous steps. Click Save.
Step 11 Click the Overview link at the top.
Step 12 Under Call Settings, click Voice Portal.
Step 13 Under Incoming Call, enter 6032 for the Extension.
Step 14 For the Voice Portal Admin Passcode, enter 071199 for the New and Confirm passcode boxes.
Step 15 At the top, click Save.

Webex Calling Lab v4

10
 Scenarios
Enabling Users for Webex Calling and License Assignment

Enabling Users for Webex Calling and License Assignment

We will enable Taylor, Rebekah, and Kellie for Webex Calling.

Procedure

Step 1 Under Management, select Users from the left-hand menu.

Step 2 Click Rebekah from the user list.
Step 3 On the Profile tab, scroll down to the Licenses section and click Edit Licenses.
Step 4 Select Calling on the left tab.
Step 5 Check the box for Webex Calling, add a check to Professional, and click Next.
Step 6 Choose dCloud for the Location, leave Phone Number as None, and enter 6022 for the Extension.
Note In the lab, you will be using Extension only for the users and features. The Phone Number option
is to assign a real PSTN number to the user's phone. There are no real PSTN services set up for
the lab.

Step 7 Click Save and then click Close.

Step 8 At the top, select the Calling tab and click Caller ID.
By default, external callers will get the caller ID number from the location they are assigned. For the name,
they are defaulted to their full name. You can change this in the boxes below, which are pre filled out at the
bottom. You can also take the location caller ID or select the other option to assign any name. Feel free to
change these Caller ID settings for any of the users you configure to see how they work.

Step 9 Edit Taylor's and Kellie's user account as above and add the Webex Calling Professional service. Set the
Extension as 6021 for Taylor and 6023 for Kellie.
Step 10 For testing purposes later on this lab, configure users, Stefan Mauk and Anita Perez, with Webex Calling
Professional. Use the Extension of 6024 for Stefan and 6017 for Anita. You will use Stefan Mauk to initiate
calls into the system to test calling features and Anita for Receptionist client testing.

Device Overrides - Device Configuration from Control Hub

The Device Override feature provides a way to manage device configurations from Cisco Webex Control
Hub. It allows greater device provisioning flexibility by allowing users to customize their devices to fit their
business needs on an organization or location level. The capabilities of this feature include:
• phone background image
• long interdigit timer
• short interdigit timer
• display name
• line key labels

Webex Calling Lab v4

11
 Scenarios
Configuring a Multiplatform Phone using Global Discovery Service

• line key LED patterns

Procedure

Step 1 If not already logged in, go back to Control Hub and log in with your account information.
Note In the steps below, we apply phone settings at the Organization level. You can apply the same
settings at the Location level too by selecting Services > Calling > Locations > Device
Configurations.

Step 2 On the Control Hub, under Services, select Calling > Service Settings. Scroll down under Device and click
Configure Default Device Settings.
Step 3 Click the MPP tab.
Step 4 For Background Image, choose the background image in the option available in the drop-down list. In our
lab, select Dark Blue.
Note At the time of writing this lab guide, the background images available are Dark Blue, Cisco Dark
Blue, Webex Dark Blue, and Custom. Also please remember that these images will only work
on phones that have 800*480 screen size.

Step 5 For the Display Name, let's change the phone display from User phone number/ Location number to User
Name (First Name Last Name).
Step 6 In the Line Key Label drop-down list, which defines the format of what's shown next to line keys, choose
from the following options: User Name (First Name Last Name).
Step 7 The Line Key LED Pattern defines lighting schemes for the line keys on MPP phones. Leave that setting to
Default.
Step 8 Leave the default values for Interdigit Short Timer and Interdigit Long Timer. Click Review Changes
and then click Start Processing. Any new MPP phone that you add in this lab going forward in coming
scenarios have the settings applied.

Configuring a Multiplatform Phone using Global Discovery

Service
This feature uses a 16-digit activation code that is generated by Cisco Global Discovery Service (GDS) and
the Webex Calling Platform to onboard and provision the device with the associated Webex Platform. When
the code is provided to a user/administrator, the code is entered into the MPP Phone. The MPP phone
communicates with GDS and redirects the phone to the hosting platform. The MPP phone communicates with
the Webex Platform and uses the activation code to authenticate with the platform. If authentication is
successful, the MPP MAC address is stored onto the platform and the phone is provided with the provisioning
server location. The phone reboots and downloads the user configuration from Device Management.
This feature is supported on the following Cisco MPP devices:
• 6821, 6841, 6851
• 7811, 7821, 7832, 7841, 7861

Webex Calling Lab v4

12
 Scenarios
Configuring a Multiplatform Phone Using Bulk Activation Code

• 8811, 8832, 8841, 8845, 8851, 8861

For more information on the supported devices, click here. If you have a physical MPP phone, use the following
instructions to register it along with other phones you would like to use. If you do not have a physical MPP
phone then the Webex app will suffice for this lab. You can skip to the next section.

Procedure

Step 1 On the Control Hub, under Management, click Devices.

Step 2 Click Add Device.
Step 3 Choose Existing User and click Next.
Step 4 Search for Taylor Bard, select him from the list, and click Next.
Step 5 Select Cisco IP Phone.
Step 6 Select the device type from the drop-down menu.
Step 7 Select the radio button for By Activation Code and click Next.
Note If your phone has not been factory reset, do that now. If the phone has already been factory reset
and powered on, reboot the phone to have it attempt the registering process again.

Step 8 Once the phone boots after a factory reset, enter the activation code into the phone and press Continue.
Step 9 After a few minutes, the phone should reboot and register. It may take a few minutes before the device is
listed on the devices page in Control Hub after registering. On Control Hub, click Close.

Configuring a Multiplatform Phone Using Bulk Activation Code

This feature delivers the ability for a Partner or Enterprise Admin to add devices for users and places using
Activation Codes.
Benefits include:
• Large enterprise user additions reduced from hours to minutes
• Leverages GDS activation code functionality

Note If you have a physical MPP phone, use the following instructions to register it along with other phones you
would like to use. If you do not have a physical MPP phone, then the Webex app will suffice for this lab. You
can skip to the next section.

Procedure

Step 1 On the Control Hub, under Management, click Devices.

Step 2 Click Add Device.

Webex Calling Lab v4

13
 Scenarios
Configuring a Multiplatform Phone Using Bulk Activation Code

Step 3 In the Multiple Cisco IP Phones section, click Import/Upload CSV file. The Admin can select to Export
user attributes CSV file or Download CSV template file. For this lab, you will be using a template file. More
information can be found at the following link: https://help.webex.com/en-us/n9r1aac/
Configure-and-Manage-Webex-Calling-Devices#id_118912
Step 4 Click the download CSV template link to download the file on your personal machine or Workstation 1.
Here are 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.
• It is recommended 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. 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 (Focus of
this lab).
• 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.

Step 5 We will enable Kellie Melby. The downloaded template will have sample data, it needs to be deleted and
then enter the info for Kellie. Save the CSV file on the desktop.

Note Each session has a unique domain. Replace the XXX and YY from your Details tab on your dCloud
dashboard session page. Remember not to enter the Directory Number in the CSV file as it's
already defined in the User section. Leaving the MAC Address column blank, activation code is
generated and must be entered on device itself.

Step 6 We will upload the file that was created for Kellie. Either drag and drop your CSV file or click browse to
select the file. Make sure Provide a link is selected and click Submit.

Webex Calling Lab v4

14
 Scenarios
Configure Webex Calling for Room Devices

Step 7 If there are no errors in your upload file, you can now download the activation code files. Click the Download
activation codes CSV link and then click Close. After entering the code on the MPP phone, the device will
boot and register as Kellie Melby.

Configure Webex Calling for Room Devices

You can also assign Webex Calling telephone numbers to room devices. As with the users, you will be
assigning extensions since there is no cloud-connected PSTN service provider configured for your lab.

Note If you have a physical room device, use the following instructions to register it. If you do not have a Room
Device, the Webex app will suffice for this lab. You can skip to the next section.

Webex Calling Lab v4

15
 Scenarios
Call Recording Using Dubber Go

Procedure

Step 1 Navigate to Devices.

Step 2 Click Add Device.
Step 3 Choose Workspace and then click Next.
Step 4 Choose New Workspace. In the box that appears, enter a workspace name.
Step 5 Click Next.
Step 6 Choose Cisco Webex Rooms device and then click Next.
Step 7 Select Cisco Webex Calling and click Next. Assign 6025 as an extension and click Next again.
Step 8 On the next screen, you will receive a single use Activation code. Enter the code on your endpoint and it will
register. Your endpoint might upgrade after registering. You will be able to dial the extensions of other users
from your room device.
OPTIONAL STEPS - ASSIGN EXTENSIONS
If you already have a room device registered on Webex Control Hub, follow the below steps to assign extension
to room devices.

Step 9 On the Control Hub, click Workspaces.

Step 10 Select your workspace.

Step 11 Click the cog wheel [ ] on the Calling card.

Step 12 Choose the Cisco Webex Calling radio button and click Next.
Step 13 Enter 6025 for the extension and click Save.

Call Recording Using Dubber Go

In this scenario, we go through the steps to configure Dubber Go. The Call Recording feature provides a
hosted mechanism for Webex Calling (WxC) customers to record their calls placed/received on the Webex
Calling platform for replay and archival. It is deployed as a hybrid feature, where the WxC platform enables
the Call Recording user feature settings (detailed below), while storage and management of recorded calls
are delivered via a portal of our third-party partner Dubber.
How does Dubber work in Webex? If a user is enabled for Call Recording in Control Hub, then when a call
is made to or from that user, the call is forked to Dubber via an extended Sip INVITE message.
What is the purpose? It provides WxC Partners with an option to meet customer requirements for business
process, regulatory, or other standards compliance needed for recording calls.
More information about Dubber can be found at www.dubber.net.
Functional Overview:
• Customer Admins and/or Administrators entitle end users with Call Recording
• Recording of calls are securely sent to the Dubber platform for playback and general management

Webex Calling Lab v4

16
Scenarios
Call Recording Using Dubber Go

Features Benefits

Designation of when calls are Always On - all calls are recorded all the time.
recorded
Always On with pause and resume - all calls are recorded, user has option
to pause recording to protect PII (bank account /credit card number, Social
security number, password, etc.)

Call Recording announcement, if When both parties are connected, the message is "This call is being
selected, a system message is recorded."
played to both parties in the
If recording is paused, upon resume the message is "Your Call Recording
language of the customer site
service has been activated successfully. Thank you."

Option to record incoming voice

messages

Option to play message during

pause and resume

Option to set a tone played

periodically (configurable from
10 to 90-second increments
between tones)

Note All recordings in Dubber will be removed once your session ends. Also, please make sure not to record any
confidential information as it is a demo account.

Webex Calling Lab v4

17
 Scenarios
Configuring Call Recording

Configuring Call Recording

Procedure

Step 1 We will now configure users for call recording. If not already logged in, go back to Control Hub and log in.
Step 2 On the Control Hub, select Users > Taylor Bard. On the next page, click the Calling tab.
Step 3 Under Call Settings, click Advanced Call Settings and then click Call Recording.
Step 4 Turn the toggle On
Step 5 Under Calls should be recorded, select the option for Always with Pause/Resume and Play recording
start/stop announcement.
Step 6 For Recording Reminder Tone, select Repeat Tone Every 20 seconds. Click Save.
Step 7 Repeat Steps 2-6 for Rebekah and Kellie to add the Call Recording service to their user accounts.
Step 8 Each user will now be enabled with call recording when they start a call. They will be able to pause and resume
the recording at their discretion.

Using Webex App for Calling

For your other users, use the Webex app to make and receive calls. (If you do not have a physical phone for
Taylor, Kellie, or Rebekah, use the Webex app for them as well.)

Procedure

Open Webex with one of your other users, either on your own computer, mobile devices, or virtual machines
provided in your session and log in. For example, Rebekah’s login info would be:
• Username: rbarretta@cbXXX.dc-YY.com
• Password: dCloudZZZZ!
Note The ZZZZ portion of the password is the last four digits of our Session ID found in your
sessions's Details tab.

Configuring Calling Features

Customer-Level Settings
Procedure

Step 1 In Control Hub, look under Services and click Calling.

Webex Calling Lab v4

18
 Scenarios
Webex Calling Feature Access Codes

Step 2 Click Locations. Select the location that was configured earlier, for instance dCloud, and click External
Dialing in the fly-out window.
Step 3 Click Edit next to External Dialing and click Continue.
Step 4 Specify the number the user must dial before placing an external call. In our lab, we will use 9 for outside
line. Under Outbound Dial Digit, choose 9 and click Save.
Step 5 Notice on the fly-out window you can set the caller ID for external calls. Right now the name will be the name
of the location. Feel free to change this if you would like.
We will test this section later in this lab, after we configure the local gateway.

Webex Calling Feature Access Codes

The Calling in Webex (Webex Calling) supports feature access codes (FAC) to give you access to advanced
calling features.
For some of the features, you need to get a dial tone before entering the code. For example, if you're on a call
that you want to park, place the call on hold, get a dial tone, and then enter *68. You can then enter the
extension at which you want to park the call or # to park the call on your own extension. The same will be
tested later in the guide. For more information, click here.

Adding New Calling Features

Now that you have the clients installed and logged in, you will configure the calling features. All of the feature
configurations are now completed in the Control Hub.

Configuring Call Queues

Call queues temporarily hold calls in the cloud when all users (agents) assigned to receive calls from the queue
are unavailable. Queued calls are routed to an available agent when he/she is no longer on an active call. Each
call queue is assigned a Lead Number, which is a telephone number outside callers can dial to reach users
assigned to the call queue. Call queues are also assigned an internal extension, which can be dialed internally
to reach users assigned to the call queue.
In the lab, you will configure a basic call queue. To view more information on call queues as well as more
advanced configurations, see Manage call queues in Control Hub.

Procedure

Step 1 In the Webex Control Hub under Services, click Calling. Click the Features tab.
Step 2 Click the Call Queue tab and Create Call Queue.
Step 3 Choose dCloud for the Location.
Step 4 Enter a relevant name for the call queue, such as Sales.
Step 5 Enter 6031 for the Extension.
Step 6 Click to choose Location number.
Step 7 Enter a name for Caller ID.

Webex Calling Lab v4

19
 Scenarios
Configuring Call Park Extensions and Call Park Group

Step 8 Choose a Language.

Step 9 At the bottom right of the page, click Next.
Step 10 Read over the call routing patterns and choose one from the list or keep Circular selected.
Step 11 Click Next.
Step 12 Toggle on Enable overflow after calls wait x seconds and keep 30 in the box.
Step 13 Toggle on Play announcement before overflow processing. Keep the default Play default announcement
selected.
Step 14 Check the box next to Welcome message is mandatory.
Step 15 Toggle on Estimated wait message for Queued Calls.
Step 16 Select the radio button for Announce Queue Position.
Step 17 At the bottom right of the page, toggle on Hold Music. Click Next.
Step 18 Click Add User or Workspace and choose Taylor Bard and Rebekah Barretta.
Step 19 Click Next.
Step 20 Review the settings and click Create. Click Done.

Configuring Call Park Extensions and Call Park Group

The Call Park feature allows a defined group user to park a call against other available members of a Call
Park group, which may be picked up by other members of the group at their phone.
What to know before getting started:
• A user can only be assigned to one Call Park group.
• A Call Park group may only have users from same site.
• A site may have multiple Call Park groups.
• Call Park group names must be unique.

Procedure

Step 1 In the Webex Control Hub under Services, click Calling. Click the Features tab.
Step 2 Click the Call Park Extension tab and then Create Call Park Extension.
Step 3 Click Manually Add.
Step 4 For location, choose dCloud.
Step 5 Enter a name for the extension, such as Call Park Extension.
Step 6 Enter 1111 for the extension.
Step 7 Click Save.
Step 8 Click the Call Park Group tab.
Step 9 Select Create Call Park Group.
Step 10 Enter a unique name for Call Park Group Name and click Next.
Step 11 Under Add Users and/or Places, select Taylor and Rebekah.
Step 12 Click Next.

Webex Calling Lab v4

20
 Scenarios
Configuring a Shared Voicemail Box

Step 13 You will see different options. For this lab, select Alert parking user only under Recall To. Click Next.
Step 14 Click Create and Done.

Configuring a Shared Voicemail Box

You can create a shared voicemail box and inbound fax box to assign to users or call routing features like an
auto attendant, call queue, or hunt group. With the voicemail group feature, you can set up new message
notifications, choose where you want the messages stored, and customize the voicemail box greeting.
You might use a voicemail group for any of the following scenarios:
• You need a general purpose voicemail for a department or workgroup.
• You'd like to add a voicemail option to an auto attendant or hunt group.
• You'd like to send the overflowed incoming calls from a call queue to a shared voicemail box.
• You have users who only need a voicemail box.

Procedure

Step 1 In the Webex Control Hub under Services, click Calling. Click the Features tab.
Step 2 Click the Voicemail Group tab and then Create Voicemail Group.
Step 3 For location, choose dCloud.
Step 4 Enter a name for the extension, such as Sales.
Step 5 Enter 3333 for the extension.
Step 6 Enter a first and last name for the group such as Sales VM.
Step 7 For the two passcode boxes, enter 071199.
Step 8 Click Next.
Step 9 On the next screen, choose a Language and keep Use internal mailbox selected.
Step 10 Toggle on New Message Notification and enter cholland@cbXXX.dc-YY.com. Replace the XXX and
YY with your session's domain info.
Step 11 Check the box for Email a copy of the message and use the same email as the previous step.
Step 12 Click Next. Click Create. Click Done.

Configuring Hunt Group

You will add/configure a hunt group. You may want to set up hunt groups in the following scenarios:
• A Sales team that wants sequential routing, such as 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.

Webex Calling Lab v4

21
 Scenarios
Configuring Auto Attendant

Procedure

Step 1 Click the Hunt Group tab, then click the Create Hunt Group.
Step 2 Enter a relevant name for the hunt group, such as Sales.
Step 3 As this is a lab environment, for the Phone Number, choose (None) from the drop-down list.
Step 4 Enter 6030 for the Extension.
Step 5 Enter a name for Caller ID, such as Sales. For Calling ID last name, enter Group.
Step 6 Choose a Language and then click Next.
Step 7 Keep Circular selected. Toggle on Advance after a set number of rings and configure 3 rings.
Step 8 Click Next.
Step 9 Select the call routing option to Advanced when Busy.
Step 10 Toggle on Forward after set number of rings and enter 7.
Step 11 For the extension enter 3333.
Step 12 Click Next.
Step 13 You have the options to add users or workspaces. Click Add User or Workspace and choose Taylor Bard
and Rebekah Barretta. Click Next.
Step 14 Review the settings and click Create and then Done.

Configuring Auto Attendant

Auto Attendants ensure 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. You can even route
calls based on caller ID attributes to create VIP lists or handle calls from certain area codes differently.

Procedure

Step 1 On the Calling features page, click the Auto Attendant tab.
Step 2 Click Create Auto Attendant.
Step 3 Enter an Auto Attendant Name, such as Main Attendant, and assign an extension 6020.
Step 4 Choose a Language.
Step 5 Enter a name for Calling ID First Name, such as Main. For Calling ID Last Name, enter Attendant.
Step 6 Click Next.
Step 7 Select the radio button for Create a new Schedule. Give the schedule a name, such as Open Hours.
Step 8 Edit the schedule that makes sense for you to test in the lab. Ideally, you’ll want to make sure when you
call in, the auto attendant will answer. Make sure the times are matching times you want to test in the lab.
Important Times are in the US PT time zone.

Step 9 Once you are finished with editing the schedule, click Next.
Step 10 Leave the Holiday Schedule as is and click Next.

Webex Calling Lab v4

22
 Scenarios
Configure Call Pickup

Step 11 Using the drop-down menus for each number, configure the following parameters from the table below for
Business Hours.

Setting Configuration
0 Exit Menu
1 Dial by extension
2 Dial by name
3 Transfer call without prompt
Enter 6021 and select Taylor from the list.

4 Transfer call with prompt

Enter 6030 and choose the hunt group from the list.

5 Transfer call without prompt

Enter 6031 and choose the call queue from the list.

You will be testing those configured numbers later but feel free to configure other numbers if you would like
for testing. To view more information about configuring an Auto Attendant, including a description on what
each option does and how to configure a custom greeting, see https://callinghelp.webex.com/manage_auto_
attendants/ and https://help.webex.com/en-us/article/nsioxoi/Manage-auto-attendants-in-Control-Hub

Step 12 Click Next.

Step 13 Keep Default Greeting for now. Feel free to expand and view the instructions or sample script sections. You
will be recording a greeting a little later. When you are finished, click Next.
Step 14 Review the configuration and then click Create and then Done.
Step 15 Next, you will dial in to record your voice prompts for the auto attendant. From your phone, dial the extension
number (6032) for the Voice Portal.
Step 16 Press the star/asterisk key [*] when prompted.
Step 17 For the mailbox ID, enter the extension for the Voice Portal (6032) and then the pound key [#].
Step 18 Enter the 071199 passcode and then the pound key [#]. (This was configured from Control Hub at the
beginning of the scenario.)
Step 19 Press 1 to change the Auto Attendant greeting.
Step 20 Press 1 to change the Business Hours greeting.
Step 21 Press 1 to change the Greeting.
Step 22 Record the new greeting to greet callers to your company and list the options configured above. When finished
recording, press pound [#].
Step 23 After recording, press 2 to listen to the greeting you recorded or 1 to re-record the greeting.
Step 24 Hang up when you are finished creating the greeting for the auto attendant.

Configure Call Pickup

You can enhance teamwork and collaboration by creating call pickups. Users that are added to a group call
pickup can answer calls when another member of the call pickup group is busy.

Webex Calling Lab v4

23
 Scenarios
Configuring Virtual Extension

Group Call Pickup enables a user to answer any ringing line within their pickup group. A pickup group is a
group administrator-defined set of users within a Site, to which the Call Pickup feature applies. The Group
Call Pickup feature requires Call Pickup groups to be added, modified, and removed as well as assigning
specific users to that pickup group.

Procedure

Command or Action Purpose

Step 1 Click the Call Pickup tab and then click
Create Call Pickup.
Step 2 Chose dCloud for the Location.
Step 3 Give the call pickup a name.
Step 4 Use the drop-down list and choose Taylor and
Rebekah.
Step 5 Click Create and then click Done.

Configuring Virtual Extension

If you have phone numbers outside your organization that users call on a frequent basis, you can make users'
lives easier by assigning extensions to those numbers.
Maybe you have remote workers on a separate telephony system or a key customer that you want to be able
to reach easily. You can associate an extension with their external phone number. You can then contact them
using their extension just like you'd contact anybody else in your organization with an assigned extension.
And when someone who's been assigned a virtual extension calls into your organization, their assigned internal
extension and name appear on the caller ID.

Procedure

Step 1 Click the Virtual Extension tab and then Create Virtual Extension.
Step 2 Click Manually Add.
Step 3 Enter a First Name, Last Name, and Phone Number. For the phone number, you can use a real number that
is accessible from the dCloud data center you are in (local or national). You can test this once you configure
the local gateway later.
Note Don't use phone number that you will be using later to test calling in from the PSTN with. This
will cause a routing loop.

Step 4 Enter 2222 as the Extension.

Step 5 Click Save.
Note You can test Virtual Extension after configuring the local gateway.

Webex Calling Lab v4

24
 Scenarios
Configuring Receptionist Clients

Configuring Receptionist Clients

Receptionist client help support the needs of front-office personnel. You can set up users as telephone attendants
so that they can screen all incoming calls to certain people within the organization. The Receptionist Client
feature realizes the promise of IP telephony by enhancing business processes and delivering rich services in
a user-friendly way.

Procedure

Step 1 Open the Webex Control Hub (https://admin.webex.com). Under Management in the left-hand menu, select
Users.
Step 2 Select Anita Perez and then click the Calling tab.
Step 3 Select Advanced Call Settings and then click Receptionist Client.
Step 4 To enable, select the toggle to On.
Step 5 Here you can select the users or workspaces that can be monitored by this receptionist user within the
Receptionist client. Select Taylor Bard and Rebekah Barretta. Click Save.
Once the Receptionist client has been set up and assigned to at least one user (Anita Perez), you can view the
list of all Receptionist clients in the Services/Features area of Control Hub.

Step 6 Under Services in the left-hand menu, select Calling > Features.
Step 7 Select Receptionist Client tab from the top menu.
Step 8 This is the list of users assigned a receptionist for this location. To export the list, select Export.

Signing in to Calling User Portal

The Receptionist Client is a web-based tool that runs in a separate browser. It combines your telephone handset
with a desktop interface that makes it easy for you to direct calls to staff, wherever they are.

Procedure

Step 1 If not already open from earlier, log in to WKST2. Open Webex app with aperez@cbXXX.dc-YY.com using
the password dCloud123!
Note You can also use your personal machine with Webex installed.

Step 2 Open a new browser tab to settings.webex.com and log in with aperez@cbXXX.dc-YY.com
Step 3 Once logged in, select the Webex Calling tab. You are routed to the Calling User Portal.
Step 4 From the Call User dashboard, click the My Apps tab.
Step 5 Click the Receptionist Soft Console (Receptionist).
Step 6 After cross-launching from the Calling User Portal, you can log into the Receptionist Soft Console by entering
the receptionist credentials e.g. aperez@cbXXX.dc-YY.com and the password of dCloud123! (if prompted).
Step 7 Click Favorites. You can see the list of users you added earlier, Taylor Bard and Rebekah Barretta.
Step 8 Enterprise displays all the contacts with in your company or organization.
Step 9 Anytime there is call between Taylor and Rebekah you can noticed the status of their lines.

Webex Calling Lab v4

25
 Scenarios
Testing Calling Features

More information about Receptionist Clients can be found here.

Testing Calling Features

Now that the calling features have been configured, it’s now time to test them.

Note You should have Taylor and Rebekah configured for a phone or logged them into Webex. As mentioned
earlier, since Taylor and Rebekah have been configured for all the calling features, it would be best if you
have another user configured, such as Stefan Mauk (Extension 6024) logged into a Webex to initiate all the
calls. If that’s not possible, you can call in with either Taylor or Rebekah. All tests below will assume a third
user calling into the system and Taylor and Rebekah answering the calls.

Testing Auto Attendant, Hunt Group, and Call Queue

Earlier when you configured the Auto Attendant, you recorded a greeting and configured the options. As a
reminder, the options were configured with the following parameters from the table below.

Setting Configuration
0 Exit Menu
1 Dial by extension
2 Dial by name
3 Transfer call without prompt
Enter 6021 and select Taylor from the list.

4 Transfer call with prompt

Enter 6030 and choose the hunt group from the list

5 Transfer call without prompt

Enter 6031 and choose the call queue from the list

Ideally, you need three users to fully test these features. You have configured Taylor and Rebekah for the
hunt group and call queue, so a third user (such as Stefan Mauk) calling in can test routing to both users.

Procedure

Step 1 Dial the extension of the Auto Attendant (6020) with your third user.
Step 2 Test option 1 and enter an extension of either Taylor or Rebekah. The call should forward to the extension.
Step 3 Test option 2 and using the keypad, enter the first or last name of Taylor or Rebekah. The call should forward
after the first three characters are entered. Answer the call. If you decline the call, it will be sent to voicemail.
Step 4 Test option 3. Taylor's phone will ring, who is the user you configured to transfer to.

Webex Calling Lab v4

26
 Scenarios
Test Call Pickup

Step 5 Test option 4. Observe the following points:

• You should hear a voice prompt telling you your call is being transferred.
• Taylor or Rebekah's phone/client will ring.
• If you decline the incoming call, it will fall over to the other user.
• If you let the call ring, it will continue to prompt the user based on the timer you set.
• Eventually, after the time you set, it will fall over to the other user to answer and eventually after no one
answers go to the group Voicemail box.

Step 6 Test option 5. Observe the following points:

• You should hear a voice prompt telling you to wait for next available agent. It will also notify you of
your queue position.
• Taylor or Rebekah's phone/client will ring.
• If you decline the incoming call, it will fall over to the other agent.
• If you let the call ring, it will continue to prompt the user based on the timer you sent.
• Eventually, after the time you set, it will fall over to the other user to answer and eventually register a
busy signal if no one answers.

Step 7 Feel free to test any other options you configured for the Auto Attendant.

Test Call Pickup

Next you will test Call Pickup. Ideally you need three users to fully test this feature. You have configured
Taylor and Rebekah in the pickup group. In this case you need a third user to dial on of htem and the other
user, not called, to initiate the pickup.

Procedure

Command or Action Purpose

Step 1 Initiate a call to Rebekah (6022) from your
third user with the Webex app.
Step 2 Do not answer Rebekah. On Taylor's
phone/client, dial *98 to pick up the call.
Step 3 Give the call pickup a name.
Step 4 When you are finished, end the call.

Testing Call Park

You will test Call Park. Ideally you need three users to fully test this feature. You have configured Taylor
and Rebekah in the Call Park group. In this case, you need a third user (Stefan Mauk) to dial one of them,
park the call, and pick up the call with the other user or the same user.

Webex Calling Lab v4

27
 Scenarios
Configuring Webex Calling Internal Dial Plans

Procedure

Step 1 Initiate a call to Taylor (6021) from your third user using the Webex app.
Step 2 Answer the call on the phone. You can park the call as follows:
• Press the Transfer softkey or physical transfer button. Enter *68 and then when you hear the long
beep, enter the four-digit extension of the user you just called or another user and then the pound [#]
key. The call will be parked at the user extension and you will hear hold music on the dial-in user’s client.
• Answer the call on the phone. Press the Park softkey. Press the pound [#] key. When you hear the long
beep, press the pound [#] key again to park the call on the user’s extension. You can also dial an extension,
such as 1111, which is the virtual extension dialed earlier.

Step 3 To retrieve the call from the phone or client, dial *88. Enter the four-digit extension of where you parked
the call followed by the pound # key.
Step 4 End the call when you are finished.

Configuring Webex Calling Internal Dial Plans

You can control the internal dial plan for your Webex Calling deployment. You can customize extension
lengths, routing prefixes, and dialing preferences to be compatible with the dialing habits of our users. As this
is a lab environment, we will focus on internal dialing patterns.

Procedure

Step 1 In the Webex Control Hub, under Services, click Calling. Click the Service Settings tab and then scroll to
Internal Dialing. Click Edit.
Step 2 Click Continue.
Step 3 Configure the following dialing preferences:
• Location Routing Prefix Length - From the drop-down list, select 4.
Note This setting is recommended if you have multiple locations. You can enter a length of 2 to
7 digits. If you have multiple locations with the same extension, users must dial a prefix
when calling between locations.

• Steering Digit in Routing Prefix - From the dropdown list select 8.

Note 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. We will change the value to
4 from drop-down list.
Note After you increase your extension length, existing speed dials to internal extensions are not
automatically updated.

Important The configured Location routing prefix length includes the leading routing prefix . As we will
be using three-digit site codes in this lab, the location routing prefix length must be set to four.

Webex Calling Lab v4

28
Scenarios
Configuring Webex Calling Internal Dial Plans

Step 4 Click Save.

Step 5 Scroll down to Call Routing between Webex Calling and premises, keep the behavior to Standard behavior.
Note For abbreviated on-net dialing, a Location routing prefix length, an internal routing prefix, and
the internal extension length must be configured for each Webex Calling customer.

• Location Routing prefix length - Defines the length for all routing prefixes to be configured for each
location.
• Internal routing prefix - Is the common first digit for all location routing prefixes e.g Steering digit.
• Internal extension length - Defines the extension length to be used in each location.

With these three settings, a universal abbreviated inter-site on -net dialing habit is defined in the form: <internal
routing prefix>-<site code>-extension
If, for example, an internal routing prefix of 8, a location routing prefix length of 4, and an extension length
of 4 are configured then all on-net destinations can be dialed in the form 8-XXX-XXXX. Here, the leading
8, followed by three digits, is the location’s prefix, and the last four digits are the extension defined within
the location.
Note As this is a lab environment, we will be creating a new location called London and use it to test
calls between two different locations ONLY.

Step 6 Under Services, click Calling. Select Locations > Add Location.
Step 7 For Location Name enter London. Select United Kingdom for Country. Enter any address and fill out all
other fields and click Save.
Step 8 In the popup windows for Add Your Calling Connection for London?, click Yes.
Step 9 Select Premised-based PSTN and click Next.
Step 10 Keep None selected and check the box to confirm you are changing the call routing to PSTN. Click Next.
Note If the Save button is greyed out, select None again from the drop-down list.

Step 11 Click Add Numbers Now.

Step 12 Keep London as the location and then click Next.
Step 13 Toggle on Activate Numbers Later.
Step 14 In the Enter phone numbers separated by commas box, add one unique number starting with 118916 and
a random string of four numbers at the end (for instance, 118916XXXX). Press Enter/Return on your keyboard
after entering the number and then click Save. Click Close.
Step 15 At the top of the page, click Locations. Click the London location.
Step 16 In the fly-out window, select the drop-down menu for Main Number and choose the fake number you created
in the previous steps for London. Click Save.
In the next steps, we will configure another user, Eric Steele, for Webex Calling and assigning him an extension
from London DN range.

Step 17 Under Management, click Users. Select Eric Steele from the user list.
Step 18 On the next page, scroll down to the Licenses section and click Edit Licenses.
Step 19 Check the box for Webex Calling, keep the box for Professional selected. Click Next.
Step 20 Choose London for the Location, leave Phone Number as None, and enter 5001 for the Extension. Click
Save then Close.

Webex Calling Lab v4

29
 Scenarios
Testing Calls between dCloud and London Location

Note As this is the lab environment and we are testing calls between two locations, make sure in the
above step you select London as Location and not dCloud.

Step 21 Under Services, click Calling. Click Location > dCloud.

Step 22 Scroll to Call Settings and choose Internal Dialing. Cick Edit for Internal Dailing and click Continue.
Step 23 For Location Routing prefix, enter 8001 and click Save.
Note In Service Setting, we have set the steering digit to 8 and defined the Location Routing Prefix
length as 4 (that includes steering digit and three digits for location routing prefix).

Step 24 On the Locations page, select the London location.

Step 25 Scroll to Call Settings and click Internal Dialing. Click Edit for Internal Dialing and click Continue.
Step 26 For Location Routing Prefix, enter 8044. Click Save.

Testing Calls between dCloud and London Location

Procedure

Step 1 Using your personal device, log in to Webex with esteele@cbXXX.dc-YY.com, or you can use one of the
Workstations provided in your session.
Step 2 We will do internal dialing from Eric (London location) to Taylor (dCloud location). Initiate a Webex call
from Eric to Taylor by dialing 80016021.
Step 3 Initiate a Webex call from Taylor to Eric by dialing 80445001.

Configuring CUBE High Availability (HA)

Value Proposition: With this feature, you are able to preserve LGW based PSTN calls, should the active
CUBE go out of service for planned or planned reasons.
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. The Active/Standby pair share the same virtual IP address (VIP) across the
respective interfaces and continually exchange status messages. CUBE session information is check-pointed
across the Active/Standby pair of routers enabling the Standby router to take over immediately all CUBE call
processing responsibilities if the Active router should go out of service, resulting in stateful preservation of
signaling and media.

Note Check pointing is limited to connected calls with media packets. Calls in transit are not check pointed, such
as Trying or Ringing state.
Further in the application note, CUBE HA will refer to CUBE High Availability (HA) Layer 2 Box-to-Box
(B2B) redundancy for stateful call preservation.

Webex Calling Lab v4

30
Scenarios
Configuring CUBE High Availability (HA)

As of IOS-XE 16.12.2, CUBE HA can be deployed as Local Gateway for Cisco Webex Calling deployments
and in this application, note we will cover design considerations and configuration. The following is a typical
CUBE HA setup as Local Gateway for a Cisco Webex Calling deployment.

Redundancy Group (RG) Infra component will provide the box-to-box communication infrastructure support
between the two CUBEs and will negotiate the final stable redundancy state. The RG Infra component 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 figure 3 above
• Configuration/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 will have to be specifically configured to support voice B2B HA.
Virtual IP address management (VIP) 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 CUCM, Webex Calling
access SBC, service provider, or proxy, will use VIP as the destination IP address for the calls traversing
through the CUBE HA routers. Hence, from 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 (i.e. calls that are not fully established yet or are in the process of being modified
with a transfer or hold function) at the time of failover will not be preserved post-switchover. A switchover
occurring on an established call may be disconnected post-switchover.

Webex Calling Lab v4

31
 Scenarios
CUBE HA Design Considerations and Restrictions

CUBE HA Design Considerations and Restrictions

The following requirements exist for using CUBE HA as LGW 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), for instance, 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/media

Webex Calling Lab v4

32
 Scenarios
CUBE HA as LGW Configuration Steps

CUBE HA as LGW Configuration Steps

CUBE HA as LGW should be configured in the following order.
1. Configure layer 2 box-to-box redundancy on both the CUBEs to bring up virtual IPs (This scenario)
2. Place LGW specific configurations on both the platforms (Next Scenario)

Name Description Host Name (FQDN) IP Address Username Password

Local CSR1000V (IOS-XE N/A 198.18.1.226 - Gig1 admin dCloud123!

Gateway1 16.12.2)
198.18.133.226 -
(CUBE HA as Gig2
LGW)
10.1.1.1 - Gig3

Local CSR1000V (IOS-XE N/A 198.18.1.227 - Gig1 admin dCloud123!

Gateway2 16.12.2)
198.18.133.227 -
(CUBE HA as Gig2
LGW)
10.1.1.2 - Gig3

(Reference: Implement CUBE High Availability as Local Gateway.)

Step by Step IOS-XE Configuration for Layer 2 Box-to-Box Redundancy

Proceed with the following steps on both the vCUBEs intended to be used in an HA pair and as a Local
Gateway.

Procedure

Step 1 Connect to Workstation 1 and open PuTTY using the icon on the desktop [ ]. (if you are VPNed into the
dCloud session, you can also use your local SSH client.) Double click the Local Gateway1. Once that window
is open, right click the top of the window and chose Saved Sessions > Local Gateway2 to open the 2nd
gateway.
Step 2 Log in to both with admin / dCloud123!
Step 3 Interface tracking: Configure the below at global level to track the status of the interfaces.

Webex Calling Lab v4

33
 Scenarios
CUBE HA as LGW Configuration Steps

Configuration

conf t
track 1 interface GigabitEthernet1 line-protocol
track 2 interface GigabitEthernet2 line-protocol
exit

Note Enter the configs on both Local Gateway1 and Local Gateway2.
Track CLI is used in RG to track the voice traffic interface state so that the Active router will quit its Active
role after the traffic interface is down.

Step 4 Enabling Redundancy Group (RG) on the platforms: Configure an RG Group on both the CUBEs for use with
VoIP HA under the application redundancy sub-mode.

Webex Calling Lab v4

34
Scenarios
CUBE HA as LGW Configuration Steps

Configuration

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

An explanation of the fields used in this configuration is as follows:

• redundancy - Enters redundancy mode
• application redundancy - Enters application redundancy configuration mode
• group - Enters redundancy application group configuration mode
• name LocalGateway-HA - Define the name of the RG Group
• priority 100 failover threshold 75 - Specifies the initial priority and failover threshold for a redundancy
group
• timers delay 30 reload 60 - Configures the two timers for delay and reload:
• Delay timer 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 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.

Webex Calling Lab v4

35
 Scenarios
CUBE HA as LGW Configuration Steps

• 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

It is recommended to have the holdtime timer configured to be at least three times the value of the hellotime
timer.

Webex Calling Lab v4

36
Scenarios
CUBE HA as LGW Configuration Steps

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

voice service voip

redundancy-group 1
exit

• redundancy-group 1 - Adding/removing this command requires a reload for the updated configuration
to take effect. We will reload the platforms after all the configuration has been applied

Note Wait till the end of all the steps before proceeding with the reload of the platforms.

Step 6 Configure the traffic interfaces for RG Infra protocol. Configure the Gig1 and Gig2 interfaces on both CUBEs
with their respective virtual IPs as shown below and apply the redundancy interface identifier (rii)

Webex Calling Lab v4

37
 Scenarios
CUBE HA as LGW Configuration Steps

Configuration

interface GigabitEthernet1
redundancy rii 1
redundancy group 1 ip 198.18.1.228 exclusive
exit
!
interface GigabitEthernet2
redundancy rii 2
redundancy group 1 ip 198.18.133.228 exclusive
exit

An explanation of the fields used in this configuration is as follows:

• 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

Note 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.
Note 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.

Webex Calling Lab v4

38
 Scenarios
Active / Standby Show Command Verification

Step 7 Save the configurations and reload both the platforms one by one starting with LocalGateway1. Wait for it
to boot up completely and then LocalGateway2.
Note This step can be done after applying the Local Gateway specific configuration to both the
platforms. However, we will proceed with this step to display relevant CUBE HA set of show
commands prior to applying Local Gateway specific CLI to the CUBEs.

Configuration

exit
wr
reload

First save the configuration of LocalGateway1 and reload it.

Once LocalGateway1 boots up completely, save the configuration of LocalGateway2 and reload it.

Active / Standby Show Command Verification

We reloaded LocalGateway2 last and as per the design considerations, the platform to reload last will always
be Standby. Using the CLI below, we can verify the Box-to-Box configuration is working as expected. Relevant
output is highlighted in bold.

Webex Calling Lab v4

39
 Scenarios
Active / Standby Show Command Verification

show redundancy application group all

LocalGateway1#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
Standby Peer: Present. Hold Timer: 10000
Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

LocalGateway1#

Webex Calling Lab v4

40
Scenarios
Active / Standby Show Command Verification

LocalGateway2#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: STANDBY HOT
Peer RF state: ACTIVE

RG Protocol RG 1
------------------
Role: Standby
Negotiation: Enabled
Priority: 100
Protocol state: Standby-hot
Ctrl Intf(s) state: Up
Active Peer: address 10.1.1.1, priority 100, intf Gi3
Standby Peer: Local
Log counters:
role change to active: 0
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: Standby
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 67, Bytes 4154, HA Seq 0, Seq Number 67, Pkt Loss 0
Authentication not configured
Authentication Failure: 0
Reload Peer: TX 0, RX 0
Resign: TX 0, RX 0
Active Peer: Present. Hold Timer: 10000
Pkts 58, Bytes 1972, HA Seq 0, Seq Number 1506, Pkt Loss 0

LocalGateway2#

Webex Calling Lab v4

41
 Scenarios
Deploying Local Gateway for PSTN Calling

Deploying Local Gateway for PSTN Calling

Value Proposition: With this feature, you are able to Bring Your Own PSTN (BYOPSTN) and provide PSTN
connectivity to your cloud registered phones.
Up until now, you have been testing all internal calls with no PSTN access. In this section, you will explore
the local gateway option for Webex Calling. There are a few options when configuring a local gateway for
your site. In this lab, you will configure a local gateway for a single customer site to route calls from/to Webex
Calling endpoints and the PSTN SIP Provider located at 198.18.133.3.
We will be using CUBE HA from the last scenario as the Local Gateway for this setup.
Local Gateway Deployment without an On-prem IP PBX

The figure above displays a Webex Calling deployment without any existing IP PBX and is applicable to a
single or a multi-site deployment. For all calls that do not match the customer’s Webex destinations, Webex
sends those calls to the Local Gateway assigned to the site for processing. Local Gateway routes all calls
coming from Webex to the PSTN and vice versa. The PSTN gateway may be a dedicated platform or co-resident
with the Local Gateway (focus of this Scenario). The dedicated PSTN gateway variant of this deployment
is a preferred option for Webex Calling deployments.
In this lab, we will deploy a co-resident PSTN and Local Gateway as shown in the figure on the next page.
The Local Gateway may be IP based, connecting to an ITSP using a SIP trunk (focus of this Scenario), or
TDM-based using an ISDN or analog circuit.

Local Gateway Hardware and Software Requirements

• ISR 4321, 4331, 4351, 4431, 4451, CSR 1000v (vCUBE) – (IOS XE 16.9(4) and 16.12.2 or later)
• IOS-XE 16.10.x is not supported as Local Gateway for any platform
• ISR 1100 (IOS-XE 16.12.2)

Webex Calling Lab v4

42
 Scenarios
Local Gateway Onboarding Process

Reference Prepare Your Environment for Webex Calling

Note The Local Gateway configuration provided in this lab is for CSR1000v running IOS-XE16.12.2 as required
for CUBE HA as a LGW setup from Scenario 3.

The call flow into the dCloud session works as follows:

1. Call comes to a dCloud PSTN DID number from the SIP PSTN provider.
2. The dCloud gateway translates that number into a four-digit extension and sends it to the Local Gateway.
• These numbers can be found in the Phone Numbers sections in your dCloud session’s details page.
They can also be found on the desktop of Workstation 1 in a text file named DN_to_DID.txt.

3. Local Gateway then routes these calls to Webex, which in turn rings the Webex Calling endpoints at a
customer site.
• Four extensions used in the lab are: 6021, 6022, 6023, 6024

Local Gateway Onboarding Process

Enabling Local Gateway for Webex Calling requires:
• Partner to define Local GW for a customer site within Control Hub, generating connection parameters
• Local GW to register over SIP TLS using connection parameters from Control Hub above
• Call Routing on LGW based on PSTN connectivity requirements

Creating Local Gateway

The first task is to create the local gateway in the Control Hub. You will need the information provided after
creation to build your local gateway.

Procedure

Step 1 Open the Chrome web browser to https://admin.webex.com and enter cholland@cbXXX.dc-YY.com. Click
Sign In.
Step 2 Enter dCloud123! as the password and click Sign In again.
Step 3 Click Accept if prompted.
Step 4 In Control Hub, under Services, navigate to Calling. Click Call Routing tab.
Each location can be assigned a trunk. In the lab, we will configure one location (such as dCloud) that will
connect to the local gateway in your dCloud session.

Step 5 Click Add Trunk. Select the dCloud location. For name, enter Hussain. Click Save.
Step 6 After a few moments, information will display. You will need this information to configure the local gateway.
Capture the info now. It is recommended to use the DN_to_DID.txt document on Workstation 1 and copy

Webex Calling Lab v4

43
 Scenarios
Creating Local Gateway

the information there. You will need the Registrar Domain, Trunk Group OTG/DTG, Line/Port, and
Outbound Proxy Address.

Step 7 Click the X to close out the window after capturing the information.
Step 8 Click the Locations tab and click the dCloud location.
Step 9 In the fly-out window, click Manage for PSTN Connection.
Step 10 Click the box for Premises-based PSTN. Click Next.
Step 11 Choose the Hussain trunk from the list and check the box to confirm changing the PSTN routing.
Step 12 Click Next and then Done.

Webex Calling Lab v4

44
 Scenarios
Local Gateway Configuration

Local Gateway Configuration

Now you will configure your local gateway with the information you have received in the previous section
on both the platforms, LocalGateway1 and LocalGateway2.

Note All the commands can also be found on the desktop of Workstation 1 named LGW_Config.txt.
All the steps in this section need to be carried out on both LocalGateway1 and LocalGateway2.

Procedure

Step 1 Connect to Workstation 1 and open PuTTY using the icon on the desktop [ ]. (If you used VPN to
connect to the dCloud session, you can also use your local SSH client.)
Step 2 Double-click the LocalGateway1 and LocalGateway2 saved session to SSH to the local gateways.
Step 3 Log in with admin / dCloud123!
Step 4 Before we proceed with the Local Gateway configuration, we need to ensure that a master key must be
pre-configured for the password with the commands shown below before it can be used in the credentials
and/or shared-secrets. Type 6 passwords are encrypted using AES cipher and user-defined master key. We
will use Password123 as our master key. Enter the commands on both the gateways.
.
configure terminal
key config-key password-encrypt Password123
password encryption aes
end

Step 5 Using the configuration below, create a dummy PKI Trustpoint and call it dummyTp.
Step 6 Assign the trustpoint as the default signaling trustpoint under sip-ua. The cn-san-validate server is needed
to ensure LGW establishes the connection only if the outbound proxy configured on the tenant 200 (described
later) matches with CN-SAN list received from the server. The crypto trustpoint is needed for TLS to work
even though a local client certificate (i.e. mTLS) is not required for the connection to be set up.

Webex Calling Lab v4

45
 Scenarios
Local Gateway Configuration

Step 7 Finally disable TLS v1.0 and v1.1 by enabling v1.2 exclusivity and set tcp-retry count to 1000 (5 seconds),
as shown below.
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
tcp-retry 1000
end

Webex Calling Lab v4

46
 Scenarios
Local Gateway Certificate Configuration and Verification

Local Gateway Certificate Configuration and Verification

Procedure

Step 1 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. The trustpool bundle must be updated
by downloading the latest Cisco Trusted Core Root Bundle from http://www.cisco.com/security/pki, as
shown below.
! Check if the DigiCert Root CA certificate exists
show crypto pki trustpool | include DigiCert
! - If not, update as shown below
configure terminal
crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b
end
! Verify
show crypto pki trustpool | include DigiCert

Step 2 Enter the following commands to turn on the Local Gateway/CUBE application on the platform.

Webex Calling Lab v4

47
 Scenarios
Local Gateway Certificate Configuration and Verification

configure terminal
voice service voip
ip address trusted list
ipv4 85.119.56.128 255.255.255.192
ipv4 85.119.57.128 255.255.255.192
ipv4 185.115.196.0 255.255.255.128
ipv4 185.115.197.0 255.255.255.128
ipv4 128.177.14.0 255.255.255.128
ipv4 128.177.36.0 255.255.255.192
ipv4 135.84.169.0 255.255.255.128
ipv4 135.84.170.0 255.255.255.128
ipv4 135.84.171.0 255.255.255.128
ipv4 135.84.172.0 255.255.255.192
ipv4 199.59.64.0 255.255.255.128
ipv4 199.59.65.0 255.255.255.128
ipv4 199.59.66.0 255.255.255.128
ipv4 199.59.67.0 255.255.255.128
ipv4 199.59.70.0 255.255.255.128
ipv4 199.59.71.0 255.255.255.128
ipv4 135.84.172.0 255.255.255.128
ipv4 135.84.173.0 255.255.255.128
ipv4 135.84.174.0 255.255.255.128
ipv4 199.19.197.0 255.255.255.0
ipv4 199.19.199.0 255.255.255.0
ipv4 139.177.64.0 255.255.255.0
ipv4 139.177.65.0 255.255.255.0
ipv4 139.177.66.0 255.255.255.0
ipv4 139.177.67.0 255.255.255.0
ipv4 139.177.68.0 255.255.255.0
ipv4 139.177.69.0 255.255.255.0
ipv4 139.177.70.0 255.255.255.0
ipv4 139.177.71.0 255.255.255.0
ipv4 139.177.72.0 255.255.255.0
ipv4 139.177.73.0 255.255.255.0
ipv4 23.89.76.128 255.255.255.128
ipv4 170.72.29.0 255.255.255.0
ipv4 170.72.17.128 255.255.255.128
ipv4 170.72.0.128 255.255.255.128
exit
allow-connections sip to sip
media statistics
media bulk-stats
no supplementary-service sip refer
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
sip
g729 annexb-all
early-offer forced
end

Webex Calling Lab v4

48
Scenarios
Local Gateway Certificate Configuration and Verification

Explanation of Commands above.

• ip address trusted list - Toll Fraud Prevention

Webex Calling Lab v4

49
 Scenarios
Local Gateway Certificate Configuration and Verification

This is to explicitly enable the source IP addresses of entities from which Local Gateway expects legitimate
VoIP calls, for example, Webex 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 from the Port Reference section of the Configuration
Guide for Cisco Webex Calling Customers document
(https://help.webex.com/en-us/b2exve/Port-Reference-Information-for-Cisco-Webex-Calling#id_119637).
The configuration on the previous page includes all the existing Webex data centers as of the writing of
this document.
• media statistics
Enables media monitoring on the LGW.
• media bulk-stats
Enables the control plane to poll the data plane for bulk call statistics.
• allow-connections sip to sip
Allows this platform to bridge two VoIP SIP call legs. It is disabled by default.
• no supplementary-service sip refer and no supplementary-service sip handle-replaces
Disables REFER and replaces the Dialog ID in the Replaces header with the peer dialog ID.
• fax protocol pass-through g711ulaw
Enables audio codec for fax transport.
• stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
Enables STUN globally. When a call is forwarded back to a Webex user (such as when both the called
and calling parties are Webex subscribers and have the media anchored at the Webex SBC), the media
cannot flow to the local gateway as the pin hole is not opened.
The STUN bindings feature on the local gateway allows locally generated STUN requests to be sent over
the negotiated media path. The shared secret is arbitrary as STUN is only used to open the pinhole in the
firewall and allow media latching to take place in the Webex Access SBC.
STUN password is a pre-requisite for LGW/CUBE to send STUN message out. IOS/IOS-XE-based
firewalls can be configured to check for this password and open pin-holes dynamically (i.e. without
explicit in-out rules). But for the LGW deployment case, the firewall is statically configured to open
pin-holes in the outbound direction based on Webex SBC subnets, so the firewall should just treat this
as any inbound UDP packet, which will trigger the pin-hole opening without explicitly looking at the
packet contents.
• sip
g729 annexb-all
Allows all variants of G729.
• sip
early-offer forced

Webex Calling Lab v4

50
 Scenarios
Configuring SIP Profile

This command forces the LGW/CUBE to send the SDP information in the initial INVITE message itself
instead of waiting to send the information till it gets an acknowledgement from the neighboring peer.

Configuring SIP Profile

In this section we will configure only the SIP profile 200 as shown in the figure below, using only the trunk
group OTG/DTG parameter for rule 20.

Procedure

Step 1 Configure the following SIP profile required to convert SIPS URIs back to SIP as Webex does not support
SIPS URI in the request/response messages (but needs them for SRV query, for example,
_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. In the example below,
hussain3350_lgu is used. Make sure you replace the example with your respective Trunk Group OTG/DTG
information.
Note Do not use the example hussain3350_lgu shown for reference in the table below. Use your
respective Trunk Group OTG/DTG information.
Sample Configuration Mapping

Local gateway SIP profile configuration.

configure terminal
voice class sip-profiles 200

Webex Calling Lab v4

51
 Scenarios
Configuring SIP Profile

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=hussain3350_lgu>"
rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

Step 2 Configure Codec Profile, STUN definition, and SRTP Crypto suite as shown and explained below.
voice class codec 99
codec preference 1 g711ulaw
codec preference 2 g711alaw
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

Explanation of commands above:

• voice class codec 99

Webex Calling Lab v4

52
 Scenarios
Configuring SIP Profile

Allows g711 (mu and a-law) codec for sessions. Will be applied to all the dial-peers.
• voice class srtp-crypto 200
Specifies SHA1_80 as the only SRTP cipher-suite that will be offered by LGW/CUBE in the SDP in
offer and answer. Webex only supports SHA1_80. This command will be applied to voice class tenant
200 (discussed later) facing Webex.
• voice class stun-usage 200
• Defines STUN usage. Will be applied to all Webex facing (2XX tag) dial-peers to avoid no-way audio
when a Unified CM Phone forwards the call to another Webex phone.

Step 3 Configure voice class tenant 200 as shown below. However, be sure to use the parameters obtained from the
Control Hub as shown in the mapping below and not as displayed under the voice class tenant 200 in this
document.
Sample Configuration

g n i p p a M
Note Do not use these examples as they are only shown here for reference that is used in the table
below. Use the configuration gathered earlier in Control Hub when adding the Local Gateway.
• Registrar Domain: 40462196.cisco-bcld.com
• Trunk Group OTG/DTG: hussain3350_lgu
• Line/Port: Hussain8789_LGU@40462196.cisco-bcld.com
• Outbound Proxy Address: la01.sipconnect-us10.cisco-bcld.com
• Username: Hussain3350_LGU
• Password: bjljJ2VQji

Webex Calling Lab v4

53
 Scenarios
Configuring SIP Profile

Local gateway tenant configuration

voice class tenant 200
registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
credentials number Hussain8789_LGU username Hussain3350_LGU password 0 bjljJ2VQji realm
BroadWorks
authentication username Hussain3350_LGU password 0 bjljJ2VQji realm BroadWorks
authentication username Hussain3350_LGU password 0 bjljJ2VQji 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

Explanation of Commands above:

• voice class tenant 200
This CUBE multi-tenant 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).

Webex Calling Lab v4

54
Scenarios
Configuring SIP Profile

• credentials number Hussain8789_LGU username Hussain3350_LGU password bjljJ2VQji realm

BroadWorks
Credentials for Trunk Registration challenge.
• authentication username Hussain3350_LGU password bjljJ2VQji realm BroadWorks
authentication username Hussain3350_LGU password bjljJ2VQji realm 40462196.cisco-bcld.com
Authentication challenge for calls.
• no remote-party-id
Disable SIP Remote-Party-ID (RPID) header as Webex supports PAI, which is enabled using CLI
asserted-id pai (see below).
• sip-server dns:40462196.cisco-bcld.com
Webex servers.
• connection-reuse
To use the same persistent connection for registration and call processing.
• srtp-crypto 200
Specifying SHA1_80 defined in voice class srtp-crypto 200.
• session transport tcp tls
Setting transport to TLS.
• url sips
SRV query has to be SIPS as supported by the access SBC; all other messages will be changed to SIP
by sip-profile 200.
• error-passthru
SIP error response pass-thru functionality.
• asserted-id pai
Turn on PAI processing in LGW/CUBE.
• bind control source-interface GigabitEthernet1
Signaling source interface facing Webex.
• bind media source-interface GigabitEthernet1
Media source interface facing Webex.
• no pass-thru content custom-sdp
Default command under tenant.
• sip-profiles 200
To change 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-us90.cisco-bcld.com

Webex Calling Lab v4

55
 Scenarios
Configuring SIP Profile

Webex Access SBC.

• privacy-policy passthru
Transparently pass across privacy header values from incoming to the outgoing leg.

Step 4 Next, configure the following voice class tenants.

Local Gateway Voice Class Tenant Configuration
! Voice class tenant 100 will be applied on all OUTBOUND dial-peers facing the IP PSTN
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 will be applied on all INBOUND dial-peers from the IP PSTN
voice class tenant 300
bind control source-interface GigabitEthernet2
bind media source-interface GigabitEthernet2
no pass-thru content custom-sdp

Step 5 Configure the following voice class URIs for URI-based dialing.
! - Defines ITSP’s host IP address

voice class uri 100 sip

host ipv4:198.18.133.3

! - Defines pattern to uniquely identify a Local gateway site within an Enterprise

voice class uri 200 sip

pattern dtg=hussain3350.lgu

Configure voice class uri 200 as shown above. See the important note below.
Note IMPORTANT – However, use the parameters obtained from the Control Hub as shown in the
mapping below and not as displayed under the voice class uri 200 in this document.
The pattern defined within voice class uri 200 is configured to match the unique Trunk Group OTG/DTG
parameter obtained from the Control Hub earlier and also defined in rule 20 of the voice class sip-profiles
200.

Webex Calling Lab v4

56
Scenarios
Configuring SIP Profile

Note Local Gateway today doesn’t support the underscore “_” in the match pattern. As a workaround,
we used the dot wildcard “.” (match any) to match the underscore “_” within hussain3350_lgu
(example displayed in this document).

Local Gateway Voice Class Configuration

Step 6 Configure the following outbound dial-peers shown below.

Local Gateway Outbound Dial-Peer Configuration
! - 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:198.18.133.3
voice-class codec 99
voice-class sip tenant 100
dtmf-relay rtp-nte
no vad

Webex Calling Lab v4

57
 Scenarios
Configuring SIP Profile

! - Outbound dial-peer towards Webex

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
voice-class stun-usage 200
no voice-class sip localhost
voice-class sip tenant 200
dtmf-relay rtp-nte
srtp
no vad

Step 7 Configure the following dial-peer groups (DPG).

Local Gateway Dial-Peer Group Configuration
! - 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 200 defined later for Webex --> LGW --> PSTN path

voice class dpg 100

description Incoming BCLD(DP200) to IP PSTN(DP101)
dial-peer 101 preference 1

! - Define dial-peer group 200. Outbound dial-peer 200201 is the target for any incoming
dial-peer invoking dial-peer group 200. We will apply DPG 200 to
!- incoming dial-peer 100 defined later for the IP PSTN --> LGW --> Webex path.

voice class dpg 200

description Incoming IP PSTN(DP100) to BCLD(DP201)
dial-peer 200201 preference 1

Webex Calling Lab v4

58
Scenarios
Configuring SIP Profile

Step 8 Configure the following inbound dial-peers.

Local Gateway Inbound Dial-Peer Configuration
! - Inbound dial-peer for incoming IP PSTN call legs

dial-peer voice 100 voip

description 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

! - Inbound dial-peer for incoming Webex call legs, with the call destined for IP PSTN

dial-peer voice 200201 voip

description Inbound/Outbound Webex Calling
max-conn 150
destination dpg 100
incoming uri request 200

Step 9 That completes the local gateway configuration. Now you will save. Type end at the command prompt.
Step 10 To save, type copy run start and press Enter/Return twice.
Note To view all the local gateway configuration in one place, go to Appendix B.

Webex Calling Lab v4

59
 Scenarios
Active / Standby and Registration Show Command Verification

At this stage, the active CUBE should be registered as a Local Gateway to Webex Calling.

Active / Standby and Registration Show Command Verification

At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex
Calling access SBC.
Let's see the output of the following show commands:
show redundancy application group 1
show sip-ua register status

LocalGateway1#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

LocalGateway1#show sip-ua register status

LocalGateway1#

Webex Calling Lab v4

60
Scenarios
Active / Standby and Registration Show Command Verification

LocalGateway2#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: STANDBY

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

RF Domain: btob-one

RF state: ACTIVE

Peer RF state: STANDBY HOT

LocalGateway2#show sip-ua register status

Tenant: 200

--------------------- Registrar-Index 1---------------------

Line peer expires(sec) reg survival P-Associ-URI================================ =========

============ === ======== ============

Hussain8789_LGU -1 48 yes normal

LocalGateway2#

From the output above it can be seen that LocalGateway2 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
LocalGateway1.
Now enable the following debugs on LocalGateway1, currently our standby CUBE in this CUBE HA as
Local Gateway pair.

LocalGateway1#debug ccsip non-call

SIP Out-of-Dialog tracing is enabled

LocalGateway1#debug ccsip info

SIP Call info tracing is enabled

LocalGateway1#debug ccsip message

Simulate failover by issuing the following command on the active LGW, LocalGateway2 in this case.

LocalGateway2#redundancy application reload group 1 self

Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenarios as well besides the
CLI listed above.
• When the ACTIVE router reloads

Webex Calling Lab v4

61
 Scenarios
Active / Standby and Registration Show Command Verification

• When the ACTIVE router power cycles

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

Now check to see if LocalGateway1 has registered with Webex Calling access SBC. LocalGateway2 would
have reloaded by now.

LocalGateway1#show sip-ua register status

Tenant: 200

--------------------- Registrar-Index 1 ---------------------

Line peer expires(sec) reg survival P-Associ-URI

=============== ========= ============ === ======

Hussain8789_LGU -1 56 yes normal

LocalGateway1#

LocalGateway1 is now the active LGW. Let's look at the relevant debug log on LocalGateway1 sending a
SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.

Webex Calling Lab v4

62
Scenarios
Active / Standby and Registration Show Command Verification

LocalGateway1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Timer Expired.

Jan 9 18:37:24.771: %RG_PROTOCOL-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://- 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:Hussain8789_LGU@40462196.cisco-bcld.com;otg=hussain3350_lgu>;tag=8D573-189

To: <sip:Hussain8789_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:Hussain8789_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:Hussain8789_LGU@40462196.cisco-bcld.com;otg=hussain3350_lgu>;tag=8D573-189

To: <sip:Hussain8789_LGU@40462196.cisco-bcld.com>;tag=SDlu8bd99-1324701502-1578595045969

Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97

Timestamp: 1578595044

CSeq: 2 REGISTER

WWW-Authenticate: DIGEST
realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58z1iBW",algorithm=MD5

Content-Length: 0

Webex Calling Lab v4

63
 Scenarios
Active / Standby and Registration Show Command Verification

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:Hussain8789_LGU@40462196.cisco-bcld.com;otg=hussain3350_lgu>;tag=8D573-189

To: <sip:Hussain8789_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:Hussain8789_LGU@198.18.1.228:5061;transport=tls>

Expires: 240

Supported: path

Authorization: Digest
username="Hussain3350_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:Hussain8789_LGU@40462196.cisco-bcld.com;otg=hussain3350_lgu>;tag=8D573-189

To: <sip:Hussain8789_LGU@40462196.cisco-bcld.com>;tag=SDlu8bd99-1897486579-1578595046184

Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97

Timestamp: 1578595045

CSeq: 3 REGISTER

Contact: <sip:Hussain8789_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

Before testing the configuration, verify the Local Gateway also shows online in Control Hub.

Webex Calling Lab v4

64
 Scenarios
Call Routing Configuration

Procedure

Command or Action Purpose

Step 1 Go back to the Control Hub and log in if needed
(cholland@cbXXX.dc-YY.com / dCloud123!).
Step 2 Navigate to Services > Calling > Call Routing.
Step 3 Click the Hussain trunk.
Step 4 On the flyout window under Details, click
Manage.
Step 5 Status should read Online. After verifying the
status, click the X to close the window.

Call Routing Configuration

Before you begin
In the beginning when local gateway was introduced, call routing was very basic. If the user's number was
unknown to Webex, it would automatically forward to the local gateway for call handling. You can still choose
that type of routing using the legacy behavior. However, for lab purposes, let's configure a very basic dial
plan to get calls flowing. First, let's look at where to configure the routing behavior.

Procedure

Command or Action Purpose

Step 1 Navigate to the Calling page, if you aren't
there already.
Step 2 Click the Service Settings tab. Scroll down to As you can see, Standard behavior is selected
Call Routing between Webex Calling and by default, which is what we want. If you
premises section. wanted all unknown numbers to be forwarded
over, the trunk to the local gateway you would
choose Legacy behavior.
Feel free to expand Show Details under each
option to see more about each routing
preference.

Step 3 Click the Call Routing tab. Click Dial Plans.

Step 4 Click Create Dial Plan.
Step 5 Enter a name, such as On Premise.
Step 6 Use the Routing Choice drop-down menu and
choose your dCloud trunk.
Step 7 Enter the dial plan 60XX and press Enter.

Webex Calling Lab v4

65
 Scenarios
Call Routing Configuration

Command or Action Purpose

Step 8 This pattern matches the extensions of the
users on premise. You could also accomplish
this by configuring the setting on the Location
(Enable routing unknown extensions to the
Premises as internal calls).

Having this pattern or updating the Internal

Dialing setting will also allow your on-premise
users to be able to dial the extension of Webex
Calling users.
Next you will add +E.164 dialing for the
dCloud datacenter you are in.

Step 9 Enter the +E.164 as shown based on the Note DO NOT just configure these
location of your dCloud lab. route patterns in a production
environment! This is for lab
purposes only so you can quickly
test calling. You'll want a more
robust dial plan than the one you
are configuring in this lab.
• +1! : for US West (dc-05) or US East
(dc-01)
• +44! for EMEAR (dc-03)
• +65! for APJ (dc-02)
• +61! for SYD (dc-08)

Webex Calling Lab v4

66
 Scenarios
Local Gateway Testing

Command or Action Purpose

Step 10 Feel free to enter any other route patterns. The
ones above will be enough for lab testing.
Click Save when finished.

Local Gateway Testing

Now that you have a fully configured and registered Local Gateway, you can test calls to/from PSTN to your
Webex Calling endpoints or Cisco Webex Teams App.
As you have configured Dubber for the users in the above sections, any PSTN calls from those users will be
recorded using Dubber recording service.

Call from PSTN to MPP/Webex Teams App

Now you can test calls from/to the PSTN. The DID numbers to dial from the PSTN are located in your dCloud
Session Details tab. They are also located on the desktop of Workstation 1 in a text file named DN_to_DID.txt.

Procedure

Step 1 With the DID number, dial one of your users using a real cell or desk phone.
Step 2 Answer the call on your Webex. If Call Recording is enabled for the user, you will hear the recording beep.
Step 3 The call flow in dCloud is as follows:
a) Incoming DID comes into dCloud from IP PSTN.
b) Platform gateways translate that DID into a four-digit extension (6XXX or 7XXX).
c) Call is routed through the Local Gateway into Webex and to the extension of the user.

Call from MPP/Webex App to PSTN

In dCloud national, calls are allowed to the datacenter region your session is located in. US West/East
datacenters are dc-05 or dc-01. EMEAR datacenter is dc-03. APJ datacenter is dc-02.
In the US datacenters, you should be able to call any national number. Remember, since the location is built
for the United States, Webex will add a +1 to any dialed number, if needed. So a 10-digit number can be
called, or a 1 + 10 digit number.
Dialing from an EMEAR or APJ session will be just a little different than US. Every session, no matter the
datacenter, the Webex Calling location is built for United States. Because of this, in the lab, dialing a national
number for the UK (EMEAR) or Singapore (APJ) requires you to dial an +E.164, so + Country Code and
then the number (10-digit for UK and 8-digit for Singapore). For the EMEAR datacenter, the country code
is 44. For the APJ datacenter, the country code is 65.
The call flow for EMEAR and APJ sessions in Unified CM is as follows:
• Call comes into Local Gateway, sent to dCloud Gateway, which delivers it to the IP PSTN.
• The +E.164 number is now routed by the IP PSTN and rings the PSTN number.

Webex Calling Lab v4

67
 Scenarios
Local Gateway Voice Translation to Remove Steering Digit ‘9’ for External Calls

Procedure

Step 1 With the dialing explanation above, dial a PSTN number. If Call recording is enabled you will hear the
recording beep.
Step 2 Answer the call.
Note You'll notice the incoming caller ID number will begin with a 919, 408, 44, or 64 number
(depending on the session's datacenter). This is expected due to the way the dCloud PSTN is set
up. The caller ID will always show as the DID assigned to the session that maps to the 7800 DN.

Step 3 End the call.

Local Gateway Voice Translation to Remove Steering Digit ‘9’ for External
Calls
When Webex Calling sends the calls to the Local gateway, as of writing this lab guide, it does not strip out
the steering digit. Hence, we will need to write a voice translation rule on the Local Gateway to strip out ‘9’,
the steering digit we have defined earlier. Proceed as shown below on both the Local Gateways:
configure terminal
voice translation-rule 101
rule 1 /^9\(.*\)/ /\1/
!
voice translation-profile StripSteeringDigit
translate called 101
!
dial-peer voice 101 voip
translation-profile outgoing StripSteeringDigit
end

Webex Calling Lab v4

68
 Scenarios
Local Gateway Debugging

You can now test external calls with the steering digit. Dial 9 plus the rest of the PSTN number to get an
outside line and then the numbering pattern as defined in the previous section.

Local Gateway Debugging

To troubleshoot call setup failures on the Local Gateway, proceed as shown below.
! - Collecting debugs in Local Gateway's logging buffer
-----------------------------------------------------------------
conf t
no logging console
no logging monitor
service timestamps debug datetime msec
logging buffered 9999999 debugging
service sequence-numbers
no logging rate-limit
exit

! - The following debugs will assist in troubleshooting call failures for this lab:

"debug ccsip message"

"debug voip ccapi inout"

You can view the debugs by issuing the "show log" command.

Webex Calling Lab v4

69
 Scenarios
Local Gateway Debugging

Webex Calling Lab v4

70
 CHAPTER 4
Appendix
• Full Local Gateway Configuration, on page 71

Full Local Gateway Configuration

The following is the full configuration that was completed in the lab of the Local Gateway for reference. (You
cannot modify this in the current lab.) Remember, the items in red are places that you need your own lab's
configuration. The figure below was used to create the config.
! LOCAL GATEWAY CONFIGURATION TEMPLATE
!-------------------------------------
! HUSSAIN SHOAIB ALI
! TECHNICAL MARKETING ENGINEER
! https://cisco.box.com/WebexCalling
! ASK-CUBE@EXTERNAL.CISCO.COM
! UPDATED : FEBRUARY 2020
!-------------------------------------

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! This template is for building a LGW (on a vCUBE) deployment not involving CUCM!
! Verify LGW interfaces for dial-peer bind statements based on your network !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! This configuration template can be used for both Customer site !
! or partner hosted LGW deployments !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!! IOS-XE 16.12.2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!%%%%%%% BEGIN

configure terminal
key config-key password-encrypt Password123
password encryption aes
!
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

Webex Calling Lab v4

71
 Appendix
Full Local Gateway Configuration

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

configure terminal
voice service voip
ip address trusted list
!! Verify updated trust list from the Webex Calling Config Guide!!
ipv4 85.119.56.128 255.255.255.192
ipv4 85.119.57.128 255.255.255.192
ipv4 185.115.196.0 255.255.255.128
ipv4 185.115.197.0 255.255.255.128
ipv4 128.177.14.0 255.255.255.128
ipv4 128.177.36.0 255.255.255.192
ipv4 135.84.169.0 255.255.255.128
ipv4 135.84.170.0 255.255.255.128
ipv4 135.84.171.0 255.255.255.128
ipv4 135.84.172.0 255.255.255.192
ipv4 199.59.64.0 255.255.255.128
ipv4 199.59.65.0 255.255.255.128
ipv4 199.59.66.0 255.255.255.128
ipv4 199.59.67.0 255.255.255.128
ipv4 199.59.70.0 255.255.255.128
ipv4 199.59.71.0 255.255.255.128
ipv4 139.177.64.0 255.255.255.0
ipv4 139.177.65.0 255.255.255.0
ipv4 139.177.66.0 255.255.255.0
ipv4 139.177.67.0 255.255.255.0
ipv4 139.177.68.0 255.255.255.0
ipv4 139.177.69.0 255.255.255.0
ipv4 139.177.70.0 255.255.255.0
ipv4 139.177.71.0 255.255.255.0
ipv4 139.177.72.0 255.255.255.0
ipv4 139.177.73.0 255.255.255.0
ipv4 23.89.76.128 255.255.255.128
ipv4 170.72.29.0 255.255.255.0
ipv4 170.72.17.128 255.255.255.128
ipv4 170.72.0.128 255.255.255.128
exit
allow-connections sip to sip
media statistics
media bulk-stats
no supplementary-service sip refer
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
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"

Webex Calling Lab v4

72
Appendix
Full Local Gateway Configuration

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=hussain_3350>"
rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

voice class codec 99

codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8
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.hussain_3350com scheme sips expires 240 refresh-ratio
50 tcp tls
credentials number Hussain8789_LGU username Hussain3350_LGU password 0 bjljJ2VQji realm
BroadWorks
authentication username Hussain3350_LGU password 0 bjljJ2VQji realm BroadWorks
authentication username Hussain3350_LGU password 0 bjljJ2VQji 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

!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
!! REPLACE A.B.C.D with ITSP's IP Address %
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
voice class uri 100 sip
host ipv4:198.18.133.3

Webex Calling Lab v4

73
 Appendix
Full Local Gateway Configuration

voice class uri 200 sip

pattern dtg=hussain3350.lgu

dial-peer voice 101 voip

description Outgoing dial-peer to IP PSTN
destination-pattern BAD.BAD
session protocol sipv2
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
!! REPLACE A.B.C.D with ITSP's IP Address %
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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 WxC(DP200) to IP PSTN(DP101)
dial-peer 101 preference 1

voice class dpg 200

description Incoming IP PSTN(DP100) to WxC(DP201)
dial-peer 201 preference 1

dial-peer voice 100 voip

description 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

Webex Calling Lab v4

74
Appendix
Full Local Gateway Configuration

no vad

end
copy run start

!!%%%%% END-TEMPLATE

Webex Calling Lab v4

75
 Appendix
Full Local Gateway Configuration

Webex Calling Lab v4

76
 CHAPTER 5
What's Next?
• What’s Next?, on page 77

What’s Next?
For more product and sales information, please reference the SalesConnect Hubs for Cisco Webex Calling
and Cisco Collaboration Flex Plan.

Webex Calling Lab v4

77
 What's Next?
What’s Next?

Webex Calling Lab v4

78