CiscoPress - CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide

CCNP Collaboration Call
Control and Mobility

CLACCM 300-815 Official
Cert Guide
Kyzer Davis, CCIE No. 54735

Paul Giralt, CCIE No. 4793
Patrick Kinane, CCIE No. 58284
Gonzalo Salgueiro, CCIE No. 4541
CCNP Collaboration Call Control and
Mobility CLACCM 300-815 Official Cert
Guide
Kyzer Davis, Paul Giralt, Patrick Kinane, Gonzalo

Salgueiro
Copyright © 2021 Cisco Systems, Inc.
Published by:
Cisco Press
Hoboken, NJ
All rights reserved. No part of this book may be

reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying,
recording, or by any information storage and retrieval
system, without written permission from the publisher,
except for the inclusion of brief quotations in a review.
ScoutAutomatedPrintCode
Library of Congress Control Number: 2020945984
ISBN-13: 978-0-13-657554-2
ISBN-10: 0-13-657554-4
Warning and Disclaimer
This book is designed to provide information about the

CCNP Implementing Cisco Advanced Call Control and
Mobility Services (CLACCM) 300-815 exam. Every effort
has been made to make this book as complete and as
accurate as possible, but no warranty or fitness is
implied.
The information is provided on an “as is” basis. The

authors, Cisco Press, and Cisco Systems, Inc. shall have
neither liability nor responsibility to any person or entity
with respect to any loss or damages arising from the
information contained in this book or from the use of the
discs or programs that may accompany it.
The opinions expressed in this book belong to the author

and are not necessarily those of Cisco Systems, Inc.
Trademark Acknowledgments
All terms mentioned in this book that are known to be

trademarks or service marks have been appropriately
capitalized. Cisco Press or Cisco Systems, Inc., cannot
attest to the accuracy of this information. Use of a term
in this book should not be regarded as affecting the
validity of any trademark or service mark.
Special Sales
For information about buying this title in bulk quantities,

or for special sales opportunities (which may include
electronic versions; custom cover designs; and content
particular to your business, training goals, marketing
focus, or branding interests), please contact our
corporate sales department at corpsales@pearsoned.com
or (800) 382-3419.
For government sales inquiries, please contact

governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact

intlcs@pearson.com.
Feedback Information
At Cisco Press, our goal is to create in-depth technical

books of the highest quality and value. Each book is
crafted with care and precision, undergoing rigorous
development that involves the unique expertise of
members from the professional technical community.
Readers' feedback is a natural continuation of this

process. If you have any comments regarding how we
could improve the quality of this book, or otherwise alter
it to better suit your needs, you can contact us through
email at feedback@ciscopress.com. Please make sure to
include the book title and ISBN in your message.
We greatly appreciate your assistance.
Editor-in-Chief
Mark Taub
Alliances Manager, Cisco Press

Arezou Gol
Director, ITP Product Management

Brett Bartow
Acquisition Editor
Nancy Davis
Managing Editor
Sandra Schroeder
Development Editor
Ellie Bru
Senior Project Editor

Tonya Simpson
Copy Editor
Kitty Wilson
Technical Editor(s)
Michael Mendoza Guzman, Esteban Valverde
Editorial Assistant
Cindy Teeters
Cover Designer
Chuti Prasertsith
Composition
Indexer
Proofreader
About the Authors
Kyzer Davis, CCIE Collaboration No. 54735, is an
escalation point for various worldwide cloud and
collaboration teams within Cisco Systems. He is the focal
point for supporting, troubleshooting, and resolving
complex, solution-level problems involving voice, video,
cloud, and security portions of the Cisco Unified
collaboration product portfolio. In addition to his work
on this book, Kyzer has authored and presented
numerous technical white papers on Cisco collaboration
configuration, architecture, protocol design, and security
topics, many of which are leveraged by Cisco partners,
Cisco exam instructors, and Cisco employees for training
and education.
Prior to writing this book, Kyzer co-authored the Cisco

Press publication Understanding Session Border
Controllers: Comprehensive Guide to Designing,
Deploying, Troubleshooting, and Maintaining Cisco
Unified Border Element (CUBE) Solutions. In addition,
he works with Learning@Cisco on strategy and content
development for numerous Cisco certifications. Kyzer is
a technology enthusiast and mentor who is always
working on automation initiatives and dabbling in new
and evolving technology. He also enjoys a mean
barbecue.
Paul Giralt, CCIE R&S, CCIE Voice, CCIE

Collaboration No. 4793, is a distinguished engineer
in the Customer Experience organization, where he
focuses on Cisco collaboration technologies. He spends
much of his time helping Cisco's largest customers
accelerate the adoption of Cisco technologies and
solutions and building new services capabilities to
provide more proactive and predictive services as well as
improve product serviceability. Paul has spent his 22+-
year career at Cisco in TAC, the Collaboration
Technology Group, Solution Validation Services, Cisco
Advanced Services, and, most recently, as part of the
Customer Experience organization. Paul has spent years
troubleshooting and diagnosing issues on some of the
largest and most complex Cisco collaboration
deployments. He is passionate about the intersection of
programmability and Cisco collaboration products as
well as giving customers the knowledge and tools they
need to diagnose issues on their own.
Paul is the author of the classic Cisco Press title

Troubleshooting Cisco IP Telephony and is well known
for his Cisco Live! sessions on SIP, collaboration APIs,
troubleshooting Cisco collaboration, and other topics
related to Cisco collaboration, making him a member of
the Cisco Live! Distinguished Speaker Hall of Fame Elite.
He is also the creator of the TranslatorX tool, which is
used across the Cisco collaboration industry, as well as a
contributor to SIP standards in the IETF. Paul has a
degree in computer engineering from the University of
Miami.
Patrick Kinane, CCIE Collaboration No. 58284, is

a senior engineer and escalation point for the worldwide
Cisco Unified Communications Manager teams within
Cisco Technical Assistance Center (TAC). He is a subject
matter expert (SME) for Cisco collaboration products
such as Cisco Unified Communications Manager, Cisco
collaboration endpoints, Cisco Paging Server, and Cisco
Emergency Responder. Patrick can be found on the
following social media sites:
YouTube: https://www.youtube.com/patrick_kinane1
Twitter: https://twitter.com/patrick__k9
LinkedIn:
https://www.linkedin.com/in/patrickkinane/
Gonzalo Salgueiro, CCIE No. 4541, is a

distinguished engineer at Cisco working in the Customer
Experience Technology Office (CXTO) helping to shape
technical and organizational strategies, leading
innovation and automation initiatives, and driving
engineering excellence. Gonzalo has spent 23+ years at
Cisco, establishing himself as a subject matter expert, an
innovator, and an industry thought leader in various
technologies, including collaboration, cloud, and IoT.
Gonzalo is an established member of numerous industry

organizations and is a regular presenter and
distinguished speaker at a variety of technical industry
conferences and Cisco events around the world. He has
held various industry leadership roles, including serving
as a member of the board of directors of the SIP Forum,
co-chair of the ASAP, INSIPID, and SIPBRANDY IETF
working groups, a member of the IoT Directorate in the
IETF, and co-chair of the WebRTC Task Group, IPv6
Task Group, and FoIP Task Group in the SIP Forum. He
is an active contributor to various industry organizations
and standardization activities.
Gonzalo previously co-authored three Cisco Press books

on IoT and collaboration technologies. He has also co-
authored 25 IETF RFCs, 4 IEEE papers, 4 ITU
contributions, and numerous industry and academic
research papers on a variety of different technical topics.
He is also co-inventor of 120+ patents (issued and
pending) and has contributed to various interop and
open source development efforts. Gonzalo received a
master’s degree in physics from the University of Miami.
Note
In addition to all the authors on this book holding a CCIE-level certification,
both Kyzer Davis and Patrick Kinane hold a CCNP Specialist Certification for
the concentration exam Implementing Cisco Advanced Call Control and
Mobility Services (CLACCM) 300-815.
About the Technical Reviewers
Esteban Valverde, CCIE No. 34305, is a Cisco
technical leader with 14 years of experience in
networking and software development. In his current
role, he is part of the Cisco collaboration team of the
Technical Assistance Center (TAC) in Research Triangle
Park, North Carolina. His main focus is working with
customers and Cisco support engineers on escalations
that involve Cisco Unified Border Element (CUBE), fax
and modems, Cisco Unified Communications Manager,
and Unified Contact Center Enterprise Deployments, as
well as working closely with the Cisco Engineering team
to enhance product serviceability and automating
common troubleshooting tasks. During the past years, he
has specialized in troubleshooting complex issues for
some of the largest VoIP networks and has provided
technical leadership for some of the most critical
worldwide collaboration deployments. Esteban has
developed and delivered all levels of training and
documentation on the Cisco Unified Border Element to
Cisco technical teams. He holds a bachelor’s degree in
systems engineering.
Michael Mendoza, CCIE No. 34300, is based in

Cisco's Research Triangle Park, North Carolina, office.
He has worked on Unified Collaboration technologies for
12 years as part of the Multiservice (MS) and the Unified
Communication Manager Technical Assistance Center
(TAC) teams. In his current role as a technical leader
within TAC, he is responsible for an escalation point as
well as a point of contact for any technical support topics
between TAC and the Cisco engineering team for
multiple unified collaboration products. Michael's areas
of expertise include Cisco Unified Communications
Manager, endpoints, Cisco Emergency Responder, voice
gateways, Cisco Unified Border Element (CUBE), and
more. Michael is a seasoned Cisco Live! speaker and is
heavily involved in automation, software development,
and innovation projects; he is always striving to find new
ways to make the lives of TAC engineers supporting
Cisco customers globally easier.
Dedications
To my parents and grandparents, for encouraging me to
always ask questions, explore new ideas, and expand my
horizons by continuously striving to learn new topics
throughout my career in information technology.
Without their wisdom and guidance, I would not be
where I am today.—Kyzer
To my beautiful wife, who has always supported me and

our family. Each time I work on a project, she takes on
more of the tasks at home (especially when I was chasing
the CCIE), and I appreciate all she does. To my amazing
children, who help motivate me to be a better version of
myself. To my parents, siblings, and extended family who
all helped me grow up to be the man I am today: I love
each of you very much.
Last, but not least, to all the people who’ve made the
Cisco collaboration content and from whom I’ve learned
over the years. Here is a short list: Vik Malhi, Mark
Snow, Kevin Wallace, Paul Giralt, Jeremy Cioara, Andy
Vassar, Ralph Smith III, and Network Chuck.—Patrick
This book is affectionately dedicated to my family.
To my brilliant and beautiful wife, Becky, whose infinite

patience and steadfast love, friendship, and support have
been the inspirational driving force in my life.
To our wonderful children, Alejandro, Sofia, Gabriela,

and Mateo, who have given me the greatest joy and have
loved me unconditionally and without question all the
days of their lives. It's hard to put into words how much I
love all of you and how proud I am to be your father.
Finally, I dedicate this book to my parents, Alberto and
Elena, who have given me so much for so long. I know
that I will never be able to repay the lifetime of kindness,
encouragement, and learning. Please know that I walk in
your footsteps, knowing full well that the amazing life
that I lead is only possible because of you.—Gonazalo
Acknowledgments
From Kyzer Davis: A big hearty thank you to the rest
of the author team for contributing to this publication
and sharing their in-depth knowledge surrounding the
various components, products, and protocols that make
up the Cisco Unified collaboration product portfolio.
A smaller personal thank you to Joseph House,

Mohammad Manna, Dillon Brown, Irina Hristova,
Daniel Alejandro Alvarado Vega, Tim Thurber, Joshua
Raja, Julio Cascante, Matt Gross, Scott Kiewert, Donald
Hohenstein, Matt Taber, Hazel Pringle, Luis Gonzalez
Galindo, Josh Meadows, Kyle West, Chris Enterline,
Jared Compiano, Christopher Hsu, and Lyle Gardner for
reviewing the chapters of this book at various stages
during publication and providing valuable feedback on
topic comprehension, structure, and flow.
From Patrick Kinane: Thank you to all the other

authors, but especially Kyzer. I know Kyzer put a
significant amount of time into this book on chapters he
authored as well as the others. A big thank you to our
technical editors, the people who read the chapters to
provide feedback, and Cisco Press.
Thank you to the TLs, PEs, DSEs, and managers within

the collaboration TAC community for always being
excited about the projects TAC engineers are taking on.
Thank you for encouraging us along the way and for your
continued guidance.
From Gonzalo Salgueiro: Thanks to all my co-

authors for their dedication and passion for making this
book a reality. Special thanks to Kyzer Davis for inviting
me to contribute to this incredibly worthwhile endeavor.
This is the second book we've worked on together, and
seeing your growth as an engineer and a leader makes
me proud.
Thanks to my management and leadership teams for

their unwavering encouragement, belief, and support
throughout this project. A nostalgic note of thanks to
Marty Martinez, Marc Holloman, and Tom Berghoff for
their friendship, their guidance, and the indelible
impressions of leadership they imparted.
Thanks to all the technical editors and reviewers who

have helped improve this manuscript. Emphatic thanks
to Esteban Valverde and Michael Mendoza for the careful
and thorough review of all the chapters to ensure that the
content is technically accurate, useful, and easily
consumable. This book is better because of Kaustubh
Inamdar and his exceptional work on our recently
published SBC book. I am immensely grateful to
Kaustubh for his technical contributions and leadership.
A hearty thanks to all the customers, developers,

engineers, and technical writers with whom I have
collaborated and co-innovated with during my many
years at Cisco. Your generosity and willingness to share
have made me a better engineer and have made projects
like this book so rewarding.
Finally, thank you to everyone at Cisco Press for all the

support with everything that happens after the technical
words hit the page. We are grateful for all your efforts in
making us look good! Special thanks to our development
editor, Ellie Bru, who is a shining example of patience,
professionalism, and excellence. This our fourth book
together, and I'm looking forward to many more.
Contents at a Glance
Introduction
1 Introduction to Unified Collaboration and Dial

Plans
2 VoIP Protocols: SIP and H.323
3 VoIP Protocols: RTP, RTCP, and DTMF Relay
4 Unified CM Call Routing and Digit

Manipulation
5 Unified CM SIP Trunk Configuration
6 Unified CM Call Control Features
7 Unified CM Mobility
8 CUBE Call Routing and Digit Manipulation
9 CUBE Interworking Features
10 Unified CME and SRST
11 Final Preparation
A Answers to the “Do I Know This Already?”

Quiz Questions
B CCNP Implementing Cisco Advanced Call

Control and Mobility Services CLACCM 300-815
Exam Updates
Online Elements
C Memory Tables
D Memory Tables Answer Key
E Study Planner
Glossary
Reader Services
Other Features
In addition to the features in each of the core chapters,

this book has additional study resources on the
companion website, including the following:
Practice exams: The companion website contains an

exam engine that enables you to review practice exam
questions. Use these to prepare with a sample exam and
to pinpoint topics where you need more study.
Interactive exercises and quizzes: The companion

website contains interactive hands-on exercises and
quizzes so that you can test your knowledge on the spot.
Glossary quizzes: The companion website contains

interactive quizzes that enable you to test yourself on
every glossary term in the book.
To access this additional content, simply register your

product. To start the registration process, go to
www.ciscopress.com/register and log in or create an
account*. Enter the product ISBN 9780136575542 and
click Submit. After the process is complete, you will find
any available bonus content under Registered Products.
*Be sure to check the box that you would like to hear from us to receive
exclusive discounts on future editions of this product.
Contents
Introduction
Goals and Methods
Who Should Read This Book?

Strategies for Exam Preparation
The Companion Website for Online Content

Review
How to Access the Pearson Test Prep Practice
Test Software
How This Book Is Organized

Exam Topics
Chapter 1. Introduction to Unified Collaboration

and Dial Plans
“Do I Know This Already?” Quiz
Foundation Topics
Introduction to Cisco Unified Collaboration
Components
Unified CM
Cisco Unified Border Element
Unified CME and Unified SRST

Dial Plan Design Overview
Why Dial Plan Design Is Difficult
North American Numbering Plan (NANP)

International Dial Plans with E.164
Case Study: Building a Globalized Dial Plan

References
Exam Preparation Tasks
Review All Key Topics
Complete Tables and Lists from Memory

Define Key Terms
Chapter 2. VoIP Protocols: SIP and H.323

Foundation Topics
Overview of SIP
Brief Introduction to and History of SIP

SIP Methods
Breaking Down a SIP Call

Analyzing a Basic SIP Call
Introduction to SDP
The Offer/Answer Framework
Operation of the Offer/Answer Framework

Overview of H.323
H.323 Components
H.323 Call Flow
References

Define Key Terms
Chapter 3. VoIP Protocols: RTP, RTCP, and

DTMF Relay

Foundation Topics
Introduction to Real-Time Media

Real-Time Transport Protocol
Real-Time Transport Control Protocol
DTMF Relay
Introduction to DTMF Relay
Variants of DTMF Relay

References


Define Key Terms
Chapter 4. Unified CM Call Routing and Digit

Manipulation
Foundation Topics
Pattern Matching
Numeric Matching
Closest-Match Routing
Digit-by-Digit Versus Enbloc Calling

Alphanumeric URI Dialing
Transformations and Masks

Digit Discard Instructions
Transform Masks
Prefix Digits
Combining Transformations
Pattern Configuration and Device Selection
Directory Numbers
Route Patterns, Route Lists, and Route
Groups
Local Route Group

Hunt Pilots, Hunt Lists, and Line Groups
Partitions and Calling Search Spaces
Time of Day Routing

Translation Patterns
Transformation Patterns
Putting It All Together: Tail-End Hop Off
(TEHO)
Alphanumeric URI Routing

Intercluster Dial Plan Replication
Intercluster Lookup Service (ILS)

Global Dial Plan Replication
Troubleshooting Call Routing and Digit

Manipulation
Dialed Number Analyzer
Real-Time Monitoring Tool

Troubleshooting Call Routing by Using SDL
Trace Files


Define Key Terms
Chapter 5. Unified CM SIP Trunk Configuration

Foundation Topics
SIP Trunk Overview and Configuration
SIP Trunk Configuration

SIP Trunk Security Profile Configuration
SIP Profile Information Configurations

SIP Trunk Features
SIP Early Offer Versus SIP Delayed Offer
SIP OPTIONS Ping
Media Termination Point Required

Run On All Active Unified CM Nodes
Verify and Troubleshoot Unified CM SIP Trunks

Packet Captures (PCAPs)
OPTIONS Ping
Changing Transport Types
CallManager SDL Traces

Reset the Trunk
References

Define Key Terms
Chapter 6. Unified CM Call Control Features

Foundation Topics
Media Resources
Ad Hoc and Meet-Me Conferencing
Music on Hold (MOH)

Media Resource Groups and Media Resource
Group Lists
Call Park
Call Pickup
Regions and Codec Preferences

Regions
Audio Codec Preference Lists

Configure Interregion and Intraregion
Policies
Call Admission Control (CAC)
Location Bandwidth Manager Service

Configure Enhanced Location Call
Admission Control (ELCAC)
Automated Alternate Routing (AAR)

Troubleshooting and Monitoring Enhanced
Location Call Admission Control


Define Key Terms
Chapter 7. Unified CM Mobility

Foundation Topics
Unified Mobility
Configure and Verify Single Number Reach

Advanced Single Number Reach
Configuration
Troubleshoot Single Number Reach

Configure and Verify Move to Mobile
Troubleshoot Move to Mobile

Configure and Verify Extension Mobility
Troubleshoot Extension Mobility

Configure and Verify Device Mobility
Troubleshoot Device Mobility

References

Define Key Terms
Chapter 8. CUBE Call Routing and Digit

Manipulation
Foundation Topics
Understanding Call Legs and Call Flows
IOS Dial Peers

Inbound Dial Peer Matching
Outbound Dial Peer Matching

Dial Peer Aggregation and Summarization
Techniques
Advanced Call Routing Techniques

Verify and Troubleshoot IOS Call Routing
Basic CUBE Call Routing Debug Analysis

Application Signaling and Media Binding
Digit, Header, and URI Manipulation

Digit Manipulation
SIP Header Interworking

SIP Normalization
SIP Profile Configuration

Outbound SIP Profiles
Inbound SIP Profiles

SIP Copylist
Common SIP Profiles

Troubleshooting SIP Profiles
References

Define Key Terms
Chapter 9. CUBE Interworking Features

Foundation Topics
SIP–SIP Interworking
Early Offer and Delayed Offer Interworking

Reliable Handling and Interworking of
Provisional Responses
Ringback and Provisional Response

Interworking
Mid-call Signaling
Hold/Resume
Call Transfer
UPDATE Interworking
Session Refresh
Managing Mid-call Signaling

SIP Authentication with CUBE
Toll Fraud Prevention

SIP Trunk Registration
SIP Digest Authentication

SIP Header–Based Authentication
Media Interworking
Audio Codec Interworking
Video Interworking and Suppression

Media Flow-Through Versus Media Flow-
Around
Music on Hold
DTMF Interworking
Troubleshooting CUBE Media
Other CUBE Features
References

Define Key Terms
Chapter 10. Unified CME and SRST

Foundation Topics
Introduction to Unified CME and Unified SRST

Unified CME Initial Configuration
SIP Phone Manual Registration

Unified CME IP Phone Registration
Overview
SIP Phone Auto-Registration

Unified CME Dial Design
Unified CME Virtual Dial Peers

Unified CME SIP Trunking
Unified CME Call Coverage Features

Configure Unified CME Hunt Groups
Configure Unified CME Multicast Paging

Configure Unified CME Call Park
Survivable Remote Site Telephony (Unified

SRST)
Implement SIP Unified SRST on Unified CM
Implement SIP Unified SRST on an IOS

Gateway
Verify and Troubleshoot SIP Unified SRST
Failover
References

Define Key Terms
Chapter 11. Final Preparation
Getting Ready
Tools for Final Preparation
Pearson Cert Practice Test Engine and

Questions on the Website
Customizing Your Exams
Updating Your Exams

Premium Edition
Chapter-Ending Review Tools

Suggested Plan for Final Review/Study
Summary
Appendix A. Answers to the “Do I Know This

Already?” Questions
Appendix B. CCNP Implementing Cisco

Advanced Call Control and Mobility Services
CLACCM 300-815 Exam Updates
Online Elements
Appendix C. Memory Tables
Appendix D. Memory Tables Answer Key
Appendix E. Study Planner
Glossary
Icons Used in This Book
Command Syntax Conventions
The conventions used to present command syntax in this
book are the same conventions used in the IOS
Command Reference. The Command Reference
describes these conventions as follows:
• Boldface indicates commands and keywords that

are entered literally as shown. In actual
configuration examples and output (not general
command syntax), boldface indicates commands
that are manually input by the user (such as a
show command).
• Italic indicates arguments for which you supply

actual values.
• Vertical bars (|) separate alternative, mutually

exclusive elements.
• Square brackets ([ ]) indicate an optional element.
• Braces ({ }) indicate a required choice.
• Braces within brackets ([{ }]) indicate a required

choice within an optional element.
Introduction
With the recent changes to the Cisco exam certifications,
a professional-level certification is now more accessible
than ever before. Within each Cisco Certified Network
Professional (CCNP) track there now exists a single core
exam and multiple concentration exams. To obtain a full
CCNP Collaboration certification, one must pass the core
exam and one concentration exam of choice within the
CCNP Collaboration track. There are no longer CCNA
prerequisites for the CCNP-level exams, and the CCNP
concentration exams can be taken as standalone exams.
For CCNP concentration exams, upon successful
completion, a specialist certification is awarded. This
added flexibility means that aspiring network engineers
can tailor their learning and study habits specifically to
what is directly required by their current position,
company, or desired subject area. Furthermore, the core
exam for each CCNP track now stands as the qualifying
exam for the CCIE practical lab. Cisco professional
certifications will continue to be an important part of the
computing industry for many years to come.
GOALS AND METHODS

The primary goal of this book is to help you pass the
CLACCM (300-815) exam. With that in mind, we wanted
to provide a Cisco Press publication that goes beyond
what the exam blueprint details. After all, call routing
and device mobility are very large parts of any Cisco
Unified Communications network engineer’s day-to-day
operations. As you continue your Cisco collaboration
journey, you will see that the topics covered in this book
are relevant to many other features and integrations in
the Cisco Unified CM product portfolio. This book is
filled with Cisco best practices and deep dives into topics
that will help network engineers day in and day out. This
book has been written to a level that is accessible to a
newcomer but continues to a level of knowledge that
justifies keeping this book around as a reference even
after you have passed your CCNP certification exam.
This book does not ask you to simply memorize topics in

order to pass the exam. Instead, it explores the topics
fully to provide a complete understanding of the subject
at hand. We know that not every reader will be able to
get hands-on lab experience before taking the exam. We
therefore provide many hand-crafted figures illustrating
scenarios and UI components. We also provide real-
world relevant examples of output from CLI show
commands, CLI debug commands, and trace/log files
that are annotated and discussed at length within the
text. These log examples serve two purposes. First, these
examples help drive home the topics covered through
actual call samples and log analysis. Second, these
examples help you become familiar with some of the
relevant snippets from working logs that you will one day
leverage for on-the-job troubleshooting.
WHO SHOULD READ THIS BOOK?

This book is written for Cisco collaboration engineers
who want to tremendously increase their chances of
passing the CLACCM (300-815) CCNP Collaboration
concentration exam. Whether you are taking this exam
as a standalone exam for the specialist certification, as
part of a larger CCNP Collaboration journey, or even as
part of a CCIE Collaboration journey, you can use this
book to learn the information you need to know along
with the technical depth required to implement,
administer, and troubleshoot in real-world scenarios.
STRATEGIES FOR EXAM
PREPARATION
There is no blanket strategy for exam preparation or for
taking Cisco exams. The strategy you use depends on
your level of existing knowledge about the topics at hand.
For example, somebody who has been working with
collaboration products for a few years might need to
simply skim through the VoIP protocols chapters
because on-the-job training and experience have
provided a great foundation. Those who are new to the
topics should review the VoIP protocols a few times to
gain a full understanding of the topics described there.
We highly encourage you not to entirely omit any topic
area from your studies. Each chapter provides notes,
tidbits, and information that might be new to you, and
you may even learn about things you didn’t know are
possible.
Regardless of the strategy you use or the background you

have, this book is designed to help you pass the exam in
the least amount of time. Several book features will help
you gain the confidence you need to be convinced that
you know some material already and to also help you
determine what topics you need to study more.
THE COMPANION WEBSITE FOR

ONLINE CONTENT REVIEW
All the electronic review elements, as well as other
electronic components of the book, exist on this book’s
companion website. To access the companion website,
start by establishing a login at www.ciscopress.com and
registering your book. To do so, simply go to
www.ciscopress.com/register and enter the ISBN of the
print book: 9780136575542. After you have registered
your book, go to your account page and click the
Registered Products tab. From there, click the Access
Bonus Content link to get access to the book’s companion
website.
Note that if you buy the Premium edition eBook and

Practice Test version of this book from Cisco Press, your
book will automatically be registered on your account
page. Simply go to your account page, click the
Registered Products tab, and select Access Bonus
Content to access the book’s companion website.
HOW TO ACCESS THE PEARSON TEST

PREP PRACTICE TEST SOFTWARE
You have two options for installing and using the
Pearson Test Prep practice test software: a web app and a
desktop app. To use the Pearson Test Prep application,
start by finding the access code that comes with the book.
You can find the code in these ways:
• Print book: Look in the cardboard sleeve in the

back of the book for a piece of paper with your
book’s unique access code.
• Premium edition: If you purchase the Premium

edition eBook and Practice Test directly from the
Cisco Press website, the code will be populated on
your account page after purchase. Just log in at
www.ciscopress.com, click Account to see details of
your account, and click the Digital Purchases tab.
• Amazon Kindle: For those who purchase a

Kindle edition from Amazon, the access code will
be supplied directly by Amazon.
• Other bookseller eBooks: Note that if you

purchase an eBook version from any other source,
the practice test is not included because other
vendors to date have not chosen to vend the
required unique access code.
Note
Do not lose the access code because it is the only means with which you can
access the QA content with the book.
Once you have the access code, to find instructions about

both the Pearson Test Prep web app and the desktop app,
follow these steps:
Step 1. Open this book’s companion website.
Step 2. Click the Practice Exams button.
Step 3. Follow the instructions listed there for

installing the desktop app and for using the
web app.
If you want to use the web app only at this point, just
navigate to www.pearsontestprep.com, establish a free
login if you do not already have one, and register this
book’s practice tests using the access code you just
found. The process should take only a couple of minutes.
Note
Amazon eBook (Kindle) customers: It is easy to miss Amazon’s email that lists
your Pearson Test Prep access code. Soon after you purchase the Kindle
eBook, Amazon should send an email. However, the email uses very generic
text and makes no specific mention of PTP or practice exams. To find your
code, read every email from Amazon after you purchase the book. Also do the
usual checks for ensuring your email arrives, like checking your spam folder.
Note
Other eBook customers: As of the time of publication, only the publisher and
Amazon supply Pearson Test Prep access codes when you purchase their
eBook editions of this book.
HOW THIS BOOK IS ORGANIZED

Although this book can be read cover-to-cover, it is
designed to be flexible and allow you to easily move
between chapters and sections of chapters to read just
the material that you need to get to know better. Where
required, forward and reverse references are included to
extend and tie topics into large discussions.
At first glance, the chapters may seem long—and some of

them are—but the book needs to fully explore the topics
at hand. No expense was spared in terms of the content
covered for each topic. Because there is no CCNA
prerequisite for this exam, the content of this book both
provides introductory knowledge and builds on that
foundation by discussing the intermediate to advanced
topics related to each blueprint item.
The following list provides an at-a-glance summary of

the chapters:
• Chapter 1, “Introduction to Unified

Collaboration and Dial Plans”: This chapter
provides a crash course in Cisco Unified CM
architecture, components, and products. In
addition, it features a discussion about dial plan
design, using a globalized dial plan as an example.
• Chapter 2, “VoIP Protocols: SIP and H.323”:

This chapter provides a vendor-neutral protocol
analysis of the Session Initiation Protocol (SIP),
Session Description Protocol (SDP), and H.323
components such as H.225 and H.245. The
foundational contents of this chapter is leveraged in
many other chapters throughout the book.
• Chapter 3, “VoIP Protocols: RTP, RTCP, and

DTMF Relay”: This chapter discusses the
protocols used for transporting real-time data such
as audio and video media across an IP network.
This chapter analyzes Real-Time Transport
Protocol (RTP) and Real-Time Transport Control
Protocol (RTCP), along with different types of
DTMF relay methods used by endpoints to convey
digit information over audio streams, RTP, SIP,
and H.323.
• Chapter 4, “Unified CM Call Routing and
Digit Manipulation”: This chapter provides an
in-depth explanation of Unified CM pattern
matching, transformations, and masks. You will
gain an understanding of device selection and the
logical grouping concepts related to calling search
spaces (CSS) and partitions. Dial plan elements
such as tail-end hop off (TEHO) and intercluster
Global Dial Plan Replication (GDPR) are discussed.
The chapter ends with valuable dial plan
troubleshooting steps, using various Cisco tools.
• Chapter 5, “Unified CM SIP Trunk

Configuration”: This chapter discusses Unified
CM SIP trunking configuration, verification, and
troubleshooting. It discusses general configurations
as well as many advanced SIP trunk features and
settings to provide insight into why you would
enable or disable specific settings and features for a
particular deployment or integration.
• Chapter 6, “Unified CM Call Control

Features”: This chapter discusses media
resources, with a focus on the many conferencing
resources available in Cisco collaboration
deployments. Furthermore, the chapter discusses
supplementary features such as call park and call
pickup, along with regions, codec preference, and
call admission control in Unified CM.
• Chapter 7, “Unified CM Mobility”: This

chapter discusses the configuration, verification,
and troubleshooting of Unified CM mobility, which
can be broadly broken down into three key areas:
unified mobility, extension mobility, and device
mobility.
• Chapter 8, “CUBE Call Routing and Digit

Manipulation”: This chapter provides an in-
depth explanation of IOS, IOS XE, and CUBE call
routing topics, including call legs, call flows,
inbound/outbound dial peer matching, and
application signaling and media binding. The
chapter also discusses various digit, header, and
URI manipulation techniques.
• Chapter 9, “CUBE Interworking Features”:

This chapter examines how CUBE performs SIP–
SIP interworking as a back-to-back user agent
(B2BUA) for sessions between Unified CM, SIP
service providers, and other third-party SIP call
control systems. This chapter discusses both initial
call setup and mid-call signaling transactions, such
as hold, resume, transfer, session refresh, and other
generic session updates. This chapter also examines
additional topics such as SIP toll fraud
authentication on CUBE, service provider
authentication, and CUBE media interworking and
troubleshooting.
• Chapter 10, “Unified CME and SRST”: This

chapter discusses the initial configuration of
Unified CME on IOS and IOS XE gateways to
facilitate SIP IP phone registration. In addition,
this chapter discusses advanced features such as
voice hunt groups, multicast paging, and call park.
Finally, it provides an overview of SRST with
Unified CM.
EXAM TOPICS
The questions on each certification exam are a closely
guarded secret. However, Cisco has published exam
blueprints that list which topics you must know to
successfully complete the exam. Table I-1 lists the
blueprint topics along with references to the book
chapter or chapters where you can find more information
about each topic. These are the same topics you should
be proficient in when designing and implementing Cisco
Unified CM networks in the real world. Note that some
topics are discussed in multiple chapters as they pertain
to specific devices and their configurations for specific
protocols.
Table I-1 CCNP CLACCM 300-815 Exam Topics and

Chapter References
Each version of the exam can have topics that emphasize
different functions or features, and some topics can be
rather broad and generalized. The goal of this book is to
provide the most comprehensive coverage to ensure that
you are well prepared for the exam. Although some
chapters might not address specific exam topics, they
provide a foundation that is necessary for a clear
understanding of important topics. Your short-term goal
might be to pass this exam, but your long-term goal
should be to become a qualified CCNP collaboration
engineer.
It is important to understand that this book is a static

reference, whereas the exam topics are dynamic. Cisco
can and does change the topics covered on certification
exams often.
This book should not be your only reference when

preparing for the certification exam. You can find a
wealth of information at Cisco.com that covers each topic
in great detail. If you think you need more detailed
information on a specific topic, read the Cisco
documentation that focuses on that topic.
Note
As CCNP Collaboration technologies continue to evolve, Cisco reserves the
right to change the exam topics without notice. Although you can refer to the
list of exam topics in Table I-1, always check Cisco.com to verify the actual list
of topics to ensure that you are prepared before taking the exam. You can view
the current exam topics on any current Cisco certification exam by visiting the
Cisco.com website, choosing Menu, and Training & Events, then selecting from
the Certifications list. Note also that, if needed, Cisco Press might post
additional preparatory content on the web page associated with this book at
http://www.ciscopress.com/title/9780136575542. It’s a good idea to check the
website a couple of weeks before taking your exam to be sure that you have
up-to-date content.
Figure Credits
This content is currently in development.
Chapter 1. Introduction to Unified
Collaboration and Dial Plans
This chapter covers the following topics:
• Introduction to Cisco Unified Collaboration

Components: This section provides a crash
course on the expansive Cisco Unified collaboration
ecosystem and introduces the three products
relevant to the CLACCM 300-815 exam blueprint
and this book: Unified CM, CUBE, and Unified
CME.
• Dial Plan Design Overview: This section

discusses dial plans and reviews good and bad
approaches to dial plan design and call routing.
This section also discusses the North American
Numbering Plan (NANP) and international
standards, such as E.164, to provide a framework
for dial plan design.
Cisco Unified Collaboration (Cisco UC) is an ever-

growing ecosystem of endpoints, application servers, and
peripherals that enable next-generation communication
by allowing customers to communicate with audio,
video, messaging, and application sharing. These
collaboration devices work together to offer many
solutions to real-world business problems. Cisco knows
there is not a one-size-fits-all approach to solving
business challenges; therefore, the Cisco collaboration
solutions can be tailored to meet your exact business
needs. Whether your company is big or small, the Cisco
collaboration portfolio offers a cohesive experience with
a feature-rich set of on-premises, cloud, and cloud hybrid
collaboration products that can help take your company’s
collaboration experience to the next level.
“DO I KNOW THIS ALREADY?” QUIZ
The “Do I Know This Already?” quiz allows you to assess
whether you should read the entire chapter. If you miss
no more than one of these self-assessment questions, you
might want to move ahead to the “Exam Preparation
Tasks” section of the chapter. Table 1-1 lists the major
headings in this chapter and the “Do I Know This
Already?” quiz questions related to the material in each
of those sections to help you assess your knowledge of
these specific areas. The answers to the “Do I Know This
Already?” quiz appear in Appendix A, “Answers to the
‘Do I Know This Already?’ Quiz Questions.”
Table 1-1 “Do I Know This Already?” Foundation Topics

Section-to-Question Mapping
1. Which products exist within the collaboration edge

component of the Cisco collaboration ecosystem?
(Choose two.)
a. Unified CM
b. Cisco Unified Border Element (CUBE)
c. Expressway-C
d. Unified CME
e. Cisco Unity Connection (CUC)
2. Which voice over IP (VoIP) protocol is used to form

trunks between many of the different collaboration
components for call routing and other features?
a. Q.931
b. Session Initiation Protocol (SIP)
c. Real-Time Transport Protocol

d. Hypertext Transfer Protocol (HTTP)
3. Which of the following are Unified CM services?

(Choose two.)
a. Endpoint registration
b. Ad hoc conferencing
c. Firewall traversal
d. PSTN SIP trunk termination
4. For which VoIP protocols does CUBE perform

interworking? (Choose two.)
a. MGCP
b. SCCP
c. SIP
d. H.323
e. WebRTC
5. What part of the North American Numbering Plan

(NANP) deals with area codes?
a. NPA
b. NXX
c. Subscriber
d. Country code
6. Which of the following is a valid +E.164 number for

San Jose, California?
a. 5267209
b. 4085267209
c. 14085267209
d. +14085267209
7. What sequence of digits would an on-premises NANP
user typically dial to indicate that an international
call should be made?
a. Steering code and phone number
b. Steering code and 1 and the phone number
c. Steering code and 00 along with the country code

and the phone number
d. Steering code and 011 along with the country code

and the phone number
FOUNDATION TOPICS
INTRODUCTION TO CISCO UNIFIED

COLLABORATION COMPONENTS
In this book, you will be introduced to a number of Cisco
collaboration solutions, including many different
products working together to achieve a common goal.
Cisco’s on-premises and cloud collaboration solutions
offer organizations the ability to integrate video and
audio across many different devices and locations.
Figure 1-1 provides an example that shows the Cisco

collaboration ecosystem’s major segments or
subsystems.
Figure 1-1 Cisco UC Architecture Overview
Figure 1-1 shows the following components:
• Cisco Unified Communications Manager (Unified

CM) is a call control application that handles
endpoint registration, call routing, supplementary
features, and many other services. In addition,
instant messaging and presence (IM&P) services
for Cisco Jabber clients are handled by an IM&P
server that works alongside Unified CM.
• Cisco Unity Connection (CUC) handles enterprise

voicemail services and also provides other features,
such as basic auto-attendant functionality, through
call handlers.
• Conferencing is a large part of any collaboration

ecosystem, and Cisco has a few on-premises
products that work together to provide a feature-
rich on-premises conferencing platform:
• Cisco Meeting Server (CMS) can be used to

provide highly scalable audio and video
conferencing options to on-premises endpoints
and mobile devices.
• Cisco Telepresence Management Suite (TMS)
can be coupled with CMS to manage video
conferencing devices on the network along with
centralized meeting scheduling.
• Cisco Meeting Manager (CMM) provides a set
of management services built around CMS.
(CMM is not shown in the figure.)
• IOS and Unified CM–based ad hoc

conferencing provide audio-only conferencing
for on-premises endpoints.
• Collaboration management applications such as

Cisco Prime Collaboration Deployment (PCD)
assist UC engineers with deployment, migration,
and installation of collaboration applications, and
Prime Collaboration Provisioning (PCP) provides a
centralized location to perform move, add, change,
and delete operations for various system
configurations, endpoints, and users.
• Endpoints include desktop endpoints such as the

Cisco IP Phone 7800 and 8800 Series and desktop
video conferencing units such as the DX80 and
Webex Desk Pro. Softphone applications such as
Cisco Jabber and Webex Teams can be leveraged
for calling, meeting, or instant messaging features.
• At the collaboration edge, a few key products

service two key areas:
• Connecting the enterprise to the PSTN so

that on-premises endpoints can call off-
net mobile devices such as a cellphones
or receive inbound calls to endpoints,
conferencing services, interactive voice
recognition (IVR) applications, and
voicemail: Public switched telephone
network (PSTN) connectivity is achieved
through Cisco Unified Border Element (CUBE),
which connects to an Internet telephony
service provider (ITSP) to provide PSTN
services or through a voice gateway, which
terminates a connection directly to a service
provider through a traditional telephony circuit
such as an Integrated Service Digital Network
(ISDN) connection.
• Enabling Mobile and Remote Access
(MRA) for teleworkers and mobile
worker devices to register the on-
premise Unified CM and leverage other
collaboration services on the enterprise
domain: The Expressway-C and Expressway-E
series of devices facilitate firewall traversal and
connection to mobile teleworker devices and
cloud collaboration systems via the public
Internet. An Expressway-E device is usually
placed in a DMZ and communicates to an
Expressway-C device, which is located inside
the corporate firewall. MRA endpoints can
register to on-premises call control systems
such as Unified CM without the need for costly
virtual private network (VPN) connections.
Expressway also provides business-to-business
(B2B) collaboration and a unified edge for
WebRTC application to connect to CMS
conferences.
• In terms of cloud collaboration, Cisco has an entire

suite of products under the Webex domain that can
be leveraged for various purposes, such as hybrid
calling services, messaging, and conferencing
through Webex Calling, Webex Teams, Webex
Meetings, and so on.
• Desktop endpoints at the remote site can register

locally to a Cisco voice gateway running Cisco
Unified Communications Manager Express
(Unified CME) or register to the on-premises
Unified CM over a dedicated WAN connection. In
the event that this WAN connection is lost, these
endpoints may use the Cisco voice gateway as a
backup or as a Cisco Unified Survivable Remote
Site Telephony (SRST) gateway. Although not
shown in Figure 1-1, Cisco Unity Express (CUE) can
be used to provide voicemail functionality to
Unified CME endpoints.
Note that Figure 1-1 does not show some devices, such as
those in customer care solutions. The smaller Unified
Contact Center Express (UCCX) can be integrated with
Unified CM to provide greater IVR capabilities to callers,
including advanced custom scripting and support for up
to 400 agents. Situations in which more agents are
required can take advantage of the more robust Unified
Contact Center Enterprise (UCCE), which is an entire
architecture that has many unique components. (UCCE
is not shown in Figure 1-1.)
Figure 1-2 rearranges the components shown in Figure 1-

1 into a network topology that you might be more
familiar with. Here you can see two Unified CM clusters,
accompanied by a set of on-premises endpoints that
register to the local Unified CM cluster. These two
clusters can be configured to communicate via a SIP
trunk, which can be used by either cluster to connect to
shared services such as IM&P, CUC, CMS, and TMS.
Similarly, Skinny Client Control Protocol (SCCP) can be
used to register IOS-based media resources.
Figure 1-2 A Common Cisco UC Topology with
Collaboration Components
The Unified CM cluster can also leverage SIP or H.323 to

form a trunk with CUBE, which in turn uses a SIP trunk
with the service provider of choice for PSTN connectivity.
Mobile and remote workers can leverage the Internet,
Expressway-E, and Expressway-C to communicate with
on-premises resources such as Unified CM, IM&P, CMS,
CUC, and on-premises endpoints. MRA endpoints can
even take advantage of CUBE when making PSTN calls.
The remote site has the option to leverage a SIP trunk

directly to the service provider and, ultimately, to the
PSTN; alternatively, remote site endpoints can register
over an MPLS WAN connection back to the on-premises
resources for registration, supplementary services, and
PSTN connectivity. Both connectivity options are
provided by a Cisco Integrated Services Router (ISR)
configured as a Unified CME or as a data router
providing WAN connectivity to the enterprise.
There are many components involved in a Cisco UC

solution, and a UC administrator will likely come across
many of these components in real-world deployments.
Unfortunately, with so many different components, there
are far too many configurations, scenarios, and
situations to discuss in a single book. Therefore, this
book focuses on the three main products required for the
CCNP CLACCM 300-815 exam, according to the exam
blueprint:
• Unified CM: Unified CM accounts for almost half

of the blueprint, with major focus on call control,
dial plans, call control features, and unified
mobility options. These topics are covered in detail
in Chapters 4, “Unified CM Call Routing and Digit
Manipulation,” through 7, “Unified CM Mobility,”
of this book. Note that Chapter 5, “Unified CM SIP
Trunk Configuration,” discusses many of the SIP
trunking configuration items that are required on
Unified CM to integrate with the shared services
applications, such as IM&P, CUC, and CMS, but it
does not cover the configurations on those
products.
• CUBE: IOS dial plans, digit manipulation, and

CUBE interworking features for SIP and media are
discussed in Chapters 8, “CUBE Call Routing and
Digit Manipulation,” and 9, “CUBE Interworking
Features.”
• Unified CME and Unified SRST: Unified CME

and Unified SRST are covered in Chapter 10,
“Unified CME and SRST.”
Various chapters provide deeper treatment of these

products and their features, as well as their
configuration, operation, and troubleshooting. This
chapter provides a quick introduction to these three
products.
Cisco collaboration products use many voice over IP

(VoIP) protocols. This book focuses on the main
protocols included in the CLACCM 300-815 exam
blueprint:
• Session Initiation Protocol (SIP) and

Session Description Protocol (SDP): While
Chapter 2, “VoIP Protocols: SIP and H.323,”
provides a comprehensive overview of the SIP,
every chapter of this book covers SIP to some
degree. For example, in Figure 1-2 you can see that
almost every product in the Cisco UC ecosystem
uses SIP for communication in some capacity.
Similarly, SDP is very important to SIP
communications and is examined, along with SIP,
throughout this book.
• H.323: H.323 consists of several different

protocols—most importantly H.225 and H.245.
H.323 is covered in Chapter 2 as well as in Chapter
9.
• Real-Time Transport Protocol (RTP) and

Real-Time Transport Control Protocol
(RTCP): Chapter 3, “VoIP Protocols: RTP, RTCP,
and DTMF Relay,” provides a rigorous introduction
to RTP (audio and video media) and RTCP. Later
chapters, such as Chapter 5, “Unified CM SIP
Trunk Configuration,” Chapter 6 “Unified CM Call
Control Features,” and Chapter 9, dive into specific
configurations on Unified CM and CUBE for media
interworking and troubleshooting.
• Dual-tone multifrequency (DTMF): The

various protocols defining DTMF relay are covered
in Chapter 3, and DTMF interworking on CUBE is
discussed in Chapter 9.
Note
Due to the content of the CLACCM 300-815 exam blueprint, this book
assumes that common networking components, such as Layer 3 IP routing and
Layer 2 components, have been properly configured. Furthermore,
foundational topics related to most UC networks—such as Domain Name
System (DNS), Dynamic Host Configuration Protocol (DHCP), Lightweight
Directory Access Protocol (LDAP) and Active Directory, Network Time Protocol
(NTP), Cisco Discovery Protocol (CDP), and Trivial File Transfer Protocol
(TFTP)—are left to the CCNP CLCOR (300-801) exam.
Unified CM
Cisco Unified CM is at the heart of every on-premises
Cisco collaboration solution for the modern enterprise.
As such, UC engineers are likely to need to deploy,
administer, or troubleshoot Unified CM at some point
during their collaboration journey. Almost half the topics
in the CLACCM 300-815 exam blueprint are relevant to
Unified CM.
Unified CM has far too many features and services to

provide an exhaustive list within this publication. The
following are some of the features you are most likely to
encounter:
• Unified CM can provide call agent registration and
call routing capabilities for many different models
of voice and video endpoints, such as Cisco IP
Phone endpoints, Webex endpoints, analog
telephony adapters (ATAs), immersive room
systems, soft clients, and many other devices.
• Unified CM can integrate with many different Cisco

products and third-party devices to extend features,
services, and call routing capabilities using VoIP
protocols such as SIP, H.323, MGCP, and SCCP.
SIP trunking is discussed in Chapter 5.
• Unified CM has the ability to provide media-related

services such as software conference bridges, Media
Termination Points (MTP), Music on Hold (MOH),
and basic IVR functionalities with integrations to
other devices such as CMS or IOS XE voice
gateways equipped with PVDMs to provide
additional media services. A few of these topics are
covered in Chapters 6 and 9.
• Unified CM can be configured to provide native call

hunting, time-of-day routing, and queuing abilities
or integrated with UCCX for customer care or
contact center functions. For situations where an
even larger solution is required, Unified CM is also
integral in UCCE deployments. Chapter 4 covers
the features native to Unified CM.
• Unified CM has a rich set of application

programming interfaces (APIs) that can be used to
integrate with custom applications for extended call
routing, call recording, and serviceability.
• Unified CM can integrate with Microsoft Active

Directory (AD) using LDAP for user management
and authentication.
• Unified CM features many bulk administration
options, which can be further expanded by
integrating PCD or PCP.
• Unified CM provides supplementary services to IP

phones, such as hold, resume, transfer, park,
pickup, call forward, malicious call identification,
and shared lines. Chapter 9 discusses some of these
topics and how they pertain to CUBE integrations.
• Unified CM provides many features that make

administration and deployment of endpoints a
breeze. These include auto-registration, self-
provisioning, and DHCP services.
• Unified CM provides many mobility options to

provide flexibility for end users, such as Extension
Mobility, Mobile Connect/Single Number Reach
(SNR), Move to Mobile, Mobile Voice Access
(MVA), Device Mobility, and Mobile and Remote
Access (MRA) through Expressway for a VPN-less
solution to registering endpoints over the public
Internet. Chapter 8 covers most of these topics,
except for MRA, which is left for the CCNP
Collaboration CLCEI 300-820 exam.
• End users can update their local speed dial,

forwarding, and mobility settings through an easy-
to-use self-care portal.
• Unified CM provides many next-generation

security features that can be used to encrypt call
signaling and media along with other traffic to and
from the server. In addition, many security features
that are enabled by default work to protect devices
during many key operations, such as configuration
download and endpoint registration.
Administrators can also control user roles to limit
access and operations on a per-account basis.
• Unified CM provides many troubleshooting and

diagnostic capabilities through the Real-Time
Monitoring Tool (RTMT). A crash course on using
RTMT for log analysis for call routing is provided at
the end of Chapter 4, and Chapters 5 through 7 also
provide relevant trace snippets gathered from
RTMT.
Unified CM operates as a virtual machine running on an

ESXi hypervisor and Cisco Unified Computing System
(UCS). This combination is often referenced as Cisco UC
on UCS. Unified CM may operate as a standalone virtual
machine or may be clustered to scale to business needs.
Depending on the requirements of your enterprise, you
might see something smaller than what is detailed in
Figure 1-3, or you might see something even larger! In
this sample cluster, a single Unified CM publisher is
responsible for the master copy of the database. The
Unified CM TFTP pairs are used to load balance TFTP
requests from endpoints and provide redundancy in the
event of a node failure. The Unified CM publisher does
not provide call processing (or TFTP) capabilities as it is
busy with the database. Instead, one or more Unified CM
call processing node pairs are leveraged to handle
endpoint registration, call routing services, and other
features. Further redundancy can be provided by
geographically locating the redundant call processing
and TFTP nodes in different data centers. IP Phone
registration should be equally load balanced across these
call processing nodes to better utilize virtual machine
resources. There are many constraints on how to create a
Unified CM cluster, and you can refer to the Unified CM
Solution Reference Network Designs (SRND) documents
for more information. A smaller deployment may have
just one or two servers in a cluster, with database, TFTP,
and call processing services running on the one or two
servers in the cluster. Which services run on which
servers in the cluster is left up to the administrator to
determine, based on design guidance offered in the
SRND.
Figure 1-3 One Publisher, Two TFTPs, and Two Call
Processing Pairs (Four Call Processing Subscribers)
Depending on the size of the enterprise, there may be

more than one Unified CM cluster. A Session
Management Edition (SME) cluster may be deployed
alongside the Intercluster Lookup Service (ILS) to
provide dial plan aggregation and ease the
administrative overhead that occurs in this type of
situation. An SME cluster is nothing more than a Unified
CM cluster with no phones registered. Its primary goal is
to aggregate connections from other Unified CM clusters,
typically referred to as leaf clusters. Figure 1-4 shows
three clear clusters of various sizes integrated with an
SME cluster for centralized dial planning. ILS and Global
Dial Plan Replication are discussed in Chapter 4.
Figure 1-4 Three-Cluster SME Design
Unified CM is a very powerful product on its own, and

when it is integrated with other Cisco collaboration
solutions, it gains even more capabilities. The next
section discusses how CUBE can be deployed alongside
Unified CM to integrate with public IP networks for
PSTN connectivity.
Cisco Unified Border Element

CUBE, much like Unified CM, is often included in
collaboration deployment solutions for enterprise PSTN
access and customer contact center solutions. As a result,
UC engineers are likely to need to deploy, configure, or
troubleshoot calls involving CUBE or IOS voice gateways
at some point. CUBE is an IOS/IOS XE-based
application that runs on both physical and virtual
hardware such as the Integrated Services Router,
Aggregated Services Router, and Cloud Services Router.
The different platforms allow CUBE to scale to different
total session capacities and cater to the needs of an
individual business. As a result, when selecting a
platform to run CUBE, UC administrators must carefully
map out the total number of sustained
inbound/outbound sessions along with the total number
of new calls per second that CUBE will be expected to
handle. This must be done to avoid oversubscribing the
resources on the device. As with most other deployment
planning, room should be left for future growth. In
addition to VoIP session capacity planning, you must
consider what other services the platform will be
handling. Cisco routing platforms can operate many
other services alongside CUBE, and those services use
the same CPU and memory resource pools. Depending
on the services, utilization, and other requirements, a UC
administrator must make a choice to either run all the
services on one device and account for these other
services in the session capacity planning or split the
CUBE functionality into a separate device that allows
total resource allocation to the CUBE application.
The CUBE application and the SIP and H.323 protocols

operate logically within the OSI model at the application
layer (Layer 7). To establish a session, CUBE
encapsulates SIP traffic into packets as application data
for transmission over Layer 3 IP networks. This means a
valid bidirectional Layer 3 network path needs to be
established between CUBE and any device that CUBE
peers with. The type of physical connections and routing
protocols to be used are determined by the underlying
network used to transmit these packets for establishing
SIP sessions. Some deployments with CUBE may require
only a few static routes, while others may require
deployment of a fully autonomous routing protocol, such
as BGP. The network connection with an ITSP may be a
direct point-to-point Ethernet connection or a serial
connection, or CUBE may be required to peer over a
WAN connection, such as MPLS. On the LAN side, the
same complexities (or more) may exist. In addition,
advanced IP routing techniques such as virtual routing
and forwarding (VRF) may be required.
Furthermore, because CUBE is on the edge of the

network and acting as a demarcation point between the
private enterprise LAN and various public networks,
most UC deployments utilize a firewall for additional
security, protection, and threat mitigation. The firewall
functionality may be colocated with CUBE via zone-
based firewall (ZBFW) or a standalone device such as a
Cisco Adaptive Security Appliance. The Layer 1, 2, 3, and
4 network design and deployment topics for CUBE are
not required by the CLACCM 300-815 exam blueprint, so
they are not covered in this chapter. All examples and
scenarios in this chapter assume that a bidirectional
network path and the required configurations to
facilitate that network path have already been completed.
Figure 1-5 illustrates a few different CUBE deployment

scenarios to help visualize how CUBE fits into an IP
network and facilitates interworking with the private
enterprise LAN and public networks through an ITSP.
CUBE may be deployed as a centralized resource for
many Unified CM clusters (alongside a Unified CM SME
cluster) to interface with the PSTN or be distributed
across many Unified CM clusters due to geographic
location. CUBE can be configured as an active/passive
high availability pair to provide redundancy and failover
of ongoing calls in the event of a link failure.
Figure 1-5 CUBE Integrating with a Service Provider

and Unified CM for Different Deployment Scenarios
The main goal of CUBE is to operate as a session border

controller (SBC) for the purpose of performing call
routing functions between the enterprise and remote
public networks. If required, administrators can use
many of the rich CUBE interworking features to handle
interoperability scenarios when interfacing with third-
party devices. These features are discussed in depth in
Chapter 9.
CUBE has many other features that can be used to

provide call signaling, media security, call recording,
media forking, DTMF interworking, multi-tenant
operations, fax detection, and media transcoding.
Chapter 8 will provide an in-depth examination of call
routing and digit analysis in CUBE, but for more
information about these other features, refer to the Cisco
Press book Understanding Session Border Controllers:
Comprehensive Guide to Designing, Deploying,
Troubleshooting, and Maintaining Cisco Unified Border
Element (CUBE) Solutions.
Unified CME and Unified SRST

Unified CME is a great remote branch office or even a
small to medium business call agent solution that
leverages IOS or IOS XE voice gateways on the ISR series
of hardware routers or Cloud Services Router virtual
machines. Like Unified CM, Unified CME offers many
call agent, registration, and call routing capabilities for
on-premises IP phone endpoints. Administrators and
end users can leverage many supplementary service
features available to IP phones, although there are not as
many as with Unified CM. Similarly, SRST provides a
redundant call agent for registration when IP phones are
located at remote branch offices behind a WAN
connection. For a full overview of Unified CME and
SRST, see Chapter 10.
DIAL PLAN DESIGN OVERVIEW

A dial plan is one of the most important parts of any
collaboration solution. After all, making and receiving
calls to and from various devices, applications, systems,
and integrations is at the core of every UC component.
Unfortunately, most UC administrators never create a
dial plan from scratch because they work on or inherit an
existing network where the dial plan was set up long ago.
Similarly, UC administrators often employ very basic dial
plan topics in their collaboration labs and do not explore
the topic properly.
The following sections discuss a dial plan design for a

large enterprise consisting of many geographic locations,
both national and international. The following chapters
reinforce the dial plan concepts with design and
configuration on Unified CM, CUBE, and Unified CME.
Why Dial Plan Design Is Difficult
As an exercise, let’s examine a few scenarios that need to
be addressed when designing a dial plan. We can start
with an IP phone that needs to call another IP phone in a
different part of the building. Both phones are registered
to the same Unified CM on the same enterprise network
(using on-network calling [on-net]). How do you
assign phone numbers in this scenario? You might be
thinking it’s as easy as using a four-digit extension and
assigning the first phone the extension 1000 and the
second phone extension 1001.
Now say that the IP phones require the ability to receive

calls from off-network (using off-network calling
[off-net]) PSTN users, such as mobile phones. To
accomplish this, you should purchase a Direct Inward
Dialing (DID) number from a service provider, utilize
CUBE as an SBC to terminate the PSTN SIP trunk, and
route the inbound call to Unified CM to reach the phone.
You will likely need to do some work to get the DID
number to ring the IP phone because it is unlikely that
the DID number assigned by the service provider ends in
1000 or 1001. This challenge is usually solved through
some form of translation that transforms the full DID
number into the four-digit extension on the IP phone. To
simplify this translation, you may choose to change the
four-digit extension of the phones from 1000 and 1001 to
match the last four digits of the DID provided by the
service provider.
Now imagine that there is another site of IP phones on a

different Unified CM cluster—perhaps in San Jose (SJ)—
which needs the capability to call the IP phones on the
first Unified CM cluster in Raleigh (RTP). How should
the SJ users reach the phones in RTP? You could have
the users dial out to the PSTN and route the call back in
using the DID, but that is a suboptimal solution which
involves hair-pinning calls through the PSTN and
ultimately allocating double the call resources on your
own devices responsible for PSTN calls; in addition, the
users would be stuck with standard G.711 audio instead
of wideband audio codecs and video. A more efficient use
of resources would involve keeping the call on-net and
sending it from the SJ Unified CM to the RTP Unified
CM over your own network, such as an MPLS WAN.
Perhaps the user could just dial the four-digit extension,
but what if the last four digits of the DIDs for the two
sites overlap (which is very likely to happen if you have
many sites)? To deal with this challenge, you can create a
private on-net dial plan that is locally significant to your
enterprise. For example, the RTP site might be assigned
a site code such as 191. The length of the site code is
arbitrary and based on how many sites you expect to roll
out in your network. A three-digit site code would give
you the ability to have 1000 sites in this case. The user
might dial a steering code plus a site code and the
extension of the phone and utilize an on-net path over
the WAN rather than off-net PSTN resources that
hairpin the call.
We have not talked about steering codes yet, so let’s dive

into those. How should the users at the IP phones
indicate to Unified CM and other devices that the call
they want to place is destined for the PSTN? For
enterprise networks, this is usually signaled via a
steering code, commonly referred to as a PSTN access
code, that is entered before the actual called number is
dialed. The most common steering code used in North
American deployments is a single 9 prefixed before the
dialed number to indicate that a call should be sent to an
off-net PSTN destination. Some deployments in North
America also utilize 8 as a steering code. In other
countries, 0 is often used as the steering code. (In the
upcoming chapters, you will see the steering code 9 used
in most examples involving a call out to the PSTN.) Now,
what steering code should be used for on-net abbreviated
dialing between sites? The most common steering code
here is a single 8. Your organization may have additional
steering codes for various services specific to your
organization. For example, overhead paging services may
be accessed by dialing * and a four-digit number. Keep in
mind that Unified CM has no concept of a steering digit
or code as a dial plan construct. In other words, there is
no place in Unified CM where you can configure
anything called a steering code. Rather, steering codes
are defined by use, as part of a configurable pattern.
Some customers choose to forgo steering digits

altogether and require their users to place all calls the
same way they would dial a number on a home or mobile
device. For a phone in North America, this would mean
dialing a 10-digit number for all calls, even if calling a
phone in the next cubicle. While this is a perfectly valid
dial plan design, it does have disadvantages, such as
making it challenging to allocate phone numbers that do
not have corresponding “real” PSTN numbers without
causing overlap problems with the PSTN and restrictions
around being able to place calls in an abbreviated
fashion. In environments where users all have DID
numbers and do not engage in much intra-site calling
where abbreviated dialing codes are beneficial, this may
be a viable option. Alternatively, you may consider using
* as a steering digit to indicate abbreviated dialing. For
example, dialing *1000 would reach extension 1000 in
the local site while still allowing users to dial all other
numbers as they would dial them from their home or
mobile phone.
So far, our examples have detailed two locations in the

same country along with three endpoints. It is not
difficult to form a dial plan with such a small number of
devices. However, in a real network, there might be
thousands of endpoints at each location, all requiring
DIDs that map to extensions and ring one or many
phones. There may be many clusters that are spread
around the globe, each serving multiple sites in different
countries. In such a case, users need to dial to many
different PSTN locations for local calls, long-
distance calls, and international calls. As you will
soon see, this process varies greatly country by country,
further complicating the issue when there are multiple
international locations. For these reasons, assigning a
simple four-digit extension to phones may not be the
most scalable approach.
In addition to the complications discussed so far, many

service and emergency numbers (such as 911 or 112) exist
in different geographic locations. Your organization may
have many different internal services that also have
phone numbers that may need to be reachable from a
host of different locations, including the PSTN. Examples
include auto attendants, IVR systems, customer care
contact centers, multiparty conferencing numbers, and
your own local IT help desk. There may be restrictions on
toll-free international calls or other local restrictions on
calling that need to be enforced in the dial plan. Also,
don’t forget about redundancy. For business-critical
services, specific phone numbers or PSTN access may
require redundant paths on the network, which adds
another layer of complexity to a dial plan.
When you consider all these variable requirements,

constructing a dial plan from scratch can be a very
daunting task. If a sound methodology is not employed
from the beginning, you will likely run into issues down
the road. Common problems with suboptimal dial plans
include the following:
• Overlapping patterns, which lead to long wait times

when dialing numbers or calls attempting to route
before all the required digits have been collected.
• Calls taking suboptimal paths, which leads to
resource allocation issues or quality of service
problems when media takes a network path that is
not engineered to carry voice or video.
• Disjointed numbering plans, which require lots of

administrative overhead, result in more complex
troubleshooting when issues arise, and lead to poor
end-user experience.
• Customers’ expected dialing habits don’t work,

resulting in call failures. For example, a customer
might expect to be able to dial a local number in a
certain way, but the configured dial plan might
permit the call only if it is dialed as a long-distance
number.
• Redundancy issues, which lead to major downtime

and loss of business. Not only should these be
baked into the dial plan early, they should be
periodically tested. You do not want to be in the
midst of an outage only to find out the redundancy
is also down and has been down for quite some
time.
• Inability to scale the dial plan as the company

grows, undergoes a merger or an acquisition, or
expands into a new country.
Luckily, various standards created by the International

Telecommunication Union (ITU) provide a framework
for how numbering plans work on national and
international telecommunication networks. By using
these standards as a starting point coupled with the
Cisco Validated Design (CVD) for call control, you can
begin to create a dial plan that is resilient to downtime,
scalable, and, most importantly, easy to understand.
North American Numbering Plan (NANP)

The North American Numbering Plan (NANP) is used in
the United States, Canada, and most Caribbean
countries. For most this is likely a very familiar format.
Telephone Numbers are broken into three key parts:
• Numbering plan area (NPA) codes: A

numbering plan area (NPA) code, often
referred to simply as an area code, is a three-digit
code that is usually mapped to a location such as a
city. Area codes always start with the digits 2
through 9 followed by any two digits except for two
1s.
• Central office exchange code (NXX): A

central office exchange (NXX) code is
another three-digit code that maps to the central
office. Cities may have more than one central office
code, depending on the size of the city. Much like
an area code, an office code always starts with the
digits 2 through 9 followed by any two digits except
for two 1s.
• Subscriber numbers: A subscriber number

is a four-digit extension that maps to a station.
You can put together parts of a phone number and use

them with or without dashes or with parentheses to
indicate digits that might not be required, depending on
the location of the caller:
NPA-NXX-XXXX
NPA NXX XXXX
(NPA) NXX XXXX
Note
Note that the nomenclature used here is that for all digits after the NPA, N can
be any digit from 2 to 9, and X can be any digit from 0 to 9. The digits 911
should never be used within an NPA or NXX code.
With the NANP, the parentheses are often around the
area code, as the last seven digits alone can be dialed by
callers in the same area code. When an area code has
more than one NXX code, seven-digit dialing is usually
not possible.
Table 1-2 provides some examples of real Cisco phone

numbers. The first row of the table indicates the NPA
area code 408, which is San Jose, California. The second
row features the same area code but with a different
NXX code. However, from the area code, you know that
408-524 and 408-526 are both located in San Jose. The
last row of the table lists the Raleigh, North Carolina,
area code 919, along with NXX code 392. The subscriber
number in the last column is a four-digit extension that
consists of digits 0 through 9 for any position.
The particular numbers in this table are all Cisco phone

numbers. The number in the first row is the frontline
number for Cisco TAC. The second row shows the Cisco
Webex meetings call-in number. The last row shows the
Cisco RTP campus number.
Table 1-2 Sample NPA and NXX Numbers from Cisco

Systems
To help visualize these phone numbers and how NPA

area codes and NXX numbers work, Figure 1-6 shows the
numbers from Table 1-2 on a map.
Figure 1-6 U.S. Map Showing NPA-NXX Numbers from
Table 1-2
For those who have worked on collaboration systems in

North America, this system likely makes sense and will
seem familiar. But for those not based in the United
States, there may be a learning curve. Many other
countries around the world use their own structuring of
numbers, and someone from the United States might
struggle with the task of making local or long-distance
calls or designing a national dial plan in Belgium. The
next section discusses the common E.164 format for
international dialing.
International Dial Plans with E.164

The ITU-T E.164 standard builds on country-specific
national dialing patterns and provides a framework to
easily describe phone numbers and place international
calls from one country to another. This method ensures
that a globally unique number exists for any phone
assigned a number on the PSTN. Thanks to this
standard, someone in the United States can call someone
in Turkey without fear of the call being routed to another
country or location, and authorities in one country can
manage the numbering plan within the country without
fear of conflicting with the numbering plan of another
country. The E.164 standard uses country codes, and
the country code is often prefixed with the plus symbol
(+). An E.164 number, including the country code,
cannot exceed 15 digits. Table 1-3 provides some
examples of international Cisco phone numbers.
Table 1-3 International Cisco Numbers
The first row in the table shows the U.S. international

country code (+1) with the national area destination code
for San Jose and finally the subscriber, which is the
seven-digit NXX-XXXX. The second row shows the
country code for Belgium (+32) and the national
destination code 2 for Brussels. A subscriber number in
Belgium can take one of a few forms; in this case, the
number takes the form XXX XX XX. The third row of the
table shows the country code of Germany (+49), with a
national destination code for München. The subscriber
number for Germany again can take many formats; this
one takes the form XXXXX XXXX. Finally, the last row
shows the international country code for Turkey (+90),
national destination code 212 for Istanbul, and a
subscriber portion in the format XXX XXXX.
Note
Sometimes a phone number has a leading zero wrapped in parentheses
prefixed to the national destination code—for example, (0). This optional zero
is used for national dialing habits in some countries and is not part of E.164.
Note
As you can see in Table 1-3, there are many ways of dividing up the digits after
the country code into national destination code and subscriber numbers. The
NANP uses one method, and other countries use different methods. When
deploying a dial plan in another country, it is important to consult official
documentation from telecommunications companies, the government, and
standards bodies for details about the national numbering scheme.
Table 1-4 lists a number of country codes. There are far
too many of them to list in this chapter, but this table
shows a selection of country codes from around the
world across many continents to illustrate the pattern. In
the table you can see that country codes starting with 2
are generally located in Africa. Similarly, country codes
starting with +3 and +4 are in Europe, and country codes
starting with +5 are in Central and South America.
Country codes starting with +6 are generally in Australia
and Southeast Asia, and +7 is used for Russia and
surrounding countries. Country codes starting with +8
are mostly in East Asia, and those beginning with +9 are
in the Middle East. Note that country codes can be up to
three digits long; for example, Greenland’s country code
is +299.
Table 1-4 Sample Country Codes from Around the

World
Figure 1-7 shows the country codes from Table 1-4 on a
world map so you can see the geographic mappings of
these country codes around the world. Although there
are far too many country codes around the world to show
on this small map, you can find interactive websites that
show all the country codes.
Figure 1-7 World Map Showing the Country Codes from

Table 1-4
In today’s networks, it is very common to see E.164

phone numbers applied to endpoints directly or as
alternative masks. Service providers often send and
accept numbers in the Plus E.164 (+E.164) format, so it
might be easier to apply these numbers directly to
endpoints than to introduce administrative burden by
stripping them down to the subscriber numbers. The
following chapters detail how to handle globalized dial
plans using E.164 phone numbers and globalized dial
plans for both call routing and number presentation.
Case Study: Building a Globalized Dial Plan

Now that you have learned the basics of how phone
numbers operate both at a national level for North
America and under international E.164 numbering plans,
this section walks through a case study to provide an
example of an optimized dial plan using the network
illustrated in Figure 1-8.
Figure 1-8 A Sample Dial Plan for a Small Enterprise
The topology for this example includes the following

major components:
• A San Jose Unified CM cluster with an E.164 DID

range of 14085267200 through 14085267299. The
X in the number indicates any number 0 through 9.
• An RTP Unified CM cluster with an E.164 DID

range of 19193922000 through 19193922999.
Again, the X in the number indicates any number 0
through 9.
• Both SJ and RTP use the +1 country code for North

America
• There is a remote site in Turkey with a DID range

in the +90 country code. For simplicity, only a
single directory number (DN) for this remote site is
shown.
• All three locations are connected to the PSTN by

way of a SIP trunk to CUBE.
• Similarly, all three locations are connected to each
other with a SIP trunk over the enterprise MPLS
WAN.
• For the sake of illustrating PSTN calling, there are

two sample E.164 PSTN numbers here as well.
The following dial plan requirements apply to this case

study:
• IP phones within a location should be able to dial

other phones using any of the following methods:
• Using the full +E.164 number associated with

the phone
• Using an abbreviated four-digit extension to
reach other phones within the same site
• Using a private on-net dial plan consisting of

the digit 8 followed by a site code and an
extension number
• Where possible, calls should not utilize PSTN

resources. IP phones that dial phone numbers for
on-premises devices should be forced back on-net
rather than route to the PSTN, even if they dial the
number using a PSTN dialing habit.
• Enterprise IP Phone users should be able to dial

local, long-distance, and international phone
numbers on the PSTN with the steering code 9.
• PSTN users should be able to call IP phones at any

of the enterprise locations.
• The dial plan should provide redundancy. For

example, if a CUBE or PSTN connection in SJ goes
down, SJ users should still be able to dial PSTN
numbers without issue.
• Emergency services calls should be reachable with

or without the PSTN steering code.
• On-premises users should be able to call endpoints
by using an email address rather than a telephone
number, which is a growing trend in the enterprise.
As discussed in Chapter 4, Unified CM provides a variety

of dial plan configuration constructs that allow an
administrator to design incredibly complex dial plans.
These capabilities provide significant flexibility in how a
dial plan can be architected. Because of the flexibility,
you should understand some best practices of dial plan
design.
One important concept is to understand how a globalized

dial plan works. As described earlier in this chapter, the
E.164 format describes a number in a globally unique
form. However, users can dial a number in a variety of
different ways: as an abbreviated dial number, as an on-
net private call, or as a PSTN call, possibly with leading
steering digits and country-specific prefixes. In a
globalized dial plan, a number dialed by a user is
converted to a global +E.164 format and then routed in
its globalized form. When the call is routed to its final
destination, the globalized number may be converted to a
localized form if, for example, the call is going to the
PSTN, where an ITSP is expecting the number in a
specific format. Keep this general paradigm in mind as
you read through the tasks involved in building a dial
plan that meets the requirements.
Task 1: On-Net Calling Between IP Phones

The first decision an administrator designing a dial plan
needs to make is how to configure the directory numbers
on phone lines. You may be tempted to assign the four-
digit extension corresponding to the extension at that
site; however, as you will see in Chapter 4, doing this can
lead to challenges.
Following best practices, the globalized +E.164 phone

number should be configured as the directory number of
the line on all endpoints rather than as an abbreviated
subscriber number consisting of something like a four-
digit extension. The configured number should include
the leading plus (+) as part of the number. When users
dial a phone number, Unified CM should perform
globalization translations to change the dialed number
into a globalized format, which will then allow the call to
route to the IP phone. The next section describes some of
these translations.
Task 2a: Abbreviated Dialing Between Locations

Users may dial 8 and then the site code and finally the
last four digits of the directory number for the endpoint
they would like to reach. For example, a user in SJ might
dial 81912000, which would route the call from the
Unified CM in SJ across the SIP trunk/WAN and to the
Unified CM in RTP where the phone is registered. This
can be achieved in a few ways. One way is to add the
abbreviated number as an enterprise alternate number
on the line and use dial plan replication, such as ILS, to
advertise this alternate number to the other Unified CM
clusters. For a less dynamic solution, you can build static
call routing elements in Unified CM to take calls with 8
along with the site code and send them to the
appropriate SIP trunks and, ultimately, Unified CM. In
this scenario, 8191 would always point to the SIP trunk to
the RTP CUCM. Alternatively, following the globalized
dial plan approach, a translation could be configured to
convert numbers that start with 8191 followed by four
digits to +1919392 followed by the same four digits.
Task 2b: Abbreviated Dialing Within the Location

It is sometimes desirable to allow users within a site to
call each other using an abbreviated number that is
locally significant to the site. For example, users in RTP
might want to be able to call other phones in RTP by
dialing the last four digits of the extension. In this case, a
translation could be created that matches 2 followed by
three more digits and prefixes +1919392 to the dialed
number before attempting to route the call.
Task 2c: Forced On-Net Calling

When a user dials a number using a PSTN dialing habit
(that is, dialing 9 followed by the DID of another user
instead of using the abbreviated internal dialing
methods) and the number really resides on the
enterprise network, the call should not be sent to the
PSTN, where it would use session capacity, bandwidth,
CPU, and memory resources on the network, CUBE, and
PSTN. A better method is to intercept the called number
and globalize it to the +E.164 number, which is also the
phone number applied to the phone. For example, if a
user in San Jose dials 919193922000, Unified CM should
intercept and convert this number to +19193922000. In
keeping with the globalized dial plan approach, you
would instruct Unified CM to convert any call that
matches 9 followed by 1 and 10 digits to +1 followed by
the 10 digits and then attempt to route the call. As you
will see in Chapter 4, Unified CM tries to find the best
match for this number, and if the resulting number exists
as a configured directory number, it is matched directly
instead of matching a more generic wildcard pattern that
would send the call to the PSTN. Through the use of
globalized dial plan replication using ILS, Unified CM in
San Jose will know that this number exists on the RTP
cluster and routes the call across the SIP trunk/WAN,
thus saving PSTN resources for actual PSTN calls.
Task 3: Outbound PSTN Calls
It is now time to discuss how a user should dial the PSTN

in this solution. Each country generally has different
dialing habits that describe how to reach a number on
the PSTN. In this example, the out-dial steering code 9 is
used. What the user dials after the 9 depends on the local
dialing habits in the country where the user is located.
Table 1-5 details the three different dialing habits used
by users on the RTP campus.
Table 1-5 PSTN Call Samples Sourced from RTP Cluster
Table 1-6 shows calls from the perspective of the remote

site in Turkey. This shows that the way a user dials a
number can vary based on the country. Users in the
United States likely dial 9011 to signal an international
call, while users in other countries, including Turkey,
dial 900.
Table 1-6 PSTN Call Samples Sourced from the Remote

Location
In all the scenarios detailed in Table 1-5 and Table 1-6,

Unified CM should work to convert the phone number
into a globalized +E.164 phone number and remove the
steering code and national dialing habit of 9, 9011, or
900. In some cases, such as for the local and 10-digit
national dialing habits, the translations must append
additional digits that were not dialed by the user. For
example, for a local call, the translation must append the
local area code to convert the local number to a +E.164
format. Globalizing the number ensures that Unified CM
selects the best path for the call, whether it be out to the
PSTN or utilizing an on-premises SIP trunk over the
WAN after finding the number advertised by ILS. These
are only two examples of national dialing habits. (For
example, some countries use 000 for international and
00 for national calls.) In any case, the first step is to
convert from the national dialing habit to +E.164 format
before routing the call.
Task 4: Inbound PSTN Calls

This task is rather trivial because Task 1 did most of the
hard work for you. The PSTN should deliver the +E.164
number to CUBE, and if it is not in the correct format,
CUBE can be configured to convert the called number to
E.164 format before sending the call to Unified CM, or
Unified CM can be configured to globalize the number as
it is received from CUBE. Because the design stipulates
that the directory number on endpoints is in +E.164
format, Unified CM simply routes the call to the
endpoint based on the +E.164 number assigned in Task
1.
Task 5: PSTN Dial Plan Redundancy

For outbound redundancy, there are multiple paths to
the PSTN. A call from SJ can egress via the local CUBE
and PSTN connection or use alternative routing to send
the call across the WAN to the RTP Unified CM and
leverage the RTP CUBE PSTN resources in the event of a
failure. The same can be said of RTP when using the local
RTP CUBE PSTN connection first and then failing over
to the SJ CUBE PSTN connection as a backup. The
remote site could use a different method of redundancy
by integrating primary and backup SIP trunks to the
same or multiple service providers; in that case, when
the first link fails, the second link may be used. This
same method of redundancy could be employed on SJ
CUBE and RTP CUBE. Furthermore, SJ CUBE and RTP
CUBE can be configured with high availability to provide
stateful failover of call signaling and media within a high
availability pair in the event of a link failure.
Task 6: Emergency Calling
Many regulations around the world indicate that

emergency services should be dialable without a steering
code. Therefore, you might need to ensure that particular
patterns are callable from all endpoints to ensure that a
user trying to call emergency services does not receive a
call failure due to dialing the wrong digits. Here are a few
examples of possible patterns for the two most common
emergency numbers, 911 and 112:
911
9911
112
0112
It is important to ensure that these patterns do not

overlap with other parts of your dial plan. For example,
you would not want to have an abbreviated dialing
number for the extension 9112. Not only would this make
accidental calls to 911 likely, you would end up in a
situation where either 9112 is not callable because you
configure the system to route 911 calls immediately upon
detecting those three digits or the system must wait after
dialing 911 because it doesn’t know if you are going to
dial another digit (2) to reach extension 9112.
Task 7: URI Dialing

It is becoming more common for email addresses to be
used in place of or alongside normal telephone numbers;
this is known as a uniform resource identifier (URI)
dialing, and it is especially useful when using soft clients
that allow for user directory searches and click-to-dial.
By using the Global Dial Plan Replication feature in
Unified CM and URI call routing with CUBE, you can
route a call to a URI more easily than ever before. With
URI dialing, for example, the Jabber endpoint in SJ may
do a quick directory search and find the email address of
Patrick in RTP. The user can click once to have the
Jabber client initiate a call to the URI
pkinane@cisco.com, which the SJ Unified CM will route
across the WAN to the RTP cluster and ultimately to
Patrick’s Jabber client. URIs can also be used on physical
phones; don’t think they are limited just to Jabber,
although dialing a URI using a phone keypad can be
cumbersome at best.
Closing Remarks
As you can see, by starting with a globalized dial plan
with E.164 as the basis, you one can create a dial plan
that is scalable, redundant, and easy to manage.
Leveraging features such as ILS and Global Dial Plan
Replication, you can efficiently route calls on the
network and make the best use of limited resources.
Chapter 4 dives into how to configure Unified CM with
these dial plan and call routing tasks in mind, and
Chapter 8 covers how to do the same for IOS XE devices,
such as CUBE and Unified CME.
REFERENCES
Cisco, “Cisco Worldwide Support Contacts,”
https://www.cisco.com/c/en/us/support/web/tsd-
cisco-worldwide-contacts.html
Cisco, “Preferred Architecture for Cisco Collaboration

12.x Enterprise On-Premises Deployments, CVD,”
https://www.cisco.com/c/en/us/td/docs/solutions/C
VD/Collaboration/enterprise/12x/120/collbcvd/contr
ol.html
Cisco, “Cisco Collaboration System 12.x Solution

Reference Network Designs (SRND),”
https://www.cisco.com/c/en/us/td/docs/voice_ip_co
mm/cucm/srnd/collab12/collab12.html
Inamdar, Kaustubh, Steve Holl, Gonzalo Salgueiro,

Kyzer Davis, and Chidambaram Arunachalam.
Understanding Session Border Controllers:
Troubleshooting, and Maintaining Cisco Unified
Border Element (CUBE) Solutions. Hoboken: Cisco
Press, 2018.
ITU, “E.164: The international public

telecommunication numbering plan,”
https://www.itu.int/rec/T-REC-E.164-201011-I
ITU, “E.123: Notation for national and international

telephone numbers, e-mail addresses and web
addresses,” https://www.itu.int/rec/T-REC-E.123-
200102-I
EXAM PREPARATION TASKS

As mentioned in the section “How to Use This Book” in
the Introduction, you have a couple of choices for exam
preparation: the exercises here, Chapter 11, “Final
Preparation,” and the exam simulation questions in the
Pearson Test Prep software online.
REVIEW ALL KEY TOPICS

Review the most important topics in the chapter, noted
with the key topics icon in the outer margin of the page.
Table 1-7 lists these key topics and the page number on
which each is found.
Table 1-7 Key Topics for Chapter 1
COMPLETE TABLES AND LISTS FROM

MEMORY
Print a copy of Appendix C, “Memory Tables” (found on
the companion website), or at least the section for this
chapter, and complete the tables and lists from memory.
Appendix D, “Memory Tables Answer Key” (also on the
companion website) includes completed tables and lists
to check your work.
DEFINE KEY TERMS

Define the following key terms from this chapter and
check your answers in the glossary:
numbering plan area (NPA) code

central office exchange (NXX) code
subscriber number
country code
E.164 number
local call
long-distance call
international call
on-network calling (on-net)
off-network calling
public switched telephone network (PSTN)
Internet telephony service provider (ITSP)
Chapter 2. VoIP Protocols: SIP and
H.323
This chapter includes the following main topics:
• Overview of SIP: This section provides a brief

history of SIP and describes its functional
components, the different methods commonly used
in SIP, and the process by which a call is set up and
torn down.
• Introduction to SDP: This section examines

Session Description Protocol (SDP) fundamentals
and describes the offer/answer framework.
• Overview of H.323: This section covers H.323

basics, including the various components typically
included in H.323 networks and the flow for a
typical H.323 call.
This chapter covers the following CLACCM 300-815

exam topics:
• 1.1 Troubleshoot these elements of a SIP

conversation
• 1.1.a Early media
• 1.1.c Mid-call signaling (hold/resume, call

transfer, conferencing)
• 1.1.e UPDATE
• 1.2 Troubleshoot these H.323 protocol elements
• 1.2.b Call set up and tear down
• 1.3 Troubleshoot media establishment
The field of communications has come a very long way

since the introduction of the telephone in the 1800s by
Alexander Graham Bell. Voice over IP (VoIP) traces its
roots back to as early as the 1920s, when the first
advancement in reproducing speech electronically and
transmitting it over long distances was made. Decades
later, in 1974, a significant milestone was achieved when
the first voice datagram was transmitted over ARPANET,
the precursor to the Internet. The year 1974 also saw
another significant milestone in the history of the
Internet: the introduction of Transmission Control
Protocol (TCP), which would revolutionize the way
information was transmitted over the Internet.
Experiments carried out in subsequent years adequately
demonstrated the need to develop a more flexible
protocol for the transmission of real-time traffic classes.
This led to the introduction of User Datagram Protocol
(UDP), which has gone on to become the default
transport layer protocol for real-time applications.
The next big leap in the world of real-time

communications occurred in 1995, when an Israeli
company by the name of VocalTec pioneered the first
widely available Internet phone. At that time, it was
possible to make calls between two such phones over the
Internet, but speech quality, reliability of connection
establishment, and the overall user experience were huge
hindrances in preventing VoIP technology from
becoming the next big wave in telecommunications.
However, transmitting real-time traffic, like voice and

video, over the Internet at a fraction of the cost incurred
in circuit-switched networks was such an exciting a
prospect that equipment manufacturers could not
abandon it. The introduction of broadband Internet, with
its always-on capability, greatly improved connection
reliability, voice quality, and the user experience. This
seemed to be the inflection point at which VoIP went
mainstream, as corporations realized the immense cost
benefits associated with this technology. Consequently,
equipment manufacturers invested significant amounts
of money and time in developing product lines with an
abundance of features and customization options.
Over the next couple years, standards organizations such

as the International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) and
the Internet Engineering Task Force (IETF) took up the
task of developing and publishing standards related to
VoIP. These standards have become the backbone
protocols and enablers on which modern, real-time
communications infrastructures operate today.
The two most significant signaling protocols used for

real-time communications are Session Initiation Protocol
(SIP) and H.323. The ITU-T first standardized the H.323
suite of protocols, which are used to define how
multimedia sessions are established. Just a few years
later, the IETF began standardizing a competing
signaling protocol for VoIP: SIP. It’s worth noting that
one of the most powerful design elements of SIP was its
maximum reuse of existing Internet standards, such as
Domain Name System (DNS), Hypertext Transfer
Protocol (HTTP), Session Description Protocol (SDP),
and Transport Layer Security (TLS). This made it easier
for SIP to be deployed and integrated into existing
environments while also allowing vendors to reuse these
other protocols in their SIP applications.
While H.323 admittedly has a few advantages over SIP, it

was the easily consumable HTTP-like text-based
approach of SIP and its flexibility, extensibility, and ease
of implementation that won out. Thus, SIP has become
the de facto signaling protocol for real-time multimedia
communications today. For this reason, we have a very
brief introduction to H.323 in this chapter but spend
more time on the SIP signaling protocol and its use of
SDP to describe and negotiate multimedia sessions.


1. Which of the following devices involves colocated

UAC and UAS functionality for the forwarding and
processing of SIP requests?
a. SIP proxy
b. Registrar server
c. Redirect server
d. B2BUA
e. Location server
2. Which of the following messages are server error

final responses? (Choose two.)
a. 404 Not Found
b. 503 Service Unavailable
c. 488 Unacceptable Media
d. 301 Moved Temporarily
e. 500 Internal Server Error

3. Which headers are required for a SIP INVITE
request? (Choose two.)
a. Call-ID
b. Expires
c. Remote-Party-ID
d. Session-ID
e. Contact
4. In an early offer call, which two SIP messages carry

the SDP message body? (Choose two.)
a. INVITE
b. 100 Trying
c. 200 OK
d. ACK
e. BYE
5. Which media codecs require the a=rtpmap SDP

attribute due to the use of dynamic payload numbers?
(Choose two.)
a. G711ulaw
b. G711alaw
c. OPUS
d. H.264
e. G.729
6. Which SIP request can be used to update an existing

media session between two user agents? (Choose
two.)
a. INVITE
b. PRACK
c. UPDATE
d. REGISTER
e. OPTIONS
7. Which H.323 protocol performs the media

negotiation during session establishment?
a. H.225
b. H.245
c. H.450
d. H.264
8. What H.225 TCP port is used to establish non-secure

signaling?
a. 1719
b. 1720
c. 1721
d. 5060
e. 5061
9. With which of the following is H.245 negotiated

before the call connects?
a. Slow start
b. Fast start
c. Early offer
d. Delayed offer
FOUNDATION TOPICS
OVERVIEW OF SIP
Session Initiation Protocol (SIP) forms the
backbone of modern real-time communication networks.
Over the years, SIP has been enhanced a great deal to
include several usage paradigms that make it a very
robust multipurpose communication protocol. The
following sections provide a brief overview of SIP.
Brief Introduction to and History of SIP

The SIP communications protocol is used for session
setup, modification, and teardown. It is an application
layer protocol that incorporates many elements of
Hypertext Transfer Protocol (HTTP) and Simple Mail
Transfer Protocol (SMTP). SIP is modular in design and
can work in concert with many other protocols that are
required to set up and support communication sessions,
including the following:
• Real-Time Transport Protocol (RTP)
• Session Description Protocol (SDP)
• Resource Reservation Protocol (RSVP)
SIP was originally designed by Mark Handley, Henning

Schulzrinne, Eve Schooler, and Jonathan Rosenberg in
1996, and it was standardized in 1999 as RFC 2543. The
version of SIP standardized in RFC 2543 was 1.0. At the
time of this writing, the current SIP version is 2.0,
standardized as RFC 3261.
SIP Operation
SIP works on the request/response framework and
mirrors a model similar to HTTP, where there is a
client/server exchange. A node that generates the
request is called a user agent client (UAC), and a
node that processes the request and sends out at least
one response is called a user agent server (UAS). The
concepts of a SIP transaction and a SIP dialog
characterize the interaction between the UACs and UASs.
A SIP transaction consists of a single request and all
responses to that request, which may include zero or
more provisional responses (1XX) and one or more final
responses (2XX, 3XX, 4XX, 5XX, 6XX). A SIP dialog is a
peer-to-peer relationship between user agents that exists
for some time.
A single SIP dialog can include multiple SIP transactions.

A transaction consists of a single request and the
response(s) to that request. Figure 2-1 shows a few of
these messages and an example of the SIP dialog with
multiple transactions. The first transaction in this figure,
known as the INVITE transaction, forms the SIP three-
way handshake observed in many SIP dialogs.
Figure 2-1 Sample SIP Dialog with Two Transactions
The following events occur in Transaction 1 in this

example:
1. The UAC sends an INVITE message to the UAS in

an attempt to establish a session.
2. The UAS send a 200 OK response, which accepts

the INVITE message for the session.
3. The UAC needs to acknowledge the 200 OK
message for the INVITE transaction, which is done
via an ACK request message. (Note that this
message is only observed during the INVITE
transaction.)
At this point, the session is established, and it continues

until one participant decides to end the session. When
that occurs, a second transaction is created, consisting of
the following events:
1. Session teardown occurs, with a BYE message sent

by one participant (in this case, the originating
UAC).
2. The UAS accepts the BYE for session teardown and
replies by sending a 200 OK.
Note
1XX messages, which are optional, are omitted from Figure 2-1. Similarly, the
type of session (for example, audio, video) being established is omitted to keep
the example simple.
SIP commonly uses TCP or UDP as the transport

protocol. For devices such as call agents, voice gateways,
SIP proxies, and session border controllers (SBCs) that
typically handle several SIP sessions simultaneously, the
transport layer protocol is usually UDP. Establishing and
maintaining a connection involves significantly more
overhead with TCP than with UDP. However, when SIP
sessions need to traverse communication links that are
prone to errors, such as packet drops, it is better to use
TCP as the transport layer protocol. Port number 5060 is
typically used for SIP over UDP or TCP.
SIP messages exchanged between UACs and UASs carry

a lot of information that could be misused if it fell into
the hands of an attacker. For example, a SIP INVITE
carries information that could reveal details of the
network topology, the nature of the device originating or
servicing the request, and details of the media stream(s),
such as the IP addresses and port numbers. This is
especially problematic when communication sessions
span open networks. To prevent such attacks, it is
possible to secure SIP signaling by using Transport Layer
Security (TLS). The port number used for SIP over TLS is
5061.
Resources on a SIP network are identified by a uniform

resource identifier (URI), which takes the following
generic format:
sip:username:password@host:port
If the port is not specified, it defaults to 5060. For secure

SIP transmission over TLS, an s may be added to the end
of sip to make it sips:
sips:username:password@host:port
Note that the sips URI is not required when using TLS,
and many implementations use SIP over TLS with the
sip URI. As with a non-secure sip URI, if the port is not
specified, a default port is used. In this case, however,
the default port is 5061 instead of 5060.
SIP devices are referred to as user agents and can be

devices such as IP phones, call servers, fax servers,
gateways, and SBCs. The originator of a SIP request is
called a UAC, and a device that processes the request is
called a UAS. SIP includes several functional
components, and interactions between user agents in
real-world scenarios are in most cases more complex
than generic client/server transactions. In order to
understand the core tenets of SIP operation, you need to
understand the following functional components of SIP:
• SIP proxy: A SIP proxy is a device that is capable
of performing call routing, authentication,
authorization, address resolution, loop detection,
and load balancing. A SIP proxy can be stateless or
stateful; the fundamental difference between the
two is whether they are aware of SIP transactions.
A SIP transaction consists of a single request and
all responses to that request, which may include
zero or more provisional responses (1XX) and one
or more final responses.
A stateful proxy becomes aware of the state of a SIP

transaction by creating a server transaction, a client
transaction, and a response context. By being
transaction aware, the proxy is capable of forking
requests, retransmitting requests, and generating
messages by itself. For example, a stateful SIP
proxy can generate a SIP CANCEL message to all
entities still processing a forked request after a final
response has already been received.
Stateless proxies, on the other hand, do not

maintain transaction state; they transparently
forward requests from the client to the server, and
they send responses in the reverse direction. Once a
request or a response is forwarded to the intended
recipient, all details or transaction context of the
message is purged. Consequently, stateless proxies
cannot fork requests, retransmit requests, or
generate messages on their own.
Proxies do not manipulate SIP message headers

such as To, From, Call-ID, and so on. They do,
however, include a Via header and a Record-Route
header, and they decrement the Max-Forwards
header value by one.
• Redirect server: A redirect server is a server that

provides location services to user agents or proxies
by replying to requests with the location or route to
the host that ultimately services the request. This is
desirable in situations where there is a need to
build highly scalable servers that do not participate
in a SIP transaction but simply help the proxy or
user agent reach the host by sending a single
message. Redirect servers reply to requests with a
3XX response in which the Contact header contains
the URI of the location to the host.
• Registrar server: A registrar server is a server

that accepts registration requests from user agents
and creates a mapping between their address of
record (AOR)—the public identifier of the user
agent—and the user agent’s location. Subsequently,
this mapping between the user agent AOR and
location is indexed and stored in a location server.
Cisco Unified Communications Manager (Unified
CM) and Cisco Unified Communications Manager
Express (Cisco Unified CME) act as registrar
servers for Cisco IP phones and other enterprise
endpoints. Similarly, Cisco Unified Border Element
(CUBE) may be required to register with a service
provider. While Unified CM is not covered as a
registrar server in this book, the topic of
configuring Cisco Unified CME as a registrar server
for SIP endpoints is covered in Chapter 10, “Unified
CME and SRST.” Registrar server interactions for a
SIP trunk solution with CUBE are covered in
Chapter 9, “CUBE Interworking Features.”
• Location server: A location server contains a

mapping between a user agent’s AOR and location;
it need not be instantiated by a separate physical
server and can be physically and logically colocated
with the registrar server.
• B2BUA: Back-to-back user agents

(B2BUAs) are devices that have both UAC and
UAS functionality and are capable of forwarding
requests and processing them. SBCs, such as CUBE,
are examples of B2BUAs. Unified CM may also act
as a B2BUA. SIP trunking with Unified CM is
covered in Chapter 5, “Unified CM SIP Trunk
Configuration,” and B2BUA operations with CUBE
are covered in Chapter 9.
SIP Methods
SIP messages are transmitted in plaintext. SIP messages
can be requests or responses to requests. Table 2-2 lists
SIP requests and describes the purpose of each one.
Table 2-2 SIP Requests
Every SIP transaction begins with a request from a UAC

to a UAS. The UAS begins processing the request as soon
as it is received. The result of this processing depends on
the nature of the request, the formatting of the request,
the state of the server at the time the request was being
serviced, and the general configuration and policies local
to the server. In the case of devices such as SIP proxies,
B2BUAs, and voice gateways, the result of processing a
request could depend on downstream devices.
SIP servers are always required to respond with the

results of request processing. SIP responses use the
following formatting convention:
• The SIP version number (2.0 is the current SIP

version number)
• A three-digit status code (for example, 404)
• A textual description (for example, Not Found)
The three-digit status code is an integer that

communicates the outcome of request processing and is
used for machine interpretation. The textual description,
on the other hand, is for human observers and is useful
in call failure debugging and call record interpretation.
The first digit of the status code indicates the SIP
response class; there are six classes in all (see Table 2-3).
Table 2-3 SIP Response Classes
Breaking Down a SIP Call

Before diving into the details of how a communication
session over SIP is established, it is important to get a
sense of how the initiator of a request—the UAC—forms
the request and how the UAS ultimately processes the
request. The following subsections take a detailed look at
how SIP requests and responses are created.
Forming a Request
Standards-based SIP requires that a request contain at
least the following header fields:
• Request-URI
• Via
• From
• To
• Call-ID
• Max-Forwards
• CSeq
Subsequent sections discuss these header fields in more

detail, and subsequent chapters introduce several other
header fields used for specific applications. The header
fields that appear in a request can vary depending on the
type of request (refer to Table 2-4). For example, a SIP
INVITE request would require additional header fields in
comparison to a SIP REGISTER request.
Example 2-1 illustrates all of the items discussed in this

section. This example shows a SIP INVITE sourced from
a Cisco 8865 SIP IP phone acting as a UAC. This INVITE
is sent to Unified CM as the UAS for the call. Here you
can see the mandatory SIP header fields, such Request-
URI, along with Via, From, To, Call-ID, Max-Forwards,
and CSeq. This example also shows the required SIP
INVITE fields, such as Contact, Allow, Supported, and
Accept. Finally, it shows the optional headers, such as
User-Agent, Session-ID, Expires, and Remote-Party-ID.
These headers and their usage are covered after Example
2-1.
Example 2-1 Sample SIP INVITE from a Cisco 8865

SIP IP Phone
INVITE sip:2001@rtp-cucm.ccnpcollab.lab;user=phone SI
Via: SIP/2.0/TCP 14.50.214.109:49850;branch=z9hG4bK43
From: “+14085557890” <sip:+14085557890@rtp-cucm.ccnpc
To: <sip:2001@rtp-cucm.ccnpcollab.lab>
Call-ID: c4b36aba-ca23000e-14159e9e-1b38e718@14.50.21
Session-ID: 735c6c0600105000a000c4b36abaca23;remote=0
Max-Forwards: 70
CSeq: 101 INVITE
Contact: <sip:+14085557890@14.50.214.109:49850;transp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REG
Supported: replaces,join,sdp-anat,norefersub,resource
Accept: application/sdp
User-Agent: Cisco-CP8865/12.7.1
Expires: 180
Remote-Party-ID: “+14085557890” <sip:+14085557890@rtp
Several mandatory SIP headers appear in all requests:
• Request-URI: In general, each resource within a

SIP network is identified by a URI, which is
expressed either as a SIP URI or a SIPS URI (SIP
Secure URI). Specifically, within the scope of a SIP
request, the Request URI header identifies the
resource that processes the request.
Note
In real-world networks, there could be several devices between the UAC and
UAS, such as call agents, SIP proxies, and SBCs. While a proxy cannot alter
the Request-URI, devices such as SBCs and call agents can modify and
transform the Request-URI, if required by local policy or configuration.
• Via: This header field indicates the transport layer

protocol used for exchanging SIP messages and the
location to which responses must be sent. For
example, the following Via header field specifies
UDP as the transport layer protocol and
10.1.1.1:5060 as the address/port pair for
responses:
Via: SIP/2.0/UDP
10.1.1.1:5060;branch=z9hG4bK2D1F9D1C08
Also included in the Via header field is the branch

parameter, which serves as an identifier for the SIP
transaction created by any request and remains the
same from the perspective of the UAC and the UAS.
The branch parameter, which is unique across
space and time, is valid until the termination of a
SIP transaction. Subsequent requests that create
new transactions must ensure that they generate
new and unique values for this parameter. When a
SIP proxy handles a request, such as a SIP INVITE,
it inserts a Via header field before forwarding the
request to the next hop. The next hop could be
another proxy server or the eventual destination
that processes the request. A request traversing
proxies has more than one Via header field value.
• From: This header field indicates the logical

identity of the user agent that initiates the request.
The From header field carries the identity of the
initiator of the request in the form of a URI.
Optionally, this header field can also include the
display name of the initiator. For media sessions
established over SIP, the display name in the From
header field serves as a caller ID assertion.
Intermediary devices such as SBCs usually
transform the contents of the From header field.
This might be required for a myriad of reasons,
such as to enable interoperability across different
SIP networks, provide topology abstraction, or
make identity assertions. The From header field
must carry a tag parameter. (The significance of the
tag parameter is explained shortly.)
• To: This header field usually identifies the logical

entity that is supposed to process the request and is
populated using a sip URI/SIPS URI or a tel URI.
The logical entity identified in the To header field
may or may not be the actual UAS that processes
the request. In fact, the entity identified in the To
header field usually isn’t the one to process the
request when the request traverses several hops.
Dialog-creating requests (such as SIP INVITE)
must never carry a tag parameter in the To header
field. Instead, the tag parameter is populated by the
user agent that processes the request.
• Call-ID: This header field uniquely identifies all

messages that belong to a SIP dialog; the SIP dialog
in turn is uniquely identified by the combination of
the Call-ID header, the From tag, and the To tag. A
SIP dialog may contain several SIP transactions.
The Call-ID header field value is created by the
UAC and retained in messages sent by the UAS.
The Call-ID must be unique across space and time.
User agents must ensure that this header field is
generated with sufficient entropy to ensure that
there isn’t any overlap with the Call-ID field of
another SIP dialog. The Call-ID header field can
sometimes carry the IP addressing information or
domain name details of the initiating user agent,
which might be undesirable in terms of topology
abstraction. As discussed in subsequent sections,
SBCs overcome this problem by overwriting the
Call-ID header field value and preventing any
internal network topology information from
crossing network boundaries.
• Max-Forwards: This header field value limits the

number of hops a request can traverse before it
reaches its final destination. Every node that
receives a request either partially or completely
processes a SIP request. Partial processing could
include running syntactical checks, adding header
fields, or occasionally modifying a request before it
is passed on to the next hop. Complete processing
of the request, on the other hand, involves sending
one or more of the six response classes listed in
Table 2-3 after processing the request. Every node
that partially processes the request decrements the
Max-Forwards header field value by one before
sending the request to the next hop. If a request is
received at a user agent or a proxy that is not the
final destination of the request, an explicit check is
run on the value of the Max-Forwards header field.
If it is 0, the request is rejected with a 483 Too
Many Hops response. If it is a nonzero value, it is
forwarded to the next hop.
• CSeq: This header field is used to order

transactions within a dialog. It is formatted as
follows:
CSeq: <Sequence-Number> <Method>
where <Method> is a SIP request (refer to Table 2-

2).
The header fields listed here are required for every type
of SIP request. However, additional header fields might
also be required, depending on the type of the SIP
method (request). For example, a SIP INVITE requires
additional header fields accompanying the mandatory
header fields to be efficiently processed by the UAS. For
SIP INVITE, the following additional header fields are
required:
• Contact: This header field provides a SIP or SIPS

URI at which the user agent can be contacted for
subsequent requests. For example, consider an
audio call that is already established between a
UAC and a UAS. Due to negotiated session policy or
application interactions, the UAS might need to
send a midsession request to the UAC. To do so, it
uses the SIP or SIPS URI indicated in the Contact
header field. Note that the usage of the Contact
header field is not restricted to INVITE requests
only. This header field is also present in responses
to the SIP INVITE and other SIP methods, when
applicable.
• Allow: It is recommended that the Allow header

field be present within a SIP INVITE. This header
field advertises the different SIP methods that can
be invoked on the UAC within the scope of the
dialog initiated by the SIP INVITE request. Parsing
the Allow header field allows a UAS to understand
the types of requests that can be sent to the UAC
during the SIP dialog. For example, if the UAS
wants to transmit dual-tone multifrequency
(DTMF) information using the SIP INFO message,
it can do so only if the UAC-advertised support for
the SIP INFO message is in the Allow header field
of the INVITE. The following is an example of the
Allow header field:
Alow:INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Although it is recommended for UACs to include

the Allow header field in INVITE requests, there
might be instances when this header field isn’t
included. In such cases, the UAS must not assume
that the UAC does not support any method; rather,
it must be interpreted as the unwillingness of the
UAC to advertise what methods it supports. The
UAS can go ahead and send requests that are
required to further advance the communication
session; however, if the method is unsupported by
the UAC, these requests are rejected by using the
405 Method Not Allowed response.
• Supported: A UAC might use this header field to

enumerate the various extensions to baseline SIP
that it supports. A UAS might apply these
extensions to baseline SIP when responding to the
request. For example, if the UAC includes the timer
extension in the Supported header field, it
advertises support for SIP session refresh. The UAS
might apply this extension to ensure session
liveliness, as per the guidelines of RFC 4028.
Session timers and session refresh operations are
covered in Chapter 9.
• Accept: The UAC might include the Accept header

field to indicate content types that are acceptable to
it in responses to requests or in new requests
within the dialog. This header field allows user
agents to advertise support for various session
description formats.
Although some of the header fields listed here are

optional, they are nonetheless used ubiquitously across
device types and vendors for initiating communication
sessions over SIP. The following header fields might be
added in SIP INVITE requests (although their exclusion
does not deter the SIP session from proceeding
smoothly):
• Require: When included in the SIP INVITE, this

header field enumerates extensions to baseline SIP
using option tags. Each option tag represents a SIP
extension that the server must support in order to
process the request. If the server cannot support a
specific extension, the request is rejected with a
420 Bad Extension response.
• Expires: This header field might be added by a

UAC to limit the validity of an invitation. Once a
communication session is established, this header
field value has no bearing on the amount of time for
which the session can last. The usage of the Expires
header field is method dependent. (As described in
Chapters 9 and 10, this header field has a different
purpose for the SIP REGISTER method.)
• Diversion: This header field is used when a call is

diverted from the original called endpoint to
another endpoint. You will observe a Diversion
header when a call is forwarded in Unified CM by
either the Call Forward No Answer, Call Forward
Busy, or Call Forward All setting for a line. This
header is covered in both Chapters 5 and 8, “CUBE
Call Routing and Digit Manipulation.”
• Remote-Party-ID (RPID): This header field is

primary used for caller identification. The data
from this header field often supersede caller
identification information in other headers, such as
the Contact header or From header, and Cisco IP
phones use this information to display caller ID
information, if present. Another header field that
effectively achieves the same thing is the P-
Asserted-Identity (PAI) field. For more information
about how to configure Unified CM to add these
header fields, see Chapter 5.
Table 2-4 summarizes the mandatory, method-

dependent, and optional headers for a SIP INVITE
message. As mentioned previously, different SIP
methods have different method-dependent and optional
headers.
Table 2-4 Classification of Headers in SIP INVITE

Messages
It is also possible for vendors to include proprietary

header fields in SIP INVITE requests. If such a request
happens to be processed by a device from the same
vendor, any proprietary header field is interpreted to
enable additional functionality. For example, Cisco
devices such as Unified CM, voice gateways, and CUBE
use the Call-Info header field in SIP INVITE messages
(and corresponding responses) to advertise support for
Cisco’s proprietary method of DTMF relay or SIP
unsolicited notify. (For more on this, see Chapter 3.) If a
nonmandatory proprietary header cannot be understood
by a UAS, it is dropped, and processing of the request
continues according to RFC 3261.
Forming a Response
On receiving a SIP request, a UAS performs a sequence
of checks to determine how to respond to the request.
Figure 2-2 illustrates the logic executed on the server to
process a request.
Figure 2-2 SIP Request Processing Logic
The first check executed at the UAS involves whether the

SIP method is supported. SIP methods are nothing but
requests that require a specific action to be executed at
the server. The SIP requests listed in Table 2-2 are all
examples of SIP methods. All SIP user agents that
initiate and support calls support the SIP INVITE
method; however, it is possible for a UAS to not extend
support to all the methods listed in Table 2-2. If a UAS
does not support a given SIP method, it responds to the
corresponding request with a 405 Method Not Allowed
response.
After inspecting whether the method is supported, the

SIP UAS proceeds to check various header fields in the
request. The first header fields to be checked are the To
and Request URI header fields. These header fields are
checked for syntactical correctness and whether the UAS
is indeed the node that is supposed to process the
request. If either check fails, the request is rejected via
the relevant 4XX class of responses.
The next check that is run is to verify whether the

request has been looped—basically, whether the UAS has
already processed exactly this request. Looping of
requests is quite common in SIP networks, especially
when nodes have improperly configured call routing. Call
loops result in the UAS rejecting the request with a 482
Loop Detected response.
If a request is determined to be new, the UAS checks

whether the client has requested special processing of
the request by using the Require header field. This field
specifies extensions to baseline SIP that facilitate specific
application usage paradigms. These extensions are
specified in the form of option tags in the Require header
field. For example, the UAC might include the 100rel
option tag in an INVITE request to ensure that the server
sends provisional responses (101 to 199 responses)
reliably. If a UAS does not support an option tag
specified by the client, it rejects the request with a 420
Bad Extension response. (For more details on the 100rel
option tag, see Chapter 9.)
After the UAS verifies that it supports the extensions

required by the client, the next check performed is to
determine whether it understands the message body
within the request. A request can carry a message body
(typically utilizing SDP) that provides additional details
about the request. If the UAS cannot interpret a message
body within a request, it is rejected.
Finally, in certain cases, a UAS might require the client

to support certain extensions to baseline SIP for the
request to be successfully processed. For example, if the
server requires that provisional responses be sent
reliably when a SIP session is being set up, and the UAC
does not include the 100rel option tag in the Supported
header field, it can reject an INVITE request with a 421
Extension Required response. A UAS should not use the
421 Extension Required response unless it truly cannot
process the request using the constructs of baseline SIP.
Once all the checks are executed at the UAS, further

processing of the request is strictly method dependent.
For example, the same set of rules cannot be used to
process an INVITE request and a REGISTER request.
While processing a SIP INVITE, the following logic is
applied:
• If the INVITE contains an Expires header field, the

UAS must send a final response before the
expiration interval. If it fails to do so, the request is
rejected with a 487 Request Terminated response.
• The received INVITE might be a mid-dialog request

(a Re-INVITE). Unless the server undergoes an
unexpected restart, it maintains state information
for all established dialogs. Mid-dialog requests are
usually sent to modify session characteristics or
ensure session freshness. For such requests, the
processing rules of Section 12.2.2 of RFC 3261 are
followed.
• A mid-dialog INVITE request received at the UAS

might not match an existing dialog. This could be
because of an unexpected server restart, where all
dialog contexts are purged, or it might be a result of
incorrect request routing by downstream devices.
Whatever the underlying cause, the guidelines of
Section 12.2.2 of RFC 3261 are followed to handle
such a situation.
If the SIP INVITE is not a mid-dialog request but rather

is a dialog-creating request, the UAS is being invited to a
communication session. When processing such a
request, the UAS can either indicate progress, failure, or
success of the request. Alternatively, the request could be
redirected:
• Progress: If the UAS cannot immediately send a

final response to the SIP INVITE message, it can
indicate some kind of progress to the request by
sending a provisional response between 101 and
199. Commonly used progress indications include
the SIP 180 Ringing and 183 Session Progress
provisional responses. Provisional responses are
classified as early dialog responses and require the
UAS to populate the tag parameter of the To header
field in the response. A provisional response is
usually followed by a 200 OK final response or, in
rare cases, a failure response.
• Failure: If the UAS is unable to accept the session

invitation, a failure response is sent to the client.
Processing of the request at the server may fail for a
number of reasons. The server could be overloaded,
in which case it sends a 503 Service Unavailable
response, or it might be that the server could not
locate the device specified in the Request URI, in
which case it responds with a 404 Not Found
response. Whatever the reason, the server responds
to the request with an error code that reflects the
outcome of processing. The failure response might
occasionally carry supplementary information to
provide more granular details of the failure and to
allow the client to augment the request, if
applicable.
As an example, if the server sends a 503 Service
Unavailable response, it can also choose to include
a Retry-After header field that provides the client a
time after which the request may be retried. If the
overloaded condition at the server clears after the
specified time interval, the server might respond
with a success response.
• Success: The session invitation being accepted at

the UAS generates a 200 OK response. It is
recommended that the 200 response include the
Allow, Supported, and Accept header fields.
Inclusion of these header fields ensures that the
server can advertise any extensions to baseline SIP
that it supports without having to be explicitly
probed, perhaps via a SIP OPTIONS message.
Even if the SIP INVITE did not carry a SDP body,

the server must include an SDP offer in the 200 OK
response. If the INVITE carried an SDP offer, the
UAS must include an SDP answer in the 200 OK
response if it was not already included in a previous
message, such as a 180 Ringing or a 183 Session
Progress.
If an SDP body was included in the 18X message

and then later in the 200 OK message, the SDP
body and the originator version must be the same
across both the messages. It is forbidden for the
UAS to alter the contents of the SDP body between
18X and 200 OK messages. (The SDP originator
version number is explained in greater detail later
in this chapter, in the section “Introduction to
SDP.”)
200 OK responses to the SIP INVITE must be

followed by a SIP ACK method. This ensures that
the 200 OK response was delivered reliably.
• Redirect: A UAS can respond to INVITE requests

with a redirect response (3XX). On receiving a
redirect response, the client is required to execute
an additional set of actions to complete the request.
This usually entails the client parsing the Contact
header field of the redirect response and sending
the INVITE message to one or more URIs included
in the Contact header field.
When multimedia communication networks peer over

SIP, more often than not, 3XX redirect responses are
viewed as attempts at toll fraud attacks. Consequently,
on receiving a 3XX response, a user agent may terminate
the request completely instead of try to further process
the request.
Continuing with the transaction started in Example 2-1,

Example 2-2 shows the subsequent 200 OK response to
that INVITE message. Many of the same header fields
observed in the original INVITE are present in this
message. The To and From header fields remain
unchanged except for a tag that is postfixed on the To
header field. This tag is used to identify the specific UAS
in the SIP dialog. All future requests and responses
between these two UAs should include this To header
tag. The Remote-Party-ID and Contact headers will be
updated to reflect the appropriate information of the
called endpoint or UA handling the request on behalf of
the remote endpoint. The Call-ID header will remain the
same as seen in the INVITE message, and the CSeq
header for this message will reference the same CSeq
header of the INVITE request since this is a response to
that specific request. The Allow header and Supported
header are included to inform the UAC of the allowed
request methods and the supported SIP extensions.
Note
During the INVITE transaction, this message always contains SDP; however, it
has been removed here for the sake of simplicity and brevity.
Example 2-2 200 OK Response from Unified CM to

INVITE Sent by the IP Phone
SIP/2.0 200 OK
From: “+14085557890” <sip:+14085557890@rtp-cucm.ccnpc
To: <sip:2001@rtp-cucm.ccnpcollab.lab>;tag=279932
Call-ID: c4b36aba-ca23000e-14159e9e-1b38e718@14.50.21
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK
Supported: replaces
Server: Cisco-CUCM12.5
Remote-Party-ID: <sip:2001@172.18.110.91>;party=calle
Session-ID: 0f3add4b00105000a000d0ec35ffeafe;remote=7
Contact: <sip:2001@172.18.110.91:5060;transport=tcp>
Analyzing a Basic SIP Call

A SIP call begins when a UAC invites a UAS to a
communication session. In real-world implementations,
the two user agents might be separated over several
hops. However, for the sake of simplicity, let’s assume
that the two user agents communicate directly with one
another.
When inviting another user agent to a communication

session, the UAC might be preconfigured with the exact
location of the UAS. If not, its request might be ferried by
a SIP proxy server to the intended UAS. When the
request is received at the UAS, the UAS allocates the
necessary resources to process the request. As the
request is being processed, the UAS might be required to
send provisional responses. It must send a final response
once the request is fully processed to alert the UAC of the
outcome.
Based on the results of request processing, the server

responds with any one of the six classes of response
codes listed in Table 2-3. Depending on the request, the
UAS may respond with a provisional response class
(1XX) followed by a final response class, or it may
respond directly with a final response class. For example,
when processing a SIP INVITE, the UAS typically sends a
100 Trying provisional response, followed by a final
response. The provisional 100 Trying response alerts the
UAC that the request is currently being processed, and a
final response is expected shortly. It also serves as a
mechanism to deter the UAC from sending subsequent
copies of the same SIP INVITE.
Figure 2-3 demonstrates a SIP message exchange for

establishing an audio call between Phone A and Phone B.
A call agent, like Cisco’s Unified Communication
Manager (commonly known as Unified CM), is the
signaling focus for both phones and aids in the
establishment of the communication session. The SIP
call in Figure 2-3 involves the following steps:
Figure 2-3 Analyzing a Basic SIP Call
Step 1. Phone A initiates a communication session

with Phone B by sending a SIP INVITE
message to Unified CM. In this scenario,
Unified CM functions as both the registrar
server for the phones and their UAS for all
outbound requests.
Step 2. Included in the SIP INVITE are several

pieces of information that enable the
transaction/dialog to progress smoothly.
These pieces of information include several
header field values in the SIP message. The
SIP INVITE can be sent in one of two ways:
• With an SDP body

• Without an SDP body
If the SIP INVITE carries an SDP body, the

call is classified as an “early offer” call. If an
SDP body is not advertised in the SIP
INVITE, the call is classified as a “delayed
offer” call. As discussed shortly, SDP is used
to encode the characteristics of a media
session, such as the type of media stream(s)
supported (for example, audio, video), the IP
addresses and port numbers for the media
stream(s), and the set of supported codecs for
different media stream types.
Sending an early offer INVITE allows the

UAC to enforce characteristics of the session
up front by including its supported media
stream types, the relevant media formats per
media stream, and any SDP-based
extensions. With delayed offer INVITE
messages, the UAC has to tailor its session
characteristics in accordance with the SDP
body advertised by the UAS. The example
shown in Figure 2-3 illustrates an early offer
call.
Step 3. On receiving the SIP INVITE message,

Unified CM sends a 100 Trying response to
Phone A. The 100 Trying response serves to
inform Phone A that the INVITE has been
received, and processing is under way. After
sending the 100 Trying response, Unified CM
examines the Request URI in the received
INVITE message and does a database lookup.
The database lookup is done to determine the
location information (IP address and port) of
Phone B. The location information for Phone
B is present in Unified CM because it also
functions as a registrar server.
Step 4. On obtaining the location information of

Phone B, Unified CM operates as a SIP
B2BUA, and a SIP INVITE is sent from
Unified CM to Phone B. Phone B sends a 100
Trying response to Unified CM.
Step 5. After the request is completely processed at

Phone B and it begins ringing, a 180 Ringing
message is sent to Unified CM. The 180
Ringing message is then relayed from Unified
CM to Phone A. At this stage, an audible
ringback tone must be generated at Phone A.
The ringback tone might be generated locally
on the phone or might be generated by
Unified CM. Alternatively, if Phone B wants
to stream a custom ringback tone or pre-
connect announcement, it sends a 183
Session Progress message with an SDP body.
This scenario, defined as “early media,”
allows Phone A to listen to media packets
encapsulating custom ringback tones or pre-
connect announcements even before Phone B
goes off-hook. For more information about
early media and ringback, see Chapter 9.
Step 6. Once Phone B is taken off-hook, a 200 OK

response is sent to Unified CM, indicating
that the call has been answered. Included in
the 200 OK is an SDP body indicating the
chosen media stream(s) and media codecs.
The 200 OK response is then sent to Phone A.
At this stage, the phones can begin to
exchange media packets with one another.
The 200 OK response must be followed by a
SIP ACK sent end-to-end to indicate that the
200 OK response was reliably received.
At this stage, the SIP dialog is considered
complete. You should note that Unified CM is
only responsible for setting up the
communication session but does not place
itself in the path of the media packets.
Step 7. The SIP call terminates when one of the

phones transmits a SIP BYE message.
INTRODUCTION TO SDP
In the earlier days of Internet telephony, the process of
setting up a call was very cumbersome and drawn out—
very unlike the seamless call setup we experience today.
To set up a communication session in the early days,
participants had to do the following:
Step 1. The caller would bootstrap an audio or video

application at a specific port number and IP
address.
Step 2. The caller would inform the callee of the

details of the port number and IP address
over a PSTN line.
Step 3. The callee would fire up a local audio or

video application and inform the caller of the
IP address and port number on her end.
While this process was acceptable for the occasional calls

made over packet networks for the purpose of research
and demonstration, it clearly would not find acceptance
if Internet telephony were to scale. Protocols were
needed to set up, modify, and tear down communication
sessions, and these protocols needed to provide enough
information to allow participation within the
communication session. SIP, as a call control protocol, is
adept at setting up and tearing down communication
sessions. However, it does not provide participants any
information about the details of the communication
session (for example, the media types supported and the
IP/port pair for media). As a result, SIP needs to work in
concert with a peer protocol to facilitate advertisement
and negotiation of media capabilities.
Session Description Protocol (SDP), originally

defined in RFC 2327 (and later updated in RFC 4566),
was designed to provide session details (such as the
media types, media codec, and IP/port pair for media)
and session metadata (such as the purpose of the session
and the originator of the session) to participants. SDP is
strictly a description protocol and is used in concert with
higher-level protocols such as Session Announcement
Protocol (SAP), Session Initiation Protocol (SIP), Media
Gateway Control Protocol (MGCP), Real Time Streaming
Protocol (RTSP), Multipurpose Internet Mail Extensions
(MIME), and Hypertext Transfer Protocol (HTTP).
SDP is completely textual and rigid in terms of

formatting. Unlike H.323, it does not use binary
encoding, such as ASN.1. This choice was made
deliberately so that SDP could be used in concert with a
plurality of protocols and to ensure that malformed SDP
bodies could be easily identified and discarded. The
formatting of SDP bodies is mostly in UTF-8. SDP bodies
contain a number of textual lines that are each either
classified as fields or as attributes. A field is separated
from the next one by a carriage return/line feed (CRLF)
sequence. The format of each field is as follows:
<type>=<value>[CRLF]
Attributes are the primary means of extending SDP. Over

time, to enable several application usage paradigms and
to enable smooth interoperability between
communicating entities, many SDP attributes were
defined and standardized. (At the time of this writing,
there are a few new SDP attributes in the process of
being standardized by the IETF.) Attributes can be of two
types:
• Property attributes: These attributes are in the
format a=<flag>. A property attribute conveys a
simple Boolean meaning for media or the session.
• Value attributes: These attributes are in the

format a=<attribute>:<value>.
The primary purpose of an SDP body is to always ensure

that the participants are provided sufficient information
to join a communication session. Accordingly, SDP
bodies are classified into three description levels:
• Session description
• Time description
• Media description
The session description consists of a number of fields

and optional attributes that provide details around the
session, such as the name of the session, the originator of
the session, and bandwidth constraints for the session.
The session description can optionally contain attributes
as well.
Communication sessions can either be unbounded or

bounded in time. SDP time descriptions specify when
communication sessions are active by using the timing
(t=) field. The timing field has the following format:
t=<start-time> <stop-time>
This field is self-explanatory: start-time and stop-time

simply encode the time when the session starts and ends,
respectively. start-time and stop-time are expressed in
decimal representations of Network Time Protocol (NTP)
time values in seconds since 1900. The encoding of the
start-time and stop-time determines whether the
communication session is bounded, unbounded, or
permanent. A bounded session has an explicit start-time
and stop-time. An unbounded session does not have a
stop-time, whereas a permanent session does not have a
start-time or stop-time. The encoding of the timing field
is useful for multicast communication sessions. For
unicast sessions, the timing field must be encoded to
specify a permanent session (t=0 0).
The media description section of SDP bodies provides

sufficient detail about the media and transport
characteristics of the communication session.
Participants use this information to join a multicast
session or negotiate common capabilities for unicast
sessions. The media description section includes the
following information:
• The media types (for example, audio, video,

application, image)
• The transport protocol (for example, RTP)
• The media formats for different media types (for

example, G711, H.264)
• Optionally, the IP address and port pair for media
Fields and attributes in SDP bodies can be either

mandatory or optional. In either case, they must follow
the rigid ordering structure shown in Table 2-5.
Table 2-5 Fields and Attributes in SDP Bodies

SDP fields and attributes can appear at two levels:
• Session level
• Media level
The session-level section of SDP bodies provides default

values for various fields that are to be used and
interpreted. For example, if a user agent wants to use the
same media connection IP address for all media streams
within the session, it can encode an SDP body with a
session-level description of media connection
information. However, if further granularity is required
on a per-media-stream basis, the user agent can encode
an SDP body with one or several media-level
descriptions. Example 2-3 is a snippet of an SDP body
carried within a SIP message. (The actual SIP message is
omitted from this example for brevity.)
Example 2-3 SDP Body Carried Within a SIP Message
v=0
o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly
m=audio 16590 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
m=video 51372 RTP/AVP 126
a=rtpmap:126 H264/90000
The session-level description starts with the v= line and

continues until the first media-level section. Every
media-level section is identified by an m= line and
continues until the next m= line or until the end of the
SDP body. As shown in Example 2-3, the media
connection IP address (c=IN IP4 10.1.1.1) has only a
session-level description, and it spans the audio and
video stream. In addition to having a media connection
information field, the direction attribute (a=recvonly) is
specified for both the audio and video media streams.
Session-level descriptions serve as default values to be
interpreted and used if no corresponding media-level
description(s) is available.
Example 2-4 is a snippet of an SDP body where the

direction attribute has a session-level description and a
media-level description. You should be aware that
certain SDP fields and attributes can be present
concurrently at different levels of the SDP body. When
this occurs, the media-level field or attribute overrides
the session-level field or attribute. So, in the case of the
direction attribute appearing twice in Example 2-4, the
media-level description of the direction attribute is given
higher precedence.
Example 2-4 SDP Body with Session- and Media-Level

Definitions for the Direction Attribute
v=0
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly

a=fmtp:101 0-15
a=sendrecv
a=ptime:20
The Offer/Answer Framework

SDP was originally conceived as a way to describe
multicast sessions over Mbone (short for multicast
backbone). SDP scales really well for multicast, as there
is a unified view of the session for all participants. For
example, for multicast communication sessions, each
participant requires a single media address and port to
join a communication session. While SDP has the
capability of describing unicast communication sessions,
it is a slightly more challenging proposition than
describing multicast sessions. For a unicast session
between two participants, each participant has a
localized view of the session; each participant has its own
media IP address and port pair, its own set of supported
media types, and its own set of supported codecs per
media type. To obtain a complete view of a unicast
session, the participants must exchange information
elements and agree on a common set of parameters. The
SDP offer/answer model, defined in RFC 3264, provides
such a framework for information exchange and
parameter negotiation. To get a better understanding of
the offer/answer framework, it is important to
understand certain terms that are frequently referenced
in subsequent sections:
• Agent: An entity involved in an offer/answer

exchange
• Answerer: An agent that receives a session

description that describes aspects of a plausible
media communication session and responds with
its own session description
• Answer: An SDP message sent from an answerer

to an offerer
• Offerer: An agent that generates a session

description to create or modify a session
• Offer: An SDP message sent by an offerer
• Media Stream: A single media instance in a

communication session
Operation of the Offer/Answer Framework

The offer/answer exchange requires the existence of a
stateful, higher-level protocol such as SIP that is capable
of exchanging SDP bodies during call setup and/or
modification. The protocol has to be stateful to maintain
context around the exchange between an offerer and an
answerer, as there may be several SDP exchanges during
the course of a call. It is important for the higher-level
protocol to accurately map requests and responses.
Generating the SDP Offer and Answer

The SDP offer/answer model begins with one of the user
agents constructing an SDP body according to the
guidelines of RFC 4566. You should realize that the
initiator of a communication session (the user agent that
sends the SIP INVITE) need not always be the one
constructing the SDP offer. For example, for SIP delayed
offer calls, the user agent being invited to a
communication session is the one that constructs the
SDP offer. Figure 2-4 shows the SIP three-way
handshake for a delayed offer call versus the same
handshake for an early offer call.
Figure 2-4 SIP Delayed Offer Versus SIP Early Offer
Regardless of which user agent constructs the offer, the

SDP body must consist of a session description, a time
description, and a media description section. This strict
encoding format ensures that the peer user agent is
provided sufficient information to participate in the
communication session. The session description section
contains all the mandatory fields (for example, v, o, s) as
well as optional attribute values. For unicast sessions,
the time description section must contain a timing field
to indicate a permanent session (t=0 0). The media
description section of the SDP offer can contain several
media lines (m=), such that each media line corresponds
to different media types or they correspond to the same
media type or a combination of the two.
Each media line in the SDP body must encode sufficient
information about the media stream to convey the
following:
• The media type of the stream (for example, audio,

video, image)
• The transport port and IP address of the media

stream
• The list of media formats per media stream
The format of any media line within an SDP body is as

follows:
m=<media> <port> <proto> <fmt list>
The <media> subfield indicates the media type, such as

audio, video, image, and so on. The possible set of media
types that can be advertised in SDP bodies is maintained
in the Media Type registry of the Internet Assigned
Numbers Authority.
The <port> subfield is used to encode the port number

on which media reception is expected. It is a common
misconception that the port number encodes the port
number from which media is sourced. For media
transport protocols such as RTP, the peer protocol Real-
Time Transport Control Protocol (RTCP) allows
participants to provide real-time media reception quality
feedback. By default, RTCP is exchanged on the next
higher port number following the RTP port number. If
for some reason an application does not want to
exchange RTCP on the next higher port number
following RTP, it can explicitly indicate this by using the
a=rtcp attribute. Example 2-5 demonstrates the use of
the a=rtcp attribute in an SDP body.
Example 2-5 SDP Body Demonstrating the Use of the

a=rtcp Attribute
v=0
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly
a=rtcp:53020
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
The <port> subfield is useful only when interpreted and

used in conjunction with the connection data (c=) field.
Without the connection data field, the remote user agent
is only aware of a port number and has no information
about the remote IP address. The connection data field
can be scoped to include a session-level or media-level
definition.
The <proto> subfield identifies the transport protocol for

media. For media encapsulated over RTP, this subfield is
set to RTP/AVP or, optionally, to RTP/SAVP for Secure
RTP (SRTP). AVP stands for audio/video profile, and
SAVP stands for secure audio/video profile.
The <fmt list> subfield specifies the media formats

supported by the user agent generating the SDP body.
The encoding of this subfield depends on the value of the
<proto> subfield, which is either set to RTP/AVP or
RTP/SAVP and includes a list of payload numbers (or
sometimes only one payload number). For applications
to discern the media format to which a given payload
number corresponds, there is a list of payload number-
to-media format mappings defined in the RTP audio/
video profile. Table 2-6 lists a selection of these
mappings for common audio codecs.
Note
A comprehensive list of the mappings of all payload numbers to media formats
is maintained in an Internet Assigned Numbers Authority registry at
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml.
Table 2-6 Mapping Between Payload Numbers and

Media Formats for Common Audio Codecs
In the case of dynamic payload numbers (payload

numbers between 96 and 127), there has to be an explicit
mapping specified in the SDP body, using the a=rtpmap
attribute. While it is not required to use the a=rtpmap
attribute for static assignments already specified in the
RTP audio/video profile, it seems to be the preferred
formatting choice for most vendors.
To better understand this concept, see the sample SDP

body provided in Example 2-6. The media line (m=) lists
three static payload numbers: 0, 8, and 18. For a user
agent that receives this SDP body, the interpretation of
the static payload numbers 0, 8, and 18 is provided by
the RTP audio/video profile and translates to PCMU,
PCMA, and G729, respectively (refer to Table 2-6).
Providing a mapping between these static payload
numbers and their corresponding media formats via the
a=rtpmap attribute is a redundant but nonetheless
ubiquitous construct. For dynamic payload numbers,
such as the OPUS codec utilizing payload type 114, the
a=rtpmap attribute is required to explicitly provide a
binding to the media format.
Example 2-6 SDP Body Demonstrating the Use of the
a=rtpmap Attribute
v=0
o=CiscoSystemsCCM-SIP 2828060 1 IN IP4 10.1.1.1
s=SIP Call
c=IN IP4 10.1.1.1
b=TIAS:64000
b=AS:64
t=0 0
m=audio 17236 RTP/AVP 0 8 18 114
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:114 opus/48000/2
a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerat
The a=fmtp attribute shown in Example 2-6 is used to

encode media format–specific parameters. For example,
when using the OPUS codec, many attributes can be
utilized. One example defined here is the maximum
average bitrate for the session via the maxaveragebitrate
attribute. As the example shows, many attributes can be
applied to a given media format on a single line by using
the semicolon (;) as a separator. These attributes vary
per media format, so refer to the applicable media format
standard for a=fmtp usage.
Media lines have their interpretations tightly coupled

with the SDP direction attribute. A direction attribute
can have a session-level scope or a media-level scope. For
unicast streams, the offerer can specify the directionality
of a media stream by using the SDP direction attribute.
Accordingly, a stream can be marked as sendonly,
recvonly, inactive, or sendrecv. Table 2-7 summarizes the
implications of the different ways in which the direction
attribute can be encoded.
Table 2-7 SDP Direction Attributes Description
When the direction attribute has a sendrecv or recvonly

value, it signifies the IP address and port number on
which the sender would expect to receive media (RTP)
from its peer. If the direction attribute is marked as
sendonly, it indirectly signifies the IP address and port
on which the sender (of the SDP) expects to receive
RTCP but not RTP.
As mentioned previously, the IP address and port listed

in the SDP offer does not signify the source address and
port for RTP packets. Instead, it signifies the address and
port on which the offerer expects to receive media.
If a user agent sets the direction attribute to inactive, it

means that the user agent wants to simply establish a
communication session without transmitting or receiving
media. However, at a later time, the user agent can
initiate a new SDP offer/answer exchange to update the
direction attribute. Regardless of the value of the
direction attribute, there is a continuous passage of
RTCP traffic between communicating entities. While
constructing an SDP body, if the user agent does not
specify an explicit value for the direction attribute, it
always defaults to sendrecv.
As mentioned earlier, the user agent constructing the

SDP offer can include one or more media lines such that
the media lines can correspond to the same media type,
different media types, or a combination of the two.
Conventionally, the offerer must use a valid, nonzero
port number for each media line within the offer. This is
because the use of port zero for a media line(s) within the
offer has no useful semantics.
On receiving the offer, the answerer must construct an

SDP body following the guidelines of RFC 4566: It must
include a session description, a time description, and a
media description. Even if there is absolute parity
between the offer and the answer in terms of the media
streams and media formats per stream, it is reasonable
to assume that the answer will differ from the offer on
certain aspects such as the IP address and port pair for
media, support for SDP extensions, and so on. In such
instances, the origin line (o=) of the answer must be
different from that of the offer. The timing field in the
answer must mirror the timing field in the offer. With
regard to the media description, the constructed answer
must follow several rules that are discussed in more
detail in the following paragraphs.
While constructing the answer, the answerer must

generate a response to each media line listed in the offer,
and the number of media lines in the offer and answer
must always be the same. If a given media type in the
offer is not supported by the answerer, the answerer
must reject the corresponding media line by setting the
port number to zero. If an answerer rejects a media
stream, there is no RTCP traffic exchanged for that
media stream. Example 2-7 demonstrates an
offer/answer exchange where the video media type is
rejected by the answerer.
Example 2-7 SDP Offer/Answer Exchange for

Disabling Video
[Offer]
v=0
o=Cisco-SIPUA 23226 0 IN IP4 14.50.214.109
s=SIP Call
c=IN IP4 14.50.214.109
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 126 97
c=IN IP4 14.50.214.109

b=TIAS:4000000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428016;packetization-mode
a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428016;packetization-mode=
[Answer]
v=0
s=SIP Call
c=IN IP4 14.50.214.107
b=AS:384
t=0 0
m=audio 49172 RTP/AVP 8
a=rtpmap:126 H264/90000
Note
If there are no media formats in common for all streams, the entire offered
session is rejected.
As discussed previously, an offerer can set the direction
attribute (at the session level or media level) to sendrecv,
sendonly, recvonly, or inactive. Table 2-8 highlights the
different ways in which the direction attribute can be set
in an answer for unicast media sessions.
Table 2-8 Different Ways of Setting the Direction

Attribute in an Answer
For streams that are marked as recvonly in the answer,

the answer must contain at least one media format that
was listed in the offer. In addition, the answerer may
include media formats not listed in the offer that the
answerer is willing to receive. This is useful in scenarios
where the offerer proceeds to modify the communication
session at a later stage and includes an updated media
format list.
For streams that the answerer marked as sendonly, the

answer must contain at least one media format that was
listed in the offer. For streams marked as sendrecv in the
answer, the answer must list at least one media format
that it is willing to use for both sending and receiving
media. In such a situation, the answer might also list
media formats that were not a part of the offer. Again,
this is useful in scenarios where the offerer proceeds to
modify the communication session at a later stage and
includes an updated media format list. For streams
marked as inactive in the answer, the media format list
in the answer mirrors that in the offer.
Note
Media formats in the offer and answer are always listed in decreasing order of
precedence, from left to right.
It is required for the answerer to use the a=rtpmap

attribute for each media format to provide a payload
number to the media format binding—regardless of
whether the answer contains static or dynamic payload
numbers. If a media format in the offer is described
using the a=fmtp attribute, and that media format is
echoed in the answer, the answerer must ensure that the
same fmtp parameters are listed.
Note
The offer and answer can optionally include bandwidth and packetization
interval attributes. For more on packetization intervals, see Chapter 3.
Media lines marked as sendonly and recvonly by the

offerer have a reverse interpretation when accepted by
the answerer. For example, consider an offer where the
audio media line is marked as sendonly. When accepted
by the answerer, the same audio media line has to be
marked as recvonly. This ensures that the offer/answer
exchange concludes with both user agents converging on
a unified view of the communication session. In this
case, the offerer only transmits media packets, while the
answerer only receives media packets. Of course, this
assumes that the answerer does not set the stream as
inactive.
Modifying a Session
During the course of a communication session, it is not
uncommon for application interactions to require
modification of session characteristics. These
modifications could include changing the media formats,
changing the value of the direction attribute, adding new
media streams, and removing existing media streams, for
instance. Some examples of scenarios where
modifications occur are during supplementary service
actions such as call hold, resume, transfer, and even
conferencing. Nearly all aspects of a communication
session can be modified. To effect a change or
modification of session characteristics, the two user
agents must engage in a new SDP offer/answer
exchange. The high-level flow of modifying a
communication session is depicted in Figure 2-5.
Figure 2-5 Modifying a Communication Session by

Using the SDP Offer/Answer Exchange
A user agent attempting to modify a communication

session first constructs an updated SDP body whose
content reflects the modifications required. These
modifications could range from the trivial to the
complex. Regardless of the degree of modification
reflected in the SDP body, the user agent must increment
the version number of the origin field (o=) by one.
Example 2-6 highlights this concept.
The original SDP body in Example 2-8 contains the

version number 5834. Sometime during the course of the
communication session, the user agent requires a change
to the list of media formats and accordingly proceeds to
construct and transmit an updated SDP body. The
updated SDP offer has its version number incremented
by one and a modified media format list in the audio
media line. This example also includes two very
important SIP headers, which are included in the SIP
message to describe and identify the contents of the SIP
message body. For an SDP body, the Content-Type value
application/sdp is used. Similarly, the Content-Length
header field provides the total length of the SDP message
body. If no message body is present in the SIP message,
the Content-Length header field is set to 0. For the sake
of brevity, the SIP header in Example 2-8 only displays
the Content-Type and Content-Length SIP header fields.
Example 2-8 Incrementing the SDP Originator Version

Number
[Original SIP+SDP]
Content-Type: application/sdp
Content-Length: 283
v=0
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:126 H264/90000
[M*odified SIP+SDP]
Content-Length: 227
v=0
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly
a=ptime:20
a=rtpmap:126 H264/90000
It is quite possible for a user agent to initiate a new SDP

offer/answer exchange without changing the contents of
the SDP body. While this exchange doesn’t result in the
modification of session characteristics, it could be used
for reasons such as determining session freshness. If a
new SDP body is identical to the previous SDP body, the
version number must remain the same.
While generating an updated offer, the user agent must

ensure that the number of media lines (m=) equals the
number of media lines in the previous SDP body. In
other words, if the previous SDP body had N media lines,
the updated SDP body must contain at least N media
lines. It is possible for the updated SDP body to contain
more than N media lines since this is required when
adding a new media line.
If SIP is the signaling protocol used to establish a media

session (with SDP message body for media description),
an existing session can be modified using either a re-
INVITE or an UPDATE SIP message. Figure 2-6
illustrates both of these scenarios.
Figure 2-6 SIP re-INVITE and UPDATE Session
Modifications
The following steps occur in the example shown in

Figure 2-6:
Step 1. The initial session is established using an

early offer signaling exchange.
Step 2. An application interaction occurs and

requires a change in media. This then triggers
a mid-call re-INVITE, with a new offer
modifying the original session.
Step 3. The UAS accepts the session modification

and sends a 200 OK with an SDP body.
Step 4. An ACK to the 200 OK confirms the

transaction and finishes the handshake.
Step 5. The session continues with the newly
established session parameters until another
application interaction occurs. At this point,
the session is modified again—this time using
an UPDATE SIP message with an SDP body
containing an offer for the new session.
Step 6. The remote party accepts this UPDATE with

an SDP body via a 200 OK, and an SDP body
confirms the session modification.
Step 7. The session continues with the newly

updated session parameters.
Note
This process of modifying the session through re-INVITE or UPDATE SIP
message can continue as many times as needed by either user agent involved
in the session. Also, note that the UPDATE transaction does not contain an
ACK SIP message because the ACK is exclusive to the INVITE/re-INVITE
transaction.
Adding a Media Stream

It is possible to add new media streams to a session by
appending the appropriate media lines to an existing
SDP body. For example, if an audio-only communication
session is established between two participants and one
of the participants wants to escalate the session to
include video, that participant appends a video media
line (m=video) to the existing SDP body and sends an
updated offer. User agents that want to add a media
stream must always append media lines to existing ones.
This ordering ensures that the peer user agent is able to
gauge any new media line additions. For example,
Example 2-9 shows a session established between a
video-capable phone and a phone that does not support
video. The original video-capable IP phone is then
transferred to another video-capable phone, and a new
video session is added to the existing media sessions.
Example 2-9 Adding a Media Stream

[Initial Call (SIP+SDP) - Offer]
Content-Length: 707
v=0
s=SIP Call
c=IN IP4 14.50.214.107
b=TIAS:64000
b=AS:80
t=0 0
m=audio 23500 RTP/AVP 114 9 124 113 115 0 8 116 18 101
b=TIAS:64000
a=rtpmap:9 G722/8000
a=rtpmap:124 iSAC/16000
a=rtpmap:113 AMR-WB/16000
a=fmtp:113 mode-change-capability=2
a=fmtp:115 octet-align=1;mode-change-capability=2
a=maxptime:20
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=fmtp:101 0-15
[Initial Call (SIP+SDP) - Answer]
Content-Length: 416
v=0
s=SIP Call
c=IN IP4 14.50.214.106
b=TIAS:64000
b=AS:80
t=0 0

b=TIAS:64000
a=fmtp:101 0-15
a=trafficclass:conversational.audio.aq:admitted
[Video Escalation (SIP+SDP) - New Offer]
Content-Length: 1499
v=0
s=SIP Call
c=IN IP4 14.50.214.106
b=TIAS:384000
b=AS:384
t=0 0
m=audio 21040 RTP/AVP 114 9 124 113 115 0 8 116 18 101
b=TIAS:64000
a=rtpmap:9 G722/8000
a=rtpmap:124 iSAC/16000
a=fmtp:113 mode-change-capability=2
a=fmtp:115 octet-align=1;mode-change-capability=2
a=maxptime:20
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=fmtp:101 0-15
a=trafficclass:conversational.audio.avconf.aq:admitte
m=video 29584 RTP/AVP 100 126 97
b=TIAS:384000
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640C16;packetization-mode
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428016;packetization-mode
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428016;packetization-mode=
a=content:main
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=trafficclass:conversational.video.avconf.aq:admitte
[Video Escalation (SIP+SDP) - New Answer]
Content-Length: 830
v=0
s=SIP Call
c=IN IP4 14.50.214.109
b=TIAS:384000
b=AS:384
t=0 0
b=TIAS:64000
a=fmtp:101 0-15
b=TIAS:320000
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640C16;packetization-mode
a=content:main
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=trafficclass:conversational.video.avconf.aq:admitte
It is also possible to add a media stream to a

communication session by activating a previously
disabled media stream. Consider a scenario in which a
user agent attempts to establish a communication
session that includes audio and video media types. If the
peer user agent does not support video, it rejects the
video media line by setting the port to zero (refer to
Example 2-7). During the course of the communication
session, either user agent may decide to reuse the video
media line slot to introduce a new media stream. The
new media stream can have a video media type or any
other valid media type.
Removing a Media Stream

A user agent can remove an existing media stream by
constructing a new SDP body and setting the media port
of the corresponding media stream to zero. When such
an SDP body is received by the peer user agent, it is
treated as a non-negotiable and explicit indication to
disable a given media stream. Therefore, the peer user
agent must construct an answer with the port for the
media stream in question also set to zero.
Media streams that are deleted by an updated SDP

offer/answer exchange cease to exchange RTP or RTCP
traffic. Any resources allocated for such media streams
can be de-allocated.
Note
The concept of zeroing out a port may also be referred to as disabling a media
stream.
Modifying the Address, Port, Transport or Media Format

As mentioned earlier in this chapter, nearly every aspect
of a communication session can be modified. The way in
which media streams can be added and removed using
the SDP offer/answer exchange is discussed in the
previous section. During the course of a communication
session, it may happen that a user agent discovers a new
interface that is known to be more reliable than the
current interface engaged in media transmission and
reception. To ensure that the newly discovered, higher-
priority interface takes over for media transmission and
reception, the user agent has to construct an updated
SDP offer in which the connection information field is
modified to reflect the new interface identity. In most
instances, a modification of the connection information
field proceeds with a change in the port number(s) for a
media line(s), and this is reflected in the update SDP
offer.
Note
There are several other scenarios that require modification of the media IP
address and port. These include, but are not limited to, media redirection from
one endpoint to another, call hold, and call resume.
Even after updating the connection information and

port, a user agent must be prepared to receive media on
the old IP address/port pair for a reasonable amount of
time. This is because the peer user agent has to accept
the updated SDP offer, proceed to process the changes,
and then program its internal software subsystems
accordingly. You should also be aware that it is possible
for an answerer to update its own IP address/port pair in
the answer to an updated offer.
When setting up a communication session, the

participants converge on a media format by using the
SDP information that is exchanged. In addition, it is
perfectly acceptable for a user agent to attempt to change
the media format midsession. Intuitively, it has to do so
by first constructing an updated SDP offer such that the
media line(s) contains a completely new set of media
formats (not present in the previous SDP) or a set of
media formats that partially overlap with the previous
SDP body. The offer can be rejected or accepted by the
answerer. When accepted, the media format used is
determined by the way in which the answer is encoded.
(Refer to the section “Generating the SDP Offer and
Answer,” earlier in this chapter.)
OVERVIEW OF H.323
H.323 is a communication protocol from the ITU-T. It is
a VoIP call control protocol that allows for the
establishment, maintenance, and teardown of
multimedia sessions across H.323 endpoints. H.323 is a
suite of specifications that controls the transmission of
voice, video, and data over IP networks. The following
are some of the H.323 specifications relevant to the
subject matter laid out in this book:
• H.225: H.225 handles call setup and teardown

between H.323 endpoints and is also responsible
for peering with H.323 gatekeepers via the
Registration Admission Status (RAS) protocol.
• H.245: H.245 acts as a peer protocol to H.225

and is used to negotiate the characteristics of the
media session, such as media format, the method of
DTMF relay, the media type (audio, video, fax, and
so on), and the IP address/port pair for media.
• H.450: H.450 controls supplementary services

between H.323 entities. These supplementary
services include call hold, call transfer, call park,
and call pickup.
H.323 Components
The H.323 protocols outlined in the previous section are
used in the communications between H.323 components
or devices. The following are the most common H.323
devices:
• H.323 gateways: H.323 gateways are endpoints

that are capable of interworking between a packet
network and a traditional POTS network (analog or
digital). Since these H.323 endpoints can
implement their own call routing logic, they are
considered to be “intelligent” and, as such, operate
in a peer-to-peer mode. H.323 gateways are capable
of registering to a gatekeeper and interworking calls
with a gatekeeper by using the RAS protocol.
• H.323 gatekeepers: H.323 gatekeepers function

as devices that provide lookup services. They
indicate via signaling to which endpoint or
endpoints a particular called number belongs.
Gatekeepers also provide functionality such as Call
Admission Control and security. Endpoints register
to the gatekeeper by using the RAS protocol.
• H.323 terminals: Any H.323 device that is

capable of setting up a two-way, real-time media
session is an H.323 terminal. H.323 terminals
include voice gateways, H.323 trunks, video
conferencing stations, and IP phones. H.323
terminals use H.225 for session setup, progress,
and teardown. They also use H.245 to define
characteristics of the media session such as the
media format, the method of DTMF, and the media
type.
• Multipoint control units: These H.323 devices

handle multiparty conferences, and each device is
composed of a multipoint controller (MC) and
multipoint processor (MP). The MC is responsible
for H.245 exchanges, and the MP is responsible for
the switching and manipulation of media.
H.323 Call Flow

An H.323 call basically involves the following:
• A TCP socket must be established on port 1720 to

initiate H.225 signaling with another H.323 peer.
This assumes that there is no gatekeeper in the call
flow. As defined in the previous section,
gatekeepers assist in endpoint discovery and call
admission.
• For an H.323 call, the H.225 exchange is

responsible for call setup and termination, whereas
the H.245 exchange is responsible for
establishment of the media channels and their
properties. In most cases, the establishment of two
independent TCP connections is required: one for
the H.225 exchange and the other for the H.245
exchange. To effectively bind the two, the TCP port
number on which the answering terminal intends
to establish an H.245 exchange is advertised in one
of the H.225 messages. The port number can be
advertised before the H.225 connect message is
sent (for example, in an H.225 progress message)
or when the H.225 connect message is sent.
• H.225 and H.245 exchanges can proceed on the

same TCP connection, using a process called H.245
tunneling.
• Every H.245 message is unidirectional in the sense

that it is used to specify the negotiation from the
perspective of the sender of that H.245 message.
For the successful establishment of a two-way real-
time session, both H.323 terminals must exchange
H.245 messages.
Figure 2-7 depicts a basic H.323 slow start call between

two H.323 terminals. The calling terminal first initiates a
TCP connection to the called terminal, using destination
port 1720. Once this connection is established, H.225
messages are exchanged between the two terminals to set
up the call. In order to negotiate parameters that define
call characteristics such as the media types (for example,
audio, video, fax), media formats, and DTMF types, an
H.245 exchange has to ensue between the terminals.
Figure 2-7 Basic H.323 Slow Start Call
In most cases, a separate TCP connection is established

between the endpoints to negotiate an H.245 exchange;
however, in some cases, as an optimization, H.245
messages are tunneled using the same TCP socket as
H.225, using a procedure known as H.245 tunneling.
When utilizing a separate TCP connection for H.245, the
called terminal advertises the TCP port number over
which it intends to establish an H.245 exchange. The
ports used for the establishment of H.245 are ephemeral
and are not dictated by the H.323 specification.
The H.245 exchange results in the establishment of the

media channels required to transmit and receive real-
time information. You should be aware that while Figure
2-7 highlights a slow start call, a variant to the slow start
procedure, known as FastConnect, also exists and is
depicted in Figure 2-8. As the name suggests,
FastConnect is a quicker and more efficient mechanism
to establish an H.323 call. In fact, FastConnect can
establish an H.323 call with as few as two messages. This
is possible because with FastConnect there is no need to
open an H.245 socket, as long as all needed media can be
negotiated via FastConnect.
Note
FastConnect is often improperly referred to as “fast start” or “fastStart,” after
the name of the associated field/element in H.225 messages that is used to
negotiate and establish FastConnect.
Figure 2-8 H.323 FastConnect Call Setup
Figure 2-8 shows how an H.323 FastConnect call is set

up. When transmitting a Call Setup message, the
endpoint populates a field, known as the fastStart
element, with H.245 messages. The called endpoint can
accept FastConnect by selecting any fastStart element in
the Call Setup message, populate the necessary data
fields (as specified in H.323), and return a fastStart
element in any H.225 message (for example, Call
Proceeding, Alerting, Connect) to the caller. The called
endpoint can also reject FastConnect and fall back to the
traditional slow start procedures shown in Figure 2-7 by
either explicitly indicating so (using a flag), initiating any
H.245 communications, or providing an H.245 address
for the purposes of initiating H.245 communications.
REFERENCES
Press, 2018.
RFC 3261, “SIP: Session Initiation Protocol,”

https://tools.ietf.org/html/rfc3261
RFC 3264, “An Offer/Answer Model with the Session

Description Protocol (SDP),”
RFC 4566, “SDP: Session Description Protocol,”

RFC 5853, “Requirements from Session Initiation

Protocol (SIP) Session Border Controller (SBC)
Deployments,” https://tools.ietf.org/html/rfc5853



MEMORY
companion website), includes completed tables and lists
to check your work.
DEFINE KEY TERMS

Session Initiation Protocol (SIP)

Session Description Protocol (SDP)
user agent client (UAC)
user agent server (UAS)
back-to-back user agent (B2BUA)
H.323
H.225
H.245
Chapter 3. VoIP Protocols: RTP,
RTCP, and DTMF Relay
• Introduction to Real-Time Media: This

section lays the groundwork for how analog voice is
digitized and made suitable for transport over an IP
network.
• Real-Time Transport Protocol: This section

provides an introduction to Real-Time Transport
Protocol (RTP) and explains how RTP packets are
formatted.
• Real-Time Transport Control Protocol: This

section covers Real-Time Transport Control
Protocol (RTCP) as a peer protocol to RTP and
discusses various RTCP packet types.
• DTMF Relay: This section provides a brief

introduction to DTMF relay and provides details
about the various methods of DTMF relay used in
real-time communication networks.

exam topics:
• 1.2.a DTMF
• 3.1 Configure these Cisco Unified Border Element

dial plan elements
• 3.1.a DTMF
• 3.2 Troubleshoot these Cisco Unified Border
Element dial plan elements
• 3.2.a DTMF
The transmission of real-time voice and video over an IP

network is complex and requires a comprehensive
framework of protocols to ensure proper operation and a
good user experience. Real-Time Transport Protocol
(RTP) and its complement Real-Time Transport Control
Protocol (RTCP) are foundational components of this
framework. These protocols and their extensions have
seen industrywide adoption as the basis of IP-based real-
time communications.
The transmission of voice and video media streams is an

important aspect of media handling on IP networks, but
there are other elements to consider. For example,
relaying dual-tone multifrequency (DTMF) across an IP
network is vital for call routing and also for navigating
interactive voice response (IVR) menus. The advent of
voice over IP (VoIP) made reliable and distortion-free
transmission of keypad button presses end-to-end
somewhat problematic because audio codecs were not
optimized for carrying DTMF tones. Fortunately, the
industry (led by the IETF and ITU-T) came up with and
standardized several methods of DTMF relay that have
worked remarkably well. This chapter analyzes these
different media plane protocols and operations,
including how voice and video are transported over an IP
network using RTP/RTCP. This chapter also provides an
introduction to the various common methods of DTMF
relay available today.


1. What is the sampling rate of the G.711 audio codec?
a. 8 kHz
b. 64 kHz
c. 8000 kHz
d. 64,000 kHz
2. Which payload types fall within the dynamic range

for RTP? (Choose three.)
a. 0
b. 18
c. 96
d. 114
e. 127
f. 151
3. Which RTP packet header is responsible for assisting

receiver applications with loss detection?
a. SSRC
b. Timestamp
c. Marker Bit
d. Sequence Number
4. In which scenario might the SSRC value for a given

RTP stream change?
a. When a rollover of the RTP Sequence Number field
occurs
b. When the Marker Bit field is set to False
c. When the RTP transport address changes
d. Every 15 minutes
5. What is the recommended amount of bandwidth

allocated to RTCP?
a. 5%
b. 15%
c. 25%
d. 50%
6. Which two SDP attributes are commonly used for

signaling RTCP port information that will be used for
a stream? (Choose two.)
a. a=rtcp
b. a=rtcp-mux
c. a=rtpmap
d. m=
e. c=
7. Which type of DTMF relay method is carried within

RTP packets as a specialized payload?
a. SIP KPML
b. Name telephony events

c. SIP INFO
d. SIP NOTIFY
8. Which of the following are possible payload types for

RTP-NTE DTMF? (Choose two.)
a. 0
b. 8
c. 18
d. 99
e. 101
9. While attempting to establish a new call, which SIP

message contains the first digit dialed by a user of a
SIP Cisco IP phone using SIP KPML to send digits to
Unified CM?
a. INVITE
b. SUBSCRIBE
c. NOTIFY
d. 200 OK
10. When troubleshooting out-of-band DTMF issues,

where should an administrator focus his or her
efforts?
a. The RTP media packets
b. The RTP-NTE packets
c. The call setup signaling
d. The firewall
FOUNDATION TOPICS
INTRODUCTION TO REAL-TIME MEDIA

The ability to communicate in real time over an IP
network was a major advancement and is the foundation
for voice over IP technologies. Communication over an
IP network requires a mechanism to transform the
analog voice signal from a telephone into a digital
format. Interestingly, this analog-to-digital conversion of
voice has been around for a long time and is also the
basis for phone calls placed over the traditional public
switched telephone network (PSTN). Obviously, one key
difference between a voice call made on the PSTN and a
voice call placed over an IP network is that once the
analog voice signal is converted to a digital signal, it must
also be encapsulated in the proper IP/UDP headers so
that it is in a format that is suitable for transport over the
IP network infrastructure.
Consider this scenario: Alice wants to place a phone call

to Bob across an IP network. Alice will speak into a
telephone, and that audio needs to be properly heard by
Bob on the other side of the network. For this to be a
bidirectional conversation, the reverse also needs to be
true. Bob will also speak into the telephone in response
to Alice, and she, in turn, must be able to properly hear
Bob’s speech. In this scenario, there are two independent
media streams:
• Alice to Bob
• Bob to Alice
So how are these media streams transported over the IP

network? The answer to this question is quite complex
and has several moving parts. Alice is speaking into a
telephone, an analog device, so there needs to be an
analog-to-digital conversion, and that digital signal then
needs to be encapsulated properly so that it can be
carried and routed across the IP network. This analog-to-
digital conversion is depicted in Figure 3-1 and involves
either three or four major steps:
Figure 3-1 Analog-to-Digital Conversion
Step 1. Sampling: The continuous analog voice

signal shown in part A in Figure 3-1 is
reduced to many discrete readings by taking
frequent recordings, or samples, at regular
time intervals, as shown in part B in Figure 3-
1. The sampling rate varies depending on the
codec being used. For example, if G.711 is the
codec being used, the analog voice signal will
be sampled at 8 kHz, or 8000 times per
second. As Figure 3-2 demonstrates, the
sampling rate greatly impacts the audio
quality because it directly determines how
accurately the original analog signal is
reproduced (fidelity). Unsurprisingly,
sampling rate has a classic trade-off whereby
the higher the sampling rate, the better the
fidelity—but at the expense of increasing data
rates. According to Nyquist’s theorem, if a
signal is sampled at a rate that is twice the
highest frequency of the signal, it provides
enough samples to accurately reconstruct the
original signal. Since the majority of normal
human speech occurs at a frequency less than
4 kHz, a sampling rate of 8 kHz is commonly
used to reproduce that speech with
acceptable fidelity, in accordance with
Nyquist’s theorem.
Figure 3-2 The Effect of Doubling the Sampling Rate
Step 2. Quantization: After sampling the original

analog signal in part A of Figure 3-1, the
resultant audio samples are quantized so
their amplitudes have discrete numeric values
assigned. This means that the signal range of
human speech is divided into a certain
number of intervals, as shown in part C of
Figure 3-1. The more intervals used to
subdivide the spectrum, the more accurate
the readings can be, compared to the original
analog waveform. Increased accuracy means
the rounding errors are fewer and smaller,
which consequently means less noise is
introduced relative to the signal.
Step 3. Encoding: The different quantized values

need to be encoded with a digital
representation (that is, some number of bits).
The number of bits used for encoding
depends entirely on the quantization. For
example, in part D of Figure 3-1, there are
eight different quantization levels, and this
can be represented digitally with just 3 bits,
as shown. It stands to reason that more
intervals require more bits to encode. So,
once again, the trade-off is between
bandwidth consumption and audio quality.
Different codecs use different quantizations,
and their audio quality is directly related to
this. For example, the standard G.711 codec
uses 8 bits per sample for quantization (256
levels), whereas the higher-quality (and
higher-bandwidth) wideband G.722 codec
uses 14 bits per sample for quantization
(16,384 levels).
Step 4. Compression (optional): The encoded

audio samples can be optionally compressed
using a variety of algorithms. Different codecs
use different compression techniques to save
bandwidth. The effects these compression
techniques have on audio quality vary greatly
based on the type of audio, network
conditions, compute availability, and so on.
Figure 3-3 shows the end-to-end voice conversation

between Alice and Bob. Alice and Bob are both using
Cisco IP phones that contain built-in digital signal
processors (DSPs). A DSP is responsible for the analog-
to-digital conversion described here (that is, sampling,
quantizing, encoding, and compression). The encoded
digital audio samples need to be properly encapsulated
with IP/UDP headers so they can be properly
transported and routed across an IP network
infrastructure. The remote IP phone needs to go through
the opposite process in order for Bob to hear Alice. This
means the IP phone needs to de-encapsulate the digital
signal from the received packets. Then the DSP on the far
end IP phone performs a digital-to-analog conversion
and plays back a reconstruction of Alice’s original analog
signal out to Bob.
Figure 3-3 End-to-End Voice Call Across an IP Network
This same process of analog-to-digital conversion and

encapsulation followed by de-encapsulation and digital-
to-analog conversion happens when Bob responds to
Alice. These are two different and independent real-time
media streams. What isn’t clear yet is the details of how
the inherently real-time properties of these original voice
signals are captured and maintained across a network
that could introduce all sorts of impairments, such as
packet loss, delay, and jitter. This is where Real-Time
Transport Protocol comes in.
REAL-TIME TRANSPORT PROTOCOL

Real-Time Transport Protocol (RTP), originally
defined in RFC 1889 and superseded by RFC 3550,
provides a framework for the end-to-end transport of
voice and video. RTP typically operates over UDP/IP and
provides built-in loss detection, receiver feedback, source
identification, important event indications, and
sequencing. RTP has a peer protocol, Real-Time Control
Protocol (RTCP), that provides media reception feedback
for the related RTP stream. RTCP is discussed in further
detail in the following section.
Central to the operation of RTP is the concept of an RTP

session. An RTP session is a group of participants
interacting over RTP, such that a given participant may
be a part of several different RTP sessions at the same
time. For example, a pair of endpoints could have both
an audio RTP session and a video RTP session active
between them. An RTP session is identified by the
combination of a network address and port pair on which
traffic is sent and received. Different ports may be used
for RTP and RTCP for each session, or both protocols
may be multiplexed over a common UDP port.
An RTP session can be either unicast (one-to-one

communication between a pair of participants) or
multicast (one-to-many communication to participants).
Before exploring various other topics discussed in this
and subsequent chapters, it is important to first take a
close look at the RTP packet format.
An RTP packet consists of two parts: an RTP header and

an RTP payload (with optional padding). Figure 3-4
shows the RTP packet format.
Figure 3-4 RTP Packet Format
The RTP header includes the following fields:
• Version (V): This header field specifies the RTP

version in use. The current version at the time of
this publication is 2.
• Padding (P): This single-bit header field, when

set to 1, indicates that there are additional octets
appended to the RTP payload. These additional
octets are not part of the payload and are primarily
inserted to ensure that certain encryption
algorithms always work on fixed-size blocks of data.
• Extension (X): This single-bit field indicates the

presence of an RTP header extension. RTP header
extensions are required to carry additional media
session information that cannot be encoded within
the standard RTP headers or payload. Typical
examples of this include the RTP header extensions
for audio-level information on RTP samples, as
defined in RFC 6464. Although header extensions
are not commonly implemented, it is important for
the specification to provide accommodation for
these rare cases.
• CSRC Count (CC): This field identifies the

number of CSRC identifiers that follow the fixed
header field. CSRCs are explained further later in
this section.
• Marker Bit (M): This header field is used to

designate important events during the media
session. For example, the marker bit might
designate the start of a new DTMF event. This
usage can be observed when using named
telephony events for DTMF transmission. Yet
another usage of the M field is when the payload
format changes during a media session. For
example, a media session might negotiate G.711 as
the audio codec and begin transmission of RTP
packets back and forth. Sometime during the
course of the communication session, an
application interaction might cause the audio codec
to change to G.729 (a change that is accompanied
by a corresponding Session Description Protocol
[SDP] offer/answer exchange), and the first RTP
packet encoded with a G.729 payload has the
marker bit set. Setting of the marker bit indicates
the occurrence of a significant event (such as a
transition from G.711 to G.729) from the
perspective of the media stream.
• Payload Type (PT): This field indicates how the

RTP packet should be handled and interpreted at
the receiver. Payload Type values are correlated to
specific payload formats (for example, PCMU,
G.729, H.264) through the use of RTP profiles.
From the perspective of SIP, this correlation is
carried within the SDP body of the offer/answer
exchange. Consider Example 3-1, which
demonstrates the SDP body of a typical SIP INVITE
request.
Example 3-1 SDP Body Demonstrating the Correlation

Between the Payload Type, Payload Format, and RTP
Profile
INVITE sip:2222@192.0.2.1:5060 SIP/2.0

Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK531305
From: <sip:1111@192.0.2.2>;
To: <sip:2222@192.0.2.1>;tag=53A7B00-628
Call-ID: 5113703A-E9E911E6-815DDB64-68BBC9B8@192.0.2.
[..Omitted for brevity..]
Content-Length: 221
v=0
s=SIP Call
c=IN IP4 192.0.2.2
t=0 0
c=IN IP4 192.0.2.61
a=ptime:20
In Example 3-1, the payload type advertised is 0,

the RTP profile is RTP/AVP, and the rtpmap
attribute provides a mapping between the payload
type (0) and the payload format (G.711μ). The
RTP/AVP profile (audio/video profile), defined in
RFC 3551, is the most commonly used profile; it
defines several static assignments of payload types
to payload formats. Table 3-2 lists some of these
well-known static assignments.
Table 3-2 Payload Type-to-Format Mapping for

RTP/AVP
The RTP profile is also useful in providing the clock

rate for predefined static assignments. The payload
formats are responsible for determining how
information is encapsulated in the RTP packet,
such as specifying what is present in the RTP
header and the RTP payload.
• Sequence Number: This 16-bit field increases

sequentially for each RTP packet sent from the
sender to the receiver. It is through this 16-bit field
that RTP provides its built-in loss-detection
mechanism. Packets are assumed to have been
dropped during transit if the receiver notices a
break in the RTP sequence numbers of received
packets. Figure 3-5 depicts a scenario in which the
receiver experiences packet loss in a real-time
communication session.
Figure 3-5 RTP Packet Loss During a Real-Time

Communication Session
The RTP sequence number is always chosen

randomly and does not start from zero. From the
randomly chosen offset of the first RTP packet,
successive RTP packets have incrementally
increasing sequence numbers. A random sequence
number value is usually chosen for the initial RTP
packet to protect against known plaintext security
attacks.
Note
A common misconception about the Sequence Number field is that it assists
the receiver in determining the order in which the packets are played out, but
this is an incorrect assumption. The order in which packets are played out at
the receiver is dependent on the RTP Timestamp header field, described next.
The Sequence Number field simply assists the receiver with loss detection.
• Timestamp: The Timestamp header field is a 32-

bit value that designates the sampling instant of the
first octet of the media payload in the RTP packet.
The sampling instant is derived from a media clock
that increases linearly and monotonically in time.
The rate at which this clock advances is dependent
on the payload format and can sometimes
drastically vary based on the media format. The
timestamp field is used at the receiver to decide the
order in which packets are played out. The
timestamp header field value in the first packet is
randomly chosen and advances at a rate specified
by the payload format (refer to Table 3-2).
• Synchronization Source (SSRC) Identifier:

This 32-bit field serves as an identifier of a
participant in an RTP session. The SSRC values
must always be chosen randomly by participants in
an RTP session because each RTP session has its
own unique SSRC space. If one or more
participants in an RTP session have the same SSRC
value (which is possible because these values are
chosen randomly), a collision occurs. Collisions are
resolved by having the endpoints send an RTCP
BYE packet, followed by choosing a new random
SSRC value. For participants that are part of
multiple RTP sessions at the same time (for
example, both an audio session and a video
session), the SSRC values have to be unique across
those multiple sessions. Some of the scenarios that
might cause the SSRC to change during the course
of a communication session include the following:
• Application restarts
• SSRC collisions
• Changes in the RTP transport address (network

address and port pair)
• Contributing Source (CSRC) Identifier:
There are often scenarios in real-time
communication sessions in which participants
stream media directly to an intermediary device
such as a mixer. The mixer is responsible for
combining streams from various participants and
sending over the resultant media stream to one or
more receivers. Because the mixer is part of the
RTP session, it has its own SSRC value that is used
when it transmits RTP packets. The number of
sources that contribute to the resultant output of
the mixer is captured in the CC field of the RTP
packet. The individual SSRCs of the contributing
sources are captured in the CSRC blocks. Note that
not all RTP packets contain this header field, as it is
only used when combining streams from various
sources. This forms a part of the optional RTP
header.
• Payload Header: The presence of this optional

header is based on the requirements of the payload
format that is negotiated.
• Media Payload: This forms the actual media data

that is framed by the RTP packet. Its contents are
governed by the payload format that is used.
When an application builds an RTP packet and places it

on the wire for transport, it utilizes UDP as the transport
layer protocol. The “fire and forget” nature of UDP is
perfect for multimedia application data such as RTP
because of the reduced overhead afforded by removing
packet acknowledgements. As mentioned earlier, a real-
time application uses the RTP sequence number to
determine whether packet loss has occurred, but the
reality is that it does not request that a missing packet be
re-sent. The real-time nature of the RTP media stream
implies that it is of no use to the applications and users
to receive out of order audio samples that were
previously missed. To further illustrate the point,
imagine a scenario in which you are listening to an RTP
stream and the phrase “Hello, how are you today?” is
mentioned and encoded in RTP packets and sent across
the network. In this theoretical example, the RTP stream
containing the word (or part of the word) “how” is
dropped along the transit path. Would the receiver of
this audio stream ever want to hear this missed audio
sample later, via retransmission of the packet from the
sender to the receiver? The answer is clearly no. In fact,
the conversation likely continued on without the need for
retransmission and often, due to a variety of audio
quality mitigation techniques, without a perceptible
impact to the conversation.
As per RFC 3550, RTP applications should use an even

UDP port number for RTP. It should also be noted that
RFC 3550 does not define any default range of UDP
ports that can be used by RTP. A common misconception
is that RTP can only use the even UDP ports ranging
from 16384 through 32767. While this is considered the
“unspoken” standard UDP port range for RTP, in the real
world, many service provider devices, third-party
devices, and even Cisco products utilize nonstandard or
extended UDP port ranges for RTP. For example, Cisco
Unified Border Element (CUBE) on IOS XE uses RTP
ports 8000 through 48198, and Cisco Expressway uses
ports 36000 through 59998. Administrators should
review applicable documents on RTP port ranges when
configuring access control lists (ACLs) and firewall rules.
Furthermore, many devices offer configurable RTP port
ranges, including Unified CM and CUBE. Thus, in the
event of preexisting implementations, you should check
active configurations to verify the RTP port range in use.
Note
Contrary to popular belief, RTP can be sent over TCP. RFC 4571 serves as the
basis for using RTP and RTCP over connection-oriented transports such as
TCP. Although it is unlikely that you will find it in most deployments, Cisco
Webex may attempt to utilize TCP as a backup transport protocol in the event
that UDP is blocked on the enterprise. The use of TCP as the transport for RTP
is signaled through the SDP with the m= line containing TCP/RTP/AVP rather
than the standard RTP/AVP used with UDP RTP.
Real-time networks transmit voice and video data over
RTP such that each individual RTP packet contains a
fixed-size payload that serves as an information unit.
Within the RTP payload are the voice and video samples
that are encoded and decoded at the sender and receiver
applications, respectively. The time duration of media
that is encoded within these payloads, known as the
packetization period, can vary on a per-codec basis. For
example, G.711-encoded streams can have packetization
periods that vary from 5 milliseconds to 40 milliseconds.
Table 1 in RFC 3551 highlights the default packetization

periods to be used by RTP-based applications for a
myriad of codecs. Table 3-3 provides a few selected
examples.
Table 3-3 Default Packetization Periods of Common

Audio Codecs
Consider that every RTP packet sent requires a

predefined amount of (IP/UDP/RTP) header data. As a
result, more packets sent per second results in more
header data being sent, amounting to higher
consumption of bandwidth. As a result, increasing the
packetization period may be desirable to reduce the
amount of bandwidth from the resulting IP/UDP/RTP
header, thus increasing the overall real-time voice or
video data throughput. This could be very useful over
bandwidth-limited or expensive WAN links. For
example, a 20 ms packetization period for G.711ulaw
means that there are 160 bytes of audio payload data
carried within the RTP packet. On the other hand, a 30
ms packetization period for the same audio codec would
contain 240 bytes of payload data. Recall from the
previous section that audio is sampled when it is
digitized. This means that the packetization period
values directly influence how many packets per second
(pps) are sent on the network. For G.711ulaw with a 20
ms packetization period, there will be 50 pps (8000 /
160). These types of calculations are useful when
performing bandwidth checks and configuring quality of
service on a network.
RTP sessions are subject to fixed and variable delays in

packet transmission. The default packetization periods
for different codecs merely serve as recommendations
and can be overridden when needed. The process of
changing the effective bit rate by manipulating the
packetization periods, known as transrating, can
increase or decrease the packetization delay, depending
on the amount of voice and video data encoded in RTP
packet payloads. With transrating, the only factor
directly influenced is the packetization delay, which is
the amount of time taken to encode the payload of the
RTP packet. Transrating introduces some trade-offs,
with advantages and disadvantages that need to be
considered on a case-by-case basis:
• Increasing the packetization period (and hence the

packetization delay) results in packets with large
media payloads but decreases the overall number of
packets that traverse the network. A risk of
increased packetization times is the increased
latency required for the sampling of audio and an
increased loss of audio content during packet loss,
which results in a decrease in the ability to conceal
the packet loss effect to the listener.
• Decreasing the packetization period means the

media payloads are smaller, resulting in the packets
being placed on the network much sooner and
decreasing the likelihood of voice quality issues.
The downside to this is the unnecessary and costly
increase in overall bandwidth utilization. A
decrease in the packetization period has no effect
on the size of the RTP/UDP/IP headers, as
packetization operations are specific to RTP
payloads.
In RTP sessions that are set up using SIP and SDP, the
packetization period is advertised using the ptime and
maxptime attributes. The ptime attribute specifies the
length of media within a packet, expressed in
milliseconds, whereas the maxptime attribute specifies
the maximum amount of media that can be encapsulated
in a packet, also expressed in milliseconds. While setting
up a communication session between RTP peers, in the
ensuing offer/answer exchange, if the ptime attribute is
included in the SDP body by the offeror or answerer, it
indicates the desired packetization interval that the
offeror or answerer would expect to receive. Example 3-2
highlights the use of the ptime attribute in SDP.
Example 3-2 Using the SDP ptime Attribute to Indicate

the Desired Packetization Interval
INVITE sip:2222@192.0.2.1:5060 SIP/2.0

Remote-Party-ID: <sip:1111@192.0.2.2>;party=calling;s
From: <sip:1111@192.0.2.2>;
To: <sip:2222@192.0.2.1>;tag=53A7B00-628
Date: Sat, 04 Feb 2017 07:11:33 GMT
Call-ID: 5113703A-E9E911E6-815DDB64-68BBC9B8@192.0.2.
[..Omitted for brevity..]
Content-Length: 221
v=0
s=SIP Call
c=IN IP4 192.0.2.2
t=0 0
c=IN IP4 192.0.2.61
a=ptime:20
The ptime (or maxptime) attribute is encoded in SDP

using the following format:
a=ptime:<packet time>
a=maxptime:<maximum packet time>
The numeric value specified in the attribute denotes the

value, in milliseconds, of the desired packetization time
or maximum possible packetization time, depending on
whether the ptime or maxptime attribute is used. If the
ptime attribute is not specified in the SDP, the default
packetization period for the codec applies. (Refer to
Table 3-3 for a selected representation and Table 1 in
RFC 3551 for further details.)
The use of these two SDP attributes is entirely optional,

and not all media codecs make use of them. If you have a
packet capture containing RTP packet, you can surmise
the ptime value for a given stream by performing the
following steps with Wireshark:
Step 1. Ensure that RTP packets are decoded by

default by navigating to Analyze > Enable
Protocols > RTP and then enabling the
rtp_udp checkbox and clicking OK. The
Wireshark dissector then decodes the packets
even when there is no accompanying call
signaling.
Step 2. Filter the packet capture down to a single
RTP stream. This can be done with a few
Wireshark filters by either determining the
UDP source or destination port or the SSRC
of the RTP stream of interest. Using Figure 3-
6 as an example, you could create three
different Wireshark filters to filter the packet
capture to a single stream. These example
filters are as follows, with the rtp.ssrc filter
being applied in Figure 3-6:
udp.srcport == 8452
udp.dstport == 24812
rtp.ssrc == 0x00007a4a
Figure 3-6 Wireshark ptime Example
Step 3. When a single RTP stream has been filtered,

navigate to View > Time Display Format
and select Seconds Since Previous
Displayed Packet. Wireshark now takes
into account displayed packets using the filter
of choice from step 2. You can now observe
the calculated time between packets. With
audio codecs that utilize linear packetization,
such as those observed in Figure 3-6, you
should see a ptime that matches the payload
size of the packet. This type of filter and
display format can also be useful for
determining areas of large delay and jitter
within a given RTP stream.
REAL-TIME TRANSPORT CONTROL

PROTOCOL
As discussed in the previous section, RTP defines a
framework for real-time transfer of audio and video
media between senders and receivers in an RTP session.
The RTP framework also defines a peer protocol called
Real-Time Transport Control Protocol (RTCP)
that includes the following functions:
• It allows receivers to provide periodic reception

quality feedback to senders by using receiver
reports. These reports enable senders to take stock
of network characteristics and possibly alter their
transmission patterns, as required.
• RTCP defines a transport-level identifier called the

canonical name (CNAME) that serves as the
common identifier for all media streams
transmitted by a source. This is especially useful in
cases in which a source changes its SSRC during a
communication session or when a source transmits
multiple streams simultaneously. It also assists the
receiver in correlating multiple streams to a given
participant and in achieving media synchronization
across the multiple streams transmitted by the
participant.
• RTCP requires all participants to exchange reports,

regardless of whether they are active senders. This
ensures that there is a global view of the RTP
session. RTCP provides useful diagnostics and gives
each participant an estimate of the number of
members in the RTP session.
• RTCP can optionally be used to transmit additional

information in terms of participant identity, email,
and location information.
Given that all participants must stream RTCP traffic,

transmission must be periodic and designed in such a
way that it does not overrun session bandwidth. This is
especially true for RTP sessions that have a large number
of participants; if RTCP traffic were to be exchanged at
the same rate as RTP, there would be bandwidth
contention and a potential for lost data. As a result,
RTCP traffic must always be allocated a fraction or
percentage of total session bandwidth. The
recommended percentage of bandwidth allocation for
RTCP is 5%, with active senders allocated one-quarter of
the total RTCP bandwidth. This ensures that required
reports, such as those for media synchronization, are
successfully delivered in a timely manner, without
competing against RTP for bandwidth.
RTCP defines many different packet types that are used

for different scenarios. This chapter covers five of the
most common RTCP types observed in Cisco Unified
Communication environments. All the RTCP packet
types use the common format shown in Figure 3-7.
Figure 3-7 Common RTCP Packet Format

The following fields are included in the common RTCP
packet format:
• Version (V): Specifies the version number, which

correlates to the version of RTP, currently 2.
• Padding (P): When set, this bit indicates that the

packet contains additional data octets toward the
end of the packet. This is primarily required when
encryption ciphers require fixed-size blocks of data.
• Receiver Count/Source Count (RC/SC): This

header field is used to provide the count of receiver
reports or source description (SDES) items
included in the RTCP packet.
• Packet Type (PT): The encoding in this header

field defines the RTCP type. Different RTCP packet
types are described in the next section.
• Length: This header field denotes the length of the

packet following the common header. This field is
expressed in 32-bit words and can have a value of
0. A value of 0 indicates an empty packet that just
contains the 4-byte common header.
All RTCP packets must be sent as compound RTCP

packets, which include a combination of different RTCP
packet types that follow a very strict ordering scheme.
The next few sections describe five different RTCP packet
types, which serve different purposes in a
communication session:
• RTCP sender report (SR)
• RTCP receiver report (RR)
• RTCP source description (SDES)
• RTCP goodbye (BYE)
• RTCP application-defined packet (APP)
RTCP Sender Report (SR)

Figure 3-8 shows an RTCP SR, which primarily assists in
media stream synchronization, and, when used in
combination with the SDES packet type, also assists
receivers in correlating media streams to a particular
source.
Figure 3-8 RTCP Sender Report Format
RTCP sender reports are sent by sources that have

recently transmitted media and are identified by a packet
type value of 200. An active sender also includes
reception statistics for all the other sources from which it
has received media packets. The reception statistics are
encoded as RTCP receiver report (RR) blocks, such that
each block corresponds to a source from which media
was received.
The Receiver Count (RC) header field in the RTCP

sender report packet captures the number of receiver
report blocks included. If media hasn’t been received
from any source, there are no receiver report blocks
included in the compound RTCP packet, and the RC
header field is set to 0.
The Reporter SSRC field of the packet sender encodes

the SSRC of the source that transmits the RTCP SR
packet, and it is a 32-bit field. Following this is a 64-bit
Network Time Protocol (NTP) Timestamp field. The time
in this field is expressed in NTP format, which is the
number of seconds that have elapsed since January 1,
1900. This field indicates the time when the RTCP SR
packet was sent.
The 32-bit RTP Timestamp header field encodes the
same time as the NTP Timestamp header field but is
expressed in RTP timestamp format. The receiver uses
the NTP Timestamp and RTP Timestamp header fields to
synchronize the media clocks of the different streams
from a sender, allowing for synchronization of offset
audio and video media streams (lip sync).
Following the RTP Timestamp field are the Sender’s

Packet Count and the Sender’s Octet Count fields. The
Sender’s Packet Count field captures the total number of
RTP data packets transmitted by the sender from the
start of the session up through transmission of the RTCP
SR packet. The Sender’s Octet Count field captures the
total number of data octets sent since the start of the
RTP session, up through transmission of the RTCP SR
packet. The octet count does not take into account the
RTP headers and padding and is only concerned with the
number of octets that are sent using the RTP packet
payload.
Note
The Sender’s Packet Count and the Sender’s Octet Count field values are
reset if the SSRC changes for a sender during the RTP session. SSRC values
can change if there is an SSRC collision detected or if the sender changes its
media type during an RTP session.
Sender reports can also be used to get an estimate of the

average payload size of RTP data packets transmitted by
a sender and the network throughput available.
RTCP Receiver Report (RR)

RTCP receiver reports are used to report transmission
statistics to the senders from which RTP media packets
are received. The format of an RTCP receiver report is
illustrated in Figure 3-9. The Packet Type header field in
an RTCP RR packet is set to 201, and the number of
reports blocks present in a particular RTCP RR is
captured in the RC header field.
Figure 3-9 RTCP Receiver Report Format
The identity of the sender of an RTCP RR packet is

captured by using the SSRC of Sender header field. The
RTP sender for which statistics are being reported is
indicated by the SSRC of Source_N header field. It is
possible for a single participant in an RTP session to
receive RTP packets from multiple sources, in which case
reception statistics have to be reported for each source. A
total of 31 reception reports are possible per RTCP RR
packet. If there are more than 31 sources to report on,
multiple RTCP RR compound packets must be leveraged.
The Loss Fraction header field captures the fraction of

RTP media packets lost from a particular source since
the transmission of the previous SR or RR packet. This
value is expressed as a fixed-point number, with the
binary point at the left edge of the field. The fraction is
calculated by dividing the number of packets lost by the
number of packets expected. During an RTP session, it is
not uncommon to come across packet duplicates, in
which case the number of packets received would be
more than the number of packets actually expected. This
results in the number of packets lost (described next)
being represented as a negative value. In such scenarios,
the Loss Fraction header field is set to 0.
The Cumulative Number of Packets Lost header field is a

24-bit signed integer that denotes the number of packets
received subtracted from the number of packets
expected. The number of packets expected is defined as
the extended last sequence number received subtracted
from the initial sequence number received. In the case of
packet duplicates, the Cumulative Number of Packets
Lost header field carries a negative value.
Extended Highest Sequence Number Received is a 32-bit

header field value, where the lower 16 bits indicate the
highest sequence number received in an RTP media
packet from a given source. The higher 16 bits indicate
the number of times the sequence numbering in RTP
media has wrapped around from 65535 (maximum
value) to 0 (minimum value).
Note
The sequence number in RTP packets is a 16-bit field, which means RTP
packets from a source can carry distinct sequence numbers for a maximum of
65,535 packets (216 packets). After crossing this maximum value, the
sequence number has to wrap around to 0. Wrapping of RTP sequence
numbers is fairly common and occurs for conversations that extend a duration
beyond 21 minutes 50 seconds (assuming a codec packetization rate of 50
packets per second). It is for this reason that sequence numbers cannot be
used to uniquely identify packets within an RTP session. To account for this, a
32-bit sequence number is commonly used, where the lower 16 bits encode
the RTP sequence number of a packet, and the upper 16 bits encode the
number of times the sequence number space has wrapped around to 0.
The Interarrival Jitter field provides an estimate of the

statistical variance of the RTP media packet interarrival
time. This header field is measured in timestamp units
and expressed as a signed integer.
The Last SR (LSR) header field captures the middle 32 of

the 64 bits received in the NTP Timestamp header field
of the previous SR packet to which this RR block
corresponds. If there haven’t been any RTCP SR packets
received from the source, this field is set to 0.
The Delay Since Last SR (DSLR) header field is a 32-bit

field expressed in units of 1/65536 seconds that
calculates the delay between receiving the last SR packet
from a source (to which this RR block corresponds) and
sending this RR block. If no SR packet has been received
yet from the corresponding source, this header field is set
to 0.
RTCP receiver reports are commonly used to provide

reception quality feedback to senders in real time.
Senders can use these reports to alter their transmission
patterns. In addition, third-party monitoring
applications use RTCP reports to gauge the overall media
quality of sessions from local, regional, or global
perspectives.
RTCP Source Description (SDES) Packet

The RTCP SDES packet is primarily used to provide a
persistent participant identifier that spans SSRC changes
and system restarts. In addition to providing a persistent
identifier, it also provides information such as the
participant name, email address, location, and telephone
number. The common SDES packet format, illustrated in
Figure 3-10, carries the packet type 202. SDES packets
contain zero or more chunks, and the exact count of
chunks is captured in the SC header field value.
Figure 3-10 SDES Common Packet Format
Each item chunk begins with the SSRC of the sender,

followed by a string of entries in the format shown in
Figure 3-11. The Type header field conveys the type of the
SDES RTCP packet, and the Length header field encodes
(as UTF-8) the number of octets of text present.
Figure 3-11 SDES Item Format
The SDES packet format contains the following items:
• The CNAME SDES item carries a Type value of 1

and is the only mandatory SDES packet that must
be sent by all implementations. This packet
provides a persistent transport-level identifier for
the participant, known as the CNAME. The CNAME
of a participant is expected to stay the same across
SSRC changes and system restarts, and it is
expected to be unique in an RTP session or a group
of related RTP sessions. The CNAME header field
value is derived algorithmically using the format
user@host or just host when the username is
unavailable. The CNAME is essential for a receiver
to identify and synchronize media streams that
originate from a given source.
• The NAME SDES item carries a Type value of 2 and

is required to provide the name of a participant.
This is usually populated by a user and can be in a
format chosen by the user (for example, John Doe).
Applications can use the NAME SDES item to
populate conference rosters as participants join.
This SDES item should not be considered unique
among all participants in a communication session.
• The EMAIL SDES item carries a Type value of 3

and is used to convey the email of the participant in
RFC 2822 format (for example,
John.Doe@example.com). The email of the
participant is expected to remain persistent during
the course of an RTP session.
• The PHONE SDES item carries a Type value of 4

and reflects the phone number of the participant in
international format.
• The LOC SDES item carries a Type value of 5 and

encodes the location of the participants with
varying degrees of detail. For example, Building 14,
HQ Campus is a valid encoding.
• The TOOL item carries a Type value of 6 and is

used to advertise the name of the product or
application generating the stream. This is used
primarily for marketing purposes and does not
have any bearing on the RTP session.
• The NOTE SDES item carries a Type value of 7 and

is used to provide a general indication such as a
status (for example, on the phone). While this is
good for occasional usage, it must not be used for
delivery of messages in a communication session,
as RTCP is exchanged too infrequently between
participants.
• The PRIV SDES item carries a Type value of 8 and

is used for experimental purposes.
RTCP Goodbye (BYE) Packet

The RTCP BYE packet is transmitted whenever a
participant leaves an RTP session or whenever an SSRC
collision is detected. There are certain timing
considerations that participants need to take into
account while transmitting RTCP BYE messages to
prevent congestion. Consider a scenario in which several
participants leave an RTP session at around the same
time; this could result in a flood of RTCP BYE packets
and some RTCP BYE message loss. To prevent this
scenario, a back-off algorithm is provided with RTCP
BYE transmission.
The format of the RTCP BYE packet is depicted in Figure

3-12; it has the packet type value 203. The SC header
field captures the number of SSRC/CSRC identifiers
present in this RTCP BYE packet. There is an optional 8-
bit field that captures the number of octets present in the
following header field, reserved for the purpose of
specifying a reason for leaving. The reason for leaving
header field provides a textual description of why the
source decided to leave the RTP session. An example
encoding of this header field could be camera not
operational.
Figure 3-12 RTCP Goodbye Packet Format
RTCP Application-Defined Packet (APP)

The RTCP APP packet allows for application-specific
extensions. This packet type is primarily used to
exchange proprietary information. As newer application-
specific extensions are developed and tested sufficiently,
they may evolve to become valid RTCP packet types.
Other RTCP Packet Types

As indicated at the start of this section, there are more
RTCP packet formats beyond those defined in RFC 3550,
but you might not run into them on many networks. For
example, the RTCP Payload Specific Feedback (PSFB)
packet type (206) from RFC 4585 may be seen with video
endpoints and is signaled in SDP through the SDP
attribute a=rtcp-fb. For a complete list of RTCP payload
types and references to the specifications where they are
defined, visit the following IANA page, which officially
registers all the RTCP control packet types:
https://www.iana.org/assignments/rtp-parameters/rtp-
parameters.xhtml#rtp-parameters-4.
RTCP Transport
As highlighted earlier, for UDP and similar transport
layer protocols, applications must use an even port
number for RTP and the next higher (odd) port number
for RTCP. As detailed in Chapter 2, “VoIP Protocols: SIP
and H.323,” applications can utilize the SDP attribute
a=rtcp:<udp-port> to define another RTP port rather
than the default next highest UDP port number.
Furthermore, RFC 5761 introduced the concept of
RTP/RTCP multiplexing over a single UDP port. This is
conveyed using the SDP attribute a=rtcp-mux.
DTMF RELAY
At some point, you have heard a prerecorded prompt
requesting some information, perhaps a credit card
number, an employee number, or a simple PIN entry.
After a couple of presses on the keypad, you magically
got the information you were looking for or were
connected to a human agent. The underlying framework
that enables this seamless transfer of information is
known as dual-tone multifrequency (DTMF).
With the advent of voice over IP (VoIP), reliable

transmission of keypad button presses end-to-end
became somewhat of a problem, as audio codecs were
not optimized for carrying DTMF tones without bringing
in a degree of distortion. There was a need to engineer a
new way of reliably transmitting DTMF, and this solution
needed to factor in all the complexities of modern real-
time networks. Fortunately, the industry (led by the
IETF and ITU-T) came up with several methods of
DTMF relay that have worked demonstrably well in real-
time networks.
Introduction to DTMF Relay

In the 1960s, Bell Labs introduced DTMF to the public
under the trademarked name Touch Tone. It was a
means for consumers to utilize tones to convey numeric
signaling information. It proved to be a viable alternative
to the rotary dial phones that were in use at the time.
DTMF uses a combination of two tones: a high-frequency
tone and low-frequency tone interleaved to represent a
digit on the keypad (0–9, *, #) or a letter (A–D). A device
that supports DTMF has a keypad layout in the form of a
4×4 matrix, such that each row represents the low-
frequency tone component and each column represents
the high-frequency tone component of the signal. Figure
3-13 illustrates the 4×4 grid used in DTMF signal
transmission.
Figure 3-13 4×4 DTMF Grid
In the illustration in Figure 3-14, a caller at an IP phone

dials in to an enterprise network, where the call is routed
to an on-premises IVR system. When the call is
connected, the IVR system might play a prompt soliciting
the caller to enter a digit for the sales department,
another digit for the service department, and so on. The
caller then enters the desired value through a series of
keypad digit presses. Each digit press is a DTMF tone
that is conveyed end to end from the caller to the IVR
system. Over standard PSTN networks, DTMF
information is transmitted as standard signals; over IP
networks, DTMF is either transmitted along the
signaling (as application protocol messages) or the media
stream (within media or RTP packets). The process of
transmitting digit information over IP networks—either
in-band (within the media), out-of-band (signaling), or a
combination of both over different call segments and
usually in a mutually exclusive capacity—is called DTMF
relay.
Figure 3-14 Sample Ladder Diagram for DTMF
The transmission of signals using DTMF over TDM and

analog networks is extremely reliable; however,
transmission of DTMF over VoIP networks isn’t so
straightforward. Consider the network topology
illustrated in Figure 3-15. In this scenario, a remote
device is calling in to the enterprise by way of the
Internet telephony service provider (ITSP). This call
routes through CUBE and Unified CM and ultimately
ends up at Cisco Unified Contact Center Express
(UCCX). UCCX may play a custom script to the caller, as
observed in Figure 3-14, and the user presses 1 on the
keypad. The DTMF then needs to be relayed across the
different call segments. The process works as follows:
Step 1. The ITSP and CUBE negotiate the in-band

RTP-NTE DTMF method, and the DTMF
digit is relayed to CUBE from the ITSP.
Figure 3-15 DTMF Relay Along Multiple Call Legs
Step 2. CUBE and Unified CM negotiate the out-of-

band (OOB) SIP KPML DTMF method, and
the DTMF digit is relayed to Unified CM.
Step 3. Unified CM and UCCX negotiate the default

DTMF method of relaying DTMF as JTAPI
events, and the DTMF method is relayed to
the IVR application to analyze and take
action.
This is just a basic example showing how applications

can transmit digits over the IP segment(s) of a call. To
ensure reliability of DTMF transmission over IP
networks, standards bodies such as the IETF and ITU-T
have designed several different methods of DTMF relay.
These different methods are covered in detail in
subsequent sections of this chapter.
Variants of DTMF Relay

Regardless of the scale and complexity of real-time
networks, there are only two ways in which DTMF can be
relayed over a given call leg:
• In-band: In-band DTMF relay refers to the

transmission of tones within the RTP (media)
stream.
• Out-of-band: Out-of-band transmission relies on

the signaling channel to transmit DTMF
information.
Both methods have merits and issues, and as with many

other things in VoIP, the best choice of DTMF relay is
implementation dependent and has a scope that spans
the entire network end to end, as opposed to being
restricted to a few devices or network segments.
In-Band DTMF Relay

Transmission of DTMF tones within the media stream is
referred to as in-band DTMF relay. Most of the
codecs used in VoIP networks were designed and
optimized for human speech, and their encoding and
decoding algorithms don’t work well with raw dual-
frequency tones. This is especially true with high-
compression codecs such as G.729 that sufficiently
distort tones so that they cannot be accurately
reproduced at the receiving application.
It is precisely for this reason that the IETF took up the

task of devising a way to reliably transmit tones within
the media stream, which subsequently led to the
standardization of named telephony events in RFC 2833
(which has since been superseded by RFC 4733). There
are two ways DTMF tones can be transmitted within the
media stream:
• Named telephony events (NTEs)
• Raw in-band tones
Named Telephony Events

RFC 2833 defines a specialized payload format and
specification for the transmission of DTMF tones within
the media stream using named telephony events
(NTEs). This specification convincingly overcomes some
of the known limitations of transmitting DTMF tones
using a standard audio codec. The improvements
provided by named telephony events over standard audio
codecs for the transmission of DTMF include the
following:
• Decoupling of DTMF tones with the audio codec

ensures transmission success even when using
high-compression codecs such as G.729.
• Defining a separate RTP payload format permits

redundancy in DTMF digit transmission while
maintaining a low transmission bit rate.
• Certain tones (such as the ANSAM tone for modem

calls) have phase reversals. These phase reversals
cannot be accurately transported as audio packets
over an IP network. Using named telephony events
to represent such tones greatly simplifies the
process.
• Newer devices can relay DTMF information as

named telephony events as opposed to actually
generating tone pairs for digits.
The NTE payload is carried in standard RTP packets

such that the same sequence number and timestamp
space are used for both audio-coded packets and NTE
packets.
Note
Further discussion in this chapter uses the term NTE packet to designate an
RTP packet that carries an NTE payload.
Three different types of packets are sent per event in the
NTE scheme:
• A packet to designate the start of the DTMF event.

The start packet always has the RTP marker (M) bit
set to 1. For RFC 2833, there may be three packets
with marker bit set to true, and with RFC 4733,
only the first packet in the DTMF event needs the
marker bit set to true.
• Refresh or update packets that are sent every 50

milliseconds until the end of the event.
• Three redundant packets that designate the end of

the event. End packets always have the end (E) bit
in the NTE payload set to 1.
The three different types of packets described are for a

single event or DTMF digit, and they all have the same
RTP timestamp. The sequence number in each
successive NTE packet increases by one. Figure 3-16
illustrates the RTP packet format with an NTE payload.
Figure 3-16 RTP Packet Format with an NTE Payload
The payload format for named telephony events is

illustrated in Figure 3-17.
Figure 3-17 Payload Format for Named Telephony
Events
The following fields appear within the payload:
• Event: This is a number between 0 and 255

(inclusive), where each number designates a
specific event, as outlined in RFC 2833 and RFC
4733. However, for DTMF, the event IDs can take a
number between 0 and 15. Table 3-4 lists the digit
and alphabetic assignments corresponding to
numeric values between 0 and 15.
Table 3-4 DTMF Named Events
Letters A through D are for military application and

are not typically used in commercial applications.
• End (E) bit: When this bit value is set to 1, it

designates the end of the DTMF event; it is
imperative that this bit not be set to 1 for packets
that either designate the start of the event or
refresh packets that are sent every 50 milliseconds.
• Volume: For DTMF digits and other events that

can be represented as tones, this field describes the
power level of the tone, expressed in dBm0 after
dropping the sign. Power levels range from 0 to
−63 dBm0. The range of valid DTMF is from 0 to
−36 dBm0.
• Duration: This field designates, in timestamp

units, the duration of the DTMF event. The
timestamp field in any RTP packet for a given event
indicates the instant when the event started, while
the Duration field in any NTE packet for a given
event indicates how long the event has lasted.
• R bit: This a reserve bit and currently does not

have any defined function.
Note
There are scenarios in which the timestamp can change within the span of a
single event; this occurs when the event lasts longer than 8 seconds.
Given that named telephony events are carried within

the media stream along with audio-encoded packets, the
receiving application distinguishes these packets from
standard audio packets by using the payload type and
payload format. For NTE packets, the payload types
chosen are dynamic and can vary between 96 and 127.
For communication sessions set up using SIP in concert
with SDP, the payload type for named telephony events
is advertised by each user agent within the
corresponding SDP body. Example 3-3 provides an SDP
snippet that advertises a dynamic payload of 101 for NTE
DTMF.
Example 3-3 SDP Advertisement of Named Telephony
Events
// SIP message omitted for brevity//

v=0
s=SIP Call
c=IN IP4 10.1.1.1
t=0 0
a=recvonly
a=fmtp:101 0-15
a=ptime:20
Although the payload type 101 is most commonly used

for NTE, it is perfectly valid to make use of any payload
type between 96 and 127. It is worth noting that dynamic
payload types can be negotiated asymmetrically. This
simply means that when negotiating NTE on a call leg,
the two user agents may advertise different payload types
for NTE. Consider the scenario in Figure 3-18, where
User Agent A advertises payload type 96 for NTE, and
User Agent B advertises payload type 101. Recall from
Chapter 2 that SDP describes what a user agent is
prepared to receive. Therefore, when User Agent A offers
payload type 96 for DTMF, User Agent B must send
DTMF using payload type 96. Likewise, when User Agent
B answers with payload type 101 for DTMF, User Agent A
must send DTMF using payload type 101. While rare, this
scenario is certainly permitted by SDP, so the user agents
need to be configured properly to allow for such
asymmetric negotiation.
Figure 3-18 Asymmetric Payload Type Negotiation for
NTE
Raw In-Band Tones

Raw in-band DTMF refers to the transmission of raw
tones within the media stream. Unlike named telephony
events, for which there is a specialized RTP payload
format for DTMF, raw in-band DTMF encodes tone
frequencies within the standard RTP payload. As
mentioned earlier, audio codecs have their algorithms
optimized for speech and don’t work optimally to
transmit DTMF tones. Using high-compression codecs
for transmission of DTMF, tones are almost certain to
impede DTMF transmission due to significant tone
distortion.
Some of the inherent disadvantages of using raw in-band

DTMF are as follows:
• Lack of codec optimization for transmission of

DTMF.
• No native support for redundancy while

transmitting DTMF tones (unlike NTE, which has
built-in redundancy). If redundancy has to be
achieved, it occurs through a redundant RTP
stream using the constructs of RFC 2198. This leads
to increased complexity and bandwidth utilization.
• Lack of diagnostics for troubleshooting. Because
these tones are carried as raw tones within the
audio codec, the only way to troubleshoot DTMF
transmission is by decoding the audio stream using
specialized software.
• Non-ubiquitous adoption across devices and

vendors.
There are still some service providers that use this

method of DTMF transmission, despite the obvious
perils and limitations. Figure 3-19 diagrammatically
depicts a sample transmission of RTP-NTE and raw in-
band DTMF. The top half of the diagram shows a call
that is connected to an on-premises enterprise IVR. The
PSTN phone presses 4 and ultimately sends an RTP-NTE
packet with event ID 4 conveying the digit press to the
local enterprise SBC. The local SBC then sends the RTP-
NTE packet with the event ID to the remote IVR, which
processes the digit press and takes action.
Figure 3-19 End-to-End Transmission of NTE and Raw

In-Band DTMF
The bottom half of Figure 3-19 shows the same sample

call, which is connected to an enterprise IVR by a remote
PSTN participant through an on-premises SBC, such as
CUBE. However, when the PSTN phone presses the digit
4, a raw in-band RTP packet is sent. The payload of the
RTP packet contains the encoded audio, which comprises
the two frequencies interleaved to produce the tone for
the DTMF digit 4. The SBC passes the RTP packet to the
on-premises IVR, which needs to be equipped with a
mechanism for detecting these in-band dual tones. If this
IVR is capable of detecting the 770 Hz × 1209 Hz tones
within the audio stream, it may take action based on the
reception of digit 4. If the remote IVR is not equipped
with a mechanism to detect raw in-band DTMF, the IVR
may wait for user input or repeat the same prompts
continuously until the call disconnects.
Out-of-Band DTMF Relay

Out-of-band DTMF relay relies on the signaling
channel to communicate digit presses. Call control
protocols such as SIP and H.323 have specialized
mechanisms and extensions for communicating DTMF
information. These mechanisms and extensions are
discussed in detail in the sections that follow. With this
method of DTMF relay, notifications for digit presses
traverse the signaling path, which could include call
agents and stateful proxies, among other devices. On the
other hand, in-band DTMF relay uses the media path
and is relayed directly between the participants of an
RTP session. Figure 3-20 depicts the difference in path
characteristics of in-band and out-of-band DTMF.
Figure 3-20 Difference in Path Traversed by In-Band
and Out-of-Band DTMF
The following subsections discuss different methods of

out-of-band DTMF relay in SIP and H.323 networks.
SIP INFO
The procedures laid out in RFC 3261 and several
accompanying RFCs define the operating principles,
methods, and extensions that make SIP a robust
multipurpose communication protocol. Defined
originally in RFC 2976, the SIP INFO method is one such
extension to SIP, designed to allow exchange of
application-level information along the signaling path.
The information that could be transmitted using SIP

INFO was varied and, in a way, limitless, as it could be
tailor made for any application usage. For example, a
vendor could leverage SIP INFO to transmit resource
availability information or billing information or even
proprietary information. Over the years, SIP INFO has
evolved into a convenient way to communicate
application information spanning a broad spectrum of
use cases, including the following:
• DTMF transmission
• QSIG encapsulation
• Fast video update requests
• Billing
Originally, application information could be carried in

INFO message bodies or in specific SIP headers; the
drawback of this approach was the lack of semantics on
how specific application-level information is transmitted.
For example, with DTMF, without a clear set of rules
indicating how DTMF digits are transmitted from one
node to another, does the application indicate digit
presses in the INFO message headers or the body? If
included in the body, what parameters should be used?
RFC 6086 was developed in an effort to standardize what

information could be transmitted using INFO messages
and the semantics of how that application-level
information is delivered. RFC 6086 allows for the
creation of “info packages” that dictate the content and
semantics of the information transmitted between
applications; that is, different info packages can be
designed to transmit different application-level
information such as DTMF, billing, or resource
availability information.
At the time of this writing, there is no standardized

method for transmitting DTMF information using the
guidelines of RFC 6086. All implementations that choose
to transmit DTMF using SIP INFO do so using the
guidelines of RFC 2976.
Support for the SIP INFO method is advertised in the

SIP Allow header field of SIP requests and responses.
The INFO method is a request and has to be answered by
a 200 OK response. The streaming of a SIP INFO
message does not create a new SIP dialog between user
agents. Rather, it is sent on the existing dialog created by
a SIP INVITE message.
Example 3-4 shows a sample SIP INFO message for
DTMF digit 1, with a duration of 160 milliseconds.
Example 3-4 SIP Message Output for a SIP INFO

Message
INFO sip:2143302100@10.1.1.1 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.2:5060
From: <sip:9724401003@10.1.1.2>;tag=43
To: <sip:2143302100@10.1.1.1>;tag=9753.0207
Call-ID: 984072_15401962@172.80.2.100
CSeq: 25634 INFO
Supported: 100rel
Supported: timer
Content-Length: 26
Content-Type: application/dtmf-relay
Signal= 1
Duration= 160
Notice in Example 3-4 that the content type is specified

as application/dtmf-relay. In some implementations, it
can also be encoded as application/dtmf, although the
former variant is more popular.
Note
SIP INFO is covered here for completeness, but most Cisco products either
don’t support it at all or have very limited support (for example, they are unable
to send SIP INFO but are able to receive it and immediately convert it to RTP-
NTE).
SIP KPML
SIP Key Press Markup Language (KPML), defined in
RFC 4730, is used to monitor key presses. Before
describing the working of SIP KPML in the transmission
of DTMF, it is important to understand the underlying
framework governing its operation. SIP KPML works on
the subscribe/notify framework, which involves a
subscriber and a notifier. The subscriber is a user agent
that initiates a subscription for event updates or state
information to the notifier, and the notifier is a user
agent that notifies the subscriber of any state change or
observed events.
To receive event notifications from another user agent,

the subscriber sends a SIP SUBSCRIBE message with an
Event header; the contents of this header indicate the set
of events for which for notifications are solicited. The
Event header includes at most a single value, which
corresponds to the name of the event package for which
notifications are requested. Event packages are SIP
extensions that build on the subscribe/notify framework
of RFC 6665 to fit a specific usage paradigm. Several
event packages are standardized as RFCs, and KPML is
the one for DTMF.
Once a SUBSCRIPTION request has been accepted, the

notifier sends a SIP NOTIFY message to communicate
observed events or changes in state information, such
that it includes the same event package specified in the
SUBSCRIBE request. Figure 3-21 describes the exchange
between user agents that support the subscribe/notify
framework.
Figure 3-21 SIP Subscribe/Notify Framework
Each event package that is used in the subscribe/notify

framework specifies a set of rules that operationally and
syntactically define headers, message bodies, and
information exchanged in a SUBSCRIBE or NOTIFY
transaction. Support for this framework can be indicated
in any of the following ways:
• With the SUBSCRIBE method in the Allow header

field of SIP requests and responses
• In the Allow-Events header field
• Using the methods parameter of the Contact header
Each accepted subscription is active for a specific

duration and has to be refreshed by the subscriber. The
duration for which the subscription remains active is
defined by the Expires header field value. The subscriber
must refresh a subscription before it expires by sending a
new SUBSCRIBE message. Figure 3-22 depicts the
subscription refresh process.
Figure 3-22 Refreshing Subscriptions
A user agent can unsubscribe from state or event

notifications by sending a SUBSCRIBE message with the
Expires header field value set to 0. Once the subscriber
terminates a subscription, the notifier must not send
further NOTIFY requests carrying event or state
information.
While sending a SIP NOTIFY to the subscriber, the

notifier must include the same event package as specified
in the SUBSCRIBE request, along with the current state
of the subscription, which can take one of three values:
• Active: Indicates that the SUBSCRIBE request has

been accepted
• Pending: Indicates that there is insufficient policy

or administrative information to accept or deny the
subscription
• Terminated: Indicates that the subscription has

terminated, and no new notifications will be sent
Drawing from the concepts discussed, the operation of

the subscribe/notify framework can be summarized as
follows:
Step 1. A user agent that requires event or state

information updates from another entity (the
notifier) and sends a SIP SUBSCRIBE
request, referencing a specific event package
in the Event header field.
Step 2. On receiving the SIP SUBSCRIBE request,

assuming that the notifier understands the
event package specified in the Event header
field, a 200 OK is sent in response to the
SUBSCRIBE request. A SIP SUBSCRIBE is a
dialog-creating request and need not always
exist within a dialog established by an
INVITE/200 OK exchange.
Step 3. The duration for which the subscription is

valid is specified in the Expires header of the
200 OK sent in response to the SUBSCRIBE
request.
Step 4. As soon as the subscription has been

accepted, the notifier must send a SIP
NOTIFY message, regardless of whether it
has any event or state information to
communicate at the instant the subscription
was accepted. If it does not have any event or
state information to communicate at the
instant the subscription was accepted, it
sends a SIP NOTIFY message with an empty
message body.
Step 5. The notifier triggers a SIP NOTIFY request

every time there is a change in state
information or an observed event. The
NOTIFY message must contain the same
Event header field value as the SUBSCRIBE
request and must include the Subscription-
State header field value.
Step 6. The subscriber must ensure that

subscriptions are refreshed in a timely
manner. If the subscriber does not wish to
receive any further event notifications, it can
explicitly terminate the subscription at any
time.
As mentioned earlier in this chapter, SIP KPML, defined

in RFC 4730, uses the subscribe/notify framework to
report digit presses by using Extensible Markup
Language (XML) documents known as KPML. XML
documents are exchanged in the bodies of the
SUBSCRIBE and NOTIFY messages. In a SUBSCRIBE
message, the XML document serves to specify the digits
or pattern(s) of interest, whereas in the NOTIFY
message, it specifies the actual patterns or digits
collected.
The operational principles of SIP KPML are governed by

the kpml event package, which has to be included as an
event package in every SUBSCRIBE and NOTIFY
message used in the KPML framework.
There are two categories of KPML subscriptions, and

they differ in the duration for which subscriptions are
kept alive:
• One-shot subscriptions
• Persistent subscriptions
A one-shot subscription terminates as soon as a pattern

match occurs and a NOTIFY message is sent (that is, the
Subscription-State header value is set to terminated).
For further pattern match notifications, a new
SUBSCRIBE dialog has to be initiated. Figure 3-23
illustrates a one-shot subscription.
Figure 3-23 One-Shot Subscription
Persistent subscriptions remain active until explicitly

terminated, regardless of whether a pattern match is
indicated with a SIP NOTIFY message. Persistent
subscriptions have two further variants: single-notify
and continuous-notify subscriptions. A single-notify
subscription sends a NOTIFY message on a pattern
match but buffers or withholds further notifications until
a new subscription is received (on the same dialog).
Figure 3-24 illustrates a persistent single-notify
subscription.
Figure 3-24 Single-Notify Subscription
A continuous-notify subscription sends notifications

every time there is a pattern match. Figure 3-25
demonstrates the exchange and subscription state of a
persistent continuous subscription.
Figure 3-25 Continuous Subscription
KPML documents sent in SIP SUBSCRIBE messages

indicate patterns of interest for an application. Each
KPML document contains a <pattern> element;
embedded within this element are a series of <regex>
elements that indicate individual digit maps. The use of
multiple <regex> elements within a KPML document is
required when user input can match a plurality of
potential patterns, such as user input dialing while
dialing numbers within the scope of the North American
Numbering Plan (NANP).
Note
KPML is extensively used to indicate digits pressed while dialing a phone
number and is not restricted to reporting only DTMF information. Many of
Cisco’s IP phones use KPML to indicate the dial string while initiating a call
with Unified CM.
However, from the perspective of DTMF, a single

<regex> element suffices, as the events to be reported
are restricted to the ones indicated in Table 3-4.
Example 3-5 provides a snippet of a sample KPML

document that solicits DTMF event notification.
Example 3-5 KPML Document Snippet
<?xml version="1.0” encoding="UTF-8” ?>\n

<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-requ
www.w3.org/2001/XMLSchema-instance” xsi:schemaLocatio
kpml-request kpml-request.xsd” version="1.0">\n
\n
<pattern interdigittimer="7260000” persist="persist">
<regex tag="dtmf">[x*#ABCD]</regex>\n
</pattern>\n
\n
</kpml-request>\n
\r\n
In Example 3-5, the <pattern> element encloses the digit

map against which DTMF event notifications are sent.
The actual digit map string is included in the <regex>
element. For the notifier to distinguish between
persistent and one-time subscriptions (described
previously), the persist attribute of the <pattern>
element is used. The persist attribute can take one of the
following values:
• one-shot: Indicates one-shot subscriptions

• single-notify: Indicates single-notify
subscriptions
• persist: Indicates continuous-notify subscriptions
In the case of DTMF, subscriptions are always persistent,

as it does not make sense to send a new SIP SUBSCRIBE
message for each DTMF digit in a call.
The interdigittimer attribute is used when the notifier

transmits dial-string information. However, in the case
of DTMF notification, this timer isn’t of consequence and
is set to a sufficiently high value.
When a multitude of patterns are specified in a

subscription and the subscriber wants to know which
particular digit map was matched, it can include the tag
attribute in each <regex> element. When there is a
match at the notifier for a specific digit map, the notifier
includes the appropriate tag in the NOTIFY message that
has the KPML report. Example 3-5 uses the dtmf tag in
the <regex> element and is operationally redundant as
there is only a single digit map specified for DTMF
patterns.
Example 3-6 provides a snippet of a SIP NOTIFY

message that is sent in response to a DTMF event.
Example 3-6 SIP NOTIFY Message Sent in Response to

a DTMF Event
NOTIFY sip:10.1.1.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bK624B9
Call-ID: BE08917-8EB011E6-80F0A8E6-417953E@10.106.118
!! Message truncated for brevity!!
Event: kpml
Subscription-State: active
Content-Type: application/kpml-response+xml
Content-Length: 113
Message Body
<?xml version="1.0” encoding="UTF-8"?><kpml-response vers
ion="1.0” code="200” text="OK” digits="1” tag="dtmf"/>\r
\n
In Example 3-6, a notification is received for a DTMF

event. Within the body of the SIP NOTIFY message is
embedded a KPML document that is also known as a
KPML report. A KPML report for DTMF includes the
following mandatory and optional attributes:
• code (mandatory)
• text (mandatory)
• digit (optional)
• tag (optional)
The code and text attributes are mandatory and must be

part of every KPML report, regardless of whether digits
are reported. For example, when the KPML subscription
terminates, the KPML report contains the body specified
in Example 3-7. The digit attribute is used to specify the
specific digit matched against the digit map included in
the KPML body of the SUBSCRIBE request. As
mentioned earlier, the tag attribute is used to distinguish
between multiple potential patterns.
Example 3-7 is a snippet of the SIP NOTIFY message

sent in response to a subscription termination.
Example 3-7 SIP NOTIFY Message Sent in Response to

a Subscription Termination
NOTIFY sip:5081003@10.1.1.1:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.1.1.1:5060;branch=z9hG4bK6BE90
Call-ID: FB1F0711-8EAF11E6-93C5BE68-C696A51A@10.106.1
Event: kpml
Subscription-State: terminated
Content-Length: 109
Message Body
<?xml version="1.0” encoding="UTF-8"?><kpml-response
code="487” text="Subscription Expired"/>\r\n
As demonstrated in Example 3-7, the code and text

attributes are different from what is reported in Example
3-6.
As mentioned earlier in this section, Cisco IP phones use

SIP KPML to convey digits pressed on the keypad when a
user is initializing a call. At a high level, the sequence of
events for SIP KPML with IP phones and Unified CM is
as follow:
Step 1. The IP phone starts the conversation by

sending a SIP INVITE containing the first
digit dialed by the IP phone user and includes
the SIP Header field value Allow-Events:
kpml.
Step 2. Unified CM answers the INVITE with a 100

Trying and then sends a SIP SUBSCRIBE to
initiate the KPML persist subscription. The IP
phone sends a 200 OK response
acknowledging the SUBSCRIBE.
Step 3. Shortly after the 200 OK, the IP phone

sends a SIP NOTIFY for KPML with the SIP
Header field set to Subscription-State: active;
expires=7200. Upon receipt of the NOTIFY
message, Unified CM sends a 200 OK
response to acknowledge that the
subscription is now active.
Step 4. From this point forward, any digit pressed

by the user is sent as a SIP NOTIFY with a
KPML-XML message body indicating the
digit pressed by the user. Unified CM
acknowledges these incoming digits with a
200 OK and attempts to route the call. The
process of Unified CM call routing and digit
analysis is detailed in Chapter 4, “Unified CM
Call Routing and Digit Manipulation.”
Step 5. These two messages, NOTIFY and 200 OK,

continue until an applicable device is found,
at which point Unified CM tears down the
KPML subscription with a SIP SUBSCRIBE
and Expires: 0 in the SIP Header field.
Example 3-8 details snippets of these SIP messages

highlighted with comments tying the snippets to the
previous steps.
Example 3-8 SIP KPML Digits from IP Phone to

Unified CM
### Step 1, INVITE first digit

INVITE sip:1@172.18.110.48;user=phone SIP/2.0
From: “1008” <sip:1008@172.18.110.48>;tag=2c31246a214
To: sip:1@172.18.110.48
Call-ID: 2c31246a-214b0007-5b3d4635-0a50b2a8@14.50.21
[..truncated..]
Allow-Events: kpml,dialog
### Step 2, KPML SUBSCRIBE

SUBSCRIBE sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14
Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK39f
From: <sip:1@172.18.110.48>;tag=512298967
To: sip:1008@14.50.214.122
Call-ID: a8dfce00-1eb1bdb2-38ed3-306e12ac@172.18.110.
CSeq: 101 SUBSCRIBE
Event: kpml; call-id=2c31246a-214b0007-5b3d4635-0a50b
Expires: 7200
Contact: sip:1@172.18.110.48:5060;transport=tcp
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
<?xml version="1.0” encoding="UTF-8” ?>

<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-requ
<pattern criticaldigittimer="1000” extradigittimer="5

<regex tag="Backspace OK">[x#*+]|bs</regex>
</pattern>
</kpml-request>
### Step 3, KPML Subscription Active

NOTIFY sip:1@172.18.110.48:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 14.50.214.122:51851;branch=z9hG4bK3c
To: <sip:1@172.18.110.48>;tag=512298967
From: <sip:1008@14.50.214.122>;tag=2c31246a214b002018
CSeq: 1000 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14
Content-Length: 0
### Step 4, NOTIFY DIGIT and 200 OK

To: <sip:1@172.18.110.48>;tag=512298967
From: <sip:1008@14.50.214.122>;tag=2c31246a214b002018
CSeq: 1001 NOTIFY
Event: kpml
Max-Forwards: 70
Contact: <sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14
Content-Length: 205
Content-Disposition: session;handling=required
<?xml version="1.0” encoding="UTF-8"?>

<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-res
SIP/2.0 200 OK
From: <sip:1008@14.50.214.122>;tag=2c31246a214b002018
To: <sip:1@172.18.110.48>;tag=512298967
CSeq: 1001 NOTIFY
Content-Length: 0

CSeq: 1002 NOTIFY
CSeq: 1003 NOTIFY
### Step 5, KPML teardown

SUBSCRIBE sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14
From: <sip:1@172.18.110.48>;tag=512298967
To: <sip:1008@14.50.214.122>;tag=2c31246a214b0020180d
CSeq: 102 SUBSCRIBE
Event: kpml; call-id=2c31246a-214b0007-5b3d4635-0a50b
Expires: 0
Contact: sip:1@172.18.110.48:5060;transport=tcp
Max-Forwards: 70
Content-Length: 0
Figure 3-26 shows a SIP ladder diagram with the events

discussed in the previous steps and shown in Example 3-
8.
Figure 3-26 SIP Ladder Diagram of SIP KPML with IP

Phone and Unified CM
SIP Notify
The out-of-band methods of DTMF relay discussed so far
are widely adopted in SIP-based networks; however, in
terms of the amount of information disseminated, there
are a few shortcomings. For example, in the case of SIP
INFO, it is impossible to determine when the DTMF
event actually began. In addition, many vendors use
default event duration values for DTMF that fail to
accurately capture the actual event duration. In the case
of SIP KPML, digit notifications sent in the KPML report
capture only the actual digit event, without providing
much detail around how long the digit press event lasted,
which could lead to issues when these tones have to be
reproduced on a POTS interface (such as an ISDN
circuit) or converted to another DTMF encoding scheme.
The section “SIP KPML,” earlier in this chapter, provides

an introduction to the SIP subscribe/notify framework,
in which SIP NOTIFY messages are used to transmit
specific event notifications or changes in state
information. However, for notifications to be sent from
one user agent to another, there always has to be an
explicit, approved subscription in place (set up by the
SIP SUBSCRIBE method). SIP NOTIFY, sometimes
called “unsolicited NOTIFY,” tweaks this framework by
sending notifications for events such as DTMF and
message-waiting indicators (MWIs) without an explicit
subscription in place. This is a Cisco-proprietary
implementation and is not standardized in any IETF
RFC.
The unsolicited NOTIFY framework borrows heavily

from the framework standardized in RFC 2833/4733 by
reusing and slightly tweaking the payload format
highlighted earlier, in Figure 3-17. The use of this
payload format provides the following benefits:
• It provides an explicit means of indicating when the

DTMF event begins (by not setting the E bit).
• It allows for sending incremental updates that

accurately capture the event duration.
• It can explicitly signal the end of the event if the E

bit is set.
Unsolicited NOTIFY cannot be negotiated with SDP or
by using custom event packages such as KPML. Support
for unsolicited NOTIFY is indicated with the Call-Info
header field value; it is advertised in the SIP INVITE
message and reciprocated by the answering side in a
18X/200 response. Example 3-9 provides a sample
snippet of unsolicited NOTIFY negotiation between a
UAS and a UAC.
Example 3-9 SIP Message Snippet for Unsolicited

NOTIFY Negotiation
INVITE sip:4082000@10.1.1.1:5060 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.2:5060;branch=z9hG4bKBC3516C
!!! Message truncated for brevity!!!
CSeq: 101 INVITE
Contact: <sip:5081003@10.1.1.2:5060>
Call-Info: <sip:10.1.1.2:5060>;method="NOTIFY;Event=telep
honeevent;Duration=2000"
Expires: 180
Allow-Events: telephone-event
SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.1.1.2:5060;branch=z9hG4bKBC3516C7
CSeq: 101 INVITE
!!! Message truncated for brevity!!!
Contact: <sip:4082000@10.1.1.1:5060>
Call-Info: <sip:10.1.1.1:5060>;method="NOTIFY;Event=telep
honeevent;Duration=2000"
Content-Length: 0
Note
The UAS can indicate support for unsolicited NOTIFY in the 200 OK message
as well.
While negotiating bidirectional support for unsolicited
NOTIFY through the exchange of the Call-Info header,
the Duration header field value is of significant interest
as it does not indicate the default value for all DTMF
events in the dialog. Rather, it indicates the amount of
time between successive NOTIFY messages sent for a
single DTMF event.
It has already been established that unsolicited NOTIFY

borrows heavily from the framework of RFC 2833/4733,
using a similar payload structure and operating principle
for DTMF event indication. The major difference
between the two is that RFC 2833/4733 sends the
payload within RTP packets, while unsolicited NOTIFY
uses the SIP NOTIFY method body to encode the payload
in binary.
An actual Unsolicited SIP NOTIFY message with a

sample digit in the message body has not been shown in
this text because the binary payload type does not
translate well to text. The payload format for SIP
NOTIFY/unsolicited NOTIFY is diagrammed in Figure 3-
27.
Figure 3-27 Payload Format of an Unsolicited SIP

NOTIFY
The payload format for SIP NOTIFY is strikingly similar

to that of named telephony events, with the exception of
the Volume field and the way the Duration field is
expressed. The Volume field is left undefined in the case
of SIP NOTIFY, primarily because it is an out-of-band
method of DTMF relay. The Duration field is measured
in milliseconds in the case of SIP NOTIFY instead of in
timestamp units.
In addition to using a similar payload format for the
transmission of DTMF events, unsolicited NOTIFY also
uses three packet types per DTMF event:
• Start packet
• Refresh packet(s)
• End packet
Unsolicited NOTIFY for DTMF works as follows:
Step 1. As soon as DTMF stimulus is detected, a

start SIP NOTIFY message is sent, such that
the payload Duration field value mirrors the
duration negotiated in the Call-Info header of
the INVITE–18X/200 exchange. Because this
is an out-of-band method of DTMF
transmission, the M bit (found only in the
RTP packet headers) cannot be set to 1.
Instead, the E bit is set to 0, indicating that
the event is in progress.
Step 2. If the actual DTMF event is of shorter

duration than what was specified in the
Duration field value of the start NOTIFY
message, another NOTIFY is sent, with the E
bit set to 1, indicating the end of the DTMF
event. In addition, the Duration field value is
updated to indicate the actual event duration.
For example, if the start NOTIFY message
was sent with a duration of 2000
milliseconds and the actual DTMF event
lasted 800 milliseconds, then an end NOTIFY
message (with the E bit set) is sent with an
updated Duration field value of 800
milliseconds.
Step 3. If the actual DTMF event lasts longer than

what was specified in the Duration field value
of the start NOTIFY message, a refresh
NOTIFY message is sent such that the
Duration field value is updated to reflect
twice the negotiated duration in the Call-Info
header field. The frequency with which the
refresh NOTIFY messages are sent is dictated
by a timer whose expiration time is the same
as that of the negotiated duration in the Call-
Info header field.
Step 4. Regardless of whether the actual event

duration exceeds the duration of the start
NOTIFY message, the end of the DTMF event
has to be indicated, and this is done in an end
NOTIFY message with the E bit set along with
the actual event duration in the Duration field
value.
H.245 Alphanumeric and Signal

While most IP-based voice and video networks today
heavily use SIP for session setup, modification, and
termination, it is not uncommon to find certain networks
still operating with H.323 as the call control protocol.
From the perspective of DTMF, H.323 uses two methods
standardized in the H.245 specification:
• H.245 Alphanumeric: H.245 Alphanumeric

transports the ASCII representation of DTMF
events from one H.323 terminal to another. It is an
out-of-band DTMF transmission method that uses
the H.245 signaling channel. One major drawback
of this method of DTMF transmission is the
inability to indicate the event duration.
• H.245 Signal: H.245 Signal is another means of

transmitting DTMF information over the signaling
channel; it improves upon the framework of H.245
Alphanumeric by indicating the accurate event
duration and should be used in place of H.245
Alphanumeric where possible.
Note
H.323 can also use NTE for DTMF relay.
Other DTMF Relay Variants

The concept of DTMF relay exists in every VoIP protocol,
and you may come across other DTMF relay variants not
discussed in this chapter as you progress along your
collaboration technologies journey. A few examples of
variants include MGCP DTMF relay using MGCP NTFY
packets and SCCP DTMF using either KeypadButton
messages for digit collection or NotifyDtmfTone
messages when involving a media resource. Cisco even
created a proprietary DTMF relay method, Cisco RTP,
which has since been deprecated and removed from most
products. Application-specific proprietary DTMF
interworking also exists, such as the OOB JTAPI DTMF
notification used by UCCX, which is required due to
UCCX’s inability to detect in-band DTMF.
Due to the myriad DTMF relay options across many

different VoIP protocols, devices that terminate and re-
originate call legs, such as CUBE, have a great influence
on session capabilities and often need to perform DTMF
interworking. As the name implies, DTMF interworking
is the ability to interwork between the various DTMF
signaling types. DTMF interworking is used when two
endpoints do not use the same type for relaying DTMF
tones. Chapter 9, “CUBE Interworking Features,” details
how to configure CUBE for DTMF interworking with SIP
and H.323.
REFERENCES
Press, 2018.
RFC 2198, “RTP Payload for Redundant Audio Data,”

RFC 2833, “RTP Payload for DTMF Digits, Telephony

Tones and Telephony Signals,”
RFC 2976, “The SIP INFO Method,”


RFC 3388, “Grouping of Media Lines in the Session

RFC 3550, “RTP: A Transport Protocol for Real-Time

Applications,” https://tools.ietf.org/html/rfc3550
RFC 3551,” RTP Profile for Audio and Video

Conferences with Minimal Control”,
RFC 4571, “Framing Real-Time Transport Protocol

(RTP) and RTP Control Protocol (RTCP) Packets over
Connection-Oriented Transport,”
RFC 4730, “A Session Initiation Protocol (SIP) Event

Package for Key Press Stimulus (KPML),”

Tones, and Telephony Signals,”
RFC 4585, “Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback
(RTP/AVPF),” https://tools.ietf.org/html/rfc4585
RFC 5761, “Multiplexing RTP Data and Control

Packets on a Single Port,”
RFC 6086, “Session Initiation Protocol (SIP) INFO

Method and Package Framework,”
RFC 6464, “A Real-time Transport Protocol (RTP)

Header Extension for Client-to-Mixer Audio Level
Indication,” https://tools.ietf.org/html/rfc6464
RFC 6665, “SIP-Specific Event Notification,”

Recommendation H.225, “Call Signaling Protocols and

Media Stream Packetization for Packet-Based
Multimedia Communications Systems,”
https://www.itu.int/rec/ T-REC-H.225.0
Recommendation H.245, “Control Protocol for

Multimedia Communication,”
https://www.itu.int/rec/T-REC-H.245
Recommendation H.323, “Packet-Based Multimedia

Communication Systems,” https://www.itu.int/rec/T-
REC-H.323


MEMORY
There are no memory tables or lists for this chapter.
DEFINE KEY TERMS

Real-Time Transport Protocol (RTP)

Real-Time Transport Control Protocol (RTCP)
dual-tone multifrequency (DTMF)
named telephony event (NTE)
in-band DTMF relay
out-of-band (OOB) DTMF relay
Chapter 4. Unified CM Call Routing
and Digit Manipulation
• Pattern Matching: This section describes how

Unified CM analyzes both numeric and
alphanumeric sequences in order to match a
configured pattern and then routes the call to the
desired destination. This section also covers the
mechanisms by which the digits can be
manipulated as they traverse the system.
• Transformations and Masks: This section

discusses operations such as discarding digits,
transformation mask application, and prefixing
digits to alter calling and called numbers.
• Pattern Configuration and Device Selection:

This section describes the steps taken to locate an
end device or devices through the use of route
patterns, route lists, route groups, hunt pilots, hunt
lists, and line groups.
• Partitions and Calling Search Spaces: This

section discusses the methods by which patterns in
Unified CM can be placed into logical groups for
the purposes of class of service restrictions,
regional variations in dial plan, time of day routing,
and more.
• Translation Patterns: This section describes a

dial plan element used to manipulate calling and
called party numbers and perform powerful
modifications during the call routing and digit
analysis process in Unified CM.
• Transformation Patterns: This section
discusses transformation patterns, which, like
translation patterns, can be leveraged to perform
calling and called party modifications but are
typically applied once a call has been routed to a
device.
• Putting It All Together: Tail-End Hop Off

(TEHO): This section shows how all the dial plan
constructs described in previous sections of this
chapter can be put together to implement tail-end
hop off (TEHO).
• Alphanumeric URI Routing: This section

describes the unique characteristics of
alphanumeric URIs and how they are handled and
routed in Unified CM.
• Intercluster Dial Plan Replication: This

section explains the mechanisms available to share
dial plan–related information between multiple
Unified CM clusters in order to facilitate both
numeric and alphanumeric dialing across an
enterprise.
• Troubleshooting Call Routing and Digit

Manipulation: This section describes various
tools and diagnostic logs that can help troubleshoot
issues related to call routing.

exam topics:
• 4.1 Configure these globalized call routing elements

in Cisco Unified Communications Manager
• 4.1.a Translation patterns

• 4.1.b Route patterns
• 4.1.c SIP route patterns

• 4.1.d Transformation patterns
• 4.1.e Standard local route group
• 4.1.f TEHO
• 4.2 Troubleshoot these globalized call routing

elements in Cisco Unified Communications
Manager
• 4.2.a Translation patterns
• 4.2.b Route patterns

• 4.2.c SIP route patterns
• 4.2.d Transformation patterns

• 4.2.e Standard local route group
• 4.2.f TEHO
• 5.2 Configure ILS, URI synchronization, and GDPR
• 5.3 Configure hunt groups
• 5.4 Configure call queuing
• 5.5 Configure time of day routing
The primary purpose of Cisco Unified Communications

Manager (Unified CM) is to collect digits or
alphanumeric sequences from a user or source device
and determine the appropriate destination for that call.
This chapter goes into detail on the various dial plan
elements available in Unified CM that, when combined,
provide instructions on how to route calls throughout the
system. Unified CM has, arguably, the most flexible and
powerful call routing engine of any comparable platform;
however, this flexibility comes at the cost of some level of
complexity. This chapter provides details on how these
dial plan elements interact with each other to form the
call routing engine of Unified CM. The majority of the
configuration options discussed in this chapter are found
in the Call Routing menu in the Unified CM
Administration user interface.

1. Which of the following matches the numbers in the

range 1000 through 1999 on a route pattern in
Unified CM?
a. 1…
b. 1XXX
c. 1***
d. 1{3d}
e. 1!
2. Which of the following are valid transformation
masks? (Choose three.)
a. \+1919555XXXX
b. 1XXX
c. 1***
d. [2-9]XXXX
e. +44XXXXXXX
3. Which of the following allow you to apply an external

phone number mask to a number? (Choose three.)
a. Route pattern
b. Route list
c. Route group
d. Line group
e. Calling party transformation pattern
f. Called party transformation pattern
4. Which of the following are distribution algorithms

you can configure on a route group? (Choose two.)
a. Longest Idle
b. Top Down
c. Bottom Up
d. Circular
e. Randomized
5. Which of the following must be present in a route

pattern to be able to use digit discard instructions?
(Choose three.)
a. X
b. !
c. @
d. .
e. #
6. Where can call queuing be configured?

a. Route pattern
b. Hunt pilot
c. Route list
d. Hunt list
e. Line group
7. Which statement is true of partitions and calling

search spaces?
a. Partitions contain unordered lists of calling search

spaces.
b. Calling search spaces contain unordered lists of

partitions.
c. Partitions contain ordered lists of calling search

spaces.
d. Calling search spaces contain ordered lists of

partitions.
e. Route patterns and directory numbers can be

placed in a calling search space.
8. Which of the following best describes the calling

abilities of a device with a calling search space set to
< None >?
a. This device will not be able to place any outbound
calls because the CSS is empty.
b. This device will be able to place outbound calls to

any device or pattern in the < None > partition.
c. This device will not be able to receive any inbound
calls.
d. This device will only be able to receive inbound

calls from others configured with the < None >
calling search space.
9. Which of the following parameters can be configured

on a translation pattern but not on a route pattern?
a. Calling Search Space
b. Route Partition
c. Do Not Wait For Interdigit Timeout On

Subsequent Hops
d. Use Originator’s Calling Search Space
e. Use Calling Party's External Phone Number Mask
10. A user dials 1000, which matches the translation

pattern 1XXX. This translation pattern is configured
to transform the called party number with a mask of
2XXX. Using the calling search space on the
translation pattern, a match is found for a route
pattern 2XXX, which is configured to route the call to
a route list. On the route pattern, you configure the
called party transformation mask 3XXX. On the route
list that matches, in the route list details for a route
group, you configure the called party transformation
mask X5XX. This route group matches a SIP trunk
with a called party transformation CSS configured. In
that CSS, you have the following called party
transformation patterns configured:
• 1XXX transforms the called party to 1111
• 15XX transforms the called party to 1555
• 2XXX transforms the called party to 2222

What will be the called party number when the call is

presented to the destination of the SIP trunk?
a. 1111
b. 1555
c. 2222
d. 2555
e. 3333
f. 3555
11. A called party transformation of 456.XXXX is

configured with the following settings:
Digit Discard Instructions: PreDot

Called Party Transformation Mask: 11XXXX
Prefix Digits: 123

If a user dials 4568888, and it matches this pattern,
what is the resulting called party number?
a. 1238888
b. 1118888
c. 123118888
d. 1234118888
e. 8888
12. What is the first step in routing a call when building

a scalable dial plan that includes tail-end hop off?
a. Localize the calling and called party numbers to
look for hop off matches
b. Use Global Dial Plan Replication to advertise

TEHO patterns
c. Globalize the calling and called numbers to +E.164
format
d. Match a route pattern with a route list containing

the remote gateway or trunk
e. Ensure that all patterns are configured for urgent

priority
13. Which statements are true of URI routing? (Choose

two.)
a. Local directory URIs are placed into partitions.
b. ILS learned directory URIs are placed into

partitions.
c. SIP route patterns are placed into partitions.
d. The cluster fully qualified DN is used when routing

non-numeric URIs.
e. The organization top-level domain is used when

routing non-numeric URIs.
14. What are the different modes a cluster can be in

when it is part of an ILS network? (Choose two.)
a. Stand Alone Cluster
b. Hub
c. Spoke
d. Client
e. Server
15. Which troubleshooting tools allow you to view a

ladder diagram of SIP signaling? (Choose three.)
a. Dialed Number Analyzer
b. SIP Call Processor
c. TranslatorX
d. Real-Time Monitoring Tool

e. Collaboration Solutions Analyzer
16. What happens to a call if the following line appears

in an SDL trace file?
potentialMatches=NoPotentialMatchesExist
a. The call fails immediately.
b. The call is routed immediately.
c. The call is routed after waiting for interdigit

timeout.
d. The call fails after waiting for interdigit timeout.
e. Not enough information is provided.
FOUNDATION TOPICS
PATTERN MATCHING
To configure a dial plan in Unified CM, an administrator
must specify the phone numbers or alphanumeric URIs
that a user can dial. These sequences are generally
referred to as patterns. A variety of dial plan
configuration elements—such as route patterns,
translation patterns, and directory numbers—provide
fields for an administrator to configure patterns.
Regardless of the dial plan element, patterns all behave
the same way throughout the system.
Patterns allow an administrator to configure either

numeric strings (for example, 1000 for extension 1000),
numeric patterns containing wildcards (for example,
1XXX, which matches the numbers 1000 through 1999),
or alphanumeric patterns (for example, a URI such as
user@example.com). Before delving into the various dial
plan elements that can accept one of these patterns, it
helps to understand the various wildcards available and
how Unified CM examines a dialed number or URI to
find a matching configured pattern. Although there are
similarities between numeric and alphanumeric patterns,
it helps to examine them separately.
Numeric Matching
Let’s first discuss how Unified CM deals with numeric
patterns. As mentioned earlier, a numeric pattern can be
a sequence of digits or can contain a variety of wildcard
characters that can match more than one digit. Table 4-2
describes the various numeric wildcard characters
available in Unified CM.
Table 4-2 Wildcard Characters for Numeric Patterns

All of the elements listed in Table 4-2 can be combined in
any order in a pattern with the exception of the ? and +
wildcards, which must be preceded by at least one other
digit or wildcard. For example, to describe a 10-digit
number in the North American Numbering Plan
(NANP), an administrator could configure the following
pattern:
[2-9]XX[2-9]XXXXXX
A phone number in the NANP comprises a three-digit

area code, three-digit office code, and four-digit
subscriber number. The area code and office codes
cannot start with either a 0 or a 1. As a result, the
wildcard sequence [2-9] is used to exclude the digits 0
and 1, and the X wildcard indicates the digits, which can
be 0 through 9.
You might be tempted to use [^01] instead of [2-9] as, at

first glance, they may appear to mean the same thing.
However, [^01] would be equivalent to [2-9#*] because *
and # are also valid digits, and [2-9] is far more readable.
To allow a user to dial the digit 9 followed by the 10-digit

number to indicate the desire to place a PSTN call, the
pattern would look like this:
9[2-9]XX[2-9]XXXXXX
The leading 9 in this case is sometimes called an access

code, dial-out pattern, or steering digit. This digit is not
part of the number the user wants to dial but rather
indicates what kind of number follows the steering digit
—in this case, a PSTN number. These steering digits are
typically removed before routing the call to the final
destination, so it is useful to delimit the portion of the
pattern that represents the part that should be removed.
The period or dot character can be used for this purpose
as follows:
9.[2-9]XX[2-9]XXXXXX
Recall that the dot does not match any digits or affect the
way the pattern is matched. It simply acts as a delimiter
that can later be used with digit discard instructions, as
discussed later in this chapter. Although 9 is the most
common steering digit, the steering digit can be
different. There may also be more than one type of
steering digit in a dial plan used to direct calls to
different parts of an organization, depending on the
particular design and deployment. Alternatively, a design
might not use steering digits at all but instead might
require users to just dial all numbers as they would from
a home phone or mobile phone.
To represent a North American number in +E.164

notation, this is the pattern to use:
\+1[2-9]XX[2-9]XXXXXX
Notice that this pattern starts with a \+ wildcard, which

matches exactly one instance of the character +. A
backslash escape character (\) is necessary because the +
wildcard already means something different.
Closest-Match Routing
In many scenarios, there may be a variety of different
configured patterns that match a sequence of digits
provided by an end user. For example, consider a Unified
CM cluster with the following patterns configured:
1000
100X
10X5
1[^1]XX
1XXX
1!
If a user dials the number 1000, which destination does

Unified CM select? The function in Unified CM that is
responsible for determining the correct destination is
called digit analysis. This component is part of the
Cisco CallManager service that runs on all Unified CM
servers that perform call processing functions. Digit
analysis finds the “best” match for a dialed number by
using closest-match routing. For each matching
pattern, digit analysis considers the number of possible
matches for a given pattern. For example, the pattern
100X can match 10 possible numbers—from 1000
through 1009. The pattern 1XXX can match up to 1000
numbers—from 1000 through 1999.
It is not obvious how many numbers the 1! pattern

matches. You might be tempted to think it matches an
infinite number of digits because the pattern matches a
variable number of digits—for example, 10, 1000,
1000000, and 1000000000 are all valid matches for the
1! pattern—but for the purposes of closest-match routing,
digit analysis only evaluates the number of potential
matches given the number of digits dialed. In other
words, if a user dials 1000, digit analysis treats the 1! as
1XXX, which means it also matches 1000 possible
numbers.
So back to our example: If a user dials 1000, it’s easy to

see that the pattern 1000 is the best match because it
matches exactly 1 number. But what if a user dials 1005?
That sequence matches 100X, 10X5, 1XXX, and 1!, with
100X and 10X5 each possibly matching 10 numbers.
Which one does digit analysis choose? In this scenario, it
is non-deterministic, meaning that you don’t know which
one will be used. Later, when we discuss partitions and
calling search spaces, you will learn of a way to give
priority to one or the other, but in general, it is not a
good practice to have such ambiguity in your dial plan.
What if a user dials the digits 1100? Which is the best

match in this case? You might be tempted to pick
1[^1]XX because your first instinct might be to consider
this to be equivalent to 1[02-9]XX, which would match
900 different patterns as opposed to the 1000 patterns
matched by 1XXX and 1! In this case, however you would
be wrong in assuming this. The caret (^) notation
includes the *, #, A, B, C, and D digits as well, so 1[^1]XX
actually potentially matches 1500 different patterns and
is therefore not as good a match as 1XXX. It turns out
that 1! in this case also matches 1000 patterns, so again,
the result is not deterministic between 1XXX and 1!. Be
very careful with overlapping patterns to always ensure
that you understand which pattern is a better match.
Digit-by-Digit Versus Enbloc Calling

Generally speaking, Unified CM performs digit-by-digit
analysis of numeric patterns. This means that, as the
name implies, it searches for a match as each digit is
entered by a user (for example, SIP IP phone via KPML).
In contrast, with enbloc calling, the originating device
sends all the digits at once (for example, SIP server via
SIP INVITE). Enbloc calling can also occur when the
user of an IP phone dials a number from a directory
(click to call) or invokes a function such as redial, where
the entire number to be dialed is already known by the
phone.
Let’s use the same patterns as before for an example of

digit-by-digit matching:
1000
100X
10X5
1XXX
1!
If a user picks up a phone and dials the digit 2, Unified

CM recognizes that there are no patterns that could
possibly match because none of the patterns permit the
first digit to be a 2. In the terminology of digit analysis,
there are no potential matches because no pattern could
potentially match if the user were to continue dialing
more digits.
On the other hand, if the user dials the digit 1, all the
patterns are considered potential matches; however,
none of them actually are matches. When the user dials a
second digit—for example, the digit 5—the situation
changes significantly. First of all, 1000, 100X, and 10X5
are no longer potential matches. 1XXX is considered a
potential match because, if the user were to dial two
more digits, it would match. 1! in this scenario is a bit
unusual in that it is both a match and a potential match.
It is a match because the digits 15 match the pattern 1! (1
followed by one or more numeric digits) but could also
possibly match additional digits as well because this
pattern allows for one or more digits after the 1.
When Unified CM is in a situation where it has found a

match, but potential matches still exist, it does not route
the call immediately and, instead, continues to wait for
more digits until the interdigit timeout (also known as
the T.302 timer) expires. There are some exceptions to
this rule. If the pattern that matched is configured with
urgent priority, the call is routed immediately, even if
potential matches exist. In addition, if the call arrives to
Unified CM via a signaling channel that does not support
digit-by-digit transmission of digits—for example, on a
SIP trunk—then Unified CM looks for a match
immediately and does not consider the possibility that
more digits could arrive. When we discuss translation
patterns later in this chapter, you will also see that an
administrator can indicate to the system that, in certain
scenarios, digit analysis should not await further digits
by using a configuration parameter on the translation
pattern.
Alphanumeric URI Dialing

With the introduction of alphanumeric uniform
resource identifier (URI) dialing in Unified CM,
the product gained the ability to dial not just phone
numbers but also URIs that look similar to email
addresses in the format user@domain (for example,
user1@example.com).
URIs have two distinct components, separated by the @

sign. The component to the left of the @ is sometimes
referred to as the left-hand-side (LHS), or the user
portion, and, as you may have guessed, the component to
the right is referred to as the right-hand-side (RHS), or
the host portion.
Unified CM generally matches URIs based only on an

exact match. URIs are always sent in a single request, so
digit-by-digit processing or potential matches do not
apply to alphanumeric URIs. If there is no exact match
for a URI, Unified CM tries to route the call based on the
host/RHS portion of the URI only. When routing based
on just the host portion, there are only a few wildcards,
as described in Table 4-3.
Table 4-3 Wildcard Characters for Alphanumeric URI

Patterns
When dealing with URIs, there are several rules that
determine how Unified CM routes these calls. These
rules are discussed later in this chapter, in the section
“Intercluster Dial Plan Replication,” as the concepts
discussed there are essential to the process of routing
URIs.
TRANSFORMATIONS AND MASKS

Once Unified CM has matched a pattern, some dial plan
elements allow administrators to define transformations
on those numbers to modify either the calling and/or
called party number before moving on to the next dial
plan element or device. Transformations and masks
are used in a variety of configuration elements in Unified
CM, and understanding how they work is essential to
having a good understanding of how dial plans work in
Unified CM.
Note
Don’t be confused by the difference between transformations and
transformation patterns. Transformation patterns are discussed later in this
chapter. Transformations can be configured on a variety of dial plan elements,
including, but not limited to, transformation patterns, route patterns, translation
patterns, and route lists.
Generally, three types of transformations can be

performed using Unified CM:
• Digit discard instructions
• Transform mask
• Prefix digits
Digit Discard Instructions

Digit discard instructions allow you to modify a
number by discarding specific digits determined by the
selected option. Many of the choices defined in the digit
discard instructions selection are tied directly to the
numbering plan selected and apply only when a pattern
contains the @ wildcard. These numbering plan–specific
digit discard instructions are seldom used, primarily
because the @ wildcard is not commonly recommended
when configuring the North American Numbering Plan
and most other numbering plans that can be added to
Unified CM do not include any special digit discard
instructions.
The most commonly used digit discard instructions are

PreDot, Trailing-#, and PreDot Trailing-# (which
combines the first two options). The names of these digit
discard instructions are self-explanatory. The PreDot
digit discard instruction removes any digits that appear
before the dot in a pattern. If a pattern does not contain a
dot, the digit discard instruction has no effect. The
Trailing-# digit discard instruction removes a #
character if found at the end of a pattern. (When we
discuss a more complex dial plan later in this chapter,
you will see how the trailing # is used to indicate end of
dialing in variable-length calling scenarios.) The final
option, PreDot Trailing-#, discards both the digits before
the dot as well as the trailing #, if present.
Transform Masks
Transform masks provide a powerful way to
manipulate arbitrary digits in a number string. They
allow an administrator to add, remove, or change
numbers in a digit string before sending that number to
the end device or the next dial plan element. Masks can
be thought of as addition problems, where the number to
be modified and the mask to be applied are right-aligned
and then the digits in the number and mask are
compared to determine the result. A mask can contain
either a digit (0-9, *, #, +) or an X. A specific digit or
character replaces the digit at that position with the one
in the mask. The X character keeps the existing digit at
that position. The mask can also be shorter or longer
than the number of digits in the number to be modified.
Let’s look at some examples that illustrate how this
works.
In this first example, we start with the number 2000 and

apply the mask 408555XXXX:
Original 20
number 00
40
85
Mask 55
XX
XX
40
85
Final result 55
20
00
You can see that the mask transforms the extension into
a 10-digit number. This mask might be used to transform
the calling party number for presentation to the PSTN.
As another example, say a user dials 9 to indicate a PSTN

call and then dials the 10-digit number 4085551234 (so
the full sequence of dialed numbers is 94085551234). To
convert this number to +E.164 format, an
administrator would have to remove the 9 and then
prefix the characters +1, with the + indicating +E.164
format and the 1 indicating the country code for the
NANP. In order to accomplish this task, the
administrator can apply the mask +1XXXXXXXXXX as
follows:
94
08
Original 55
number 51
23
4
+1
XX
XX
Mask
XX
XX
XX
+1
40
85
Final result
55
12
34
Notice how in a mask, to prefix a + character you do not

include the backslash character the way you do when
indicating the + character in a pattern.
As a final example, consider the case of the number 2000

with the mask +1XXXXXXXXXX. What happens in this
scenario?
Original 20
number 00
Mask +1
XX
XX
XX
XX
XX
+1
??
??
Final result
??
12
34
In this case, the final result has digits that are unknown
because an X is being applied to a nonexistent digit. In
this scenario, the entire number is discarded because it is
invalid. Care should be taken to ensure that scenarios
like this do not occur.
Prefix Digits
The final form of transformation by using prefix digits.
The Prefix Digits field allows administrators to, as the
name implies, prefix digits to a number. The prefix is
applied regardless of the number of digits. For example,
if the Prefix Digits field is set to 9, the numbers 10, 100,
and 1000 are transformed to 910, 9100, and 91000,
respectively.
Combining Transformations
The three transformations mentioned—digit discard

instructions, transform masks, and prefix digits—can all
be used at the same time on some dial plan elements.
Not all of them are available on all dial plan elements.
For example, digit discard instructions are generally only
applicable to called party numbers. Sometimes only a
transform mask is available. Whenever more than one
transformation is available, the transformations all
apply, and the order in which they are applied is
important. When we dive into some of the specific dial
plan elements, you will see that the Unified CM
Administration UI displays the transformations in the
order which they are applied, which makes the order
easy to determine. However, generally speaking, the
order is always digit discard instructions followed by
transform mask followed by prefix digits.
For example, a route pattern (as discussed in the next

section) permits an administrator to transform the called
party number with digit discard instructions, a transform
mask, and prefix digits—applied in this order. An
administrator could have a pattern such as 9.[2-9]XX[2-
9]XXXXXX configured to discard PreDot, apply the
transform mask 1XXXXXXXXXX, and then prefix +:
94
08
Dialed 52
number 67
20
9
9.
[2
-
9]
XX
Route pattern [2
-
9]
XX
XX
XX
Pr
Discard eD
ot
New number 40
85
26
72
09
1X
XX
Transform XX
mask XX
XX
X
14
08
52
New number
67
20
9
Prefix +
+1
40
85
Final number
26
72
09
Note
This example is just for illustrative purposes because it would be much easier
to just apply a mask of +1XXXXXXXXXX to achieve the same result. However,
you will find that in some scenarios, using one or more of the transformations is
easier.
Now that you know how Unified CM finds the best

pattern using digit analysis and the tools available to
manipulate numbers, let’s move on to more specifics on
where these patterns are configured and how patterns
are mapped to an end device or feature that can process
the call.
PATTERN CONFIGURATION AND
DEVICE SELECTION
Unified CM provides a variety of configuration
constructs for assigning numbers or ranges of numbers
to devices and features. This chapter largely focuses on
how dialing a number or URI results in a call being
routed to a device, whether it be a locally registered
device such as a phone or a destination that is reachable
by traversing a gateway or trunk to reach an external
system or other network. Patterns associated with
specific features are discussed in greater detail in
Chapter 6, “Unified CM Call Control Features.” As you
will see, patterns are configured similarly, regardless of
whether they are being configured on a device or on a
feature.
The patterns that Unified CM allows you to configure

ultimately associate a called device or feature with a
particular number or alphanumeric sequence. For
example, if an administrator assigns the pattern 2000 as
the directory number on a phone line, the desired
outcome is for the phone line to ring when the number
2000 is called. As you will see, the call routing logic can
be significantly more complicated than this, but you
should understand the basics of where patterns can be
configured. The following sections provide details on the
various pattern configurations.
Directory Numbers
A directory number is the most basic pattern
configuration. It assigns a pattern to a line on a device,
whether it be a physical phone, a soft client such as Cisco
Jabber or Webex Teams, or a virtual device such as a
Remote Destination Profile or CTI Route Point.
You typically configure directory numbers by navigating

to the configuration page for a phone (accessed through
Unified CM Administration > Device > Phone) and then
selecting one of the directory numbers available for that
device. You can also configure directory numbers
independently of the phones they appear on by
navigating to Unified CM Administration > Call Routing
> Directory Number. Figure 4-1 shows the pattern
\+19195551234 being configured as a directory number
on an IP phone line. (Note that after you click Save when
adding a line, the Active checkbox disappears, so you see
this option only while adding a line or if when looking at
a directory number that is not assigned to a phone.)
Figure 4-1 Directory Number Configuration on a Line
In nearly all real-world scenarios, a directory number

does not contain any wildcards. This is because a line on
a phone is typically assigned a single number rather than
a range of numbers that would cause that line to ring;
however, there is nothing stopping an administrator
from configuring wildcards on a directory number.
A directory number directly associates a pattern to one

or more devices. Multiple devices can share a directory
number. This is referred to as a shared line appearance.
A shared line appearance allows for multiple devices to
ring at the same time when a directory number is dialed,
and a user can answer the call on any of the devices that
are ringing. A call on a shared line appearance can be
placed on hold and resumed on other devices sharing
that line. A shared line appearance is a prerequisite for
features such as barge, a feature that allows a user to join
(barge) into an active call on a shared line.
Note that while multiple devices can share a single
directory number, there are some configuration
parameters that apply to the appearance of a shared line
on a specific device. For example, the text label used to
display the line on a phone can be different between two
devices sharing the same line. More critically for the
purposes of call routing and digit manipulation, each line
appearance of the same directory number can have
different external phone number masks.
The external phone number mask is an important

parameter to understand, as it can be used to manipulate
the calling party number when sending calls out to the
PSTN or other external systems. As the name implies,
the external phone number mask is a transform mask. By
itself, the external phone number mask has no effect on
calling or called party numbers. Other configuration
parameters that we will discuss shortly can selectively
decide whether to use the external phone number mask
during the course of routing a call to its ultimate
destination. The external phone number mask is also
leveraged as part of the automated alternate routing
(AAR), feature which attempts to reroute calls that fail
between locations if the amount of bandwidth is
exceeded. In the case of a CAC failure, the external phone
number mask is used along with the AAR group
configuration to determine the PSTN number to use to
reroute the call.
Note
An administrator can configure alternate numbers associated with a directory
number. Alternate numbers are discussed later in this chapter, in the section
“Global Dial Plan Replication.”
Another unique characteristic of directory numbers is

that this is the only way that Unified CM allows an
administrator to configure a name associated with a
number. There are two distinct names that can be
configured on a directory number: the alerting name and
the display name. The alerting name is presented to a
device that places a call to the directory number. For
example, if directory number 2000 has an alerting name
configured as Line Name 2000, if Phone A places a call
to 2000, the display on Phone A shows that the
destination is Line Name 2000.
Remember that directory numbers can appear on various

phones as shared line appearances. Each shared line
appearance of a directory number allows an
administrator to configure the display name. Continuing
the previous example, if Phone B and Phone C both have
directory number 2000 configured, the display name
could be configured differently for the line appearances
on those phones. For example, directory number 2000
appearing on Phone B could be configured with the
directory name Phone B 2000, and the directory number
2000 appearing on Phone C could be configured with the
directory name Phone C 2000. If Phone A dials 2000,
Phone A still shows the destination name of the call as
Line Name 2000, as in the previous example, but after
the call is answered, the display changes, depending on
whether Phone B or Phone C answers the call. If Phone B
answers the call, Phone A now shows Phone B 2000 as
the connected name, whereas if Phone C answers the
call, Phone A shows Phone C 2000 as the connected
name. Table 4-4 illustrates this example by indicating
what appears on the calling party device for the alerting
and connected party names.
Table 4-4 Shared Line Alerting and Connected Name

Example
Whenever a call originates from a phone line, the display
name is always used as the calling party name. This does
not change the way that the called/connected party name
changes when the call is answered. Using the same
example as in Table 4-4, the remote called party phone
would show an inbound call from Phone A 1000 on the
display during both the alerting (ringing) phase and
when the call has been answered.
The final point to mention regarding the display and

alerting name configuration is that the Unified CM
Administration user interface has a configuration page
with two fields, one of which allows you to configure the
ASCII version of the name. The ASCII version is used for
any devices that do not support UTF-8-encoded text.
This applies to a small number of legacy phones and,
more importantly, applies to any SIP trunks that do not
have the Transmit UTF-8 for Calling Party Name setting
configured.
Route Patterns, Route Lists, and Route Groups

Route patterns, route lists, and route groups work
together to allow an administrator to route calls from a
Unified CM cluster to an external destination. This
includes routing calls to PSTN gateways such as CUBE
and Expressway for B2B video calls, and it could even
extend to routing a SIP trunk to another Unified CM
cluster, such as a Session Management Edition (SME)
cluster. The destination device can be a gateway device
(Unified CM Administration > Device > Gateway) or a
trunk device (Unified CM Administration > Device >
Trunk). Gateways include MGCP, H.323, and SCCP
gateways, while trunks include SIP and H.323
intercluster trunks (both gatekeeper and non-
gatekeeper-controlled).
At a high level, a route pattern allows an administrator

to configure a pattern that, when matched, routes a call
either directly to a gateway or trunk device or to a route
list. A route list is an ordered list of route groups that
are used to find the appropriate destination, and a route
group is a collection of one or more gateways or trunks.
Together, these three constructs allow an administrator
to route calls to external systems while also providing
load balancing and redundancy. Although the routing
logic matches in the order route pattern, then route list,
then route group, then gateway/trunk, you must
configure these in the opposite order because you must
have a gateway or trunk configured before you can add it
to a route group, you must have a route group configured
before you can configure the route list, and you must
have the route list configured before you can add a route
pattern. (Chapter 5, “Unified CM SIP Trunk
Configuration,” goes into detail on how to configure SIP
trunks.)
Figure 4-2 shows the relationships between route

patterns, route lists, route groups, gateways, and trunks.
Figure 4-2 Relationships Between Route Patterns,

Route Lists, Route Groups, Gateways, and Trunks
Route Patterns
Although when configuring these dial plan elements, you
configure the route pattern last, here we talk about it
first. Figure 4-3 shows the route pattern configuration
page in Unified CM Administration user interface, which
you reach by navigating to Call Routing > Route/Hunt >
Route Pattern.
Figure 4-3 Route Pattern Configuration
You can see that there are many possible configuration

options on this page, which can be a bit intimidating.
However, as you will see, most of the options are self-
explanatory. You will also see that there are many
similarities between the configuration of a route pattern
and the configuration of a translation pattern, covered
later in this chapter.
The first parameter on the route pattern configuration

page is somewhat confusingly named Route Pattern.
Unified CM generally refers to patterns as route patterns
and also has a specific configuration element called a
route pattern. This book uses the term pattern to refer to
the generic use of the word route pattern (as it appears
as the label for the first parameter on this configuration
page) and uses the term route pattern to denote the dial
plan element called the route pattern configuration
(shown in Figure 4-3). The Route Pattern field on the
route pattern configuration page allows you to specify
the pattern you would like to be matched. A route
patterns typically contains a pattern with wildcards, as
these patterns typically match large ranges of directory
numbers. (However, route patterns do not always have
wildcards.)
Table 4-5 describes each of the fields on the route

pattern configuration page and the function of each
parameter. If you are unfamiliar with any of the fields on
the route pattern configuration page, you should read
through the table because you will see that most of these
parameters apply to other dial plan elements, such as
translation patterns and calling/called number
transformation patterns, discussed later in this chapter.
Table 4-5 Parameters on the Route Pattern

Configuration Page
You will notice that after matching a route pattern, you
have quite a bit of flexibility to modify both the calling
and called party numbers. Be aware that transformations
made on a route pattern could have some unintended
consequences. First of all, any transformations of the
called party number will be reflected (at least
temporarily) on the phone of the user placing the call.
For example, if you configure a PreDot digit discard
instruction on a pattern 9.[2-9]XX[2-9]XXXXXX and a
user dials 99195551234, the user’s phone display changes
to indicate that the number 9195551234 has been called.
You will see, however, that additional dial plan elements
may change this again.
When in doubt about a setting in the Unified CM

Administration user interface, remember that you can
select Help > This Page to get to a built-in guide with
many definitions specific to the page currently being
viewed.
The second idiosyncrasy to keep in mind with

transformations on a route pattern is that any
transformation done on a route pattern will be
completely replaced by transformations performed on a
route list, as discussed shortly. The transformations on a
route list start from the original calling/called party
numbers, not the output of the transformations on the
route pattern. Because of these caveats, it is often
preferable to not use the transformations on the route
pattern configuration page and rather use the similar
configuration options provided on the route group
details configuration on the route list.
If the route pattern configuration page indicates a

gateway or trunk as the destination, the call is routed
immediately to that single gateway or trunk. There is no
additional failover that occurs if the call fails to be
extended on the specified gateway or trunk. To be able to
route calls across multiple gateways or trunks to balance
the load across multiple trunks or to provide resiliency in
the event that one or more gateways or trunks fail, you
must leverage route lists and route groups.
Route Lists
A route list allows you to specify an ordered list of route
groups to which to route a call. The route groups
specified in a route list are always used in a top-down
order. This means that as long as the devices within the
first route group in a route list are working, that route
list will receive all of the calls until all of the devices
within that route group fail or run out of capacity, at
which point the next route group in the route list is
attempted. This continues until the call succeeds or until
the end of the list is reached. If Unified CM fails to
extend a call to any of the route list entries, it generates a
RouteListExhausted alarm and alerts to tell the
administrator that the system was unable to extend a call
on a particular route list. This could be because all the
trunks are busy and there is no capacity, because there is
a failure to connect to the trunk destination, or because
the far end of the gateway or trunk is returning a failure
cause when the call is extended.
Configuring a route list involves two distinct

configuration pages. First is the route list configuration
page, where you specify the name and a handful of
parameters along with the list of route groups you want
to include in the route list. The second configuration
page is the route group details for each route group
configured in the route list. In other words, for each
route group you add to a route list, you can specify
transformations specific to that route group when used
as part of this particular route list.
Figure 4-4 shows the main route list configuration page

in Unified CM which can be accessed from Unified CM
Administration > Call Routing > Route/Hunt > Route
List.
Figure 4-4 Route List Configuration Page in the Unified

CM Administration User Interface
You can see that there are very few settings on this page.
However, there are some important concepts related to
how these parameters work that you need to understand
—especially the significance of the Cisco Unified
Communications Manager Group setting.
By default, a single route list process is created on one

node of a multi-node Unified CM cluster. That one node
is responsible for handling all calls destined to that route
list. The Cisco Unified Communications Manager Group
setting specifies the list of servers where the route list
process for this route list may run. It runs on the first
server in the group that is available. The Registration
field indicates which server in the cluster is currently
running the route list process for this route list. If you
see the route list showing up as Unregistered, click the
Reset button at the top of the page to restart the process.
The Run On All Active Unified CM Nodes checkbox
changes this behavior. Instead of running on a single
server, when this parameter is selected, each server in
the cluster runs a copy of the route list process for this
route list. There are several advantages to doing this,
mainly the ability to better balance load across the
cluster because each server can handle processing of
route list events instead of relying on a single server. This
improves troubleshooting because data related to a
single call is more likely to be all on the same server
instead of being spread out across many different servers
in the cluster. The recommendation is to always use the
Run On All Active Nodes parameter to achieve the best
load balancing and make troubleshooting easier.
Before we discuss the route list details for each route

group, you need to understand some additional
parameters that determine when Unified CM hunts to
the next route group and when it stops routing
altogether. If a call connects, a route list does not attempt
to reroute the call, even if there is some failure after the
call connection. Connecting a call stops the route list
hunting process. For call failures during the attempted
call establishment, Unified CM usually extends the call to
the next device within a route list’s route group; however,
there are four service parameters that control the routing
behavior for specific types of call failure scenarios. These
are found under Unified CM Administration > System >
Service Parameters > Server > Cisco CallManager, in the
section Clusterwide Parameters (Route Plan). You must
click the Advanced button at the top of the page to see
the fourth parameter, as it is hidden by default. These
four service parameters specify whether Unified CM
should stop routing or continue attempting additional
route groups and devices configured as part of those
route groups after receiving specific cause codes.
The first is the Stop Routing on Out of Bandwidth Flag

parameter. By default, this is set to False, which means if
a call is attempted and the reason the call was not
extended is a cause code indicating that there is not
sufficient bandwidth to complete the call, Unified CM
continues to route to the next route group member. The
naming of these parameters can be somewhat confusing.
When Stop Routing on Out of Bandwidth Flag is set to
False, it indicates that you do not want to stop. In other
words, it means you want continue in this scenario.
The next parameter is Stop Routing on Unallocated

Number Flag. This parameter is set to True by default,
which means if a call is attempted to a gateway or trunk
and the cause code returned when a call is extended
indicates the number is unallocated (for example, Q.850
cause code 1 or a SIP 404 response), the route list does
not continue hunting; the assumption is that if the
number does not exist on one trunk, it won’t exist on any
of the other trunks configured.
The third parameter is Stop Routing on User Busy Flag.

This parameter is also set to True by default, to stop
routing calls if the returned cause code indicates that the
user is busy (for example, Q.850 cause code 17 or a SIP
486 response). Again, the reasoning is that if a user is
busy when dialed on one trunk, sending the call via a
different trunk a few milliseconds later will likely not be
useful because the user is still probably busy.
The final parameter, which you can see only if you click
the Advanced button at the top of the page, is the Stop
Routing on Q.931 Disconnect Cause Code parameter,
which allows you to specify one or more cause codes,
separated by spaces. Remember that by default, Unified
CM continues routing on any cause code other than
unallocated number and user busy, based on the two
parameters mentioned previously. If you would like
Unified CM to stop routing on any other cause code, you
must specify it in this field.
You should be very careful about using these parameters.

They are global in nature and therefore apply to calls on
all route lists and route groups configured on the cluster.
You might, for example, try to use one of these
parameters to force a call to route or not route based on a
specific issue, but there can be unintended consequences
of doing so because the change affects other gateways or
trunks on the system.
Now that you understand the ordered list of route groups

in a route list and the logic used to determine whether to
continue hunting for another route group, you should
understand the route list details configuration that can
be applied to each route group in the route list. For each
route group that is added to a route list, there is an entry
in the Route List Details section at the bottom of the
route list configuration page, as you can see back in
Figure 4-4. If you click on any of the entries that appear
on that section, you see the route list member
configuration screen, as shown in Figure 4-5.
Figure 4-5 Route List Details Configuration Page in the

Unified CM Administration User Interface
This page should look familiar because the entries are a

subset of the Calling Party Transformations and Called
Party Transformations sections of the route pattern
configuration page. These transformations work
identically to those for route pattern configuration, so if
you have a question about how any of them work, refer to
Table 4-5. The only parameter that is different is the Use
Calling Party’s External Phone Number Mask setting,
which is a selection menu instead of a checkbox. On the
route list details configuration, there are three settings:
Default, On, or Off. As mentioned earlier, any
transformations applied on the route list details
completely replace any transformations done on the
route pattern. Selecting Default indicates to use the
setting configured on the route pattern, and selecting On
or Off replaces the setting with what has been
configured.
If Use Calling Party’s External Phone Number Mask is

changed from Default or if anything is configured in the
Calling Party Transform Mask or Prefix Digits (Outgoing
calls) fields, the original calling party number gets the
new transformations applied. Similarly, in the Called
Party Transformations section. Any configuration in this
section supersedes the settings that were applied on the
route pattern. One setting worth pointing out is the
difference between < None > and NoDigits for the
Discard Digits parameter. If set to < None >, the
configuration on the route pattern applies. If set to
NoDigits, no digits are discarded, and the settings on the
route list details override the called party number
transformations on the route pattern.
Also note that any transformations performed on the

called party number on a route list do not affect the
display of the dialed number on the IP phone placing the
call, whereas transformations on the route pattern do
affect the display. Later processing still has the potential
to update the called or connected party number, but the
route list transformations do not.
Route Groups
A route group is a collection of one or more gateways or
trunks that are used to route a call. Route groups are
configured in Unified CM Administration > Call Routing
> Route/Hunt > Route Group (see Figure 4-6).
Figure 4-6 Route Group Configuration Page in the
In the first section of the route group configuration page,

you can specify the name of the route group as well as the
distribution algorithm. There are only two choices: Top
Down and Circular. As the names imply, the Top Down
setting tries each gateway or trunk in the route group,
always starting with the first available entry on the list.
For gateway devices where Unified CM knows the active
call state for each port or channel, such as MGCP or
SCCP voice gateways, Unified CM starts hunting from
the first available or non-busy port when set for Top
Down. For gateway or trunks where Unified CM does not
know whether capacity is available—for example, for
H.323 or SIP gateways—Unified CM assumes that all
gateways are available and hunts through them as if they
all have available capacity. In the event of a call failure,
such as a SIP 500 Internal Server Error response, during
call setup, the route group continues to hunt through the
list of devices until the call is successful or until all
entries in the route group are exhausted.
Top Down behaves the same way a hunt list behaves. In

fact, you may have a hard time deciding whether to
create several route groups with one gateway each and
put those route groups into a route list in the desired
order or put all the gateways and trunks into a single
route group set for Top Down. These two options behave
identically. The main reason you might want to break
things up into more than one route group is if you need
to apply different transformations to different sets of
trunks because the route list details apply to all gateways
and trunks in a route group.
The Circular setting provides some level of round-robin

load balancing by starting the hunt sequence from a
different member each time the route group is used. For
example, if a route group is configured for circular
distribution, and it contains three trunks, named A, B,
and C, the first time the route group is used, Trunk A is
used first. The second call that uses the route group
starts on Trunk B. The next call is extended to Trunk C.
The next call again starts from Trunk A, and the process
repeats. If all ports are busy on a trunk or if a call fails
during setup, the next trunk is used. Let’s use the second
call on this trunk as an example: If the call establishment
fails across Trunk B, Trunk C is next up for the call, and
Trunk A is last if the call also fails across Trunk C. This
mechanism should provide for reasonably even
distribution between devices in the route list. As you will
see in Chapter 5, SIP trunks can also provide load
balancing and redundancy by allowing for multiple
destinations on a single trunk.
By combining route lists and route groups, you can load

balance calls among a set of trunks or gateways. Then,
only when all those routes are exhausted or fail, you can
move on to a second set of devices by having a second
route group in the route list. Note that the Stop Routing
On… service parameters described earlier apply to route
groups as well. Unified CM stops routing through a route
group if one of the Stop Routing On… cause codes
applies, and subsequently it does not move on to the next
entry in the route list. For example, if a call returns a 404
Not Found with the Q.850 Cause Code 1, indicating an
unallocated number, Unified CM checks the Stop
Routing on Unallocated Number service parameter to
determine what to do next. If this parameter is set to
True, Unified CM stops routing and fails the call; if it is
set to False, Unified CM continues to the next available
device in the route group.
Local Route Group

The combination of route pattern, route list, and route
group offers a flexible set of tools for an administrator to
route calls to external devices and achieve load balancing
and redundancy, but you may have noticed that the three
dial plan elements are strongly tied to each other. Say
that the administrator of a company with 4000 remote
branches wants to configure a pattern for users to dial a
PSTN number by dialing 9.1[2-9]XX[2-9]XXXXXXX and
then match a route list, which sends the call out through
a centralized SIP trunk, but if that call fails, try to send
the call out through a local gateway at the branch. With
the dial plan elements we have discussed so far, the
administrator would have to configure 4000 route
patterns, each of them pointing to 1 of 4000 route lists,
each of which contains the route group with the central
SIP trunk followed by the local gateway for that site. This
means configuring 4000 route patterns, where the only
difference is the route list, and configuring 4000 route
lists, where the only difference is the second route group
that appears in the list. Certainly, there must be a better
way! This type of deployment challenge is what led to the
development of the dial plan element called the local
route group. This feature, initially introduced in
Unified CM Version 7.0, was enhanced with the multiple
local route group feature in Version 10.5; it gives
administrators a way to address the situation where
route patterns, route lists, and route groups are identical
with the exception of the route groups being different,
depending on some criterion such as the location,
branch, or site.
The local route group allows an administrator the ability

to place a generic placeholder in a route list instead of in
a specific route group. The local route group then
abstracts a specific route group from the call routing
logic and allows an administrator to assign a location-
specific route group that will be used in its place. Because
the multiple local route group feature has been available
since Version 10.5, we discuss this more advanced
version. (Prior to Version 10.5, however, everything
works exactly the same way except that there is only a
single local route group available.)
When using a local route group, instead of specifying the

Branch 1234 Local Gateway route group, an
administrator can add a more generic Branch Local
Gateway route group to a route list. In this case, Branch
Local Gateway is not the name of a route group but
rather it is the name of a placeholder. The actual route
group used is determined by the configuration on the
device pool of the calling device. This means that you can
change what Branch Local Gateway means for a
particular device by changing the local route group
configured on the device pool for this device.
The original local route group feature had only one such
placeholder, named Standard Local Route Group. The
name was not configurable, and only one local route
group could be configured on the device pool. Thanks to
the introduction of the multiple local route group
feature, you now have additional flexibility. To see how
this is configured, start with the configuration for the
local route group names by navigating to Unified CM
Administration > Call Routing > Route/Hunt > Local
Route Group Names. Figure 4-7 shows an example of
this configuration page.
Figure 4-7 Local Route Group Names Configuration in

the Unified CM Administration User Interface
In the example shown in Figure 4-7, you can see that

there are three local route groups configured: Emergency
PSTN Route, Priority 1 PSTN Route, and Priority 2 PSTN
Route. These are just arbitrary names selected by an
administrator who wants to control how emergency calls
and other PSTN calls are routed. You can click the Add
Row button to add as many local route group names as
you would like. It is unlikely that you will ever need to
create more than a handful of them, however. By default,
Unified CM comes with a single local route group named
Standard Local Route Group, but you can rename it to be
anything you want; however, you must always have at
least one local route group configured.
Once a local route group name has been added to the

local route group names configuration page, these names
appear in the route list configuration page, alongside all
your other (real) route groups. You can use this route
group the way you would any other route group, with the
distinction being that the actual route group used will
depend in the calling device’s device pool. To configure
the actual route group, navigate to Unified CM
Administration > System > Device Pool. In the device
pool configuration page is a section labeled Local Route
Group Settings that shows a list of the local route groups
you added earlier. By default, all the local route groups
on a device pool are set to < None >. If a local route
group is set to < None > on the device pool of a calling
device and a call is placed through a route list containing
that local route group, it is as if the route group is not
configured on the route list at all. This by itself does not
cause an error and in some cases may be a desired
configuration if there are other route groups in the route
list available to handle the call.
Hunt Pilots, Hunt Lists, and Line Groups

Route patterns, route lists, and route groups are used to
distribute calls to other systems external to Unified CM.
Hunt pilots, hunt lists, and line groups are used to
distribute calls to groups of IP phones registered to a
Unified CM cluster. In some ways, they behave similarly:
Hunt pilots are similar to route patterns, hunt lists are
similar to route lists, and line groups are similar to route
groups. However, there are also several differences worth
discussing. As with route patterns, route lists, and route
groups, the configuration order is the reverse of the
order discussed here: You must configure hunt groups
first, then add them to hunt lists, and then use a hunt list
on a hunt pilot.
Line Groups
The first element you must configure is the line group. A
line group allows you to group a series of lines on
phones into a group for the purposes of distributing calls
in some fashion to those lines. Figure 4-8 shows the line
group configuration page, which can be found by
> Route/Hunt > Line Group.
Figure 4-8 Line Group Configuration in the Unified CM
Administration User Interface
There are a variety of parameters you can configure for a

line group. One of them is RNA Reversion Timeout
(where RNA stands for ring no answer). This determines
how long this line group will ring a line or group of lines
before attempting another group.
The Distribution Algorithm parameter determines how

calls are distributed between the members of the line
group. There are four options:
• Top Down: The devices in the list will always be

tried starting from the first and hunting
sequentially through the list.
• Circular: The devices on the list will be selected in

a round-robin fashion.
• Longest Idle: The device on the list that has been
idle for the longest period of time will be selected.
• Broadcast: The call will ring all the devices in the

line group simultaneously, and the first device to
answer will accept the call.
The Hunt Options settings determine how Unified CM

treats no answer, busy, or unregistered conditions of line
group members. For each of those three conditions, you
can select one of the following options:
• Try next member; then, try next group in

Hunt List: This is the default value. If a member
meets the condition (no answer, busy, or not
available/unregistered), it is just skipped.
• Try next member, but do not go to next

group: If a member meets this condition, other
members in the group are attempted, but the next
group in the hunt list (if there is another group
after this line group) will not be used.
• Skip remaining members, and go directly to

next group: If the selected condition is met, no
other members of this line group are used, and
Unified CM moves on to any subsequent line
groups that appear in the hunt list.
• Stop hunting: If the condition is met, no further

members are selected from the line group or hunt
list, and the call fails.
Unified CM allows for users to be either logged in or

logged out of a line group either through administrative
configuration or a softkey or button on the phone that
controls whether a user is logged in or out of configured
line groups. In the case of no answer, you can optionally
enable the checkbox Automatically Logout Hunt Member
on No Answer, which does exactly what the name
implies. This means you can avoid continuously ringing a
phone where someone has stepped away without logging
out manually. A user must then manually log back into
the hunt group to receive new calls by using the
configured hunt group login softkey, or an administrator
may log a phone back in to a hunt group by checking the
Logged Into Hunt Group value on a phone configuration
page in the Unified CM Administration user interface.
Once you have selected all the distribution and hunting

options, the only thing left to do is add the lines to the
line group. The list of lines shown in the Selected
DN/Route Partitions list is an ordered list, although the
order generally only applies to the Top Down
distribution algorithm.
Hunt Lists
After you have created a line group, you can add it to a
hunt list. A hunt list is very similar to a route list. To
configure a hunt list, navigate to Unified CM
Administration > Call Routing > Route/Hunt > Hunt
List. Figure 4-9 shows the hunt list configuration page.
Figure 4-9 Hunt List Configuration in the Unified CM

Administration User Interface
The configuration of the hunt list is relatively

straightforward. You just need to provide a name, select
an option for Cisco Unified Communications Manager
Group, and add groups. You should check the box to
enable the hunt list, and if the hunt list is being used to
extend calls to Unity Connection or another voicemail
system, you should select the For Voice Mail Usage
checkbox.
If you check the For Voicemail Usage check box, the

route list control process keeps a count of the setups that
are being served to the hunt list and does not allow more
setups than the number of available devices. This
prevents Unified CM from sending more calls than the
voicemail system can receive.
The list of line groups in the hunt list is ordered and is

always processed top-down, starting with the first line
group in the list and moving down the list based on the
hunt options that configured on the line group. Each line
group’s hunt options determine whether and when the
next entry in the hunt list is chosen. Unlike with route
lists, there is no special transformation or configuration
on a per-line-group basis on the hunt list configuration.
Hunt Pilots
The final step needed to get line groups to work is to
create the hunt pilot. A hunt pilot is similar to a route
pattern, but it contains additional configuration to deal
with forwarding and queueing of calls. Figure 4-10 shows
the pattern definition section of the hunt pilot
configuration, which can be found by navigating to
Unified CM Administration > Call Routing >
Route/Hunt > Hunt Pilot.
Figure 4-10 Hunt Pilot Configuration in the Unified
CM Administration User Interface
You can see that this part of the configuration is very

similar to the route pattern configuration. The biggest
difference is that you can specify a hunt list instead of a
route list. A hunt pilot also allows you to configure a call
pickup group. (This feature is discussed in Chapter 6.)
Finally, the configuration allows you to specify an
alerting name, which is what calling phones see on the
display when they call the hunt pilot before a line group
member answers the call.
The interesting part of the hunt pilot configuration is the

Hunt Call Treatment Settings section, shown in Figure 4-
11.
Figure 4-11 Hunt Pilot Hunt Call Treatment Settings in

the Unified CM Administration User Interface
You have two options, which are mutually exclusive: You

can choose to either use call forwarding on busy and/or
no answer on the hunt pilot, or you can enable queueing.
If you select the Queue Calls checkbox, the forwarding
settings are disabled.
By default, calls are not forwarded or queued, so if all
hunt list and line group members are exhausted, the call
fails. If you choose to invoke forwarding, you can do so
for calls that are unanswered or calls where all the
members are busy. If you select the option Use Forward
Settings of Device That Forwarded to Hunt Pilot, the Call
Forward No Coverage setting on the forwarding device is
used. Otherwise, the page allows you to specify a phone
number and a calling search space to use. (Calling search
spaces are covered in the next section.) You can also
specify the maximum hunt timer, which determines how
long a call to this hunt pilot will attempt to ring devices
before forwarding to the no answer destination.
If you want to be able to have callers put into a queue

instead of being forwarded when all members are busy or
not available, you can enable queuing with the Queue
Calls checkbox. When queuing is enabled, you have a
variety of options. First, you must select the music on
hold audio source as well as the maximum number of
calls to allow into the queue. If the queue reaches the
limit, you have the option to either disconnect the call or
have the call forwarded to another destination—perhaps
a voicemail box number or some other recording that
tells the users the system is busy. You can also specify a
maximum time to wait in queue, at which point the
When Maximum Wait Time Is Met parameter is invoked
to either disconnect the call or forward it to another
destination.
The last parameter in this section allows you to

determine what happens if none of the members answer
the call or if no members are registered.
The remainder of the hunt pilot configuration is identical

to the route pattern configuration page, allowing you to
add calling and called party number transformations.
These are generally not used often because the calls are
being extended to phones rather than being sent over a
trunk.
After having configured route patterns, route lists, route

groups, hunt pilots, hunt lists, and line groups, you
might be wondering if there is a way to get a visualization
of how these elements tie together. The Route Plan
Report page, available from Unified CM Administration
> Call Routing > Route Plan Report allows you to search
for numeric or alphanumeric patterns and view a quick
snapshot of the configuration. Figure 4-12 shows an
example of this page.
Figure 4-12 Route Plan Report
You can see in the figure that each route pattern shows
the route list, route groups, and trunks or gateways
associated with that pattern, and a hunt pilot shows the
hunt list and line group members. The Route Plan
Report pages provides a very convenient way of quickly
searching for configured dial plan elements.
The hunt pilot configuration pages have several areas

where you have to select a calling search space, and the
following section covers this topic.
PARTITIONS AND CALLING SEARCH
SPACES
Several of the configuration pages you have already seen
allow you to configure a route partition, but up until
now, we have glossed over what this is and how it works.
Partitions and calling search spaces work together to
provide some of the most flexibility in your dial plan
design. Administrators new to Unified CM sometimes
find understanding partitions and calling search spaces
confusing, but this is likely due to not having the concept
explained properly. In reality, partitions and calling
search spaces are simple, but you can use these simple
constructs to build complex dial plans.
At a high level, partitions and calling search spaces allow

an administrator to create groups of patterns, whether
they be route patterns, directory numbers, numbers
associated with features, alphanumeric URIs, or any
other dial plan element that can be called. These groups
of patterns are called partitions. A calling search
space is simply a list of partitions that a calling device or
feature can look at to find a match for a number. To be
more specific, a calling search space is actually an
ordered list of partitions, but you will soon realize that
the order of partitions in a calling search space is often
irrelevant. A partition is assigned to anything that can be
called, and a calling search space is assigned to anything
that needs to look for a number to call or invoke a
feature.
Any time a pattern is configured in Unified CM, it must

be placed into a partition. By default, a pattern is placed
into the < None > partition. This is a special default
partition that exists on a fresh installation and cannot be
removed. As a general best practice, you should never
use the < None > partition because patterns in the <
None > partition can be reached by any device or feature
on the system: Every calling search space, including the
< None > calling search space, has access to the < None
> partition.
To configure a partition, navigate to Unified CM

Administration > Call Routing > Class of Control >
Partition. A partition has only one required configuration
parameter: a name. You can also configure an optional
description when first creating a partition. After you add
a partition, you can modify it by adding a time schedule,
as discussed later in this chapter.
A partition should contain groups of patterns that are

equally reachable by a calling entity. For example, you
might want to have a partition for all the directory
numbers in your cluster. This assumes that all directory
numbers are equivalent from an authorization
perspective—in other words, a user or device authorized
to reach the directory numbers partition can place a call
to all directory numbers. If you have some specific
requirement to restrict calls to certain directory numbers
from certain phones, you might need to create a separate
partition to hold the restricted directory numbers.
The calling search space configuration is found under

Unified CM Administration > Call Routing > Class of
Control > Calling Search Space. To create a dial plan in
Unified CM, you have to leverage various partitions and
calling search spaces to break apart the pieces of your
dial plan to restrict access to certain patterns so that only
authorized users can reach them. You might also need to
rely on partitions and calling search spaces to handle
location-specific differences; for example, what it means
to dial a local number in one area could be very different
from what it means in another area, or national dialing
could be completely different in clusters handling calls
for phones in several different countries.
To begin, an administrator might want to add the ability
for phones to place calls to other phones or place
emergency calls but not have the ability to place any
outbound PSTN calls. Figure 4-13 shows a very basic dial
plan with two partitions: one with all directory numbers
and another with the route patterns for emergency calls.
Figure 4-13 Partition and Calling Search Space

Example for Internal and Emergency Dialing
All the directory numbers on phones are in the

Phone_Lines_PT partition. Route patterns used to reach
emergency numbers are in the US_Emergency_PT
partition. Why not put all of these patterns in the same
partition? The reason is simple. Perhaps you want to
later create a calling search space where a phone can
only dial other phones but cannot place emergency calls,
or vice versa—where a phone can only place an
emergency call but cannot call other phones in the
system. By breaking the patterns into separate partitions,
you have the flexibility to mix and match which
partitions are contained in a given calling search space.
To expand on this dial plan and add the ability for

certain phones to place local PSTN calls, you might add
another partition with additional route patterns and a
new calling search space, as shown in Figure 4-14.
Example for Local PSTN Dialing
The NC_919_984_Local_PT partition contains patterns

to dial local calls in the 919 and 984 area codes, which
correspond to central North Carolina in the United
States. This partition and the previously discussed
partitions are added to a new calling search space, the
NC_919_984_Local_Calling_CSS calling search space.
A device assigned to this calling search space will be
allowed to call other phones, make emergency calls, and
place local PSTN calls.
Next, you might want to permit certain phones to dial

long-distance calls in addition to local calls. In that case,
you need to add additional route patterns and place them
in yet another partition. Figure 4-15 shows the addition
of two new partitions and a new calling search space that
permits national calling.
Example for National Dialing
This figure shows the two new partitions that have been
added and added to the newly created
NC_919_984_National_Calling_CSS calling search
space. The US_National_PT partition contains patterns
allowing access to any PSTN number in North America
for calls that are considered long-distance calls. Because
of the way the North American Numbering Plan (NANP)
works, several countries all share the same country code,
so the patterns in the US_Block_CC1_Intl_PT partition
is used to add blocking patterns that block calls to area
codes that are considered to be international calls. These
are all route patterns configured with Block This Pattern
on the route flag. In a real deployment, there would be
many more of these patterns—one for each area code in
Canada and the Caribbean.
The NC_919_984_National_Calling_CSS calling search

space permits a calling device to place calls to on-cluster
directory numbers, emergency calls, PSTN calls to the
local area codes 919 and 984 by using 10-digit dialing,
and calls to national numbers in the United States with
the exception of those area codes considered to be
international calls. Figure 4-16 shows the configuration
page for the NC_919_984_National_Calling_CSS calling
search space.
Figure 4-16 Configuration of
NC_919_984_National_Calling_CSS Calling Search
Space
You might have noticed that the route pattern 9.1[2-

9]XX[2-9]XXXXXX overlaps with the pattern
9.1242XXXXXXX. If someone dials a number such as 9 1
242 555 1234, which of these route patterns is matched?
The 9.1242XXXXXXX pattern is matched because it is a
better or closer match, based on the closest-match
routing rules discussed earlier in this chapter. You may
be tempted to think that the order of the partitions in the
calling search space would factor into this equation, but
it does not. This is a key point to understand. The order
of partitions in a calling search space does not matter—
with one exception. The order matters only if there are
two equivalent matches found in different partitions. In
the case where there are two equivalent matches, the
pattern in the highest partition in the list is chosen. If the
call fails when routed to this pattern, it does not use any
other equivalent matches in another partition.
Finally, if you want to add a calling search space that

permits international calls, you can add one more
partition and create a new calling search space that
includes the new partition, along with the internal, local,
and national PSTN patterns mentioned before. Figure 4-
17 shows the partitions and calling search space needed
to enable international calling.
Example for International Dialing
The US_International_PT partition contains patterns

that allow for calling to international locations, and this
partition is included in the international calling search
space. Notice that the
NC_919_984_International_Calling_CSS calling search
space does not include the US_Block_CC1_Intl_PT
partition, which is used to block international calls that
look like U.S. national calls. A phone in this calling
search space would be allowed to call these numbers
because they are international numbers, so they do not
need to be blocked.
When you put everything together, you end up with the

relationships of partitions and calling search spaces
shown in Figure 4-18, which is a full example of the five
partitions and four calling search spaces described
previously to create a simple dial plan with class of
service restrictions.
Example
You can see how the relationships between partitions

and calling search spaces are a many-to-many
relationship. Calling search spaces can contain many
different partitions, and a partition may appear in more
than one calling search space. This allows you a great
deal of flexibility in designing your dial plan.
One last item to note regarding calling search spaces is

the interaction of calling search spaces configured on a
phone device and the lines associated with that phone.
You can configure a calling search space on a phone, and
you can configure calling search spaces on a line. If you
place a call from a line on a phone, which calling search
space gets used? The answer is both. Unified CM
concatenates the list of partitions in the line calling
search space with the list of partitions in the device
calling search space (in that order) and then searches for
a match in the full list. Remember that the order matters
only when there are equal matches, so if a partition that
is part of the device calling search space contains a the
best match for a dialed number, it is matched even if
there is a less-specific match on the line calling search
space.
Time of Day Routing

As mentioned earlier, partitions allow you to assign a
time schedule to a partition. A time schedule contains
a list of time periods. Figure 4-19 shows a
configuration example for a time period named Work
Day that includes the times from 9 a.m. to 6 p.m. on
Monday through Friday.
Figure 4-19 Work Day Time Period Configuration

Example
This time period can then be added to a time schedule, as

shown in Figure 4-20.
Figure 4-20 Work Hours Time Schedule Configuration

Example
The time schedule can include more than one time

period. For example, you might create a time period for
each holiday and then create a time schedule named
Holidays that includes all the holiday time periods.
Once you have created a time schedule, you can apply it

to a partition. For example, if you want to restrict
international calls to be allowed only during work hours
for the dial plan presented earlier, you can apply the
Work Hours time schedule to the US_International_PT
partition. When a time schedule is applied to a partition,
that partition exists only during the time periods added
to the time schedule. Outside those times, it is as if the
partition and all the patterns contained in that partition
do not exist. Figure 4-21 shows the configuration of a
time schedule on a partition.
Figure 4-21 Work Hours Time Schedule Added to a

Partition
Notice that the configuration for a time schedule also has

a selection for a time zone. This selection is important
because it determines the time zone that will be
considered when evaluating a time period. For example,
if a time period allows calls from 8 a.m. to 6 p.m., what
time zone are those times in? The selection on the
partition configuration page allows you to either select
the time zone of the originating device or select a specific
time zone. If you select a specific time zone, the partition
is active for the same periods of time, regardless of what
device is placing the call. If Originating Device is
selected, then the time zone will come from the
date/time group assigned to the device pool on the
originating device.
So far in this chapter you have learned the basics of
partitions and calling search spaces. It is important to
remember that partitions contain patterns or numbers
that can be dialed, and calling search spaces contain the
partitions to look through when a device or feature needs
to look up a number. The complexity in partitions and
calling search spaces mainly comes from the sheer
number of places in the Unified CM Administration user
interface where you can configure calling search spaces.
Understanding the purpose of each calling search space
configuration field can be difficult, but you can simply
remember that they all do the same thing: provide a list
of partitions to search through for a pattern. One area
where the intricacies of calling search spaces comes into
play is with translation patterns, discussed next.
TRANSLATION PATTERNS
Translation patterns are some of the most powerful
call routing tools at your disposal as an administrator.
Understanding all the various parameters available to
you in a translation pattern can help you build complex
dial plans. At first glance, the configuration for a
translation pattern looks almost identical to the
configuration for a route pattern—and for good reason:
Most of the configuration parameters for a translation
pattern are identical to and serve the same purpose as
those on the route pattern configuration page. Before we
discuss how you configure a translation pattern, you
need to understand the purpose of a translation pattern
and how it fits into a dial plan.
A translation pattern works very similarly to a route

pattern in that you configure a pattern to match, and that
pattern is placed in a partition, like any other callable
number in Unified CM. This means that a device with a
calling search space that contains the partition in which
the translation pattern is configured can dial a sequence
of digits to match the configured pattern on the
translation pattern. The difference is that instead of
routing the call to a route list or gateway/trunk, a
translation pattern reroutes the call back to the digit
analysis engine and performs a new digit analysis lookup
after applying whatever calling and called party
transformations were configured on the translation
pattern. In order to perform a new search through digit
analysis, the translation pattern has a calling search
space that is used to perform the new search after the
configured transformations. It is as if a new call were to
have been placed, but instead of using the calling search
space configured on the device or feature invoking the
call, the calling search space is replaced with the one
configured on the translation pattern.
Figure 4-22 shows the translation pattern configuration

page, which can be found by navigating to Unified CM
Administration > Call Routing > Translation Pattern.
Figure 4-22 Translation Pattern Configuration in the

Recall that Table 4-5 describes all the parameters on the
route pattern configuration page. Most of the parameters
on the translation pattern configuration page are
identical to those described in Table 4-5, so they are not
repeated here. Instead, we focus on the parameters that
differ from those for the route pattern configuration.
The biggest difference that you will notice is that a

translation pattern does not have a Gateway/Route List
parameter but instead has a Calling Search Space
parameter to specify the calling search space to be used
to route the call after the transformations have been
applied by the translation pattern.
Figure 4-23 shows an example of how a translation

pattern can be used to covert a phone number dialed by a
user as a 7-digit local phone number into +E.164 format
before routing the call to the PSTN.
Figure 4-23 Example Translation Pattern Call Routing

Flow
Notice that the user dials 9 followed by a 7-digit number:

9 555 1234. The calling search space on the user’s phone
or line contains the Local_AC_919 partition, which
contains the translation pattern 9.[2-9]XXXXXX. If this
translation pattern is the best match in all the partitions
that appear in the phone’s calling search space, it
attempts to translate the number and search for another
match. In this case, the translation pattern first applies a
calling party number transformation which indicates
that the external phone number mask configured on the
line should be used. This means the mask
+1984555XXXX is applied to line 1000 to convert the
calling party number to +19845551000. Second, a called
party transformation pattern is applied to the number:
+1919XXXXXXX. This means that, for this example, the
called party number is transformed to +19195551234.
This new calling and called party number is then passed
back to the digit analysis engine, using the calling search
space configured on the translation pattern—
Full_PSTN_Access—and a new route lookup is
performed.
The Full_PSTN_Access calling search space contains a

partition named PSTN_Routes, which contains the route
pattern +!. The new called party number that was created
by the translation pattern matches this route pattern,
and the call routes through the appropriate route list.
Notice that the IP phone does not have direct access the
\+! pattern because the phone does not have the
PSTN_Routes partition in its calling search space.
However, the call eventually does use this route pattern
to route the call. Translation patterns allow you to access
other partitions in a restricted fashion, as highlighted in
this example.
There are several other configuration parameters on the

translation pattern configuration page that differ from
the parameters for a route pattern. For example, if the
Use Originator's Calling Search Space checkbox is
selected, the Calling Search Space field is disabled. By
checking this box, you tell the translation pattern to use
the calling search space of the device/feature that
originated the call. If the originating device is an IP
phone, the combined list of partitions from the line and
device calling search spaces that were used to originate
the call is used. This capability gives you additional
flexibility by allowing you to create a translation pattern
that strictly transforms the calling/called party number
but does not affect which calling search space the user
has access to. This means you can use this checkbox to
create a translation pattern that is broadly used across a
variety of devices; where the call gets routed after the
transformations depends on the calling device.
The next parameter that appears on the translation

pattern configuration page that is not found on the route
pattern configuration page is the checkbox Do Not Wait
for Interdigit Timeout on Subsequent Hops. This
checkbox can be useful as you can prevent a user from
having to wait for interdigit timeout after dialing a
number if you know there should be no further digits
provided. In the example shown in Figure 4-23, when the
dialed number was translated to +19195551234, it
subsequently matched the route pattern \+!. This route
pattern is a variable-length route pattern, so even though
the full number has already been provided by the
translation pattern and no further digits are expected,
Unified CM still waits for the interdigit timeout because
the \+! pattern can accept additional digits. To avoid
having to wait for the interdigit timeout, the translation
pattern shown in Figure 4-23 should also have the Do
Not Wait for Interdigit Timeout on Subsequent Hops
checkbox selected so that the call routes immediately.
This is also typically used on any translation pattern with
the Trailing-# digit discard instruction configured. The
pound sign is commonly used to indicate that no further
digits are coming, and translation patterns are often used
to remove this pound sign before routing a call to its
ultimate destination, but this setting can ensure that
after matching the pound sign, the system does not wait
for further digits.
The final checkbox that is new on the translation pattern

page is the Route Next Hop By Calling Party Number
checkbox. This is an unusual selection that temporarily
changes the way pattern matching works in Unified CM.
If this box is selected, after the calling and called party
numbers have been transformed, Unified CM searches
for a match by using the calling party number, not the
called party number. Note one very unusual behavior
when using this feature: If the next hop that is matched
is a route pattern, the called party number remains as the
calling party number that was used to match the route
pattern, and therefore, the outbound call setup contains
what was originally the calling party number as the
called party number. This behavior is rarely desirable.
Typically, when this feature is used, the subsequent hop
is another translation pattern that does not have Route
Next Hop By Calling Party Number selected, in which
case the proper called party number once again becomes
the called party number to extend the call. This checkbox
is typically used to block calls from specific phones and
other PSTN sources based on the calling party number.
Besides the parameters mentioned in this section, all the

other parameters on the translation pattern
configuration page are identical to those configured for a
route pattern. One behavior difference worth
mentioning, however, is that changes made on a
translation pattern become the “original called party
number” and “original calling party number” for the
purposes of any modification done on a route list. Recall
that modifications done on the route list details for a
specific route group override any changes made on the
route pattern configuration. This is not the case for
changes made on a translation pattern. If a call passes
through a translation pattern before reaching a route
pattern, any changes done on a route list apply to the
numbers after translation pattern transformations are
applied.
As if all this talk of transformations on translation

patterns and transformations on route patterns and
route list details for route groups weren’t confusing
enough, there is yet one more dial plan element
remaining to cover: the transformation pattern.
TRANSFORMATION PATTERNS
One of the possible challenges that the local route group
feature introduces is the inability to perform calling or
called number transformations on a per-route-group
basis. With a normal route group, you can manipulate
calling and called party numbers by using the route list
details configuration to modify numbers on a per-route-
group basis, but with a local route group, these
transformations apply to all the route groups configured
as a local route group. For example, if you have route
groups named Branch 0001 PSTN through Branch 2000
PSTN assigned as the local route group named Branch
PSTN on 2000 different device pools and you have a
single route list that contains the Branch PSTN local
route group, any transformations you perform on the
route list details for the Branch PSTN local route group
will be applied to all 2000 route groups when they are
used as part of this route list. If you want to be able to
manipulate digits differently, depending on which of the
branch PSTN routes you take, you must resort to
transformation patterns.
There are two types of transformation patterns: calling

party transformation patterns and called party
transformation patterns. As you might imagine, calling
party transformation patterns allow you to manipulate
the calling party number, and called party
transformation patterns allow you to manipulate the
called party number. Other than this distinction, they
operate in nearly the same way. The key to
understanding transformation patterns is understanding
how they are configured and how they get used.
Up until now, patterns have been configured on dial plan

elements that can be called—such as on a directory
number, a route pattern, or a translation pattern—and
these patterns are all placed into a partition that is
reachable through one or more calling search spaces.
Transformation patterns follow a similar paradigm, but
they are not something you can call, although they can be
“looked up” by Unified CM as part of the call routing
process. How that lookup occurs is controlled by a calling
search space that works similarly to when a call is placed,
as you will see.
Transformation patterns should look very familiar to you

because the parameters configurable on transformation
patterns are a subset of the parameters available on a
translation pattern. For example, Figure 4-24 shows the
configuration page for a calling party transformation
pattern. You reach this page by navigating to Unified CM
Administration > Call Routing > Transformation >
Transformation Patterns > Calling Party Transformation
Pattern.
Figure 4-24 Calling Party Transformation Pattern
Configuration in the Unified CM Administration User
Interface
As you can see, you can configure a transformation

pattern just the way you configure a route pattern or
translation pattern, and you can place the pattern into a
partition. All transformation patterns are considered to
be urgent priority because they are not matched digit-
by-digit the way that other patterns are matched, so
although the Urgent Priority checkbox appears on the
screen, it cannot be deselected. Other than that, the other
parameters behave the same as the ones you already
know about. When you configure the calling party
transformation patterns, you must place them into a
partition. It is recommended that you create separate
partitions and calling search spaces for your calling and
called party transformation patterns, although
technically they could live alongside other patterns, such
as route patterns and directory numbers. However, when
configuring a calling search space that looks for calling
party transformation patterns, none of the other pattern
types are considered.
Figure 4-25 shows the configuration for a called party

transformation pattern, which can be found by
> Transformation > Transformation Patterns > Called
Party Transformation Pattern.
Figure 4-25 Called Party Transformation Pattern

Configuration in the Unified CM Administration User
Interface
In the same way that calling party transformation

patterns are placed into a partition, called party
transformation patterns are also placed into a partition.
Again, it is suggested that you keep each transformation
type in its own partition, which in this case means having
a partition that contains only called party transformation
patterns (or multiple partitions that contain only called
party transformation patterns if you need to perform
different types of transformations based on the outbound
trunk or device).
Transformation patterns get applied after a pattern has

been matched (either directory number or route pattern,
after possibly going through one or more translation
patterns) and the call has been extended to either a
phone, gateway, trunk, or remote destination profile.
Each of these device types offers various parameters that
allow you to apply transformation patterns. This is all
done by using special calling search spaces that are
configured on the device. Each calling search space looks
for either calling or called party number transformation
patterns and looks for a match to transform a number
based on that calling search space. The sheer number of
places where these calling search spaces are available is
what causes the most confusion, especially for calling
search spaces with names that do not make it clear what
kind of transformation patterns apply. Figure 4-26
shows a portion of the SIP trunk configuration page in
the Unified CM Administration user interface.
Figure 4-26 Transformation CSS Configuration on a

SIP Trunk in the Unified CM Administration User
Interface
In this figure, you can see eight transformation pattern–

related parameters. There are four calling search spaces
you can configure:
• Connected Party Transformation CSS
• Called Party Transformation CSS
• Calling Party Transformation CSS
• Redirecting Party Transformation CSS
For each of these calling search space selections, you

have the checkbox Use Device Pool <x> Transformation
CSS, were <x> matches the name of the calling search
space from the previous list. (For example, you can
enable or disable the Use Device Pool Called Party
Transformation CSS checkbox.) Each of the checkboxes
determines whether the calling search space configured
on the device should be used or whether the applicable
calling search space configured on the device pool in
which this device has been configured should be used.
Note
You may already be confused upon seeing this list because we have only
discussed calling party and called party transformation patterns but not
connected party or redirecting party transformation patterns. This is because
there is no such thing as a connected party or redirecting party transformation
pattern. Both of these parameters also look for calling party transformation
patterns. The only one that looks for called party transformation patterns is the
Called Party Transformation CSS parameter.
It is important to understand what each of these calling

search spaces does and which numbers they apply to.
The first is the Called Party Transformation CSS. The
calling search space configured here should contain a
partition that contains called party transformation
patterns. The called party number that gets sent to the
gateway will be used to search for transformation
patterns. One very important point to note is that
transformation patterns search for the original called
party number, not the number after any
transformations are performed on a route pattern or
route list details. This point cannot be stressed enough.
The route pattern transformations and route list details
are completely overwritten if a transformation pattern
matches and the number that is used to look for a match
is the original called party number, not the transformed
number. You need to couple this with the fact that
transformations performed on a translation pattern
create a new “original” calling and called party number,
so if a call passes through one or more translation
patterns before matching a route pattern, the output of
the last translation pattern matched is what is used as
the input to any transformation patterns.
The best way to drive this point home is through an
example. Imagine that a user dials 1000, which matches
the translation pattern 1XXX. This translation pattern is
configured to transform the called party number with the
mask 2XXX, and the resulting called party number is
2000. Using the calling search space on the translation
pattern, a match is found for a route pattern 2XXX,
which is configured to route the call to a route list. On
the route pattern, you configure the called party
transformation mask 3XXX. On the route list that
matches, in the route list details for a route group, you
configure the called party transformation mask X5XX.
This route group matches a SIP trunk with a called party
transformation calling search space configured. In that
calling search space, you have the following called party
transformation patterns configured:
• 1XXX transforms the called party to 1111.
• 15XX transforms the called party to 1555.
• 2XXX transforms the called party to 2222.
What will be the called party number when the call is

presented to the destination of the SIP trunk? What if
there is no called party transformation calling search
space configured on the trunk?
Let’s walk through the process. When the user dials 1000
and the first translation pattern, 1XXX, is matched, it
transforms the called party number to 2000. This now
becomes the new original called party number and is
used for the next digit analysis lookup. The new called
number, 2000, now matches the 2XXX route pattern,
which transforms the called party number to 3000. The
route pattern points to a route list, and the route list
details say to apply the called party transformation
X5XX. Does this become 3500? No, it does not.
Remember that the route list details override any
transformations performed on the route pattern and
transform based on the original called party number.
Since the user dialed 1000, would this transformation
become 1500? Again, no, it will not because the
translation pattern creates a new original called party
number, so at this point, the called party number
becomes 2500. Now the call is routed to the trunk for
routing. There is a called party transformation calling
search space configured on the trunk with the patterns
listed. Which (if any) pattern is matched, and what
would the transformed number be? You might be
tempted to think it would match 25XX, which would
output 2555 as the called party number, but that is
incorrect. Transformation patterns only look at the
original called party number, but the original called party
number was changed by the translation pattern, so the
number that is searched for a match is 2000 (the called
party number that matched the route pattern).
Therefore, the final called party number sent out in the
SIP INVITE is 2222, after matching the 2XXX
transformation pattern.
Figure 4-27 should help you visualize the called party

number at various stages and which numbers are used in
the transformations at each stage.
Figure 4-27 Called Party Transformation Logic
What if there is no called party transformation calling

search space configured on the trunk? In this case, the
called party number would be 2500 because it would use
the transformation that was applied by the route list
details configuration. Figure 4-28 provides a visual
example of how this works.
Figure 4-28 Called Party Transformation Logic

Without Transformation Patterns
Note
If you are not 100% confident in the explanation for this example, please
reread it as many times as necessary to make sure you understand it fully. If
you understand this, you will have a good grasp of how transformation patterns
work and the order of operations and precedence with transformations in
various call routing elements. In fact, if you have a Unified CM cluster at your
disposal, configure the example in some test partitions and calling search
spaces and observe what happens. Also remember that although these
patterns do not affect the routing of the call through Unified CM because they
get applied after the destination device has been selected, they can affect the
eventual routing of the call because the transformation modifies the number
sent to the far-end system on the SIP trunk.
Although this example has examined called party

number transformation patterns, the same process
applies to calling party transformation patterns. Calling
Party Transformation CSS allows you to select which
calling party transformation patterns are searched by a
match on the original calling party number. If there is a
match, the calling party number is changed as the call is
routed out through the trunk. This does not affect call
routing but does affect number presentation of the
calling party number.
The other two transformation calling search spaces,

connected and redirecting, do not apply to the calling or
called party number, but they still both leverage the
calling party transformation to find potential matches
and apply transformations to the connected number and
redirecting number.
The third transformation calling search space is the

Connected Party Transformation CSS. Although not
visible in Figure 4-26, the Connected Party Settings
section of the configuration is found under the Inbound
Calls section of the configuration. This indicates that this
calling search space only applies to calls arriving from an
external device. This calling search space allows you to
manipulate the connected number. By default, without
any kind of transformation, Unified CM transmits the
directory number of the device that was called as the
connected party number so that the caller sees the
number of the device that answered the call. This is not
always the same as the number dialed to reach that
device. Connected Party Transformation CSS allows you
to transform that connected number (the number of the
device that answered the call) as the connected number
is being transmitted back to the originator of the call.
The final transformation calling search space is the
Redirecting Party Transformation CSS. This calling
search space is also in the Outbound Calls section of the
configuration and applies to calls that are being sent out
through the trunk and contain a redirecting party
number (for example, if the call has been forwarded prior
to being directed to the trunk). By default, the redirecting
party number is the directory number of the line that
redirected the call. This calling search space can look
through calling party transformation patterns for a
match and transform the redirecting number before
sending the call out through the trunk.
Trunks are not the only location where you can configure
transformation calling search spaces. The phone
configuration page contains two calling search spaces
that can be used to match calling party transformation
patterns. They affect the way the calling party number is
presented on a phone as well as manipulate the calling
party number for calls placed from the phone. Figure 4-
29 shows the configuration options on the phone
configuration page, which you reach by navigating to
Unified CM Administration > Device > Phone.
Figure 4-29 Transformation Calling Search Spaces on a

Phone Configuration
The first transformation calling search space shown in

this figure is in a section labelled Caller ID for Calls from
This Phone. The directory number configured on the
phone is used to search for a match for a calling party
transformation pattern for all calls originating from this
phone. You might wonder why this parameter exists if
there are already options to provide an external phone
number mask on a line and use that when routing a call
through a route pattern or translation pattern. The
reason is that there are situations with alphanumeric
URI-based dialing in which a call is routed without ever
touching a translation pattern or route pattern that
would normally apply the external phone number mask
to globalize the calling party number. (This is discussed
later in the chapter, when we go into more detail on
intercluster alphanumeric dialing.) This calling search
space allows the administrator to configure
transformation patterns that manipulate the calling
party number for all outbound calls, even if they do not
go through some other dial plan element that allows for
the modification of the calling party number.
The second parameter on this page is in a section titled

Remote Number. This calling party transformation
calling search space affects how the remote calling party
number is displayed on the phone’s display to the user
receiving an inbound call. The transformation performed
by the remote number, however, does not affect the
number stored in the phone’s call history. Because this
does not modify the call history, an administrator has the
flexibility to provide a calling party number to a phone’s
display in a globalized format that is familiar to the user
while still retaining other modifications to the calling
number that show up in the call history on the IP phone.
One example of modifying the calling number for the call
history is to append a 9, 91, or + to ensure that the call
history on the phone matches the dial plan for outbound
calls. With this in place, an end user can simply select a
number from the call history without needing to perform
extra modifications, such as adding a 9, 91, or +.
Note
The 9, 91, or + prefix applied to the calling party number is usually achieved by
performing a calling party modification on the inbound gateway or trunk, which
in turn affects how the number is displayed in the call history on the endpoint
that ends up receiving the call. General design best practice is to globalize the
number into +E.164 format instead of prefixing a steering digit such as a 9.
Another type of device that allows an administrator to
configure a transformation calling search space is the
remote destination profile configuration page, found in
Unified CM Administration > Device > Device Settings >
Remote Destination Profile. Remote destination profiles
are discussed in Chapter 7, “Unified CM Mobility.” As
you will learn in that chapter, this feature allows calls to
an IP phone to simultaneously ring a mobile device. The
calling party transformation calling search space
configured on a remote destination profile allows you to
manipulate the calling party number for calls destined to
a remote destination. Again, these transformation
patterns are needed because a call from a phone calling
another phone on the cluster does not pass through a
route pattern or translation pattern, so this is an
opportunity for an administrator to manipulate the
calling party number to ensure that it is properly
presented to the PSTN. These transformations can be
used to globalize the calling party number, and when the
call is routed out to the PSTN to reach the mobile device,
it can be localized by the transformation patterns
configured on the trunk or gateway.
Transformation patterns are the final piece of the puzzle

you can use to create complex dial plans in Unified CM.
To put all the parts together, a real-world example is
provided in the next section.
PUTTING IT ALL TOGETHER: TAIL-

END HOP OFF (TEHO)
Tail-end hop off (TEHO) is often configured in large,
multinational companies as a way of leveraging
corporate WAN links to save on international (or
sometimes national) toll costs. The concept of TEHO is
straightforward: Route a call out through the gateway or
trunk where the PSTN costs for that call are the lowest.
This typically means sending a call originating in one
country through a gateway sitting in a different country—
usually the one where the called party resides. For
example, if a user in the United States places an
international call to a user in the United Kingdom,
instead of sending the call out through a local trunk in
the United States as an international call, the system
sends the call sent over the corporate WAN to a gateway
or trunk in the United Kingdom, where it is sent as a
local call. This, of course, assumes that the company has
trunks or gateways in the United Kingdom. The opposite
can also be configured, so that a user in the United
Kingdom placing a call to the United States egresses
through a U.S.-based gateway or trunk, thus avoiding
any international toll call fees.
The TEHO process requires careful manipulation of

calling and called party numbers to ensure that calls can
be routed and formatted correctly for the PSTN provider
receiving the calls. Also, in such a situation it is desirable
to be able to attempt the call through alternate routes if
the TEHO call fails without the user having to do
anything special. The user should just be able to dial the
number as if she were dialing an international call, and
the system should handle any and all transformations
necessary to route the call correctly.
In this section we go through a small subset of a much

larger dial plan that shows how to configure TEHO for
calls from the United States to the United Kingdom.
These same concepts can then be applied to add other
destinations or countries.
For this example, we assume that a user in the United

States is required to dial a 9 to place a call to the PSTN
and is using the standard North America dialing habit
requiring the digits 011 to indicate an international call,
followed by the country code and national number. For
completeness, we also want the user to be able to
optionally dial a pound sign (#) at the end of the digit
sequence to route the call immediately instead of waiting
for interdigit timeout.
Assume this customer has a SIP trunk to a PSTN

provider in the United Kingdom, two SIP trunks in U.S.
data centers, and a SIP trunk to a local PSTN gateway at
each of 100 branch offices. For calls to the United
Kingdom, the customer would like calls to first route
over the WAN to the SIP trunk in the United Kingdom. If
that fails, the call should attempt to use the SIP trunks in
both data centers. If these three options are exhausted,
the call should egress through the local gateway in the
branch where the originating phone is registered.
The called party and calling party numbers must be

formatted differently, depending on which outbound
trunk is used, because the different PSTN providers are
expecting the numbers in different forms. Figure 4-30
shows how the calling party number needs to be
modified depending on the trunk or gateway used for the
call.
Figure 4-30 TEHO Call Routing
As you can see in the figure, the user dials

9011441632960286# to reach the mobile number
01632960286 in the United Kingdom. If the call egresses
through the PSTN in the United Kingdom, the called
party number must be 01632960286 because the PSTN
provider is seeing this as a local call and requires a
leading zero. The two SIP trunk providers in the
centralized data centers in the United States will accept
the international call in +E.164 format
(+441632960286), and the local PSTN gateways at the
branches might have different requirements, based on
the PSTN provider at that branch, so you should provide
some level of flexibility to manipulate the called number
differently, depending on the branch, but for the one
branch you care about here, the number must be sent as
011441632960286.
Where do you start in building the dial plan to meet

these requirements? First, the general best practice is to
take the approach where any number dialed by the user
is converted to a globally unique format that is
independent of local dialing habits. In other words,
regardless of whether a number is dialed in the United
States, the United Kingdom, or China, the numbers
dialed by the user should be converted to a common
format. The well-established format for globalized phone
numbers is the +E.164 format discussed in Chapter 1,
“Introduction to Unified Collaboration and Dial Plans,”
which consists of the plus (+) symbol followed by the
country code and national phone number. Once the
number has been globalized into +E.164 format, the call
should be routed to the appropriate destinations by
matching globalized patterns. Only when the call reaches
the end device should the number be localized to meet
the requirements of the system receiving the call. This
globalization and localization should apply to both the
calling and the called party numbers.
Figure 4-31 provides a high-level overview of the calling

search spaces, partitions, route patterns, translation
patterns, transformation patterns, route lists, and route
groups needed to create the TEHO routing for calls from
the United States to the United Kingdom. The details of
the configuration of each item are discussed shortly.
Figure 4-31 TEHO Dial Plan Elements Overview
You can see six calling search spaces and six partitions
for this example. The first two are for the translation and
routing of the call, and the next four are for calling and
called party transformations. You need to create the six
partitions and then create the six calling search spaces
that include those partitions. The first calling search
space, International_With_TEHO_CSS, is the calling
search space assigned to the phone placing the call. This
calling search space allows access to the
NANP_International_PSTN partition. In a real-world
scenario, there would be other partitions that allow
access to other patterns in addition to these international
dialing patterns, but this section focuses specifically on
the components needed to make this TEHO call work.
This partition contains only translation patterns.
In order to globalize the calling and called party

numbers, you should use translation patterns. The
translation patterns will match the digits the user dials
and then apply transformations to convert the localized
numbers to +E.164 format. The first translation pattern
shown in Figure 4-31 should be configured with the
following parameters:
• Pattern: 9011.!
• Partition: NANP_International_PSTN
• Calling Search Space:

Global_PSTN_Patterns_CSS
• Provide Outside Dial Tone: selected
• Calling Party Transformations:
• Use Calling Party’s External Phone

Number Mask: selected
• Called Party Transformations:
• Discard Digits: PreDot

• Prefix Digits (Outgoing Calls): +
This translation pattern accepts calls dialed as 9 followed

by 011 followed by the country code and number, strips
off the 9011, and prefixes a + to convert the called
number to +E.164 format. It also applies the calling
party’s external phone number mask, which has been
defined on the phone in +E.164 format already. In effect,
this translation pattern converts both the calling and
called party numbers into +E.164 format.
The second translation pattern is similar except it has the

trailing pound sign, allowing a user to force the system to
not wait for interdigit timeout. This translation pattern is
configured as follows:
• Pattern: 9011.!#

• Provide Outside Dial Tone: selected

• Do Not Wait for Interdigit Timeout on
Subsequent Hops: selected

• Discard Digits: PreDot Trailing-#

• Prefix Digits (Outgoing Calls): +
One difference between this translation pattern and the

previous one is that Do Not Wait for Interdigit Timeout
on Subsequent Hops is selected so that the subsequent
match (which is the +! route pattern) does not have to
wait for interdigit timeout. The other difference is that
the digit discard instructions remove the trailing pound
sign.
You might be wondering why the third and fourth

translation patterns are needed since the patterns
created so far already match the number in +E.164
format. These patterns are needed to ensure that the
calling party number gets globalized. These patterns are
configured as follows:
• Pattern: \+!


Finally, the last translation profile needs to be configured

as follows:
• Pattern: \+!#

• Do Not Wait for Interdigit Timeout on

Subsequent Hops: selected

• Discard Digits: PreDot Trailing-#
Each of these translation patterns has the calling search

space Global_PSTN_Patterns_CSS configured. This
calling search space includes only the
Global_TEHO_Patterns partition. In a real deployment,
this calling search space would also include other
globalized route patterns to reach other destinations,
even if they are not TEHO sites. For the sake of this
example, the partition includes only a single route
pattern that matches calls to the United Kingdom
(country code 44) and routes them to a route list. The
route pattern is configured as follows:
• Pattern: \+44.!
• Partition: Global_TEHO_Patterns
• Gateway/Route List: UK_DC1_DC2_LRG
Most of the parameters on the route pattern are left

blank because there are no transformations being
performed on the route pattern. Transformations to
localize the number will be done either on the route list
details for each route group or by using transformation
patterns.
The route list contains three route groups, which will
route the call to the U.K. PSTN trunk, the two centralized
SIP trunks, and the local gateway, based on the local
route group. From the point onward, you have several
options for how to localize the number back to a form
that the PSTN providers are expecting. You could use
transformations on the route list details to perform the
transformations, but this would cause problems for the
local route group if you needed to apply different
transformations at different branches that are using the
local route group since the route list details configuration
applies to the whole local route group.
Instead, you can use calling and called transformation

patterns applied on the trunks or gateways. You need two
sets of transformation: one to handle the calling and
called party transformations for calls the egress through
the U.K. PSTN and another set to localize the calling and
called party numbers for egress through the U.S. PSTN.
The first called party transformation pattern handles
localization of the called party number for the United
Kingdom:
• Pattern: \+44.!
• Partition: UK_Called_Xform_CSS
• Prefix Digits: 0
As you can see, this transformation pattern would

remove the +44 and prefix a 0 to make the called
number compatible with the U.K. PSTN. This converts
the number +441632960286 to 01632960286. This
transformation pattern would then be applied to the U.K.
SIP trunk because the called party transformation calling
search space is set to UK_Called_Xform_CSS.
Next, configure the following calling party
transformation pattern to transform the calling party
number:
• Pattern: \+.1!
• Partition: UK_Calling_Xform
This transformation pattern may or may not work,

depending on how the PSTN carrier in the United
Kingdom handles calling number information. It is
possible that the carrier will accept the calling party
number in +E.164 format, in which case this
transformation is not needed. It is also possible that the
carrier will not accept an international number for the
calling party number, in which case you may have to
resort to masking the number with a phone number
owned by your company in the United Kingdom so that
the called party will at least receive a phone number
indicating that the call is originating from your company.
If you need to do this, you can add a calling party
transformation mask on the calling party transformation
pattern with the number you want to send any time a
TEHO call originates from the United States. To apply
these transformations to the calling party number, you
set the calling party transformation calling search space
on the U.K. SIP trunk to UK_Calling_Xform_CSS. Now
calls dialed from the United States as international U.K.
numbers will be routed via TEHO through the U.K. SIP
trunk.
In case the call through the U.K. SIP trunk fails for some
reason, the route list includes a second route group.
Although not shown in Figure 4-31, this route group
contains two SIP trunks: one in each data center. The
provider for these two SIP trunks accepts the calling and
called party numbers in +E.164 format, as shown in
Figure 4-30, so for these two SIP trunks, no calling or
called party transformation calling search space
configuration is necessary.
If U.K. SIP trunk and both data center SIP trunks fail to
route the call, the call is sent to the local gateway at the
branch. This gateway is selected via the Local Route
Group feature. Based on the device pool of the device, the
route group that contains the gateway for that branch is
selected. There are two more transformation patterns
needed to convert the +E.164 format to a format
expected by the local PSTN. Start with the called party
number. The PSTN provider providing service to the
local gateway you are interested in expects the calling
and called party numbers to be in NANP format, which
means the calling party number should be a 10-digit
number, and the called party number should adhere to
the standard NANP dialing habit. This means that for
international calls, the number should be 011 + country
code + national number. To transform the number,
configure the following transformation pattern:
• Pattern: \+.[2-9]!
• Partition: US_Called_Xform_CSS
• Prefix Digits: 011
Notice that this pattern matches anything that starts

with a + followed by 2 through 9. This represents any call
to an international destination from the perspective of a
U.S.-based caller. The pattern strips the + and prefixes
the 011. This means that the number +441632960286
becomes 011441632960286, which is what the local
provider is expecting.
Finally, configure the following transformation pattern

to deal with the calling party number:
• Pattern: \+1.!
• Partition: US_Calling_Xform
Notice the position of the dot (.) in this case. The PreDot
instruction discards the +1, leaving the 10-digit national
number as the calling party number. Once you have put
all this together, you will have a flexible TEHO design for
calls to the United Kingdom.
Hopefully you can see how this process can be easily

extended to other countries as well. If you want to add
another TEHO destination, you just need to add a few
more patterns to deal with calls to that country; users
across your enterprise can then make use of it.
Now that we have covered numeric dialing in depth, it is

time to return to the topic of placing calls using
alphanumeric URIs.
ALPHANUMERIC URI ROUTING

Alphanumeric URI dialing is becoming increasingly
common, thanks to the adoption of video endpoints and
video-capable soft clients, especially in environments
where business-to-business (B2B) calling is enabled
through Cisco Expressway. Alphanumeric dialing allows
for calling between endpoints using a URI that resembles
an email address, such as kydavis@cisco.com.
We briefly discussed alphanumeric URIs at the

beginning of this chapter. As a reminder, a URI has two
distinct components that are separated by the @ sign.
The component to the left of the @ is sometimes referred
to as the left-hand side (LHS), or the user portion, and
the component to the right is referred to as the right-
hand side (RHS), or the host portion. Unified CM
generally matches URIs based only on an exact match. If
there is no exact match for a full URI, Unified CM tries to
route the call based on the host/RHS portion of the URI
only.
Figure 4-32 provides a flowchart that outlines the

process by which Unified CM determines how to route a
URI-based call.
Figure 4-32 URI Routing in Unified CM
Let’s walk through the flowchart. The first determination

Unified CM makes when receiving a call in URI form is
to check whether the user portion (LHS) of the URI is
numeric (that is, only numbers). There is an asterisk next
to that question in the flowchart because there is a caveat
here: This decision is affected by the setting of the Dial
String Interpretation parameter on the SIP profile of the
calling device. There are three choices for this parameter:
• Phone Number Consists of Characters 0–9, *, #,

and + (This is the default setting.)
• Phone Number Consists of Characters 0–9, A–D, *,

#, and +
• Always Treat All Dial Strings as URI Addresses
The first option is the default setting, but if one of the

other options is selected, then the “digits” ABCD are
considered to be numeric or, in the case of the third
option, the URI follows the NO path in the flowchart,
regardless of whether the LHS is numeric. An additional
caveat is that if the SIP request URI contains user=phone
—for example
sip:*1234@172.18.110.48;user=phone—Unified
will treats the dialed string as a number, regardless of the
Dial String Interpretation setting.
Let’s focus on the flow if the LHS is not numeric, which is

the case for most alphanumeric URIs. The first thing that
occurs is Unified CM searches for a match for the URI in
the calling search space configured on the phone in the
same way that it would search for a directory number or
another pattern. URIs are configured on the directory
number configuration page alongside the numeric
pattern. In fact, you can configure up to five directory
URIs on a directory number, and you can also configure
Unified CM to automatically assign a directory URI to a
line based on the directory URI configured on a user
associated with the line, as shown in Figure 4-33.
Figure 4-33 Directory URIs Configured on a Line
You can see in the figure that the first URI in the list
cannot be modified. This is because it is imported from
the associated user. Notice that the partition for the
imported directory URI is just named Directory URI.
This partition comes preinstalled in the system and
cannot be deleted. You can include this partition in any
appropriate calling search spaces to allow users to dial
URIs in those partitions or you can configure the
Directory URI Alias Partition parameter in the
Enterprise Parameters configuration page (Unified CM
Administration > System > Enterprise Parameters). If
you select a partition for this parameter, any imported
directory URI in the Directory URI partition is
automatically placed into the Alias partition. If you add a
new URI, the partition in which the URI is placed is
configurable, as it would be a directory number or for
another pattern.
Also notice that there is an Advertise Globally via ILS

checkbox next to each URI. Although we have not talked
about ILS yet, it will be discussed in the next section. For
now, just note the presence of this checkbox and know
that it’s a good practice to leave it enabled, even in a
single-cluster environment, in case you ever need to
expand your network to replicate URIs to other clusters.
If the calling search space on the calling device does not

have the partition with the URI being dialed or the URI
doesn’t exist on the cluster at all, the call will move to the
next step in the flowchart. If the URI is found in the
calling search space, the call is extended to the device
where the URI is configured.
It is important to note that URIs must be matched

exactly as dialed to make a match—with one exception.
By default, URI matching is performed in a case-
sensitive manner. This means that if a line is configured
as bob@example.com and a user dials
Bob@example.com, the call will fail. Most administrators
relax this policy to make URI matching case-insensitive
so that bob@example.com, Bob@example.com, and
BOB@EXAMPLE.COM all match the same URI
(bob@example.com). In order to enable case-insensitive
matching, you must set the URI Lookup Policy enterprise
parameter, configured under Unified CM Administration
> System > Enterprise Parameters, to Case Insensitive.
The next step is to look to see if the URI matches one in
ILS, which is discussed in the next section. This is the full
list of URIs that have been replicated from other clusters
in the enterprise. The mechanisms by which ILS works
are covered shortly; for now just know that Unified CM
stores a list of all the URIs on all other clusters, and each
of those URIs is associated with a value called a route
string that identifies how to reach the cluster that “owns”
that URI. If an entry in the ILS database is found with an
associated route string, Unified CM attempts to route the
call by searching for a SIP route pattern that matches the
route string.
SIP route patterns are configured in Unified CM from the

Unified CM Administration > Call Routing > SIP Route
Pattern configuration page (see Figure 4-34).
Figure 4-34 SIP Route Pattern Configuration
In this example, Unified CM is being told that any

subdomain of the webex.com domain (for example,
cisco.webex.com or example.webex.com) will match this
pattern. A SIP route pattern is placed into a partition just
as any other pattern would be, so a calling device must
contain the partition in its calling search space in order
to place a call through a SIP route pattern. All the other
parameters should look familiar. Notice that there are no
called party transformations. This is because you cannot
do any kind of manipulation on URIs. When they are
matched, they are always sent as matched. You can,
however, manipulate the calling party number (not the
calling URI, which is also sent as configured).
Notice that when Unified CM checked to see if a URI

matched one in ILS, it did not check for a partition. This
is because learned URIs are not placed into a partition.
They all exist in a global table. The only way to restrict
access to URIs is by restricting access to which SIP route
patterns a user is allowed to reach. If the user’s calling
search space cannot reach the partition of the SIP route
pattern for the route string, the phone cannot call the
URI. SIP route patterns match a route list or gateway
device and route the call through the normal route
list/route group/trunk logic as discussed earlier in this
chapter.
If the URI is not found in ILS or if a SIP route pattern is

not found for the route string, then the last thing Unified
CM attempts to do is just look at the host portion (RHS)
of the URI and attempt to match a SIP route pattern
based on just the RHS. If a match is found, the call is
routed to the destination specified by the SIP route
pattern. Otherwise, the call fails.
If the LHS is numeric, Unified CM follows the bottom

section of Figure 4-32. Patterns that are considered
numeric based on the SIP profile configuration never
attempt to match the full URI, either by looking for a
matching directory URI on the cluster or by looking in
ILS. Numeric patterns follow a completely different logic.
The first step is to determine whether the RHS matches
either the hostname, fully qualified domain name
(FQDN), or IP address of any of the servers in the cluster
or if the RHS matches the Cluster Fully Qualified DN
(CFQDN) enterprise parameter. If either of these is true,
Unified CM attempts to find a numeric match based on
the LHS of the URI. If a match is found, the call is routed
just as if that number had been dialed from a phone. If a
match is not found, no further action is taken, and the
call fails.
However, if the RHS does not match a cluster node

address or the CFQDN parameter, Unified CM checks to
see if the RHS matches the Organization Top Level
Domain (OTLD) enterprise parameter. If it does match,
it searches for a numeric match of the numbers on the
LHS, but this time if there is no match, the call does not
fail, and Unified CM looks for a SIP route pattern that
matches the RHS of the URI. It also attempts to search
for a SIP route pattern match if the RHS does not match
the OTLD.
Now that you understand how URIs are routed in

Unified CM, you should understand how to replicate URI
information between different clusters so that users in
different clusters can reach each other via URI dialing.
INTERCLUSTER DIAL PLAN

REPLICATION
Traditional URI dialing between enterprises has relied
on routing based on the right-hand side of the URI. For
example, if alice@rtp-cucm.ccnpcollab.lab wants to call
bob@sj-cucm.ccnpcollab.lab, Alice’s Unified CM cluster
just needs to know how to reach the sj-
cucm.ccnpcollab.lab domain. It does not need to know
whether bob@sj-cucm.ccnpcollab.lab is a user. It is up to
the call control device for the sj-cucm.ccnpcollab.lab
domain to determine whether that URI is valid. In
general, URI dialing is done based on the RHS of the
URI.
How do you handle an enterprise with multiple call

control devices (for example, Unified CM clusters) with
users in the same domain—such as if pgiralt@cisco.com
has a device registered to Unified CM Cluster A and
kydavis@cisco.com has a device registered to Unified CM
Cluster B? How can you route calls between these two
clusters? Well, if it’s just two clusters, you could have a
“default route.” Basically, if Cluster A does not find a
match for a user locally, then it can have a route saying to
send all calls to the cisco.com domain to Cluster B.
Cluster B can do the same, paying special attention to not
loop a call back to Cluster A if it originated from Cluster
A (and Cluster A should do the same to avoid sending
calls from Cluster B back to Cluster B). This works well
enough when only two clusters or other call control
devices exist, but what happens when you go beyond
two? You could have Cluster A send unknown calls to
Cluster B and, if a not found is returned from Cluster B,
then try Cluster C. However, this is messy and ends up
generating needless load on the system. As the number
of clusters increases, the problem gets worse and worse.
Because URIs can’t be summarized, the only way to deal

with intra-domain calling between clusters is to replicate
the full set of known URIs throughout the system so that
Unified CM managing calls for a given domain knows
which cluster is responsible for processing calls for that
URI. The mechanism by which Unified CM does this
replication is through a service called the Intercluster
Lookup Service (ILS).

ILS allows Unified CM clusters to replicate a variety of
data, including URIs, directory numbers, and patterns.
Enabling ILS is straightforward, but there are a few
decisions you must make before enabling it to ensure
that you have a smooth deployment.
Starting with Unified CM Version 10.0, ILS replication is

performed by the publisher server in a Unified CM
cluster. A cluster can take one of two roles in an ILS
network: hub or spoke. At the time of this writing,
Unified CM supports up to 10 hub clusters, and each hub
cluster can have up to 10 spoke clusters. All hub clusters
form a full mesh with other hub clusters, and each spoke
only forms a connection to the hub cluster it is assigned
when you first add the spoke to the network. Regardless
of whether a cluster is a hub or a spoke, it replicates the
full data set from all clusters in the ILS network. Using
more hubs gives you additional redundancy so that if one
hub goes down, other hubs (and spokes talking to those
hubs) can continue to communicate. However, if a hub
goes down, all spokes that rely on that hub will no longer
replicate with the rest of the network until the hub is
restored. In practice, an outage of an ILS hub is generally
not service impacting because clusters continue to cache
previously replicated data, so the only impact of an
outage is that any new changes made are not replicated
until the problem is remediated. If you plan on having
more than 10 clusters in a network or your clusters are
geographically distributed, you might want to consider
making certain nodes hubs and other spokes in order to
scale your network properly.
Figure 4-35 shows a sample ILS network topology with

12 clusters, where 4 clusters are hub clusters, and each
hub has 2 spoke clusters.
Figure 4-35 Sample ILS Network with 12 Clusters

ILS replicates data on a configurable time period. Each
cluster replicates data to all clusters to which it
communicates at the configured time interval. This
means that for data to propagate throughout the
network, it might take up to three times the configured
replication interval. For example, if Spoke 1A has some
new information to replicate to the network, it can wait
up to the replication interval before it replicates this data
to Hub 1. Once Hub 1 receives the data, it can wait up to
the replication interval before it replicates the data to
Hubs 2, 3, and 4 as well as Spoke 1B. Hubs 2, 3, and 4
will wait up to the replication interval before they
replicate the new data to their spokes. This means that if
the replication timer is set to the default value of 10
minutes, replication of new data might take up to 30
minutes.
Before you enable ILS, there is one parameter you must

change to ensure that you do not have problems later.
Every Unified CM cluster has a cluster ID, which is an
arbitrary text string configured by the administrator.
Normally this identifier is not significant, but it is very
important for ILS. This cluster ID must be unique
throughout the ILS network. By default, every Unified
CM cluster comes preconfigured with the cluster ID set
to StandAloneCluster. If you were to enable ILS without
changing this value on each of your clusters, you would
run into problems. To change this setting, navigate to
Unified CM Administration > System > Enterprise
Parameters and change the value for the Cluster ID
parameter to a unique value on each cluster.
Next, to enable ILS, navigate to Unified CM

Administration > Advanced Features. Figure 4-36 shows
the ILS configuration page on a cluster that has not yet
been configured.
Figure 4-36 ILS Configuration
When configuring ILS, you first set the Role parameter

for the cluster. The default setting is Stand Alone Cluster,
which means the cluster is not part of an ILS network.
You must select either Hub Cluster or Spoke Cluster.
Also ensure that the Exchange Global Dial Plan
Replication Data with Remote Clusters checkbox is
selected. (We discuss Global Dial Plan Replication
shortly.)
The next parameter is Advertised Route String. This

string should be in DNS domain format, but it does not
need to be a real DNS name because Unified CM will
never perform a DNS query on this string. Unified CM
will search for a SIP route pattern that matches this
route string on other clusters that need to send calls to
the cluster on which you are enabling ILS. For example,
you can use the route string cluster1.example.com.
Next, you must configure the synchronization interval.

By default Unified CM synchronizes every 10 minutes,
but you can reduce this timer to as low as 1 minute or as
long as 1 day.
Finally, you must select how you want clusters to

authenticate each other. Clusters are not allowed to join
the ILS network without proper authentication. You can
use either certificate-based authentication or password-
based authentication (or both). To use certificate-based
authentication, you must exchange the Tomcat
certificates between clusters. You can export the
certificates from one cluster and import into the others
by using the bulk certificate service or manually
managing the certificates in Cisco Unified OS
Administration. Hubs must trust certificates from all
other hubs, and any spokes attached to a hub. Likewise,
spokes must trust their hub. If you are using CA-signed
certificates, you must exchange the certificates between
clusters unless you also use a password. You can also
choose to just use a password for authentication. This is
a shared key, and it must be configured identically on all
clusters in the ILS network.
When you save the ILS configuration page for the first
time after changing the role, you see a popup dialog
asking you to either enter the address of another hub in
an existing ILS network or leave the entry blank if this is
the first hub in the network. You also see the checkbox
Activate the Intercluster Lookup Service on the Publisher
in this Cluster, which is selected by default. Make sure
you leave this checkbox selected and click OK. After a few
minutes, ILS should be activated on the publisher, and
the new network should be up or the cluster should join
the existing network. You may have to click the Refresh
button to update the list of clusters that appear at the
bottom of the page. Repeat this process of creating more
hubs and spokes and adding them to the network. When
adding a hub, you can pick any existing hub to add it to
the network. When adding a spoke, chose the hub
carefully because this will be the hub to which the spoke
replicates.
ILS can be used to advertise different information

between clusters, but the focus of this chapter is on the
ability to replicate dial plan information, including both
URIs and numbers. By enabling the checkbox Exchange
Global Dial Plan Replication Data with Remote Clusters
when you enabled ILS, you have enabled the GDPR
feature, but now you must understand how to make use
of it.
Global Dial Plan Replication

The first purpose of the Global Dial Plan
Replication (GDPR) feature is to facilitate the
replication of directory URIs between clusters. If you
have followed the steps described so far in this section,
any URIs that you have configured on the clusters in the
ILS network will be replicated as long as you left the
Advertise Globally via ILS parameter enabled on the
directory URI, as shown back in Figure 4-33. Remember
that replicating across the whole ILS network can take up
to three times the configured replication interval.
To check to see what URIs have been learned by a

cluster, navigate to Unified CM Administration > Call
Routing > Global Dial Plan Replication > Learned
Directory URIs. You should see the learned URI, the
cluster ID for the advertising cluster, and the route string
associated with the URI. Figure 4-37 shows the sample
output of the learned directory URIs page in Unified CM
Administration.
Figure 4-37 Learned Directory URIs
Now that the clusters have replicated the URIs via ILS,
the remaining step is to configure routes so the clusters
know how to reach each other, based on the advertised
route strings. The first step is to create a SIP trunk that
will be used to route the call to the destination cluster.
(This configuration will be covered in Chapter 5.) The
destination of the SIP trunk does not necessarily have to
be the cluster that owns the route string. In larger
enterprises, you might want to route all the calls from
leaf clusters to a Session Management Edition (SME)
cluster and then have the SME cluster route the calls to
the advertising cluster. This is a perfectly valid—and in
some cases recommended—design. For example, if you
have 20 clusters named c1.example.com,
c2.example.com, …, c20.example.com as well as an SME
cluster, you can configure all the leaf clusters to send
unknown calls destined to *.example.com to the SME
cluster, and then the SME cluster can have individual
routes to the specific route strings of the domains. This
prevents you from having to configure 20 SIP trunks and
20 SIP route patterns on each leaf cluster. By aggregating
the route string routing on the SME cluster, you reduce
the configuration from 400 SIP trunks to 40 (1 on each
of the 20 leaf clusters and then 20 on the SME). How you
route the calls is completely independent of the
advertisement of the route string.
To configure the routes between clusters, after you have

created the SIP trunk to the destination, you create a
route group that contains the SIP trunk and a route list
containing the route group. Next, you create a SIP route
pattern that matches either the exact route string being
advertised by the destination cluster or a route string
with a wildcard that will match. Ensure that this SIP
route string is in a partition that is reachable from any
devices you want to be able to dial a remote URI. A this
point, you should have fully operational intercluster
calling.
One important point to note is that while the route string

is matched for the purposes of determining the
destination to route a call, it is not used as the RHS of the
URI when the call is routed. What does this mean? Say
that a user dials bob@example.com. The URI
bob@example.com is learned by Cluster 1 from Cluster 2
with a route string of c2.example.com. When Cluster 1
finds a match for bob@example.com, it sees that it is an
ILS-learned URI, and the call needs to be routed using
the route string c2.example.com. Cluster 1 performs a
lookup for c2.example.com and finds a SIP route pattern
that matches the route string and points to a route
list/route group/SIP trunk. When the call is sent out the
SIP trunk to Cluster 2, the request URI and to headers in
the SIP INVITE both say the call is destined to
bob@example.com. Nowhere in the SIP message being
sent to Cluster 2 does the route string c2.example.com
appear. The route string is only used locally to make a
local routing decision. It is optionally possible to send
the route string as part of a special header in the
outbound SIP INVITE message. To enable this
functionality, you select the option Send ILS Learned
Destination Route String on the SIP profile associated
with the outbound SIP trunk. When you enable this
parameter, you see that the outbound INVITE message
includes a X-cisco-dest-route-string header with the
route string value. For example, the call in Example 4-1
is being routed to the URI bob@example.com, and the
route string included in the INVITE message is
c2.example.com. Several headers have been removed or
truncated in Example 4-1 in the interest of brevity.
Example 4-1 SIP Message with the X-cisco-dest-route-

string Header
INVITE sip:bob@example.com SIP/2.0

Via: SIP/2.0/TLS 10.122.249.71:5061;branch=z9hG4bK4f5
From: “Paul Giralt” <sip:80041000@10.122.249.71>;tag=
To: <sip:bob@example.com>
Date: Thu, 21 May 2020 16:43:29 GMT
Call-ID: 31aad400-1eb1b985-4ed2-47f97a0a@10.122.249.7
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
CSeq: 101 INVITE
Session-Expires: 1800
X-cisco-dest-route-string: <sip:c2.example.com>
Contact: <sip:80041000@10.122.249.71:5061;transport=t
Max-Forwards: 69
Content-Length: 5246
You can include the route string and use Cisco Unified
Border Element (CUBE) to allow CUBE to route the call
based on the route string instead of routing the call
based on the URI. CUBE cannot participate in an ILS
network, so this feature allows CUBE to be inserted in
the signaling and media path between two clusters
participating in an ILS network. ILS Call Routing with
CUBE is discussed in Chapter 8.
Once you have enabled intercluster URI dialing, you can

build on this and advertise directory numbers and other
numeric patterns as well. Numeric patterns can generally
be summarized, so the need to replicate them may not be
as obvious as the need for URI replication. However, in
large designs, being able to dynamically advertise
directory numbers and patterns can serve two purposes.
First, it makes provisioning easier. When you add a new
number on a cluster, you can have it automatically
advertised throughout the network to other clusters, and
it becomes reachable without requiring changes to the
configurations on the other clusters. In addition, this
feature allows for automatic PSTN failover of calls that
fail to be established via the on-net path by rerouting the
calls over the PSTN destination.
GDPR for numeric patterns does not operate in the same

way as URI replication. This is because numbers have
different requirements. The fact that numbers can be
summarized and that closest-match routing must be
performed to find the correct match means that the
simplistic rule of just checking to see if a numeric pattern
has been learned or not does not work. GDPR allows you
to advertise two distinct types of numeric routes:
numbers and patterns. A number represents a specific
directory number configured as a directory number on
the line of a phone (along with some transformations
performed on that number, which we discuss in a
moment). Patterns are like route patterns in that they
can contain wildcards and generally represent a range of
numbers rather than one specific device. Numbers and
patterns are further subdivided into two groups:
enterprise numbers/patterns and +E.164
numbers/patterns.
Enterprise and +E.164 are really just placeholders for

two different “buckets” you can advertise and place
learned patterns into. There is nothing in the system that
enforces that a number or pattern tagged as an +E.164
advertisement is actually in +E.164 format. That said,
these two designations were created specifically to
address real-world design challenges in which
enterprises need the ability to replicate both +E.164
representations of a directory number along with an
enterprise-specific number that might follow a global on-
net private dial plan—for example, in a case where you
might dial an access code followed by a site identifier
followed by the extension of the phone at that site.
Whatever you advertise via GDPR, you should ensure
that it is global in nature.
To advertise a number into ILS via GDPR, navigate to

the directory number on a device by either navigating to
Unified CM Administration > Device > Phone >
Directory Number on the Device or Unified CM
Administration > Call Routing > Directory Number. On
the directory number configuration page are two buttons
for alternate numbers, labeled Add Enterprise
Alternate Number and Add +E.164 Alternate Number.
By default, a directory number does not have either one
of these numbers. Figure 4-38 shows the administration
page after both of the alternate number buttons are
clicked.
Figure 4-38 Alternate Number Configuration on a

Directory Number
Each of the alternate number configuration sections

allows you to configure several parameters. The first is
Number Mask. This parameter allows you to manipulate
the directory number to convert it to a form that can be
advertised to other clusters. In the example shown in
Figure 4-38, the directory number configured on the line
is the four-digit extension 1000. This is not a globally
unique number. In fact, you may have many branches
where the reception desk always has extension 1000, for
example. You would like anyone to reach the reception
desk at any site by dialing 8 followed by a 3-digit site
code followed by the extension (1000 in this case). You
would also like others to be able to reach this number by
dialing its full +E.164 number. For the purposes of
inbound call routing, you would have to somehow
transform inbound calls to the +E.164 number into the
directory number on this line, but instead of doing that,
you can just create an alias for this extension with the full
+E.164 number. The GDPR configuration allows you to
do this in addition to advertising the pattern globally
throughout your enterprise.
In this example, because this phone is located at site 555,
the mask for the enterprise alternate number is
8555XXXX. As you type, the web page dynamically
updates to show you the result of applying the mask to
the directory number next to the Alternate Number field
so you can be sure the number is as you expect it to be.
The next parameter, Add to Local Route Partition, allows

you to make this transformed number available to dial
for users on this same cluster. This essentially creates an
alias for this directory number, using the alternate
number, and places the alternate number into a partition
of your choice. You must select which partition you
would like to insert the pattern into by using the Route
Partition field. When inserting into a local partition, you
can select whether the pattern that is inserted is marked
urgent priority or not.
The last parameter is the checkbox Advertise Globally via

ILS. If this box is selected, the alternate number is
advertised via ILS and associated with the route string
for this cluster, along with a tag indicating the type of
alternate numeric pattern—in this case, an alternate
number.
The configuration is identical for the +E.164 alternate

number configuration. In this case, the number mask
applied translates the directory number to a full +E.164
pattern. By inserting this +E.164 pattern into a partition
that is searched when callers place outbound PSTN calls,
you enable a function often referred to as “forced on-
net.” Basically, you are ensuring that if someone decides
to place a call to one of your on-net extensions by dialing
that number as if they were calling through the PSTN,
the system recognizes this and routes the call directly
between devices instead of sending the call out to the
PSTN and back. This also allows you to preserve features
such as video and wideband audio when users
inadvertently dial each other using a PSTN dialing habit
instead of using an on-net dial plan.
There is one additional configuration parameter related

to GDPR on the line configuration page: the Advertised
Failover Number selection. You can set this parameter to
either Enterprise Number or +E.164 Number. This
parameter tells the remote cluster which number should
be used in the event of a failed call to this directory
number. This failover number applies to calls made to
any directory URIs configured on this directory number
as well as any alternate numbers. This means you can
now have PSTN failover for URI calls. For example, if a
user dials bob@example.com as an intercluster call that
matches a URI learned via ILS and there is a failure for
some reason, if an +E.164 alternate number is configured
and advertised via ILS as well and marked as the
advertised failover number, the call is rerouted over the
PSTN. The calling device uses the AAR calling search
space on the device to determine the path to the PSTN.
You must ensure that the AAR calling search space has
route patterns with routes to the PSTN that can match
the failover number in +E.164 format for the failover to
work.
This is all that is needed to advertise numbers between

clusters, but additional configuration is required to be
able to call these numbers from other clusters. The first
piece of additional configuration you already did when
configuring intercluster URI dialing: the configuration of
SIP trunks and SIP route patterns to facilitate
intercluster routing of calls via route string. There is one
other bit of configuration needed that is unique to
numeric GDPR advertisements. This configuration is
found on the Unified CM Administration > Call Routing
> Global Dial Plan Replication > Partitions for Learned
Numbers and Patterns configuration page. Figure 4-39
shows this configuration page.
Figure 4-39 Alternate Number Configuration on a

Directory Number
This configuration page determines what happens to

advertised numbers and patterns that are learned by this
cluster. Unlike URIs that are placed in a global ILS
lookup table that is referenced when Unified CM cannot
find a match for a local URI, numbers and patterns must
be explicitly placed into a specific partition as they are
learned. Four unique types of numbers and patterns can
be advertised: enterprise alternate numbers, +E.164
alternate numbers, enterprise patterns, and +E.164
patterns. A number or pattern advertisement gets placed
into the appropriate partition, based on its type. By
default, the system comes preconfigured with four
partitions for the different types of learned numeric
advertisements, but you can choose to change the
partition.
You have the option to mark the patterns that are

learned as urgent or not. For learned patterns (which can
contain wildcards), you also have the option to only mark
patterns that are fixed length as urgent while keeping
variable-length patterns non-urgent. You may be
wondering why you might want to mark a pattern or
number as urgent. Let’s consider a quick example.
Suppose you are following a methodology similar to the

TEHO example discussed previously, where a user
dialing a PSTN number matches a translation pattern,
which then translates the number to +E.164 format. You
may have just a simple route pattern of \+! configured to
send all calls to the PSTN after being translated to
+E.164 format. If you wanted to intercept calls that
should remain on-net, you could place the Global
Learned E164 Numbers partition into the calling search
space configured on the translation pattern so that after
translating the number to +E.164 format, Unified CM
not only searches for the partition containing the \+!
route pattern but also searches through the learned
+E.164 patterns. If a better match is found in the learned
patterns, the call is routed on-net. When you mark the
learned patterns with urgent priority, the call gets routed
immediately instead of waiting for additional digits.
Advertised patterns can be configured by navigating to

Unified CM Administration > Call Routing > Global Dial
Plan Replication > Advertised Patterns. Figure 4-40
shows a sample configuration for an advertised pattern.
Figure 4-40 Advertised Pattern Configuration
The configuration of an advertised pattern is slightly

different from the configuration of an alternate number.
First of all, the pattern can contain wildcards, and the
pattern can even be variable length. You can designate
the pattern to be advertised as either an enterprise
number pattern or an +E.164 number pattern. In
addition, you have some options for PSTN failover
advertisements. You can chose not to advertise any PSTN
failover, advertise the number itself as the PSTN failover
number (which is useful if the number being advertised
is itself an +E.164 number, so the same number should
be tried via the PSTN instead of via on-net), or
manipulate the number by stripping a certain number of
digits from the left side of the number and then prefixing
a certain number of digits to create the failover pattern.
You might wonder why you would take this approach
instead of just adding a mask. Masks do not work for
variable-length patterns because you don’t know how
long you need to make the mask; masks don’t offer
variable-length masking options.
The advertised patterns are placed into the appropriate

partitions on the receiving clusters, and you can then
incorporate the learned patterns into your dial plan in
any way you see fit.
What if you are in a scenario where you have URIs that

need to be routed to an external system that does not
support ILS and GDPR, and those URIs are part of the
same domain as the URIs that are being routed by the
Unified CM clusters? Unified CM provides a mechanism
to deal with this situation, through the use of an
imported dial plan catalog. This is a mechanism by which
you can import a CSV file containing a list of URIs or
patterns and associate them with a route string, just as if
those URIs had been learned from an external system
advertising that route string.
Note that, by default, ILS and GDPR allow a cluster to

insert up to 100,000 learned objects (URIs and alternate
numbers) into the local database, but Unified CM can
scale up to 1,000,000 entries on a properly sized cluster.
To change the maximum number of learned objects, you
must modify the ILS Max Number of Learned Objects in
Database parameter for the Cisco Intercluster Lookup
Service under Unified CM Administration > System >
Service Parameters.
You now have all the tools you need to create a robust,
scalable, global, multi-cluster dial plan for both numeric
and alphanumeric URI dialing. Although you now have
the tools and know the basics of how to use the tools,
building a dial plan can sometimes be more of an art
than a science. It can be tricky to take into account the
requirements from end users as well as business and
scaling requirements to build a dial plan that meets your
business needs and that also provides the needed
flexibility to your end users. You must practice building
dial plans to become fully proficient in this art. Even
after you have configured a dial plan, you are bound to
run into challenges implementing it, so understanding
how to troubleshoot dial plan–related issues is a key skill
to master.
TROUBLESHOOTING CALL ROUTING

AND DIGIT MANIPULATION
Unified CM provides a variety of built-in tools and
logging that can help you diagnose and troubleshoot dial
plan–related problems. In addition, external tools
provided by Cisco and third parties can assist you in
troubleshooting problems related to call routing and
digit manipulation. Typically, call routing issues manifest
as users attempting to place calls that do not complete.
There are other variations, as well, such as inbound calls
not ringing a phone or calls being routed to the wrong
number or through the wrong gateway. Sometimes a call
seems to complete, but the user ends up receiving a
message indicating that there was a problem completing
the call. This section explores the available tools to help
you better diagnose the root causes of these types of
issues.
This section discusses the following tools:
• Dialed Number Analyzer (DNA)

• Real-Time Monitoring Tool (RTMT)
• SDL trace files
• The trace parsing tools Collaboration Solutions

Analyzer and TranslatorX
Dialed Number Analyzer

The Dialed Number Analyzer (DNA) tool is a built-
in component of Unified CM that allows you to provide a
set of dialed digits or URIs and ask Unified CM to return
the digit analysis results and call flow information for
how a given call would be routed through the system. It
allows you to examine the call routing logic that would be
used if such a call were to be placed on a real device.
DNA has two modes of operation. In one mode, you can
select a configured device—a phone, gateway, or trunk—
and then ask the system what would happen if a call were
to originate from that device with a given set of
parameters. The other mode is a more generic analyzer
that allows you to provide calling and called numbers
along with a calling search space and ask the system to
evaluate the call, based on those parameters. Both modes
actually do the same thing. The only difference is that
when you choose a device, DNA determines the calling
number and calling search space information from the
device (and line) instead of requiring you to enter it
manually.
To access the DNA tool, you must first ensure that the
service is activated and running. You do so from Cisco
Unified Serviceability. If you are logged in to Unified CM
Administration, navigate to Cisco Unified Serviceability
> Tools > Service Activation. Activate both the Cisco
Dialed Number Analyzer and Cisco Dialed Number
Analyzer Server services. Both services must be activated
for DNA to work.
Once you have the DNA services running, navigate to the
DNA tool by navigating to Cisco Unified Serviceability >
Tools > Dialed Number Analyzer or pointing your
browser to https://<publisher_ip_address>/dna/.
The Analysis menu in DNA has the following options:
• Analyzer: Allows you to specify a calling number,

calling search space, called number, and time and
returns the results of the digit analysis match and
call routing for that call.
• Gateways: Allows you to select a gateway and port

on the gateway and then specify a calling number
and a called number as well as a time for the call to
analyze the call flow for that call.
• Phones: Allows you to select a line configured on a

specific phone and analyze the call flow for a call
placed from that line at a specific time to a specified
dialed number.
• Trunks: Allows you to select a trunk and specify a

calling number and a called number as well as a
time for the call to analyze the call flow for that call.
• Dump DA Information: Dumps a full listing of

the digit analysis tree, digit discard instructions,
and learned patterns.
• Multiple Analyzer: Performs the same action as

the Analyzer option, but allows you to import a CSV
file with the data to analyze. DNA outputs a file
with all the results.
• View File: Each of the results mentioned in this

list can be saved to a file. This option allows you to
open a previously saved analysis to view it in the
browser.
The Analyzer, Gateways, Phones, Trunks, and Multiple

Analyzer features all essentially do the same thing, so
this section goes through a couple examples of calls that
originate from a phone device. To analyze a call from a
phone, navigate to Dialed Number Analyzer > Analysis >
Phones and search for a phone. Figure 4-41 shows the
Phones page, where you can select the line and specify
the dialed digits or URI and the time.
Figure 4-41 Dialed Number Analyzer Phone Analysis
You can see that the tool shows the phone configuration
information and allows you to select a line—in this case
line 1 with directory number 1001 in the 1stLine
partition. In the Dialed Digits box, you see that 1000 has
been entered. After entering this, you would click the Do
Analysis button, which would cause a new window to
appear with the analysis results, as shown in Figure 4-42.

Results
The first section of the results is the Results Summary
section, which provides information on the final calling
and called party numbers, including the pattern that
matched. In this case, you can see that the dialed digits
are 1000, but the matched pattern is 2000 in the test
partition. You can also see that Match Result says either
RouteThisPattern or BlockThisPattern to indicate
whether the call should be routed or blocked. In this
case, the results indicate that routing will be attempted.
The Call Flow section gives you details on how that result
was achieved.
In the Call Flow section, you can see that the dialed digits
first match the translation pattern 1XXX in the test
partition. You can see that there is a calling party
transformation on the translation pattern that applies
the mask +1919555XXXX to transform the calling party
number to +19195551001. There is also a called party
transformation that transforms the called party number
to 2000.
The output of the translation pattern, 2000, then

matches the directory number 2000 in the test partition.
The Forwarding Information section is collapsed in
Figure 4-42, but if you expand that section, you see all
the forwarding options configured on the line. Next, you
see the actual device that would ring if this call were
placed. The device is a Jabber endpoint (Cisco Unified
Client Services Framework) with the name
CSF8000000007.
Notice the section at the bottom of the window labeled

Alternate Matches. This section shows you other patterns
that matched the dialed digits but with less-specific
matches than the pattern that actually matched. In this
example, you can see that there is an alternate match
of XXXX, which is less specific than the 1XXX pattern
that is shown to have matched.
As a second example, let’s examine what happens when
you analyze a call that is destined to an external party
through a SIP trunk. In this case, the phone is selected,
and an analysis is done on the called party number
89915678. This example has some unusual
transformations configured so you can see how they are
displayed in DNA. This section looks at the results in two
parts. First, Figure 4-43 shows the Results Summary
section.

Results Summary
Notice that this section indicates that the calling party

number is 80041000, the matched pattern is
8XXXXXXX, and the dialed digits are 89915678;
however, the called party number shows 80029999. As
you will see, this is somewhat misleading because the
called party number can actually change depending on
what trunk or gateway a call egresses. DNA is not making
a real call, so it is just showing you all the possibilities of
routing paths, and the called party number shown is the
number after any transformations applied on the
matching route pattern, but it does not include route list
detail or gateway/trunk transformations. Those appear
later, in the Call Flow section, the first part of which is

Results Call Flow
You can see that the pattern matched is 8XXXXXXX and

that no calling party transformations are applied, but
there is a called party transformation of 80029999.
Figure 4-45 shows the remaining part of the Call Flow
section, with the route list, route group, and SIP trunk
details for the call.
Results Route List
The route list matched is vnt-cm1-cluster-rl, which

contains a single route group named vnt-cm1-cluster.
The pre-transform calling and called party numbers are
shown. Remember that any modifications performed on
the route list are applied to the pre-transform numbers,
so the called party number is back to being 8991578 for
any modifications made on the route list details. You can
see that in the route list details for this route group, there
is a called party transformation that transforms the
called party number to 83922900. The route group
contains two SIP trunk named vnt-cm1b and vnt-cm1c.
Since there are no transformations on the called party
number on the SIP trunks, the number that would be
sent out both trunks would be 83922900 in this case.
The analyzers for trunks, gateways, and the generic

analysis/multiple analysis features operate the same way
as the phone feature in DNA, so there is no need to go
into detail on how those features work. For any of these
features, you can click the Save button in the top-right
corner of the analysis results window to save the results
in an XML file. You can then use the Analyzer > View
File menu to open those results at a later time.
DNA gives you the power to view hypothetical calls

traversing through a Unified CM cluster, but what if you
want to look at real calls? In such cases, you must use
either the Session Trace feature for SIP calls or look at
the SDL trace files generated by Unified CM. To do either
of these, you need to use the Real-Time Monitoring Tool
(RTMT).
Real-Time Monitoring Tool

The Real-Time Monitoring Tool (RTMT) is an
application you install on a client PC and connect to a
Unified CM cluster to perform real-time diagnostics on
the cluster. We do not go into great detail about all the
capabilities of RTMT, but this section discusses a few
features that are useful for troubleshooting issues related
to call routing. If you have not already installed RTMT on
your PC, navigate to Unified CM Administration >
Application > Plugins and download and install RTMT
for Windows or Linux.
Once installed, launch the application and log in. You

should see a window similar to the one in Figure 4-46.
Figure 4-46 Real-Time Monitoring Tool
The first feature of RTMT that is useful for diagnosing

call routing issues is the Session Trace Log View feature.
You can find this tool by navigating to RTMT >
Voice/Video > Session Trace Log View > Real Time Data.
You then see a list of the last 30 minutes of calls, by
default. Figure 4-47 shows an example of the session
trace call list that appears.
Figure 4-47 Session Trace Search and Call List
You can see three calls in the list shown in Figure 4-47. If
you want to search for a different timeframe, you can
change the start time and duration. You can only search
for up to 60 minutes at a time. You can also specify the
calling or called number to search for. The asterisk
character is a wildcard. By default, the search is for any
calling or called party number.
This call view provides you with some useful
information. It shows you the calling and called party
numbers. Note that what is listed under Final Called DN
is actually not necessarily what gets sent out to the
destination. Remember from the DNA example how the
called number shown was the number after the
transformations on the route pattern; if there are any
transformations done on the route list details or
transformation patterns on the trunk, they do not appear
in this view of the call. You can also see the calling and
called devices, so without looking any further, you
already know which trunk or gateway (or phone, in the
case of an on-net call) the call was destined to. Finally,
this view gives you a termination cause code, which
indicates the reason the call ended. This cause code can
be a “normal” cause code such as cause code 16, which is
a normal call clearing. It can also be an abnormal (or
perhaps expected) cause code, such as 1, which is an
unallocated (unassigned) number.
In the first call in the list in the example in Figure 4-47,

you can see that the called number is just the digit 4.
This call fails immediately because there are no patterns
on this Unified CM cluster that start with a 4. The next
two calls connect successfully. You can double-click on
any of the calls listed here to pull up a ladder diagram of
the calls for a quick visualization of the SIP signaling
involved in the call. To get more details on the SIP
signaling, you can use one of the post-processing tools
discussed later in this chapter.
A useful feature in RTMT for diagnosing call routing–

related issues is the Trace & Log Central tool, which
enables you to download the trace files for the timeframe
of an issue you have experienced and then use a post-
processing tool to analyze the files. To use Trace & Log
Central, navigate to RTMT > System > Tools > Trace &
Log Central > Collect Files. You are presented with a
window that lists all the services and servers from your
Unified CM cluster, as shown in Figure 4-48.
Figure 4-48 Trace & Log Central in RTMT
To gather call routing–related log messages, the only

service you need to collect data from is the Cisco
CallManager service. Check the box in the column
labeled All Servers to download files from all the servers
in the cluster. Click Next twice until you get to the Collect
File Options page. This is where you can specify the
timeframe for the traces you want to collect. If you are
troubleshooting a problem that is easily reproducible,
just reproduce the problem and then use the Relative
Range option to select traces from the last 5 or 10
minutes. If you are trying to diagnose an issue that
happened in the past, select the appropriate timeframe
in the Absolute Range section. Select a directory in which
to place the downloaded files and then click Finish. After
a few minutes, you should have the files from all the
servers in the cluster downloaded for the timeframe in
question. Once you have downloaded the files, you can
explore them manually or use a post-processing tool to
analyze them.
Troubleshooting Call Routing by Using SDL Trace Files

When you have downloaded the SDL trace files from
Unified CM, you will have a hierarchy of folders in the
folder you designated as the download location. You will
have a folder for each server in the cluster, and in each of
those folders you will have a folder with the timestamp of
the trace collection. Below that you can see the folders
cm > trace > ccm > sdl, where you can find all the SDL
trace files in gzip (.gz) format. You can generally leave
the files in .gz format because most text reading tools can
natively read .gz files. To troubleshoot call routing issues
in the raw SDL trace files, open a file in your favorite text
editor. You need to know which server folder to look at
first. You want to look at the folder for the server to
which the originating or calling device is registered. If
the call arrives via a trunk, it may be hard to determine
which server the call originated from. (You will see
shortly that the post-processing tools make this task
much easier.)
When you first open the SDL trace file, it can be a bit
overwhelming. This section shows you the places to look,
and then when you learn to use the post-processing
tools, you will see how you can automate this process.
The first thing to understand in these trace files is how
dial plan–related information appears in the traces.
Recall that digit analysis is the process that handles all
number and URI lookups in Unified CM. Any time digit
analysis is called to perform a match, you see a line that
looks like Example 4-2 in the SDL trace file.
Let’s break down each section of the trace line shown in

Example 4-2. First of all, to find lines like this, you just
need to search for the text “Digit analysis: match,” and
you will see a line very similar to this any time you search
for that text. The fqcn value is the calling number with
the external phone number mask applied. It does not
necessarily mean that the external phone number mask
will actually be used for this call; it just means that this is
the masked number in case it is needed. The cn value
indicates the calling party number. The pss field is a
representation of the calling search space, but it is shown
as the list of the partitions that will be searched. If this is
a call from a phone, you see the list of partitions from the
line calling search space followed by the partitions from
the device calling search space, with any duplicates
removed. The TodFilteredPss field is the list of partitions
again, but it does not include partitions that are inactive
because the configured time schedule indicates that it
should not be active. The dd value stands for dialed digits
and indicates the number that is being analyzed using
digit analysis.
Example 4-2 Unified CM Digit Analysis Trace Snippet
02102283.008 |21:21:54.310 |AppInfo |Digit analysis:
Any digit analysis request results in a digit analysis

response. In this case, you see the following two lines
appear in the trace, as shown in Example 4-3. The first
line indicates a message from digit analysis saying that
no potential matches exist. This in and of itself does not
necessarily indicate a problem. When Unified CM says
that no potential matches exist, it means that there are
no patterns that have partially matched, but if the user
were to continue dialing more digits, there might be a
match. When Unified CM decides that there are no
potential matches (in other words, there is nothing the
user could possibly dial beyond what has already been
dialed to match a different pattern that requires more
digits than have already been dialed), Unified CM makes
an immediate decision on the disposition of the call.
Either the call is routed because there is a match (and no
potential matches) or the call fails because there is no
match and there are no potential matches, so there is no
point in allowing the user to dial additional digits.
In this case, you do not see a match. You only see the
message indicating that no potential matches exist. If
there is no match and there are no potential matches,
Unified CM is indicating that there is no number that
matches what has been dialed so far, and there is no
point in continuing to wait for more digits because there
is no pattern that could potentially match, given what
has been received so far.
By using these digit analysis lines, you can very quickly

see what numbers have been dialed by a user as well as
the configured calling search space that is being used to
look up a match. In Example 4-3, if you expect the user
to be able to dial a number that begins with a 4, you
would want to look at the pattern that you think should
be matching and make sure it appears in one of the
partitions listed. If it does not, you have to move the
pattern to the correct partition or modify the calling
party device’s calling search space to include the required
partition.
Example 4-3 Digit Analysis and

NoPotentialMatchesExist Explained

02102284.000 |21:21:54.310 |SdlSig |DaRes
For a second call, you might see something that looks
like Example 4-4 in the trace file. This time, you can see
that the user dialed the digit 8, as evidenced by dd="8".
Notice that this time, the message from digit analysis
indicates that potential matches exist. When potential
matches exist, Unified CM continues to wait for more
digits.
Example 4-4 Unified CM Digit Analysis Showing

PotentialMatchesExist

Up until now, we have not really explored how Unified

CM has been receiving these digits for processing. If you
want to dig a bit deeper, you need to look at the protocol-
level signaling. In most cases today, that signaling is SIP.
Shortly before the digit analysis match for the digit 8,
you see a SIP INVITE with only the digit 8 in the
Request-URI. This INVITE is shown in Example 4-5. You
can see that this is an inbound INVITE from an IP
phone, and the phone is indicating to Unified CM that it
would like to place a call to the digit 8—hence the
subsequent lookup to digit analysis for this digit.
Example 4-5 Initial INVITE from IP Phone to Unified

CM with the First Digit Dialed by the User
INVITE sip:8@svs-uc-alpha-test-cm1b.cisco.com;user=ph
From: “Test Phone 2” <sip:89943782@svs-uc-alpha-test-
To: <sip:8@svs-uc-alpha-test-cm1b.cisco.com>
Call-ID: 885a92d9-bca8007a-57658166-1fb2b634@10.122.2
Max-Forwards: 70
Session-ID: 47dbbea900105000a000885a92d9bca8;remote=0
Date: Fri, 22 May 2020 01:21:49 GMT
CSeq: 101 INVITE
Contact: <sip:2efe6755-2942-b329-6d6a-ce1d7de77e1e@10
Expires: 180
Accept: application/sdp
Remote-Party-ID: “Test Phone 2” <sip:89943782@svs-uc-
Allow-Events: kpml,dialog
Recv-Info: conference
Recv-Info: x-cisco-conference
Content-Length: 689
Content-Disposition: session;handling=optional
Because potential matches exist, Unified CM needs to be

able to accept additional digits from the phone. In order
to accomplish this, Unified CM sends a SUBSCRIBE
message to the phone to subscribe to KPML. The full
process of completing a subscription for SIP KPML is
detailed in Chapter 3, “VoIP Protocols: RTP, RTCP, and
DTMF Relay.” As a result, this chapter skips that topic
and jumps directly to the SIP NOTIFY message sent by
the IP phone in Example 4-6. The IP phone sends a
NOTIFY with an XML message body containing the rest
of the digits dialed as the user presses keys on the
keypad. Example 5-6 details the next digit, 9, being sent
from the IP phone to Unified CM.
Example 4-6 SIP NOTIFY Message with the KPML

Digit 9

To: <sip:8@10.122.249.71>;tag=1670742895
From: <sip:89943782@10.122.251.105>;tag=885a92d9bca81
Call-ID: a0138480-1eb1b9cd-52d0-47f97a0a@10.122.249.7
Session-ID: b8ce549500105000a000885a92d9bca8;remote=0
Date: Fri, 22 May 2020 01:21:50 GMT
CSeq: 1001 NOTIFY
Event: kpml
Max-Forwards: 70
Contact: <sip:2efe6755-2942-b329-6d6a-ce1d7de77e1e@10
Content-Length: 205

After Unified CM accepts the SIP NOTIFY and sends a

200 OK response, you see a new digit analysis performed
on the new number. Example 4-7 shows the digit
analysis for the second digit received by Unified CM. You
can see that the dialed digits have now accumulated to
89, and there are still potential matches.
Example 4-7 Digit Analysis for the Second Digit Dialed

by the IP Phone User

This process of digit-by-digit analysis continues until the

point where the phone dials something that matches.
Skipping forward a bit, Example 4-8 shows the action
that occurs when the user has dialed the digits 89915678.
Any time there is a match, you see the line “Digit
analysis: analysis results.” You can search for this key
phrase to look for all instances of pattern matching in a
trace file.
Example 4-8 Digit Analysis Showing Analysis Results

for 89915678

Any time there is a match, as shown in Example 4-8, the

output shown in Example 4-9 follows. This is the full
digit analysis result, which contain lots of useful
information.
Example 4-9 Full Digit Analysis Results for the Dialed

Number

02103238.013 |21:22:11.970 |AppInfo ||PretransformCa
|CallingPartyNumber=89943782
|DialingPartition=Internal
|DialingPattern=8XXXXXXX
|FullyQualifiedCalledPartyNumber=89915678
|DialingPatternRegularExpression=(8[0-9][0-9][0-9][0-
|DialingWhere=
|PatternType=Enterprise
|PotentialMatches=NoPotentialMatchesExist
|DialingSdlProcessId=(0,0,0)
|PretransformDigitString=89915678
|PretransformTagsList=SUBSCRIBER
|PretransformPositionalMatchList=89915678
|CollectedDigits=80029999
|UnconsumedDigits=
|TagsList=SUBSCRIBER
|PositionalMatchList=89915678
|VoiceMailbox=
|VoiceMailCallingSearchSpace=
|VoiceMailPilotNumber=
|RouteBlockFlag=RouteThisPattern
|RouteBlockCause=0
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=1
|OverlapSendingFlagEnabled=0
|WithTags=
|WithValues=
|CallingPartyNumberPi=NotSelected
|ConnectedPartyNumberPi=NotSelected
|CallingPartyNamePi=NotSelected
|ConnectedPartyNamePi=NotSelected
|CallManagerDeviceType=NoDeviceType
|PatternPrecedenceLevel=Routine
|CallableEndPointName=[a2b59152-1bfe-d81e-2b27-379fe1
|PatternNodeId=[71a1456e-9a38-6460-a76d-857e4361f89b]
|AARNeighborhood=[]
|AARDestinationMask=[]
|AARKeepCallHistory=true
|AARVoiceMailEnabled=false
|NetworkLocation=OnNet
|Calling Party Number Type=Cisco Unified CallManager
|Calling Party Numbering Plan=Cisco Unified CallManag
|Called Party Number Type=Cisco Unified CallManager
|Called Party Numbering Plan=Cisco Unified CallManage
|ProvideOutsideDialtone=false
|AllowDeviceOverride=false
|IsEmergencyNumber=false
|AlternateMatches=
|TranslationPatternDetails=
|ResourcePriorityNamespace=
|PatternRouteClass=RouteClassDefault
You can see in Example 4-9 that there is a lot of

information to process. This output gives you
information about the final route pattern or directory
number that matched the dialed digits. If this is a route
pattern match, the results indicate any transformations
that were applied on the route pattern. The one thing you
do not see here by default is any translation patterns that
were involved in routing this call. Numbers are just
magically translated without any indication as to how
this occurred. Recall that the DNA tool shows translation
pattern results.
Although the default behavior is to not show translation

pattern or alternate pattern results in the trace, you can
(and should) configured Unified CM to do so. This
capability is controlled by the service parameter Digit
Analysis Complexity. You can find this parameter by
navigating to Unified CM Administration > System >
Service Parameter, selecting a server in the cluster, and
selecting the Cisco CallManager service. You can then
find the Digit Analysis Complexity parameter in the
System section and change the value of the parameter to
TranslationAndAlternatePatternAnalysis. Note that this
parameter is not a clusterwide parameter, which means
you must select each server in the cluster independently
to enable the parameter on each one. While you are here
changing parameters, take a moment to make sure the
CDR Enabled Flag parameter is set to True. Even if you
are not using call detail records for billing purposes, they
can be useful for troubleshooting, as you will see later.
Note that this parameter also must be configured on each
node individually and does not apply clusterwide.
Another parameter worth enabling is the CDR Log Calls

with Zero Duration flag, which shows call detail records
for calls that may not generate a CDR—namely, calls that
do not connect (and therefore have a zero duration) but
for which the cause code for the call failure is considered
to be normal. This can happen when a call is routed to
the PSTN and the PSTN plays a recording indicating that
the call failed, resulting in the caller hanging up the
phone. From Unified CM’s perspective, the call ended
“normally,” with the user hanging up before the remote
participant answered the call.
Once a digit analysis match has been performed, Unified

CM attempts to route the call to the device associated
with this pattern. The CallableEndPointName entry in
the analysis results indicates the endpoint where the call
will be routed. The value is provided as a database
primary key identifier (PKID), so it is not immediately
obvious what the called device is. It appears later in the
trace, however, so if you want to look up the value in the
database, you can query the device table with the
platform CLI command on the publisher, as shown in
Example 4-10.
Example 4-10 Unified CM SQL Query for Device PKID

Based on CallableEndPointName
admin: run sql select name from device where pkid='a2

name
==================
vnt-cm1-cluster-rl
Continuing through the traces, you can see that the

endpoint associated with this pattern is a route list, so
Unified CM proceeds to find a match in the route list.
The first line in the trace indicates that routing to the
route list has started. Here you can see the name of the
route list and the fact that it has two members. A few
lines later, you see more details on this count. Here you
can see that there is a single route group with two devices
in it, as shown in Example 4-11. You also see a line
indicating the distribution algorithm configured. The
type field indicates the distribution algorithm, with 1
being Top Down and 2 being Circular.
Example 4-11 Unified CM Traces Showing Route List

and Route Group Information
02103253.001 |21:22:11.971 |AppInfo |RouteListContro
02103254.007 |21:22:11.972 |AppInfo |RouteList - Rou

02103254.008 |21:22:11.972 |AppInfo |RouteListCdrc -
02103254.009 |21:22:11.972 |AppInfo |RouteListCdrc -
02103258.003 |21:22:11.972 |AppInfo |RouteListCdrc::
Next, you can see all the route list transformations being
applied for this route group. Example 4-12 details the
called party number being transformed to 83922900.
Recall that the digit analysis results as well as the RTMT
call list indicated that the called party number was
80029999, but here you can see that the route list is
overriding that.
Example 4-12 Digit Manipulation on the Route Group

Finally, as shown in Example 4-13, you can see that the

route list finally routes the call to the first route group
member.
Example 4-13 Unified CM Selecting a Device in the

Route Group
02103259.003 |21:22:11.972 |AppInfo |SMDMSharedData:
Finally, an outbound SIP INVITE is sent to the

destination of the SIP trunk, as shown in Example 4-14.
Notice that the request URI in the SIP INVITE is
83922900@172.18.106.59, which is the transformed
number from the route list details.
Example 4-14 Outbound SIP INVITE Sent to the

Destination Selected on the SIP Trunk
02103289.001 |21:22:11.977 |AppInfo |SIPTcp - wait_S

[333047,NET]
INVITE sip:83922900@172.18.106.59:5061 SIP/2.0
Via: SIP/2.0/TLS 10.122.249.71:5061;branch=z9hG4bK536

From: “Test Phone 2” <sip:+18889943782@10.122.249.71>
To: <sip:83922900@172.18.106.59>
Date: Fri, 22 May 2020 01:22:11 GMT
Call-ID: a7d32900-1eb1b9cd-52d3-47f97a0a@10.122.249.7
Min-SE: 1800
User-Agent: Cisco-CUCM12.5
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-cal
Call-Info: <urn:x-cisco-remotecc:callinfo>; security=
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-vi
Session-ID: 3a72348700105000a000885a92d9bca8;remote=0
Cisco-Guid: 2815633664-0000065536-0000000026-12075320
P-Asserted-Identity: “Test Phone 2” <sip:+18889943782
Remote-Party-ID: “Test Phone 2” <sip:+18889943782@10.
Contact: <sip:+18889943782@10.122.249.71:5061;transpo
Max-Forwards: 69
Content-Length: 679
This high-level overview shows how to troubleshoot call

routing issues using the raw SDL trace files. However, in
larger environments, this process can be very
painstaking due to the sheer volume of traffic in the log
files. A couple tools can help make this process
considerably easier.
TranslatorX
The first tool you might want to use is called
TranslatorX, which is not an official Cisco tool. You
can download this tool, which is available for Windows,
macOS, and Linux, from https://translatorx.org.
TranslatorX supports all versions of Unified CM and can
read protocol-level messages for SIP, SCCP, MGCP, and
H.323 (as well as ISDN Q.931 and QSig messages carried
by MGCP gateways). It is a Swiss Army knife of SDL
trace reading and can help you quickly find issues. For
one thing, TranslatorX allows you to view logs across all
your servers in a cluster (or even across multiple
clusters) at the same time. It also supports reading files
from other products, such as Cisco Expressway and
CUBE.
When you run TranslatorX, you should see a window
that looks similar to what is shown in Figure 4-49.
Figure 4-49 TranslatorX Window
The next step is to take the folder of trace files you

downloaded using the Collect Files feature in RTMT and
drag the whole folder into the box in TranslatorX.
Depending on how many files you have in the folder, this
can take a few seconds or a few minutes. When this is
complete, you see a list of protocol messages that were
found in the trace file. If you enabled the CDR Enabled
Flag service parameter, as suggested earlier, you see a list
of calls, and you can easily find a specific call in the logs
by clicking the Call List button at the top of the screen.
You then see a window that looks like the one in Figure
4-50. (Note that this is the same list of calls shown in
Figure 4-47 in the session trace tool of RTMT.)
Figure 4-50 TranslatorX Call List
From the call list, you have a couple of options. You can
select a call and either double-click it or click the View
Details button on the screen. Either way, you see a
window that looks similar to Figure 4-51.
Figure 4-51 TranslatorX CDR Details Window
This window shows you the call details. You can see that
there is no destination for the call, and the call never
connected. You can also see that the only digit dialed was
4. How can you see more details like the ones you saw in
the SDL trace file? Return to the Call List window, select
the call you want to troubleshoot, and click the Generate
Filter button to filter the messages and include only
messages relevant to this particular call. Figure 4-52
shows what the main TranslatorX window looks like
when you do this.
Figure 4-52 TranslatorX Window with One Call
Filtered
If you click on a message in the top pane of the window,

TranslatorX shows you the decoded message in the
bottom pane for the message selected. In this case, you
can see that the INVITE is selected, and the full SIP
message is shown in the bottom pane. At any time, you
can double-click on a message to open the SDL trace file
where that message was found to be taken to the exact
point in the log file that contains that message. For
example, if you double-click on the INVITE, a new
window appears that looks like the one shown in Figure
4-53.
Figure 4-53 TranslatorX Raw Trace File View
You still have to rely on the raw SDL trace files to see
things like digit analysis results and any kinds of
transformations being applied by digit analysis, but
TranslatorX makes this process easier by taking you to
the exact point in the trace associated with a particular
event, such as a SIP INVITE.
You can click the Generate Diagram button in the

bottom-right corner to view a ladder diagram for the call.
For the call we have been examining, the ladder diagram
is not very exciting because the call failed due to the
number dialed being an invalid number. Let’s take a look
at a ladder diagram for the second call we looked at
previously in the SDL trace file, where the call was
routed through the route list to a SIP trunk. Figure 4-54
shows the first part of the message sequence diagram for
this call.
Figure 4-54 TranslatorX Message Sequence Diagram
You can see that the call originates from an IP phone

with a NOTIFY message followed by a SIP INVITE. You
can click on the message on the diagram to look at the
details of the message at any time. For example, if you
click the INVITE, you see something similar to the
information shown in Figure 4-55.
Figure 4-55 TranslatorX Message Sequence Diagram

with INVITE Selected
If you want to be taken to the place in the trace file where

the INVITE occurred, you can click on the Show in Trace
button to be taken to the raw SDL trace file. If you scroll
through the ladder diagram, you can see the remainder
of the call flow, as shown in Figure 4-56.
Figure 4-56 TranslatorX Message Sequence Diagram,

Continued
The ladder diagram enables you to easily visualize where
the call originates from and where it is destined to. You
can click on the outbound SIP INVITE to examine the
calling and called party number information being sent
to the far-end destination to ensure that it is as expected.
Note
In-depth SIP troubleshooting could fill a book of its own. What we have
covered here should give you enough information to diagnose most call
routing–related issues.
Collaboration Solutions Analyzer

The last tool available to help you diagnose call routing–
related issues is the Cisco Collaboration Solutions
Analyzer (CSA). At the time of this writing, the tool
can be found at https://cway.cisco.com/csa. Make sure
you have first navigated to cisco.com and logged in with
a valid Cisco.com account before attempting to access
the CSA website. CSA contains several modules. The
module we discuss here is the Log Analysis module.
When you visit the CSA website, click on the Log
Analysis button, and you are presented with a window
that allows you to upload a set of log files. For CSA, you
must package all the log files together, so after
downloading the files from Unified CM using Collect
Files in RTMT, use a compression utility to create a
single archive of the contents of the entire folder.
After you upload the files to CSA, the tool should detect
the files with CUCM as the product type, as shown in
Figure 4-57.
Figure 4-57 Collaboration Solutions Analyzer Available
Files
You can select the checkbox next to the files and either
click the Run Analysis button or click the Play button on
the right side to analyze the logs. Depending on the
number of log files uploaded, CSA might take some time
to do the processing.
CSA processes not only the SDL traces but also some
additional logs that are included in the log file download
called the calllogs files. These files contain summary data
about SIP messages and feature invocations, but do not
include details of the messages. Because CSA reads the
calllogs files, it includes many calls that do not have
corresponding SDL traces. Those calls show up on the
list of calls with a red x in the right-most column, labeled
Within SDL, as shown in Figure 4-58.
Figure 4-58 CSA Call List with No SDL
You need to check the With SDL Only box in the Within
SDL column. Once you have selected this box, the list
shows only calls that are present in the SDL trace files.
As shown in Figure 4-59, after you. select this checkbox,
you see the same list of three calls that you saw in RTMT
and in TranslatorX.
Figure 4-59 CSA Call List Showing Only Calls with
Messages Found in SDL Traces
You can select a call from the list and wait for CSA to
perform additional processing on the call. After
processing, you see a Call Detail section with four tabs:
Call Leg Info, Signaling, Ladder Diagram, and Annotated
Logs.
The Call Leg Info tab provides an overview of the parties

involved in the call, DTMF capabilities of each party,
whether a transcoder or MTP was required for the call,
and region bandwidth information. The ladder diagram
is similar to the one presented in TranslatorX. Figure 4-
60 shows a portion of the ladder diagram for a call in
CSA.
Figure 4-60 Ladder Diagram in CSA
As with TranslatorX, you can click on a SIP message to

view the details of the message. Perhaps the most useful
feature in CSA is the Annotated Logs tab. This tab gives
you an abbreviated, annotated view of the most
important lines in the SDL trace file and filters out a lot
of the noise that is not relevant in day-to-day
troubleshooting. For example, Figure 4-61 shows a
portion of the annotated logs output for the same call
you looked at in the raw SDL trace files.
Figure 4-61 CSA Annotated Logs
Notice that CSA indicates the SIP NOTIFY messages

(which you can click on to expand and see more detail)
and the subsequent digit analysis matches as each digit is
presented. You can then finally see the digit analysis
results, just as you did in the SDL trace file. The
annotated logs also show you the route list selection and
device selection, as shown in Figure 4-62.
Figure 4-62 CSA Annotated Logs, Continued
CSA is a powerful tool that allows you to analyze Unified

CM log files to diagnose call routing as well as other
potential issues with a Unified CM cluster. We suggest
placing some calls in your environment and using RTMT,
TranslatorX, and CSA to analyze them so you can
become familiar with these tools.
Now that you have completed this chapter, you should

have a solid understanding of how to configure and
troubleshoot call routing in Unified CM for both numeric
and alphanumeric patterns, including the ability to
translate and transform calling and called party numbers
and route calls through route patterns, route lists, route
groups, hunt pilots, hunt lists, and line groups. You
should have a good understanding of why ILS is needed
for intercluster routing and the advantages of using
Global Dial Plan Replication. Finally, you should have an
understanding of the tools available for diagnosing and
troubleshooting a variety of call routing–related
problems.



MEMORY
to check your work.
DEFINE KEY TERMS

digit analysis
pattern
wildcard
closest-match routing
enbloc
alphanumeric uniform resource identifier (URI)
dialing
transform mask
transformation
digit discard instructions
directory number
route pattern
route list
route group
hunt pilot
hunt list
line group
urgent priority
local route group
partition
calling search space
time period
time schedule
translation pattern
transformation pattern
+E.164 format
tail-end hop off (TEHO)
LHS
RHS
Global Dial Plan Replication (GDPR)
alternate number
Dialed Number Analyzer (DNA)
Real-Time Monitoring Tool (RTMT)
SDL trace file
TranslatorX
Collaboration Solutions Analyzer (CSA)
alternate match
Chapter 5. Unified CM SIP Trunk
Configuration
• SIP Trunk Overview and Configuration: This

section details how to configure SIP trunks and the
various settings used for interoperability between
many different SIP trunk integrations.
• SIP Trunk Features: This section covers a few of

the features provided by SIP trunks and their
operation.
• Verify and Troubleshoot Unified CM SIP

Trunks: This section describes some
troubleshooting techniques, tools, and methods
that can be used when verifying calls that traverse
Unified CM SIP trunks.

exam topics:

conversation
• 1.1.d Session timers
• 4.1 Configure these globalized call routing elements

in Cisco Unified Communications Manager
• 4.1.g SIP trunking
• 4.2 Troubleshoot these globalized call routing

elements in Cisco Unified Communications
Manager
• 4.2.g SIP trunking
Cisco Unified Communication Manager (Unified CM)

serves many purposes in a unified collaboration network.
Primarily, Unified CM enables you to register and
manage various collaboration endpoints, such as
physical IP phones like the Cisco IP Phone 8865, soft
clients like Cisco Jabber, and telepresence desktop
endpoints like the Cisco Webex Desk Pro. In addition,
Unified CM routes calls and assists in negotiating media
capabilities between endpoints. A simple call between
two IP phones registered to Unified CM requires
minimal configuration, but there are times when Unified
CM endpoints need to communicate with devices which
use third-party servers, public networks, or even another
Unified CM cluster to control their calls. Examples
include outbound calls from an IP phone to a mobile
phone located on a public network and inbound calls
from an IP phone on another Unified CM cluster. To
facilitate these types of communication, a Unified CM
cluster may be configured to communicate with
neighboring devices by using Session Initiation Protocol
(SIP) to establish media sessions. This type of peer-to-
peer connection between call control devices using SIP is
referred to as a SIP trunk.
This chapter focuses on Unified CM SIP trunks and dives

into the various sections of the Trunk Configuration page
in Unified CM. There are many settings on a Unified CM
SIP trunk, and this chapter looks specifically at settings
that affect call routing decisions and the SIP signaling
used for call routing purposes. In addition to SIP trunks,
the chapter discusses other configuration parameters
that are required to properly understand the topic,
including the SIP trunk security profile and SIP profile.
Where possible, real-world examples and scenarios are
detailed, along with relevant configuration examples and
SDL trace samples.

1. What applications can be integrated with Unified CM

using SIP trunks? (Choose three.)
a. Cisco Emergency Responder (CER)
b. Cisco Unity Connection (CUC)
c. Active Directory (AD)
d. Unified instant messaging and presence (IM&P)
e. Cisco Unified Bore Element (CUBE)
2. When Unified CM receives an inbound call over a SIP

trunk with calling number 2000 and called number
1000, what device is the calling device, from the
perspective of Unified CM?
a. 2000
b. The device with directory number 1000
c. The device with directory number 2000

d. The SIP trunk that is used to receive the inbound
call
3. How do you specify the listening port for a SIP trunk

in Unified CM?
a. The listening port cannot be changed.
b. Specify the port in the remote destination section

of the trunk configuration page.
c. Modify the incoming port on the SIP trunk security

profile applied to the trunk.
d. Modify the incoming transport type on the SIP

trunk security profile used by the trunk.
4. How can Unified CM determine if the remote peer

defined on a SIP trunk is available to receive calls?
a. Check the Dialed Number Analyzer (DNA) tool in

Unified CM.
b. SIP is a peer-to-peer protocol, so this is not

possible.
c. Use SIP OPTIONS ping.
d. Do a TCP handshake to see if it succeeds.
5. When Media Termination Point Required is enabled

on a SIP trunk, what happens when Unified CM is
unable to allocate a media termination point?
a. The call fails because the MTP is required.
b. The call succeeds; however, it doesn’t use an MTP.
c. It depends on the value of the service parameter

Fail Call Over SIP Trunk if MTP Allocation Fails.
d. The call succeeds because Unified CM inserts a

dummy MTP.
6. How can you remove a possible point of failure for

outbound calls in a multi-node Unified CM cluster
that makes use of a SIP trunk as the called device?
a. Set Incoming Transport Type to TCP+UDP in the
SIP trunk security profile configuration.
b. This is not possible because the SIP trunk is a

virtual device.
c. Check the box for Run On All Active Unified CM

Nodes for the SIP trunk in order to avoid failure
due to intracluster communication failure.
d. Ensure that the Unified CM SIP trunk has the

Media Termination Point (MTP) checkbox enabled.
7. How can you determine whether the TCP handshake

is successful when Unified CM is preparing to
communicate with a remote destination? (Choose
two.)
a. Review the web page to see if the trunk is

registered.
b. Review the Cisco CallManager service SDL traces.
c. Review the logs on the remote destination.
d. Collect and review packet captures taken from the

Unified CM.
e. Review the Cisco IPVMS traces.
8. Which Unified CM log files contain information

about the use of SIP trunks?
a. The device tables in the databases
b. Cisco CallManager service SDL traces
c. Cisco Trace Collection Service logs
d. Cisco CTIManager service logs
FOUNDATION TOPICS
SIP TRUNK OVERVIEW AND
CONFIGURATION
Unified CM SIP trunks allow for communication with a
variety of entities, including the following:
• Cisco Unified Border Element (CUBE): CUBE

acts as a session border controller (SBC) and
performs interworking features between public
networks by way of Internet telephony service
providers (ITSP), third-party call control systems
(3PCC), and many other SIP user agents.
• Other Unified CM clusters: Unified CM clusters

can be connected via SIP Trunks to facilitate
intercluster calling.
• Cisco Unity Connection (CUC): CUC is used

for voicemail and auto-attendant functions.
• Cisco Expressway: Expressway is used to

facilitate mobile and remote access for remote
endpoints as well as business-to-business calling
over the public Internet.
• Cisco Instant Messaging and Presence

(IM&P): IM&P allows for instant messaging
services with Cisco Jabber.
• Cisco Meeting Server (CMS): CMS is used for

large-scale audio and video conferencing.
• Other third-party SIP devices: Other third-

party SIP devices include fax servers, paging
servers, and other SIP 3PCC.
Figure 5-1 illustrates a few SIP trunk integration

scenarios. As you might imagine, there is no one-size-
fits-all approach to the configurations required for each
type of SIP trunk integration. Some integrations require
that specific parameters be enabled, and other
integrations may not need those parameters at all, so you
can leave them disabled. Due to the varied nature of SIP
trunk integrations with Unified CM, it is very important
to understand how each parameter works and, more
importantly, what is being enabled or disabled.
Figure 5-1 Various SIP Trunk Integrations with Unified

CM
Throughout this chapter, keep in mind that Unified CM

sees a SIP trunk as a device. When Unified CM receives a
call for processing, it is considered an inbound call from
the perspective of Unified CM and the SIP trunk which
received the call is identified by Unified CM as the calling
device. When Unified CM has processed a call and sends
the call to a remote system, this is considered an
outbound call from the perspective of Unified CM. For
outbound calls over a SIP trunk, the SIP trunk is
identified by Unified CM as the called device. Figure 5-2
provides an illustration to help visualize this.
Figure 5-2 Inbound Call to a Unified CM SIP Trunk
Device
Figure 5-2 illustrates the following process:
Step 1. Unified CM receives an inbound SIP INVITE

message from IP 1.1.1.1 on port 5060. The
called number is 2000.
Step 2. From the perspective of Unified CM, the

calling device is SJ_SIP_TRUNK, which has
a remote destination configured for 1.1.1.1
and the SIP Trunk Security Profile for the
trunk expects inbound connections on port
5060.
Step 3. Unified CM processes the call and routes the

call based on the called number (2000) to the
trunk in step 4, as described in Chapter 4,
“Unified CM Call Routing and Digit
Manipulation."
Step 4. The called device is RTP_SIP_TRUNK, with

remote destination 2.2.2.2 and destination
port 5060.
Step 5. Unified CM sends an outbound SIP INVITE

message to 2.2.2.2 on port 5060.
Configuring a Unified CM SIP trunk involves three main

configuration components:
• The SIP trunk: This is configured from the
Device > Trunk menu in the Cisco Unified CM
Administration web interface.
• The SIP trunk security profile: This is

configured from the System > Security > SIP Trunk
Security Profile menu in the Cisco Unified CM
Administration web interface.
• The SIP profile: This is configured from the

Device > Device Settings > SIP Profile menu in the
Cisco Unified CM Administration web interface.
SIP Trunk Configuration

The SIP trunk configuration page is broken into a few
sections that group together similar configuration
parameters. The main sections required to understand
SIP trunks for the purpose of call routing are as follows:
• Device Information: This section of the

configuration page defines many of the device-
specific fields for the SIP trunk. Most of these fields
are found on all devices configured in Unified CM,
but some fields are exclusive to a SIP trunk device.
• Call Routing Information: This section of the

configuration page features many of the fields that
impact call routing and digit manipulation for both
inbound and outbound calls using this SIP trunk
device. This section is split into two subsections,
which detail the inbound and outbound settings
separately.
• SIP Information: This section of the

configuration page is where you define the SIP
adjacencies that the Unified CM cluster should
expect to communicate with via each SIP trunk. In
addition, there are many other settings defined
here, such as the association to the SIP profile and
SIP trunk security profile.
The next few sections discuss the SIP trunk configuration

parameters in these three sections.
Device Information Section

The Device Information section defines many of the
fields seen on most devices in Unified CM, such as the
device name, device pool, media resource group list, and
others. The following sections discuss only the fields
involved in SIP trunk configuration that relate to call
routing and digit manipulation.
Call Classification
Several parameters in Unified CM depend on knowing
whether a party is internal or external. For example, an
administrator can configure Unified CM to disallow
transfers between two external parties. The Call
Classification field is used to determine whether the
system should consider calls using the SIP trunk as
internal (OnNet) calls or external (OffNet) calls; the
system default is external (OffNet). This field applies to
both inbound calls and outbound calls.
This classification assists with preventing toll fraud

because the service parameters Block OffNet to OffNet
Transfer and Drop Ad Hoc Conference depend on this
classification in order to block or allow calls. The system
parameter Drop Ad Hoc Conference makes use of the
information if the parameter is set to When No OnNet
Parties Remain in the Conference. A call is determined to
fall into one of four groups: OffNet to OffNet, OffNet to
OnNet, OnNet to OffNet, or OnNet to OnNet. Figure 5-3
shows these settings and the default values.
Figure 5-3 CallManager Service Parameters for Call
Classification
The Call Classification parameter also affects the way an

IP phone rings on inbound calls. Calls received on a
trunk marked as external present a double ring on each
ring cycle on some IP phone devices, while calls received
on a trunk marked as internal present a single ring for
each ring cycle. This allows users to audibly determine
whether a call is internal or external without having to
look at the phone.
AAR Group
The AAR Group setting is used for automated alternate
routing (AAR), which is a topic covered in Chapter 6,
“Unified CM Call Control Features.” The AAR group on
the SIP trunk is only applied to inbound calls; therefore,
outbound calls that do not have enough bandwidth fail.
Retry Video Call as Audio
The name of the Retry Video Call as Audio parameter

just about says it all: When a video call fails, Unified CM
attempts to retry the call as audio only. However, there
are some small details that cannot be gleaned from the
parameter name alone. For starters, this setting works
only for outbound calls and does not have any impact on
calls that Unified CM receives over the SIP trunk.
Furthermore, this setting applies to video calls that fail
due to Location Bandwidth Manager (LBM) rejecting the
call based on bandwidth restrictions, as shown in Figure
5-4. This means video calls that fail because of issues
such as network outages do not attempt audio only.
Note
Retry Video Call as Audio relies on call admission control (CAC), which is a
topic covered in Chapter 6.
Figure 5-4 Sample Call That Starts as Video and Falls

Back to Audio After Failure
Step 1. SJ phone reaches out to SJ Unified CM to

initiate a video call with RTP phone.
Step 2. When SJ Unified CM checks whether the

video call can be routed over the SIP trunk to
RTP Unified CM, there is not enough
bandwidth for the video call and it is rejected.
Step 3. SJ Unified CM sees the SIP trunk to RTP

Unified CM is configured to retry the video
call as an audio-only call. Because there is
enough bandwidth for the audio call, SJ
Unified CM extends the audio call to RTP
Unified CM.
Step 4. RTP Unified CM extends the call to the RTP

phone.
Example 5-1 details what occurs in Figure 5-4 in the

CallManager SDL Trace on the SJ Unified CM. It is
important to understand that Step 3 occurs only when
the Retry Video Call as Audio is enabled on the SIP
Trunk.
Example 5-1 CallManager SDL Trace Analysis for
Checked Retry Video Call as Audio
##### Step 1: Digit analysis is performed after the u

01814796.011 |06:39:11.254 |AppInfo |: match(pi="2",
##### Step 2: We see this call is going to traverse t

01814818.003 |06:39:11.287 |AppInfo |SMDMSharedData:
##### Step 2: A little later there is an LBM request

01814824.000 |06:39:11.293 |SdlSig |LBMRegisterReq
##### Step 2: The request fails

01814825.002 |06:39:11.396 |AppInfo |LBMIF: CI: 1858
#### Step 3: This is where you see a difference in th

01814825.004 |06:39:11.396 |AppInfo |LBMIF: retrying
01814825.005 |06:39:11.396 |AppInfo |LBMIF: CI: 1858
01814825.006 |06:39:11.396 |AppInfo |LBMIF: RSV XML>
##### Step 4: Eventually the SJ Unified CM sends a SI

[60444,NET]
INVITE sip:2000@rtp-cucm.ccnpcollab.lab:5060 SIP/2.0
From: <sip:1000@172.18.110.61>;tag=20268~bbab2af3-f2b
To: <sip:2000@rtp-cucm.ccnpcollab.lab>
Call-ID: 5caff700-10001-40-0@172.18.110.61
CSeq: 101 INVITE
Content-Length: 575
c=IN IP4 14.50.214.108

a=sendrecv
m=video 0 RTP/AVP 31 34 96 97
a=inactive
In contrast, Example 5-2 shows what happens in the SJ

CallManager SDL traces when the Retry Video Call as
Audio checkbox is unchecked and video bandwidth
allocation fails.

Unchecked Retry Video Call as Audio
##### The LBM registration request is sent with video
01811704.000 |06:08:42.592 |SdlSig |LBMRegisterReq
##### The request fails.

01811706.002 |06:08:42.646 |AppInfo |LBMIF: CI: 1858
#### Shortly after the failure we see a Call Control

01811709.000 |06:08:42.647 |SdlSig |CcRejInd
Call Routing Information Section

The Call Routing Information section, shown in Figure 5-
5, contains many of the fields that impact call routing for
both inbound and outbound calls. At the top of this
section are the checkbox for Remote-Party-ID and the
dropdown for Asserted-Type, which has the options P-
Asserted-ID (PAI) and P-Preferred-ID (PPI). These two
configuration parameters influence the delivery of these
SIP headers in SIP messages using this trunk. The
Asserted-Identity checkbox must be enabled to send
either a PAI or PPI header specified by the Asserted-
Type dropdown.
The following sections discuss the details related to

inbound call routing first and then outbound call
routing.
Note
Several fields in this section relate to digit manipulation and caller ID
presentation rather than call routing. Chapter 4 covers digit manipulation in
depth; this chapter only discusses digit manipulation in terms of how it impacts
path selection in the Unified CM call routing process.
Figure 5-5 Call Routing Information Section
Inbound Calls Subsection

The settings in the Inbound Calls subsection of Call
Routing Information apply only to calls received by
Unified CM and associated to this particular SIP trunk,
based on the source IP address and source port number.
This contains the following settings for modifying call
routing behavior:
• Significant Digits: This setting determines how

many digits are sent to digit analysis. The
precedence is given to the rightmost digits. For
example, if the called number is +14085251000
and Significant Digits is set to 4, the digits 1000 are
sent for processing. The impact to call routing is
clear as you can see that 1000 is a different called
number than the original digits received on the
trunk.
• Calling Search Space: When Unified CM

receives calls on a SIP trunk, the calling search
space (CSS) chosen here is the one used to
determine the calling privileges of the SIP trunk,
given that it is the calling device from the
perspective of Unified CM. Modifying the CSS
applied to the trunk modifies the directory
numbers or patterns that are searched by digit
analysis when an inbound call is received. For more
information about CSS and partitions, refer to
Chapter 4.
• AAR Calling Search Space: Like the CSS

previously mentioned, the AAR CSS modifies
calling privileges for the trunk on inbound calls;
however, this is applicable only for calls that failed
because CAC determined there was no available
bandwidth for the call. This CSS is applied only if
there is an AAR group configured on the trunk;
otherwise, AAR is not invoked. AAR groups are
discussed later in this chapter.
• Prefix DN: If an administrator would like to prefix

something to the called number of an inbound call,
it can be done with this field. The modified called
number can be seen in the CallManager SDL traces;
however, the traces don’t indicate which setting
performed the change, even with the CallManager
Service Parameter Digit Analysis Complexity set to
TranslationAndAlternatePatternAnalysis. As shown
Example 5-3, the inbound SIP INVITE message
with called number 1000 is processed with the
dialed digits (dd) +14085251000 because the Prefix
DN field is set to +1408525.
Example 5-3 CallManager SDL Traces with the Prefix

DN Shown

[627563,NET]
INVITE sip:1000@sj-cucm.ccnpcollab.lab:5060 SIP/2.0
From: <sip:2000@172.18.110.91>;tag=94005~594cd2d2-a0c
To: sip:1000@sj-cucm.ccnpcollab.lab

Tip
The prefix is applied after the significant digits are gathered. This is important if
the Significant Digits field is set to something other than All.
• Redirecting Diversion Header Delivery -

Inbound: When a SIP call is redirected (diverted),
the SIP Diversion header indicates the number of
the party who redirected the call. This parameter
determines whether Unified CM pays attention to
the number presented in the Diversion header on
calls received by the SIP trunk. This information
can be used in a variety of ways. For example, it can
be delivered to an IP phone to display the
redirecting number information or passed on to
another system, such as voicemail, to indicate the
redirecting number. Figure 5-6 shows Unified CM
consuming the Diversion header on a SIP trunk
instead of providing it to the called party IP phone
because Redirecting Diversion Header Delivery -
Inbound is unchecked (which is the default for this
setting). Figure 5-7 shows the same call flow but
with the Redirect Diversion Header Deliver -
Inbound option enabled. Unified CM sends to the
IP phone an outbound INVITE message that
includes the Diversion header.
Figure 5-6 Sample Call Between Two Unified CM

Endpoints That Is Redirected to a Third Unified CM
Endpoint with Redirecting Diversion Header Delivery –
Inbound Unselected
For a call received on a SIP trunk with Redirecting

Diversion Header Delivery - Inbound enabled, the
outbound SIP trunk must also have the Redirecting
Diversion Header Delivery - Outbound option
enabled in order for the redirecting information to
be passed through from one trunk to another.
Outbound Diversion header delivery is discussed
later in this chapter.
Note
The diverted number is sometimes called the redirecting party number or
original called party number.
This setting is very important for call flows that

include multiple Unified CM clusters and
integrations with service providers or other Unified
CM applications.
Step 1. The RTP phone with DN 2000 calls the RTP

phone with DN 2001.
Step 2. RTP Unified CM attempts to route the call to

the RTP phone with DN 2001; however, DN
2001 is configured to forward calls to the SJ
phone with DN 1000.
Step 3. RTP Unified CM extends the call to SJ

Unified CM, and you can see the Diversion
header in the SIP INVITE message.
Step 4. SJ Unified CM extends the call to the SJ

phone, and there is no Diversion header
because the inbound trunk on the SJ Unified
CM did not have the box checked for
Redirecting Diversion Header Delivery -
Inbound.
Figure 5-7 shows the Diversion header in the SIP INVITE
message sent from SJ Unified CM to the SJ phone with
extension 1000.

Endpoints That Is Redirected to a Third Unified CM
Endpoint with Redirecting Diversion Header Delivery –
Inbound Selected
Incoming Called Party Settings Subsection
This section of the SIP trunk configuration allows you to

modify the called number by prefixing and stripping
digits; therefore, this section impacts call routing as the
called number is modified and before it is sent to digit
analysis for processing. When a value other than Default
is defined in the Prefix section, Unified CM allows the
modification of the Strip Digits section. The Prefix
section is self-explanatory and operates similarly to the
Prefix DN parameter described earlier in this section.
Next let’s examine the Strip Digits section. Which digits

will be stripped? The leftmost digit(s), also known as the
most significant digit(s), will be stripped when there is a
value other than 0 configured. Consider the
configuration shown for the Incoming Called Party
Settings subsection in Figure 5-8.
Figure 5-8 Configuration of the Incoming Called Party
Settings
In Figure 5-8 you can see the Calling Search Space

parameter and Use Device Pool CSS checkbox. These two
settings influence the lookup of called party
transformations based on the configured CSS and
partition combination. Use Device Pool CSS is checked
by default, and as you would expect, the Device Pool
setting for the Called Party Transformation CSS is used.
To override what is configured in the device pool with a
SIP trunk–specific CSS, you must ensure that Use Device
Pool CSS is unchecked and then select the appropriate
CSS from the Calling Search Space drop down menu. It is
important to remember that the transformation pattern
lookup and subsequent changes are applied after the
strip digits and prefix operations are applied in this
section of the configuration. For more information about
calling and called party transformations, refer to Chapter
4.
Note
The configurations in the SIP trunk Incoming Called Party Settings subsection
override the prefix configured on the device pool Incoming Called Party
Settings.
Figure 5-9 illustrates the following events:
Step 1. The RTP phone at 2000 sends an INVITE

message to RTP Unified CM with called
number 9900.
Step 2. RTP Unified CM extends the call to SJ

Unified CM with called number 9900 (that is,
To: <sip:9900@sj-cucm.ccnpcollab.lab>).
Step 3. Because the SIP trunk has Strip Digits set to
2, SJ Unified CM strips the two leftmost
digits from the called number, making the
called number 00.
Step 4. Because the SIP trunk has Prefix set to 10,

SJ Unified CM prefixes 10 to the modified
called number 00, making the called number
1000.
Step 5. SJ Unified CM processes the call with called

number 1000 and extends the call to the SJ
phone at 1000.

Endpoints
Example 5-4 shows the CallManager SDL trace analysis

from the SJ Unified CM for this example.
Example 5-4 CallManager SDL Traces for Figure 5-9
##### First, we see the SIP INVITE come in with a To

[401216,NET]
From: <sip:2000@172.18.110.91>;tag=53066~594cd2d2-a0c
To: <sip:9900@sj-cucm.ccnpcollab.lab>
##### Later we see the call information modified by t

02983419.028 |11:29:47.143 |AppInfo |SIPCdpc(0) - gl
02983419.029 |11:29:47.143 |AppInfo |SPROC :: stripA
##### When the call is sent to the DigitAnalysis proc

##### Eventually the INVITE is sent to the SJ phone a

[401218,NET]
INVITE sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@14.50
Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK2d4
From: <sip:2000@172.18.110.61>;tag=200797~bbab2af3-f2
Note
The Incoming Calling Party Settings subsection operates under the same logic
as the Incoming Called Party Settings subsection regarding the Prefix and Strip
Digits operations and thus has been omitted from this text for the sake of
brevity.
Outbound Calls Subsection

None of the settings in the Outbound Calls subsection,
shown in Figure 5-10, relate to call routing. Instead, they
all pertain to number presentation or call information of
some sort. Many of these caller ID–related settings are
discussed in Chapter 4, so they are not discussed in this
chapter.
Figure 5-10 Sample Configuration of the Outbound

Calls Subsection
Redirecting Diversion Header Delivery - Outbound

One setting that is crucial to the success of SIP
integrations with voicemail systems such as Cisco Unity
Connection (CUC) is Redirecting Diversion Header
Delivery - Outbound. When a call is forwarded to a
voicemail system, it is important to know if the call is
placed directly to the voicemail system or redirected to
the voicemail system. If the call is redirected, the
voicemail system needs to know the original called
number. This allows the voicemail system to identify the
proper voicemail box for leaving a message. When the
setting is enabled on a SIP trunk, Unified CM adds a SIP
Diversion header in the outbound INVITE message for
redirected calls. In the following Diversion header, for
example, you can see that extension 1001 was dialed, and
the call was diverted from there:
Diversion: <sip:1001@172.18.110.61>;reason=no-answer;
As indicated in the previous section, when a call is

between an inbound SIP trunk and an outbound SIP
trunk, in order to properly pass a Diversion header
between the two call legs, both the Redirecting Diversion
Header Delivery - Inbound and Redirecting Diversion
Header Delivery - Outbound settings must be enabled.
SIP Information Section

The SIP Information section of the SIP trunk
configuration is where you define the SIP adjacencies
that the Unified CM cluster uses to communicate with by
using this trunk. In addition, there are many other
settings defined here, such as the association to the SIP
profile and SIP trunk security profile. Figure 5-11
provides an at-a-glance view of what can be configured in
this section. The following sections discuss some of these
parameters.
Figure 5-11 SIP Information Section of the SIP Trunk
Configuration Page
Destination
The Destination subsection of the SIP trunk
configuration is where you define the SIP peers with
which the Unified CM cluster will communicate with via
the trunk. Figure 5-12 shows the Destination subsection
of the SIP Information section.
Figure 5-12 Sample Configuration for the SIP Trunk

Destination
The Destination Address field is where you specify the

remote peer. There are three valid formats that can be
entered in the Destination Address field:
• IPv4 address
• Fully qualified domain name (FQDN)
• DNS SRV record
The Destination Address Is an SRV checkbox must be

selected only when the value provided in the Destination
Address field is a DNS SRV record. If the remote peer
supports IPv6, the address is entered in the Destination
Address IPv6 field. Some devices support IPv4 as well as
IPv6, and in those scenarios, it is recommended to
configure the Destination Address field and the
Destination Address IPv6 field.
You can add up to 16 Destinations by clicking the plus

icon to the right of the Duration column. When multiple
destinations exist on a SIP trunk, Unified CM handles
load balancing of calls in a round-robin fashion. If you
want to route calls to the remote destinations using a
different distribution algorithm, for example top down,
you might want to add individual trunks for each
destination to control call routing decisions by using
route lists and route groups as described in Chapter 4.
When a DNS SRV is selected, only a single DNS SRV
record can be configured. If there are any extra
destination rows added with the plus icon, they are
grayed out and unconfigurable.
The last configuration field in this section is Destination

Port. Typically, this is set to 5060; however, if SIP over
TLS is configured to enable encrypted signaling, it may
be set to 5061. However, it all depends on what the
remote peer is configured to use. For example, if the
remote peer is listening on 5066, the Destination Port
setting on the SIP trunk needs to reflect 5066. You
should configure the port number to match the listening
port number of the far-end device.
If the remote service to which this SIP trunk connects

supports multiple redundant servers for terminating or
originating calls through this SIP trunk, the plus icon
located all the way to the right is used to add additional
entries. If the Destination Address Is an SRV checkbox is
checked, the plus icon is disabled, and only one
destination address can be specified for the trunk, and
Unified CM determines the list of peers from the DNS
SRV record.
Note
If the remote peer is a Unified CM cluster, and a DNS SRV is configured in the
Destination Address field, it is important that the DNS SRV record include all
nodes on the remote cluster that are running the CallManager service.
Note
The Status, Status Reason, and Duration columns display N/A by default. The
information in these columns is dependent on whether SIP OPTIONS ping is
enabled on the SIP profile in use. SIP OPTIONS ping is covered in more detail
later in this chapter, along with other SIP profile parameters.
While the Destination section allows you to define the
remote endpoint information for where Unified CM will
send outbound calls, this section is also relevant for
inbound calls. Upon receiving a SIP INVITE message,
the Unified CM node checks the source of the call against
all locally available SIP trunks for a configured
destination address that matches the source address. If a
destination configuration matching the source of the
inbound INVITE message is found, the call uses that
particular SIP trunk as the incoming device, and the
settings for incoming calls apply. If there is no locally
available SIP trunk with a configured destination
matching the inbound INVITE message, Unified CM
rejects the call with a 503 Service Unavailable error and
includes a Warning header with the text “Unable to find
a device handler for the request received on port 5060
from 172.18.110.88” (as shown in Example 5-5). This IP
address will be what Unified CM was checking SIP trunk
destinations for.
Note
The listening port is the Incoming Port defined on the SIP Trunk Security
Profile as described in the upcoming sections of this chapter.
Example 5-5 Unified CM 503 Service Unavailable for

Inbound Trunk Selection Based on IP:Port
SIP/2.0 503 Service Unavailable

Via: SIP/2.0/UDP 172.18.110.88:5060;branch=z9hG4bK-24
From: <sip:1001@172.18.110.88:5060>;tag=24292SIPpTag0
To: <sip:1234@172.18.110.48:5060>;tag=1811051381
Date: Thu, 23 Jul 2020 16:23:53 GMT
Call-ID: 1-24292@172.18.110.88
CSeq: 1 INVITE
Allow-Events: presence
Warning: 399 cucm-12-5 “Unable to find a device handl
Content-Length: 0
Rerouting Calling Search Space

As previously discussed, the CSS configured in the
Device Information section is used to determine which
patterns are searched when a call is received on the
trunk; however, a different CSS is referenced when a call
is redirected using the SIP trunk. That CSS is the
Rerouting calling search space. The Rerouting Calling
Search Space setting is commonly used when the remote
peer sends Unified CM a SIP REFER message. The
Rerouting Calling Search Space setting may also be used
if an INVITE message contains a Replaces header or if a
3xx Redirection response is received for a call.
The Rerouting Calling Search Space setting is required

when CUC is integrated using SIP and there is a call
handler that transfers calls back to Unified CM using the
CUC configuration option Release to Switch. In this
scenario, a SIP REFER message is used as the transfer
method by the CUC call handler. Similarly, the Rerouting
Calling Search Space setting is also used when Unified
CM is integrated with CMS, and the Move Participants
feature is invoked to migrate a conference participant
from a conference on one call bridge to a conference on
another call bridge. In the CMS scenario, Unified CM
receives a SIP INVITE message with a Replaces header,
which triggers the Rerouting calling search space lookup.
Normalization Script
The Normalization Script settings allow an administrator

to apply one of the many built-in SIP normalization
scripts to a SIP trunk. These scripts utilize the Lua
programming language to modify aspects of inbound or
outbound SIP messages across a trunk. In one common
scenario, when Unified CM integrates with CMS, the
built-in cisco-meeting-server-interop SIP normalization
script should be applied to perform changes to the SIP
message, which allow CMS and Unified CM to function
properly. Similarly, there are other scripts which can be
found under Device > Device Settings > SIP
Normalization Script. You can also configure a custom
SIP normalization script and apply it to the SIP trunk.
The Enable Trace checkbox in this section can be useful
for printing SIP normalization logs in Unified CM SDL
traces. The topic of custom SIP normalization scripts is
beyond the scope of the CLACCM 300-815 exam. For
more information on SIP normalization on Unified CM
using Lua, visit https://developer.cisco.com/site/uc-
manager-sip/documents/sip_normalization_trans/.
SIP Trunk Security Profile Configuration

The SIP Trunk Security Profile is a mandatory field on
the SIP trunk configuration page. This profile functions
similarly to device pools: Just as a device pool allows
several settings to be applied as a single field on the
configuration page of a device, the SIP Trunk Security
Profile groups security settings related to SIP trunks. All
the security settings in the profile are applied to the
trunk when the profile is defined on the trunk.
Although there are default SIP Trunk Security Profiles

which can be applied to a SIP Trunk, administrators
often create a new SIP Trunk security profile to apply
custom settings. To configure a SIP trunk security
profile, navigate to System > Security > SIP Trunk
Security Profile. When the Find and List SIP Trunk
Security Profiles page loads, click Add New. At this point,
you reach the SIP Trunk Security Profile Configuration
page, which is shown in Figure 5-13. This is where you
specify the security parameters you want to apply on SIP
trunks.
Figure 5-13 Creating a Trunk Security Profile Called
Non Secure SIP Trunk Profile
The Name field is mandatory, and the name specified

here is what appears in the dropdown menu for SIP
Trunk Security Profile on the trunk configuration page.
The other main fields and options for SIP trunk security
profiles are discussed in the following sections.
Incoming Transport Type

There are two options for the Incoming Transport Type
field. The TCP+UDP option is the only possible choice if
Device Security Mode is set to Non Secure and the TLS
option is the only choice possible when the Device
Security Mode is set to Encrypted or Authenticated. This
section simply modifies the OSI Model Layer 4 transport
protocol the SIP trunk expects inbound SIP requests to
use.
Outgoing Transport Type

The outgoing transport type is the same as the incoming
transport type; however, the Outgoing Transport Type
parameter determines what transport protocol Unified
CM uses when sending calls to a remote peer. The three
option are UDP, TCP (default), and TLS. This field may
be used in troubleshooting when UDP is in use and the
remote device is not replying to SIP messages or when
TCP is selected and the TCP SYN message is not being
acknowledged. In such a case, you can toggle this field to
see if a network device is blocking one transport protocol
or the other. TLS is beyond the scope of the CLACCM
300-815 exam so this chapter will not cover TLS in
depth.
Incoming Port
The Incoming Port parameter defines the SIP listening

port for inbound SIP traffic from remote peers. The
default value for this parameter is 5060 for insecure TCP
or UDP traffic; for secure TLS SIP traffic, Unified CM
automatically changes the Incoming Port to 5061. This
parameter is used in conjunction with the destination
address specified on the SIP trunk in order to accept or
reject inbound calls on the trunk. Do not confuse the
incoming port with the destination port configured on
the trunk as the destination port is used for outbound
calls while the Incoming Port is used for inbound calls. If
the remote peer wants to send SIP signaling using port
5063, then the Incoming Port needs to reflect port 5063
or the inbound call will fail.
The Incoming Port parameter is reflected as the port sent

in SIP headers for outbound calls. Unified CM
administrators might change the Incoming Port
parameter to influence the peer’s responses, such as 100
Trying or 200 OK in response to Unified CM sending a
SIP INVITE message. For example, when the incoming
port is defined as 5065, the SIP Via and Contact headers
in an INVITE message sent by Unified CM show port
5065, as indicated in the following output:
INVITE sip:+123456789@10.10.10.11:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.10.12:5065;branch=z9hG4bK12a93
Contact: <sip:7777@10.10.10.12:5065>
Accept Unsolicited Notification

Two common use cases for the Accept Unsolicited
Notification checkbox are DTMF and message waiting
indication (MWI). For example, when Cisco Unity
Connection (CUC) is integrated with Unified CM using
SIP, the MWI update is sent using a SIP NOTIFY
message after the caller leaves a message and ends the
call. For example, at the bottom of Figure 5-14, the
original call has ended, and a SIP NOTIFY message is
observed. There is no explicit subscription via SIP
SUBSCRIBE, and the SIP message was not part of the
original SIP dialog—hence the unsolicited nature of this
message. If the Accept Unsolicited Notification checkbox
is not selected, unsolicited SIP NOTIFY messages are
rejected with a SIP 403 Forbidden error.
Figure 5-14 Sample Call to Cisco Unity Connection with
Subsequent Unsolicited SIP NOTIFY for MWI
Accept Replaces Header

As mentioned earlier, Unified CM leverages the
Rerouting Calling Search Space parameter when an
INVITE with a Replaces header is received on a SIP
trunk. This is commonly seen when Unified CM
integrates with a CMS cluster that is using the Move
Participants feature. The SIP Replaces header may also
be used by CMS for general load balancing of calls across
the CMS cluster when using the Call Bridge Groups
feature. For these two features to work properly, the
Accept Replaces Header setting should be enabled on the
SIP trunk security profile.
SIP Profile Information Configurations

The SIP Profile Information section, like the SIP Trunk
Security Profile Information section, enables you to
perform configurations in a templatized fashion. All the
settings in a SIP profile are applied to the trunk when the
profile is defined on the trunk. Rather than specifying
settings on each trunk, you put them in the profile and
then apply the profile to the appropriate trunks.
Much like the SIP Trunk Security Profile, there are

default SIP profiles that can be applied to a trunk.
However, many Unified CM administrators create new
SIP profile’s with custom settings enabled or disabled
based on their requirements for the SIP trunk. To
configure a SIP profile, navigate to Device > Device
Settings > SIP Profile. When the Find and List SIP
Profiles page loads, click Add New. At this point, you
reach the SIP Profile Configuration page, which is shown
in Figure 5-15. There are many options on this page, and
this section covers a few of them.
Figure 5-15 Standard SIP Profile
Keep in mind that SIP profiles are used by both SIP IP

phones and SIP trunks, and there are different
configuration sections for each. This section focuses on
the trunk-specific configuration, using the settings
displayed in Figure 5-16. Although early offer support for
voice and video calls and SIP OPTIONS ping are shown
in the figure, those configuration settings are covered
later in the chapter. There are also many other features
within the SIP Profile that are not discussed in this
chapter as they are beyond the scope of the CLACCM
300-815 exam.
Figure 5-16 Trunk-Specific Configuration Portion of the

Unified CM SIP Profile
SIP Rel1XX Options

The SIP Rel1XX Options field is required and pertains to
SIP provisional responses. For more information on SIP
PRACK operation, see Chapter 9, “CUBE Interworking
Features.” This chapter covers PRACK in terms of the
SIP trunk configuration and how this setting affects
PRACK on Unified CM SIP trunks. There are three
options for this field:
• Disabled: This means Rel1XX is not enabled.
• Send PRACK if 1xx Contains SDP: When this

option is used, PRACK is sent only when there is
SDP present in the 1XX message.
• Send PRACK for All 1xx Messages: This option

indicates that every 1XX message is acknowledged
with a PRACK; however, the SIP Rel1XX Options
field does not apply to the 100 Trying message, as it
is forbidden by the RFC 3262 to use PRACK for the
100 Trying message.
If either of the Send PRACK options are enabled, PRACK
is used on inbound calls when Unified CM sends a 1xx
message other than a 100 Trying provisional response; in
addition, Unified CM includes the 100rel header in its
own egress SIP INVITE messages when traversing a
trunk which is associated with a SIP profile that has
PRACK enabled; therefore, indicating to the far end that
PRACK is supported for the outbound call. The following
is a sample SIP Supported header, which indicates
support for reliable provisional responses (100rel):
Tip
If the remote peer sends SIP signaling that doesn’t include 100rel in the
Supported SIP header, Unified CM does not send a PRACK message,
regardless of which SIP Rel1XX Options setting is selected.
Session Refresh Method

Because SIP is a peer-to-peer protocol, it is important to
have a way to determine whether any given session is
still alive. The session status is maintained with an
occasional refresh message. When a refresh is late or
nonexistent, the session is deemed no longer active, and
a BYE is sent to terminate the session. There are two
options for this field: INVITE and UPDATE. The default
option is INVITE, which means sessions are refreshed by
sending a re-INVITE; the UPDATE option results in
sessions being refreshed using a SIP UPDATE message.
Note
Chapter 9 covers Session Refresh in-depth.
Reject Anonymous Incoming Calls

The Reject Anonymous Incoming Calls setting is self-
explanatory: If a call is received on the trunk, and the
calling party is anonymous, the call is rejected. Example
5-6 shows CallManager SDL trace analysis for a situation
in which a call is rejected because of this parameter.
Unified CM receives a SIP INVITE message with a From
header containing anonymous as the user ID. Next, the
SIP process sends a 433 Anonymity Disallowed message
to reject the call.
Example 5-6 CallManager SDL Trace Analysis for Call

Rejected Based on Anonymous Caller ID
##### The SIP trunk receives an INVITE which is from

[213830,NET]
From: “Anonymous” <sip:anonymous@anonymous.invalid>;t
Call-ID: 6e373480-10001-16-0@172.18.110.91
CSeq: 101 INVITE
X-Cisco-Presentation: “anonymous” <sip:anonymous@anon
P-Asserted-Identity: <sip:172.18.110.91>
Privacy: id
Remote-Party-ID: <sip:172.18.110.91>;party=calling;sc
Contact: <sip:172.18.110.91:5060;transport=tcp>;video
##### After the parameter is checked, the server prin

01563242.016 |14:46:30.302 |AppInfo |SIPCdpc(9) - pr
##### The response to the INVITE is seen below and it

[213832,NET]
SIP/2.0 433 Anonymity Disallowed
From: “Anonymous” <sip:anonymous@anonymous.invalid>;t
To: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=102437~bbab
Date: Mon, 02 Dec 2019 19:46:30 GMT
Call-ID: 6e373480-10001-16-0@172.18.110.91
CSeq: 101 INVITE
Reason: Q.850; cause=21

Reject Anonymous Outgoing Calls
The Reject Anonymous Outgoing Calls setting is like
Reject Anonymous Incoming Calls, but there are two
differences. The first difference is in the direction of the
call. For the Reject Anonymous Outgoing Calls
parameter to be applicable, the call must be leaving
Unified CM using a SIP trunk with this parameter set.
The other difference is found in the CallManager SDL
traces. For the outbound call, Example 5-7 shows the
message shown in the traces; you do not see this message
for the inbound call sample in Example 5-6.
Example 5-7 A Sample Snippet of CallManager SDL

Traces Detailing a Call Rejection Based on Anonymous
Caller ID
01575230.003 |15:21:21.482 |AppInfo |SIPCdpc(19) - n
SIP TRUNK FEATURES

Up to this point, the chapter has discussed different SIP
trunk configurations that impact call routing and digit
manipulation. The following sections discuss some of the
settings on the SIP trunk configuration page that affect
various aspects of Unified CM, such as SIP interworking,
media processing, and SIP trunk availability both in
Unified CM and with remote devices.
SIP Early Offer Versus SIP Delayed Offer
While the concepts of SIP early offer and delayed offer

are covered in Chapter 2, “VoIP Protocols: SIP and
H.323,” this section discusses early offer and delayed
offer on Unified CM SIP trunks and how to influence the
type of offer sent by Unified CM. By default, Unified CM
uses delayed offer when sending egress SIP INVITE
messages. In order to modify this behavior, it is
necessary to change the configuration of early offer
support for voice and video calls on the SIP profile used
by the SIP trunk.
There are three options for the field Early Offer support
for voice and video calls:
• Disabled (Default Value): INVITE messages

sent from the Unified CM to a remote peer do not
contain SDP.
• Best Effort (No MTP Inserted): An early offer

is sent via the SIP trunk only if the media
information of the calling party is known at the
time the call is placed. An example of this behavior
is illustrated in Figure 5-17, which shows two
different scenarios that are possible when this
parameter is configured with this setting. In the
first scenario, the inbound SIP INVITE contains
SDP, which means Unified CM can send an egress,
early offer SIP INVITE message. In the second
scenario, where a delayed offer SIP INVITE is
received by Unified CM, the egress SIP INVITE sent
by Unified CM also uses delayed offer because
Unified CM does not know the media information
of the calling party.
Figure 5-17 Using Best Effort (No MTP Inserted) with a

Unified CM SIP Trunk
• Mandatory (Insert MTP if Needed): With this
setting, an early offer is sent for all outbound calls.
Furthermore, a media termination point (MTP) is
inserted if the media information for the calling
party is unknown. Figure 5-18 illustrates a similar
scenario to the one shown in Figure 5-17 but with
Mandatory (Insert MTP if Needed) enabled. In the
first call shown in Figure 5-18, early offer is
received on the ingress INVITE message, and thus
an INVITE message with an early offer is sent.
However, in the second call depicted in Figure 5-18,
the following process occurs:
1. No SDP or media information is received with the

ingress INVITE message.
2. Unified CM needs to allocate an MTP; therefore,
Unified CM pulls in an available MTP which
happens to be on a voice gateway.
3. The egress SIP INVITE message is sent as early

offer with SDP. Unified CM adds the MTP IP
address and port number to the SDP for of the
egress SIP INVITE message.
4. RTP is established between the calling party and
the MTP, as well as between the called party and
the MTP.
Note
Unified CM has local, software MTPs that can be used in place of the MTP on
the voice gateway.
Figure 5-18 Using Mandatory (Insert MTP if Needed)
with a Unified CM SIP Trunk
SIP OPTIONS Ping

Unified CM can utilize SIP OPTIONS messages known as
SIP OPTIONS Ping or SIP Keepalive to perform out-of-
dialog (OOD) SIP reachability testing. This reachability
check allows Unified CM to determine whether the
remote peer defined on a SIP trunk is active and
reachable. If a destination does not respond to a SIP
OPTIONS message, it is considered down and Unified
CM will not attempt routing calls to the destination.
Once the destination responds to the SIP OPTIONS
messages, Unified CM will then attempt to extend calls to
the destination when appropriate. This reduces the
failover time when there are multiple SIP trunks in a
route group. To be considered down, or “out of service,”
one of the following must occur:
• If TCP or TLS is used, the TCP socket is not

established.
• If UDP is used, no response is received to multiple

transmissions of a SIP OPTION message.
• A SIP 503 Service Unavailable response is received.
• A SIP 408 Timeout response is received.

All other responses to a SIP OPTIONS message are
considered valid, and the trunk remains up and in
service. Note that each Unified CM server is responsible
for tracking its own reachability of the remote peer. It is
possible for Unified CM Server A to send a SIP OPTIONS
message, receive a 200 OK message, and mark the trunk
as being in service locally; however, for one reason or
another, Unified CM Server B may send a SIP OPTIONS
message but never receive a response. Unified CM Server
B then marks the trunk down and out of service. In this
scenario, only Unified CM Server A can process inbound
and outbound calls because it is the only server with the
SIP trunk marked as in service. While Unified CM Server
B might process a call intended for the remote peer,
Unified CM Server B will not extend the call to the
remote peer due to reachability issues. The call will not
be handed over to Unified CM Server A and the call will
fail because the remote peer is not reachable from the
Unified CM node that processed the call.
Unified CM does not send SIP OPTIONS pings by

default. This is a feature that needs to be enabled via the
SIP profile assigned to a SIP trunk (see Figure 5-19). To
enable OPTIONS pings, simply enable the SIP OPTIONS
Ping checkbox; as shown in Figure 5-19, selecting this
checkbox enables the time intervals and retries counters
for modification.
Figure 5-19 Unified CM SIP Profile Configuration for

SIP OPTIONS Ping
When SIP OPTIONS messages are enabled on a SIP
profile assigned to a SIP trunk, the SIP Trunk Status
column found on the Device > Trunk page (shown in
Figure 5-20) is populated with one of three values and
the SIP Trunk Duration is populated with total time the
trunk has been in that status:
• Full service: All remote destinations are

reachable or have returned SIP responses
indicating that they are up and accepting
connections from Unified CM.
• Partial Service: At least one destination peer has

failed the reachability check defined earlier in this
section. Partial status is from the perspective of the
current Unified CM node.
• No Service: None of the destination peers are

reachable, or they have failed one of the checks
defined earlier in this section.
Figure 5-20 SIP Trunk Status Reported Through the

SIP OPTIONS Message
Tip
If SIP OPTIONS messages are not enabled, the SIP Trunk Status column on
the Device > Trunk page indicates Unknown OPTIONS Ping not Enabled.
If a trunk is not in full service, a status reason is usually

shown on the SIP trunk page, next to the problematic
destination address. The reason can be one of three
values:
• local=1: Request timeout
• local=2: Local SIP stack is not able to create a

socket connection with the remote peer
• local=3: DNS query failed
Figure 5-20 details two different statuses for SIP trunks.

The first is a SIP trunk (SIP_OPTIONS_BAD) with a
status of No Service, and the second is the SIP trunk
(SIP_OPTIONS_GOOD) that is in full service. The first
part of this figure shows both SIP trunks in a table that
has SIP Trunk Status and SIP Trunk Duration columns.
The two portions at the bottom of the figure show
Destination sections for both SIP trunks. The values
under Status, Status Reason, and Duration are listed
next to the destination address and port that was polled
with the SIP OPTIONS message.
Media Termination Point Required

Figure 5-21 shows the SIP trunk configuration page.
When the Media Termination Point Required box on this
page is checked, an MTP is allocated for each outbound
call. The use of the word Required in the name implies
that calls will fail if an MTP is not available; however,
this is not completely true. A Cisco CallManager service
parameter determines whether the call should fail when
the MTP is not available: Fail Call Over SIP Trunk if MTP
Allocation Fails. The default setting for this parameter is
False, which causes Unified CM to attempt call routing in
a scenario where no MTP can be inserted.
Figure 5-21 Media Termination Point Required
The MTP Required field is sometimes recommended as a

solution to a variety of issues; however, it is not an ideal
approach and is typically a workaround to some other
issue that can be solved through other mechanisms. It is
best to let the Unified CM server dynamically insert an
MTP into a call rather than allocate an MTP for each
outbound call. When this field is enabled, media
resources are needlessly consumed. Furthermore, if an
outbound fax call uses a trunk that requires an MTP, the
fax call is negatively impacted by the presence of the
media resource.
Note
The allocation logic of media resources by Unified CM is beyond the scope of
the CLACCM 300-815 exam.
Run On All Active Unified CM Nodes

The Run On All Active Unified CM Nodes setting enables
each node in a cluster to process calls for a SIP trunk
directly rather than needing to potentially contact
another node in the cluster in order to make use of a SIP
trunk. When the Run On All Active Unified CM Nodes
setting is disabled, calls are subject to an additional point
of failure, and the SIP trunk process runs only on nodes
that are in the Unified CM group of the device pool
configured on the SIP trunk. This means that only some
nodes in the cluster accept calls for this SIP trunk. In
addition, outbound calls originate only from the nodes in
the Unified CM group. Figure 5-22 shows how a call is
processed when this feature is not enabled.
Figure 5-22 Sample Call Without Run on All Active CM

Nodes Enabled
In contrast, when the Run On All Active Unified CM

Nodes setting is enabled, there is additional redundancy
and less intracluster traffic across the network, as shown
in Figure 5-23. This setting also simplifies
troubleshooting because all call processing occurs on a
single server in the cluster, reducing the number of trace
files to review when diagnosing an issue.
Figure 5-23 Sample Call with Run on All Active CM

Nodes Enabled
Note
Note that the Run on All Active CM Nodes setting applies only to Unified CM
nodes running the Cisco CallManager service.
VERIFY AND TROUBLESHOOT

UNIFIED CM SIP TRUNKS
Whether in the lab or on the job, at some point, you will
need to troubleshoot a Unified CM SIP trunk. Common
scenarios for both new and existing SIP trunk
integrations include the following:
• A SIP trunk is down or out of service.
• Inbound or outbound calls across a specific SIP

trunk fail.
• Supplementary service features across a SIP trunk

fail.
• Presentation of Caller ID or SIP headers for calls

across a SIP trunk fail to show.
• General call routing issues occur, with the SIP

trunk as the calling or called device.
Trace analysis methods discussed in Chapter 4 are

applicable to troubleshooting the problems on a SIP
trunk; however, they are not repeated in this section. The
following sections detail a few additional methods you
can use to help scope and identify problems involving
Unified CM SIP trunks.
Packet Captures (PCAPs)

As when troubleshooting most other issues on a network,
it is often useful to get packet captures when
troubleshooting a SIP trunk. When a trunk is configured
to send SIP signaling via TCP, you can use a packet
capture to confirm the TCP handshake is being
established correctly and view the SIP signaling being
sent/received between Unified CM and a remote SIP user
agent. When SIP signaling is sent via UDP, it is still
possible to see the messages in the pcap, including UDP
SIP messages being sent repeatedly if they are not
responded to.
The commands shown in Example 5-8 enable a packet

capture from the Unified CM CLI. This packet capture is
enabled on a node-by-node basis; therefore, the
command needs to be executed in the CLI of each
Unified CM node when gathering packet captures from
multiple nodes. To stop a packet capture, simply enter a
break command such as Ctrl+C. If the packet capture file
fills up, the capture automatically stops unless you are
using the capture-rotate command, which rotates
packet captures to a new file. The first command in
Example 5-8 will capture packets of any size, for all
hosts, on all ports, for up to 1000 packets, and saves the
data into a file named cucmpcap while the second
command shows available options.
Example 5-8 Packet Capture Commands from Unified

CM CLI
admin: utils network capture size all count 1000 file
admin: utils network capture-rotate ?

Syntax:
utils network capture-rotate [options]
options mandatory file fname
options optional size bytes,sizePerFile megabytes
Example 5-9 demonstrates how to enable a packet

capture specifically for SIP traffic that is sent to, or
received from, a specific IP address. This is useful when
troubleshooting a specific SIP trunk because you can use
the IP address of the remote device for the trunk. The
command in Example 5-9 captures up to 1000 packets of
any size that are sent to, or received from, 192.168.120.5
on port 5060 and saves the data into a file named
filteredcucmpcap.
Example 5-9 Filtered Packet Capture Command
admin: utils network capture size all count 1000 host
Executing command with options:

size=ALL count=1000 inte
src= dest= port
ip=192.168.120.5
OPTIONS Ping
As previously discussed, the OPTIONS ping feature
enables Unified CM to send OPTIONS messages to
remote destinations to check their availability. This can
be a useful troubleshooting tool as the status of the trunk
helps you understand if all, some, or none of the remote
destinations are reachable by a given Unified CM node.
You can use OPTIONS ping and packet captures together
to get more visibility into the SIP dialogue for a ping.
Changing Transport Types

If Unified CM is attempting to make a TCP connection
with a SIP trunk’s remote peer, and the TCP handshake
is failing, you might choose to test SIP over UDP. If the
SIP trunk is already using UDP as the outgoing transport
type, you can attempt to use TCP. This test can provide
important information about the network path between
the two devices as sometimes one transport protocol may
work while the other transport protocol does not work.
CallManager SDL Traces

Logs for SIP trunks write to the SDL trace files for the
Cisco CallManager service. The good news about this is
that developers for Unified CM did a great job with
logging in reference to the Cisco CallManager service.
The difficult part for many is getting comfortable with
collecting and reading the logs. Throughout the sections
of this book there are snippets of CallManager SDL
traces. As you have seen, you can learn a lot by simply
collecting logs from Unified CM and reading through
them to see what is available.
As discussed in Chapter 4, there are many tools that can
be used to enhance trace analysis, including RTMT
Session Trace, Collaboration Solutions Analyzer (CSA),
and TranslatorX. While these tools are great, don’t be
afraid to open the traces in a text editor and read them
yourself. You will learn more that way.
Reset the Trunk

A SIP trunk that is added to Unified CM must be reset. In
addition, when a trunk configuration is changed, the
trunk must be reset in order for the changes to take
effect. It is best to troubleshoot an issue before resetting
the trunk; however, it is important to remain aware of
the chance a reset was required due to a configuration
change but possibly not performed. Many administrators
have lost a lot of valuable time troubleshooting trunks
that required a reset due to a configuration change and
the reset was forgotten.
Note
Any active calls traversing a trunk will drop when the trunk is reset. Care
should be taken when resetting Unified CM trunks on production networks.
REFERENCES
Cisco, “System Configuration Guide for Cisco Unified
Communications Manager, Release 12.5(1)SU1,”
mm/cucm/admin/12_5_1SU1/systemConfig/cucm_b
_system-configuration-guide-
1251su1/cucm_b_system-configuration-guide-
1251su1_restructured_chapter_01001.html

mm/cucm/srnd/collab12/collab12.html
Cisco, “Feature Configuration Guide for Cisco Unified
mm/cucm/admin/12_5_1SU1/cucm_b_feature-
configuration-guide-for-
cisco1251SU1/cucm_b_feature-configuration-guide-
for-cisco1251SU1_chapter_0100100.html
Network Working Group, “The Session Initiation

Protocol (SIP) ‘Replaces’ Header,”
http://www.rfcreader.com/#rfc3891_line158
Network Working Group, “The Session Initiation

Protocol (SIP) Refer Method,”
Network Working Group, “Session Timers in the

Session Initiation Protocol (SIP),”
Network Working Group, “Reliability of Provisional

Responses in the Session Initiation Protocol (SIP),”



MEMORY
DEFINE KEY TERMS

OnNet
OffNet
Chapter 6. Unified CM Call Control
Features
• Media Resources: This section introduces the

concept of media resources that are used for Music
on Hold, conferencing, and media termination
points and the configuration constructs that control
access to media resources in Unified CM.
• Ad Hoc and Meet-Me Conferencing: This

section describes several Unified CM features that
allow for users to establish and join ad hoc and
Meet-Me multi-party audio or video conferences.
• Music on Hold (MOH): This section discusses

the configuration of the Music on Hold feature.
• Media Resource Groups and Media

Resource Group Lists: This section details the
configuration and function of Media Resource
Groups (MRGs) and Media Resource Group Lists
(MRGLs).
• Call Park: This section describes the call park

feature and the various options available to
customize the configuration.
• Call Pickup: This section discusses the various

call pickup features, how they work, and how to
configure them.
• Regions and Codec Preferences: This section

helps you understand how Unified CM selects audio
and video codecs to use when establishing a call
between two parties.
• Call Admission Control (CAC): This section
explains how to implement location-based
(including enhanced location-based) call admission
control to ensure that connections with limited
bandwidth are not overrun by too many calls. This
section also discusses the options to reroute calls
through the PSTN in the event of a CAC failure.

exam topics:

conversation

• 5.1 Troubleshoot Call Admission Control (exclude

RSVP)
• 5.6 Configure supplementary functions
• 5.6.a Call park

• 5.6.b Meet-me
• 5.6.c Call pick-up
Cisco Unified Communications Manager provides a

variety of features that enhance your ability to manage
and route calls in the system, including multi-party
conferencing, call park, and call pickup. It also includes
features for managing the use of bandwidth for calls
through the ability to select appropriate codecs,
depending on the endpoints involved and the amount of
bandwidth between them. In addition, it allows you to
restrict the number of calls to a site if an additional call
will cause congestion on the network. This chapter looks
at each of these capabilities in detail.


1. Which types of media resources are provided by IOS

devices? (Choose three.)
a. Media termination point (MTP)
b. Transcoder
c. Conference bridge
d. Interactive voice response (IVR)
e. Music on Hold (MOH)
2. Which protocols do media resources use to

communicate with Unified CM? (Choose three.)
a. DSP Registration Protocol (DRP)
b. Skinny Client Control Protocol (SCCP)
c. Session Initiation Protocol (SIP)

d. Hypertext Transfer Protocol (HTTP)
e. Media Gateway Control Protocol (MGCP)
3. Which codecs are supported by the IP Voice Media

Streaming App service for ad hoc conferencing?
(Choose two.)
a. G.711
b. G.722
c. G.729
d. Opus
e. Wideband 256k
4. When configuring Cisco Meeting Server as an ad hoc

conference resource for Unified CM, intro which trust
store must you import the Cisco Meeting Server SSL
certificate?
a. CallManager
b. CallManager-trust
c. Tomcat
d. Tomcat-Trust
e. IPsec
5. What types of conferences are natively available in

Unified CM? (Choose three.)
a. Cisco Webex
b. Cisco Conductor
c. Ad hoc
d. Meet-Me
e. Conference Now
6. Where is most configuration for the Conference Now

feature performed?
a. Conference bridge media resource configuration
b. End-user configuration
c. Device configuration
d. Annunciator configuration
e. Interactive voice response configuration
7. Which of the following are types of audio sources that

can be configured on a device? (Choose two.)
a. Device hold source
b. User hold source
c. Line hold source
d. Network hold source
e. Global hold source
8. How many file-based audio sources can be

configured on a single Unified CM cluster?
a. 1
b. 50
c. 51
d. 500
e. 501
9. Which of the following describes the behavior when a

media resource group list is configured both on a
phone device and on the device pool of which the
phone is a member?
a. The media resource groups from the two lists are
combined, with preference for the group’s part of
the list that is configured on the phone.
b. The media resource groups from the two lists are

combined, with preference for the group’s part of
the list configured on the device pool.
c. Only the media resource group list on the device is
used.
d. Only the media resource group list on the device

pool is used.
e. This is an invalid configuration that would

generate an error.
10. What is the default duration for the Call Park

Reversion timer?
a. 15 seconds
b. 30 seconds
c. 60 seconds
d. 120 seconds
e. 1800 seconds
11. If a user uses the directed call park feature to park a

call at park destination 3001 and another user dials
3001 to retrieve the call, will the call be retrieved
successfully?
a. It depends on the calling search space of the phone

attempting to retrieve the call.
b. No; the call cannot be retrieved by directly dialing

the number.
c. Yes; this will work if the number is dialed from the

phone that originally parked the call.
d. Yes; this will work if the user has speed dial

configured for extension 3001.
e. Yes; this will work from any phone registered to

the same Unified CM cluster.
12. Which of the following call pickup features are

available in Unified CM? (Choose three.)
a. Forward pickup
b. Group pickup
c. Alternate pickup
d. Other pickup
e. Directed pickup
13. Which of the following is true of an audio codec

preference list?
a. It allows an administrator to add or remove codecs
advertised by Unified CM.
b. It allows an administrator to select the order in

which codecs are advertised by Unified CM.
c. It allows an administrator to disallow specific

codecs from being used when calls are being
recorded.
d. It defines the amount of audio bandwidth available

between two devices.
e. It defines the amount of total session bandwidth

(both audio and video) allowed between two
devices.
14. For what types of calls can you set bit rate limits by
using the regions feature? (Choose three.)
a. Audio
b. Video
c. Presentation sharing
d. Desktop sharing
e. Immersive video
15. Which of the following must be configured for

enhanced location call admission control to work
between devices in two locations? (Choose three.)
a. LBM groups
b. Locations
c. Links
d. Weights
e. Regions
16. Which locations are preconfigured on Unified CM?

(Choose three.)
a. Location 0
b. Hub_None
c. Phantom
d. Shadow
e. Transparent
FOUNDATION TOPICS
MEDIA RESOURCES
A number of Unified CM features cannot be discussed
without first discussing the broader topic of media
resources. The annunciator, conferencing, transcoding,
Music on Hold, and media termination point features all
rely on some kind of media resource because these
features all require Unified CM to terminate media on a
device other than the originating or terminating
endpoint. This chapter explores each of these features
and details each media resource. Media resources fall
into the following categories:
• Conferencing: These resources facilitate multi-

party audio or video communications by mixing the
audio and video streams of participants. A
conference involves, at a minimum, three
participants. The upper bound restricting how
many participants are involved in a single
conference is usually governed by the application
hosting the conference resource.
• Interactive voice response (IVR):

Interactive voice response (IVR) resources
play prompts and can interactively collect dual-tone
multifrequency (DTMF) digits and take action
based on user input. Two features that leverage the
IVR functionality are the Conference Now feature
and the Mobile Voice Access (MVA) feature.
• Annunciator: The annunciator capability is

invoked by Unified CM any time a prerecorded
message needs to be played to a user, such as a
message saying “Your call cannot be completed as
dialed” when the user calls an invalid number.
Annunciators can also be used for other purposes,
such as playing a ringback during a call transfer.
• Music on Hold (MOH): MOH resources play

one of several audio streams when callers are
placed on hold. The audio stream presented to a
user may be a series of tone-on-hold beeps, static
music, a custom prerecorded announcement, or
even live audio sourced from a third-party device.
• Media termination point (MTP): An MTP acts

as an intermediary to terminate media between two
devices and is used for a variety of reasons. For
example, an MTP might be used as a trusted relay
point (TRP) or as a way to terminate media on
behalf of another device when that device is not
able to terminate media for itself in a given
situation. MTPs can also be used to interwork
DTMF from one type to another type in scenarios
where there is a DTMF mismatch between two
endpoints.
• Transcoding: Transcoding resources use digital

signal processors (DSPs) to convert one audio
codec to another for scenarios where two devices
cannot support a common codec. The most
common example is interworking a codec such as
G.711μ-law into a variant of G.729. Transcoders can
also perform transrating—that is, changing the
packetization rate—where required. A transcoder
could be inserted to interwork the same media
stream with differing ptime values. An example
would be interworking G.711μ-law media stream
with a ptime of 20 ms into a G.711μ-law media
stream with a ptime of 30 ms (and vice versa).
In general, a media resource is made available to Unified

CM either through a Skinny Client Control Protocol
(SCCP) registration or, for some conference resources, a
combination of Session Initiation Protocol (SIP) and
HTTP connectivity. This chapter explores both
connectivity models and the configuration required to
make them work.
Media resources can be provided by hardware devices or

software. The IP Voice Media Streaming App
service can be activated on one or more servers in a
Unified CM cluster to provide several different software-
based media resources. Smaller deployments can have
this service activated on the same servers as Unified CM,
while larger clusters typically have dedicated servers to
run this service. The IP Voice Media Streaming App
service handles playing music on hold, plays messages
through the annunciator, handles the IVR for the
Conference Now feature, serves as an audio mixer for
audio conference calls, and provides software media
termination point (MTP) resources. All these
capabilities are configured from the Media Resources
menu in the Unified CM Administration user interface.
In addition to the media resources provided by the IP
Voice Media Streaming App service, a variety of
hardware and software solutions can register to Unified
CM and provide conference resources as well. This
chapter discusses them, as well as the individual types of
media resources.
AD HOC AND MEET-ME

CONFERENCING
While the most basic function of Unified CM is to
connect two parties in a point-to-point call, in today’s
highly collaborative world, there is increasing need to
communicate between three or more people
simultaneously. A significant portion of multi-party
conferencing occurs on cloud-based meeting platforms
such as Cisco Webex or on-premises solutions such as
Cisco Meeting Server (CMS). However, there are
situations in which a simple ad hoc conference is
needed, without the overhead associated with scheduling
a meeting and asking participants to dial in. To meet this
need, Unified CM offers a variety of options to enable ad
hoc conferencing invoked directly from a phone or soft
client. Leveraging the same infrastructure used for ad
hoc conferencing, Unified CM also provides the ability
for very basic Meet-Me conferencing functionality when
the advanced functionality of a dedicated meeting
platform is not needed. In order to enable these features,
you must first add conference resources to a Unified CM
cluster.
Unified CM supports various types of conference

resources. The types differ in their ability to support
audio or video, the number of simultaneous streams
supported, the maximum number of participants in a
conference, and the codecs supported. Unified CM
supports a variety of legacy platforms as media
resources, but this chapter discusses the ones that are
recommended for new deployments. (The legacy
platforms are configured in nearly the same way as the
ones we discuss in this chapter.) These conference
resources are discussed in this chapter:
• Unified CM software-based conference resources

(IP Voice Media Streaming App service)
• Cisco IOS-based hardware conference resources
• Cisco Meeting Server (CMS)
Once you have activated the IP Voice Media Streaming

App service, all the media resources provided by the
service, including conferencing resources, register
because they are preconfigured any time you add a server
to a cluster. While the default configuration will give you
basic functionality, you might want to make some
changes to the default configuration.
To view and change the configuration of the conference

resources, navigate to Unified CM Administration >
Media Resources > Conference Bridge and click the Find
button. You should see conference bridges named CFB_
followed by a number for each server in your cluster. If
the IP Voice Media Streaming service is activated and
started, you see the resources registered for that server in
the cluster. Note that although the service runs on one or
more servers in the cluster, the service registers to the
Cisco CallManager service based on the configured
device pool on the device, just like a phone. This means
that the media resource might not be registered to the
same server that the IP Voice Media Streaming App
service is running.
Figure 6-1 shows an example of a Unified CM cluster

with two servers with the IP Voice Media Streaming App
service running and registered. If you have already
configured other types of conference bridge resources,
you might see other items on the list as well, but by
default, you always see the software conference resources
for each node in your cluster.
Figure 6-1 List of Software Conference Resources in

Unified CM Administration
To make a configuration change to the conference bridge

resources, select the resource from the list. You then see
options shown in Figure 6-2.
Figure 6-2 Software Conference Bridge Resource

Configuration
There are not many configuration parameters here. You

can change the name to be more descriptive, perhaps to
indicate which server in the cluster it belongs to. The
name is not important, but note that changing the name
causes the resource to re-register, so you should not do
this while calls are actively using the resource. The device
pool determines the Unified CM group that this resource
uses to register, so basically it determines which servers
in the cluster the resource registers to. Unified CM can
use resources registered to any server in the cluster, even
those registered to a server that is different from the
server where a phone is trying to invoke a conference
resource. It is best practice to distribute conference
resources across your cluster in the same way you
distribute phones across multiple servers in the cluster.
The device pool also indicates the region where the
conference resource is located. This is used to select the
appropriate codec. Note that the IP Voice Media
Streaming App conference resource supports only the
G.711 and Wideband 256k codecs, so you need to ensure
that your regions are configured such that they permit
these codecs to the resource or you have an appropriate
transcoding resource available.
The Location field is used for location-based call

admission control, which is discussed later in this
chapter. This setting determines whether there is enough
bandwidth available between and endpoint and this
conference resource. If there is not enough bandwidth,
Unified CM attempts to allocate a different resource.
The Use Trusted Relay Point setting determines whether

calls that invoke this conference resource must connect
media through a trusted relay point (TRP) instead of
sending media directly to the conference resource. The
setting Default for this parameter means to use the
configuration from the common device configuration, if
one is configured. Most of the settings in the common
device configuration do not apply to conference
resources, so they are not used.
As you can see, there are very few parameters required to

register a conference resource; however, when we
discuss how media resource groups and media resource
group lists can be used to control access to media
resources, you will see that there are a variety of service
parameters that apply to conference resources as a
whole.
Note
The software conference implementation is very basic. It works well enough for
small three- to four-party conference calls, but it can be problematic for larger
calls because it does not intelligently identify silent parties, and as more
participants are added, the overall volume level for all participants can be
affected. It is highly recommended to use either a Cisco IOS hardware
conference resource or Cisco Meeting Server as a conference resource.
To enable a Cisco Integrated Services Router (ISR)

device equipped with DSPs as a conference resource, you
must add it to Unified CM and then configure the router
as a conference resource. To configure it in Unified CM,
add a new conference bridge resource and select Cisco
IOS Enhanced Conference Bridge as the conference
bridge type. The configuration is nearly identical to the
software conference bridge resource configuration shown
in Figure 6-2. However, in this case, the name is
important. The name you select as the conference bridge
name must match the name you configure in IOS. Also,
these types of media resources support encryption, so
you have the option to select whether the device security
mode is encrypted or not.
Once you have configured the resource in Unified CM,

you must then configure the router to register as a media
resource. Example 6-1 shows the commands needed to
configure and register an IOS enhanced conference
bridge resource.
Example 6-1 IOS Enhanced Conference Bridge

Configuration
ISR-4451-X# show inventory

[..truncated..]
NAME: “PVDM subslot 0/4", DESCR: “PVDM4-64 Voice DSP
PID: PVDM4-64 , VID: V01 , SN: FOCXXXXXXXXX
ISR-4451-X# show run | section sccp|voice-card|dspfar

!
sccp local GigabitEthernet0/0/0
sccp
sccp ccm 10.122.249.70 identifier 1 version 7.0
sccp ccm 10.122.249.71 identifier 2 version 7.0
!
voice-card 0/4
dsp services dspfarm
!
dspfarm profile 1 conference
codec g729br8
codec g729r8
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
codec g722-64
codec ilbc
maximum sessions 4
associate application SCCP
no shutdown
!
sccp ccm group 1
bind interface GigabitEthernet0/0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register svs-ios-conf01
!
These resources all use SCCP to register to Unified CM,

so you need to enable SCCP and bind it to a local
interface IP address on the router with the commands
sccp and sccp local <interface>, as shown in Example
6-1. You must then add the IP addresses of the Unified
CM servers to which you would like this resource to
register. Note that you should ensure that this matches
the Unified CM group in the device pool associated with
the resource as configured in Unified CM. Note that you
should select Version 7.0 for any Unified CM Version 7.0
or later (which should be all deployments).
Next, you enable the Packet Voice Digital Signal

Processor Module (PVDM) on the system for use as a
dspfarm by applying the command dsp services
dspfarm to the applicable voice card. In Example 6-1,
voice-card 0/4 references the motherboard DSP on an
ISR 4000 Series router. The actual location of your voice
card may be different, depending on the model of your
ISR. Issue the show inventory command to locate the
slot/sublot of the PVDM module. Example 6-1 shows the
relationship between the show inventory command
and the voice-card command.
Once a module has been enabled for use as a dspfarm,

the next task is to create a dspfarm profile for the
conference resource. You can specify one or more codecs
that you would like the conference resource to support,
and you can also indicate the maximum number of
sessions to support and associate the profile with the
SCCP application. The maximum sessions are
determined by the number of DSP resources that you
have available and configured on the router for DSP farm
purposes. You can issue the command maximum
sessions ? to see an on-demand total for the available
maximum number of configurable sessions. Finally, you
should enable the dspfarm profile by using the command
no shutdown. One key item to remember is that the
default maximum participants in an IOS conference
bridge is 8. You can increase this number by running the
maximum conference-participants command with
an upper limit of 32 participants in a given conference
session. The trade-off for increasing the maximum
participants in a single conference session is that the
maximum number of conference sessions available
shrinks. Example 6-1 allows for four conference sessions
with eight participants each.
Finally, you create an sccp ccm group to bind the

group to an interface on the router and then associates
the previously configured servers with the dspfarm
profile. The dspfarm profile number must match the one
previously configured. Similarly, the profile name
configured here should also match what was configured
in Unified CM. Once you have taken these steps, the
resource should appear as being registered in Unified
CM administration.
One large drawback of IOS-based conferencing is that it

supports only audio conferencing. A second drawback is
the total number of participants that can be engaged in
audio-only conferences using IOS dspfarms as a
conference resource. If you want your ad hoc and Meet-
Me conferences to support video calls, the best choice is
to leverage the Cisco Meeting Server (CMS) platform.
CMS is also a very scalable audio conferencing platform
as well, with the ability to scale to hundreds of
participants in a single meeting. CMS conference
resources use a combination of SIP and HTTPS to set up
conference calls. Unified CM uses HTTPS signaling to
dynamically create a new conference as needed and then
directs calls into that conference by using SIP. Because of
the dual nature of the signaling required, you will see
that the configuration requires the configuration of both.
Before you can configure CMS as a conference resource,

you must first create a SIP trunk from Unified CM to the
CMS server or servers. For details on how to configure a
SIP trunk, refer to Chapter 5, “Unified CM SIP Trunk
Configuration.” After you have created the SIP trunk, you
can add a new conference resource from the Unified CM
Administration > Media Resources > Conference Bridge
by adding a new device and selecting the type of CMS
server.
Figure 6-3 shows the configuration of a CMS server as a

conference bridge resource.
Figure 6-3 Cisco Meeting Server as a Conference
Resource in Unified CM
The name specified is arbitrary and just for your

information. You must also select the SIP trunk you
created that points to the CMS server or servers. By
default, Unified CM assumes that the IP addresses
configured on the SIP trunk are the same ones that
should be used for the HTTPS signaling. If you want to
override this, select the Override SIP Trunk Destination
as HTTPS Address checkbox, and then you can add one
or more IP addresses to use for the HTTPS signaling.
In the HTTPS Interface Info section, you must specify a

username and password that you have configured on the
CMS server that has API access. Also ensure that the
HTTPS port matches your CMS server (which is typically
port 8443).
Note
Unified CM always uses an encrypted HTTPS connection to communicate with
CMS; therefore, Unified CM must properly trust the certificate presented by
CMS when connecting. Unified CM must have certificates for all the CMS
cluster servers present in the CallManager trust store. This is important!
The final parameter that we have not discussed is the

Conference Bridge Prefix parameter. When Unified CM
creates a dynamic conference for an ad hoc call, it picks a
long random number for the call. You can choose to
prefix that number with a set of digits you configure in
the Conference Bridge Prefix parameter to ensure that
conferences created by this cluster never overlap with
other parts of your dial plan or other Unified CM
clusters. This is useful when you have more than one
cluster configured to use the same CMS cluster for ad
hoc conferencing. Just make sure you specify a unique
prefix for each cluster.
Once you have added CMS as a conference resource,

Unified CM can use it when a user invokes an ad hoc or
Meet-Me conference from a phone. As before, the device
pool determines the region configuration for calls to this
media resource, but in this case, it is the region of the
SIP trunk that matters.
A variety of service parameters allow you to customize

conference-related features at a global level. If you
navigate to Unified CM Administration > System >
Service Parameters and select the Cisco CallManager
service, you see a section named Clusterwide Parameters
(Feature - Conference). Figure 6-4 shows the options
available on this page.
Figure 6-4 Conference Configuration Parameters in

Unified CM
Table 6-2 describes the important parameters in this
section. Several parameters are omitted from this table
because they are not important to the discussion in this
chapter.
Table 6-2 Conference Configuration Parameter Details

Once you have configured ad hoc conference resources
on a cluster, you can invoke an ad hoc conference in a
variety of ways, depending on the endpoint you are
using. On IP phones, while on a call, you press the
Conference button or soft key, call a third participant,
and then press the Conference button or softkey again to
create the conference. At that point, Unified CM selects a
conference resource based on the capabilities of the
participants and connects the three parties to the
conference resource. You can also use the Join feature to
join active calls together into an ad hoc conference.
Similarly, in Cisco Jabber or Cisco Webex Teams, you
use the Merge button to merge two existing calls into a
conference. Regardless of how you invoke the feature, in
the end, you have three or more participants in a call.
You can then continue to add additional participants,
one at a time. If at any point the number of participants
drops to two, the conference resource is de-allocated,
and the remaining two parties are connected directly to
each other, thereby freeing up your conference resource.
Later in this chapter, you will see how media resource

groups and media resource group lists can be used to
determine which conference resources are used. By
default, all configured resources are in a default group,
which is reachable by all devices configured on the
cluster, so even with no media resource groups
configured, ad hoc conferencing works.
Meet-Me conferencing uses the same media resources

configured for ad hoc conferencing but allows users to
dial in to a meeting number instead of requiring a user to
add each person to the conference. There is also a newer
feature that is similar to Meet-Me called Conference
Now, which enhances the original Meet-Me feature.
What makes a Meet-Me conference unique is that it must
be initiated from a phone by using the Meet-Me softkey
or button. By default, most phones do not display the
Meet-Me button or softkey, so it must be added to either
the softkey template for the phone or added as feature
button on the display of the phone where you want to
enable Meet-Me. You must also designate phone
numbers as Meet-Me conference numbers. You can
configure Meet-Me numbers from the Unified CM
Administration > Call Routing > Meet-Me
Number/Pattern configuration menu. Figure 6-5 shows
the configuration of a Meet-Me number range.
Figure 6-5 Meet-Me Pattern Configuration
A Meet-Me conference can be configured as either a

single directory number or a pattern, as shown in Figure
6-5. In this example, the numbers 80010000 through
80010009 are available for Meet-Me conferences. Once a
Meet-Me number has been configured, it is available to
anyone whose calling search space allows them to reach
the pattern, based on the partition in which you have
placed the Meet-Me pattern. If you want these numbers
to be reachable from the PSTN, you must ensure that the
appropriate call routing is in place so that calls from the
PSTN can reach these directory numbers, just as you
would for any other phone line.
Once the Meet-Me pattern is configured and conference
resources are available, a user initiates a Meet-Me
conference by pressing the Meet-Me button or softkey
and then dialing an available Meet-Me number. This
feature is relatively primitive, and there is no way to
schedule or check to see if someone else is using a given
Meet-Me number. However, if a user presses the Meet-
Me softkey and dials a number that is already being used
for a Meet-Me call, the user hears a reorder tone.
Once a user has activated a Meet-Me conference using

the Meet-Me softkey, other users can dial in to the
meeting by simply dialing the phone number. They must
do this without pressing the Meet-Me softkey. If
someone dials the Meet-Me number before someone has
used the Meet-Me key to start the meeting, callers simply
get a reorder tone. Once a conference is started, it
remains active until all participants have left the
conference. When the conference has ended, the number
is once again available for someone to initiate a Meet-Me
conference using the Meet-Me softkey.
Unified CM Version 11 added a new feature that is an

extension of this feature to make it more scalable and
easier to use called the Conference Now feature.
Conference Now requires that the host and meeting
participants dial in to a single phone number, which is
answered by an IVR system. The IVR system prompts
the user for a meeting ID and a PIN. A Conference Now
meeting must be started by a meeting host before
participants can talk to each other; attendees who join
before the meeting host joins hear hold music instead
getting a reorder tone, as with the Meet-Me feature.
Enabling Conference Now is a multistep process. The

first step is to ensure that there are conference media
resources available. You must also have an IVR resource
available. IVR resources can be provided by the IP Voice
Media Streaming App service discussed earlier in this
chapter, so if the service has been activated and started,
it should be available. You can verify that the IVR is
available by navigating to Unified CM Administration >
Media Resources > Interactive Voice Response (IVR).
Figure 6-6 shows an example in which two IVR resources
are registered.
Figure 6-6 IVR Resources Registered in Unified CM

Administration
As with the other media resources we have discussed,

you can configure the device pool on these resources to
control which Unified CM they register to, and you can
also control the region for codec selection. IVR supports
G.711, G.729, and Wideband 256k codecs.
Note
One important note about IVR is that it only supports out-of-band (OOB) DTMF
relay. In other words, it does not support in-band DTMF, such as RFC
2833/4733 (RTP-NTE). This means that if you have a device dialing in that
supports only in-band DTMF, a media termination point (MTP) is needed to
convert from in-band to out-of-band DTMF. For more information about DTMF,
review Chapter 3, “RTP, RTCP, and DTMF Relay.”
When you have conference and IVR media resources

registered, there are several steps needed to configure
the Conference Now feature. This feature is strongly tied
to individual end users, so most of the configuration is
actually performed on the end-user configuration, but
the first step is to configure the directory number for the
Conference Now IVR resource. This is done by
> Conference Now. Figure 6-7 shows the configuration
parameters for Conference Now.
Figure 6-7 Conference Now IVR Configuration
The first parameters you must configure are the directory

number and partition for the number that users will dial
to join a conference. You can make this number a DID so
that it is reachable from the PSTN as well as by internal
users. The only two other parameters are Maximum Wait
Time for Host Unit Participant Is Disconnected, which
specifies how long a participant can be placed on hold
while waiting for the host to join, and MOH Source
While Participant Is Waiting. These parameters are all
global. You can only have a single IVR number, and all
participants must hear the same MOH source while on
hold. If for some reason you would like multiple PSTN
numbers to be able to reach the IVR resource (for
example, if you have gateways in several countries and
you want to provide international numbers to dial in),
you can use translation patterns to translate any number
of phone numbers to the IVR number and thereby
provide multiple dial-in numbers.
Once the IVR number is configured, the only remaining

step is to enable end users for the Conference Now
feature. The Conference Now feature relies on two pieces
of configuration that are not specific to the Conference
Now feature: the user’s PIN and the primary extension.
Both of these must be configured for the Conference Now
feature to work and can be found by navigating to
Unified CM Administration > User Management > End
User. The primary extension will become the user’s
meeting number, and the PIN will be required for the
host to start the meeting. In addition to these
parameters, there is some Conference Now–specific
configuration as well. Figure 6-8 shows the Conference
Now Information section of the end-user configuration
page.
Figure 6-8 Conference Now Configuration on the End-

User Page
To enable a user for the Conference Now feature, select

the Enable End User to Host Conference Now checkbox.
When the configuration is saved, the Meeting Number
field populates with the primary extension for the user.
You may optionally add an attendee access code, which
will be required for attendees (not the host) to join the
meeting. Even with the attendee access code, the meeting
does not start until the host joins and enters their
personal PIN.
When the Conference Now configuration is complete, the

process of joining a Conference Now meeting is easy:
Step 1. Both attendees and the host dial the IVR

directory number and are prompted for the
meeting ID. The meeting ID is the primary
extension of the user whose meeting they
want to join.
Step 2. The IVR system prompts the user to enter

the host PIN if the user is the host or just
press the pound (#) key if the user is not the
host.
Step 3. If the host enters the correct PIN, the

meeting is started. If an attendee is joining
and presses pound, that user might be
prompted for the attendee access code, if one
is configured.
MUSIC ON HOLD (MOH)
Music on Hold (MOH) enables callers to hear music
or announcements when they are placed on hold. It is
also used for features such as Conference Now and call
queuing (discussed in Chapter 4, “Unified CM Call
Routing and Digit Manipulation”). As mentioned earlier,
MOH is provided by the IP Voice Media Streaming App
service. Up to this point, we have not discussed the
scalability and capacity of this service. By default, the
service provides up to 48 streams each for software
conferencing, annunciator, IVR, and MTP. These settings
are all configured in the service parameters for the IP
Voice Media Streaming App service, which can be
accessed by navigating to Unified CM Administration >
System > Service Parameters > Server > Select IP Voice
Media Streaming App. Figure 6-9 shows the parameters
available on this page.
Figure 6-9 IP Voice Media Streaming App Service

Parameters
You can see that the top half of the page lets you specify a
run flag and call count for each media resource provided
by the IP Voice Media Streaming App service, with the
exception of MOH. However, the bottom of the page
provides MOH-related configuration settings. The Run
Flag allows you to disable a specific media resource if you
do not want to use it. For example, if you are going to use
hardware or external conference resources, you might
want to disable the conference bridge capability.
The Supported MOH Codecs parameter allows you to

specify which codecs the server should natively stream
for MOH. By default, only G.711ulaw is supported. You
can multi-select all four options (711 mulaw, 711 alaw,
729 Annex A, and Wideband) if you want to support all
four. Note that the wideband option doesn’t appear
unless you scroll down to see it.
So where do you configure the run flag and stream count

for MOH? These settings are located on a separate
configuration page dedicated to the configuration of the
MOH resources. As with other media resources, the
MOH server registers with Unified CM with by using
SCCP and is configured by default when a server is added
to the cluster. The Music on Hold service is configured
from Unified CM Administration > Media Resources >
Music On Hold Server. Figure 6-10 shows the
configuration page for an MOH server.
Figure 6-10 Music on Hold Server Configuration
As with the other media resources, you can configure a

device pool and location to indicate to the MOH server
which server in the Unified CM cluster to register to and
also control the region’s configuration. You can also
specify a location for call admission control purposes.
You can see that the equivalent of the Call Count setting
available for other resources is available here, with the
parameter Maximum Half Duplex Streams. By default,
Unified CM supports 250 streams. The settings for MOH
as well as the other services can be increased on servers
that are dedicated to providing these services. (For
guidance on the maximum number of streams supported
for each platform, please consult the Unified CM
documentation for MOH.) This configuration page also
has a Run Flag setting, which allows you to disable MOH
on a specific server, if you so desire.
The MOH service supports both unicast and multicast

streams. For unicast, each participant on hold has a
unique media stream from the MOH server to the party
hearing the hold music; for multicast, the server only
ever sends a single stream continuously, and then end
devices are instructed to join the multicast group to hear
the stream. Multicast MOH is far more scalable but
requires the network to be multicast enabled between the
MOH server and any client that may be placed on hold.
The most common deployment model is unicast MOH.
If deploying multicast MOH, you should understand how

the base multicast address works. As we will discuss in a
moment, you can have up to 501 MOH audio sources
configured. Each audio source can have up to 4 codecs
configured (depending on the setting in the service
parameter discussed previously). If you set Increment
Multi-cast On to IP Address, Unified CM starts with the
Base Multi-cast IP Address value and increments the IP
address for each source and codec, potentially using up
to 2004 multicast IP addresses. If you chose to
increment based on port number, the same IP address is
used, and only the port number is incremented; however,
you should use this option with caution because
multicast networks either allow or deny traffic based on a
multicast IP address, so any phone that gets placed on
hold receives all the multicast MOH streams being sent
to the multicast IP address, even if they are on different
port numbers. Incrementing on IP address is the
preferred method if you are going to use multicast. Table
6-3 shows the difference between incrementing by IP
address and by port number when the base address is
configured as 239.1.1.1 and the port number is
configured as 16384 on a server with all four codecs
enabled for MOH and two audio sources.
Table 6-3 Example of the Differences Between

Incrementing Multicast on IP Address and Incrementing
Multicast on Port Number
Once you have configured the MOH server, you can add
audio sources. By default, Unified CM comes with a
single audio source, named SampleAudioSource, which
is assigned the source ID 1. Each MOH audio source is
assigned a number from 1 through 501. Number 51 is
special in that it is reserved for a fixed audio source;
however, this source has not been usable since Unified
CM moved to VMware, which does not have an easy way
to connect USB devices to a virtual machine. When this
source was available, a USB sound card could be used as
an input to stream live audio from an external source.
Streaming a live audio source today requires an external
music streaming device that can be rebroadcast, as
discussed shortly.
Note
SampleAudioSource is a recording of a song named Opus No. 1 written and
recorded by high-school friends Tim Carleton and Darrick Deel long before IP
phones existed. Some consider it to be the most played song ever and
certainly the most known Music on Hold track. Various articles talk about the
history of this song, and an episode of This American Life (Episode 516,
January 17, 2014) goes into the history of the song.
To add a new audio source or modify an existing one,

navigate to Unified CM Administration > Media
Resources > Music On Hold Audio Source. Figure 6-11
shows the configuration page for a Music on Hold audio
source.
Figure 6-11 Music on Hold Audio Source Configuration
You must select an audio source ID from 1 to 501. You

will notice that 51 is missing from the list because it is
dedicated to the fixed source, as mentioned earlier. You
use this source ID in various parts of the Unified CM
configuration to select the audio source. On this page,
you can either choose an audio file from one of the files
already uploaded or you can upload one by clicking the
Upload File button at the top or bottom of the page. You
can also upload and manage uploaded files from the
Unified CM Administration > Media Resources > MOH
File Management menu. Instead of using a static file, you
can choose to rebroadcast an external multicast source.
The primary use case for this option is to use an external
streaming device connected to a live audio source that is
configured to stream to the network on a multicast IP
address. Unified CM is then configured to listen to this
multicast group as the source and rebroadcast that
source as needed to unicast or multicast destinations, as
it would stream any other prerecorded file. Figure 6-12
highlights how this works with Unified CM.
Figure 6-12 Music on Hold Multicast Rebroadcasting
Note
Cisco Unified Border Element (CUBE) can also perform multicast-to-unicast
MOH interworking for calls involving service providers over public networks.
This process is detailed in Chapter 9, “CUBE Interworking Features.”
The MOH audio source configuration also allows you to

configure initial and periodic announcements that are
played at the beginning and at regular intervals while a
call is on hold. The option Initial Announcement for
Queuing-Enabled Hunt Pilot Calls indicates whether the
initial announcement is played even when the call is not
going to be placed on hold because a member is
available.
When your audio sources are configured, you can decide

which sources are played when a user places a call on
hold. You should understand two basic types of hold:
• User hold: With a user hold, a user presses the

Hold button on a phone to explicitly place the caller
on hold. If Phone A and Phone B are having a
conversation, and the user of Phone B presses the
Hold button, Phone B’s user hold source is
streamed to Phone A.
• Network hold: A network hold occurs when a

call is placed on hold as part of the processing of a
supplementary service, such as park, transfer, or
conference. If Phone B presses the Transfer button
to transfer a call, Phone A still gets placed on hold
but hears Phone B’s network audio source while the
rest of the transfer operations complete.
The network and user audio sources can be configured in

a variety of locations in the Unified CM Administration
user interface. The various configuration options allow
you to configure audio sources at various levels of
granularity. The least-granular configuration is with a
pair of service parameters found by navigating to Unified
CM Administration > System > Service Parameters >
Server > Cisco CallManager. In the Service section of the
service parameters page are two parameters, Default
Network Hold MOH Audio Source ID and Default User
Hold MOH Audio Source ID, that each take an integer
value from 1 to 501 to indicate the default audio source.
If this value is not overridden on any of the more
granular configuration options, this is the audio source
callers hear.
The next place the audio sources can be configured is
under the Common Device Configuration. You can find
this by navigating to Unified CM Administration >
Device > Device Settings > Common Device
Configuration. This configuration page has options that
allow you to select both the user and network MOH
audio sources. You can then apply this common device
configuration to groups of devices. If a phone has a
common device configuration selected that has audio
sources configured, they override the global service
parameter.
You can also configure a specific user and network hold

source on a device. Such settings override the global
and/or common device configuration settings. The final
location where the audio sources can be configured is on
an individual line. The line setting overrides any of the
other settings. This means that you can have different
hold music played for calls to the same phone, depending
on which line the call comes in on.
Note
Note that the audio source setting determines which file or rebroadcast a user
hears, but it does not determine which MOH server plays the audio. The
determination of which MOH server is used is determined by the configuration
of the media resource group list associated with the held party.
MEDIA RESOURCE GROUPS AND

MEDIA RESOURCE GROUP LISTS
Two configuration elements control access to media
resources: media resource groups (MRGs) and
media resource group lists (MRGLs). These work
similarly to route groups and route lists, covered in
Chapter 4. All media resources—MOH servers,
annunciators, IVRs, conference resources, media
termination points, and transcoders—can be placed into
media resource groups.
By default, there are no media resource groups
configured in Unified CM. Any media resource that is not
in a media resource group is placed into what is known
as the default group. There is no way to see this group or
the devices that are in the default group other than by
looking at SDL trace files, but if a media resource does
not appear in any MRG, it is in the default group. This
means that, by default, all devices registered to a cluster
have access to all media resources because all media
resources are in the default group by default. The
moment a media resource is added to an MRG, it is
removed from the default group, even if the group has
not been assigned to a media resource group list.
Media resource groups are unordered lists of media

resources, which means all resources in a group are
considered equivalent. Generally speaking, Unified CM
uses the resource in the MRG that has the most available
resources. For example, if two MOH servers are available
and both support 250 streams and one server has 1 call
on hold, the next call that gets placed on hold uses the
other server. Media resources within an MRG are
distributed evenly. Figure 6-13 shows the configuration
of an MRG that contains all the available media
resources.
Figure 6-13 Media Resource Group Configuration

A media resource can appear in multiple media resource
groups. One common practice is to add all media
resources on a cluster to a media resource group named
something like Catch All. This group is not assigned to
any media resource group lists, but it ensures that no
devices exist in the default group. This is done to reduce
the potential for media resources from different
geographical regions or sites being allocated from the
default list. The last thing you want to do is have a call
from North Carolina to San Jose using a media resource
registered in Brussels, which could introduce delay,
jitter, and other quality impairments to the media
stream. Because media resources can appear in multiple
groups, you can add these same resources to other
groups, as needed to ensure they are being allocated
properly.
Once you have assigned media resources to MRGs, you

can add the MRGs to media resource group lists. MRGLs
are ordered lists of MRGs. In other words, all resources
in the highest MRG on the list are used before
attempting to use the resource of a subsequent MRG.
There are some exceptions to this rule, depending on the
parameters set for conferencing, where audio resources
may be prioritized over video resources if the number of
video participants is below the configured threshold or if
you have configured parameters to prefer encrypted
audio over video calls. One other caveat to note is that
Unified CM uses transcoders as media termination
points (but cannot use media termination points as
transcoders), so it is highly recommended to put
transcoding resources in a separate MRG with a lower
priority than software MTP resources so that you do not
waste transcoding resources (which require expensive
hardware DSPs) as MTPs unless absolutely necessary.
Once you have added MRGs to MRGLs, you must assign

the MRGLs to devices. Just as with the MOH
configuration, there are a variety of places where you can
configure an MRGL. The least granular configuration is
on the device pool. Each device pool has a setting for
MRGLs that applies to all devices in the device pool. If
you want to override this setting, you can do so on the
device. Note that unlike with calling search spaces, when
an MRGL is configured on a device, it overrides the
device pool configuration; it does not add the two. This
means that you could inadvertently remove media
resources from a device when you add an MRGL if you
are not careful to ensure that the MRGL configured has
access to all the resources already available on the device
pool MRGL.
When it comes to selecting a media resource, the MRGL

used depends on the feature. For example, for MOH, the
MRGL used is that of the held party as it is the device
that is being connected to the media resource. In the case
of conferencing, the MRGL used is that of the conference
creator (that is, the user pressing the Conference softkey
to start an ad hoc conference or the user starting a Meet-
Me conference by pressing the Meet-Me softkey). In the
case of annunciators and IVR resources, it is the MRGL
of the user dialing in to the IVR system or the device
where the announcement is being played. MTPs and
transcoders are generally allocated based on the MRGL
of the device needing the resource (for example, if a SIP
trunk needs an MTP to support a feature such as early
offer).
CALL PARK
The call park feature is similar to call hold in that it
allows you to place a caller on hold temporarily and then
resume the call at a later time. The difference is that call
park allows you to resume the call on a different phone
or line than the line that originally parked the call. This
can be useful, for example, in environments where
overhead paging systems are used to announce the
presence of a call and anyone who hears the
announcement can choose to retrieve the parked call.
When a call is parked, it is associated with a call park

number that can be dialed from any phone that has
access to the park pattern (via its calling search space) to
retrieve the call. You must first configure the range of
numbers that can be used for parking the call. This is
done from Unified CM Administration > Call Routing >
Call Park. Figure 6-14 shows the configuration for a call
park range.
Figure 6-14 Call Park Configuration
A call park range can have up to two Xs in the pattern

(for example, 20XX), so a park range can support up to
100 parked calls. If you need to be able to support more
parked calls, you just need to add more park ranges. The
partition is important because it determines which park
range will be used to park the call as well as who can
retrieve the calls parked in this range. In deployments
that involve multiple sites, it is typical to have separate
park ranges (in separate partitions) for each site since
retrieving a parked call across sites is not a typical use
case; however, if this is something that is important to
your deployment, you can do so. In fact, parked calls can
even be retrieved from a different cluster or even from
the PSTN, as long as they have access to dial the park
number based on the calling search space of the calling
device.
The last parameter, Cisco Unified Communications
Manager, is a bit unusual for a pattern like this. For this
parameter, you select a server in the cluster to associate
with this call park range. By default, you must configure
non-overlapping call park ranges for each server in your
Unified CM cluster where devices might need to park a
call. If a phone is registered to a server in the cluster that
does not have a call park range configured (that the
phone can reach via its calling search space), the call
park operation fails. This behavior can be modified, and
there is a service parameter that controls the behavior.
To change this parameter, navigate to Unified CM
Administration > System > Service Parameters > Server
> Cisco CallManager and click the Advanced button. If
you change the setting for Enable Clusterwide CallPark
Number/Ranges to True, the Cisco Unified
Communications Manager setting on the call park range
becomes irrelevant, and all configured park numbers can
be used by devices registered to any server in the cluster.
At some point in the future, this may become the default
configuration, and the setting to tie the park range to a
specific server will be removed.
While we are on the topic of service parameters, it helps

to go through all the call park–related service parameters
available (see Figure 6-15).
Figure 6-15 Call Park Service Parameters
Most of the parameters are timers that control how the

call park feature works. To understand these timers, you
must first understand some fundamentals of call park,
such as how it works:
Step 1. A user parks a call by pressing the Call Park

softkey or button on his or her phone.
Step 2. Unified CM automatically selects an

available park number from the configured
park ranges and displays a message on the
phone indicating the number where the call is
parked.
Step 3. The party that gets parked starts hearing

hold music. The Music on Hold source
selected is the network MOH source for the
line that parked the call.
Step 4. Anyone with the correct calling search space

that can reach the number range from where
the call park number was selected can dial
that number and retrieve the parked call. The
service parameter Call Park Display Timer
determines how long the message stays on
the phone indicating the park number.
Once a call is parked, a timer is started. If no one picks

up the parked call within the allotted time, a call park
reversion occurs. The timer that governs this is called
the Call Park Reversion timer, and it is set to 60 seconds
by default. After this timer expires, the call rings the
phone that parked the call, and the parked party stops
hearing music on hold and hears ringback instead.
Administrators can change this timer to extend the
amount of time a call can remain parked. One challenge
with call park reversion is that when the call reverts back
to the party that parked the call, the call behaves like a
new call coming into that phone. This means that if the
phone is busy, the Call Forward Busy treatment is
followed, and if the call is not answered, the Call Forward
No Answer treatment is applied.
Some phones support an additional feature call park
monitoring. This feature is generally available only on
newer SIP phones with larger displays, such as the Cisco
8800 Series and 9900 Series phones. On phones that
support park monitoring, the user has an enhanced
experience when parking a call. Instead of just displaying
the number where the call is parked for just a few
seconds, the phone shows the call being parked until
someone retrieves the parked call. At any point, the user
who parked the call can just press one button to retrieve
the parked call without having to dial the park number.
Also, the phone continuously displays the number where
the call is parked.
There are three parameters that affect the behavior of

call park on phones that support park monitoring. The
Park Monitoring Reversion timer behaves like the Call
Park Reversion timer. After the Park Monitoring
Reversion timer expires, the phone that parked the call
rings, but the parked party continues to hear the hold
music. The phone that parked the call at this point can
choose to ignore the park reversion. From this point
onward, at intervals dictated by the Park Monitoring
Periodic Reversion timer, the phone that parked the call
rings again until the call is retrieved from park. By
default this is every 30 seconds. If no additional
configuration is done, this goes on indefinitely. However,
one additional timer can be enforced: the Park
Monitoring Forward No Retrieve timer. This timer
determines how long the call continues trying periodic
reversion indications until a forwarding behavior is
taken.
The park monitoring forwarding, when not retrieved, is

determined by the configuration on each individual line.
Figure 6-16 shows the park monitoring configuration on
a directory number.
Figure 6-16 Park Monitoring Configuration on a Line
Note that although this configuration appears on all

lines, it only applies to phones that support park
monitoring. You can configure park monitoring
forwarding on no retrieve to behave differently
depending on whether the call that is parked is an
internal call or an external call. External calls are any
calls on devices that are marked as off-net devices. You
can also configure the Park Monitoring Reversion timer
for a line that overrides the global service parameter.
There is an additional variation of call parked called

directed call park. Whereas standard call park allows
Unified CM to select the park number automatically,
directed call park allows a user to park a call at a specific
phone number by transferring the call to a directed call
park number. The user experience with directed call park
is different. Instead of using the Park softkey or button,
the user simply performs a standard call transfer as if
transferring the call to another extension, but instead of
dialing another extension, the user dials the directed call
park number. The user needs to know the directed call
park number beforehand.
The directed call park feature is usually deployed

alongside a busy lamp field (BLF) for directed call park.
When a BLF for directed call park is configured, a button
appears on a phone that lights up any time a call is
parked on that call park slot. This BLF can appear on
many phones, and users who see a call parked on that
slot can simply press the button to retrieve the parked
call without having to call a number to retrieve the call.
Directed call park behaves slightly differently than
standard call park in that a prefix is needed to retrieve
the parked call. The best way to understand this is to
look at the configuration for a directed call park number.
To configure a directed call park number, navigate to
Unified CM Administration > Call Routing > Directed
Call Park. Figure 6-17 shows the configuration options
for a directed call park number in the first box. The
second box shows the configuration of a directed call
park BLF added to an IP phone’s second button; this is
accomplished by navigating to Unified CM
Administration > Device > Phone. If the phone button
template does not contain a BLF Directed Call Park
button, the parameter Add a New BLF Directed Call Park
is part of the Unassigned Associated Items section of the
line association configuration. You can use the Modify
Button Items button at the top of the line association
section to add the BLF directed call park option to the
phone button of choice and then select Add a New BLF
Directed Call Park to associate the call park number to
the button.
Figure 6-17 Directed Call Park Number Configuration
The first major difference between the configuration for

directed call park and standard call park is that the
directed call park configuration requires a specific
number to be configured. It cannot be a range specified
using a wildcard; each directed call park number must be
configured individually. As with any other pattern, you
must select a partition to place the number in and ensure
that it is reachable from any calling search space that
needs to be able to park or retrieve a call to this park
number.
The Reversion Number and Reversion Calling Search

Space parameters specify what happens to a call parked
on the directed call park number after the reversion
timer expires. Unified CM attempts to revert the call
back to the number provided and use the configured
calling search space to search for a match.
The Retrieval Prefix parameter specifies a digit or set of

digits that must be prefixed to the directed call park
number to retrieve the call. In the example shown in
Figure 6-17, a user would transfer a call to the number
3001 to park it but would have to dial *3001 to retrieve
the parked call. Phones configured with a BLF for
directed call park automatically dial the prefix when the
button is pressed to retrieve the call parked on that BLF.
CALL PICKUP
Some commonly used call control features are the
various call pickup features available in Unified CM.
All of these features involve something called a pickup
group. A pickup group is assigned a directory number
that exists in a partition, like any other directory
number. Phone lines in Unified CM can be placed into a
single pickup group (or no pickup group at all). The call
pickup feature generally allows phones to answer calls
that are ringing on a different phone. There are four
variations of call pickup:
• Call pickup: This type of call pickup allows a user
in a pickup group to answer a call ringing on
another phone in the same pickup group by
pressing the Pickup button or softkey.
• Group call pickup: A group call pickup allows

a user to answer a call ringing on a phone in a
different pickup group by pressing the Group
Pickup button or softkey and then dialing the
pickup group number where a phone is ringing. The
caller must have access to the partition for the
directory number of the pickup group where the
phone is ringing.
• Other call pickup: An other call pickup allows

administrators to associate multiple pickup groups
so that a caller can answer a call ringing on a
pickup group other than the pickup group of the
phone without having to enter the pickup group
number.
• Directed call pickup: A directed call pickup

is similar to group call pickup in that it allows a
user to answer a call ringing on another phone by
pressing the Group Pickup softkey but instead of
dialing the pickup group number, the user dials the
extension of the phone that is ringing. In order for a
user to have permissions to do a directed call
pickup, the pickup group configured on the line of
the user attempting to perform the directed call
pickup must be associated with the pickup group of
the phone that is ringing.
For all four variations of call pickup, the first

configuration step is always to configure pickup groups.
This can be done by navigating to Unified CM
Administration > Call Routing > Call Pickup Group.
Figure 6-18 shows the configuration of a pickup group.
Figure 6-18 Pickup Group Configuration
A pickup group is given a name, a directory number, and

a partition. To pick up a call, you must ensure that the
calling search spaces of the devices performing the
pickup contain this partition. The Call Pickup Group
Notification Settings section determines whether other
phones in the pickup group get any kind of notification
any time a phone in the group is ringing. For example, if
lines 1001, 1002, and 1003 are all assigned pickup group
6001, if the pickup group is configured for a visual alert
notification policy and someone calls extension 1001, the
phones with extensions 1002 and 1003 configured
receive a visual alert indicating that extension 1001 is
ringing. The administrator can decide whether the
notification includes calling party information, called
party information, or both.
The bottom section of the call pickup configuration page

is for the other call pickup and directed call pickup
features. You can associate any number of pickup groups
with the group you are configuring. Note that the
association is not automatically bidirectional. In this
example, pickup group 6001 is associated with pickup
group 6002, which allows members of pickup group
6001 to use the other pickup key to answer calls ringing
on phones in pickup group 6002, but this does not mean
that lines associated with pickup group 6002 can answer
calls ringing on phones in pickup group 6001. If the
desired behavior is for lines in pickup group 6002 to
answer calls ringing on 6001 as well, the association
must be configured explicitly on pickup group 6002.
By default, when the pickup feature is invoked, a call that

was ringing on another phone starts ringing on the
phone that invoked pickup. At that point, the call must
still be answered like any other inbound call. There is a
service parameter that modifies this behavior. If you
navigate to Unified CM Administration > System >
Service Parameters > Select a Server > Cisco
CallManager and find the Feature - Call Pickup section,
you can look for the parameter named Auto Call Pickup
Enabled. If you set this parameter to True, instead of
ringing the phone that invoked a pickup feature, the call
is automatically answered instead.
If auto pickup is not enabled, there is one other timer

that applies: the Call Pickup No Answer timer. If a user
invokes pickup and the phone starts ringing, if the user
does not actually answer the call in the time determined
by the Call Pickup No Answer timer, the call goes back to
ringing the original phone that was called.
The call pickup feature can also be used in conjunction

with the BLF speed dial feature, which enables a user to
monitor the state of another phone extension. When the
monitored extension is in use, the BLF speed dial button
on a phone lights up to indicate that the line is in use.
However, there is an additional checkbox available when
configuring a BLF speed dial: Call Pickup. If this
checkbox is selected, not only does the BLF speed dial
light up when the line is in use, it also flashes if the line is
ringing; pressing the BLF Speed Dial button while in this
state performs a call pickup.
REGIONS AND CODEC PREFERENCES

Unified CM not only routes a call between two devices
but also exchanges media information between the two
devices so that they can communicate. Voice and video
over IP use a variety of different codecs to encode audio
and video data over an IP network. Most devices support
a variety of different audio and video codecs and
generally advertise those capabilities to Unified CM
when placing a call. Based on administrator
configuration, Unified CM can filter or reorder the list of
capabilities advertised by a device to enforce specific
codecs, as determined by the administrator. This could
be done to ensure that codecs that only consume a
specific amount of bandwidth are used or perhaps to
prefer higher-fidelity codecs or codecs that tolerate
packet loss better than others. The two features Unified
CM offers to control these aspects of codec selection and
media negotiation are regions and the audio codec
preference list.
Regions
A region is a grouping of devices that are equivalent
from a codec selection perspective. You expect all devices
in a region to have a policy for which codecs to use when
communicating with each other and a different policy for
communicating with other regions. In a simple multi-
region configuration, you only care about the generic
case of one region talking to any other region, and you
can build a simple matrix to highlight the full mesh of
settings between regions. For example, given four
regions—Region A, Region B, Region C, and Region D—
you could build the matrix shown in Table 6-4.
Table 6-4 Conference Configuration Parameter Details
Region pairings are bidirectional, so the setting that

defines the policy for Region A to Region B is the same as
the setting that defines the policy for Region B to Region
A. As a result, the redundant policies are blacked out in
the table. Communication between two devices in the
same region are considered intraregion calls. Unified CM
allows administrators to define each pairing between
regions, but for most configurations, administrators only
care about having a single policy for intraregion calls and
a different policy for interregion calls, regardless of
which regions are involved. Unified CM facilitates this
type of configuration while also allowing for exceptions
on an as-needed basis. Figure 6-19 visually depicts what
this would look like.
Figure 6-19 Codec Selection Between Four Regions
Figure 6-19 shows how calls between phones inside a

region are configured to use the G.722 codec, while calls
between regions are configured to use G.729. That said,
this description is actually not completely technically
accurate. When you configure a codec between two
regions, you are not configuring a codec at all. You are
actually configuring the maximum amount of bandwidth
you would like Unified CM to allow for calls between the
two devices. This means that if you select G.722, you are
really saying that you want audio calls to consume no
more than 64 kbps of bandwidth (before the overhead
associated with L4/L3/L2 headers). To determine which
codec is actually used, Unified CM makes a decision
based on the capabilities advertised by each of the
endpoints involved in the call, as well as the preference
order defined in the audio codec preference list.
Audio Codec Preference Lists
An audio codec preference list allows you to specify

the relative priority of one audio codec over another.
This means that you can prefer a lower-bandwidth codec
such as G.729 over a higher-bandwidth codec such as
G.711μ-law, for example. So if a region is configured to
allow calls with up to 64 kbps of bandwidth, if G.729
appears higher in the audio codec preference list, G.729
is used even though the region allows for enough
bandwidth for a G.711 call. Audio codec preference lists
are configured by navigating to Unified CM
Administration > System > Region Information > Audio
Codec Preference List. Unified CM comes with two lists
by default: the factory default lossy and factory default
low loss lists. The factory default lossy list prioritizes
codecs that are designed to deal with packet loss better
than other codecs, even if the overall quality is not as
high; the factory default low loss list prioritizes the
highest-fidelity codecs, even if they behave poorly when
there is packet loss. Figure 6-20 shows an example of the
factory default lossy preference list.
Figure 6-20 Factory Default Lossy Audio Codec

Preference List
The first important note about audio codec preference

lists is that you cannot add or remove codecs from the
list. The codecs on the list come preinstalled with Unified
CM and cannot be changed. This means that to support a
new audio codec, Unified CM must be upgraded.
Fortunately, new audio codecs don’t come along very
often. The factory default lists cannot be modified. If you
want to make a change, you must click the Copy button
to copy one of the factory default lists and then reorder
the codecs as you like.
You can see in the list that each codec has an amount of
bandwidth associated with the codec. A few codecs are
variable-rate codecs. In the case of variable-rate codecs,
such as Opus, Unified CM attempts to negotiate the
highest rate possible, based on the region configuration.
Just because the Opus codec can go as high as 510 kbps
does not exclude it from being advertised if the region
pairing only allows for 64 kbps of bandwidth. In this
case, Opus will be negotiated with a max bit rate of 64
kbps.
Furthermore, the region relationship between two

endpoints and the audio codec preference list are used
with call signaling to establish a session and select a
codec. Just because a region relationship is 64 kbps
doesn’t guarantee that G.722 or G.711 will be used as the
codec. Both devices involved in the call signaling must
agree on a codec that is within the bandwidth
requirements defined by the region relationship. This
could be G.729 (8 kbps) because that is the only common
codec supported by both endpoints and is less than 64
kbps. Similarly, when Unified CM makes an offer such as
a SIP early offer INVITE, it includes all available audio
codecs that meet the bandwidth requirements of the
region relationship. In this early offer scenario, the
remote endpoint can select an available codec from the
list in the offer when responding with an answer.
Configure Interregion and Intraregion Policies

Now that you understand the fundamentals of how
regions work and the concept of audio codec preference
lists, we can look at how to configure the interregion and
intraregion policies. The most basic way of configuring
region policies is through a variety of service parameters.
Navigate to Unified CM Administration > System >
Service Parameters > Server > Cisco CallManager and
find the section System - Location and Region section
(see Figure 6-21). This section has some parameters for
the locations call admission control feature as well, but
we can ignore those for now as we will come back to
them in the next section.
Figure 6-21 Location- and Region-Related Service
Parameters
Recall that there is no way to remove a codec from an

audio codec preference list. However, you can see in the
list of service parameters that there are ways to enable
and disable codecs on a global basis. There are individual
parameters for a variety of codecs, such as G.722 Codec
Enabled and Opus Codec Enabled. Each of these
parameters has three settings:
• Enabled for All Devices: All devices that

support this codec are allowed to negotiate it,
provided that the regions pairing allows it based on
the bandwidth consumed by the codec.
• Disabled: This codec is never negotiated between

devices.
• Enabled for All Devices Except Recording-

Enabled Devices: As the name implies, this is
similar to Enabled for All Devices except that if one
of the devices in the call is enabled for call
recording, this codec is not permitted. The primary
reason for this setting is that many call recording
servers don’t support more advanced codecs such
as Opus or iSAC, and negotiating one of those
codecs will cause call recording to fail.
Regions allow you to specify not only the maximum

audio bit rate for calls within and between regions but
also the maximum amount of video bandwidth allowed
for standard video calls as well as immersive
(telepresence) video calls.
If you only care to set policy for all interregion and

intraregion calls, you can do so by using the service
parameters shown previously. There are size parameters
that control the global region settings for audio, video,
and immersive calls:
• Default Intraregion Max Audio Bit Rate: This

parameter allows administrators to select the
maximum audio bit rate and, indirectly, the subset
of codecs allowed for calls between devices in the
same region. The default is 64 kbps, which means
that some of the higher bit rate codecs, such as
AAC-LD, are not negotiated by default. This
parameter lets you select from specific values that
correspond to groups of codecs. You can reference
the audio codec preference list to determine how
much bandwidth a codec consumes.
• Default Interregion Max Audio Bit Rate: This

parameter behaves the same as the Default
Intraregion Max Audio Bit Rate setting but applies
to calls between devices in different regions.
• Default Intraregion Max Bit Rate for Video

Call: This parameter allows administrators to
define the maximum amount of bandwidth to use
for video calls between devices in the same region.
As discussed later in this chapter, this can be either
the bandwidth just for the video portion of the call
or the combined session bandwidth for both audio
and video. This parameter accepts an arbitrary
integer value and represents the bitrate in kilobits
per second.
• Default Interregion Max Bit Rate for Video

Call: This parameter behaves the same as the
Default Intraregion Max Bit Rate for Video Call
setting but applies to calls between devices in
different regions.
• Default Intraregion Max Bit Rate for

Immersive Video Call: This parameter allows
administrators to define the maximum amount of
bandwidth to use for video calls between immersive
video systems. Only TX/IX Series video units (and
older CTS Series units) are considered immersive
video systems. This setting is similar to the Default
Intraregion Max Bit Rate for Video Call parameter
but defines the setting specifically for immersive
devices. It accepts an arbitrary integer value in
kilobits per second and defaults to 2000000000,
which basically means unlimited bandwidth up to
the capabilities of the device.
• Default Interregion Max Bit Rate for

Immersive Video Call: This parameter behaves
the same as the Default Intraregion Max Bit Rate
for Immersive Video Call parameter but applies to
calls between devices in different regions.
Most, if not all, video calls also have an audio channel

associated with the call. When a call is negotiated as a
video call, Unified CM can either treat the audio and
video bandwidth separately or treat the audio portion of
the call as part of the video bandwidth. In other words, if
a region is configured to allow 384 kbps of video
bandwidth, this can mean 320 kbps of video plus 64 kbps
of audio (or any other combination that adds up to 384
kbps, such as 376 kbps of video plus 8 kbps of audio), or
it can mean 384 kbps of video plus whatever is
configured for the audio bit rate between the two regions.
The setting that controls this is not shown in Figure 6-21
because it appears in a different section of the service
parameters configuration page. The parameter is called
Deduct Audio Bandwidth Portion from Audio Pool for a
Video Call and is located in the Call Admission Control
section of the service parameters page. When this
parameter is set to False, the default value, the video
bandwidth determines the overall session bandwidth
allowed, including both audio and video. If it is set to
True, the audio bandwidth is determined separately.
The final step in configuring regions is to create the

regions, add any exceptions to interregion or intraregion
settings, and assign the regions to device pools. To add
and configure a region, navigate to Unified CM
Administration > System > Region Information >
Region. Figure 6-22 shows the configuration page for a
sample region.
Figure 6-22 Region Configuration
When adding a region, the only parameter that is

required is the name. If you do not modify any of the
other settings, Unified CM uses the system default
settings for interregion and intraregion bandwidth for
audio, video, and immersive video calls. By default, the
Region Relationships section of the page does not show
any other regions because only regions where a non-
system default setting is configured are shown. For the
sake of example, we have shown a couple of settings
being overridden in Figure 6-22. In this example, Region
A is being configured to override the video call session
bandwidth within the region to 6000 kbps. You can see
that this is intraregion because this is the relationship
between Region A and itself (Region A). The example
also shows that Region A is configured to use the factory
default lossy audio codec preference list and up to 16
kbps of audio bandwidth for calls between the two
regions.
The Modify Region Relationships section of the

configuration allows you to change any of the four
settings: Audio Codec Preference List, Maximum Audio
Bit Rate, Maximum Session Bit Rate for Video Calls, and
Maximum Session Bit Rate for Immersive Video Calls.
Note that the text that appears on this page depends on
the Deduct Audio Bandwidth Portion from Audio Pool
for a Video Call setting. If that parameter is set to True,
the page shows Maximum Video Bit Rate for Video Calls
instead of Maximum Session Bit Rate for Video Calls.
For each setting, you can keep the current setting, use
the system default value, or set an explicit value. This
means you can modify one setting while keeping the
other parameters set to the system defaults.
The final configuration step is to assign the regions you

have configured to device pools and then assign those
device pools to devices. Once you have your regions
configured correctly, you might want to limit the number
of calls allowed between the regions. Unified CM
provides features that allow you to set limits for the
maximum amount of bandwidth allowed for audio and
video calls. This is called call admission control.
Note
To stop Unified CM from advertising video capabilities in an offer (through
m=video lines in the SDP body of a SIP message), simply set the video
bandwidth between two regions to None. This method of blocking the
advertisement of video capabilities is usually leveraged on SIP trunks
interfacing with CUBE when connecting to the PSTN, as most Internet
telephony service providers (ITSPs) do not support video. You should place the
SIP trunk in its own region and set the Session Bandwidth for Video parameter
to None for pairings from the CUBE region to any regions containing video-
capable devices.
CALL ADMISSION CONTROL (CAC)
The regions feature allows you to control which codecs
and how much bandwidth is allowed for individual calls
between two devices that might be in different sites, but
it does not control the aggregate amount of bandwidth
allowed for all calls between those two sites. Call
admission control (CAC) is a feature that allows you
to limit the aggregate bandwidth allowed between two
logical groupings of devices. These groups are called
locations in the enhanced location call admission
control (ELCAC) feature in Unified CM. Although
regions and locations typically logically group the same
sets of devices (for example, all phones at a specific
remote site are assigned a region called Remote Site 1
and also assigned a location called Remote Site 1), these
two groupings are completely independent of each other
and do not have to match.
Before the ELCAC feature was introduced, Unified CM

supported a very basic location CAC feature that allowed
for tracking of bandwidth across either hub-and-spoke or
fully meshed topologies. ELCAC added the ability to
track bandwidth across arbitrarily complex network
topologies as well as track bandwidth across multiple
clusters that may share bandwidth to a given location.
Location Bandwidth Manager Service

Configuring ELCAC begins with activating an essential
service needed to make the feature work. If you do not
activate the Cisco Location Bandwidth Manager
(LBM) service, you can configure ELCAC, but by default
it does not restrict any calls from being completed, even
if the calls exceed the bandwidth limits put in place.
Before configuring ELCAC, be sure to navigate to Unified
CM Serviceability > Tools > Service Activation and
activate the Cisco Location Bandwidth Manager service.
You can activate this service on whichever servers in the
cluster you wish, but it is strongly recommended that you
activate the service on all servers in the cluster that are
running the Cisco CallManager service.
Once the LBM service has been activated, you should

create LBM groups. This is not required, but to ensure
high availability for the LBM service, you should create
an LBM group for each server in the cluster running
LBM. An LBM group allows you to configure a primary
LBM server and backup LBM server. To understand why
you should configure a group for each server, you need to
understand the logic Unified CM uses to find the LBM
service.
The Cisco CallManager service first looks to see if an

LBM group is configured and associated with the server
on which the service is running. If it is, the Cisco
CallManager service uses the primary and backup LBM
servers listed in the LBM group. If no LBM group is
assigned to the server, the Cisco CallManager service
looks locally for the LBM service, and if the service is
running on the same server, it works; however, if the
LBM service fails on the local server for whatever reason,
the Cisco CallManager service does not look elsewhere in
the cluster for another LBM service. If the Cisco
CallManager service cannot find an active LBM service
based on this logic, it looks at the service parameter
named Call Treatment When no LBM Available, which
defaults to Allow. This means that, by default, if LBM is
not available, calls are permitted even if there might not
be enough bandwidth for those calls.
The recommendation is to create an LBM group for each

server in the cluster running the Cisco CallManager
service and, for each group, to assign the server to which
the LBM group will be assigned as the primary and then
assign as a backup a second node that is in close
geographic proximity to the primary node. Figure 6-23
shows how this would work for a five-server cluster with
one publisher and four servers running the Cisco
CallManager service.
Figure 6-23 LBM Group Topology
In this example, you would create four LBM groups, each

with the local server as primary and then the closest
server as the backup. For example, you would assign
LBM Group 1 to Unified CM 1, LBM Group 2 to Unified
CM 2, and so on. To configure an LBM group, navigate to
Unified CM Administration > System > Location Info >
Location Bandwidth Manager Group. Figure 6-24 shows
the sample configuration for an LBM group.
Figure 6-24 LBM Group Configuration
You can assign an arbitrary name to the group and then

assign active and standby servers for the group. Once you
have created an LBM group for each server in the cluster,
you need to assign the LBM groups to the appropriate
servers. This is done from Unified CM Administration >
System > Cisco Unified CM. Select each server running
the Cisco CallManager service and assign the LBM group
you configured for that server.
Configure Enhanced Location Call Admission Control

(ELCAC)
Now that you have activated the LBM service and created
and assigned LBM groups, you need to understand how
ELCAC works. ELCAC is a model-based static CAC
mechanism. To configure ELCAC, you must configure
locations and links to model the topology of the network
to represent how the WAN network topology routes
media between groups of endpoints for end-to-end
audio, video, and immersive calls. Although Unified CM
provides configuration and serviceability interfaces in
order to model the network, it is still a “static” CAC
mechanism that does not consider network failures,
alternate paths, or changes made to the network;
therefore, the model needs to be updated when the
network topology changes. ELCAC is also call oriented,
and bandwidth deductions are per-call not per-stream,
so asymmetric media flows where the bit rate is higher in
one direction than in the other always deduct for the
highest bit rate. In addition, unidirectional media flows
are deducted as if they were bidirectional media flows.
ELCAC incorporates the following configuration

components to allow you to build the network model
using locations and links:
• Locations: A location represents a LAN or

aggregation point in a network. It could contain
endpoints or could simply serve as a transit
location between links for WAN network modeling.
For example, an MPLS provider could be
represented by a location. Devices in a given
location are generally considered to have
unrestricted bandwidth, but ELCAC allows for
intraregion restrictions as well.
• Links: Links interconnect locations and are used

to define bandwidth available between locations. A
link logically represents the amount of bandwidth
available for different types of calls between two
locations.
• Weights: A weight provides the relative priority

of a link in forming the effective path between any
pair of locations. The effective path is the path used
by Unified CM for the bandwidth calculations, and
it has the least cumulative weight of all possible
paths. Weights are used on links to provide a cost
for the effective path and are relevant only when
there is more than one path between any two
locations.
• Path: A path is a sequence of links and

intermediate locations connecting a pair of
locations. Unified CM calculates least-cost paths
(lowest cumulative weight) from each location to all
other locations and builds a map of the various
paths. Only one effective path is used between any
pair of locations.
• Effective path: The effective path is the end-to-

end path with the least cumulative weight. As far as
Unified CM is concerned, all traffic between two
locations only traverses the effective path.
• Bandwidth allocation: Bandwidth

allocation refers to the amount of bandwidth
allocated in the model for each type of traffic:
audio, video, and immersive video. These
bandwidth deductions are taken based on the
region configuration as well as the codecs that are
actually negotiated for a call.
• Location Bandwidth Manager (LBM): As

discussed previously, the service that assembles a
network model from configured location and link
data in one or more clusters determines the
effective paths between pairs of locations,
determines whether to admit calls between a pair of
locations based on the availability of bandwidth for
each type of call, and deducts (reserves) bandwidth
for the duration of each call that is admitted. When
using ELCAC, the Cisco CallManager service makes
a request to the LBM service for every call.
To best understand how these constructs come together,

refer to Figure 6-25, which shows a sample topology
using ELCAC.
Figure 6-25 ELCAC Sample Topology
This is an example of a fairly simple network; however,

these concepts extend to much more complex topologies.
In this example, you would configure six locations:
• Remote Site 1
• Remote Site 2
• MPLS WAN
• Campus 1
• Campus 2
• Campus 3
Each of these locations represents a logical grouping of

devices or a transit point in the network. The name of a
location is important if you plan on implementing
ELCAC between multiple clusters because the names of
locations must match identically if you plan on creating
links between locations on different clusters or adding
devices on multiple clusters to the same location. Be
absolutely certain that if you are configuring the same
location on multiple clusters that the name matches.
Connecting each of the locations is a link. In some cases,

such as between the MPLS WAN and the Campus 1
location, there are two links in the real network.
Unfortunately, Unified CM does not know the routing
tables or how traffic is being forwarded on redundant
links, so depending on how you model the network, you
would assume a particular route for the traffic. To be
conservative, you would want to assume that the traffic is
using the lower-speed link, but if you model the network
so that Unified CM knows about both links, it assumes
that the better link is always available. In fact, when
modeling the network, you do not need to add two links
between Campus 1 and the MPLS WAN locations
because the lower-cost link will never be used.
Each link is assigned an arbitrary weight that you can use

to influence which link Unified CM considers when
building the effective path between two locations. The
link weight does not necessarily have to correspond to
the bandwidth available on the link. The weight simply
helps determine which path will be used, regardless of
the bandwidth available. In Figure 6-25, you can see that
a weight of 10 is assigned to almost every one of the links
except for one of the two links between Campus 1 and the
MPLS WAN. Setting the higher-bandwidth link with a
lower weight ensures that the link is used for
calculations.
When building the effective path between Remote Site 1

and Campus 3, Unified CM takes the path Remote Site 1
→ MPLS WAN → Campus 1 → Campus 3; however,
when calculating the effective path between Campus 3
and Campus 2, the effective path is just Campus 3 →
Campus 2. Unified CM assumes that traffic between
Campus 2 and Campus 3 traverses the direct link
between the two instead of going up through Campus 1.
If for some reason the network topology were such that
the normal traffic pattern was through Campus 1, you
could modify the weight of the Campus 2–to–Campus 3
link to be higher than 20. Since the weights of the two
links between Campus 1 and Campuses 2 and 3 are each
10, the cumulative weight to get from Campus 3 to
Campus 2 via Campus 1 is 20. This means that as long as
the direct link between Campus 2 and Campus 3 is
higher than 20, the path between Campus 1 will be
selected as the effective path.
To configure this topology in Unified CM, navigate to

Unified CM Administration > System > Location Info >
Location. Figure 6-26 shows the location configuration
page for adding a new location.
Figure 6-26 Location Configuration
You must provide a name for the location, and Unified

CM always prompts you to add at least one link from the
location you are creating to another location. If this is the
first location you are creating, you might not have
another location to create a link to yet. You can select the
Hub_None location, which is a default location that
comes with Unified CM, to create the initial link and then
you can delete it later. In this case, say that you are
adding the Remote Site 2 location, which, based on the
topology diagram in Figure 6-25, has a link to the MPLS
WAN location. To create this link, select the location to
which this link connects (MPLS WAN in this case) and
then configure the weight and allowed bandwidth for
audio, video, and immersive video.
If you click the Advanced button link at the bottom, you

expose the Intra-location - Bandwidth for Device Within
This Location setting, which allows you to specify
bandwidth limits for calls between devices in the same
location. This is typically left at the default setting,
Unlimited, which is why it is hidden in the advanced
options.
Once you have saved the new location, you see a screen
like the one shown in Figure 6-27. On this page, you can
add, delete, or modify all the links that are associated
with this location. Links are bidirectional, which means
that if you look at the MPLS WAN location, you see the
same link pointing back to the newly added Remote Site
2 location.
Figure 6-27 Location Configuration After Saving
Once you have modeled your network by configuring

locations and links, the last step is to assign locations to
your devices. This can be done by configuring the
location on the device itself or, if you are using the device
mobility feature, it can be assigned dynamically based on
the physical location of the device on the network. Note
that if you are not using device mobility, you must assign
the location on the device itself. The location assigned on
the device pool does not apply as there is no “use default”
setting for a location on the device configuration page, so
whatever is configured on the device is used. By default,
all devices are in the Hub_None location.
Also be careful that you do not leave devices in a location

to which there are no links. If a location has no path to
another location, you cannot make any calls between
those two locations.
In addition to the Hub_None location, there are two

other special locations that come preconfigured with
Unified CM: the Phantom and Shadow locations. These
two locations serve similar purposes, but the Phantom
location comes preconfigured for the legacy location call
admission control feature and should not be used with
ELCAC. The Shadow location should be used on SIP
trunks that point to other Unified CM clusters that are
also performing ELCAC. The Shadow location does not
have links associated with it and just indicates to Unified
CM that it should transmit information to the other
cluster about the originating location and should expect
information from the other cluster regarding the
terminating location.
Automated Alternate Routing (AAR)

When a call fails due to insufficient bandwidth between
locations, the default behavior is to play a reorder tone to
the user and display a message on the phone indicating
that the call could not be completed. This is not an ideal
user experience. If the originating and terminating
endpoints both have local PSTN connectivity that does
not rely on the WAN, the automated alternate routing
(AAR) feature can be used to automatically reroute the
call over the PSTN if there is insufficient bandwidth. The
biggest disadvantage to rerouting over the PSTN is that
PSTN audio is typically narrowband (G.711 at best) and
does not support video, so the experience for the user
will be impacted, but given the alternative of blocking the
call entirely, routing over the PSTN is usually the best
available option.
Figure 6-28 illustrates how the AAR feature works. The

figure shows the following steps:
Figure 6-28 AAR in Action Example
Step 1. User 85551000 in Remote Site 1 dials user

85552000 at Campus 2.
Step 2. Unified CM attempts to route the call, and

ELCAC determines that the effective path
between Remote Site 1 and Campus 2 is via
the Remote Site 1 → MPLS WAN link
followed by the MPLS WAN → Campus 1 link
followed by the Campus 1 → Campus 2 link.
Because there is no bandwidth available on
the Campus 1 → Campus 2 link, the call is
rejected. (Note that there would be
bandwidth available if the call were to take
the path from Campus 1 to Campus 3 and
then to Campus 2, but ELCAC only considers
the effective path and does not consider other
paths even if one link is congested.)
Step 3. If AAR is configured, AAR transforms the

called party number to a number that is
reachable via the PSTN and reroutes the call
over the PSTN.
In order for step 3 to work, there are two things Unified
CM must do. First, it must determine how to reach
85552000 via the PSTN. The number 85552000 is not
an E.164 number, so sending those digits to the PSTN
would result in a call failure. Once it has transformed the
digits to something reachable via the PSTN, Unified CM
must match a route pattern that routes the call to the
local PSTN gateway. Let’s examine each of these two
steps.
The first step is transforming the digits. There are three

different places that can affect the number getting into
the form where it can be called via the PSTN. The first is
the AAR destination mask, which can be configured on a
line. Figure 6-29 shows the AAR Settings section for
configuring a line in the Unified CM Administration user
interface.
Figure 6-29 AAR Settings on a Line
The AAR Destination Mask setting allows you to mask

the directory number to transform it to an E.164 number.
This transformation can convert the number to anything
you like. For example, if the directory number does not
have a DID associated with it, you can convert the
number to an IVR system or a reception desk at the
destination site. In this case, you could configure the
AAR mask as +19195552000 to match the DID
associated with the 85552000 extension. The other
important setting in the AAR Settings section is AAR
Group. For AAR to function, the originating and
terminating devices must be in an AAR group. As you
will see in a moment, you can put all phones in the same
AAR group if you do not need additional digit
manipulation when calling from one location to another.
The second way that the number can be transformed for
the purposes of AAR is through the External Phone
Number Mask parameter. This is usually the preferred
method of transforming the number because the external
phone number mask usually needs to be configured
anyway to ensure proper calling party number
presentation for PSTN calls, so this field ends up serving
a dual purpose.
Note
In order for AAR to work, you must have either an external phone number
mask or an AAR destination mask configured. This means that if your directory
number is already in a globalized form that can be reached over the PSTN—for
example, if the directory number is in +E.164 format already—you must still
configure a mask if you want AAR to function, even if the mask is identical to
the directory number.
The final mechanism available to modify the directory

number for the purposes of AAR is to use prefixes
configured as part of the AAR group configuration. The
general design recommendation is to not use this
mechanism and instead transform the number to +E.164
format and ensure that phones can dial a number to the
PSTN by directly dialing the number in +E.164 format.
However, if you cannot do this for some reason, AAR
allows you to prefix digits to the transformed number,
depending on the source and destination groups. To
configure an AAR group, navigate to Unified CM
Administration > Call Routing > AAR Group. Figure 6-
30 shows the AAR group configuration page.
Figure 6-30 AAR Group Configuration

The AAR group prefix digits configuration allows you to
specify what digits to prefix when rerouting a call from
one AAR group to another. In this case, you can see that
91 is being prefixed for calls from the Campus 1 AAR
group to all the other AAR groups. (In addition, calls
from all the other AAR groups will get 91 prefixed to calls
destined to the Campus 1 AAR group.) If using a
configuration like this, you might have an external phone
number mask that transforms the directory number to a
10-digit national number (for example, 9195552000) and
then use the AAR prefix to prefix the access code needed
to make this a PSTN call. Best practice is to not leverage
this mechanism and just make sure numbers are
transformed to +E.164 format and that a route pattern
exists to match the +E.164 number for routing to the
local gateway.
After the number has been transformed to a number

reachable through the PSTN, the call must be routed.
This is done by placing a call to the transformed number,
but instead of using the line/device calling search space
of the device, the AAR calling search space is used. The
AAR calling search space can have permissions to dial
numbers via the PSTN that the user might not normally
be allowed to dial directly. For example, if the call failure
is between two phones in different countries, you might
allow AAR to place an international call when the user is
not normally allowed to place international calls.
If using the design guidance of transforming the number

to +E.164 format, you can simply have a single route
pattern matching \+! with urgent priority (because AAR
calls are always presented enbloc, so you do not have to
worry about digit-by-digit dialing), and that route
pattern can point to a route list with a local route group
configured. You might even choose to define one of the
local route groups as the AAR local route group and then,
for each device pool, specify the route group that should
be used for placing AAR calls for devices where that
device pool is configured. With a +E.164 dial plan,
enabling AAR is very simple: Just ensure that you have a
single AAR group with no prefixes configured assigned to
all directory numbers, ensure that you have an external
phone number mask in +E.164 format, and ensure that
the AAR calling search space is configured to point to a
partition with a pattern that can route all calls to the
local route group.
Troubleshooting and Monitoring Enhanced Location

Call Admission Control
After you have configured locations and associated them
with devices, you can place calls, and Unified CM ensures
that you do not exceed the limits of your network, based
on the configuration, and it reroutes to the PSTN as
needed if you have enabled AAR. Unified CM provides
several features that allow you to monitor and
troubleshoot ELCAC to understand why calls may or may
not be working between two locations.
The first set of tools are available under Unified CM

Serviceability > Tools > Locations. The first option here
is the Topology menu, which allows you to view the list of
all locations and the links associated with a location. For
example, Figure 6-31 shows the information for the
MPLS WAN location.
Figure 6-31 ELCAC Topology View in Unified CM

Serviceability
The most useful feature in Unified CM Serviceability for
diagnosing issues with ELCAC is the Effective Path
submenu, which allows you to select any two locations
and view the path between those two sites, as calculated
by Unified CM, as well as the bandwidth configuration
and real-time available bandwidth. For example, Figure
6-32 shows the path between the Campus 1 and Remote
Site 1 locations.
Figure 6-32 Example Path Between Two Unified CM

Locations
The Quick Path Overview section shows information

about the most constrained link on the route along the
path between the two locations. This is effectively the
available bandwidth between the two locations. The
Detailed Path View section shows the details of each
location and link so you can see how much bandwidth is
configured and available at each hop along the path. In
this example, you can see that there is no video
bandwidth available between these two locations because
the link between MPLS WAN and Remote Site 1 is full.
This means that no additional video calls are permitted
on this link, although audio calls and immersive video
calls are still allowed. The Effective Path menu is the first
place you should look when trying to understand why a
call between two locations is being rejected.
You can also use the Real Time Monitoring Tool (RTMT)
Performance menu to monitor the available bandwidth
on links as well. In this case, you can just monitor
specific links or locations and not the effective path
between locations. Figure 6-33 shows the available
bandwidth for audio and video for the link between
Campus 1 and the MPLS WAN as well as the link
between the MPLS WAN and Remote Site 1.
Figure 6-33 RTMT View of ELCAC Counters
These counters can also be polled through the PerfMon

API that is part of the Serviceability XML API available
on Unified CM. (For more information on the
Serviceability XML API, visit developer.cisco.com.) You
can see that the example in Figure 6-33 is monitoring for
the BandwidthAvailable and VideoBandwidthAvailable
counters. You can also see that it is monitoring the
OutOfResources counter, which increments any time a
call is denied because of a CAC failure. These are good
counters to monitor because if the out-of-bandwidth
counters are incrementing, you might want to consider
adding bandwidth to those links.
If you want to dig in deeper to detect CAC failures, you

can look in the SDL traces or call detail records. The first
clue of a CAC failure appears in the call detail records.
Unified CM indicates cause code 125 for a CAC failure, so
if you see this cause code, it is likely to be CAC related.
To delve deeper, you can examine the SIP signaling for a
call from a phone destined to another location. When
Unified CM rejects a call due to insufficient bandwidth,
the response to the INVITE message is a 488 Not
Acceptable Media error, as shown in Example 6-2.
Example 6-2 SIP Response for a CAC Failure
SIP/2.0 488 Not Acceptable Media

From: “Test Phone 2” <sip:89943782@svs-uc-alpha-test-
To: <sip:89943781@svs-uc-alpha-test-cm1b.cisco.com>;t
Call-ID: 885a92d9-bca80046-5b9a7239-7b4621d4@10.122.2
CSeq: 101 INVITE
Allow-Events: presence
Session-ID: 00000000000000000000000000000000;remote=5
Warning: 370 10.122.249.71 “Insufficient Bandwidth"
Reason: Q.850; cause=125

Remote-Party-ID: “Test Phone 1” <sip:89943781@10.122.
Content-Length: 0
You can see in the example that Unified CM provides a

Warning header with the message Insufficient
Bandwidth. If you want to look deeper in the SDL trace,
just before the 488 is sent, you see the lines shown in
Example 6-3.
Example 6-3 CAC Failure Messages in SDL Trace
00018315.001 |00:24:09.958 |AppInfo |LBMIF: CI: 4375

00018315.002 |00:24:09.958 |AppInfo |LBMIF: device 0
00018315.004 |00:24:09.958 |AppInfo |LBMIF: CI: 4375
00018315.005 |00:24:09.958 |AppInfo |LBMIF: RSV XML>
00018315.006 |00:24:09.958 |AppInfo |LBMIF: Sending
00018316.001 |00:24:09.960 |AppInfo |LBMIF: RSV XML<
00018316.002 |00:24:09.960 |AppInfo |LBMIF: CI: 4375
00018316.003 |00:24:09.961 |AppInfo |LBMIF: Erase tr
If you want to get additional detail on the failure, you

need to look at the LBM trace files that can be
downloaded using RTMT or from the platform CLI. In
the LBM trace files, you can see the bandwidth request
coming from the Cisco CallManager service to LBM, as
shown in Example 6-4.
Example 6-4 Bandwidth Request from Cisco

CallManager to LBM
00001151.001 |00:40:15.963 |AppInfo |LBMServer - Rec

msg = {
messageId = (37)
msgkey = ()
nofwd = (0)
choice = (reservationReq)
reservationReq = (
transId = (13210859295534481426)
seqNum = (0)
choice = (reserve)
reserve = (
sideA = (
loc = (Remote Site 1)
fs_id = (SVS-UC-Alpha-Test-Cluster1:43759218)
ext = ()
)
sideB = (
loc = (Campus 1)
fs_id = (SVS-UC-Alpha-Test-Cluster1:43759219)
ext = ()
)
cacSt = (0)
precedLvl = (5)
mlpp = (0)
execOVR = (0)
enforce = (0)
a_val = (1)
v_val = (0)
i_val = (0)
a_bw = (24)
v_bw = (0)
i_bw = (0)
a_op = (0)
v_op = (0)
i_op = (0)
ext = (<msg></msg>)
)
ext = ()
)
}
In Example 6-4, you can see that this is a reservation

request between Remote Site 1 and Campus 1 locations,
and the request is for an audio call of 24 kbps. In the
output, a stands for audio, v stands for video, and i
stands for immersive. a_val set to 1 indicates that audio
is being requested, and the a_bw value indicates 24
kbps. LBM then shows the attempt to allocate bandwidth
along the path, as shown in Example 6-5.
Example 6-5 LBM Searching for Available Bandwidth
00001152.001 |00:40:15.963 |AppInfo |LBM: RES_REC OP

00001152.002 |00:40:15.963 |AppInfo |LBM: RES_REC En
00001152.006 |00:40:15.963 |AppInfo |LBM: RES_REC NO
This triggers LBM to generate an alarm, as shown in

Example 6-6.
Example 6-6 Out-of-Bandwidth Alarm Generated by

LBM
00001152.007 |00:40:15.963 |AppInfo |GenAlarm: Alarm

ResourceType : 1
AppID : Cisco Location Bandwidth Manager
ClusterID : SVS-UC-Alpha-Test-Cluster1
NodeID : svs-uc-alpha-test-cm1b
The severity of this alarm is only level 4, so depending on

your network management configuration, you might not
alert on this. If you are using ELCAC, this is an alarm you
might want to pay attention to because it indicates a CAC
failure due to lack of bandwidth.
Most ELCAC issues are due to either misconfiguration or

legitimate lack of bandwidth. Proper monitoring of
counters and alarms so that administrators are aware of
CAC failures can ensure that additional bandwidth is
added to provide the call capacity needed by users at a
location.



MEMORY
DEFINE KEY TERMS

media resource
ad hoc
Meet-Me
conferencing
Music on Hold (MOH)
call park
call pickup
region
audio codec preference list
call admission control (CAC)
enhanced location call admission control (ELCAC)
interactive voice response (IVR)
annunciator
media termination point (MTP)
transcoder
IP Voice Media Streaming App service
Conference Now
user hold
network hold
media resource group (MRG)
media resource group list (MRGL)
directed call park
call park reversion
call park monitoring
group call pickup
other call pickup
directed call pickup
Location Bandwidth Manager (LBM)
location
link
weight
path
effective path
bandwidth allocation
Chapter 7. Unified CM Mobility
• Unified Mobility: This section details mobility-

related features that allow remote users to connect
to Unified CM, regardless of their physical location.
• Configure and Verify Extension Mobility:

This section covers the Extension Mobility feature,
which enables users to share phones while
maintaining their own phone settings, including
their directory number.
• Configure and Verify Device Mobility: This

section covers the Device Mobility feature, which
lets users take their devices to different sites and
inherit settings that are specific to the site they are
visiting.

exam topics:
• 6.1 Configure Cisco Unified Communications

Manager Mobility
• 6.1.a Unified Mobility
• 6.1.b Extension Mobility

• 6.1.c Device Mobility
• 6.2 Troubleshoot Cisco Unified Communications

Manager Mobility
• 6.2.a Unified Mobility
• 6.2.b Extension Mobility

• 6.2.c Device Mobility
Meeting business needs while also being as flexible as
possible for end users and Unified CM administrators is
one of the most important goals of Cisco collaboration
products. For example, for users who need to be
reachable via their desk phone number at any time,
Unified CM administrators can implement the Unified
Mobility feature Single Number Reach (SNR) to extend
inbound calls to a user’s desk phone and the user’s
desired remote device, such as a cell phone. A growing
trend is the use of open concept office spaces. In these
offices, users might not always be working in the same
physical space or even the same physical building day in
and day out, and endpoints cannot be individually
assigned. In such settings, Unified CM administrators
can leverage Extension Mobility to make it possible for
users to share physical phones while maintaining their
individual phone settings, including directory numbers.
Similarly, there may be a need for a physical device to
move with a person across the country or even between
countries to a different remote office. Unified CM
administrators need not fret because Unified CM Device
Mobility lets users take their device to different locations
and inherit settings that are specific to the site they are
visiting, with little administrative intervention.
This chapter focuses on features mentioned previously as

well as some of the smaller features provided by Cisco
Unified Mobility, such as Move to Mobile and Intelligent
Session Control.
Note
Two Unified Mobility topics that are not discussed in this book are Mobile Voice
Access (MVA) and Enterprise Feature Access because these features have
essentially been replaced by Mobile and Remote Access (MRA). Although
MRA replaced some of the Unified Mobility features, it is not covered in this
book because it is not covered on the CLACCM 300-815 exam. It is, however,
covered on the Implementing Cisco Collaboration Cloud and Edge Solutions
(CLCEI) 300-820 exam.
Although Cisco CallManager Express (CME) includes

mobility features, the CLACCM 300-815 exam covers
mobility features as they relate to Unified CM and not
CME. Therefore, this chapter covers only Unified CM
mobility and not CME mobility.


1. Which of the following best describes the

functionality that can be leveraged with Single
Number Reach?
a. Single Number Reach allows users to log in to

Extension Mobility via single sign-on (SSO).
b. Single Number Reach allows a user to receive calls

at home or on a personal mobile phone when
someone calls that user’s desk phone.
c. Single Number Reach is a mobility-related feature

that adds functionality to Extension Mobility.
d. Single Number Reach allows users to call in to the

corporate environment and place an outbound call
as if it originated at their desk phone.
2. Which of the following is a feature of Intelligent

Session Control?
a. It allows the remote destination to hang up and
enables the user to resume the call on his or her
desk phone.
b. It allows inbound calls from the remote

destination to present as though they originated
from the desk phone.
c. When an internal call is placed to a remote

destination, Unified CM routes the call to the desk
phone instead of to the remote destination.
d. When users are logged in to a phone, Intelligent

Session Control knows when to log the user out of
the phone.
3. Which of the following are common mistakes when

configuring Single Number Reach? (Choose two.)
a. Enabling the user instead of the device for mobility
b. Leaving the Line Association checkbox unchecked
c. Setting up Single Number Reach for the wrong

user
d. Applying the device calling search space and not

the rerouting calling search space to the remote
destination profile
e. Leaving the user’s PIN blank
4. When does Unified CM perform digit analysis for

remote destination numbers?
a. In parallel with digit analysis for the desk phone
number
b. After the Delay Before Ringing timer expires
c. When the user clicks the iDivert softkey

d. At the time of configuring the remote destination
5. Which of the following best describes the

functionality of Move to Mobile?
a. It allows a user to hang up a call on his mobile
phone and resume the call on his desk phone.
b. It is an Extension Mobility feature for mobile

phones.
c. It allows a user to transition from her desk phone

to her remote destination.
d. It allows a user to use Cisco Jabber on his mobile

phone as a shared line.
6. To use Move to Mobile, what must be added to a

phone?
a. A call forward button
b. A second directory number
c. A softkey
d. Extension Mobility
7. If Move to Mobile isn’t working, which checkbox

should be reviewed on the Remote Destination
Configuration page in Unified CM?
a. Enable Single Number Reach
b. Enable Move to Mobile
c. Enable Extend and Connect
d. Mobile and Remote Access (MRA)
8. Which of the following best describes Extension

Mobility?
a. Extension Mobility allows a user to move her

phone between campuses, and the phone will use
local settings for the new campus.
b. Extension Mobility allows a user to transition a call
from his desk phone to his mobile phone.
c. Extension Mobility allows agents to log in to a call

queue with any phone, including a personal phone.
d. Extension Mobility allows a user to log in to a

phone and temporarily use her device profile on
the phone.
9. How can a remote Unified CM administrators tell

which device profile is logged in to a phone with
Extension Mobility?
a. Check the Extension Information section on the
phone configuration page
b. Reset the phone
c. Check the CDP debugging information on the

switch connected to the phone
d. Browse to the web page of the phone
10. Which of the following is a common mistake

observed when configuring Extension Mobility?
a. Not enabling the Enable Mobility checkbox on the

end-user page
b. Leaving the user logged in to the phone
c. Forgetting to set the primary extension on the end-

user page
d. Using the EMCC URL instead of the EM URL
11. What should a Unified CM administrator do when a

user can log in to a device but cannot log out?
a. Log the user out of the phone from the Extension
Information section of the phone configuration
page
b. Subscribe the phone to the Extension Mobility

service
c. Subscribe the device profile to the Extension
Mobility service
d. Have the user power cycle the phone
12. Which of the following best describes Device

Mobility?
a. Device Mobility allows a user to move between
sites and log in to local phone in order to apply her
profile to the phone.
b. Device Mobility allows a user to move his phone

between campuses, and the phone will use local
settings for the new campus.
c. Device Mobility allows a user to connect her phone

to Cisco Unified Communications Manager from
external networks by using VPN-less access.
d. Device Mobility adds functionality to Extension

Mobility Cross Cluster.
13. When is Device Mobility–related information applied

to a phone?
a. When a device moves between Device Mobility

groups
b. When a device changes subnets
c. When a device moves between physical locations

and Device Mobility groups
d. When a device moves between physical locations

but remains in the same Device Mobility group
14. In the following Unified CM trace snippet, is

SEPD0EC35FFB4C4 at its home site, or has the user
moved the phone to a new site?
01998726.003 |22:45:30.987 |AppInfo

|DeviceManager::addMobileDevice - added mobile
device to Device Mobility Route Table.
DeviceName=SEPD0EC35FFB4C4, DeviceType=36225
IpAddr=6AD6320E, DevicePool=CDMX_DP(3529fd90-
bf5e-8765-87b0-2ecf0d281cc7),
RoamingDevicePool=SJ_DP(3f6bb86d-4d49-a843-
24d6-bc928ecaf337), EMCCGeoLocationFilter=,
DeviceGeoLocation=[],
GeoLocationTokensMatched=0
a. There is not enough information to tell; the phone

console logs are needed to determine the answer.
b. The phone is roaming.
c. The phone is not roaming.
d. It depends on whether the phone has changed

Device Mobility groups.
FOUNDATION TOPICS
UNIFIED MOBILITY
This chapter covers the Unified Mobility features Single
Number Reach (SNR), Move to Mobile, Intelligent
Session Control, Extension Mobility, and Device
Mobility. It shows the purpose of each of these features,
how to configure them, and how to validate they’re
working as expected. Furthermore, this chapter
examines how to troubleshoot each feature. The Move to
Mobile and Intelligent Session Control features rely
heavily on SNR, so the chapter opens with the SNR
feature.
Note
The terms mobile phone and remote destination are used interchangeably in
this chapter.
Configure and Verify Single Number Reach

It is common for a person to have more than one phone
number where he or she can be reached, such as a work
number and a personal mobile device number or home
phone number. Unified Mobility makes it easier to reach
a user, no matter which phone the user is near. For
example, say someone calls your work phone number
and only the desk phone rings, but you are not at your
desk, so you don’t receive the call. When SNR is
configured, a caller can call your work number, and your
personal mobile device or home phone will ring
simultaneously with your desk phone (see Figure 7-1).
Figure 7-1 Single Number Reach Overview
Note
This chapter does not address the intricacies of call routing with Unified CM or
CUBE. Instead, it discusses Unified Mobility configuration, validation, and
troubleshooting. For more information about call routing with Unified CM, refer
to Chapter 4, “Unified CM Call Routing and Digit Manipulation.” For more
information on call routing with CUBE, see Chapter 8, “CUBE Call Routing and
Digit Manipulation."
Figure 7-1 illustrates the following events that occur

when Unified CM routes a call to a line associated with a
remote destination:
Step 1. The phone with DN 1001 sends Unified CM a

SIP INVITE to call DN 1000.
Step 2. Unified CM performs a digit analysis for the

called number 1000, which is a line with an
SNR remote destination profile (RDP).
Before Unified CM extends the call to the IP
phone with line 1000, a second digit analysis
for the remote destination number (408-555-
7890) is performed to determine the call
should route to CUBE and, ultimately, the
PSTN service provider.
Step 3. Unified CM extends the call to the IP phone,

which begins to ring.
Step 4. Depending on some SNR timers (discussed

later in the chapter), Unified CM might also
extend the call to the SNR remote destination
or wait for the configured delay interval
before extending the call to CUBE and,
ultimately, the PSTN service provider.
Step 5. The service provider extends the call to the

cell phone with E.164 number
+14085557890. At this point, the two phones
continue ringing until one of the following
occur:
• The called party answers the call on the IP

phone 1000.
• The remote destination 408-555-7890
answers the call.
• The timers for the call expire. (Timers are

discussed later in this chapter.)
• The calling party hangs up.
When a call is answered on a remote destination it can be

ended by either the calling party or the remote
destination. It is important to know that the calling party
is placed on hold if the remote destination is the side that
hangs up. Before fully disconnecting the call, Unified CM
extends the phone call to the desk phone again. This hold
allows the user to switch from the remote destination
phone to the desk phone and continue talking with the
calling party. The transition from the remote destination
to the desk phone is accomplished with the Desk Pickup
feature, and the default amount of time for Desk Pickup
is 10 seconds. This timer value can be configured by
changing the Maximum Wait Time for Desk Pickup
parameter in the End User Configuration under Mobility
Information, as shown in Figure 7-2. To disable Desk
Pickup, set the Maximum Wait Time for Desk Pickup
parameter to 0.
Figure 7-2 End-User Mobility Information Section
As an alternative to hanging up on the remote

destination in order to use Desk Pickup, you can use the
Enterprise Feature Access Code for Session Handoff to
transition calls between the desk phone and remote
destinations. Figure 7-3 shows a list of the default
Enterprise Feature Access Codes.
Figure 7-3 Default Enterprise Feature Access Codes
Configure Single Number Reach

The next few sections detail how to configure SNR.
Throughout the following examples, the end user's
mobile phone serves as the remote destination, and 408-
555-7890 is the number associated with the mobile
device. The following steps are required to complete the
implementation of Single Number Reach for a single
user:
Step 1. Enable mobility on the end user: To

enable mobility on the end user, navigate to
Cisco Unified CM Administration > User
Management > End User. Find and select the
target end user and scroll to the Mobility
Information section. Select the Enable
Mobility checkbox (refer to Figure 7-2).
Step 2. On the phone configuration page,

select the appropriate user in the
Owner User ID field: Select the IP phone
on which to enable SNR by navigating to
Unified CM Administration > Device >
Phone. In the Device Information section,
ensure that the Owner toggle is set to User
rather than Anonymous (Public/Shared
Space). Select the appropriate user’s user ID
in the Owner User ID dropdown. Save and
apply configuration on the phone to complete
the change.
Step 3. Create an RDP and associate it with

the end user: To create an RDP and
associate it with the end user, navigate to
Cisco Unified CM Administration > Device >
Device Settings > Remote Destination Profile.
On the RDP page you can select Add New,
and the page changes to the Remote
Destination Profile Configuration page, as
shown in Figure 7-4. Use this page to add the
specific settings for the RDP.
Figure 7-4 Remote Destination Profile Configuration
Page
Ensure that the User ID field matches the

user ID found on the end user configuration
page. The route patterns used for routing
calls to the remote destinations (typically the
user’s mobile phone or home phone) must be
accessible to the rerouting calling search
space configured on the RDP.
Note
Notice that the calling search space applied to the RDP for SNR to work is the
rerouting calling search space and not the typical device calling search space.
This is because calls sent to the remote destination are treated similarly to
calls that are forwarded. In Figure 7-4 you can see that no device calling
search space is configured, but a rerouting calling search space is configured.
Step 4. Add a directory number to the RDP:

When you click Save, the page refreshes and
shows the Add Successful status message (see
Figure 7-5). Now you should see the option to
add a directory number to the RDP, along
with the option to add a new remote
destination.
Figure 7-5 RDP Configuration Page After Save
The directory number configured on the RDP

must be the same as the directory number
configured on the user's desk phone. This
means the same number and same partition.
Figure 7-6 shows the directory number
configured on the user’s Cisco 8865 phone.
Figure 7-6 Directory Number on a Desk Phone
Now that you know the desk phone directory

number, you can add the directory number to
the RPD by clicking Add a New DN (shown
previously in Figure 7-5). The page that
appears for configuring the directory number
on the RDP looks almost the same as the page
for adding a directory number to a phone.
While adding the directory number to the
RDP, you can modify the line settings that are
device specific. Figure 7-7 shows the phone’s
device-specific line settings (left) and the
RDP’s device-specific line settings (right).
Figure 7-7 Device- and RDP-Specific Line Settings
Step 5. Add a remote destination (mobile

phone number or home phone
number) to the RDP: Next, you can define
the remote destination by clicking on Add a
New Remote Destination (shown previously
in Figure 7-5). When you add the remote
destination, you must give it a name and
destination. The destination configured here
is the phone number of the remote phone.
Figure 7-8 shows the name and destination
for the setup used to write this book.
Figure 7-8 Name and Description for a Remote
Destination
Depending on the call routing configuration,

you may or may not need to define the dial-
out number before the remote destination
number. In this example, there is an 8 in
front of the user’s mobile number
(4085557890) because the translation
pattern required to route this call starts with
an 8. That translation pattern strips the 8 and
prefixes +1 to create a +E.164 number for
presentation to the service provider. The
translation pattern and route pattern
configurations are shown in Figure 7-9.
Figure 7-9 Translation and Route Pattern Settings
Step 6. Enable the Line Association

Checkbox: When you save the remote
destination configuration, the page refreshes
to include directory number(s) from the RDP
and a checkbox to enable the line association
between the remote destination and the
directory number(s) as shown in Figure 7-10.
By default, this checkbox is not checked;
however, it must be checked for the remote
destination to ring when a call comes into the
RDP’s directory number.
Figure 7-10 Line Association Checkbox
Success! The configuration is complete. Make a test call

to the directory number associated with the end-user’s
RDP to confirm the work phone and remote destination
both ring.
Note
After a directory number and remote destination are configured on the RDP,
the directory number page shows a new field titled Associated Remote
Destinations. This field displays the remote destination(s) found on the RDP.
Something important about this field is that it appears on the directory number
page even if nobody puts a check in the Line Association checkbox (shown
earlier in Figure 7-10). Do not reference the Associated Remote Destination
field on the directory number page to confirm the remote destination has been
correctly associated to the line. To be sure the Line Association checkbox is
enabled when troubleshooting SNR, navigate to the remote destination page
for confirmation. Figure 7-11 and Figure 7-12 show the directory number page
before and after the RDP has a directory number and remote destination
added.
Figure 7-11 Directory Number Page Before RDP Has a
Line and Remote Destination
Figure 7-12 Directory Number Page After RDP Has a

Line and Remote Destination
To quickly create a remote destination profile with some

configurations pulled from the desk phone, you can
select Copy to Remote Destination Profile from the
Related Links dropdown, as shown in Figure 7-13.
Figure 7-13 Copying a Phone to an RDP
Advanced Single Number Reach Configuration

When using SNR, keep the following in mind:
• Mobile phones may send calls directly to voicemail

at times (for example, situations where mobile
service is unavailable or the device is powered off).
• Be aware of the time of day users want to receive

calls on their mobile phone. For example, a user
might not want to receive calls on a remote
destination outside business hours or on weekends.
• Some users might want to block a call to the remote

destination if the calling party is a specific number.
The next two sections detail how we can handle these

situations using more advanced SNR configuration
parameters, including SNR Timers, SNR Ring Schedule,
and SNR Access Lists. This section also covers other
lesser-known advanced SNR topics, such as Inbound
Remote Destination Caller ID and Intelligent Session
Control.
SNR Timers
This section reviews the timers associated with a remote
destination. In Figure 7-14, the first timer listed in the
Timer Information box of the Remote Destination
Configuration page is called the Delay Before Ringing
timer. This timer determines how long Unified CM will
wait before extending the call to the remote destination.
The Delay Before Ringing timer is measured in seconds
and the default value is 4. While you review the
CallManager SDL trace logs later in this chapter, you will
see when Unified CM performs digit analysis for the
remote destination number and how long it waits before
sending a SIP INVITE to the remote destination.
The second and third timers, the Answer Too Soon timer
and Answer Too Late timer, focus on preventing the
remote destination’s voicemail from answering the call.
The Answer Too Soon timer determines how long the
remote destination should ring before answering the call.
This timer can be set to a range of 0 to 10 seconds, with a
default of 1.5 seconds. If the remote destination answers
the call before the call rings long enough, Unified CM
does not allow the call to connect with the remote
destination and instead continues ringing the desk
phone. This time addresses situations in which a remote
destination call is forwarded straight to voicemail rather
than ringing.
The Answer Too Late timer is very similar to the Answer

Too Soon timer, but it determines when Unified CM
should stop ringing the remote destination in order to
prevent the remote destination’s voicemail system from
answering the call after ringing for a long time. The
Answer Too Late timer time is measured in seconds, and
valid entries are 0 or a number from 10 to 300. When the
Answer Too Soon timer or Answer Too Late timer is set
to 0, the timer is disabled.
Figure 7-14 Remote Destination Timer Information
Figure 7-14 shows a timeline of these default timers

overplayed with a standard U.S. ringing cycle of 6
seconds (2 seconds of ringback with 4 seconds of
silence). Note the following in this timeline:
• The Delay Before Ringing timer stops after the

configured 4 seconds.
• The Answer Too Soon timer and Answer Too Late

timer do not start until the Delay Before Ringing
timer ends.
• The Forward No Answer timer references the

default No Answer Ring Duration setting
configured on the directory number. The default
value of 12 seconds is used in this example. When
this timer ends, the call is forwarded based on the
configured Forward No Answer settings of the
directory number. The No Answer Ring Duration
timer can be configured on the directory number or
left blank to assume the CallManager Service
Parameter configuration.
The following are examples of common scenarios

observed with SNR timers:
• If the remote destination answers within the

Answer Too Soon timer, the call is pulled back from
SNR, and the enterprise desk phone continues
ringing. This is usually observed when the remote
destination voicemail answers without the remote
destination phone ringing.
• If the remote destination answers the call before

the Answer Too Late timer expires, the enterprise
desk phone stops ringing, and the call is connected
to the remote destination.
• If the enterprise desk phone answers the call before

the Forward No Answer timer ends, the call is
connected to the enterprise desk phone and the
remote destination stops ringing.
• If the Forward No Answer timer expires, the Ring

No Answer configurations redirect the call. To
prevent the remote destination’s voicemail from
answering the call, the Ring No Answer timer
should be less than the amount of time it takes for
the remote destination’s voicemail to answer the
call.
• If the Answer Too Late timer has ended (assuming

that the Forward No Answer timer has not ended
first), Unified CM will tell the remote destination to
stop ringing (by sending a SIP CANCEL to the
remote destination). The enterprise desk phone
continues ringing until the Forward No Answer
timer expires.
• Sometimes a user may request that the SNR remote

destination voicemail answer the call rather than
use the Ring No Answer settings of the line. In such
a scenario, you can set the Forward No Answer and
Answer Too Late timers to a large value; therefore,
the remote destination’s voicemail has plenty of
time to answer the call before the Forward No
Answer and Answer Too Late timers expire.
SNR Ring Schedule

As mentioned earlier, some users might not want their
mobile phones ringing at all hours. The Ring Schedule
configuration section makes it possible to define times
when a remote destination should ring and should not
ring. Figure 7-15 shows the default ring schedule
settings. You can define the entire day or select a range of
time by specifying the start and stop times. The start and
stop time inputs are formatted as 24-hour (HH:MM) 15-
minute increments.
Figure 7-15 Ring Schedule
SNR Access Lists

Imagine two scenarios that might arise when
implementing SNR:
• You might need to restrict specific numbers from
reaching the remote destination number when
someone calls the desk phone.
• You might want to permit certain calling numbers

to reach a remote destination; you want all other
calling numbers to ring the desk phone but not the
remote destination, essentially disabling the SNR
feature for most calls.
Either of these scenarios can be achieved by applying

access lists to the remote destination in the
configuration page section When Receiving a Call During
the Above Ring Schedule. The default configuration is
shown in Figure 7-16. Creating access lists is not very
intuitive because you must first navigate to Cisco Unified
CM Administration > Call Routing > Class of Control >
Access List. Once on the access list configuration page,
you need to provide a name for the access list and select
whether it is for allowing or blocking. After you save the
access list, you can add members to it, as shown in
Figure 7-17.
Figure 7-16 Applying Access Lists to a Remote

Destination
Figure 7-17 Adding Members to an Access List
When adding an access list member, you must provide

the filter mask and the directory number mask. The filter
mask is dependent on the caller ID of the calling party,
and there are three options available:
• Directory Number
• Not Available
• Private
If you choose Directory Number, you need to provide a

number, a wildcard, or a combination of the two in the
DN Mask field. However, the DN Mask field is grayed out
if you chose Not Available or Private because all calls will
be caught by the access list when the caller ID is
unavailable or marked as private.
The following wildcards are available for the directory

number mask:
• X or x to match a single digit
• ! to match any number of digits, either at the

beginning or end of the pattern (This character can
only be used once in a pattern.)
• # to indicate an exact match for a single digit
After you finish creating an access list, you can navigate

to the remote destination and apply the access list to the
configuration section shown in Figure 7-16.
Inbound Remote Destination Caller ID and Intelligent

Session Control
Consider these two key SNR scenarios:
• Calls placed from the remote destination number to

an internal phone number; for example, a call from
the user’s mobile number to their co-worker’s desk
phone.
• Calls placed from an internal number directly to a

remote destination; for example, a call from a co-
worker’s desk phone to the user’s mobile number.
When someone places a call from a remote destination to

a phone number that is internal, the call comes into the
corporate environment and reaches Unified CM. Unified
CM extends the call to the called number; however,
Unified CM changes the calling party information to
reflect the desk phone that is associated with the remote
destination rather than showing the remote destination
as the calling party. Figure 7-18 illustrates this call flow,
which includes the following steps:
Figure 7-18 Inbound Call from a Remote Destination
Step 1. The remote destination calls 1001’s full

number to reach the internal phone from
outside the network.
Step 2. The call enters the network and is sent to

Unified CM.
Step 3. Unified CM notices that the calling party,

+1-408-555-7890, matches a remote
destination.
Step 4. Unified CM extends the call to 1001 as if it is

from the desk phone at 1000.
Step 5. The phone at 1001 displays caller ID that

reflects the desk phone at 1000.
Note
The phone with DN 1000 is not engaged in the call, but extension 1000 on the
desk phone shows as a shared line in use remotely. This is because the line on
the RDP is a shared line.
Two service parameters affect this inbound calling party

matching: Matching Caller ID with Remote Destination
and Number of Digits for Caller ID Partial Match (see
Figure 7-19). You can find them by navigating to Cisco
Unified CM Administration > System > Service
Parameters > Server > Cisco CallManager. The options
for Matching Caller ID with Remote Destination are
Complete Match and Partial Match. When this
parameter is set to Partial Match, you can specify how
many digits must match by modifying the service
parameter Number of Digits for Caller ID Partial Match.
When using partial match with a requirement to match 7
digits, the last seven digits are considered. For example,
when the calling party is +1-408-555-7890, the digits
555-7890 must match a remote destination. The
minimum number of digits allowed for this parameter is
3, and the maximum is 24.
Figure 7-19 Inbound Calling Party Match Service
Parameters
In the scenario in which someone places a call from

within the internal network to a remote destination,
Unified CM can route the call to the desk phone rather
than to the remote destination. This is known as
Intelligent Session Control. To use Intelligent
Session Control, you must navigate to Cisco Unified CM
> Cisco CallManager. Then, in the service parameter
configuration, you locate the section Clusterwide
Parameters (Feature - Reroute Remote Destination Calls
to Enterprise Number). Figure 7-20 shows this section,
which includes the parameter Reroute Remote
Destination Calls to Enterprise Number.
Figure 7-20 Reroute Remote Destination Calls to

Enterprise Number Service Parameter
When Reroute Remote Destination Calls to Enterprise

Number is set to True, Unified CM routes calls to the
desk phone rather than to the remote destination. As
with most other settings, it is advisable to restart the
phone after a configuration change to ensure the phone
is updated with the latest information from Unified CM.
Figure 7-21 shows a call flow using Intelligent Session
Control:
Figure 7-21 Intelligent Session Control Call Flow
Step 1. The user at 1001 calls the remote destination

(+14085557890).
Step 2. Unified CM notices the called party

+14085557890 matches a remote
destination; furthermore, the remote
destination is associated with the internal
directory number 1000.
Step 3. Unified CM routes the call to the desk phone

at 1000 instead of the remote destination.
Note
Intelligent Session Control is considered a security concern because someone
can use this feature to intercept calls meant for another person and redirect
them.
Troubleshoot Single Number Reach

After configuring SNR, you can verify the feature is
working by placing a test call to the desk phone and
seeing if the remote destination rings. It is important to
wait long enough for the timers when testing SNR as the
call is only extended to the remote destination after the
Delay Before Ringing time is met.
Note
When troubleshooting SNR, it is important to keep in mind the sequence of
events shown earlier in this chapter in Figure 7-1.
Consider the following recommendations when
troubleshooting SNR:
• Validate the configuration using the steps and

screenshots from the previous section as a
reference.
• Place a test call to reproduce the issue and then

collect CallManager SDL trace logs for analysis, as
described in this section.
The following mistakes commonly occur with SNR

configurations:
• No Rerouting Calling Search Space is applied to the

RDP.
• The Line Association checkbox is not selected on

the RDP.
• The remote destination does not match a pattern

for routing the call.
• Enable Mobility is not selected on the end-user

configuration page.
Figure 7-22 illustrates a sample call flow where a call is

answered at the remote destination. Notice that when the
user hangs up the mobile phone, the calling party is put
on hold because the Desk Pickup feature is enabled.
Note
Remember when a user hangs up their mobile phone and resumes the call on
their desk phone, this is called Desk Pickup. If the calling party hangs up, the
call terminates completely. The ability to transition between devices applies
only when the called party (the remote destination) hangs up and the calling
party waits for the end user to resume the call on their desk phone.
Figure 7-22 SNR Sample Call Flow

You can collect CallManager SDL trace logs from Unified
CM to confirm the system is routing calls properly.
Example 7-1 through Example 7-10 detail the following
steps, which relate to Figure 7-22.
Note
A lot of text has been removed from the SIP messages and other parts of the
log snippets throughout this chapter. This was done for brevity and to focus on
the important sections of the logs.
Step 1. Unified CM receives a SIP INVITE from IP

Phone A (1001) with the called party being IP
Phone B (directory number 1000). Unified
CM performs digit analysis on the called
number to locate a callable device (see
Example 7-1).
Note
For more information about the digit analysis process, refer to Chapter 4.
Example 7-1 CallManager SDL Trace Analysis for SNR,

Snippet 1

[606276,NET]
INVITE sip:1000@sj-cucm.ccnpcollab.lab;user=phone SIP
From: “1001" <sip:1001@sj-cucm.ccnpcollab.lab>;tag=d0
Call-ID: d0ec35ff-ebc4001c-66ccd3c8-5a691abc@14.50.21
CSeq: 101 INVITE
Contact: <sip:64ec99aa-a2d0-4bc7-b17d-47c547fdc3e9@14
Remote-Party-ID: “1001” <sip:1001@sj-cucm.ccnpcollab.
Content-Disposition: session;handling=optional

m=audio 16598 RTP/AVP 114 9 124 113 115 0 8 116 18 10
c=IN IP4 14.50.214.106
a=sendrecv

|CallingPartyNumber=1001
|DialingPartition=partition_for_dn_1000
|DialingPattern=1000
|FullyQualifiedCalledPartyNumber=1000
|DialingPatternRegularExpression=(1000)
Step 2. Unified CM finds two callable devices: the IP

phone SEPC4B36ABA1B5A associated to the
line and the remote destination profile (RDP)
pkinane_RDP associated with the line. Notice
the trace logs shown in Example 7-2, this is in
the format remotedestination_rdpname.
This helps find where the RDP is engaged in
the trace logs.

Snippet 2
04827752.001 |15:37:31.042 |AppInfo |LineCdpc(39): -

04827752.002 |15:37:31.042 |AppInfo |LineCdpc(39): -
Step 3. Unified CM checks the time zone, date, and

day of the week then looks for any active
access lists to determine if the call should
move forward as displayed in Example 7-3. In
this scenario, IP Phone A is permitted to call
the remote destination. Note that the
DayOfWeek value is a number rather than a
name. The call occurred on a Friday, and thus
number 5 (the week starts on Sunday, which
has the value 0). Unified CM also prints the
remote destination dump (RemDest dump),
which includes the value of the Delay Before
Ringing Timer; however, the value is listed
here in milliseconds.
Snippet 3
04827753.004 |15:37:31.049 |AppInfo |TODAccessHelper

04827753.007 |15:37:31.050 |AppInfo |SNRD::wait_CcSe
04827754.006 |15:37:31.060 |AppInfo |DbMobility - Re
Step 4. Unified CM performs a digit analysis for the

remote destination number +14085557890
(see Example 7-4). Note that a translation
occurs, and it is not visible in the trace logs.
This translation modifies 84085557890 into
the globalized +E.164 format
(+14085557890). Also notice that the digit
analysis occurs before any of the SNR timers
mentioned previously in the chapter.

Snippet 4

|CallingPartyNumber=+14085251001
|DialingPartition=
|DialingPattern=+!
|FullyQualifiedCalledPartyNumber=+14085557890
|DialingPatternRegularExpression=(+[0-9]+)
Step 5. Unified CM extends the call to IP Phone B.

The signaling and logs from this call leg are
truncated in Example 7-5 to focus on the
aspects of SNR in the trace logs.

Snippet 5

[606281,NET]
From: <sip:1001@172.18.110.61>;tag=313455~bbab2af3-f2
Call-ID: 2db73d00-10001-46f88-93f492a@172.18.110.61
CSeq: 101 INVITE
Remote-Party-ID: <sip:1001@172.18.110.61;x-cisco-call
Step 6. After 4 seconds of ringing IP Phone B, the

SdlTimerService sends a notification that the
4 second Delay Before Ringing timer has
expired. Then Unified CM sends SJ CUBE an
INVITE message to call the remote
destination at +14085557890 (see Example
7-6). Remember this was decided in step 4
during the digit analysis action. Here you can
also confirm that the remote destination
answers the call, as indicated by the 200 OK
message received from CUBE. The call sent to
IP Phone B is terminated with a SIP CANCEL
message, which is not shown in the trace
snippets in this chapter (although it is present
in the trace logs collected from Unified CM).

Snippet 6
04827855.000 |15:37:35.107 |SdlSig |DelayBeforeRing

[606284,NET]
INVITE sip:+14085557890@sj-cube.ccnpcollab.lab:5060 S
From: <sip:+14085251001@172.18.110.61>;tag=313456~bba
To: <sip:+14085557890@sj-cube.ccnpcollab.lab>
Call-ID: 30199700-10001-46f89-0@172.18.110.61
CSeq: 101 INVITE
P-Asserted-Identity: <sip:+14085251001@172.18.110.61>
Remote-Party-ID: <sip:+14085251001@172.18.110.61>;par

[606292,NET]
SIP/2.0 200 OK
From: <sip:+14085251001@172.18.110.61>;tag=313456~bba
To: <sip:+14085557890@sj-cube.ccnpcollab.lab>;tag=B7C
Call-ID: 30199700-10001-46f89-0@172.18.110.61
CSeq: 101 INVITE
Server: Cisco-SIPGateway/IOS-16.12.1a

c=IN IP4 172.18.110.62
c=IN IP4 172.18.110.62
Step 7. The call remains active until one of the

endpoints hangs up. In Example 7-7, the
remote destination hangs up, and Unified CM
receives a SIP BYE message to end the call
with the mobile phone; however, the call is
not completely done yet.

Snippet 7
[606308,NET]
BYE sip:+14085251001@172.18.110.61:5060;transport=tcp
Via: SIP/2.0/TCP 172.18.110.62:5060;branch=z9hG4bK1A4
From: <sip:+14085557890@sj-cube.ccnpcollab.lab>;tag=B
To: <sip:+14085251001@172.18.110.61>;tag=313456~bbab2
Call-ID: 30199700-10001-46f89-0@172.18.110.61
CSeq: 101 BYE
Reason: Q.850;cause=16
Step 8. Instead of completely disconnecting the call

with IP Phone A, Unified CM places IP Phone
A on hold. Before IP Phone A can be placed
on hold, A SIP re-INVITE message is sent
from Unified CM to IP Phone A tearing down
the media as shown in Example 7-8. Note the
quad-zero connection IP address (0.0.0.0)
and a=inactive, indicating the media is being
torn down. Hold concepts and resume
concepts are discussed in detail in Chapter 9,
“CUBE Interworking Features.”

Snippet 8
04828249.000 |15:37:56.441 |SdlSig |CcHoldInd

[606309,NET]
INVITE sip:64ec99aa-a2d0-4bc7-b17d-47c547fdc3e9@14.50
From: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=313453~bb
To: “1001” <sip:1001@sj-cucm.ccnpcollab.lab>;tag=d0ec
Call-ID: d0ec35ff-ebc4001c-66ccd3c8-5a691abc@14.50.21
CSeq: 102 INVITE
Remote-Party-ID: <sip:1000@172.18.110.61>;party=calli

c=IN IP4 0.0.0.0
a=inactive
Step 9. IP Phone B is provided the option to use the

Desk Pickup feature when Unified CM sends
a SIP NOTIFY message to IP Phone B (see
Example 7-9). This NOTIFY message lets the
phone know there is a call available for the
Desk Pickup feature.

Snippet 9

[606313,NET]
NOTIFY sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@14.50
From: <sip:172.18.110.61>;tag=1610814960
To: <sip:1000@14.50.214.108>
Call-ID: 3c9def80-10001-46f8d-e3b038a0@172.18.110.61
CSeq: 101 NOTIFY
Max-Forwards: 70
Date: Fri, 17 Jan 2020 20:37:56 GMT
Event: dialog
Contact: <sip:172.18.110.61:5060;transport=tcp>
Content-Type: application/dialog-info+xml
Content-Length: 971
<dialog-info xmlns="urn:ietf:parmams:xml:ns:dialog-in
xmlns:call="urn:x-cisco:parmams:xml:ns:dialog-info:d
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
version="8” state="partial” entity="sip:1000@172.18.
<dialog id="39” call-id="9@172.18.110.61” local-tag
<state>confirmed</state>
<call:instance>1</call:instance>
<call:orientation>From</call:orientation>
<call:lock>unlocked</call:lock>
<duration>25</duration>
<call:gci>1-6020</call:gci>
<local>
<identity display="">sip:1000@172.18.110.61:506
<target uri="sip:1000@172.18.110.61:5060">
<param pname="+sip.rendering” pval="no"/>
</target>
</local>
<remote>
<identity display="">sip:1001@172.18.110.61:506
</remote>
</dialog>
</dialog-info>
Step 10. IP Phone B sends Unified CM an INVITE

message, and then Unified CM sends the
phone a 200 OK message in response (see
Example 7-10). Although the example does
not show it, Unified CM sends a re-INVITE
message to IP Phone A to take IP Phone A off
hold and connect IP Phone A with IP Phone
B.

SNR, Snippet 10

[606316,NET]
INVITE sip:1001@sj-cucm.ccnpcollab.lab;user=phone SIP
From: “pkinane desk phone” <sip:1000@sj-cucm.ccnpcoll
Call-ID: c4b36aba-1b5a0010-0a6aef56-4eb856a0@14.50.21
CSeq: 101 INVITE
Contact: <sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@14
Replaces: 9@172.18.110.61;to-tag=bbab2af3-f2b4-4a8c-a
Remote-Party-ID: “pkinane desk phone” <sip:1000@sj-cu

m=audio 25846 RTP/AVP 114 9 124 113 115 0 8 116 18 10
c=IN IP4 14.50.214.108
a=sendrecv

[606325,NET]
SIP/2.0 200 OK
From: “pkinane desk phone” <sip:1000@sj-cucm.ccnpcoll
To: <sip:1001@sj-cucm.ccnpcollab.lab>;tag=313464~bbab
Call-ID: c4b36aba-1b5a0010-0a6aef56-4eb856a0@14.50.21
CSeq: 101 INVITE
Contact: <sip:1001@172.18.110.61:5060;transport=tcp>;

c=IN IP4 14.50.214.106
Example 7-11 shows the CallManager trace logs related to

the SNR timers for two calls. Using these trace snippets
as a point of reference, you can see what is occurring
with the SNR timers, such as the Call Forward No
Answer of the Line, SNR Delay Before SNR Ringing, SNR
Answer Too Soon, and SNR Answer Too Late timers. The
first test call illustrates the 4-second Delay Before
Ringing timer and then the Answer Too Soon timer. This
call was never answered, so the IP phone’s Call Forward
No Answer timer canceled the call to all devices after 12
seconds of ringing.
The second test call still uses the default SNR timers, but
the Forward No Answer timer on the line has been
changed from the default value to 36 seconds. Since this
timer is larger than the SNR Delay Before Ringing and
SNR Answer Too Late timers, the remote destination
stops ringing before the IP Phone stops ringing. Twenty-
three seconds into the call (Delay Before Ringing [4] +
Answer Too Late [19] = 23), you can see the remote
destination call is cancelled. At the 36-second mark, the
Forward No Answer timer expires, and that call is
canceled.
Example 7-11 Default SNR Timers in the Trace Logs
### Test Call 1, default Unified CM Timers

### Default SNR Timers are set
### Unified CM sets the Call Forward No Answer timer and

sends an INVITE to the IP Phone
00392320.002 |11:17:03.062 |AppInfo |Forwarding - st

INVITE sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14.50
### 4 seconds later, the Delay Before Ringing timer ends

and Unified CM extends the call to SNR RD

INVITE sip:5555@172.18.110.65:5060 SIP/2.0
### Answer Too Soon Timer Ends
00392415.000 |11:17:08.577 |SdlSig |Answer2SoonTime
### The Call Forward No Answer ends at 12 seconds and Uni

fied CM sends a SIP CANCEL all devices
00392425.000 |11:17:15.066 |SdlSig |ForwardNoAnswer

CANCEL sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14.50

CANCEL sip:5555@172.18.110.65:5060 SIP/2.0
-----------------------------------------------------
### Test Call 2, default SNR Timers but 36 second Call Fo

rward No Answer Timer
### Default SNR Timers are set

### Unified CM sets the Call Forward No Answer timer and
sends an INVITE to the IP Phone
00393288.002 |11:20:05.228 |AppInfo |Forwarding - st

INVITE sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14.50
### 4 seconds later, the Delay Before Ringing timer ends

and Unified CM extends the call to SNR RD

INVITE sip:5555@172.18.110.65:5060 SIP/2.0
### After 19 seconds the SNR Answer Too Late Timer expire
s and the call to the SNR RD is cancelled. Total time of
the call so far is 23 seconds.
00393423.000 |11:20:28.248 |SdlSig |AnswerTooLateTi

CANCEL sip:5555@172.18.110.65:5060 SIP/2.0
### The Call Forward No Answer ends at 36 seconds and Uni

fied CM sends a SIP CANCEL to the IP Phone
00393468.000 |11:20:41.242 |SdlSig |ForwardNoAnswer

CANCEL sip:ef63152f-917c-4f6b-881f-d1c0bed01604@14.50
Configure and Verify Move to Mobile

Imagine that you are engaged in an important
conference call on your enterprise desk phone, but you
need to step out of the office. Normally you would need
to disconnect from the desk phone and rejoin the call
from your mobile phone; however, the Move to Mobile
feature allows users to transition the call from the desk
phone to the mobile phone through a simple button
press. It is essentially the reverse of Desk Pickup,
described earlier.
The Move to Mobile feature is closely related to SNR, and
configuring this feature involves the same configuration
as SNR; however, you do not need to check the SNR box
on the Remote Destination Configuration page in order
for Move to Mobile to work (see Figure 7-23). However,
many organizations have Move to Mobile and Single
Number Reach configured at the same time, and in such
scenarios, both the SNR checkbox and Move to Mobile
checkbox are checked.
Figure 7-23 Move to Mobile Does Not Require SNR
When you have finished configuring Move to Mobile, you

need to add the Mobility softkey to the phone. To add the
softkey, navigate to Cisco Unified CM Administration >
Device > Device Settings > Softkey Template. At this
point, you can add the softkey to an existing template or
create a new one. This section shows how to create a new
template named Mobility_User. To create a new
template, on the Softkey Template page, click Add New
then, as shown in Figure 7-24, select the template you
want to use as a basis for your new template (for
example, Standard User).
Figure 7-24 Copying the Standard User Template

When your new template is saved to the system, make
sure Related Links is set to Configure Softkey Layout, as
shown in Figure 7-25, and click Go.
Figure 7-25 Configuring the Softkey Layout
Two call states include the Mobility softkey: On Hook

and Connected. To use Move to Mobile, the Mobility
softkey must be added to the Connected call state, as
shown in Figure 7-26 and Figure 7-27.
Figure 7-26 Connected Call State Without the Mobility

Softkey
Figure 7-27 Connected Call State with the Mobility

Softkey
When the new template is added to the phone, and the
phone is connected to a call, you should see the Mobility
option on the phone, as shown at the bottom of Figure 7-
28.
Figure 7-28 Connected Call Showing the Mobility

Softkey
When the Mobility softkey is clicked, the user is

prompted to make a selection, as shown in Figure 7-29.
If the user chooses to send the call to a mobile phone, the
desk phone returns to the connected call while waiting
for the mobile phone to answer.
Figure 7-29 Mobility Selection
Note
The Mobility softkey has two functions. If the Mobility softkey is added to the
On Hook call state, it can be used to enable/disable SNR; however, the phone
screen says Mobile Connect because SNR was formerly known as Mobile
Connect. If SNR is disabled, and the Mobility softkey is added to the On Hook
call state, the user can enable SNR by using the softkey. The second function
is to move connected calls from the desk phone to the mobile phone, as
previously illustrated.
Troubleshoot Move to Mobile

Move to Mobile is so closely related to SNR that
troubleshooting is essentially the same. When
troubleshooting Move to Mobile, consider the following
recommendations:
• Validate the configuration by using the screenshots

and text in this chapter for reference.
• Place a test call to reproduce your issue and then

collect CallManager SDL trace logs for analysis.
• Collect a Problem Reporting Tool bundle from the
phone to make sure there is no issue on the phone.
• If needed, collect debugging information from your

SBC or voice gateway to perform analysis from that
point in the call flow.
This section looks at CallManager SDL trace logs for a

working Move to Mobile call as illustrated in Figure 7-30.
The following analysis shows that the call between
extension 1001 and extension 1000 is already connected,
and the user at 1000 uses Move to Mobile by pressing
the Mobility softkey to transition the call to their mobile
phone.
Figure 7-30 Move to Mobile Sample Call Flow
Note
Some signaling has been intentionally left out of Figure 7-30 and Examples 7-
12 through 7-20 for the sake of brevity.
The following steps detail what is happening at each

phase in Figure 7-30:
Step 1. When the user presses the Mobility softkey,

a REFER SIP message is sent to Unified CM
to make the server aware of the softkey
selection. The XML message body within this
REFER message contains the softkey event
Mobility (see Example 7-12).

Move to Mobile, Snippet 1

[21878,NET]
REFER sip:172.18.110.61 SIP/2.0
From: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=c4b36aba1
To: <sip:1001@172.18.110.61>
Call-ID: OutOfDialog--0008-30ae310d-7c6bb484@14.50.21
CSeq: 101 REFER
Referred-By: <sip:1000@sj-cucm.ccnpcollab.lab>
Refer-To: cid:44b1abd0@14.50.214.108
Content-Type: application/x-cisco-remotecc-request+xm

<x-cisco-remotecc-request>
<softkeyeventmsg>
<softkeyevent>Mobility</softkeyevent>
</softkeyeventmsg>
</x-cisco-remotecc-request>
Step 2. Unified CM sends a REFER message to the

IP phone that includes an XML message body
which the IP phone will display on the screen
to the user (see Example 7-13). The user has
to make a selection at this point so the phone
knows what to do.


[21880,NET]
REFER sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@14.50.
Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27a
From: <sip:1000@172.18.110.61>;tag=587273788
To: <sip:1000@14.50.214.108>
Call-ID: 13d4f000-10001-2781-400000@172.18.110.61
CSeq: 101 REFER
Refer-To: cid:1234567890@172.18.110.61
Content-Id: <1234567890@172.18.110.61>
Referred-By: <sip:1000@172.18.110.61>
Content-Type: multipart/mixed; boundary=uniqueBoundar
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-cm+xml
<?xml version="1.0” encoding="ISO-8859-1” ?><CiscoIPP
--uniqueBoundary--
Step 3. When the user selects the option Send Call

to Mobile Phone, the IP phone sends
another REFER message to Unified CM so
the server is aware of the selection (see
Example 7-14). This is indicated by the value
101 in the second REFER message’s body.
You can also see that the Unified CM trace log
states 101 Perform CellPickup(Send a call to
Mobile Phone), which describes the 101 in the
previous SIP REFER message.


[21887,NET]
REFER sip:sj-cucm.ccnpcollab.lab SIP/2.0
From: “pkinane desk phone” <sip:1000@14.50.214.108>;t
To: <sip:sj-cucm.ccnpcollab.lab>
Call-ID: c4b36aba-1b5a0004-788c1af7-4f03fc27@14.50.21
CSeq: 1000 REFER
Accept: application/x-cisco-remotecc-response+xml
Referred-By: “pkinane desk phone” <sip:1000@14.50.214
Refer-To: cid:55239feb@14.50.214.108
Content-Id: <55239feb@14.50.214.108>
Content-Type: multipart/mixed; boundary=uniqueBoundar
--uniqueBoundary

<datapassthroughreq>
<applicationid>0</applicationid>
<transactionid>16777240</transactionid>
<stationsequence>StationSequenceLast</stationsequ
<displaypriority>0</displaypriority>
<appinstance>0</appinstance>
<routingid>0</routingid>
<confid>29154853</confid>
</datapassthroughreq>
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-cm+xml
101
--uniqueBoundary–
##### 09:40:11.434 || Unified CM to Perform CellPickup(Se

nd a call to Mobile Phone)
00225706.002 |09:40:11.434 |AppInfo |MKI::( 3)w
Step 4. Unified CM searches for an appropriate

remote destination number. Once found,
Unified CM performs a digit analysis on the
remote destination number to find the
callable device and, ultimately, where to
extend the call (see Example 7-15). If this
succeeds, Unified CM sends an INVITE
message to the remote destination through
CUBE to the ITSP.

00225706.003 |09:40:11.435 |AppInfo |DbMobilityHelpe

00225706.004 |09:40:11.435 |AppInfo |DbMobilityHelpe

|CallingPartyNumber=+14085251001
|DialingPartition=
|DialingPattern=+!
|FullyQualifiedCalledPartyNumber=+14085557890
|DialingPatternRegularExpression=(+[0-9]+)

[21889,NET]
INVITE sip:+14085557890@sj-cube.ccnpcollab.lab:5060 S
From: <sip:+14085251001@172.18.110.61>;tag=11449~bbab
To: <sip:+14085557890@sj-cube.ccnpcollab.lab>
Call-ID: 15061d00-10001-2782-0@172.18.110.61
CSeq: 101 INVITE
P-Asserted-Identity: <sip:+14085251001@172.18.110.61>
Step 5. Unified CM receives a 200 OK message from

CUBE, which indicates that the remote
destination has answered the call successfully
and is ready to receive media (see Example 7-
16).


[21894,NET]
SIP/2.0 200 OK

From: <sip:+14085251001@172.18.110.61>;tag=11449~bbab
To: <sip:+14085557890@sj-cube.ccnpcollab.lab>;tag=EF2
Call-ID: 15061d00-10001-2782-0@172.18.110.61
CSeq: 101 INVITE

c=IN IP4 172.18.110.62
c=IN IP4 172.18.110.62
Step 6. Unified CM sends a re-INVITE message to

the calling phone and the desk phone to tear
down media between them. To do this, a SIP
INVITE message with a=inactive and the
connection 0.0.0.0 is sent to the endpoints
(see Example 7-17).


[21902,NET]
Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27b
From: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=11430~bba
Call-ID: d0ec35ff-ebc40006-4882433b-7b671eee@14.50.21
CSeq: 101 INVITE
Remote-Party-ID: “pkinane desk phone” <sip:1000@172.1
Contact: <sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@17
c=IN IP4 0.0.0.0
a=inactive

[21903,NET]
To: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=c4b36aba1b5
Call-ID: f2740400-10001-2778-93f492a@172.18.110.61
CSeq: 102 INVITE
Contact: <sip:64ec99aa-a2d0-4bc7-b17d-47c547fdc3e9@17
c=IN IP4 0.0.0.0
a=inactive
Step 7. The desk phone is no longer needed in the

call because the remote destination has
answered. Therefore, Unified CM sends a
BYE message to the desk phone (see Example
7-18).


[21910,NET]
BYE sip:4fe4f35a-a0a9-4b7a-a8c5-c18de4d3e277@14.50.21
To: <sip:1000@sj-cucm.ccnpcollab.lab>;tag=c4b36aba1b5
Call-ID: f2740400-10001-2778-93f492a@172.18.110.61
Step 8. Unified CM sends an UPDATE message to

the calling phone to let the caller know they
will now be connected to the mobile phone.
This results in Caller ID updates appearing on
the screen of the calling phone that reflect the
remote destination number instead of the
desk phone’s number (see Example 7-19).


[21912,NET]
UPDATE sip:64ec99aa-a2d0-4bc7-b17d-47c547fdc3e9@14.50
CSeq: 102 UPDATE
Contact: <sip:+14085557890@172.18.110.61:5060;transport=t
cp>
Step 9. Unified CM sends a re-INVITE message to

the calling phone to continue the process of
establishing media between the calling phone
and the mobile phone (see Example 7-20).
This is needed because Unified CM tore down
media in step 6. The signaling process (200
OK and ACK) continues until media is
established between the calling phone and
the remote destination.

##### 09:40:18.659 || Unified CM sends 1001 an invite

[21917,NET]
CSeq: 103 INVITE
CONFIGURE AND VERIFY EXTENSION
MOBILITY
Extension Mobility is a feature that allows more than
one person to use the same phone while maintaining
their individual settings; for example, they can maintain
their phone number instead of sharing a phone number
with other people. Extension Mobility is most often used
in call centers and open concept office spaces where
people do not have dedicated workstations but instead
share a workstation with other people. This section
discusses how to configure Extension Mobility, how to
confirm that it is functioning correctly, how to tweak
Extension Mobility service parameters, and the purpose
of the default device profile.
Configuring Extension Mobility involves the following

steps:
Step 1. Create a user that will be used for testing

Extension Mobility.
Step 2. Confirm that the appropriate Extension

Mobility services are in an operational state.
Step 3. Create a phone service for Extension

Mobility.
Step 4. Set up the phone to be Extension Mobility

enabled and subscribe the phone to the
Extension Mobility phone service.
Step 5. Create a device profile and subscribe it to the

Extension Mobility service.
Step 6. Associate the end user with the device

profile.
Step 7. Test logging in and logging out of the phone.
The example in this section illustrates the creation of a

user named test_em. To create this user, navigate to
Cisco Unified CM Administration > User Management >
End User and click Add New. Then give the new user the
following settings:
User ID: test_em

Password: adgjm
PIN: 134679
Last Name: em
Next, you need to ensure that the Extension Mobility

service is activated and running. To do so, navigate to
Cisco Unified Serviceability > Tools > Control Center -
Feature Services. Look for Cisco Extension Mobility then
confirm it is started and activated. If the service is not
activated, navigate to Cisco Unified Serviceability > Tools
> Service Activation, select the Cisco Extension Mobility
service, and click save to activate it. Next, navigate to
Cisco Unified Serviceability > Tools > Control Center -
Network Services. Look for the Cisco Extension Mobility
application and confirm that it is running.
Moving forward, you need to create a custom phone

service for Extension Mobility. To create a phone service,
navigate to Cisco Unified CM Administration > Device >
Device Settings > Phone Services. Then click Add New.
There are a few fields on the IP Phone Services
Configuration page which are not strictly controlled. The
service name can be whatever you want to name it; in
this example, the name is EM. You can choose to include
a description or not; however, using a descriptive name
is often enough.
The service URL for Extension Mobility is

http://<Unified-
CM_ip_or_hostname>:8080/emapp/EMAppServl
et?device=#DEVICENAME#
It is important to note that http in the URL can be

changed to https, and the URL can be placed in the
Secure-Service URL field. The Enable checkbox is not
selected by default, but it is required to use the service,
so although this checkbox seems optional, it is not. The
Enterprise Subscription checkbox, however, is optional.
When it is selected, all devices in the cluster are
subscribed to the phone service in question.
Figure 7-31 shows the configuration for the service in this

section’s example. When you save the phone service, the
option to add parameters to the service is available. The
Extension Mobility service does not require any
parameters.
Figure 7-31 EM Phone Service Configuration
At this point, you need to configure the phone where the

user will use the login feature. Navigate to Cisco Unified
CM Administration > Device > Phone and find the phone
you want to use for testing. This chapter uses the phone
with extension 1001. While on the Phone Configuration
page, scroll down to the Extension Information section
and confirm that the checkbox Enable Extension
Mobility is checked (see Figure 7-32). If you made any
changes, such as enabling Extension Mobility on the
phone, be sure to click save. Next, select
Subscribe/Unsubscribe Services from the Related Links
dropdown and click Go.
Figure 7-32 Related Links
In the popup window that appears (see Figure 7-33),

select the EM phone service from the Select a Service
dropdown menu and click Next.
Figure 7-33 Subscribed IP Phone Services
The page in the popup window will refresh to look as

shown in Figure 7-34. At this point, you click Subscribe.
Figure 7-34 Subscribed IP Phone Services Refresh
The page in the popup window refreshes one more time

so that it looks as shown in Figure 7-35. Notice the phone
service is now listed in the Subscribed Service section.
Nothing else needs to be done in this window, and you
can close it.
Figure 7-35 The Phone Is Subscribed to EM
Next, you need to configure a device profile and

subscribe it to the EM service as well. To add a device
profile, navigate to Cisco Unified CM Administration >
Device > Device Settings > Device Profile and click Add
New. The device profile type, as shown in Figure 7-36,
may match the phone model where the user will log in. It
is ideal to match the device profile type with the phone
model, but this matching is not required (as discussed
later in this chapter).
Note
It is important to ensure that the device profile is subscribed to the phone
service for EM. If it is not, users who log in to EM will not be able to log out of
their profile due to the missing subscription on the device profile.
Figure 7-36 Device Profile Type
Click Next, and a new page opens with all the fields ready
to be populated for the device profile. Figure 7-37 shows
an example with the fields Device Profile Name, Phone
Button Template, and Softkey Template modified.
Figure 7-37 Device Profile Configuration
When the device profile is saved, it is possible to add a

directory number to it. The number used on this profile
is 3333, which makes it easy to tell if the login is
successful and the profile is applied to the desk phone.
Finally, the device profile needs to be subscribed to the
EM phone service using the same steps for the desk
phone (refer to Figures 7-32 through 7-35 for these
steps).
Now you need to associate the end user with the device
profile. To do this, you need to navigate back to the end
user (test_em in this case) and scroll down to the
Extension Mobility section. To associate the device
profile with the end user, move the profile from the
Available Profiles box to the Controlled Profiles box, as
Figure 7-38 End-User Controlled Profiles
Finally, you need to restart the phone to ensure that the

EM service you created is populated on the phone. After
you restart the phone, you can test logging in to the
phone by following these steps:
Step 1. Press the hard button on the phone that

shows a gear icon (see Figure 7-39).
Figure 7-39 Gear Icon Button
Step 2. When the Applications screen opens, select

the phone service, as shown in Figure 7-40.
Figure 7-40 Applications Screen Phone UI
Step 3. Enter the credentials for the user, as shown

in Figure 7-41, and press the Submit button.
Figure 7-41 User Login Credentials
The phone’s screen displays the login

response Login Successful, as shown in
Figure 7-42. The screen also informs the user
of a phone reset.
Figure 7-42 Phone Screen Successful Login
After the phone reset, the screen on the

phone shows the settings (directory number)
of the phone profile, as shown in Figure 7-43.
Figure 7-43 Phone Screen with Device Profile Directory
Number
You can determine whether a user is logged in to a phone

by accessing the phone’s configuration page in Unified
CM and checking the Extension Information section, as
shown in Figure 7-44. Also, you can log the user out from
this page as well.
Figure 7-44 Extension Information Phone

Configuration Page
Figure 7-45 shows the EM logout screen on the phone.

To log out of the profile, press the gear icon button,
select the phone service from the Applications page, and
press the Yes button.
Figure 7-45 Phone Screen Extension Mobility Logout
Tip
You can remotely test Extension Mobility login and logout by using a web
browser. To understand the following tests for logging in and logging out, you
need to know these prerequisites:
• The server running the EM service is sj-cucm.ccnpcollab.lab.
• The MAC address of the test phone is SEPC4B36ABA1B5A.
• The user ID of the test user is test_em.
• The pin of the test user is 134679.
Using this information, you can use the following URL to log in:
http://sj-
cucm.ccnpcollab.lab/emapp/EMAppServlet?
device=SEPC4B36ABA1B5A&userid=test_em&seq=134679
You can use this URL to log out:
http://sj-
cucm.ccnpcollab.lab/emapp/EMAppServlet?
device=SEPC4B36ABA1B5A&doLogout=true
As mentioned earlier in this section, it is not necessary to

match the device profile type with the phone model of
the desk phone. It is ideal to match them, but it is not
necessary. When the profiles don’t match, the default
device profile for the desk phone’s model is used. You
can find the default device profiles by navigating to Cisco
Unified CM Administration > Device > Device Settings >
Default Device Profile. The default device profiles are
added automatically for each model registered to a
cluster. You can create your own default device profiles,
per model, if you choose to. The value in creating a
default device is that you can make sure the proper
phone button templates, softkey templates, and other
settings are applied to the phone when a mismatched
profile is used to log in.
You can tweak parameters pertaining to Extension

Mobility by navigating to Cisco Unified CM
> Cisco Extension Mobility and clicking Advanced. The
page should look as shown in Figure 7-46.
Figure 7-46 Extension Mobility Service Parameters
The following parameters are often modified for

Extension Mobility due to their potential impact on the
system or security:
• Enforce Intra-cluster Maximum Login

Time: The default setting for this parameter is
False; however, you can set it to True in order to
prevent people from remaining logged in when
they’re likely no longer at work. The duration of
time is measured in hours; the default value is 0,
and the suggested value is 8 hours (specified as
8:00). The time is set in the parameter named
Intra-cluster Maximum Login Time.
• Maximum Concurrent Requests: The default

value is 15, which matches the suggested value, and
this parameter determines how many login and
logout operations the system can handle at the
same time. You can modify this value in order to
adjust the amount of system resources used by the
• Multiple Login Behavior: This parameter

specifies what occurs when a user attempts to log in
to a phone while their profile is already logged in to
another phone. The available values are Multiple
Logins Allowed, Multiple Logins Not Allowed, and
Auto Logout. When it is set to Multiple Logins
Allowed, the user can log in to multiple phones;
however, the user can only log in to a single phone
when the parameter is set to Multiple Logins Not
Allowed. When the parameter value is Auto Logout,
the user is permitted to log in to the phone but is
logged out of the other phone where their profile is
active.
• Validate IP Address: This parameter is set to

False by default. When set to True, Unified CM
validates the IP address of the source requesting
login or logout. It is important to note that when
the value is True, login and logout times are slightly
longer because it takes time for Unified CM to
validate the source.
Troubleshoot Extension Mobility

When people make mistakes setting up Extension
Mobility, they will likely make one of these common
misconfigurations:
• Not enabling the device for Extension Mobility
• Not enabling the user for Extension Mobility
• Not enabling the service when it is created
• Not subscribing the phone to the service, resulting

in the phone not being able to log in to Extension
Mobility or see the Extension Mobility service on
the phone
• Not subscribing the device profile to the service
Note
When the profile isn’t subscribed to the Extension Mobility service, the user
can log in to the phone but cannot log out of the phone. This is because the
Extension Mobility service is not present once the user profile is applied. Refer
to Figure 7-40 to recall what it looks like when it is present.
• Not associating the profile to the user
• Initial Trust List (ITL) issues preventing the phone

from connecting to a secure service URL
To troubleshoot Extension Mobility when the
configuration seems correct, it is important to know the
login flow. Before we discuss those details, let's discuss
the Services Provisioning enterprise parameter. You can
modify this parameter, shown in Figure 7-47, by
navigating to Cisco Unified CM Administration > System
> Enterprise Parameters. The parameter can be set to
Internal, External, or Both. The default value for Services
Provisioning is Internal. When it is set to External or
Both, the phones send an HTTP GET message to Unified
CM in order to ask Unified CM which services are
available to the phone. When it is set to Internal, phones
reference their local configuration file to determine
which services are available. Example 7-21 shows how
the configuration file stores the Extension Mobility
service configured earlier in this chapter. Figure 7-48
outlines the login flow, which involves the steps of the
Extension Mobility login flow as described below.
Example 7-21 Phone Configuration File Service
##### The phone's configuration file shows the EM URL as

listed below
<phoneService type="0” category="0">

<displayName>EM</displayName><name>EM</name>
<url>http://sj-cucm.ccnpcollab.lab:8080/emapp/EMAppSe
Figure 7-47 Services Provisioning Enterprise Parameter

Figure 7-48 EM Login Flow
Note
Steps 1 and 2 do not occur when the Services Provisioning parameter is set to
Internal.
Step 1. When the user presses the gear icon button

on the phone, the phone performs a call to
determine what applications (including
phone services) are available to the phone.
The call is sent to the server, which is
configured in the URL Services enterprise
parameter. This is done via an HTTP GET
request from the IP phone to the Unified CM.
Step 2. The Cisco IP Phone Services service is

queried to determine which services the
phone is subscribed to. The list is sent to the
phone in a 200 OK HTTP response.
Step 3. When the user selects the Extension

Mobility phone service, an HTTP GET
request is sent to the Extension Mobility
Application (EMApp) service which forwards
the request to the Extension Mobility service
(see Example 7-22).
Example 7-22 CallManager SDL Trace, EMApp Trace,

Extension Mobility Trace, and Cisco TFTP Trace
Analysis, Part 1
##### EMApp Trace - The EMApp service receives a request

from the phone
2020-01-29 14:57:11,346 INFO [http-bio-8080-exec-9]

##### EMApp Trace - The EMApp service forwards the query

to the EM Service
2020-01-29 14:57:11,407 DEBUG [http-bio-8080-exec-9]

<appInfo>
<appID>CCMSysUser</appID>
<appEncryptedCertificate>xxxxxxx</appEncryptedC
</appInfo>
<deviceUserQuery>
<deviceName>SEPD0EC35FFEBC4</deviceName>
<remoteIPAddr>14.50.214.106</remoteIPAddr>
</deviceUserQuery>
</query>
##### EM Trace - The EM service receives the request from

EMApp
##### EM Trace - We see the request is to determine the d

evice to user association “deviceUserQuery"

<!DOCTYPE query SYSTEM “http://172.18.110.61:8080/ems
<query>
<appInfo>
<appEncryptedCertificate>*****</appEncryptedCer
</appInfo>
<deviceUserQuery>
</deviceUserQuery>
</query>
Step 4. In response to the call made in step 3, the

EMApp service forwards an XML message to
the phone, requesting the user’s credentials
for EM login. The XML is carried within the
200 OK HTTP response. Example 7-23 shows
a snippet from the trace log indicating that
the login page has been sent. The 200 OK
message from EMApp to the phone instructs
the phone to display the login screen and
request the user ID and PIN.

Analysis, Part 3
##### EMApp Trace - The login page is sent to the phone
Step 5. The user enters their credentials in the

phone’s UI and then presses the Submit
button to send the data to the EMApp service.
An HTTP GET, containing the user’s
credentials, is sent to Unified CM for
verification. Example 7-24 shows the trace
snippets for this operation.

Analysis, Part 4
##### EMApp Trace - EMApp gets another request from the p

hone. This time the phone is sending the user credentials
Step 6. As shown in Example 7-25, the EMApp

service proxies the information to the

Analysis, Part 5
##### EMApp Trace - The EMApp service sends the informati

on to the EM Service
##### EMApp Trace - This is going to the login service sp
ecifically

<appInfo>
<appEncryptedCertificate>xxxxxxx</appEncryptedC
</appInfo>
<login>
<userID>test_em</userID>
<deviceProfile>test_em_dev_pro</deviceProfile>
<isViaHeaderSet>false</isViaHeaderSet>
</login>
</request>
Step 7. The Extension Mobility service queries the

Cisco Unified CM database to determine the
device profile to use and apply the settings of
the device profile to the phone’s
configuration. Example 7-26 shows the login
was successful.
Example 7-26 CallManager SDL Trace, EM App Trace,

EM Trace, and Cisco TFTP Trace Analysis, Part 6
##### EM Trace – The login to the device is successful

<response>
<success/>
</response>
Step 8. The Extension Mobility service informs the

EMApp service of the successful login and the
EMApp service then responds to the phone
with an HTTP 200 OK.
Step 9. The CallManager service sends a restart

message to the phone. As part of the restart
process, the phone requests the appropriate
Extension Mobility configuration. Example 7-
27 shows the TFTP service receiving the
request and building the updated
configuration file, which includes the settings
from the device profile.

Analysis, Part 7
##### At this point the phone is coming back online and n

eeds to contact TFTP for its configuration file
##### TFTP Trace - TFTP Trace - The device requests the c
onfig file from TFTP after login
00022631.003 |14:57:40.200 |AppInfo | HTTPConnecti

Host:172.18.110.61:6970
##### TFTP Trace - TFTP builds the config file with the u
nderstanding the EM user is logged with profile test_em_d
ev_pro
00022634.059 |14:57:40.283 |AppInfo |CXMLSIPLines::B

Step 10. Finally, as shown in Example 7-28, with the
phone configuration downloaded, the IP
phone re-registers with Unified CM by
sending a SIP REGISTER message. Unified
CM would accept the registration with a SIP
200 OK response.
Example 7-28 CallManager SDL Trace, EM App Trace,

EM Trace, and Cisco TFTP Trace Analysis, Part 8
##### Now the phone knows which Unified CM to use and whi
ch DN to use
##### CallManager SDL Trace - CCM receives REGISTER messa
ge from the phone, now using extension 3333

[54911,NET]
REGISTER sip:sj-cucm.ccnpcollab.lab SIP/2.0
From: <sip:3333@sj-cucm.ccnpcollab.lab>;tag=d0ec35ffe
Call-ID: d0ec35ff-ebc40005-506434f5-2f073c6e@14.50.21
CSeq: 121 REGISTER
Reason: SIP;cause=200;text="cisco-alarm:23 Name=SEPD0
One of the great things about Extension Mobility is the

error codes provided when something goes wrong. Any
time there is an issue with Extension Mobility login or
logout, the first thing you want to know is the error code
on the screen. For example, say that the user is trying to
log in to the phone and sees the message “Login is
unavailable(28)”. Based on the sample output and the
information in Table 7-2, you can surmise the meaning
of this error code and how to fix it. This error was an
Extension Mobility service error code, which is different
than EM Application errors.
Table 7-2 EM Service Error Codes

Table 7-2 details only a few of the common errors you
might encounter. The full list of Extension Mobility error
codes, along with detailed reasons, is too long to print in
this book, but you can find a digital version in the
Unified CM feature configuration guide, at
https://www.cisco.com/c/en/us/td/docs/voice_ip_com
m/cucm/admin/12_5_1/featureConfig/cucm_b_feature
-configuration-guide-1251/cucm_b_feature-
configuration-guide-1251_chapter_011110.html.
Note
Some of the error messages in this table are for Extension Mobility Cross
Cluster; however, this book focuses on only Extension Mobility.
Table 7-3 details some other error codes, which are more
likely to occur when EMApp has a problem. As you will
see later in this chapter, knowing whether the Extension
Mobility service or EMApp is facing issues can greatly
reduce your troubleshooting efforts.
Table 7-3 Phone Display Messages from EMApp

CONFIGURE AND VERIFY DEVICE
MOBILITY
Users sometimes move between buildings, sites, regions,
and countries. In the process, a user might bring their
phone with them; however, the user is more likely to take
only their computer and mobile device. This is not an
issue on the surface; however, there are concerns about
settings applied to the device and/or device pool. The
following are some of those settings:
• SRST Reference
• Date/Time Group
• Region
• Location
• Calling Search Space
• Media Resources
Consider an example of why these settings might be

problematic: Say that a user moves from a site in Mexico
to a site in the United States. While in the United States,
the user initiates an ad hoc conference, and the
conference bridge selected is in Mexico, even though the
user is currently in the United States. A media resource
in Mexico is selected due to statically assigned settings,
such as the media resource group list. This opens the
door for bandwidth issues and possible connectivity
issues as well.
The Device Mobility feature addresses these concerns.

With this feature, certain settings can be dynamically
assigned when a user is roaming.
This section explains the configurations needed for

Device Mobility, describes the difference between
Roaming Sensitive settings and Device Mobility–Related
Information settings, provides a diagram for Device
Mobility, and shows how to verify whether a phone is
roaming.
Figure 7-49 provides a high-level view of the topology

used for the example in this section. This figure will be
very important when we talk about Device Mobility–
Related Information and its impact on dialing external
phone numbers.
Figure 7-49 Domestic Device Mobility Topology
Note
Device Mobility is not a cross-cluster feature. Furthermore, devices with
statically assigned IP addresses do not invoke the Device Mobility feature.
Device Mobility might seem complicated at first, but the

basic idea is to determine whether an endpoint has
changed subnets and whether the endpoint’s settings
should be dynamically updated if the device has moved
to a new subnet. There are only a few pieces to the
configuration, and most of them are simply used to make
indirect connections to other pieces of the configuration.
The ability to make indirect connections between the
Device Mobility settings allows administrators more
flexibility in their design. Configuring Device Mobility
involves the following steps.
Step 1. Set the Device Mobility mode, which

indicates whether Device Mobility is enabled
on an endpoint.
Step 2. Configure physical locations, which are

used to logically segment low-level areas
(buildings, campuses, cities, and so on). A
good approach would be to make a physical
location per device pool as device pools are
typically configured for low-level areas as
well.
Step 3. Configure Device Mobility groups,

which are used to logically segment high-level
areas. Typically, Device Mobility groups are
made per country.
Step 4. Configure device pools, which are used to

link physical locations and Device Mobility
groups to the Roaming Sensitive settings
and Device Mobility–Related
Information. In more direct terms, the
device pool helps identify settings that should
be dynamically assigned to a roaming device.
A static device pool is configured on a
phone’s configuration page. A roaming
device pool is a device pool that is
dynamically applied to the phone while the
phone is roaming to a new subnet.
Step 5. Configure Device Mobility information

to specify which subnet is associated with
which device pool(s).
Figure 7-50 provides an illustration that shows how

these elements connect in a real-world example.
Figure 7-50 Device Mobility Example
Note
Notice that the Roaming Sensitive settings are applied when the physical
location is different between device pools, but the Device Mobility–Related
Information is applied when the Device Mobility group is the same between
device pools.
Let’s talk about each of the configurations, starting with

how to set the Device Mobility mode. There are two ways
to set Device Mobility mode: via a service parameter or
via the device configuration page. When Device Mobility
mode is set at a service parameter level, all devices that
reference the service parameter configuration are either
set to on or off, depending on what value is chosen for
the service parameter. The value originally specified on
the phone configuration page for Device Mobility mode
is Default. This means the phones, by default, reference
the service parameter; furthermore, the default setting
for the Device Mobility mode service parameter is off.
Figure 7-51 shows the Device Mobility mode setting on
the phone configuration page, and Figure 7-52 shows the
service parameter. For simplicity, the configuration in
this chapter uses the service parameter by setting the
Device Mobility Mode parameter to On. To review or
modify the service parameter, navigate to Cisco Unified
CM Administration > System > Service Parameters >
Server > Cisco CallManager and then locate the
parameter in the section Clusterwide Parameters (Device
- Phone).
Figure 7-51 Device Mobility Mode Setting on a Phone
Figure 7-52 Device Mobility Mode Setting Service

Parameter
To create physical locations, you navigate to Cisco

Unified CM Administration > System > Physical
Location and click Add New. The configuration here is
simple as you only need to provide a name and an
optional description. Figure 7-53 shows what the
Physical Location Configuration page looks like, and
Figure 7-54 shows three physical locations added to the
configuration for testing.
Figure 7-53 Physical Location Configuration Page
Figure 7-54 Three Physical Locations Added
Note
Physical locations are typically configured based on Class of Control (CAC)
and media resources.
Next, you need to add a Device Mobility group to the

configuration. To do this, you navigate to Cisco Unified
CM Administration > System > Device Mobility > Device
Mobility Group and click Add New. As with the physical
location configuration, Device Mobility groups simply
require a name and an optional description. Figure 7-55
shows that the test configuration uses three Device
Mobility groups.
Figure 7-55 Three Device Mobility Groups
Note
Device Mobility groups are typically configured with consideration of
maintaining user dialing habits. For example, someone from Europe who
traveled to America might not be familiar with how to dial external numbers.
Device Mobility Groups allow them to maintain their typical dialing instead of
learning how to dial external numbers while in America.
Next, you need to configure device pools (unless they are

already configured, as they are when implementing
Device Mobility in a preexisting environment). To
configure device pools, navigate to Cisco Unified CM
Administration > System > Device Pool and click Add
New to create a device pool or click Find to edit an
existing device pool.
Table 7-4 shows the two settings that can be configured

for a device pool.
Table 7-4 Device Pool Roaming Sensitive Versus Device

Mobility Related Information
Note
This section of the chapter is written with a traditional dial plan in mind;
however, some notes about the impacts of globalized dial plans are provided
where appropriate. Globalized dial plans greatly simplify configurations for
advanced features and advanced call routing setups. When using globalized
dial plans with Device Mobility, end-user dialing habits are maintained due to
number globalization and localization; furthermore, the local gateway is always
used due to the local route group feature, which is defined on the roaming
device pool. In short, globalized dial plans eliminate the need for Device
Mobility Groups.
Figure 7-56 shows the Roaming Sensitive Settings

section of the Device Mobility configuration.
Figure 7-56 Roaming Sensitive Settings Section

Notice that these settings are primarily related to a
device moving from one campus to another or one city to
another, and they don’t impact a user’s dialing habits.
For example, if someone from the SJ site takes a device
to the RCH office, the device will then be in a different
time zone and warrant use of a different date/time
group.
Figure 7-57 shows the Device Mobility Related

Information configuration settings, and you can see
these settings pertain only to call routing. You can use
these settings to preserve a user’s ability to dial as they
normally would. For example, when a user from CDMX
visits SJ, they will change Device Mobility groups. You
might want to allow the user to dial the same way they
would while in Mexico. Then, when she changes Device
Mobility groups, the Device Mobility–Related
Information settings are ignored. This means the static
CSS remains applied from user’s device, and the user can
maintain their typical dialing habits.
Figure 7-57 Device Mobility Related Information

Section
Tip
There are overlapping settings between a phone and a device pool. The
settings on the phone take precedence over those on the local device pool, but
the roaming device pool has the highest precedence when the device is
roaming.
The final item to configure is Device Mobility

information. To do this, you navigate to Cisco Unified
CM Administration > System > Device Mobility > Device
Mobility Info and click Add New. Figure 7-58 shows
what the Device Mobility Info Configuration page looks
like. This example shows the creation of Device Mobility
Information for CDMX and SJ. The CDMX Device
Mobility Information links the subnet 14.48.38.0 /24 to
the CDMX_DP device pool while the SJ Device Mobility
Information links the 14.50.214.0 /24 subnet to the
SJ_DP device pool.
Figure 7-58 Device Mobility Info Configuration Page
Figure 7-59 shows that Device Mobility information may

be associated with one device pool or with multiple
device pools. Also, a device pool can be associated with
one or more Device Mobility Information configurations.
In reviewing the figure, we can see the one-to-one
association between Device Mobility Information A and
Device Pool A, the single Device Mobility Information to
multiple device pool association between Device Mobility
Information B and Device Pools A and C, and the single
device pool to multiple Device Mobility Information
association between Device Pool C and Device Mobility
Information B and C.
Figure 7-59 DMI-to-Device Pool Relationships
Now let’s look at how all these settings come together.

Figure 7-60 shows the logic diagram used to determine
whether a device is roaming and whether the device’s
settings should be dynamically modified.
Figure 7-60 Device Mobility Logic Diagram
To test the Device Mobility configuration, you can take a

phone from the CDMX site and bring it to the SJ site.
The expected behavior is as follows:
Step 1. The phone gets a new IP address for the SJ

subnet from DHCP located in SJ.
Step 2. The SJ subnet is associated with a the

Device Mobility Information named
SJ_NETWORK_DMI; therefore, Unified CM
identifies the device pool associated with this
Device Mobility Information.
Step 3. The roaming device pool is the SJ_DP
device pool. This is different from the phone’s
static device pool, which is CDMX_DP;
therefore, the Roaming Sensitive settings of
SJ_DP are applied to the phone.
Step 4. Unified CM checks whether the roaming

Device Mobility group (US_DMG) is different
from the phone’s static Device Mobility group
(MEX_DMG). Because it is different, the
Device Mobility–Related Information is
ignored.
Now you need to confirm that the phone is roaming and

determine which roaming settings are applied to the
phone. One way to know if a phone is roaming is to reset
the phone and see if the screen of the phone displays the
message shown in Figure 7-61. This message appears
after the phone registers, but it does not remain on the
screen for long.
Figure 7-61 Phone Screen for a Roaming Device
Another way to tell if a device is roaming is to check the

current Device Mobility settings on the phone’s
configuration page in Unified CM. Figure 7-62 shows
where to find this option.
Figure 7-62 View Current Device Mobility Settings
When you click on View Current Device Mobility

Settings, you see the information shown in Figure 7-63.
Note that this figure shows the settings while the phone
is roaming. Figure 7-64 shows the static device pool
settings applied to the device when it is not roaming.
When a device is not roaming, the Roaming Sensitive
Settings reflect the static settings and they appear grey as
seen in Figure 7-64.
Figure 7-63 Current Device Mobility Settings for a

Roaming Device
Figure 7-64 Static Device Pool Settings for a Device
That Is Not Roaming
The easiest way to compare the current Device Mobility

settings to the static device pool settings is to click on
View Details next to the Device Pool field on the phone’s
configuration page (see Figure 7-65).
Figure 7-65 Device Pool View Details Button
Troubleshoot Device Mobility

To troubleshoot Device Mobility, it is important to know
the logic of Device Mobility (refer to Figure 7-60).
When troubleshooting issues that might be affected by

Device Mobility, such as call routing issues, it can be
helpful to disable the Device Mobility mode on some test
phones. Then you can try to reproduce the issue at hand
to determine if Device Mobility is a factor to consider
while troubleshooting.
You should also be familiar with how CallManager SDL

trace logs look for a working scenario. Example 7-30
provides an example, where the following process occurs:
Step 1. Unified CM prints a clear line about the

device registering and indicates that a device
is roaming.
Step 2. Unified CM adds the device to the Device

Mobility route table and documents the static
and roaming device pools.
Step 3. Unified CM sends a SIP REFER message to
the phone so the phone can display “Device in
Roaming Location".
Step 4. The phone replies to the REFER message

with a 200 OK message.
Example 7-30 CallManager SDL Trace
##### Step 1
01998705.049 |22:45:30.974 |AppInfo |SIPStationD(28)
01998726.002 |22:45:30.987 |AppInfo |mMobileDevice =
##### Step 2
01998726.003 |22:45:30.987 |AppInfo |DeviceManager::
##### Step 3
01998737.001 |22:45:30.999 |AppInfo |//SIP/SIPUdp/wa

[196878,NET]
REFER sip:3653753d-8826-ed17-ef00-104ac1b00175@14.50.
From: <sip:6000@172.18.110.61>;tag=2090933714
To: <sip:6000@14.50.214.111>
Call-ID: c9360500-10001-166ec-400000@172.18.110.61
CSeq: 101 REFER
Referred-By: <sip:6000@172.18.110.61>
<?xml version="1.0” encoding="iso-8859-1"?>

<statuslineupdatereq>
<action>notify_display</action>
<statustext>Device In Roaming Location</statustext>
<displaytimeout>10</displaytimeout>
<priority>1</priority>
</statuslineupdatereq>
##### Step 4
01998750.001 |22:45:31.013 |AppInfo |//SIP/SIPUdp/wa
[196879,NET]
SIP/2.0 200 OK
From: <sip:6000@172.18.110.61>;tag=2090933714
To: <sip:6000@14.50.214.111>;tag=D0EC35FFB4C40010685a
Call-ID: c9360500-10001-166ec-400000@172.18.110.61
CSeq: 101 REFER
When you check the phone console logs, you see a SIP
REFER message from Unified CM that says “Device in
Roaming Location” as well as the line shown in Example
7-31, which indicates the phone is localizing the string
and provides and ENUM value 24.
Example 7-31 Phone Console Logs from the Problem

Reporting Tool (PRT)
5268 DEB Feb 03 21:45:29.253878 (3982-4172) JAVA-SIPC
Note
The test phone’s Phone Log Profile parameters were set to Default, Preset,
Telephony, SIP, and UI.
REFERENCES
Cisco, “Feature Configuration Guide for Cisco Unified
mm/cucm/admin/12_5_1SU1/cucm_b_feature-
configuration-guide-for-
cisco1251SU1/cucm_b_feature-configuration-guide-
for-cisco1251SU1_chapter_010.html
mm/cucm/srnd/collab12/collab12/mobilapp.html



MEMORY
There are no memory tables or lists for the chapter.
DEFINE KEY TERMS

Single Number Reach (SNR)

remote destination profile
remote destination
access list
Intelligent Session Control
Move to Mobile
Mobile Connect
Extension Mobility
Device Mobility
Device Mobility mode
physical location
Device Mobility group
static device pool
roaming device pool
Device Mobility information
Roaming Sensitive settings
Device Mobility–Related Information
Chapter 8. CUBE Call Routing and
Digit Manipulation
• Understanding Call Legs and Call Flows:

This section lays the foundation for understanding
the rest of the chapter by describing call legs and
call flows.
• IOS Dial Peers: This section describes inbound

and outbound dial peer matching for the purpose of
establishing sessions on CUBE. The section wraps
up with a discussion of summarization,
aggregation, and advanced techniques that can be
leveraged with IOS dial peers.
• Application Signaling and Media Binding:

This section covers application protocol binding,
which can be leveraged to influence Layer 3 packet
routing on a network to ensure that end-to-end
bidirectional sessions are established properly.
• Digit, Header, and URI Manipulation: This

section discusses digit and SIP header
manipulation for the purpose of interworking calls
with other Unified Communications (UC) devices.

exam topics:

dial plan elements
• 3.1.b Voice translation rules and profiles
• 3.1.d Dial peers

• 3.1.e Header and SDP manipulation with SIP
profiles
• 3.1.f Signaling and media bindings

• 3.2.b Voice translation rules and profiles
• 3.2.d Dial peers

• 3.2.e Header and SDP manipulation with SIP
profiles
• 3.2.f Signaling and media bindings
The majority of Unified Communications Manager

deployments involve endpoints on a customer’s local
area network (LAN) establishing media sessions with
parties that do not reside on the local network. Such a
session may consist of a simple outbound call from an
enterprise endpoint to a mobile device on the public
switched telephone network (PSTN) or even a call to an
external conference with many other participants to
discuss the latest quarterly results. On the flip side,
somebody might need to reach your enterprise users for
various reasons. In this case, a session might be as
simple as an inbound call from a potential customer on
the PSTN to a LAN endpoint or a more complex call from
a cell phone to your interactive voice response (IVR)
system, which performs deterministic call routing by way
of prerecorded prompts that solicit user input via speech
recognition or digit collection. These various scenarios
have a common goal: to ensure that the customer’s
enterprise LAN can communicate and interface with
public networks such as the PSTN.
The Cisco session border controller (SBC) called Cisco

Unified Border Element (CUBE) enables administrator
to interface and connect the enterprise LAN with one or
many Internet telephony service providers (ITSPs) and
other third-party call agents for all the purposes
described above. This type of connection is achieved by
leveraging a logical SIP trunk to establish inbound and
outbound sessions with users on public networks such as
the PSTN and other ITSPs. This chapter provides an in-
depth explanation of IOS call routing techniques using
dial peers to facilitate inbound and outbound session
establishment through CUBE. In addition to covering
call routing, this chapter discusses key topics such as SIP
URI and digit manipulation. Along the way, this chapter
describes verification and troubleshooting techniques to
assist with triage and troubleshooting different issues
that may occur when routing calls with CUBE. Where
possible, real-world examples and scenarios are detailed,
along with relevant configuration examples and
debugging samples.

Table 8-1 “Do I Know This Already?” Foundation

Topics Section-to-Question Mapping
1. What is the minimum number of call legs for a single
call that traverses CUBE?
a. 1
b. 2
c. 3
d. 4
e. 5
2. What information is contained in a call flow

diagram? (Choose two.)
a. Layer 1 physical cabling information
b. Layer 3 network routing information
c. Layer 4 transport information
d. Layer 7 application information
3. Which filtering operation occurs before CUBE

attempts to match an inbound dial peer?
a. URI filtering
b. VRF filtering
c. Called number filtering
d. Media capability filtering
e. Calling number filtering
4. Variants of the same session transport command

are configured in voice service voip, voice class
tenant, and a voice dial peer. Which command has
an effect on the outbound session created by CUBE?
a. voice service voip configuration
b. voice class tenant configuration
c. voice class tenant configuration applied to a dial

peer
d. dial peer configuration
5. Of the following inbound dial peer match criteria

commands, which does CUBE evaluate first for
inbound dial peer matching?
a. incoming called-number
b. incoming uri via
c. incoming uri to
d. incoming call from
e. answer-address
6. Which commands must be present on an outbound

dial peer for it to be administratively up and
operationally up? (Choose two.)
a. Incoming matching command
b. Outbound matching command
c. Next-hop session information (session target)
d. Application signaling and media binding

commands
e. Audio codec commands
7. What are the conditions for selecting an outbound

dial peer when performing a dial peer match with
dial-peer hunt 0? (Choose three.)
a. Random selection
b. Longest match in phone number
c. Least recent use
d. Explicit preference
e. Round-robin selection
8. Which dial peer commands can be aggregated and

summarized with the e164-pattern-map
command? (Choose two.)
a. session target
b. destination-pattern
c. voice class uri
d. session protocol
e. incoming called-number
9. Which commands can be leveraged to view

information about active calls on CUBE? (Choose
two.)
a. show cube status
b. show call active voice brief
c. show version
d. show run
e. show voip rtp connections
10. Which interface types require application signaling

and media binding to properly source application
packets on CUBE? (Choose two.)
a. GigabitEthernet interfaces
b. Subinterfaces
c. Loopback interfaces
d. VLAN switch virtual interfaces (SVIs)
e. Serial interfaces
11. What types of manipulations can be performed by a

voice translation profile? (Choose two.)
a. SIP alphanumeric user ID
b. Numeric called number
c. Numeric calling number

d. SIP alphanumeric host
12. Which CUBE manipulation technique can be

leveraged to modify a SIP header in an egress 200 OK
response to an INVITE?
a. Inbound SIP profile
b. Outbound SIP profile
c. Voice translation profile
d. Voice translation rules
FOUNDATION TOPICS
UNDERSTANDING CALL LEGS AND

CALL FLOWS
Understanding call legs and call flows is very important
for the upcoming sections and chapters. A single call
leg includes all the Layer 7 signaling and media for
establishment of a given session between two devices. An
end-to-end call has multiple call legs that establish
separate sessions with different devices. Figure 8-1
shows all the call legs for a call that traverses the
enterprise LAN and is sent to the service provider
network. A diagram of these call legs, like the one in
Figure 8-1, is referred to as a call flow. Basically, a call
flow is a grouping of Layer 7 signaling and media
information that pertains to the devices involved in a
specific call. A call flow differs slightly from the Layer 1,
2, and 3 network topology diagrams used by network
engineers. Network topology diagrams are usually more
granular than application level diagrams such as call
flows. Each hop of a call flow contains a call leg that
traverses a network at Layer 1, 2, and 3, but these layers
are usually omitted from a call flow diagram.
Figure 8-1 Call Flow Diagram Detailing the Application
Hops in a Given Call
Keeping an up-to-date call flow diagram for application

layer signaling and media along with an up-to-date
network topology is very beneficial to any
administrator’s troubleshooting, designing, and planning
activities. Remember that the call flow does not end at
the service provider. There are many more call legs and
hops as the call traverses the network and other service
provider networks, although they are usually omitted
from an enterprise call flow as they are not usually
known.
Tip
Call flow diagrams may include Layer 4 transport information, which is often
useful for troubleshooting.
From the perspective of CUBE, there is always an

inbound call leg and an outbound call leg for a session
traversing the SBC. The inbound call leg consists of the
ingress and egress SIP signaling involving a SIP user
agent client (UAC). This UAC may be the ITSP, Cisco
Unified CM, or a third-party SIP client. CUBE answers
this signaling and takes the role of user agent server
(UAS) for that call leg. CUBE then uses information from
the ingress SIP messaging coupled with the configuration
defined by the administrator to make a logical call
routing decision. Upon deciding where to route the call,
CUBE assumes the role of UAC and originates a new SIP
session, with the UAS determined by the previous call
routing logic. This second SIP session is the outbound
call leg. Figure 8-2 illustrates inbound and outbound call
legs with respect to the SIP signaling and call directions.
Figure 8-2 B2BUA Operation with Inbound and
Outbound Call Legs
Note the following in Figure 8-2:
• The inbound call leg starts on the side of the device

where the first session establishment message is
received.
• The outbound call leg consists of the side of the call

where the device extends the call to the next hop
with a new session establishment message.
• Both inbound and outbound call legs consist of

bidirectional (sent and received) signaling
messages.
• This figure shows a high level SIP three-way

handshake that consists of the INVITE, 200 OK,
and ACK messages as CUBE performs back-to-back
user agent (B2BUA) functions.
Because B2BUA operation is not clearly defined by any

RFC, the actual interworking varies greatly by SBC
vendor. By default, CUBE works to echo any SIP
signaling received on one call leg to the peer call leg. For
example, with CUBE, a SIP 183 Session in Progress
message received on the outbound call leg would be
transmitted on the peer inbound call leg. Figure 8-2
illustrates this for a basic call setup through CUBE. For
granular control, CUBE has many configurations that
allow you to change the way CUBE handles interworking
during specific scenarios; you can even outright block
specific messages from being passed through CUBE.
(These features are covered in Chapter 9, “CUBE
Interworking Features.”)
Tip
It is very important to remember that the terms inbound call leg and outbound
call leg refer to the direction of the call from perspective of the device you are
currently working with rather than the direction of the overarching call. Inbound
calls to your LAN from a service provider and outbound calls from your LAN to
a service provider will always have an inbound call leg and an outbound call
leg from CUBE’s perspective.
Because it is an SBC, CUBE’s core functionality is to

interact with VoIP call legs and interwork connections
between multiple LANs for the purpose of routing calls.
The two main VoIP protocols that CUBE uses are H.323
and SIP. CUBE can natively interwork four different
permutations of the calls with only a few commands; any
combination of SIP–SIP, SIP–H.323, H.323–SIP, and
H.323–H.323 calls can be routed through CUBE. Note
that when SIP–SIP interworking is being performed,
CUBE is acting as a back-to-back user-agent
(B2BUA). For other scenarios, such as H.323–H.323,
SIP–H.323, and H.323–SIP, CUBE is acting as an IP-to-
IP gateway (IPIPGW). These interworking scenarios are
disabled by default, but Example 8-1 details four allow-
connections commands that are used to enable these
permutations. This example also details the mode
border-element command, which is required to enable
a CUBE license, and the show cube status command,
which is used for gathering a quick verification of the
CUBE version running on the IOS platform.
Example 8-1 Sample CUBE Configuration for Protocol
Interworking
rtp-cube# show run | section voice serv

voice service voip
mode border-element license capacity 100
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
rtp-cube# show cube status

CUBE-Version : 12.7.0
SW-Version : 16.12.1a, Platform ISR4321/K9
HA-Type : none
Licensed-Capacity : 100
Tip
CUBE versions are directly tied to IOS versions. Upgrading or downgrading
IOS also upgrades or downgrades CUBE. When running multiple feature and
services, you should always consult the applicable feature roadmaps and
release notes to ensure that key features are not lost when performing
downgrades.
IOS DIAL PEERS

A dial peer is an IOS command set that allows an
administrator to accept and route calls through CUBE. In
modern IOS deployments, dial peers come in two flavors:
Plain Old Telephony Service (POTS) dial peers and voice
over IP (VoIP) dial peers. POTS dial peers are used to
interface with analog and digital connections, such as
Foreign Exchange Station (FXS), Foreign Exchange
Office (FXO), Ear and Mouth (E&M), E1 R2, T1/E
Primary Rate Interface (PRI), and Basic Rate Interface
(BRI). These legacy connections are used by IOS voice
gateways to interoperate with private branch exchange
(PBX) systems, PSTN service providers, and analog
endpoints such as fax machines. Because the CCNP
blueprint explicitly states that the CLACCM 300-815
exam covers CUBE dial peers, POTS dial peers are not
discussed in this chapter. Instead, this chapter discusses
VoIP dial peers and how they operate for SIP.
Dial peers can best be compared to the concept of static

routing commands used for Layer 3 packet routing. Dial
peers are created and match criteria statements are
defined using wildcards and regular expressions (regex).
Two logical operation descriptions of dial peers appear in
debugging output: inbound dial peers for association
with inbound call legs and outbound dial peers for
association with and creation of outbound call legs. A
dial peer contains a host of configurations that allow
administrators and CUBE to exert control and perform
interworking on the matching call legs of a session. A
number of commands can be used to control various
aspects of a call, such as DTMF relay, codecs/media
operation, Layer 4 transport, VoIP protocol usage,
encryption, calling/called translations, and SIP header
interworking.
A three-level hierarchy for configuration preference

defines which commands and their actions are applied to
a given call leg on CUBE. The following is the command
preference order, starting with the most explicit
preference:
1. Dial peer configuration commands: These

IOS commands are applied to inbound and
outbound dial peers used by a session. These
commands take precedence over all other
configurations.
2. Voice class tenant configuration

commands: A voice class tenant is a CLI
command structure that facilitates grouping of
system-level commands for specific tenants.
Multitenancy is a feature in CUBE that enables
administrators to host multiple organizations,
customers, or other differentiated services on the
same CUBE. Through the use of the voice class
tenant command, an administrator can configure a
host of settings for a specific tenant while also
configuring different system-level settings for a
different tenant. When these settings are applied to
a dial peer, the dial peer inherits all of the
command settings defined on the tenant. Dial peer
commands still override voice class tenant settings
when both exist.
3. Global configuration commands: Commands
applied to sip-ua, voice service voip, or sip
subsection of voice service voip are applied to all
calls traversing CUBE. These commands can be
overwritten by voice class tenant or dial peer–level
configurations.
The following sections detail how to configure these dial

peers to match on either an inbound call leg or an
outbound call leg.
Inbound Dial Peer Matching

Every session that is established through CUBE uses an
inbound dial peer. The dial peer selected is assigned to
the inbound call leg, and the configuration defined by the
administrator is leveraged by CUBE to exert control over
the signaling and media negotiation for that call leg.
Commands on the inbound dial peer also influence
aspects of IOS call routing decisions and outbound dial
peer selection, as discussed later in this chapter.
When IOS receives a new session and VoIP signaling

message on a listening IP address and port, CUBE
processes the following sequence of events for the
inbound call leg:
Step 1. CUBE applies global number translations or
inbound SIP profiles.
Step 2. CUBE filters dial peers based on virtual

routing and forwarding (VRF) criteria.
Step 3. CUBE selects an inbound dial peer based on

the defined matching commands.
Step 4. CUBE applies configurations such as more

translations, SIP profiles, and binds to the
VoIP signaling message.
Step 5. CUBE sends an acknowledgement message

to stop retransmission of the VoIP signaling
message from the sending device. For SIP,
this is usually in the form of a 100 Trying
message.
Table 8-2 show the IOS selection preference and the

commands used to define the matching preference on
dial peers. Defining any of these commands on a VoIP
dial peer enables that dial peer for inbound selection.
CUBE examines all dial peers that are configured with
the commands found in the rightmost column of a given
row of the table. CUBE examines different portions of
the ingress VoIP signaling message and compares them
to the wildcards and regex defined by match criteria
commands. (Wildcards and regex are covered later in
this chapter.) If a valid match is found, inbound dial peer
hunting stops. Inbound dial peer hunting moves to the
next row’s match criteria only when zero eligible
matching dial peers have been found for the specific
match criteria. For rows that have more than one
command in the rightmost column, the commands have
equal weight, and all dial peers with those match criteria
commands are processed at the same time. This process
is repeated for each row of the table until an applicable
match for given match criteria has been found.
Table 8-2 Inbound SIP Dial Peer Selection Preference
Tiebreakers and Longest and Most Specific Matching Logic
The dial-peer preference command does not

influence inbound dial peer selection when there are
multiple dial peers with the same match criteria that
could be selected, based on the ingress VoIP signaling
message. CUBE uses the concept of the longest and most
specific match to determine the priority. “Longest” and
“most specific” refer to how many numeric digits (or
alphanumeric characters for URIs) are matched on a
regular expression run against a given input. In short, a
dial peer with a match criteria command containing a
more exact match will always be leveraged over a dial
peer that is less exact. Example 8-2 shows two potential
dial peers that can match the called number 1001. The
first dial peer, 1000, has an exact match on the first digit
(1), but the second dial peer (1001) has an exact match
on three digits (100). Thus, dial peer 1001 is the longest,
most specific match for the given called number and is
therefore used as the inbound dial peer for this example.
When two inbound dial peers of given match criteria
have the same match length and are still tied, IOS selects
the first of the tied dial peers according to the order of
the running configuration. This is true for both URI and
number matching criteria commands.
Example 8-2 Sample Configuration for Inbound Dial

Peer Matching Based on Called Number
!
dial-peer voice 1000 voip
incoming called-number 1...
!
incoming called-number 100.
!
Because IOS only moves to the next row’s match criteria

when zero applicable matching dial peers have been
found, there is a possibility that a match criteria
command with a better longest and most specific match
may not be used if IOS finds an applicable match on a
dial peer with a higher-preference match criteria
command. For example, a dial peer with an exact match
incoming calling or answer-address command may
not ever be examined by IOS when a catch-all incoming
called-number . command exists. IOS selects the dial
peer with the incoming called-number command in
this scenario because it satisfies matching conditions of
being the longest and most specific match for that row’s
match criteria (even if the match is a single digit).
Likewise, if an applicable incoming uri command can
match on a SIP header, the incoming calling and
incoming called-number commands will never be
examined.
Dial Peer Wildcards and Regex

For the dial peer match criteria commands that match on
numeric strings, you can configure IOS wildcards and
regex to define the range of numbers you would like a
dial peer to service. Table 8-3 shows the different dial
peer wildcard options, limited regex values, and usage
examples and descriptions. You will see an example of
regex and wildcard commands in the upcoming Example
8-4 for inbound dial peer matching using incoming
called-number statements.
Table 8-3 Regex and Wildcard Commands Used by IOS

Dial Peers
Dial Peer Filtering
As mentioned earlier in this chapter, dial peers are first
filtered before the match criteria are examined. When
the signaling is received on an interface with a VRF tag
assigned, all dial peers are filtered to include only those
associated to the VRF instance of the ingress interface.
The VRF association is created by binding the dial peer
to the interface with the VRF instance. The VRF
instance–to–dial peer association is created when a dial
peer is bound to an interface that has been assigned to a
VRF instance with the vrf forwarding command. VRF
instances are often employed alongside voice class
tenant configurations discussed earlier in the chapter.
Figure 8-3 shows a SIP message received by CUBE, the
filtering that occurs, and the dial peer match criteria
evaluated from the different parts of the SIP message
(refer to Table 8-2).
Figure 8-3 Sample Mapping of Dial Peer Match Criteria

Commands and a SIP INVITE Message
Dial Peer 0, the Default Inbound Dial Peer

As mentioned at the beginning of this section, CUBE
always associates an inbound call leg with an inbound
dial peer. This is true even when no configured dial peer
satisfies the IOS match criteria condition checks laid out
in the previous paragraphs. When this scenario occurs,
the default dial peer 0 is used as the inbound dial peer.
This is a less-than-ideal situation in most cases because
dial peer 0 is not configurable and contains a set of static
capabilities that may affect session establishment in a
negative way:
• Dial peer 0 has no DTMF relay mechanisms.
• Dial peer 0 advertises all voice codecs for VoIP

calls.
• Dial peer 0 uses fax-rate voice.
• Voice activity detection (VAD) is enabled for dial

peer 0.
• Dial peer 0 does not support RSVP.
• Dial peer 0 does not support IVR for basic

telephone service (POTS) calls.
• Direct inward dialing (DID) is enabled for dial peer

0.
• Dial peer 0 does not support VRF instances.
Given these issues, it is better to configure an inbound

dial peer than to match dial peer 0.
Although dial peer 0 is the default and not configurable,

you can assign another VoIP dial peer on CUBE as the
system default inbound dial peer. This dial peer can then
be configured with various parameters and will be
matched in place of dial peer 0. This gives you flexibility
to change the parameters leveraged when the default dial
peer is selected. Example 8-3 shows the commands for
enabling a VoIP dial peer as the system default to enable
capabilities not available with dial peer 0. At the end of
the example, the show dial-peer voice command is
used to verify that this dial peer has the system default
attribute.
Example 8-3 Sample Configuration Showing the

Creation of a Default Inbound Dial Peer
Router# show run | section 999

dial-peer voice 999 voip system
dtmf-relay rtp-nte
codec g711ulaw
fax rate 9600
no vad
Router# show dial-peer voice 999 | i default

peer type = voice, system default peer = TRUE
Matching Inbound Call Legs Using incoming called-number

Commands
This chapter has already discussed the order of
operations IOS uses for matching inbound calls to an
inbound dial peer. This section examines how to use the
incoming called-number command to perform a
match on the numeric phone number and avoid
matching dial peer 0.
Say that two phone calls are received at CUBE from a

peer SIP user agent and require matching an inbound
dial peer. CUBE finds these called numbers in the SIP
INVITE Request-URI:
• INVITE sip:14085267209@172.18.110.42:5060
SIP/2.0
• INVITE sip:918005532447@172.18.110.42:5060
SIP/2.0
This example assumes that the enterprise PSTN access

code is 9; that is, 9 is the code that users of end devices
must dial to reach the public PSTN. Given the called
number 14085267209, we can assume that dial peer 2 in
Example 8-4 will be used as the inbound dial peer due to
the regex match of a single dot (any character). Since the
called number 14085267209 does not start with a 9, dial
peer 22 will not be used. Further, we can observe that the
called number 918005532447 matches dial peers 2 and
22 in various ways. Since these are all incoming called
number statements, they are all evaluated to find the
longest, most explicit match. The match on dial peer 2
for 918005532447 is a single digit: the leading 9. The
match on dial peer 22 is four digits, so this is a longer,
more explicit match (918xx5xxxxxx of 918005532447).
Because dial peer 22 is the longest, most specific match,
it will be used as the inbound dial peer for this call.
Example 8-4 shows the use of the show dial-peer
voice summary command, which indicates these dial
peers are administratively up and operationally up,
which means they are eligible for inbound dial peer
matching based on their matching criteria commands.
The same logic observed in this example can be
replicated to the incoming calling or answer-
address commands.
Example 8-4 A Sample Configuration Showing

Inbound Dial Peers
rtp-cube# show run | section dial-peer

!
session protocol sipv2
incoming called-number .
!
incoming called-number 91[2-9]..[2-9]......
!
rtp-cube# show dial-peer voice summary

dial-peer hunt 0
AD PRE PASS
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU
2 voip up up 0 syst
22 voip up up 0 syst
Matching Inbound Call Legs Using URIs

URI-based dial peer matching for SIP makes use of
voice class uri commands, which are configured with
subcommands that use standard regex to match on
different portions of a SIP header’s URI. URIs in SIP
headers have a few distinct parts that can be leveraged
for dial peer matching, and Table 8-4 details the order of
operations used to evaluate a SIP URI. (For more
information on SIP URI structuring, refer to Chapter 2,
“VoIP Protocols: SIP and H.323.”)
Table 8-4 Voice Class URI Match Preference Order
Used by CUBE
Tip
Match preferences 1 and 2 can be reversed with the command voice class uri
sip preference user-id host, which instructs CUBE to check the user ID
before checking the host portion of the URI.
Example 8-5 shows the syntax for the voice class uri
command along with the optional subcommands. The
name option is an administrator-defined name, and the
regexMatch option is a regex string up to 32 characters
long for user ID/host matches and 128 characters long
for pattern matches.
Example 8-5 Voice Class URI Command Syntax
! SIP URI
voice class uri name sip

host regexMatch
!
user-id regexMatch
!
phone regexMatch
!
pattern regexMatch
!
! Tel URI
voice class uri name tel

phone regexMatch
!
voice class uri name tel
pattern regexMatch
!
Tip
Up to 10 host commands can be configured on a single voice class uri
command. Phone, pattern, and user-id only one definition per voice class uri
command.
Using the information in Example 8-5, Example 8-6

details an inbound SIP message and a match that is
configured to occur on the SIP Via header. This involves
first defining a voice class uri to match the host IPv4
address. The voice class uri is then added to a dial peer
using the incoming uri command. Any call that has a
Via header containing IPv4 address 172.18.110.65 then
uses dial peer 2 as the inbound dial peer.
Example 8-6 A Sample Depicting a Voice Class URI

Match Using the Via SIP Header
# Inbound INVITE
INVITE sip:14085267209@172.18.110.58:5060 SIP/2.0

Via: SIP/2.0/UDP 172.18.110.65:5060;branch=z9hG4bKBB1
From: <sip:18005532447@172.18.110.65>;tag= 4FD707ED-1
To: <sip: 14085267209@172.18.110.58:5060>
! Voice Class URI Configuration

voice class uri viaHeader sip
host ipv4:172.18.110.65
!
incoming uri via viaHeader
!
Example 8-7 shows how to define various voice class
uri statements to further illustrate voice class uri
usage. For example, voice class uri HOST sip can
perform a match on many different types of host URIs,
including regex matches, DNS fully qualified domain
names (FQDNs), and IPv4 and IPv6 addresses. voice
class uri USER sip and voice class uri UserRegex
sip show how to match aspects of the user ID portion of
a URI.
At the end of Example 8-7 are more regex samples that

use the pattern command to perform more complex
regex matches on any aspect of the URI. voice class uri
ipRegex sip is a one-line statement that matches
172.18.110.101, 172.18.110.103, 172.18.110.104, or
10.10.10.10 via the pipe regex character (|), which
indicates a ternary OR operation, and thus matches the
first regex statement OR the second regex statement
within the parentheses.
With a bit of practice, you can leverage voice class uri

statements to match dial peers in ways that match
statements such as incoming called-number,
answer-address, and incoming calling do not allow.
You can then apply these statements to a dial peer by
using the syntax defined in the right column in Table 8-
2. Example 8-7 ends with the assignment of multiple
incoming uri commands to a dial peer for inbound dial
peer examination for the Via, Request-URI, To, and
From SIP header URIs.
Example 8-7 A Collection of Miscellaneous Voice Class

URI Commands and Their Uses
! Creation
voice class uri HOST sip

host (.*).webex.com
host dns:ccnpcollab.lab
host ipv4:172.18.110.42
host ipv6:[2000::27E:95FF:FE8C:9991]
!
voice class uri USER sip
user-id testUsername
!
voice class uri UserRegex sip
user-id test(.*)
!
voice class uri patternRegex sip
pattern 86753.*
!
voice class uri hostRegex sip
pattern (.*).cisco.com
!
voice class uri portRegex sip
pattern :5065
!
voice class uri ipRegex sip
pattern (172\.18\.110\.10[134]|10\.10\.10\.10)
!
! Assignment

incoming uri via HOST
incoming uri request hostRegex
incoming uri to patternRegex
incoming uri from portRegex
!
Tip
All inbound matching commands can be defined on a dial peer at the same
time. For example, the incoming called-number and incoming uri
statements can both reside on the same inbound dial peer. The dial peer
match criteria commands are still evaluated according to the preference order
in Table 8-2.
Now that we have covered inbound dial peer matching

techniques, the next section discusses how CUBE makes
call routing decisions and selects outbound dial peers.
Outbound Dial Peer Matching

The previous sections of this chapter detail how to match
an inbound call leg to an inbound dial peer. This section
examines how to achieve CUBE’s main functionality and
route calls to the next-hop call agent. Here we look at
outbound dial peers. IOS has an order of operations that
defines the method of selecting outbound dial peers.
Table 8-5 details this order of operations.
IOS examines each row’s match criteria and dial peer

match criteria commands for an applicable match to
route a call to the next-hop call agent. If a match is
found, outbound dial peer matching checks stop, and the
call is routed using the configuration on that dial peer. If
zero eligible dial peer matches are found for a row’s
match criteria commands, the next row’s match criteria
is examined. This process repeats until there are no more
dial peers to check. Unlike with inbound dial peers, there
is no default outbound dial peer. If no matches are found
on any match criteria command, the call fails with a SIP
404 Not Found error and cause code 1 for an unallocated
number.
Table 8-5 Outbound SIP Dial Peer Selection Preference

Outbound Dial Peer Hunting Logic and Tiebreakers
When attempting to route a call and perform an

outbound dial peer selection, IOS uses the logic dictated
by the dial-peer hunt command to determine which
dial peer of a given match criteria should be used. The
default configuration for dial-peer hunt is 0, which
indicates “Longest match in phone number, explicit
preference, random selection.” As this suggests, the
concept of longest, most specific match applies to
outbound dial peers just as it applies to inbound dial
peers. When two dial peers with a given match criteria
command can route a call, the one with the most
explicitly defined digits takes precedence. If both dial
peers have the same number of explicit digits, IOS looks
at the administrator’s defined preference command.
The default dial peer preference is 0, with that value,
zero, also being the highest (most important) preference.
If there is still a tie, IOS selects one of the two dial peers
at random. This type of hunting can be changed by using
the command syntax shown in Example 8-8. To view the
current outbound dial peer hunting, you use the show
dial-peer voice summary command and check the
first line of the output for the current configuration. In
Example 8-8, the show command output also indicates
that the two dial peers configured for outbound call
routing are administratively up and operationally up. For
an outbound dial peer to be up/up, both an outbound
matching command and next-hop session information
must be configured. Omitting either of these items will
remove the dial peer from outbound call routing
selection. (The following sections provide more
information about these two prerequisites and their
required commands.)
Example 8-8 CLI Output Detailing Dial Peer Hunt
Usage Definitions
rtp-cube(config)# dial-peer hunt ?

<0-7> Dial-peer hunting choices, listed in hunting
0 - Longest match in phone number, explicit preference,

random selection.
1 - Longest match in phone number, explicit prefere

2 - Explicit preference, longest match in phone num
3 - Explicit preference, longest match in phone num
4 - Least recent use, longest match in phone number
5 - Least recent use, explicit preference, longest
6 - Random selection.
7 - Least recent use.
dial-peer hunt 0
AD PRE PASS
3 voip up up 1408....... 0
33 voip up up 9T 0
Routing Calls with destination-pattern and session target
Most deployments route calls based on the called

number. In this scenario, the most common outbound
dial peer command is destination-pattern. This
command utilizes dial peer wildcards and regex to
perform a match on the called number. However, unless
you instruct CUBE where to send the call when this dial
peer is matched, the destination-pattern command
alone does not offer much value. You must also configure
a session target that defines the Layer 3 addressing
information of the next-hop device CUBE will attempt to
establish a session with and route the call toward.
Let’s say that CUBE receives two different phone calls,

each with a different SIP INVITE message. The inbound
dial peer matching has been completed, and you now
need to select an eligible outbound dial peer to route the
call. The following called numbers are found in the SIP
INVITE’s Request-URI:
• INVITE sip:14085267209@172.18.110.42:5060
SIP/2.0
• INVITE sip:918005532447@172.18.110.42:5060
SIP/2.0
Example 8-9 shows two dial peers configured on CUBE.

For the first number, 14085267209, dial peer 3 can be
used to route the call based on the destination-
pattern 1408....... command matching 1408xxxxxx of
the called number 14085267209. IOS creates an
outbound TCP SIP connection to the IPv4 address
172.18.110.91 as per the configured outbound session
transport, session protocol, and session target
commands. For the second number, 918005532447, dial
peer 33 and 333 both match on the same number of
digits (the leading 9). As a result, with the default dial
peer hunting scheme, IOS looks at the preference
assigned to the dial peer. Dial peer 333 has a preference
of 1, and dial peer 33 has a preference of 2. This means
dial peer 333 is used for the outbound connection. CUBE
then establishes a UDP SIP session with 172.18.110.66 as
per the two commands session protocol and session
target. Because the session transport command is
not configured, the dial peer assumes the default global
outbound transport type, which would be configured in
sip subsection of voice service voip using the same
session transport command. If that has not been
defined either, UDP will be used as the default value for
outbound session transport.
Example 8-9 A Sample Configuration for Multiple
Outbound Dial Peers
rtp-cube# show run | section ice 3

destination-pattern 1408.......$
session target ipv4:172.18.110.91
session transport tcp
!
preference 2
destination-pattern 9..........$
huntstop
!
preference 1
destination-pattern 9..........$
!
Tip
Dial peers assume the default session protocol H.323 when the session
protocol command is omitted from a VoIP dial peer.
IOS selects only one dial peer at a time for outbound call
routing purposes. If a call setup failure occurs on the
selected outbound dial peer, the next best outbound dial
peer is used, and the outbound dial peer selection
process proceeds normally. In this scenario, if the call
setup signaling for dial peer 3 and 14085267209 failed,
IOS would attempt to select a new dial peer. The
remaining dial peers, 33 and 333, do not match the
called number, and thus the call fails completely. With
the second number, 918005532447, if dial peer 333 fails
during the call setup signaling, dial peer 33 is attempted
for outbound call routing purposes. If session
establishment on this dial peer also fails, IOS typically
continues hunting for eligible outbound dial peers.
However, dial peer 33 in this example has the command
huntstop, which instructs IOS to stop call routing and
dial peer hunting if a call setup failure is observed on a
session attempting to use that dial peer. As a result, dial
peer 3 is never evaluated, and the call fails completely.
The huntstop command should be applied to the last
dial peer in a sequence of similar dial peers to avoid
routing calls to undesired locations and potentially
creating unwanted call loops. Note that if IOS
establishes/connects a session using an outbound dial
peer and the call fails later for any reason, dial peer
hunting does not resume.
Table 8-6 describes the commands shown in Example 8-

9.
Table 8-6 Outbound Dial Peer Commands
Tip
The commands show dial-peer voice numeric-tag or show run all | dial-peer
voice numeric-tag can be used to view every setting of a dial peer, including
the default settings not shown with a standard show run command. Replace
numeric-tag with the numeric identifier assigned to the dial peer you want to
view.
The session target command is a very important

command for outbound call routing. After all, if IOS is
not instructed where to send a call, the dial peer is not
eligible for outbound call routing. Unfortunately, the
context-sensitive help using the question mark (?) leaves
much to be desired. Table 8-7 details all the different
options for the session target command.
Table 8-7 Inputs for the session target target-

address Command
Note
Session targets for SAF, loopback, and enumerations are beyond the scope of
the CLACCM 300-815 exam but have been included in the table to provide a
complete list. In addition, older IOS versions may accept arguments such as
ras and settlement providers, which are no longer supported by CUBE.
The session target dns command has a few wildcard

macro options that you can use in creative ways to
influence DNS queries sourced from a device. Table 8-8
describes the wildcard values and provides examples.
Table 8-8 DNS Wildcards
Matching Outbound Dial Peers Using URIs

Just like their inbound counterparts, outbound dial peer
matching commands can leverage SIP URIs. The
destination uri command allows the outbound dial
peer lookup and matches on the host portion of the
Request-URI. Example 8-10 shows the commands
required to enable call routing based on URI with CUBE.
The call-route url command instructs CUBE to route
calls based on the Request-URI. The voice class uri
command is then leveraged to define the match
statement for which IOS should check the Request-URI
header. This is then applied to the outbound dial peer
with destination uri CUCM. The session target
command is then defined as session target sip-uri,
which instructs IOS to derive the IP address of the next
hop from the ingress Request-URI. Because we are using
this for matching purposes, it is rtp-
cucm.ccnpcollab.lab. The command requri-passing
is needed because in normal operation, CUBE replaces
the Request-URI and To headers with the IP address
defined by the session target. With this command in
place, CUBE passes the received URI in those two
headers.
Example 8-10 also shows debugging using this

configuration to route an inbound SIP INVITE message
received with the Request-URI 1008@rtp-
cucm.ccnpcollab.lab. Inbound dial peer matching
debugging has been excluded as the example focuses on
the outbound dial peer operation. When performing
outbound dial peer selection, CUBE selects dial peer 777,
based on the destination uri statement configured
using the voice class uri and host dns statements.
When the outbound dial peer is selected, CUBE
determines that the session target for the selected
outbound dial peer is a SIP URI, and thus a DNS
resolution is required to ascertain the IP address of the
FQDN. Next, CUBE passes the Request-URI header from
the inbound SIP message to the outbound SIP message,
which is then put on the line and sent to the IP address
gleaned from the DNS resolution.
Example 8-10 A Sample Configuration and Debugging

Detailing How to Route Calls Based on the Request-URI
Header
### Configuration
!
voice service voip
sip
call-route url
requri-passing
!
voice class uri CUCM sip
host dns:rtp-cucm.ccnpcollab.lab
!
destination uri CUCM
session target sip-uri
!
### Debugging
005275: *Apr 9 18:11:42.529: //-1/xxxxxxxxxxxx/SIP/M
Received:
005560: *Apr 9 18:11:42.537: //-1/824242DB804A/DPM/d

Match Rule=DP_MATCH_DEST_URI; URI=sip:1008@rtp-cuc
005562: *Apr 9 18:11:42.537: //21/824242DB804A/CCAPI
[..truncated..]
Guid=824242DB-79C9-11EA-804A-B636EC901AA2, Outgoin
005622: *Apr 9 18:11:42.538: //16/665021018033/SIP/I

005626: *Apr 9 18:11:42.539: //-1/xxxxxxxxxxxx/SIP/I
005978: *Apr 9 18:11:42.547: //16/665021018033/SIP/I

005980: *Apr 9 18:11:42.547: //16/665021018033/SIP/I
005984: *Apr 9 18:11:42.547: //16/665021018033/SIP/I
005985: *Apr 9 18:11:42.547: //16/665021018033/SIP/I
006042: *Apr 9 18:11:42.549: //16/665021018033/SIP/M

Sent:
Note
If a fully qualified domain name is in use for the Request-URI header, a
successful DNS resolution needs to occur before it is possible to establish a
session with the remote user agent.
Many other outbound dial peer matching commands are

covered in the following sections.
Dial Peer Aggregation and Summarization Techniques

As an enterprise grows to include more and more devices
that need to communicate with public networks, the
number of dial peers that need to be configured for
various scenarios also grows. Up to this point in the
chapter, only a few dial peers have been used in the
examples to illustrate specific topics. Imagine a scenario
where there are many discontiguous direct inward
dialing (DID) ranges that CUBE needs to handle for
inbound calls, and there are many different dialing
patterns required for outbound calls. There may be two
or more Unified CM clusters with multiple call
processing nodes for application redundancy. Similarly,
there may be redundancy on the service provider
network, with multiple IP addresses and trunks for PSTN
redundancy. If you were to attempt a configuration that
handles these variable and permutations by using the
configurations examined up to this point, the number of
dial peers required would be very high. The greater the
number of dial peers, the greater the administrative
overhead for maintaining and troubleshooting. Luckily, a
few aggregation and summarization techniques can be
used with CUBE to ease the administrative burden in
scenarios like this.
E.164 Pattern Maps
One aggregation technique involves the use of an E.164

pattern map. With traditional dial peer configuration,
you can configure only a single destination-pattern or
incoming called-number command per dial peer.
Even with regex and wildcards defined for maximum
matches, this can mean a lot of dial peers. By using E.164
pattern maps, you can define a list of dial peer wildcard
regex patterns as E.164 pattern entries and then apply an
entire E.164 pattern map to a dial peer with either the
incoming called e164-pattern-map or destination
e164-pattern-map command. This effectively means
that one dial peer can be configured to handle hundreds
of incoming called number and destination pattern regex
statements! Example 8-11 shows a sample configuration
that can be used as a starting point for most CUBE
deployments. In this example, e164-pattern-map 1 is
used to match many of the different local, long-distance,
and international dialing patterns used in the North
American numbering plan (NANP). These all start with
the enterprise PSTN outcall number 9. The last E.164
pattern matches 911 and 9911, depending on how an end
user can dial the emergency number from an endpoint.
This E.164 pattern map is then assigned to an inbound
dial peer and an outbound dial peer for routing calls
from the enterprise to the service provider network. In
e164-pattern-map 2, there are multiple DID ranges
defined; they refer to numbers owned by the enterprise.
These numbers are then assigned to dial peers for
routing inbound calls from the service provider PSTN to
Unified CM on the enterprise LAN. The 4 dial peers in
this configuration could easily be more than 16 dial peers
with the traditional incoming called-number and
destination-pattern commands.
Example 8-11 A Sample Configuration Using e164-

pattern-map
! OUTBOUND Calls
voice class e164-pattern-map 1

description E164 Pattern Map for PSTN Number Ranges
e164 9[2-9]......$
e164 91[2-9]..[2-9]......$
e164 9011T
e164 9?911$
!
description Incoming from CUCM to CUBE
incoming called e164-pattern-map 1
!
description Outbound from CUBE to PSTN
destination e164-pattern-map 1
!
! INBOUND CALLS

description E164 Pattern Map for DID Number Ranges
e164 1408.......$
e164 1919574....$
e164 1919392....$
e164 +1T
!
description Incoming from PSTN to CUBE
!
description Outbound from CUBE to CUCM
!
Note that E.164 patterns maps can also be loaded from a

.cfg file on the flash or a network location such as HTTP
or FTP. When using a configuration file, up to 5000
E.164 entries can be present to allow for even greater
aggregation and control. This file could be used manually
or even levered for network automation purposes.
Imagine a scenario where DIDs change regularly. Rather
than change the E.164 pattern maps by hand, you could
use a third-party DID management tool for DID
management and tracking. This tool could output a .cfg
file, in the required format, to a network location. You
could then have CUBE access and load this file at a given
time by using the voice class e164-pattern-map load
and configuring a Kron policy with the kron command
set, as shown in Example 8-12. You can use the
command show voice class e164-pattern-map to
view the contents of a static loaded E.164 pattern map.
(For more information on IOS Kron policies, see
https://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/cns/configuration/15-s/cns-15-s-book/cns-cmd-
sched.html.)
Example 8-12 A Sample Showing Kron and E.164

Pattern Map Usage
!
url http://http-host/config-files/pattern-map.cfg
!
dial-peer voice 11
Session protocol sipv2
!
kron occurrence e164-pattern-load at 0:00 Sun recurri
policy-list e164-pattern-load
!
kron policy-list e164-pattern-load
cli voice class e164-pattern-map load 11
!
Session Server Groups
It is possible to aggregate multiple session target

commands into one logical group by using the voice
class server-group command. A server group can
contain up to five IPv4 or IPv6 entries and is applied to
an outbound dial peer. Using server groups along with
E.164 pattern maps can greatly reduce the number of
dial peers configured on a system when the next-hop
devices leverage application redundancy through
clustering. Example 8-13 shows a sample voice-class
server-group command with IPv4 and IPv6 entries.
This server group is set up for the round-robin hunting
scheme. The default hunting scheme uses the preference
defined by the administrator. The command show
voice class server-group can be leveraged to view
elements of a server group.
Example 8-13 A Sample Configuration Detailing Voice

Class Server Group Usage
!
voice class server-group 22
description CUCM Servers
hunt-scheme round-robin
ipv4 172.18.110.91 port 5060 preference 1
ipv6 2000::245:1DFF:FED2:991 port 5060 preference 3
!

e164 1408.......$
e164 1919574....$
e164 1919392....$
e164 +1T
!
!
session server-group 22
!
DNS SRV Load Balancing
As you might have noticed, there is not a DNS entry
available in the voice class server-group
configuration. In fact, DNS has a built-in load balancing
mechanism. By leveraging DNS SRV load balancing, you
can use a single session target dns entry to service any
number of IP addresses and thus aggregate session
targets and dial peers. RFC 2782 defines DNS SRV and
indicates that a DNS SRV query has the following
format:
_Service._Proto.Name TTL Class SRV Priority Weight Po
The fields in the SRV record are as follows:
• _Service: The name of the service being used.
• _Proto: The transport protocol used to

communicate with the server.
• Name: The domain name for the request.
• TTL: The time to live, in seconds, which indicates

how long the record will be cached by the DNS
client.
• Class: SRV records belong to the INTERNET (IN)

class with code type 22.
• Weight: The priority of the entry. The larger the

weight, the higher the priority. The default is 0.
• Port and Target: The port and hostname of the

device providing the service.
Upon receiving a DNS SRV query from a DNS client, a

DNS server responds to the DNS SRV query with
multiple A or AAAA records. Depending on the weight of
these results, the DNS client can perform a second DNS
lookup on the A or AAAA record to retrieve the IP
address. CUBE can assume the role of a DNS client and
attempt to perform different DNS SRV lookups,
depending on the session protocol, session
transport, session target dns, and voice-class sip
url commands configured on the dial peer. Example 8-
14 shows the different types of SRV lookups CUBE
performs, along with the dial peer configurations that
triggered the lookups.
Example 8-14 A Sample Configuration for DNS SRV

Usage with Dial Peers
! _sip._udp. DNS SRV Query on port 5060

session transport udp
session target dns:ccnpcollab.lab
!
! _sip._tcp. DNS SRV Query on port 5060

!
! _sip._tcp. DNS SRV Query on Port 5061

session transport tcp tls
!
! _sips._tcp. DNS SRV Query on port 5061

session transport tcp tls
voice-class sip url sips
!
An administrator can force CUBE to skip the DNS SRV

query by simply including a port at the end of the
session target dns command. For example, session
target dns:ccnpcollab.lab will perform a DNS SRV
query while session target
dns:ccnpcollab.lab:5060 will perform a regular DNS
A record query.
CUBE can be configured to interface with an external

DNS server or can be configured to perform DNS SRV
lookups locally by also acting as a DNS server. In
Example 8-15, the DNS name server is configured with
the ip name-server command. If CUBE is the local
DNS server, this command references CUBE’s IP
address. Next, the IP domain lookup needs to be
enabled. Then, depending on the dial peer configuration,
one of the four groupings of SRV commands is
configured by using ip host commands. The A record is
defined at the end of a command. Finally, the A record–
to–IP address mapping is defined in the last set of ip
host commands.
Example 8-15 A Reference Configuration That Can Be

Leveraged for Local DNS SRV Lookups
!
ip name-server 172.18.110.42
!
ip domain lookup
!
ip host _sip._udp.ccnpcollab.lab srv 1 50 5060 1.ccnp
!
ip host _sip._tcp.ccnpcollab.lab srv 1 50 5060 1.ccnp
!
!
ip host _sips._tcp.ccnpcollab.lab srv 1 50 5061 1.ccn
!
ip host 1.ccnpcollab.lab 10.10.10.1
!
When debugging DNS issues on IOS, use the following

show and debug commands to view currently cached IP
addresses and debug the DNS SRV query process:
show host
debug ip domain
debug ip dns view
debug ccsip transport
Putting It Together
Together, E.164 pattern maps, session server groups, and
DNS SRV queries can greatly reduce the total number of
dial peers and the amount of administrative overhead
involved in large collaboration deployments. The
following section covers some advanced call routing
scenarios. The summarization and aggregation
techniques covered in this section can also be applied to
the topics covered in the next section. Example 8-16
shows a sample configuration that leverages all of these
summarization and aggregation techniques.
Example 8-16 A Reference Configuration That

Leverages the Aggregation and Summarization
Techniques Presented So Far
! OUTBOUND Calls from LAN to ITSP

e164 9[2-9]......$
e164 91[2-9]..[2-9]......$
e164 9011T
e164 9?911$
!
description Incoming from CUCM to CUBE
!
description Outbound from CUBE to PSTN
session target dns:myITSP.itspDomain.com
!
! INBOUND CALLS from ITSP to LAN

e164 1408.......$
e164 1919574....$
e164 1919392....$
e164 +1T
!
description CUCM Servers
hunt-scheme round-robin
!
!
!
Advanced Call Routing Techniques

So far in this chapter, we have looked at some common
scenarios for matching inbound dial peers on incoming
call legs, routing, and establishing an outbound call leg
using an outbound dial peer. A key point to remember is
that there is no standard configuration for routing calls
through CUBE. The commands detailed in the previous
sections give you granular control over how sessions are
established and how inbound and outbound call legs are
handled with CUBE. These commands can be leveraged
in many different combinations and permutations to
meet the call routing requirements of a business. The
following sections show how to use the commands from
the previous section to achieve advanced call routing
requirements in various scenarios.
Dial Peer Groups (DPGs)
As you have already seen in this chapter, the inbound

dial peer selected for an inbound call leg can play a role
in the selection of outbound dial peers. One way to force
a call to use a specific outbound dial peer if a specific
inbound dial peer is selected is to use a dial peer group
(DPG). A DPG creates a static association between an
inbound dial peer and one or more outbound dial peers.
This is the first option in Table 8-5 because no other
outbound dial peer matching criteria are evaluated when
a DPG exists on an inbound dial peer matched on the
inbound call leg.
Example 8-17 shows a DPG configured with the

command voice class dpg number. Dial peers are
assigned with the dial peer subcommand, and a
preference can optionally be applied. The default
preference is 0 (which is also the highest preference).
The DPG is then applied to the inbound dial peer by
using the destination dpg command. In this scenario,
the called number 14085267209 would match dial peer 4
as the inbound dial peer due to the exact match
incoming called-number 14085267209 command.
Because this dial peer is configured with a destination
dpg command, IOS looks at the dial peer configured as
the destination for the call. The dial peers configured on
the DPG are ordered by preference, and IOS selects the
highest-preference dial peer for the outbound dial peer.
In this example, only dial peer 400 is configured, and it
is selected as the outbound dial peer. An outbound call
leg session is set up using TCP SIP with the IP address
returned by the DNS query on the FQDN (sj-
cucm.ccnpcollab.lab), as per the session transport,
session protocol, and session target commands.
Note
In Example 8-17, destination-pattern has the value AAAAA, which does not
match the called number 14085267209. IOS still selects this dial peer as the
outbound dial peer. The reasoning is that the destination-pattern command is
not evaluated when selecting an outbound dial peer defined by a DPG. The
destination-pattern command is only required to place the outbound dial peer
in an administratively up and operationally up state, as discussed earlier in this
chapter. As a result, it is best to set destination-pattern for dial peers used in
DPGs to a value such as AAAAA so that it is not easily selected erroneously
for normal outbound call routing lookups on dial peers that do not have DPGs
assigned. The command show voice class dpg can be used to view the
contents of a given dial peer group.
Example 8-17 A Sample Dial Peer Group Configuration
voice class dpg 400

dial-peer 400 preference 1
!
destination dpg 400
incoming called-number 14085267209

!
destination-pattern AAAAA

session target dns:sj-cucm.ccnpcollab.lab
!
Sourced-Based Call Routing with Dial Peer Groups

Source-based routing involves routing a call from a
specific source to a static predefined destination,
regardless of the calling/called number. The source
match is performed by the voice class uri command
assigned to an inbound dial peer. All calls with this
source match the incoming uri statement, which is one
of the first inbound match criteria checked. Then a DPG
is assigned to the same inbound dial peer to force CUBE
to use a specified outbound dial peer configured by the
administrator. Example 8-18 shows voice class uri
assigned to dial peer 5 to match all calls from a specific
IP address in the SIP From header. When any call with a
From header containing the IP address 172.18.110.65 is
received, inbound dial peer 5 is selected, and the DPG is
leveraged to select outbound dial peer 500 for outbound
call routing. Note that dial peer 500 has destination-
pattern set to AAAA, which forces the dial peer into an
operationally up state. destination-pattern is not
leveraged during this call as the DPG has already
selected this dial peer as the outbound dial peer for the
call.
Example 8-18 A Sample Configuration for Source-

Based Routing
!
voice class uri 5 sip
host ipv4:172.18.110.65
!
voice class dpg 500
dial-peer 500
!
destination dpg 500
incoming uri from 5
!
destination-pattern AAAA
!
Dial Peer Provision Policy Routing
A dial peer provision policy (DPP) allows you to use

information from the inbound SIP header URIs as values
for looking up an outbound dial peer. A DPP is created
and then assigned to an inbound dial peer. When that
inbound dial peer is leveraged for an inbound call leg, the
policy is invoked, and outbound dial peers are evaluated
according to the defined policy. The policy may define a
single match criteria or two match criteria attributes that
need to be evaluated on the outbound dial peers. When
two match criteria attributes are configured on the same
policy preference, both attributes are evaluated for
matches at the same time. If either match statement fails
to match the call properly, the outbound dial peer is not
selected.
You can define two policies per DPP with the

preference command. This preference also determines
the order in which each policy will be evaluated. Policy
preference 2 will be evaluated only when policy
preference 1 returns zero applicable dial peer matches.
Only one of the secondary attributes can be selected. The
secondary attributes are filtered based on the primary
attribute entered. Table 8-9 defines the permutations of
primary and secondary policy attributes for the policy
preference command.
Table 8-9 The Permutations of Match Criteria

Attributes for a Dial Peer Provision Policy
The last DPP requirement is to configure the outbound

dial peers to match by using the match attributes
selected in the policy. Using the information from Table
8-9, you can now examine Table 8-10, which maps the
attributes to their respective outbound dial peer match
criteria commands.
Table 8-10 The Mapping of Dial Peer Match Criteria

Commands to the Dial Peer Policy Syntax
Example 8-19 uses the information from Table 8-9 and
Table 8-10 to show two specific scenarios using dial peer
groups. Both of these scenarios use a common ingress
SIP INVITE message, and the Request-URI, From, and
To headers are displayed. Two voice-class uri
commands are used: one for the From Header user ID
and the second for the To Header user ID. A DPP has
been created, with two preference options. The first
preference instructs CUBE to search for an outbound
dial peer that matches both the FROM and TO headers.
Dial peer 12345 is outfitted with both destination uri-
from FROM and destination uri-to TO, which point
to the voice class uri commands defined earlier. The
second policy is invoked only if the first policy returns
zero matches. This second policy instructs IOS to look for
whether the called number and dial peer 11111 has been
configured with an exact match destination-pattern
14085267209 command.
Example 8-19 An Example of DPP Use on a Sample SIP

INVITE Message
### Received INVITE
INVITE sip:14085267209@172.18.110.58:5060 SIP/2.0

From: <sip:18005532447@172.18.110.65>;tag=1
To: <sip: 14085267209@172.18.110.58:5060>
### Configurations
!
voice class uri FROM sip
user-id 18005532447
!
voice class uri TO sip
user-id 14085267209
!
voice class dial-peer provision-policy 1
description match From AND To header. If false, try
preference 1 from to
preference 2 called
!
destination provision-policy 1
!
destination uri-from FROM
destination uri-to TO
!
destination-pattern 14085267209
!
Dial Peer Groups Versus Dial Peer Provision Policies

DPGs and DPPs both enable you to influence outbound
dial peer matching and call routing based on the
incoming call leg and incoming dial peer. The main
difference between the two options is that DPGs are far
more static and less customizable. That is, the mapping
of inbound dial peer to outbound dial peer for matching
does not leave much room for intricate call routing. With
a DPP, on the other hand, there is far more room for
customization. You can leverage DPP to force CUBE to
perform an outbound dial peer lookup using specific
match criteria commands. These commands can use
traditional dial peer wildcard and regex statements. The
customization possible with a DPP can be useful for
solving complex call routing requirements.
Intercluster Lookup Service (ILS) Call Routing on CUBE

As discussed in Chapter 4, “Unified CM Call Routing and
Digit Manipulation,” SIP trunks can be configured to
send the x-cisco-dest-route-string SIP header for
outbound SIP INVITE messages when the Unified CM
SIP profile setting Send ILS Learned Destination Route
String is enabled. This header is very beneficial to CUBE
as it may be placed in between two Unified CM clusters
for ILS call routing. CUBE has a set of configurations you
can leverage to assist with call routing in this type of
deployment. Example 8-20 shows the configuration
required to get a single direction working for ILS with
CUBE between two Unified CM clusters.
Example 8-20 ILS Route String CUBE Configuration
!
voice class uri CISCO sip
pattern cisco.com
!
voice class route-string 1
pattern svs-alpha-c1.cisco.com
!
voice class sip-hdr-passthrulist 1
passthru-hdr x-cisco-dest-route-string
!
description INBOUND dial-peer
incoming uri request CISCO
voice-class sip call-route url
voice-class sip requri-passing
voice-class sip pass-thru headers 1
!
description OUTBOUND dial-peer
destination route-string 1
voice-class sip call-route dest-route-string
!
The first thing you should notice about Example 8-20 is

that it includes many of the commands previously
discussed in this chapter. ILS can send alphanumeric SIP
URIs, so CUBE needs to leverage these command sets to
properly handle alphanumeric URIs. At the beginning of
the example, you can see voice class uri configured for
the pattern cisco.com, which will be used later to match
the inbound dial peer, based on the domain portion of
the SIP request. Next, the command voice class route-
string defines a numeric tag and regex pattern for
matching the x-cisco-dest-route-string SIP header.
This will later be applied to the outbound dial peer. Next,
the voice class sip-hdr-passthrulist command is
configured with passthru-hdr for the x-cisco-dest-
route-string SIP header that Unified CM will be
supplying. (This is a defined header to pass through
CUBE from the inbound call leg to the outbound call leg.)
This command is discussed in more detail later in this
chapter, but for now, just note that it is required here to
ensure that the remote Unified CM server receives the
destination route string information sent by the
originating Unified CM server.
The next configuration is the inbound dial peer (dial

peer voice 1 voip), which matches inbound SIP
requests based on the CISCO voice class URI. The voice-
class uri command should be well known by this point
in the chapter; the syntax to apply to dial peer 1 is
incoming uri request CISCO. Next, there are a few
new variants of the voice-class sip command we looked
at earlier in the chapter. Both voice-class sip call-
route url and voice-class sip requri-passing
operate the same as their goal voice service voip
configuration counterparts commands described earlier
in the this chapter:
• The voice-class sip call-route url command,

when applied globally or on a dial peer, instructs
CUBE to look at the entire SIP Request-URI rather
than at the E.164 numeric-only user portion of the
Request-URI header. Without this command
configured, you would see a 484 Address
Incomplete error along with cause code 28.
• The voice-class sip requri-passing command

instructs CUBE to pass the Request-URI from the
inbound call leg to the outbound call leg without
modification. Remember that without this
command, CUBE replaces the domain portion of
the Request-URI with the session target configured
on the outbound dial peer.
Finally, the inbound dial peer is configured to pass

through the SIP headers from the aforementioned sip-
hdr-passthrulist via the voice-class sip pass-thru
headers command.
The outbound dial peer, created with dial-peer voice 2

voip, is configured as you would expect except for two
new commands that are exclusive to the ILS feature:
• The destination route-string command

references the voice class route-string and
pattern configured earlier. During call routing
operations, CUBE compares the received value in
the x-cisco-dest-route-string header to any
available destination route-string/voice class
route-string patterns to determine if an outbound
dial peer can be matched successfully.
• The voice-class sip call-route dest-route-

string command enables CUBE for route string
based call routing. This can be configured globally
via the voice service voip and sip subsection, but
for the sake of brevity, it has been configured only
on the outbound dial peer, which is also configured
with the destination route-string command.
With the configuration from Example 8-20 in place on

CUBE, you can now route ILS calls for a remote Unified
CM server through CUBE. (Refer to Chapter 4 for ILS
configuration on Unified CM.) The debugging sample in
Example 8-21 shows Unified CM sending a call to CUBE
for kydavis@cisco.com by using debug voip dialpeer
along with debug voip ccapi inout and debug ccsip
messages. You can see that the following steps occur:
Step 1. A SIP INVITE message is received for

kydavis@cisco.com with the X-cisco-dest-
route-string value svs-alpha-
c1.cisco.com.
Step 2. An inbound dial peer match for dial peer 2 is

configured to match based on the cisco.com
domain portion of the received Request-URI.
This dial peer match also applies the
commands for URI call routing, Request-URI
passing, and header passthrough that are
required for this type of call.
Step 3. The dial peer debugging shows CUBE

checking the received route string against
available dial peers and ultimately arriving at
a match on dial peer 2 due to the two route
string configurations applied to that dial peer.
Step 4. CUBE sends a SIP INVITE message to the

session target configured on the dial peer.
Notice that, due to the configuration on the
inbound dial peer, the outbound SIP INVITE
message contains the original Request-URI
kydavis@cisco.com rather than
kydavis@10.122.249.70, along with the full x-
cisco-dest-route-string, which has been
successfully passed from the inbound call leg
to the outbound call leg.
Example 8-21 ILS Route String Debugging Sample on

CUBE
Received:
INVITE sip:kydavis@cisco.com SIP/2.0
From: <sip:9195746726@10.122.249.59>;tag=438~393fe797
To: <sip:kydavis@cisco.com>
Call-ID: 54fe580-1eb1f25b-44-3bf97a0a@10.122.249.59
X-cisco-dest-route-string: <sip:svs-alpha-c1.cisco.com>
Aug 2 00:35:12.198: //-1/054FE5800000/CCAPI/cc_api_c
[..truncated..]
Incoming Dial-peer=1, Progress Indication=NULL(0),
Aug 2 00:35:12.200: //-1/054FE5800000/DPM/dpMatchPee

Match Rule=DP_MATCH_DEST_ROUTE_STR; Destination Ro
Aug 2 00:35:12.201: //-1/054FE5800000/DPM/dpMatchPee

Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=2
Aug 2 00:35:12.201: //49/054FE5800000/CCAPI/ccCallSe

[..truncated..]
Guid=054FE580-0001-0000-0000-00293BF97A0A, Outgoin
*Aug 2 00:35:12.206: //50/054FE5800000/SIP/Msg/ccsip

Sent:
INVITE sip:kydavis@cisco.com SIP/2.0
From: <sip:9195746726@172.18.110.58>;tag=9A9706-1298
To: <sip:kydavis@cisco.com>
Call-ID: DC3D4022-D38E11EA-80B7E480-B2AED6E6@172.18.1
X-cisco-dest-route-string: <sip:svs-alpha-c1.cisco.com>
Next-Hop Availability Through SIP OPTIONS

CUBE can be configured to monitor the reachability of a
next-hop session target on a dial peer by using out-of-
dialog (OOD) SIP OPTIONS messages at defined
intervals. The voice-class sip options-keepalive
command applied on a dial peer sends a SIP OPTIONS
message every 60 seconds when the dial peer is up. If
there is no response, CUBE retries five more times before
marking the dial peer as busyout. At this point, CUBE
sends a SIP OPTIONS message to the session target
every 30 seconds, with 5 retries. If the device responds,
the dial peer is placed back into an active state. When a
dial peer is busyout, it is ineligible for outbound call
routing selection.
Dial peers are placed into busyout when one of the

following occur:
• There are zero responses to an OOD SIP OPTIONS
message and all retries are exhausted
• A 503 Service Unavailable Response is received
• A 505 SIP Version Not Supported Response is

received
All other error codes including 4xx level error codes are
considered a valid response and keep the dial peer active.
Note that a normal voice-class sip options-

keepalive command does not track elements in a server
group. Thus you should configure a voice-class sip
options-keepalive profile to ensure that the status of
every server group entry is checked. Example 8-22 shows
a sample server group and keepalive profile
configuration. A dial peer displays as active in show call
active voice summary even when elements of the
server group are down. To view the element status, you
can issue show voice class sip-options-keepalive
for the keepalive profile defined on the dial peer.
Example 8-22 A Sample OPTIONS Keepalive Profile

Used with a Server Group
rtp-cube# show run | section server-group 33|voice 33

!
voice class sip-options-keepalive 33
down-interval 30
up-interval 60
retry 5
!
ipv4 172.18.110.48
ipv4 172.18.110.65
!
voice-class sip options-keepalive profile 33
!

dial-peer hunt 0
AD PRE PASS S
TAG TYPE MIN OPER DEST-PATTERN FER THRU SESS-TAR
33 voip up up 1234 0 syst SESS-SVR
rtp-cube# show voice class sip-options-keepalive 33

Voice class sip-options-keepalive: 33 Admi
Description:
Transport: system Sip Profiles: 0
Interval(seconds) Up: 60 Down: 30
Retry: 5
Peer Tag Server Group OOD SessID OOD S

-------- ------------ ---------- -----
33 33 Activ
Server Group: 33 OOD Stat: Active

OOD SessID OOD Stat
---------- --------
3 Busy
4 Active
OOD SessID: 3 OOD Stat: Busy

Target: ipv4:172.18.110.48
OOD SessID: 4 OOD Stat: Active

Target: ipv4:172.18.110.65
Tip
The command voice-class sip options-ping is used for in-dialog SIP
OPTOINS messages (that is, SIP OPTIONS messages sent during an active
session). This differs from voice-class sip options-keepalive, which sends an
out-of-dialog (OOD) SIP OPTIONS keepalive message for checking next-hop
reachability and service.
Verify and Troubleshoot IOS Call Routing

When deploying or operating CUBE, you might at some
point need to investigate a call failure. You should work
to determine the fault of the failure and employ
corrective actions. Unlike Unified CM, CUBE does not
have the same level of persistence storage that can be
found in a fully-fledged server with dedicated hard drive
disk space. CUBE uses the local IOS logging buffer to
store debugging information, when enabled. Debugging
is not usually left running in order to avoid inadvertently
oversubscribing CPU and memory services. The
downside is that you cannot perform an analysis on a call
failure if debugging was not enabled. CUBE call failure
troubleshooting is almost always done by reproducing
the failure after IOS debugging is enabled and then
gathering the data before it is overwritten in the logging
buffer.
If you decided to keep debugging enabled and increased

the logging buffer to a very high limit, there would still
be a very small window of time before the debugging
information would overwrite itself. Depending on how
long it takes for a failure to occur and be reported by a
customer, the logs might be long gone. This time window
decreases exponentially as the number of calls per
second handled by CUBE—and therefore the number of
logs written to the buffer—increases. IOS syslogs can be
leveraged to send IOS logs and debugging information to
a dedicated syslog server, but you must be careful not to
oversubscribe CPU and memory processes, thus causing
more harm. With devices that handle thousands of calls,
this might not be an option.
With SIP CUBE, the following debug commands can

often be used to determine faults with call routing:
debug voip dialpeer

debug voice translation
debug ccsip messages
debug ccsip error
debug ccsip info
debug ccsip transport
debug voip ccapi inout
For more intrinsic issues, the commands debug ccsip

all or debug ccsip verbose can be enabled, but you
should never enable everything with these commands
without first verifying that CPU usage is low enough that
you will not impact production traffic.
Tip
Before enabling any debugging in CUBE, you should use show processes
cpu sort and show processes cpu history to verify that CPU usage is not
already above 50%. Enabling debugging may cause unwanted call failures due
to CPU spikes.
The configuration in Example 8-23 can be leveraged to

mitigate CPU spikes and ensure valid data collection
when enabling debugging. These commands enable
timestamps in the debugging down to the millisecond,
with explicit sequence numbering to verify whether any
logging data has been dropped. The buffer in this case is
set to 10 million bytes, and logging to the console and
monitor are disabled. These settings help mitigate CPU
spikes that occur when trying to print debugging
information to multiple terminals in real time. The queue
limit and rate limit have been set to high limits to avoid
dropping messages when very busy debugging is
occurring. Finally, IEC syslogs have been enabled to
provide some extra error logging when IOS is responsible
for a call failure.
Example 8-23 A Reference Configuration That Can Be

Used to Define Logging Parameters on IOS Gateways
service timestamps debug datetime msec localtime show

service timestamps log datetime msec localtime show-t
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog
When troubleshooting or verifying a dial plan, be sure to

use the information in Tables 8-2 and 8-4 from the
beginning of the chapter. It is a good practice to re-verify
the dial peer being matched by a session in debugging
even when you are confident in the configuration. Many
issues are due to matching an undesired incorrect dial
peer due to a misconfiguration. If a call is active, you can
use the command show call active voice brief |
include pid, as shown in Example 8-24, to filter the
output to the lines that contain the dial peer matched on
the incoming call leg (Answer) and outgoing call leg
(Originate). If the call completed recently, the history
variant of the same command can be leveraged: show
call history voice br | i pid. The dial-control-mib
retain-timer and dial-control-mib max-size
commands can be leveraged to increase the show call
history table. If there are many calls on the device, you
should examine the caller ID information next to
Answer and Originate to track your test call.
Example 8-24 show Command Output Detailing the

Inbound and Outbound Dial Peer Match
Router# show call active voice brief | include pid

<ID>: <CallID> <start>ms.<index> (<start>) +<connect>
362B : 109 2251638910ms.1 (*20:01:46.396 EDT Tue Sep
362B : 110 2251638930ms.1 (*20:01:46.416 EDT Tue Sep
Basic CUBE Call Routing Debug Analysis

In this section, we examine a very basic inbound and
outbound call through CUBE by using debugging.
Example 8-25 shows the information using the
commands mentioned so far in this section. This
example shows a basic inbound dial peer with an
incoming called number statement and an outbound dial
peer with the destination pattern matching on the called
number 14085267209. In the debugging output, you can
see a received SIP message with the called URI
14085267209@172.18.110.62. CUBE attempts to match
this call to any VRF instances for filtering dial peers, but
none are found. Next, there is an attempt to match the
call based on the called number, and you can see an
incoming dial peer match of 1. With the inbound dial
peer match done, CUBE must now route this call
somewhere. A dial peer lookup is performed, and dial
peers 2 and 3 are found. CUBE evaluates both dial peers
to determine the longest, most specific match and finds
that dial peer 2 has a more explicit match and thus is
used. If the call fails on dial peer 2, dial peer 3 can be
used as a backup.
The dial peer’s session target is a DNS entry, so CUBE

must perform a DNS SRV query, which returns an A
record, which is then queried to return the IP address
172.18.110.61. The dial peer has TCP as the session
transport, so a TCP socket is established, and then the
SIP INVITE message is built and sent to Unified CM,
using the information of dial peer 2. Figure 8-4
illustrates debug outputs from a sample call using this
process.
Example 8-25 A Basic Call Example and Debugging

Walkthrough
! Config

codec g711ulaw
!
preference 1
destination-pattern 1408526....$
session target dns:sj-cucm.ccnpcollab.lab
codec g711ulaw
!
huntstop
preference 2
destination-pattern 1408.......$
session target dns:rtp-cucm.ccnpcollab.lab
session transport udp
codec g711ulaw
!
! Debugs, Received INVITE
010303: Oct 14 14:54:40.960 EDT: //-1/xxxxxxxxxxxx/SI

Received:
INVITE sip:14085267209@172.18.110.62:5060 SIP/2.0
Call-ID: 1-27656@172.18.110.65
! Debugs, VRF Checking
010314: Oct 14 14:54:40.961 EDT: //-1/000000000000/SI

! Debugs, Inbound dial-peer searching
010370: Oct 14 14:54:40.968 EDT: //-1/E9A61FCE80DD/SI

010388: Oct 14 14:54:40.969 EDT: //-1/E9A61FCE80DD/DP
Calling Number=18005532447, Called Number=14085267
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Sea
Peer Info Type=DIALPEER_INFO_SPEECH
Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=1
Result=Success(0) after DP_MATCH_INCOMING_DNIS; In
010578: Oct 14 14:54:40.984 EDT: //-1/E9A61FCE80DD/CC
Interface=0x7FDF3EC2BF48, Call Info(
Calling Number=18005532447,(Calling Name=)(TON=Unk
Called Number=14085267209(TON=Unknown, NPI=Unknown
Calling Translated=FALSE, Subscriber Type Str=Unkn
Source Trkgrp Route Label=, Target Trkgrp Route La
! Debugs, Outbound dial-per selection

Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):

1: Dial-peer Tag=2
2: Dial-peer Tag=3
Result=Success(0); Outgoing Dial-peer=2 Is Matched (8

digits)
Result=Success(0); Outgoing Dial-peer=3 Is Matched (5

digits)
010716: Oct 14 14:54:40.995 EDT: //71/E9A61FCE80DD/CC

Calling Number=18005532447(TON=Unknown, NPI=Unknow
Called Number=1000(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=18005532447, Final Destination Flag
Guid=E9A61FCE-EDEA-11E9-80DD-E8A5F2283ACD, Outgoin
! DNS SRV and A Record Query

! Sent INVITE
011129: Oct 14 14:54:47.037 EDT: //72/E9A61FCE80DD/SI

Sent:
INVITE sip:14085267209@sj-cucm.ccnpcollab.lab:5060 SI
Call-ID: E9AE8676-EDEA11E9-80E3E8A5-F2283ACD@172.18.1
Figure 8-4 A Visualization of the Call and Debugging
Information Analyzed in This Section
Example 8-26 demonstrates show commands you can

use to view various aspects of active SIP sessions on
CUBE. For example, you can use show sip-ua calls
called-number or show sip-ua calls calling-
number to gather lots of useful SIP signaling and RTP
media information during an active call. The command
show call active voice brief provides more
information about a call, such as TX/RX counters for
sent/received RTP packets along with other media and
signaling information. You can use the compact form of
the command (show call active voice compact) to
get a quick at-a-glance view of an active call’s codec and
remote media IP address. Finally, you can get complete
media information for a call by using show voip rtp
connections.
Note
IOS XE gateways require the command media bulk-stats to be configured via
voice service voip in order to leverage TX/RX statistics.
Example 8-26 show Command Output for the

Debugging Information from Example 8-25, Showing
Similar Information
sj-cube# show call active voice brief

12C6 : 71 3459414160ms.1 (14:54:40.987 EDT Mon Oct 14
dur 00:00:23 tx:1140/228000 rx:1100/228000 dscp:0 me
IP 172.18.110.65:6000 SRTP: off rtt:0ms pl:0/0ms los
media inactive detected:n media contrl rcvd:n/a time
long duration call detected:n long duration call dur
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:867251d0ebfc5155adc48564c2cff41b
RemoteUUID:54e59c8c00105000a000c4b36aba1b5a
VRF: NA
12C6 : 72 3459420210ms.1 (14:54:47.037 EDT Mon Oct 14

dur 00:00:23 tx:1100/228000 rx:1140/228000 dscp:0 me
IP 14.50.214.108:28968 SRTP: off rtt:0ms pl:0/0ms lo
media inactive detected:n media contrl rcvd:n/a time
long duration call detected:n long duration call dur
LostPacketRate:0.00 OutOfOrderRate:0.00
LocalUUID:54e59c8c00105000a000c4b36aba1b5a
RemoteUUID:867251d0ebfc5155adc48564c2cff41b
VRF: NA
sj-cube# show voip rtp connection

VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP
1 71 72 8046 6000 172.18.
2 72 71 8048 28968 172.18.
Found 2 active RTP connections
sj-cube# show call active voice compact

<callID> A/O FAX T<sec> Codec type Pee
Total call-legs: 2
71 ANS T30 g711ulaw VOIP P18
72 ORG T30 g711ulaw VOIP P14
sj-cube# show sip-ua calls calling-number 18005532447

Total SIP call legs:2, User Agent Client:1, User Agen
SIP UAC CALL INFO
Call 1
SIP Call ID : E9AE8676-EDEA11E9-80E3E8
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 18005532447
Called Number : 14085267209
Called URI : sip:1000@sj-cucm.ccnpcol
Bit Flags : 0xC04018 0x90000100 0x80
CC Call ID : 72
Local UUID : 54e59c8c00105000a000c4b3
Remote UUID : 867251d0ebfc5155adc48564
Source IP Address (Sig ): 172.18.110.62
Destn SIP Req Addr:Port : [172.18.110.61]:5060
Destn SIP Resp Addr:Port: [172.18.110.61]:5060
Destination Name : sj-cucm.ccnpcollab.lab
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 72
Stream Type : voice-only (0)
Stream Media Addr Type : 1
Negotiated Codec : g711ulaw (160 bytes)
Codec Payload Type : 0
Negotiated Dtmf-relay : inband-voice
Dtmf-relay Payload Type : 0
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [172.18.110.62]:8048
Media Dest IP Addr:Port : [14.50.214.108]:28968
APPLICATION SIGNALING AND MEDIA

BINDING
Ensuring that a remote device can properly route
responses and media back to the source device is of the
utmost importance when establishing any session that
requires bidirectional communication. It all starts with
the network path used for routing packets between the
two devices charged with establishing the session. If
roundtrip networking between the two devices is
incorrect, the devices in charge of establishing sessions
will not be able to function properly. For VoIP, this can
lead to call setup failures, one-way and no-way audio
situations, or loss of access to the devices. Thus, it is very
important to ensure that there is a good round-trip
network path to facilitate bidirectional communication
for media and signaling.
Before jumping into application protocols, let’s first

examine a good bidirectional network path between two
devices. Figure 8-5 shows a sample network device,
Device 1, which has two uplinks to two different LANs.
The first interface, Gig0, has the IP address 9.9.9.9, and
the second interface, Gig1, has the IP address
10.10.10.10. These two interfaces connect to their
respective default gateways. (The IP address of each of
these gateways is omitted as it is not relevant to the
example.) The default gateways connect to a WAN, which
facilitates connection to the remote location that has a
default gateway and Device 2, with one uplink and IP
address 12.12.12.12. For the examples in the next
sections, Device 1 needs to send a request packet to
Device 2, which then sends a response packet back to
Device 1, finishing the communication session. The
examples detail every hop of the network these packets
use to communicate and transport the request and
response packets. (The data in the request and response
is not relevant for these examples and has been omitted.)
Figure 8-5 A Sample Topology That Used in Upcoming

Examples
Figure 8-6 illustrates a scenario in which Device 1 and

Device 2 attempt to communicate by using Gig0 and IP
address 9.9.9.9 as the source IP address and exit
interface for the request. In this scenario, the request
involves the following steps:
Figure 8-6 A Baseline Working Scenario with good

Network Routing
Step 1. Device 1 initiates the communication by

checking the local routing and adjacency
tables to determine where to send the packet
and which interface should be used as the exit
interface for the IP address 12.12.12.12. The
results show that Gig0 should be used for
routing packets to the remote IP address of
Device 2.
Step 2. Device 1 builds the request with the source

IP address 9.9.9.9 and routes the packet
toward the default gateway by using the
egress interface Gig0.
Step 3. Device 1’s default gateway receives the

packet then routes it to the WAN.
Step 4. The routing steps in the WAN are omitted,

but the WAN does contain all the routing
information required to send the packet to
Device 2’s default gateway.
Step 5. Device 2’s default gateway has no problem

sending the packet to Device 2 because they
reside on the same LAN.
Step 6. The request is processed by Device 2, and a

response should be generated.
In the scenario shown in Figure 8-6, the response

Step 1. Device 2 builds a response packet with the

source IP address 12.12.12.12 and destination
address 9.9.9.9 as this was the source of the
received request packet. Since Device 2 and
Device 1 reside on different networks, the
response packet sourced from Device 2 and
sent to Device 1 must be sent to the local
default gateway for Device 2.

packet and performs a routing lookup to find
out where to send the packet. This check
determines that a route exists through the
WAN.
Step 3. The WAN is easily able to route the packet to
Device 1’s default gateway.
Step 4. Device 1’s default gateway and Device 1 are

on the same LAN, so routing the packet to
Device 1 is easy.
Step 5. The response packet is received, and the

communication session completes
successfully.
Figure 8-6 illustrates that when a valid Layer 3 IP

address routing on the LAN and WAN has been
configured, establishing roundtrip sessions between two
devices goes well. Figure 8-7 shows exactly the same
scenario as Figure 8-6, but in this case, Device 1 sends
the packet from the other egress interface, Gig0, with
source IP address 10.10.10.10. Device 1 does not know it,
but the default gateway for Device 2 was not configured
with routing information for 10.10.10.10, so a failure will
occur. In the scenario shown in Figure 8-7, you see the
following actions for the request:
Figure 8-7 An Example of Bad Network Response

Routing

and which interface to use as the exit
interface for IP address 12.12.12.12. The
Device 2.
Step 2. Device 1 builds the request packet with

source IP address 10.10.10.10 and sends the
packet out Gig1 toward the default gateway
for that LAN segment.
Step 3. The default gateway receives the packet and

routes it over the WAN toward Device 2’s
default gateway.
Step 4. The WAN has all the information required

to properly route the packet to Device 2’s
default gateway.

packet and forwards it to Device 2 since they
are on the same LAN segment.
Step 6. The request is received successfully, and a

In the scenario illustrated in Figure 8-7, the response

Step 1. Device 2 builds a response packet with the

source IP address 12.12.12.12 and the
destination address 10.10.10.10 as this was
the source of the received request packet.
Because Device 2 and Device 1 reside on
different networks, the response packet
sourced from Device 2 and sent to Device 1
must be sent to the local default gateway for
Device 2.
Step 2. The default gateway receives the packet and

performs a routing table lookup to determine
where to send this packet. Here is where a
problem occurs: There are no default routes
on Device 2’s default gateway, and there are
no routes for Interface 2 of Device 1’s Gig1
interface IP address 10.10.10.10.
Step 3. Device 2’s default gateway drops the

response packet, and the communication
session fails because Device 1 does not get a
response from Device 2.
The good news is that the scenario illustrated in Figure

8-7 is easy to fix. In fact, there are two ways to solve the
problem:
• You can fix routing on LAN 2’s default gateway so

that there is a route back to Device 1’s Interface 2.
• You can change the routing on Device 1 to send the

packet out Interface 1 rather than Interface 2, thus
assuming the IP address assigned to Interface 1 as
the source IP address. This allows the remote
device’s default gateway to properly route the
response packet.
Now you might be wondering why we have all this talk

about Layer 3 IP routing in a book about Layer 7
application protocols such as SIP. The fact is, scenarios
like this arise all the time in the real world. Response
packet routing might not be possible when packets are
sourced from a specific network IP address. This
situation may arise because of security settings, due to
design elements, or because of suboptimal network
routing. Additional complexity arises when logical
interfaces such as loopback interfaces are in play. If
Interface 1 in Figure 8-7 were a loopback rather than a
physical interface, the route-changing solution would not
be an option because you cannot route packets out a
logical interface.
Fortunately, there is a third option: You can use

application protocol binding. Application protocol
binding involves “spoofing” the source of an application
packet to influence response routing at Layer 3. Figure 8-
8 illustrates a scenario that follows the same rules as
Figure 8-6 and Figure 8-7. Without any protocol binding,
the same scenario shown in Figure 8-7 would play out.
Fortunately, however, in Figure 8-8, the network
administrator has leveraged an application protocol
binding command on Device 1 to bind request traffic to
Gig0 with the IP address 9.9.9.9.
Figure 8-8 A Sample Scenario Illustrating Good

Network Response Routing with Application Protocol
Binding
In the scenario illustrated in Figure 8-8, the request


and which interface to use as the exit
interface for IP address 12.12.12.12. The
Device 2.
Step 2. Because the administrator leveraged

application protocol binding for Gig1, Device
1 spoofs the source of the request packet from
that interface while still routing the packet
out the physical interface, as per the lookup
from step 1.
Step 3. A response packet with the source IP

address 9.9.9.9 is created, and the packet is
sent out interface Gig1 toward that LAN
segment’s default gateway.
Step 4. The default gateway routes across the WAN

to LAN 2’s default gateway, as normal,
sending the packet to Device 2.
Step 5. The request is processed by Device 2, and a

In the scenario illustrated in Figure 8-8, the response

Step 1. Device 2 builds a response packet with

source IP address 12.12.12.12 and destination
address 9.9.9.9 as this was the source of the
received request packet. Because Device 2
and Device 1 reside on different networks, the
response packet sourced from Device 2 and
sent to Device 1 must be sent to the local
default gateway for Device 2. Note here that
Device 2 does not know that the packet was
sent from Gig1. The source has been spoofed
to look as if the packet came from Gig0.
Step 2. Regardless of the source IP address of the

request packet, because Device 2 and Device 1
reside on different LAN segments, Device 2
must route the response packet to the local
default gateway for further routing decisions.

packet and performs a lookup to determine
where to route the packet. Because the
destination of this response is Gig0 of Device
1, Device 2’s default gateway determines that
it must route this response packet across the
WAN. This would not be possible without
application protocol binding.
Step 4. The rest of the scenario plays out as
expected: The LAN 1 default gateway receives
the response packet and forwards it to Device
1, which receives the packet on Gig0.
Step 5. Due to the application protocol binding

created by the administrator, the response
packet is received, and the communication
session completes successfully.
Tip
Leveraging application protocol binding on physical interfaces that traverse
different network segments such as those shown in Figure 8-8 can increase
the chances of asymmetric routing for responses.
Application protocol binding can be a very valuable tool

for any network administrator. For many application
protocols, such as TFTP, FTP, HTTP, SIP, H.323, MGCP,
and SCCP, IOS binding commands can be leveraged to
solve scenarios like the one illustrated in Figure 8-7. For
SIP and CUBE, binding can be leveraged in two forms:
• Signaling/control binding: Used to change the

source IP address information in Layer 3 packets
and Layer 7 SIP headers
• Media binding: Used to change the IP source

information observed in the SIP SDP message body
With SIP, binding commands can be applied in multiple

places for granular control of calls established through
CUBE. IOS examines a configuration in the following
order and selects the first configuration found when
determining the source address information for the
session:
1. Binding commands configured on the dial peer

selected for the inbound or outbound call leg
2. Binding commands configured on a voice class
tenant, which is then assigned to a dial peer
selected for the inbound or outbound call leg
3. Binding commands configured globally via voice
service voip and sip, which affect any call leg
when the previous two bindings do not exist
When none of the binding commands mentioned

previously have been configured, CUBE and IOS leverage
both the routing table and adjacency table by way of the
Cisco Express Forwarding (CEF) table to determine the
egress interface that will be used to route SIP packets to
the network address on the session target. This
interface’s network information is then used as the
source information for the SIP packet. When good IP
routing configurations have been put in place and no
logical interfaces are used, application protocol binding
is not required.
Tip
Remember that when application protocol binding is applied, the application
packet only looks as if it was sent from the binding interface when it is received
by the remote party. The application packet still egresses through a physical
interface, as determined by IOS IP routing logic. When binding is used, always
check the routing table and CEF table with show ip route and show ip cef to
verify that the packet is being sent out the correct physical interface and to the
correct next-hop IP address. Incorrect packet routing on the local device
cannot be overcome with application protocol binding that influences response
packet routing.
With CUBE, you enable binding with a few simple

commands. Example 8-27 shows the binding commands
that can be applied for SIP dial peers, voice class
tenant commands, and global voice service voip to
bind controls (SIP signaling) and media (SDP and RTP)
to a specific source interface.
Example 8-27 A Reference Configuration for How to

Apply Signaling and Media Binding with CUBE
! Dial-peer Bind, most specific

voice-class sip bind control source-interface Loopback0

voice-class sip bind media source-interface Loopback0
!
! Voice Class Tenant Bind, secondary check
voice class tenant 8888
bind control source-interface Loopback0

bind media source-interface Loopback0
!
voice-class sip tenant 8888
!
! Global Bind, applies to all call-legs if the first
voice service voip
sip
bind control source-interface Loopback0

bind media source-interface Loopback0
Tip
Binding commands for media cannot be changed while there are active CUBE
sessions until IOS-XE 17.3.
As mentioned earlier, when no binding is configured, the

IOS CEF table is leveraged to determine the egress
interface for routing packets to the remote IP address.
The remote IP address used in the lookup may be the IP
address defined on the dial peer’s session target, or it
may be the SIP Via or Contact header IP address from an
inbound SIP request. Example 8-28 shows a sample IP
configuration, along with a dial peer that has a session
target of 172.18.110.48. The CEF table shows that the
egress interface is Gig0/0.206, which has source IP
address 14.50.244.63. This IP address is used to source
the packet sent from this device toward 172.18.110.48.
You could leverage application protocol binding to
source the packet from Loopback0 while still sending the
packet out Gig0/0.206 but without using that as the
source IP address.
Example 8-28 show Command Output Showing

Which Interface Would Be Used to Send a Packet
rtp-cube# show ip interface brief | e una

Interface IP-Address OK? Method
GigabitEthernet0/0.206 14.50.206.50 YES manual
Loopback0 172.18.110.68 YES NVRAM
KYDAVIS-CME-2951# show ip cef 172.18.110.48
172.18.110.48/32
nexthop 14.50.206.1 GigabitEthernet0/0.206
SIP application protocol binding can also be leveraged to

change the listening port for UDP, TCP, and TCP TLS
traffic sent to CUBE. By default, CUBE always listens for
inbound connections on SIP UDP/TCP port 5060 and
TLS port 5061. This can be confirmed with the show
sip-ua status command or show sip-ua connections
{udp | tcp | tcp tls} brief. Example 8-29 shows these
verification commands and the inbound listening IP
addresses. By default, CUBE listens on all IP addresses
for IPv4 and IPv6 (if configured). The listening addresses
for IPv4 and IPv6 can be limited or changed by using
global binding commands, as described in the previous
paragraphs. Inbound UDP, TCP, or TCP TLS can be
disabled by adding no transport {udp | tcp | tcp tls}
to a sip-ua configuration. For outbound transport types,
the configured session transport command is
leveraged. CUBE’s default outbound transport type is
UDP. Layer 4 UDP, TCP, and TLS CUBE interworking
does not require any configuration.
Example 8-29 A Few show Commands That Detail the

Listening IP Addresses and Ports for UDP, TCP, and TLS
rtp-cube# show sip-ua status

SIP User Agent Status
SIP User Agent for UDP : ENABLED

SIP User Agent for TCP : ENABLED
SIP User Agent for TLS over TCP : ENABLED
[..Truncated for brevity..]
rtp-cube# show sip-ua connections udp brief

-------------- SIP Transport Layer Listen Sockets ---

Conn-Id Local-Address
=========== =============================
0 [0.0.0.0]:5060:
1 [::]:5060:
rtp-cube# show sip-ua connections tcp brief


=========== =============================
0 [0.0.0.0]:5060:
1 [::]:5060:
rtp-cube# show sip-ua connections tcp tls brief


=========== =============================
0 [0.0.0.0]:5061:
1 [::]:5061:
DIGIT, HEADER, AND URI

MANIPULATION
When interfacing with third-party service providers or
other SBCs, there is a possibility that differing dial plans
may be in use. The digit format used by one party to
route a call may not be the format configured on the local
endpoints or call processing agents, such as Unified CM.
One of the most common examples is the use of the
+E.164 dial plan by the service providers while the local
LAN is configured with four-digit extensions, where the
last four digits of the full +E.164 number are what the
endpoint expects to be called. Chapter 1 and Chapter 4
discuss that deploying a globalized dial plan and placing
the +E.164 number on the endpoint mitigates the need
for these types of digit modifications on inbound calls.
On the flip side, most enterprise deployments use an
enterprise dial-out number such as 8 or 9, which is
prefixed by a user who wants to dial an off-net number.
This is used in dial planning on Unified CM and CUBE as
a steering code to differentiate calls for endpoints on the
network from calls that should be routed to an off-net
location such as the ITSP. Because the enterprise dial-
out number is used only by LAN endpoints to signal the
need to reach the PSTN, most service providers do not
want this number prefixed on a call. As a result, it must
be stripped from the called number before the call is sent
to the service providers. Again, assuming a globalized
dial plan is in place this might already have been done by
Unified CM and no digit stripping is required on the
+E.164 number received by CUBE.
Likewise, SIP headers and URIs may need to be modified

or removed to facilitate call routing and interworking
with third-party devices. CUBE Enterprise can be
leveraged to perform the required interworking for
digits, SIP headers, and SIP URIs found in calls
traversing the SBC. The next two sections detail how you
can leverage translation rules and profiles to modify
digits or SIP profiles and how you can use SIP copylists
to modify any aspects of a SIP header, including the SIP
URI.
Digit Manipulation
Digit manipulation involves changing the numeric

numbers dialed during session establishment from one
set of digits to another set of digits. Digit manipulation
may be used to change the destination of a called
number, change the caller ID of the calling party
number, or block numbers entirely. With older IOS
analog voice gateways, digit manipulation can occur in
many different places. With CUBE, the options are much
more limited. In most scenarios, digit manipulation on
CUBE involves using voice translation rules and voice
translation profiles to modify numeric digits in SIP
headers.
Voice Translation Rules and Profiles

The process of creating and applying translation rules
and profiles on CUBE involves the following steps:
Step 1. Define a voice translation rule container and

individual actionable rules. Such a container
can hold up to 100 actionable rules that
perform input matches and output
modifications based on the input match.
Step 2. Create a voice translation profile to

reference a voice translation rule and bind the
voice translation rule to a specific type of
lookup. The lookups are as follows:
• Called: This type of lookup maps to the
user ID in the SIP Request-URI header.
• Calling: This type of lookup maps to the
user ID in the SIP From, Remote-Party-ID,
P-Asserted-ID, or P-Preferred-ID header.
• Redirect-called: This type of lookup maps

to the user ID in the SIP Diversion header.
• Redirect-target: This type of lookup maps
to the user ID in the SIP Refer-To header.
• Callback-number: Unified
Communications Manager Express uses this
type of lookup to modify the callback
number shown on an IP phone.
Step 3. The voice translation profile is applied to a

dial peer for use with a call leg. Alternatively,
a global inbound translation profile can be
defined with the command voip-incoming
translation-profile.
Example 8-30 shows the syntax for translation rules and

translation profiles, and Example 8-31 shows the usage
and application of translation profiles in IOS.
Example 8-30 The Command Syntax for Translation

Rules and Profiles
!
voice translation-rule numeric-tag
rule [1-100] /match-statement/ /modify-statement/
!
voice translation-profile word
translate {called | calling | redirect-target | red
!
Example 8-31 The Application of Translation Profiles

to Global Configuration or Dial Peers
!
voip-incoming translation-profile word
!
dial-peer voice tag voip
translation-profile outgoing word
translation-profile incoming word
!
Tip
Incoming translation profiles are applied when a dial peer is selected as an
inbound dial peer. Outbound translation profiles are applied when the dial peer
is selected as an outbound dial peer for a given call leg.
Translation rule match statements use regex that are

very similar to the regex and wildcards used with dial
peer matching commands (refer to Table 8-3). In
addition, voice translation rule match statements have
their own wildcards that serve various purposes. Table 8-
11 shows the wildcard statements specific to voice
translation rule match statements.
Table 8-11 Translation Rule Match Statement

Wildcards and Regex
Understanding Match and Modify Statements

As noted in Table 8-11, regex or digits wrapped in
parentheses are considered a set. A set is usually escaped
to avoid matching a literal ( or ) character. A set can be
used to store the matched characters between the
parentheses as a variable that can be used later in the
modify statement. The sets are then referenced using an
escaped number in the modify statement. For example,
the very first set in a match statement is referenced with
\1 in the modify statement, the next set is \2, and so on.
\0 has a very special purpose of matching everything in
the match statement; it is equivalent to the modify
statement ampersand wildcard character (&). Example
8-32 shows a few variations using sets. The command
test voice translation-rule can be used to test IOS
translation rules and view the logic.
Example 8-32 An Example Detailing How Sets and

Wildcards Work with Translation Rule Match and
Modify Statements
!
voice translation-rule 777
rule 1 /^111$222$333$444$555/ /\1\2/
rule 2 /^14085267209/ /+\0/
rule 3 /^4085267209/ /+1&/
rule 4 /^9$.*$/ /\1/
rule 5 /\+$.*$/ /\1/
rule 6 /.*$....$/ /\1/
!
Router# test voice translation-rule 777 1112223334445
Matched with rule 1

Original number: 111222333444555 Translated numbe
r: 222444
Matched with rule 2

Original number: 14085267209 Translated number: +14085
267209
Matched with rule 3

Original number: 4085267209 Translated number: +14085
267209

Matched with rule 4
Original number: 918005532447 Translated number: 180055
32447
Router# test voice translation-rule 777 +14085267209
Matched with rule 5

Original number: +14085267209 Translated number: 140852
67209
Matched with rule 6

Administrators use everything except rule 1 of the match

statement and modify statement examples in Example 8-
32 in everyday deployments. Note the following process
in Example 8-32:
Step 1. The first rule matches 111222333444555 and

specifically has brackets around 222 and 444,
which applies them as sets 1 and 2. These two
sets are then referenced as \1 and \2, which
change the number 2224444.
Step 2. The second rule matches 14085267209 and

adds a leading plus character (+). The \0 is
the wildcard for set 0, which references
everything in the match statement.
Step 3. The third rule accomplishes the same thing

but with a match of 4085267209. The modify
statement adds a +1 prefix and uses the
ampersand (&) wildcard to leverage
everything found in the match statement.
Step 4. The fourth rule matches anything with a

leading 9 and any other character designated
by the dot (.) and asterisk (*). This is then
grouped into set 1 and used in the
modification statement. Since the 9 was not
part of the set grouping, it is effectively
stripped from the number. (This is a very
common translation profile to apply in
CUBE.)
Step 5. The fifth statement matches a literal plus (+)

by escaping the character. If the plus were not
escaped, it would be treated as a regex plus.
The plus is then stripped by referencing set 1,
which matches anything else in the number
string with .*.
Step 6. The last statement illustrates how to strip a

given input to a specific length, starting with
the right-justified digits. In this case,
14085151111 becomes 1111 because the match
statement matches any character and then
assigns the last four digits of the numeric
string as set 1.
Keep in mind that translation rule match statements are

evaluated from the top down, like access control lists
(ACLs). When an applicable match statement is found on
a given rule, the hunting stops, and the modification
statement is applied. No further rules are examined. You
should order translation rule match statements so that
more exact match statements are given lower rule
numbers to ensure they appear higher in the list. The
more inclusive regex match statements should be at the
bottom of the list, by applying a larger rule number, to
avoid greedily matching numbers they should otherwise
not match and modify. To illustrate this, in Example 8-
33, rule 1 shows an all-inclusive dot star match (.*). This
is the regex equivalent of saying that anything goes. Rule
2 matches on 14085267209, but because the greedy
match on rule 1 literally matches any value provided to
the translation rule, IOS will never match rule 2.
Example 8-33 A Sample Translation Rule Illustrating
Greedy Matches Affecting the Ability to Match Rules
Further Down the List

rule 1 /.*/ /8675309/
rule 2 /^14085267209/ /+\0/
Matched with rule 1

9
Matched with rule 1

9
Router# test voice translation-rule 666 AAAA
Matched with rule 1

Original number: AAAA Translated number: 8675309
Blocking Calls with Translation Rules

As mentioned earlier in this chapter, translation rules
can be used to block numbers. These rules use the same
command syntax you are already familiar with, but the
modify statement is dropped, and the match statement is
prefixed with the reject statement. Example 8-34 shows
the syntax for blocking a call on CUBE using translation
rules. Notice that the translating profile is applied to the
dial peer by using the call-block translation-profile
incoming command, and the call-block disconnect-
cause incoming command specifies the type of block
reason signaled to the calling party.
Example 8-34 Command Syntax for Defining Call

Blocking Using Translation Rules and Profiles
!
voice translation-rule numeric-tag
rule 1 reject /match-statement/
!
voice translation-profile profile-name
translate calling numeric-tag
!
dial-peer voice dial-peer-tag voip
call-block translation-profile incoming profile-name
call-block disconnect-cause incoming { call-reject
!
Table 8-12 provides a mapping between the disconnect

reason, SIP Response header, and Q.850 cause code.
Table 8-12 The Mapping of Disconnect Causes to SIP

Responses and Q.850 Cause Codes
Note
voip-incoming translation-profile applies translations before the inbound dial
peer match is made, which may affect call block matching on the inbound dial
peer.
To test a translation rule for blocking calls, you can use

the same test command used in the previous examples.
Example 8-35 shows a block on the pattern 8675309 in
addition to the application of this block pattern to a dial
peer.
Example 8-35 A Sample Configuration and Verification

of a Blocked Number on an Inbound Dial Peer
!
rule 1 reject /8675309/
!
voice translation-profile CALLBLOCK
translate calling 164
!
call-block translation-profile incoming CALLBLOCK
call-block disconnect-cause incoming invalid-number
!
8675309 blocked on rule 1
Troubleshooting Voice Translations

When the test voice translation-rule command does
not suffice, you might need to perform live debugging
and examine the logic of debug voice translation. You
can run this command along with other commands, such
as debug ccsip messages and debug voip ccapi
inout. Example 8-36 shows a very simply translation on
an incoming SIP INVITE message that checks four
match rules and finds a match on the last rule. This rule
then modifies the called number in the SIP Request-URI
from 4444 to 1234.
Example 8-36 Debugging Output Showing the Logic

for Voice Translation Rules and Profiles
020464: Sep 21 17:42:31.023: //-1/xxxxxxxxxxxx/SIP/Ms

Received:
INVITE sip:4444@172.18.110.58:5060 SIP/2.0
020528: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE

020529: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE
020530: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE
020531: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE
020532: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE
020540: Sep 21 17:42:31.028: //-1/054D9FB28175/RXRULE
When non-numeric values are being used, translation

rule match statements lose their ability to match
effectively. This is very common in SIP, where the user
ID portion of a header can be an alphanumeric entry. For
such scenarios, a match and modification with voice
class SIP profiles should be leveraged. The next few
sections cover how to perform SIP header manipulation.
SIP Header Interworking

A SIP header has the following format:
Header: Value
The contents of Value in a SIP header can be almost

anything. The goal of a SIP header is to carry data and
provide the data in a consumable manner to the next-
hop application, which handles the parsing of the SIP
message. Many RFCs pertaining to SIP define required
and optional SIP headers; in addition, there are vendor-
proprietary headers and custom application headers.
From an SBC’s perspective, it is nearly impossible to
incorporate support for parsing, understanding, and
interpreting every possible SIP header in existence.
RFC 3261 details a small list of required headers for

every SIP request or SIP response. However, for most
SBCs, there is a list of additional supported headers that
are considered mandatory to handle SIP messages and
session establishment. All headers outside this list are
unsupported and may be dropped when creating
additional requests and responses during session
establishment. There is a problem here: Every SBC
vendor or service provider may have a slightly different
list of mandatory headers that need to be present for a
session to successfully complete with another device.
Sometimes specific headers need to be passed seamlessly

across an SBC, possibly without modification.
Alternatively, there may arise a situation in which a
specific header should not be sent across an SBC because
the inclusion of a specific header may cause the
upstream device to handle a session incorrectly,
terminate a call prematurely, or behave in some other
undesired fashion. This means the ability of an SBC to
interwork headers from many different device types is of
paramount importance.
Note
The Cisco document “Configurable Pass-Through of SIP INVITE Parameters”
details the supported mandatory and supported non-mandatory CUBE headers
.
Table 8-13 details many of the most common SIP

headers that need to be interworked through CUBE.
These headers are so important that each one has its own
CLI command.
Table 8-13 Common SIP Headers
Tip
The command header-passing is often mistakenly configured on CUBE,
although this command has no bearing on any SIP–SIP header interworking.
This command is used to allow the passing of SIP headers to IOS-based TCL
applications, which otherwise do not have access to such information.
In addition to the explicit CLI commands for the specific

headers listed in Table 8-13, CUBE enables you to
configure passthrough of any unsupported SIP header, as
shown in Example 8-37. If a more refined approach is
desired, rather than passing every unsupported header,
you can define a list of unsupported headers that can be
passed by using the commands shown in Example 8-38.
Example 8-37 Passthrough of Unsupported SIP

Headers
voice service voip

sip
pass-thru headers unsupp
Example 8-38 Defined List of Unsupported Headers
voice service voip

sip
pass-thru headers 1
!
voice class sip-hdr-passthrulist 1
passthru-hdr MyCustomHeader
passthru-hdr-unsupp
Even more granularity is possible through the use of SIP

profiles and SIP copylists, which allow you to add custom
headers and manipulate not only SIP headers but
anything in a SIP message. The next section dives into
this topic.
SIP Normalization
With SIP normalization, a user agent manipulates SIP
headers, header data, or SDP attributes. The need to
modify portions of a SIP message may arise in a number
of different scenarios, such as when formatting header
fields to the preference of upstream devices, adding
proprietary data to a SIP message, or modifying received
SIP messages to enable smooth processing.
A SIP message, including the SIP headers and message
bodies (for example, SDP), contains plaintext data. As a
result, with SIP profiles you use regex to match portions
of a SIP message and modify the matched portions to
meet your needs. This process is similar to the
translation rules and profiles discussed earlier in this
chapter. The big difference is that a SIP profile is not
constrained to just a phone number. For example, a
message received from a device might contain a SIP
header that is malformed or incorrectly formatted, and
processing such a message could lead to unexpected
behavior. SIP normalization is an effective tool for
modifying such messages and ensuring that they are
correctly formatted before processing.
SIP normalization is usually broken down into two main

categories: preprocessing normalization and
postprocessing normalization. Figure 8-9 displays both
forms of SIP normalization and details the flow of
operations for each. With preprocessing normalization,
the following events occur:
Figure 8-9 Pre- and Postprocessing SIP Normalization
Step 1. The SIP message is received by the SBC as an

IP packet.
Step 2. The SIP message is extracted from the IP

packet and passed on to the SIP application.
Step 3. The SIP application performs the required

preprocessing normalization, based on locally
configured policies.
Step 4. The normalized message is passed on to the

SIP stack, and the message is then
interpreted for processing.
Step 5. Based on the results of processing, further

action is performed. This could include
immediately sending a response, passing the
message to the peer call leg, or formulating a
new request.
With postprocessing normalization, the following events

occur:
Step 1. The SIP stack performs local logic, such as

forming a new request or handling a message
from the peer call leg.
Step 2. New SIP message data is created, and

existing data from the peer leg may be added
to the newly created SIP message. This
message is then passed to the SIP application.
Step 3. The SIP application performs the required

postprocessing normalization, based on
locally configured policies.
Step 4. The normalized SIP message is encapsulated

for transport over the LAN as an IP packet.
Step 5. The IP packet containing the SIP message is
put on the wire and sent to the next hop.
SIP Profile Configuration

You configure a SIP profile by defining voice-class sip
profile profile-id, where profile-id is a numeric
identifier for the configured SIP profile. You can add
statements to a SIP profile, where each statement
consists of a request or a numbered response, the
specific message being modified, a header type, and the
actual header name. With a SIP profile, you can modify,
add, or remove SIP message data. Example 8-39 and
Table 8-14 show the command syntax used to configure a
SIP profile for SIP header or SDP modification.
Example 8-39 SIP Profile Syntax Used for Header

Modification
!
voice-class sip profile profile-id
{request | response} message {sip-header | sdp-heade
!
Table 8-14 SIP Profile Modification Syntax
You can also use SIP profiles to add proprietary headers

to SIP messages. You do this by using the ADD
statement in a SIP profile. The ability to add custom
headers was introduced in IOS 15.5(2)T and IOS XE
3.13S. Example 8-40 and Table 8-15 show the command
syntax for adding a SIP header or an SDP value to a SIP
message.
Example 8-40 SIP Profile Syntax Used for Adding

Headers
!
!
Table 8-15 SIP Profile Addition Syntax
You can also use a SIP profile to remove a value from a

SIP message. This is a very powerful way of dropping
headers that may be causing interworking issues.
Example 8-41 and Table 8-16 detail the command syntax
for header removal.
Example 8-41 SIP Profile Syntax Used for Removing

Headers
!
!
Table 8-16 SIP Profile Removal Syntax
Once a SIP profile has been defined, it can be applied to

the global configuration under voice service voip and
the SIP subsection, which allows for the profile to be run
against any SIP message, regardless of the dial peers
used. Global application of SIP profiles is also useful
when you need to manipulate SIP messages that do not
use dial peers (for example, SIP REGISTER messages,
OOD OPTIONS messages). SIP profiles can also be
applied to voice class tenant configurations or dial peers
for more granular control of SIP messages on a per-call
basis.
Example 8-42 shows the different levels of profile

application. One thing to keep in mind is the order of
operations for SIP profiles and that SIP profiles defined
on a dial peer/tenant take precedence over a global SIP
profile when they are modifying the same item.
Example 8-42 Different SIP Profile Application Levels
! Global Application
!
voice service voip
sip
sip-profiles 1
!
! Tenant Application
!
voice class tenant 1
sip-profiles 1
! Dial-peer Application
!
voice-class sip profiles 1
Outbound SIP Profiles

Outbound SIP profiles are the most common type of SIP
profile used in CUBE deployments. These SIP profiles
follow the postprocessing normalization process defined
earlier in this chapter (refer to Figure 8-9). This
modification occurs after call routing decisions are made
and before the SIP message is placed on the wire and
sent to the next hop as an IP packet. This modification
can be applied to both SIP requests and responses as well
as SIP headers and an SDP body.
A common use case of outbound SIP profiles is for

adding or modifying a SIP Diversion header sent in an
egress SIP INVITE message for authentication by an
upstream device, such as a proxy or an ITSP. The SIP
profile in this use case would be added to the outbound
dial peer so that CUBE can modify the egress INVITE
message before actually sending the message to the user
agent that requires the header. Example 8-43 shows the
configuration for the addition of a Diversion header. This
method can be used when no Diversion header is
received on the other call leg. Example 8-44 shows the
modification performed by CUBE that takes place in this
scenario.
Example 8-43 Adding a Diversion Header to an Egress

INVITE Message
voice class sip-profiles 777

request INVITE sip-header Diversion add “Diversion: <si
p:1234@example.com>"
!
codec g711ulaw
Example 8-44 shows debugging information for the

configuration shown in Example 8-43. Notice the
outbound dial peer match 777. This is where the
outbound SIP profile is applied. Thus the addition of the
new header occurs when the SIP profile is executed on
the SIP INVITE request. The new SIP message
containing the added header is then put on the wire and
sent on the network.
Example 8-44 Debugging for Adding a Diversion

Header
May 19 21:05:57.762: //125/6B6A2E000000/CCAPI/ccCallS
Guid=6B6A2E00-0001-0000-0000-001A306E12AC, Outgoin
May 19 21:05:57.762: //-1/xxxxxxxxxxxx/SIP/Info/info/

May 19 21:05:57.764: //126/6B6A2E000000/SIP/Msg/ccsip

Sent:
INVITE sip:7777@172.18.110.65:5060 SIP/2.0
Diversion: <sip:1234@example.com>
The previous two examples detail a situation in which a

Diversion header is not present on the ingress SIP
messaging. If a Diversion header is received on the
ingress call leg, CUBE passes the Diversion header
through to the outbound call leg. Example 8-45 shows
how to modify a Diversion header that was received and
passed through CUBE. Example 8-46 shows the received
Diversion header field, CUBE SIP profile modification,
and egress SIP message after modification. A good rule
to remember is that a modification always occurs on a
header that is present either by default or by being
passed from one call leg to another.
Example 8-45 Modifying a Diversion Header in an

Egress INVITE Message

request INVITE sip-header Diversion modify “sip:(.*)>”
“sip:1234@example.com>"
!
codec g711ulaw
Example 8-46 shows the debugging for the configuration

in Example 8-45. Notice that the outbound dial peer
match occurs on dial peer 888, where the outbound SIP
profile is applied. Because you receive an inbound SIP
request with a Diversion header, this is going to be
passed through CUBE and included in the outbound SIP
request. The SIP profile is then able to modify that
header because it is present in the outbound request. The
final SIP message containing the modification is then put
on the wire and sent across the network.
Example 8-46 Debugging Information for Modifying a

Diversion Header
Sent:
INVITE sip:7777@172.18.110.48:5060 SIP/2.0
Diversion: <sip:1024@172.18.110.48>;privacy=off;reason=un
conditional;screen=yes
May 19 21:13:27.416: //147/77A2BB000000/CCAPI/ccCallS

Guid=77A2BB00-0001-0000-0000-001D306E12AC, Outgoin

Sent:
INVITE sip:7777@172.18.110.65:5060 SIP/2.0
Diversion: <sip:1234@example.com>;privacy=off;reason=unco
nditional;screen=yes
A common misconception is that an outbound SIP
profile can only be applied to an outbound dial peer. This
is not the case. The term outbound SIP profile references
the direction of SIP messaging that needs modification.
For example, you might need to modify an outbound SIP
message on an inbound call leg. You achieve this by
applying the defined SIP profile to an inbound dial peer
that is anchored to the call leg where you need to modify
outbound SIP messaging.
An example of this use case would be changing a 100

Trying message sent from CUBE to a 100 Giving a Try
message. The 100 Trying response is always sent after
CUBE matches an inbound dial peer, and because this is
an egress SIP message—from CUBE to the previous hop
—this is where you would apply an outbound SIP profile.
Example 8-47 shows the configuration needed to
perform outbound SIP message modification on an
inbound dial peer, and Example 8-48 shows the
outbound SIP 100 Provisional response and the
outbound SIP profile modification applied to this egress
message. All of this is done by applying an outbound SIP
profile to an inbound dial peer.
Example 8-47 Outbound SIP Profile on an Inbound

Dial Peer

response 100 sip-header SIP-StatusLine modify “100 Tryin
g” “100 Giving a Try"
!
description INBOUND DIAL-PEER
dtmf-relay rtp-nte
codec g711ulaw
Example 8-48 shows the debugging information for the

configuration in Example 8-47. Notice the inbound dial
peer match 222. This is where the outbound SIP profile
is defined. CUBE attempts to send a 100 Trying response
to the previous hop in order to let that UAC know that it
is currently processing the message. Because you have an
outbound SIP profile, it is first executed against the 100
Trying message. The message matches the statement and
changes the value of the status line to 100 Giving a Try.
The message is then put on the wire and sent across the
network.
Example 8-48 Debugging Information from an

Outbound SIP Profile on an Inbound Dial Peer
May 19 21:00:49.005: //-1/B33C85800000/CCAPI/cc_api_c

Incoming Dial-peer=222, Progress Indication=NULL(0

May 19 21:00:49.005: //109/B33C85800000/SIP/Info/info
May 19 21:00:49.005: //109/B33C85800000/SIP/Info/info
Sent:
SIP/2.0 100 Giving a Try
Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK3ce

From: <sip:1024@172.18.110.48>;tag=23232~1992ce86-77a
To: <sip:7777@172.18.110.58>
Call-ID: b33c8580-b0019080-a4-306e12ac@172.18.110.48
CSeq: 101 INVITE
Content-Length: 0
Inbound SIP Profiles

Like their outbound counterparts, inbound SIP profiles
are used to manipulate aspects of a SIP message,
including SIP headers and the SDP body. The syntax of
an inbound SIP profile is exactly the same as that of an
outbound SIP profile. The main differences between
inbound and outbound SIP profiles are in their use and
application.
Inbound SIP profiles modify ingress messages on CUBE

globally or for each dial peer. Just as with outbound SIP
profiles, you can apply an inbound SIP profile to an
inbound or outbound dial peer. Inbound SIP profiles
allow you to modify a SIP message before CUBE
processes the message. This gives you great flexibility in
modifying SIP messages and SDP bodies of inbound
traffic before the traffic is actually processed by CUBE.
Inbound SIP profile support must be enabled globally

before the feature can be used on a SIP message (see
Example 8-49).
Example 8-49 Enabling Inbound SIP Profile Support
voice service voip

sip
sip-profiles inbound
When inbound SIP profile support is enabled, you can

start the process of defining a SIP profile. When the
definition of the desired SIP profile is complete, you
apply it to either global configuration or dial peers by
postfixing the keyword inbound to the normal sip-
profile command, as shown in Example 8-50.
Example 8-50 Applying an Inbound SIP Profile
! Global Application
!
voice service voip
sip
sip-profiles 555 inbound
! Dial-peer Application
!
voice-class sip profiles 555 inbound
Examples 8-51 and 8-52 show an inbound SIP profile

being used to convert a received Date header in a SIP
INVITE message from EST to GMT. RFC 3261 explicitly
states that Date headers must be in the GMT format, and
the reception of a nonstandard Date header would cause
this call to fail. You can use an inbound SIP profile to
perform the desired modification on the Date header
before the CUBE application processes the message and,
as a result, avoid undesired session termination.
Example 8-51 Configuring an Inbound SIP Profile
voice service voip

sip
sip-profiles inbound
!
request ANY sip-header Date modify “EST” “GMT"
!
voice-class sip profiles 111 inbound
codec g711ulaw
Example 8-52 shows the debugging information for the

configuration in Example 8-51. Here you can see a
received INVITE message with a Date header containing
the problematic EST value. An inbound dial peer match
occurs, and the inbound SIP profile defined on that dial
peer is triggered. As a result, the EST is changed to GMT.
This is all done before the SIP message is parsed by the
SIP stack, thus circumventing the failure that may occur
without the manual change to this header.
Example 8-52 Debugging Information for an Inbound

SIP Profile
Received:
INVITE sip:1234@172.18.110.58:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.110.65:5060;branch=z9hG4bK-16
From: <sip:7777@172.18.110.65:5060>;tag=1
To: sut <sip:1234@172.18.110.58:5060>
Call-ID: 1-16095@172.18.110.65
CSeq: 1 INVITE
Contact: sip:7777@172.18.110.65:5060
Max-Forwards: 70
Supported: timer
Date: Fri, 25 May 2018 21:01:13 EST
Session-Refresh: 1800;refresher=uac
Subject: Performance Test
Content-Length: 130
v=0
o=user1 53655765 2353687637 IN IP4 172.18.110.65
s=-
c=IN IP4 172.18.110.65
t=0 0
a=maxptime:20
May 25 21:07:12.568: //-1/xxxxxxxxxxxx/SIP/Info/verbo

SIP Copylist
A SIP copylist is a special type of SIP profile that allows
CUBE to copy contents from a SIP header as a variable
that is stored in memory for later use. The value of this
variable can then be used in an outbound SIP profile to
manipulate SIP message data.
A SIP copylist can be used to expand on the Diversion

header example previously demonstrated in the
discussion of outbound SIP profiles. The application of a
copylist in this example allows the modification
statements to use a variable rather than statically defined
data. Subsequently, this variable acts as a placeholder for
a large number of potential patterns. Example 8-53
shows a sample configuration in which the copylist
copies the user in the From header URI of the ingress
INVITE message. CUBE then stores that value as
variable u01. Then, by referencing this variable in the
outbound SIP profile statement, the outbound SIP
profile can be made to operate with potentially limitless
patterns, as long as the patterns follow a specific syntax
that allows the regex to properly match. When the
outbound SIP profile executes its logic, it inserts the data
from the variable u01. Example 8-54 displays the entire
process and debugging for the full copylist scenario.
Example 8-53 SIP Copylist Example for a Diversion
Header
!
voice class sip-copylist 2
sip-header From
!
voice-class sip copy-list 2
!
request INVITE peer-header sip From copy “<sip:(.*)@
request INVITE sip-header Diversion modify “sip:(.*)
!
!
Example 8-54 shows the debugging information from

CUBE for the configuration shown in Example 8-53.
Here you can see a received INVITE with the From
header containing user 1027. An inbound dial peer
match occurs, and the SIP copylist is applied. You can
see that the SIP copylist executes and successfully
matches the value 1027, as you would expect. This value
is then stored as variable u01 for later use. Outbound
dial peer matching occurs, and the SIP profile defined on
that dial peer is executed. The value from the u01
variable is then substituted in the SIP profile, which
means 1027 is now placed in the Diversion header.
Finally, you see the outbound SIP INVITE and modified
Diversion header sent to the next hop, and the header
contains the 1027 value copied from the inbound INVITE
message's From header.
Example 8-54 Debugging Information for the SIP

Copylist for a Diversion Header
Received:
INVITE sip:7777@172.18.110.58:5060 SIP/2.0
Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK3e8
From: <sip:1027@172.18.110.48>;tag=23337~1992ce86-77a
May 19 21:37:58.510: //-1/E46B84800000/CCAPI/cc_api_c

May 19 21:37:58.512: //201/E46B84800000/CCAPI/ccCallS

Guid=E46B8480-0001-0000-0000-0020306E12AC, Outgoin

May 19 21:37:58.513: //202/E46B84800000/SIP/Info/info
May 19 21:37:58.514: //202/E46B84800000/SIP/Msg/ccsip

Sent:
INVITE sip:7777@172.18.110.65:5060 SIP/2.0
Diversion: <sip:1027@example.com>;privacy=off;reason=
Common SIP Profiles

You might need to modify the URI of a SIP header to
meet specific formatting requirements of the next hop.
Example 8-55 shows how to modify the user portion, the
host portion, or the entire URI. This modification can be
used for any SIP header and is not limited to the Contact
header.
Example 8-55 Modifying the User, Host, or Entire URI

in a SIP Header
! User
!
request ANY sip-header Contact modify “sip:(.*)@” “s
!
! Host
!
request ANY sip-header Contact modify “@10.10.10.10>
!
! Modify the full URI, Both User and Host
!
request ANY sip-header Contact modify “sip:(.*)>” “s
!
A situation may arise in which you need to modify the

received caller name in a SIP header. Normally this
would happen if a caller ID (CLID) name such as
Anonymous or Unknown is being received in a SIP
message. The caller ID name is displayed in a SIP
message as a quoted string between the specific header
and the SIP URI, as shown here:
From: “MY CLID NAME” <sip:1234@10.10.10.10>
Example 8-56 shows a way to match everything in the

quotes within the content of the From header. The
modification statement produces TEST CLID as the
output in the From header content.
Example 8-56 Modifying the Caller ID Name

request INVITE sip-header From modify “\".*\"” “\"TE
Tip
The command clid strip can be defined under a dial peer to remove the caller
ID name if removal rather than modification is desired.
If you do not want to advertise update capabilities on
CUBE for a specific call leg, you can use the code in
Example 8-57 to remove the UPDATE extension from
the Allow header. The result of this SIP profile is that the
SIP messages sent do not contain the UPDATE entry in
the Allow header. Thus, a device receiving the message
should not send an UPDATE message to this SBC for any
reason.
Example 8-57 Removing UPDATE Advertisement on

CUBE

request ANY sip-header Allow-Header modify “, UPDATE
response ANY sip-header Allow-Header modify “, UPDAT
You might experience a situation in which sending one of

the hold methods defined in the hold/resume section
produces issues with a remote device. Example 8-58
defines different methods of modifying the audio media
attributes for a=sendonly or a=inactive and replacing
them with a=sendrecv. The use of a pipe character (|) is
the regex OR method and essentially presents a list of
alternatives. Thus, the statement is looking for either
audio direction attribute (a=) in parentheses, and if
either is present, the modification takes place.
In addition, Example 8-58 details how to change the

connection address that is all zeros, 0.0.0.0, to a real IP
address. This can be defined for both requests and
responses, depending on the direction of messaging that
needs to be modified. You could, for example, replace
10.10.10.10 with the desired IP address.
Example 8-58 Hold/Resume or Audio Interop with a

Provider
request ANY sdp-header Audio-Attribute modify “(a=se
request ANY sdp-header Audio-Connection-Info modify
response ANY sdp-header Audio-Attribute modify “(a=s
response ANY sdp-header Audio-Connection-Info modify
Example 8-59 shows how to insert the option

user=phone into any To header in a SIP request or
response. This example also details the concept of a set.
Each set in regex is a grouping of data within a pair of
parentheses. In Example 8-59, the SIP profile is grabbing
everything between the < and > characters and storing it
as set 1. The \1 is a back reference that allows IOS or IOS
XE to call the data from the set 1 that was previous
stored. Up to nine unique sets can be used within a SIP
profile. The data in a set correlates with the order in
which the data appears in a match statement.
Example 8-59 Modifying a To Header with Sets
voice class sip-profile 400

request ANY sip-header To modify “<(.*)>” “<\1;user=
response ANY sip-header To modify “<(.*)>” “<\1;user
Later versions of CUBE allow a user to define a rule tag

on a SIP profile. This capability was added to allow for
the definite ordering of SIP profile statements and to
facilitate quicker modification of statements. Without a
rule tag, you must delete the statement and then add it
back; otherwise, the statement is duplicated and placed
at the end of the current list of statements. Example 8-60
shows a simple SIP profile with rule tags. This example
also shows the modification of a SIP header into its
shorthand form.
Example 8-60 A SIP Profile with Three Rules

rule 1 request INVITE sip-header From modify “From:”
rule 2 request INVITE sip-header To modify “To:” “t:
rule 3 request INVITE sip-header Contact modify “Con
The commands voice sip sip-profiles downgrade

and voice sip sip-profiles upgrade can be used to
either remove or add the rule statements from previously
configured SIP profiles. Example 8-61 shows the use of
these commands.
Example 8-61 Dynamic Rule Tag
CUBE# voice sip sip-profiles upgrade

CUBE# show run | section 1234
rule 1 request INVITE sip-header From modify “From:”
rule 2 request INVITE sip-header To modify “To:” “t:
rule 3 request INVITE sip-header Contact modify “Con
CUBE# voice sip sip-profiles downgrade

CUBE# show run | section 1234
request INVITE sip-header From modify “From:” “f:"
request INVITE sip-header To modify “To:” “t:"
request INVITE sip-header Contact modify “Contact:”
Tip
It is important to note that if rule tags are being used and you downgrade IOS
to a version where rules tags are not present, the SIP profile will be lost. The
rule tag command was introduced in IOS 15.5(2)T and IOS XE 3.15S. It is
recommended to issue the voice sip sip-profiles downgrade command
before downgrading software versions.
Troubleshooting SIP Profiles

SIP profiles allow for granular control over SIP
messages, but improper configuration can lead to
incorrect formatting of SIP messages, SIP headers, or
SDP. Always refer to the applicable RFCs when
manipulating any SIP messages to avoid violating the
standard formatting of a header and causing undesired
call failures. If a modified SIP message is no longer RFC
compliant, an upstream device may respond with a 400
Bad Request or another 4xx client-level error indicating
that the modification is not accepted.
Use the following debug commands to triage and

troubleshoot SIP profile configuration and configuration
issues:

debug ccsip info
debug ccsip feature sip-profile
debug voip ccapi inout
debug voip uri
You can also leverage the Cisco SIP-Profile Test tool (see
) to test SIP profiles without the need to make any
changes to a device or perform test calls. As shown in
Figure 8-10, to use this tool, you input the SIP message
you would like to modify, along with the proposed SIP
profile. The tool then runs the SIP profile against the SIP
message provided and displays the output before and
after modification, highlighting the items that were
modified or added.
Figure 8-10 The SIP-Profile Test Tool
REFERENCES
“Cisco Unified Border Element Configuration Guide,”
xml/ios/voice/cube/configuration/cube-book.html
“Configurable Pass-through of SIP INVITE

Parameters,” https://www.cisco.com/en/US/docs/ios-
xml/ios/voice/cube_sip/configuration/15-0m/voi-
conf-pass-thro.html
“Dial Peer Configuration Guide,”

xml/ios/voice/dialpeer/configuration/15-mt/vd-15-
mt-book/vd-dp-overview.html
“In Depth Explanation of Cisco IOS and IOS-XE Call

Routing,”
https://www.cisco.com/c/en/us/support/docs/voice/i
p-telephony-voice-over-ip-voip/211306-In-Depth-
Explanation-of-Cisco-IOS-and-IO.html

Press, 2018.
RFC 2782, “A DNS RR for specifying the location of

services (DNS SRV),”

https://www.ietf.org/rfc/rfc3261.txt



MEMORY
chapter and complete the tables and lists from memory.
to check your work.
DEFINE KEY TERMS

call leg
call flow
back-to-back user agent (B2BUA)
inbound dial peer
outbound dial peer
session target
Chapter 9. CUBE Interworking
Features
• SIP–SIP Interworking: This section details call

setup features and interworking involved with
establishing SIP-to-SIP sessions through CUBE.
• Mid-call Signaling: This section describes the

mid-call signaling that occurs and how CUBE can
perform interworking actions to modify or block
specific signaling exchanges observed on a given
call leg.
• SIP Authentication with CUBE: This section

covers the different ways CUBE can authenticate
incoming SIP sessions in addition to responding to
authentication requests from other SIP user agents.
• Media Interworking: This section explores the

methods CUBE uses to perform interworking to
multimedia streams established through CUBE.

exam topics:

conversation
• 1.1.b PRACK
• 1.1.d Session timers

• 1.1.e UPDATE
• 1.2.a DTMF
• 1.2.b Call set up and tear down

dial plan elements
• 3.1.a DTMF
• 3.1.c Codec preference list

• 3.2.a DTMF
• 3.2.c Codec preference list
As a session border controller (SBC), CUBE is often

tasked with interworking and establishing sessions
between different real-time multimedia networks. These
interworking tasks range from normalizing signaling
exchanges, messages, responses, and event sequencing to
media encoding interworking for audio, video, and
DTMF. The need for CUBE interworking features often
arises due to vendor interoperability. Although SIP is an
open standard defined by numerous Requests for
Comments (RFCs), not all vendors support the full range
of SIP RFCs. In addition, some vendor equipment and
endpoints expect very specific signaling exchanges to
occur, and a slight deviation from that baseline signaling
exchange could cause call failures or media issues. As a
result of these needs, CUBE Enterprise contains a variety
of interoperability features that enable Unified CM
administrators to exert control over sessions established
through CUBE to perform the required interoperability
actions for both signaling and the media. This chapter
covers the most common interworking features used
with CUBE deployed in Unified Collaboration (UC)
environments around the world. This chapter also
provides configuration examples and debugging samples
to further illustrate the topic.


1. Which command is required to instruct CUBE to

always send early offer on the outbound call leg,
regardless of the inbound call leg’s offer type?
a. delayed-offer disable
b. voice-class sip eo
c. early-offer forced
d. pass-thru content sdp
2. Which SIP provisional responses indicate that in-

band audio, such as ringback, will be streamed to
CUBE through an audio channel? (Choose two.)
a. 183 Session in Progress without SDP

b. 183 Session in Progress with SDP
c. 180 Ringing without SDP
d. 180 Ringing with SDP
3. Which SDP parameters can be used by a SIP user

agent in a re-INVITE message to signal a call hold?
(Choose three.)
a. a=sendrecv
b. a=sendonly
c. a=inactive
d. c=IN IP4 0.0.0.0
e. a=rtpmap:0 PCMU/8000
4. Which SIP header field is referenced by CUBE

attempting to interwork a SIP REFER when
configured for REFER consumption?
a. Referred-by
b. To
c. Request-uri
d. Refer-to
5. Which transfer type in Unified CM allows an IP

phone user to open a media channel with the transfer
target first and have a conversation before completing
the transfer?
a. Blind transfer
b. Unattended transfer
c. Consult transfer
d. Refer transfer
6. What perquisite exists before an UPDATE message

with SDP can be sent to change media parameters on
a call that has not yet been answered with a 200 OK +
SDP?
a. None. This is impossible.
b. 183 Session in Progress must be present.
c. A PRACK handshake must be completed

successfully.
d. Early offer must be enabled on CUBE.
7. By default, when CUBE receives a SIP packet from an

untrusted source, what action is taken?
a. CUBE sends a 403 Forbidden.
b. CUBE trusts all IP addresses and routes the call.
c. CUBE drops the packet.
d. CUBE sends a 503 Service Unavailable.
8. Which types of addresses can be configured on CUBE

by the IP trusted list feature? (Choose two.)
a. IPv4
b. IPv6
c. Domain names
d. Phone numbers
9. What is the default codec for a SIP VoIP dial peer?
a. g729br8
b. g729r8
c. g711ulaw
d. g711alaw
10. Which command should be used to disable video

calls on CUBE?
a. no video codec
b. audio forced
c. codec g711ulaw
d. no vad
11. When configuring DTMF relay interworking on

CUBE, which command allows CUBE to negotiate
different RTP payload types, such as reception of
RTP-NTE PT 100 and sending of RTP-NTE PT 101?
a. asymmetric payload dtmf
b. rtp payload-type nte 101
c. pass-thru content sdp
d. early-offer forced
FOUNDATION TOPICS
SIP–SIP INTERWORKING
The most common CUBE deployment uses SIP as the
signaling protocol to connect different networks. In this
type of scenario, CUBE acts as a back-to-back user agent
(B2BUA). As a B2BUA, CUBE has collocated user agent
client (UAC) and user agent server (UAS) functionality.
This is very useful for SIP interworking as it allows the
SBC to receive and send SIP messages from either
perspective during a session. The B2BUA can maintain
two separate SIP dialogs and interwork any events that
occur on one dialog with the participant of the other
dialog and vice versa.
The following sections cover the many different

interworking options available for SIP–SIP SBCs.
Early Offer and Delayed Offer Interworking

Chapter 2, “VoIP Protocols: SIP and H.323,” discusses
early offer and delayed offer. As you learned there, the
inclusion of media parameters and SDP within a UAC’s
initial INVITE message determines whether the call is
early offer. A call is considered early offer when the
INVITE message sent from the UAC contains SDP, and
the UAS usually replies with a response that contains an
answer. In most scenarios, this answer is in the UAS’s
200 OK response. In contrast, with delayed offer, the
UAS’s 200 OK contains the SDP offer, and the ACK from
the UAC contains the answer SDP. Most Unified CM
devices support either type of offer and can generate an
answer accordingly. However, some services require
early offer support in order to cut through service
messages and ringback tones toward the calling party. In
addition, some devices only signal delayed offer.
As a result of these varying requirements, CUBE must be

able to interwork delayed offer and early offer during
session establishment so that the offer/answer is
completed properly on all legs of a call. Normally, when
sending an offer, CUBE mirrors the type of offer received
on the ingress call leg. That is, if CUBE receives an early
offer INVITE message, it sends an early offer INVITE
message to the peer call leg. Similarly, if CUBE receives a
delayed offer INVITE message, it sends a delayed offer
INVITE message to the peer call leg. For scenarios where
early offer is required on the outbound call leg and
delayed offer is required on the inbound call leg, CUBE’s
default behavior can be modified to ensure that early
offer is always sent on the outbound call leg. Example 9-1
shows how to modify this behavior on CUBE in order to
always send early offer.
Tip
CUBE cannot send delayed offer on an outbound call leg if early offer is
received on the inbound call leg. Early offer is always sent in this scenario.
Example 9-1 Forcing Early Offer Globally
! Global Configuration
voice service voip
sip
early-offer forced
! or
! Per Dial-peer
voice-class sip early-offer forced
Note
Examples in this chapter include both global configuration and dial peer–
specific configuration to show both CLI syntax. As a refresher, remember the
order of operations for voice configurations in IOS. The configuration found on
the inbound and outbound dial peer used during a session always supersede
any other configuration. If no dial peer–specific configuration exists, any voice
class tenant configuration applied to an inbound or outbound dial peer used
during a session is used. Finally, if no dial peer–specific or voice class tenant
configuration exist, the global configuration in the voice service voip or sip-ua
commands is leveraged.
Reliable Handling and Interworking of Provisional

Responses
A provisional response acknowledgement, better known
as a PRACK, is a SIP request used to reliably confirm the
receipt of a provisional 1xx-level response. PRACK is
defined in RFC 3262 as a way to mirror the reliability
seen with INVITE, 200 OK, and ACK. Some Internet
telephony service providers (ITSPs) and other devices
require a PRACK exchange before cutting through
ringback or service messages. In addition, some SIP
RFCs indicate that specific signaling exchanges cannot
be completed unless a reliable message exchange
involving PRACK has occurred. This chapter details one
such scenario.
Take, for example, the scenario outlined in Figure 9-1, in

which a UAC has sent an early offer INVITE to an
upstream UAS, and there are many different network
hops in between. This UAS sends an 18x message with
SDP to the UAC, with the intent that it will be sending
media to the UAC. Due to some unforeseen
circumstances, the 18x message is dropped in transit
across one of the network hops and does not make it to
the UAC. The UAS does not know that this was dropped
and begins sending packets to the UAC. From the
perspective of the UAC, which did not receive the 18x
message, these packets may be dropped as they are not
part of the SIP current dialog. Had the 18x message been
sent with reliability in mind, the UAS would know for
sure if the 18x was received and processed by the UAC.
Figure 9-1 Unreliable Provisional Response Across
Different Network Hops
A UAC advertises the ability to support PRACK by

including the tag 100rel in the Supported header of a SIP
INVITE message (see Example 9-2). RFC 3262 dictates
that the only SIP request type that can advertise support
for PRACK is a SIP INVITE message. In addition, the use
of advertising support for PRACK in a re-INVITE
message is not often seen because mid-call re-INVITE
messages rarely have provisional responses, which would
require the use of reliability. Finally, in addition to
having a Supported header, a UAC may also advertise
PRACK support and necessity by sending the 100rel tag
in the Require header.
Example 9-2 Sample INVITE Message with PRACK

Support
INVITE sip:7777@172.18.110.58:5060 SIP/2.0

Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK3a3
From: <sip:1024@172.18.110.48>;tag=22968~1992ce86-77a
To: <sip:7777@172.18.110.58>
Call-ID: 82535500-b00171fb-80-306e12ac@172.18.110.48
Min-SE: 1800
CSeq: 101 INVITE
Expires: 180
Session-ID: 1aaee55200105000a0000c75bd110ca4;remote=0
Max-Forwards: 69
Content-Length: 0
Because this UAC has advertised the ability to support

PRACK, the UAS receiving this request can send a
provisional response reliably if it wants to. The reception
of a Supported header with 100rel does not require the
UAS to send a response reliably. These items are only
informing the UAS that it can send PRACK if it deems it
necessary. In the same vein, a UAS cannot request a
reliable response if the UAC has not advertised support
for PRACK in the INVITE message. The UAC instead
may send a 421 Extension Required response to the UAC,
indicating that the UAS expects the UAC to support
PRACK.
If the UAS wants to send a provisional response reliably,

it must include the 100rel tag within the Require SIP
header of the provisional response. Including this header
and tag requires a PRACK from the UAC, and failure to
return a PRACK indicates that the provisional response
must not have been handled properly by the UAC. The
UAS retransmits the provisional response to the UAC
and requests PRACK to confirm reliable reception of the
retransmission. If no PRACK is received for the
retransmitted response, the retransmission may occur a
few more times, as per the applications logic or
administrative configuration. After all retries of the
provisional are exhausted without a PRACK being
received by the UAS, the UAS terminates the call because
it does not believe the UAC has handed the provisional
response properly. The message also contains an RSeq
header with a numeric value for later use by the PRACK
message. Example 9-3 details a 180 Ringing message
sent from the UAS, requesting a reliable confirmation by
the UAC.
Tip
PRACK cannot be sent for the 100 Trying response. All other numbered
responses 101 through 199 can be sent reliably.
Example 9-3 A 180 Ringing Response Expecting

PRACK
SIP/2.0 180 Ringing

From: <sip:1024@172.18.110.48>;tag=22968~1992ce86-77a
To: <sip:7777@172.18.110.58>;tag=512A088-1C36
Call-ID: 82535500-b00171fb-80-306e12ac@172.18.110.48
CSeq: 101 INVITE
Require: 100rel
RSeq: 3322
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDA

Content-Length: 0
Upon receiving a provisional response with a Require

100rel header, the UAC must respond with a PRACK to
inform the UAS of that it received the message. The
PRACK message includes the RAck header, which
contains the value from the RSeq header of the message,
requiring reliability in addition to the method that is
copied from the CSeq of that same response being
acknowledged. Example 9-4 shows the PRACK sent in
response to Example 9-3.
Example 9-4 Sample PRACK for the 180 Ringing

Response
PRACK sip:7777@172.18.110.58:5060;transport=tcp SIP/2

From: <sip:1024@172.18.110.48>;tag=22968~1992ce86-77a
To: <sip:7777@172.18.110.58>;tag=512A088-1C36
Call-ID: 82535500-b00171fb-80-306e12ac@172.18.110.48
CSeq: 102 PRACK

RAck: 3322 101 INVITE
Max-Forwards: 70
Content-Length: 0
Upon receiving the PRACK, the UAS sends a 200 OK

with the CSeq of the PRACK to confirm receipt. At this
point, the PRACK process is complete, and the rest of the
session establishment occurs normally. Figure 9-2
illustrates the entire PRACK exchange, starting with the
first request and ending with the 200 OK.
Figure 9-2 Full PRACK Exchange Between a UAC and a

UAS
CUBE supports PRACK by default, without the need for

configuration. If a device indicates support for reliable
provisional responses through the presence of the rel1xx
tag in the Supported or Required header within an
INVITE message, CUBE requests reliability of
provisional responses on that call leg. By default, CUBE
advertises PRACK capabilities for egress SIP INVITE
messages, regardless of the PRACK support on the
inbound call leg. This is due to PRACK being a per–call
leg mechanism, meaning that one call leg on CUBE may
have a PRACK exchange occur, while the other call leg
does not have a PRACK exchange. Figure 9-3 shows an
example of the asynchronous nature of PRACK on CUBE.
Figure 9-3 Asynchronous PRACK Exchange Across an
SBC
PRACK support on CUBE can be disabled by adding the

command shown in Example 9-5. Alternatively, Example
9-6 details how CUBE can be configured to require
PRACK and advertise Require: 100rel in the outbound
INVITE requests. The command can be returned to the
default by issuing one of the commands shown in
Example 9-7.
Example 9-5 Disabling PRACK Support on CUBE
voice service voip
sip
rel1xx disable
! or
! Per Dial-peer Configuration
voice-class sip rel1xx disable
Example 9-6 Requiring PRACK Support on CUBE

voice service voip
sip
rel1xx require 100rel
! or
voice-class sip rel1xx require 100rel
Example 9-7 Returning to the Default PRACK Support

on CUBE
voice service voip

sip
no rel1xx
! or
voice service voip
sip
rel1xx supported 100rel
Ringback and Provisional Response Interworking

During session establishment involving CUBE, ringback
may be played from one of a few sources. The first is a
remote device, usually special-purpose equipment on a
service provider network or, in some rare scenarios, the
end device that is being called. In this scenario, a
unidirectional audio channel is established from the
called party to the calling party, and ringback is played
out over this channel. In this scenario, the ringback
played is specific to the country of the device providing
ringback through the established audio channel. Figure
9-4 illustrates a remote device such as the ITSP playing
ringback to the SBC and calling party.
Figure 9-4 Ringback Generated from Special Provider

Equipment
The second method for generating ringback is for the

called device to signal the inability to play ringback to the
SBC. This indication is usually achieved via the absence
of media capabilities in the UAS’s response, so that early
media channels do not open. When CUBE receives this
type of message, it is passed through to the peer call leg
because CUBE does not have the ability to generate in-
band ringback on behalf of another device. Similarly,
Unified CM does not have the ability to generate in-band
ringback in this scenario. As a result, Unified CM sends
this response to the IP phone, which plays the local
ringback. Figure 9-5 shows this scenario, with the IP
phone playing ringback.
Figure 9-5 Ringback Generated Locally by the IP Phone
In the context of a SIP call, call alerting (with the called

party in the ringing state) is signaled using the SIP 180
Ringing or 183 Session Progress provisional responses.
When a call is attempted, it may take the called party
several seconds—or maybe even a few minutes—to
answer the call. Before the call is connected, the called
party may choose to send either zero, one, or more
provisional responses. The 18x (180 or 183) provisional
responses serve as an indication to play in-band audio,
such as a ringback tone, to the calling party. The specific
type of the 18x provisional response usually indicates the
source of the ringback tone.
A 180 Ringing response is sent by the called party or a

device that is negotiating call setup on behalf of the
called party (for example, an IP PBX local to the called
party) to indicate the inability or lack of intent to stream
in-band ringback and that another device should play a
locally generated ringback tone. On the other hand, a 183
Session Progress response is sent by the called party or a
device that is negotiating call setup on behalf of the
called party (for example, an IP PBX local to the called
party) to indicate that the ringback tone will be
generated in-band from the called party or special access
equipment on the service provider network.
For the ringback tone to be generated from the called

side, two conditions must be met:
• An audio channel from the called party to the

calling party must be established.
• Information must be provided about the IP address

and port pair on which the calling party is
expecting to receive media.
The first condition is fulfilled by the called party,

including an SDP body in the 183 Session Progress
response. The second condition is met only when the
SDP body encoding the media characteristics of the
calling party is made available. If an early offer call is
sent and a 183 with SDP is received, then early media can
be cut through for ringback. If a delayed offer call is sent
and a 183 with SDP is received, then a PRACK with SDP
should be exchanged to enable early media ringback and
audio session establishment for ringback. Note that in
order for this scenario to occur, Unified CM and CUBE
must both be configured for PRACK and 100rel support.
Chapter 5, “Unified CM SIP Trunk Configuration,”
details how to enable PRACK for Unified CM SIP trunks.
If PRACK is not configured and Unified CM sends a
delayed offer INVITE and receives a 183 with SDP,
Unified CM converts the 18x with SDP into a 180 Ringing
without SDP and sends it to the IP phone to play local
ringback.
Figure 9-6 illustrates the different permutations of 183

with SDP and early and delayed offer.
Figure 9-6 Sample In-Band Ringback Scenarios

Between a UAC and a UAS
A problem arises because RFC 3261 does not define

which 18x responses should contain SDP. Although this
is not defined, it is normal to see a 183 with SDP for in-
band ringback and use the 180 Ringing message without
SDP to signal the inability or lack of intent to play in-
band ringback. In rare circumstances, a 180 with SDP or
a 183 without SDP may be observed. Thus, it is generally
accepted that a device is attempting to establish an audio
channel for ringback if it sends either 18x message with
SDP, and the absence of SDP indicates the inability to
provide ringback, in which case local ringback
interworking is required.
In most scenarios, an SBC simply forwards the received

18x response from the in leg to the out leg, without the
need for extra configuration. Another problem that can
arise is that there may be no upper bound on how many
provisional response messages can be sent during
session establishment. This includes the number of
duplicate provisional responses and the sending of
different types of provisional responses. In addition, RFC
3261 does not set any guidelines for the handling and
interpretation of multiple different types of provisional
responses within the same dialog. Should an SBC place
preference on a provisional response with SDP for
ringback, or should it honor the first or last provisional
responses received? Due to this issue, an SBC may be
equipped with its own logic with regard to the handling
of multiple provisional responses, including those of
different types. One example of this logic would be to
block, disregard, or filter specific types of provisional
responses so that only specific occurrences of provisional
responses are sent on the other side of the SBC. CUBE
allows an administrator to define different types of 18x
messages based on the presence or absence of SDP, as
shown in Example 9-8. The logic of the present or absent
postfix on this command is effectively stating “if SDP
present” or “If SDP absent,” so a 180 Ringing with SDP
could be blocked with the command block 180 sdp
present.
Example 9-8 18x Blocking on CUBE
voice service voip
sip
block {180 | 181 | 183} sdp {present | absent}
!
voice-class sip block {180 | 181 | 183} sdp {present |

absent}
Another example of local logic in regard to provisional

response handling is changing the messages received on
one call leg into another type for the egress call leg. This
can be observed if CUBE receives a 180 response with
SDP. This message is converted, by default, into a 183
Session in Progress with SDP unless the command send
180 sdp is enabled, as shown in Example 9-9.
Example 9-9 Enable the Sending of 180 with SDP
voice service voip
sip
send 180 sdp
!
voice-class sip send 180 sdp
Finally, in addition to blocking, modifying, or filtering

specific messages, CUBE can be configured to disable
early media for 18x responses containing SDP with the
disable-early-media command under the sip-ua
configuration, as shown in Example 9-10. Be aware that
when you add this command, the UAS may not be able to
successfully deliver ringback or service messages to the
UAC, which may result in silence during session
establishment.
Example 9-10 Disabling 180 Early Media
sip-ua
disable-early-media 180
When troubleshooting ringback issues, it is important to

look at the SIP signaling exchanged in debug ccsip
messages. Then you need to attempt to answer the
following questions:
• What type of 18x response is received?
• Does the remote party provide in-band ringback? If

so, has the early media exchange been completed
successfully?
• Does the SBC properly forward this message from

one call leg to another?
• If an 18x with SDP is received, is the early media

session being properly opened through a valid
offer/answer?
• If this session is being opened properly, does the

remote device actually send RTP packets from the
defined IP and port in the SDP of the 18x with
SDP? (To verify this information, a packet capture
can be collected and reviewed.)
• If ringback is delayed for a bit before finally being

heard by the calling party, are there protocol errors,
UDP retransmissions, or erroneous call hunting
(which leads to delay in the signaling that is
ultimately sent to the called device)? (You can best
troubleshoot delays in ringback on CUBE by
enabling debug ccsip messages and debug
voip ccapi inout.)
Table 9-2 can assist with troubleshooting ringback and

provisional response interworking on CUBE.
Table 9-2 CUBE 18x Interworking
MID-CALL SIGNALING
When a session is established, additional signaling
exchanges may be required to maintain or modify a
session. These post-session establishment messages are
referred to as mid-call signaling. Mid-call signaling
includes actions such as calling or called party
number/name updates, modification of session media
parameters, and determination of session refresh
intervals. In addition to the previous signaling
exchanges, mid-call signaling also includes
supplementary services, such as call hold, call resume,
and call transfer.
CUBE is responsible for ensuring that these mid-call

signaling messages are appropriately handled on both
SIP dialogs involved in a call. The following sections
detail some of the most common mid-call signaling
exchanges as well as how an SBC interworks the different
types of mid-call signaling that can occur with these
signaling exchanges.
Hold/Resume
"Let me put you on hold while I check on this item.” You
frequently hear this sentence from customer care
centers. What occurs in such scenarios is that one party
momentarily disrupts the bidirectional flow of media by
pressing a softkey or button (typically the Hold softkey)
on her local device. Bidirectional flow of media is
resumed when the same party presses another softkey
(or the same Hold softkey) on her local device.
Optionally, the held party is presented with hold music
streamed from a Music on Hold server during the hold.
Because any participant in a session can place the call on

hold, the terms holder and holdee are often used to
define participants of a hold scenario. The holder is the
participant who initiates the call hold event, and the
holdee is the person being placed on hold. Placing a call
on hold in most modern IP-based telephony systems
typically consists of the following sequence of events:
Step 1. One party places the call on hold by pressing

a softkey (such as the Hold softkey) or keying
in a specific system-defined sequence of keys.
Step 2. The indication of call hold is communicated

by the call control protocol over the signaling
channel.
Step 3. Bidirectional flow of media is disrupted

between the participants.
Step 4. Usually, when a call is placed on hold, a new

media session is established between a
streaming server and the holdee. This
streaming server is commonly referred to as a
Music on Hold (MOH) server, and it streams
hold music or prerecorded announcements.
Because a new media session is initiated
between the holdee and the MOH server, the
holdee doesn't have to listen to dead air until
the call is resumed.
Step 5. When the holder is ready to resume a

bidirectional media session, he presses the
call Hold button or softkey or keys in a
specific system-defined sequence.
Step 6. The indication to remove the call from hold

and resume the communication session is
communicated by the call control protocol
over the signaling channel. This results in
terminating the media stream between the
MOH server and the holdee and creating a
new media session (or reusing the previous
one) between the holder and holdee.
With SIP, the endpoints involved in the call are either the
holder or holdee. As an SBC, CUBE takes the role of a
holder for one call leg and holdee on another call leg,
although it is very rare for CUBE to initiate a hold event
without first receiving a hold event from another device
on a peer call leg. The main goal for CUBE is to interwork
hold and resume events so that media is terminated,
redirected, and reestablished properly for all parties and
call legs. Failure to do this properly may result in
problematic one-way audio situations, no-way audio
situations, or even undesired call terminations. For the
examples in this section, Unified CM takes the role of the
holder and signals hold events to CUBE, which assumes
the role of the holdee and ultimately interworks these
events to the peer call leg. The IP phones engaged in the
call are not shown for the sake of simplicity, but users of
these devices would initiate the hold by pressing softkeys
or buttons on the devices.
There is no explicit SIP header field that indicates call

hold and call resume. Rather, SIP has to be used in
concert with SDP to indicate call hold and resume. While
there isn't unanimous consensus on the exact semantics
of SIP and SDP for call hold and call resume, most
vendors follow the guidelines of RFC 3264 and 6337. The
predominant method of indicating call hold and call
resume is to use SIP re-INVITE messages and to format
the SDP media direction attribute (a=) and connection
data information (c=) fields.
A holder can indicate desire to place a call on hold by

appropriately modifying the media direction attribute
(a=) or/and connection data information field (c=) of the
SDP body enclosed within the SIP re-INVITE message.
There are distinct ways in which a call can be placed on
hold:
• A call can be placed on hold without any music.
• A call can be placed on hold such that the holdee

hears hold music.
The first scenario involves the holdee hearing silence,

which is commonly referred to as “dead air,” when the
call is placed on hold. This is achieved when the holder
sends a SIP re-INVITE message such that the direction
media attribute of the SDP is set to a=inactive. As per the
guidelines of RFC 3264, when the direction media
attribute in the SDP offer is set to a=inactive, the SDP
answer must mirror the same value of the direction
attribute (that is, it must be set as a=inactive). Setting
the media direction attribute to a=inactive in the offer
and answer ensures that there is no media sent or
received. A second method by which the holder can
achieve the same outcome is by setting the connection
data information field to all zeros (c=IN IP4 0.0.0.0).
This not only results in suspension of any media
exchange between the calling party and the called party
but also results in termination of any RTCP traffic.
Therefore, this alternative is not always the best. Figures
9-7 and 9-8 illustrate these alternatives for holds with no
music. There are certain scenarios in which these
methods are used together—that is, where the SDP of the
re-INVITE message has the media direction attribute set
to a=inactive and the connection data information field
set to 0.0.0.0.
Figure 9-7 Hold with No Media: 0.0.0.0
Figure 9-8 Hold with No Media: a=inactive
Another scenario (see Figure 9-9), which is preferred by

enterprises, involves the holdee listening to hold music
or prerecorded messages for the duration of the hold
sequence. This scenario is achieved when the holder
sends a SIP re-INVITE message such that the media
direction attribute in the SDP offer is set to a=sendonly.
If the holdee sets the media direction attribute to
a=recvonly in the SDP answer, a unidirectional media
channel that terminates on the holdee is established. In
real-world scenarios, the hold music or announcements
are usually streamed from a standalone device to the
holdee endpoint. Therefore, to effectively stream hold
music or announcements, the holder must first tear
down the media stream between itself and the holdee
and establish another media stream between the MOH
server and the holdee. To break the media stream, the
holder might engage in an initial offer/answer exchange
that sets the connection data information field to all
zeros (c=IN IP4 0.0.0.0). After this, a subsequent
offer/answer exchange is initiated to establish another
media stream between the MOH server and the holdee.
This exchange often establishes unidirectional one-way
media from the MOH server to the holdee through the
media direction attributes a=sendonly and a=recvonly.
Figure 9-9 illustrates this process.
Figure 9-9 Hold with Unidirectional Media:

a=sendonly
Note
Unified CM administrators can instruct Unified CM to send a=sendrecv and
subsequently open a bidirectional media channel with the MOH server by
setting the Unified CM service parameter Duplex Media Enabled to True.
Although the MOH server is never expecting to receive audio, only send MOH,
it may need to open a bidirectional media stream to facilitate opening pinholes
when firewalls are present between the MOH server and the endpoint receiving
the MOH stream.
To resume a held call, the holder must initiate another

offer/answer exchange to reestablish the media stream
between itself and the holdee. If hold music is being
streamed, the holder may first send a re-INVITE
message in an attempt to remove the media session with
the MOH server and the holdee. This re-INVITE message
may set the connection data information field to all zeros
(c=IN IP4 0.0.0.0) and send a media direction attribute
of a=inactive. Once the MOH stream has been removed,
another re-INVITE message is sourced from the holder;
it contains the media information of the holder and sets
the media direction to a=sendrecv. The holdee returns
his own media information, and if he also responds with
a media direction attribute of a=sendrecv, bidirectional
media is reestablished.
There is currently no standard that defines the

procedures to be followed by SBCs or B2BUAs to reliably
handle call hold and resume. Nonetheless, vendors of
such devices must embed sufficient logic in software to
ensure that such events are handled reliably, without
negatively impacting the call experience. Broadly, SBCs
handle call hold/resume events in one of two ways:
• Passing SIP re-INVITE message sequences

end-to-end with minimal modification: SIP
re-INVITE messages and responses that tear down
the media stream between the holder and holdee
establish a media stream between the MOH server
and the holdee and reestablish the media stream
between holder and holdee on call resume and
passed across from the holder network to the
holdee network with minimal modification. These
modifications typically include overwriting the IP
addresses advertised in the SIP header fields and
the SDP bodies of SIP re-INVITE messages and
responses. (Figure 9-11, later in this chapter,
demonstrates this.)
• Abstracting hold/resume events from the

holdee: The SBC completely abstracts
hold/resume exchanges by the holder by handling
such exchanges locally. This method may lead to
interoperability issues and unexpected behavior
when a peer device expects to be notified of such
events. On the other hand, a peer device may not be
properly equipped to handle specific types of
hold/resume events, and this may result in audio
problems during or after the hold/resume. Thus,
this method can be employed to solve this type of
interoperability issues by not advertising
hold/resume events to the peer device. The benefits
and drawbacks of the application of this method by
an SBC are highly dependent on the peer devices’
capability sets and local network variables.
Using CUBE and Cisco Unified CM as an example, this

chapter details a sample hold/resume event signaled by a
Unified CM registered endpoint. Unified CM uses a
mixture of the hold methods defined in the previous
section when advertising a hold event. Figure 9-10 shows
the topology for the following hold/resume event. Note
that Unified CM also takes on the role of the MOH server
for this sample session.
Figure 9-10 Unified CM, CUBE, and ITSP Topology
After a call is established, a user can press the Hold

button or softkey on her device to initiate a hold event.
Unified CM then modifies the established media stream
by sending a SIP re-INVITE message with the media
direction attribute set to a=inactive and the connection
data information field set to c=IN IP4 0.0.0.0. Example
9-11 shows the SIP signaling for this event between
CUBE and Unified CM. CUBE forwards the re-INVITE
message for modifying the media stream to the peer call
leg and waits for a response on that call leg before
sending an answer to Unified CM. After a response is
received on the peer call leg, CUBE answers the re-
INIVTE message with a 200 OK message that contains
the media direction attribute a=inactive as an answer to
the re-INVITE offer, but CUBE chooses to send its local
IP address rather than respond with c=IN IP4 0.0.0.0 in
both the global and local connection data information
SDP lines.
Example 9-11 Signaling with Audio Set to Inactive and

0.0.0.0 Advertised
Received:
INVITE sip:7777@172.18.110.58:5060;transport=tcp SIP/
CSeq: 102 INVITE
[...Truncated for Brevity...]
v=0
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
a=inactive
a=fmtp:101 0-15
[...The same information occurs on the other call leg
Sent:
SIP/2.0 200 OK
CSeq: 102 INVITE
v=0
s=SIP Call
c=IN IP4 172.18.110.58
t=0 0
c=IN IP4 172.18.110.58

a=inactive
a=fmtp:101 0-16
After the media stream is successfully disabled through

the SDP offer/answer exchange end to end, Unified CM
sends a delayed offer re-INVITE message soliciting the
SBC and, ultimately, the holdee for its media capabilities
(which are subsequently encoded in the 200 OK
response). After receiving the peer SDP, Unified CM
sends an ACK with SDP with the media direction
attribute set to a=sendonly and the connection data
information encoding the IP address of a MOH server.
Example 9-12 shows the delayed offer exchange between
Unified CM and CUBE for MOH insertion. (MOH is
covered later in this chapter.) Again, this SIP transaction
takes place end to end. When this SIP transaction
concludes, the call is on hold, and the holdee hears hold
music audio. This continues until the user desires to take
the call off hold. In addition, because the MOH media
resource does not need to receive media but only send
media, Unified CM allocates a dummy port of 4000 for
sourcing media from the MOH resource.
Example 9-12 Negotiating Unicast MOH
Sent:
SIP/2.0 200 OK
CSeq: 103 INVITE
v=0
s=SIP Call
c=IN IP4 172.18.110.58
t=0 0
m=audio 8066 RTP/AVP 0 101 19
c=IN IP4 172.18.110.58
a=fmtp:101 0-16
a=ptime:20
Received:
ACK sip:7777@172.18.110.58:5060;transport=tcp SIP/2.0
CSeq: 103 ACK
v=0
s=SIP Call
c=IN IP4 172.18.110.48
t=0 0
a=X-cisco-media:umoh
a=ptime:20
a=sendonly
When the end user is ready to take the call off hold, he
presses the button or softkey again to resume the call;
Unified CM sends another re-INVITE message with the
media direction attribute set to a=inactive and the
connection data information field set to 0.0.0.0. This
results in the de-allocation of the media resource for
MOH. Finally, Unified CM sends a delayed offer re-
INIVTE message, soliciting the SBC and, ultimately, the
holdee for their capabilities (which are subsequently
encoded in the 200 OK response). Finally, Unified CM
reconnects audio to the endpoint and sends an ACK with
SDP, which reopens bidirectional media. Figure 9-11
illustrates the entire hold/resume process and multiple
transactions in the SIP dialog that takes place between
Unified CM and CUBE.
Figure 9-11 Full Hold Resume and MOH Signaling on
Unified CM, CUBE, and ITSP
When troubleshooting hold/resume issues, it is best to

use debug ccsip messages, debug ccsip error, and
debug voip ccapi inout on an SBC. Because there will
be upward of 20 SIP messages per dialog, it is
recommended to use an application such as TranslatorX
to assist in visualizing the different events of the mid-call
signaling. You can break up the different events into
their own respective SIP transactions for further
diagnosis (for example, initial call establishment, media
inactive, MOH establishment, MOH de-allocation, media
recommencement). By using this method,
troubleshooting can be focused on specific parts of the
hold/resume process and can facilitate finding whether
something may have gone awry during that specific
transaction. It is also important to remember that the
process consists of many different media changes and
may involve negotiating different codecs for the MOH
server. Ask and attempt to answer the question: Does the
hold fail due to one device attempting codec negotiation
that is unsupported by other devices?
Call Transfer
Interactive voice response (IVR) systems, contact center
scripts, and even end telephone users need to be able to
transfer a call to a different destination without the other
party hanging up or being disconnected. CUBE must not
inhibit the transfer process and may even be required to
perform interworking so that the call transfer can be
seamlessly completed. A call transfer differs from a call
forward in that it takes place after a session is
established, and the bulk of the signaling to facilitate a
transfer takes place in the mid-call signaling. There are a
few different ways to complete a transfer. The following
sections define these transfer types.
Note
The terms transferor, transferee, and transfer target are used to define the
parties involved in a call transfer. The transferor is the person or device
initiating a transfer, and the transferee is the person being transferred to a new
destination. Finally, the transfer target is the new destination to which the
transferee will be connected when the transfer is completed by the transferor.
These terms are illustrated in Figure 9-12.
Figure 9-12 Transferor, Transferee, and Transfer

Target Illustrated
REFER Transfer
The SIP REFER method was defined and standardized in
RFC 3515 to provide a framework for call transfers in SIP
networks. Over the years, several modifications have
been made to the implementation of the SIP REFER
method to fit a variety of application usages. This section
provides an overview of the basic implementation of the
SIP REFER method outlined in RFC 3515.
A user agent (transferor) attempting to transfer a call (to
the transfer target) does so by sending a SIP REFER
request to the transferee. Included in the SIP REFER
request is information on how the transferee can reach
the transfer target; this information is encapsulated in
the Refer-To header field (see Example 9-13). For a
REFER request to be sent, there needs to be an
established, active communication session between the
transferor and transferee. The REFER request is sent on
the same SIP dialog as the established communication
session to ensure that the request is delivered to the
intended recipient, can be correctly correlated by the
transferee to the existing communication session, and is
from an authorized source.
Example 9-13 Sample REFER and the Refer-To Header
REFER sip:b@atlanta.example.com SIP/2.0

Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: sip:alice@atlanta.example.com
Contact: sip:a@atlanta.example.com
Content-Length: 0
The SIP REFER request creates an implicit subscription

between the transferor and transferee. This subscription
is then used by the transferee to notify the transferor of
the status of processing the REFER request. The
messages sent in this implicit subscription are detailed in
Figure 9-13.
Figure 9-13 High-Level REFER Overview
The SIP REFER method for call transfer proceeds as

follows:
Step 1. A communication session is established

between Party A and Party B. At some time
during the call, Party A decides that the call
needs to be transferred to another party,
Party C.
Step 2. A SIP REFER request is sent from Party A to

Party B, such that the request carries a Refer-
To header. The Refer-To header field
encapsulates the SIP URI of Party C.
Step 3. On receiving the SIP REFER request, Party
B parses the request to ensure correct
formatting. If the request is incorrectly
formatted, the request is rejected, with an
appropriate error code. For example, if the
REFER request carries zero or more than one
Refer-To header field, it is rejected with a
400 Bad Request response.
Step 4. If the request is correctly formatted, Party B

sends a 202 Accepted response to Party A.
This response also results in the
establishment of an implicit SIP subscription
between Party A and Party B, and the aim of
the subscription is for Party B to notify Party
A of the status of processing the REFER
request.
Step 5. Immediately after sending a 202 Accepted

response, Party B sends a SIP NOTIFY
request to Party A. In parallel, it attempts to
create a communication session with Party C,
using the URI specified in the Refer-To
header field of the REFER request.
Step 6. The results of the attempt to establish a

communication session with Party C are
encapsulated in subsequent NOTIFY
messages sent from Party B to Party A. If
Party B succeeds in establishing a
communication session with Party C, it sends
a SIP NOTIFY with the SIP response status
line SIP/2.0 200 OK. If the attempt is
unsuccessful, it sends a SIP NOTIFY with a
SIP response status line or SIP/2.0 603
Declined.
Note that the implicit subscription created by the REFER

request can either be explicitly or implicitly terminated
by the transferor (Party A) at any time. Termination of
the subscription should not negatively impact the
outcome of REFER processing by the transferee (Party
B). SIP NOTIFY messages sent by the transferee to the
transferor indicate the outcome of request processing at
the transferee. Every NOTIFY message must contain a
message body of type message/sipfrag and must include
an Event header field with the tag value refer. Example
9-14 displays a SIP NOTIFY message with a message
body containing SIP/2.0 100 Trying to let the transferor
know the request is being processed.
Example 9-14 Sample SIP NOTIFY Message with a 100

Trying sipfrag Body
NOTIFY sip:a@atlanta.example.com SIP/2.0

Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-

Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
When the transfer is answered, the device handling the

REFER sends one last NOTIFY message, specifying 200
OK. This final NOTIFY message contains the SIP header
Subscription-State: terminated;reason=noresource to
indicate that this is the final NOTIFY message, and the
REFER process is complete. Example 9-15 displays a SIP
NOTIFY message with a message body containing
SIP/2.0 200 OK, indicating to the transferor that the
REFER has been processed completely, and a session
with the transfer target has been established.
Example 9-15 Sample NOTIFY Message with a 200 OK

sipfrag Body
NOTIFY sip:a@atlanta.example.com SIP/2.0

Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
CSeq: 1993403 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
SIP/2.0 200 OK
As mentioned earlier in this section, a number of

enhancements to the REFER method are defined in RFC
3515. RFC 3892 defined a new header, Referred-By, for
use in REFER-based transfers scenarios. The user agent
originating a REFER request may include a single
Referred-By header, which has the following format:
Referred-By: <sip-uri>
A user agent processing a REFER containing a Referred-

By header may include the Referred-By header within
the SIP INVITE request sent to the refer target indicated
in the Refer-To header. The use of the Referred-By
header allows the refer target to parse the SIP URI
provided and authenticate the call transfer by using local
logic. For example, say that there is an established
session between Alice and Bob. Bob attempts to transfer
Alice to a refer target, Josh. The Referred-By header
would state that Bob is the one referring Alice to Josh.
Josh may have in place logic that rejects a call transfer if
Bob is the referring party, and this is communicated to
Josh by the content of the Referred-By header.
The use of a Referred-By header is entirely optional and

not required for a successful REFER-based transfer to
complete. However, a device may require that a
Referred-By header be present to satisfy local logic and
permit session establishment. In this scenario, a 429
Provide Referrer Identity may be sent in response to a
REFER/INVITE that does not contain a Referred-By
header.
Tip
This chapter does not discuss out-of-dialog (OOD) REFER messages.
Often the transferor, transferee, and transfer target are

on different networks. In such scenarios, there may be
many different devices, such as a third-party call agent
and a CUBE, involved in the session. In such a scenario,
the REFER request is sent from the transferor to other
signaling devices involved in the session. These devices
can take one of two actions with a received REFER
request:
• The device can act on behalf of the transferee and

attempt to establish a session with the transfer
target defined in the Refer-To header of the REFER
request.
• The device may pass the REFER request from one
call leg to the peer call leg without acting on the
REFER request.
The first method of REFER handling, detailed

previously, is often referred to as REFER consume. In
this scenario, CUBE consumes the REFER request, as
shown in Figure 9-14, and takes action on the provided
URI in the Refer-To header. If the Refer-To header
contains a SIP URI, the CUBE extends an INVITE
between itself and the user agent identified in the Refer-
To header in an attempt to establish a session. This is the
most common implementation of SIP REFER handling
on an SBC.
Figure 9-14 REFER Consumption on CUBE
With the second method, CUBE performs a passthrough

of the REFER so that a downstream device can take
further action on the REFER request. This method can
be used to potentially remove CUBE from further
signaling after the transfer is complete. This method is
often used when transferring an off-net PSTN party to
another off-net PSTN party. Both the transfer target and
the transferee are not on the network that CUBE is
responsible for, so the SBC may be dropped from the
signaling. Figure 9-15 shows this method.
Figure 9-15 REFER Passthrough on an SBC
CUBE can be configured to either consume or pass

across a received REFER message. Using the
configuration example in Example 9-16, when CUBE
receives a REFER message, it does not process the
REFER message but instead creates an egress REFER
message with the same information and sends it to the
peer hop. When the REFER transfer is complete in this
scenario, CUBE is no longer involved in the call. Most
ITSPs do not support REFER-based transfers, so REFER
consume is often used.
Example 9-16 CUBE REFER Passthrough
Configuration
voice service voip
supplementary-service sip refer

no supplementary-service media-renegotiate
sip
referto-passing
Example 9-17 shows how to configure CUBE to consume

and completely process the REFER request. When this
method is used, CUBE parses the user portion of the
request URI in the Refer-To header. This is used as the
key for performing a dial peer lookup. When the dial
peer matching logic is satisfied, an outbound INVITE is
sent to the session target defined on the dial peer. When
the REFER is complete, CUBE is still involved in the
signaling and session. The transferor who sent the
REFER is removed, and the session now involves the
transferee, CUBE, and the transfer target. The
supplementary-service command for media
renegotiation is included to allow CUBE to renegotiate
end-to-end media capabilities when consuming the
REFER and establishing the new session call leg.
Example 9-17 CUBE REFER Consumption

Configuration
voice service voip
no supplementary-service sip refer

supplementary-service media-renegotiate
sip
no referto-passing
Cisco Unified Communications Manager Express

(Unified CME) and Unified CM also leverage SIP REFER
for transfer purposes. Unified CM’s use of REFER is
covered in the next section, and the Unified CME process
is covered in Chapter 10, “Unified CME and SRST.” Note
that if Unified CM is engaged in a call where the inbound
device and outbound device are both SIP trunks, a
REFER message received on one SIP trunk can be passed
through Unified CM and sent on the other SIP trunk with
the aid of the “refer-passthrough” SIP normalization
script. Unified CM never sends a REFER outbound on a
SIP trunk for calls being transferred by an IP phone. In
this scenario, an INVITE transfer is used. The next
section discusses how Unified CM performs this type of
transfer involving IP phones.
INVITE Transfer
Another method of call transfer, which is primarily used
by SIP IP phones, Unified CM, and Unified CME, is
achieved by using SIP INVITE messages. During a call
transfer that utilizes a SIP INVITE to create a new call
and call leg, the original media stream may be
temporarily suspended while a new INVITE message is
being processed. When the call transfer is complete, the
original call and the call established with the new
INIVTE message are bridged together; the media stream
is subsequently reestablished between the transferee and
the transfer target.
Note
The upcoming examples feature CUBE sending an inbound call to Unified CM,
which routes the call to an IP phone. The IP phone then transfers the call to
another endpoint registered to the same Unified CM cluster. The peer call leg
of CUBE has been omitted to simplify the diagrams.
To initiate the hold and new INVITE transfer process,

the transferor presses a button or softkey, which places
the transferee on hold. While the transferee is on hold,
the transferor can initiate a call transfer by dialing the
number of a transfer target. During this process, a
minimum of four different call legs are created on
Unified CM between the different endpoints. These call
legs will be discussed further later on, but for now you
just need to know these basics:
• Call Leg 1: This is the original ingress unified CM

call leg. This was the call leg starting from the
endpoint that initiated the call. Call Leg 1 could
easily be another SIP IP phone, but for upcoming
examples this call leg is from CUBE and assumes
the role of the transferee.
• Call Leg 2: This is the original egress unified CM

call leg. This is the call leg Unified CM used to
connect the call to the IP phone endpoint. For the
upcoming examples, this device takes the role of
the transferor.
• Call Leg 3: This is the new call leg created by the

transferor to reach the transfer target. This is sent
to Unified CM to facilitate interworking.
• Call Leg 4: This is the new egress unified CM call

leg created to connect with the transfer target.
When the transfer is completed in the upcoming

examples, Call Legs 1 (transferee) and 4 (transfer target)
are connected, and Call Legs 2 and 3 (transferor) are
removed from the session. Note that either Call Leg 1 or
Call Leg 2 can assume the role of a transferor, making
the other the transferee. After dialing the transfer target
number, the transferor can complete the transfer in one
of few ways.
The first transfer method is termed an unattended

transfer, or blind transfer, which means a call is directed
to the transfer target, and when the transfer target
answers, audio is connected between the transferee and
the transfer target. The transferor is dropped from the
session before the transfer target answers. Figure 9-16
provides a high-level overview of the events that occur in
a blind transfer with Unified CM, CUBE, and two IP
phones. This figure serves as the basis for discussing
blind transfer in upcoming paragraphs.
Figure 9-16 High-Level Overview of Blind Transfer

with Unified CM, CUBE, and Two IP Phones
The blind transfer in Figure 9-16 occurs as follows:
Step 1. CUBE sends a call to Unified CM; this is Call

Leg 1.
Step 2. Unified CM creates Call Leg 2 and sends the

call to the IP phone, which assumes the role
of transferor.
Step 3. The audio is now connected with

bidirectional (two-way) media.
Step 4. The transferor places the original call with
the transferee on hold by pressing the
Transfer softkey or button a single time. This
triggers normal hold/resume signaling (as
discussed earlier in this chapter) while the
user performs the rest of the transfer
sequence.
Step 5. The Unified CM endpoint creates a new call

(Call Leg 3) and sends a new INVITE message
to Unified CM with the transfer target’s
number after the user dials the number.
Step 6. Unified CM works to route the call to the

transfer target and creates Call Leg 4.
Step 7. At any point, usually once ringback is heard

to confirm that the transfer target is being
called, the transferor may press the Transfer
softkey or button again to confirm the
transfer. If the Unified CM service parameter
setting Transfer On-Hook Enabled is set to
True, the IP phone may also simply hang up
the call to complete the transfer. The Unified
CM endpoint sends a REFER (on Call Leg 2)
with a Refer-To SIP header that contains a
tag with the call-id, the to header tag, and the
from header tag that references the call
ringing the transfer target.
Step 8. Unified CM works to interwork the

transferee (Call Leg 1) and transfer target
(Call Leg 4) based on this REFER message.
The transferor call legs (Call Legs 2 and 3) are
removed from the session.
Step 9. Because the transfer has been completed by

the IP phone, ringback is played to the
transferee to signal that the remote party is
being called and proceeding normally. The
ringback continues until the transfer target
answers the call. Because the call is already
connected, an 18x message is not sent;
instead, a media resource such as the Unified
CM annunciator is required to play ringback
to the transferee.
Step 10. When the call is answered by the transfer

target, Unified CM de-allocates the
annunciator and renegotiates media with the
transferee and transfer target.
Figures 9-17, 9-18, and 9-19 provide a more granular

view of these steps. The main SIP signaling exchanges
have been included for all four call legs for a blind
transfer, although some signaling—such as the SIP
SUBSCRIBE, SIP KPML, and SIP 1xx messages—has
been omitted for brevity.
Figure 9-17 illustrates the initial SIP three-way

handshake to establish the call between the calling party
and the called party and then the hold signaling observed
when the Transfer key is pressed for the first time. Note
that the hold signaling occurs twice: first to remove the
media and then to establish MOH. (The first removal of
media has been omitted from this figure for brevity.)
Figure 9-17 The Initial Call Signaling and Hold
Figure 9-18 starts with the initial call on hold, and a new
call leg (Call Leg 3) is created by the transferor to call the
transfer party. This new call is sent to Unified CM, which
performs digit analysis and finds a callable endpoint.
Unified CM attempts to establish a new session with the
transfer target specified by the transferor. This results in
the creation of Call Leg 4. Here an INVITE message is
sent to the transfer target, and a 180 Ringing message is
received by Unified CM. This 180 Ringing message is
relayed to the transferor. The transferor now hears
ringback and knows the transfer target has been called
successfully. At this point, the Transfer key is pressed
again to start the blind/unattended transfer. A REFER
message is sent to Unified CM on Call Leg 2, and it
contains a Refer-To header with a Replaces tag that
includes the call-id, a to header tag, and the from header
tag of Call Leg 3. Unified CM then removes MOH on Call
Leg 1 to replace the MOH with ringback streamed from a
local annunciator. The two call legs involving the
transferee are disconnected with a SIP BYE. At this
point, the transferee is hearing ringback while the
transfer target is ringing.
Figure 9-18 Unified CM Facilitating the Transfer

Between the Transferee, Transferor, and Transfer Target
Example 9-18 The REFER on Call Leg 2, Which
Instructs Unified CM to Replace the Call with the Call
from the Session Established on Call Leg 3.
Call Leg 3 180 Ringing

SIP/2.0 180 Ringing
From: “2001” <sip:2001@rtp-cucm.ccnpcollab.lab>;tag=d
To: <sip:2@rtp-cucm.ccnpcollab.lab>;tag=45272~594cd2d
Date: Thu, 10 Oct 2019 22:54:25 GMT
Call-ID: d0ec35ff-eafe0008-474553bb-079c2d73@14.50.21
Call Leg 2 REFER

REFER sip:777@172.18.110.91:5060;transport=tcp SIP/2.
From: <sip:2001@rtp-cucm.ccnpcollab.lab>;tag=d0ec35ff
To: <sip:777@172.18.110.91>;tag=45268~594cd2d2-a0cb-4
Call-ID: e1fa3800-10001-47-93f492a@172.18.110.91
Max-Forwards: 70
Session-ID: 27ee888100105000a000d0ec35ffeafe;remote=9
Date: Thu, 10 Oct 2019 22:54:20 GMT
CSeq: 103 REFER
Contact: <sip:d3890d29-e50a-48d0-94ea-29464e124527@14
Refer-To: <sip:2000@rtp-cucm.ccnpcollab.lab?Replaces=
Referred-By: <sip:2001@rtp-cucm.ccnpcollab.lab>
Content-Length: 0
Figure 9-19 starts where Figure 9-18 left off: The

transferee is being called, and the transfer target is
actively ringing. Unified CM sends an UPDATE message
to each caller that contains caller ID information of the
new parties. (The UPDATE message is discussed in
upcoming sections.) Once the transfer target answers the
call, Unified CM removes the annunciator and
renegotiates media with the transferee. At this point, the
call is connected with media flowing between the
transferee and transfer target.
Figure 9-19 The Caller ID Updates and Media
Connection After the Transfer Target Answers
Another transfer method that is often seen with Unified

CM endpoints is the consult transfer, or attended
transfer. In this type of transfer, the call is sent to the
transfer target, and when the transfer target answers,
audio is connected between the transferor and the
transfer target. The transferee remains on hold while the
transferor and transfer target are engaged in
conversation. To complete the transfer, the transferee
may press the Transfer button again, and the transferor
is then removed from the session, and the transferee and
transfer target audio session is established. Figure 9-20
provides a high-level overview of the events that occur in
a consult transfer with Unified CM, CUBE, and two IP
phones. This figure serves as the basis for discussing
consult transfer in upcoming paragraphs.
Figure 9-20 High-Level Overview of Consult Transfer
with Unified CM, CUBE, and Two IP Phones
The consult transfer in Figure 9-20 occurs as follows:
Step 1. CUBE sends a call to Unified CM. This is Call

Leg 1.
Step 2. Unified CM creates a Call Leg 2 and sends

the call to the IP phone, which assumes the
role of transferor.
Step 3. The audio is now connected with

bidirectional (two-way) media.
Step 4. The transferor places the original call with

the transferee on hold by using a Transfer
softkey or button on the endpoint. This call
uses the normal hold/resume signaling
discussed earlier in this chapter.
Step 5. The Unified CM endpoint creates a new call

(Call Leg 3) and sends a new INVITE message
to Unified CM with the transfer target’s
number after the user dials the number.
Step 6. Unified CM works to route the call to the

transfer target and creates Call Leg 4.
Step 7. Up until this point, the transfer process has

been exactly the same between
blind/attended and consult/unattended
transfers. The differences occurs when the
transferor waits for the transfer target to
answer the call, at which point an audio
session is established between the transferor
and the transfer target. The transferee
remains on hold. At any point, the transferor
can press the Transfer softkey or button again
to confirm the transfer.
Step 8. The Unified CM endpoint sends a REFER

(on Call Leg 2) with a Refer-To SIP header
that contains a replaces tag referencing the
call-id, the to header tag, and the from header
tag that references the call ringing the
transfer target.
Step 9. Unified CM works to interwork the

transferee (Call Leg 1) and transfer target
(Call Leg 4) based on this REFER. The
transferor call legs (Call Legs 2 and 3) are
removed from the session.
Step 10. No ringback is played to the transferee

because the media renegotiation between the
transferee and transfer target begins
immediately. The MOH resource is de-
allocated, and an audio stream is established
between the transferee and the transfer
target.
Figures 9-21, 9-22, and 9-23 provide a more granular

view of these steps discussed. The main SIP signaling
exchanges have been included for all four call legs for a
consult transfer, although some signaling—such as the
SIP SUBSCRIBE, SIP KPML, and SIP 1xx messages—has
been omitted for brevity.
Figure 9-21 starts from the point of Figure 9-17 that

details the initial call setup and hold. A SIP three-way
handshake occurs to establish the call between the
calling party and the called party and then hold signaling
occurs when the Transfer key is pressed for the first time.
Note that the hold signaling occurs twice: first to remove
the media and then to establish MOH. (The first removal
of media has been omitted for brevity.)
Figure 9-21 Unified CM Facilitating the Transfer

Between the Transferee, Transferor, and Transfer Target
with the Transferor and Transfer Target Connecting
Audio
Figure 9-21 starts with the initial call on hold. A new call
leg (Call Leg 3) is created by the transferor to call the
transfer target. This is sent to Unified CM, which
performs digit analysis and finds a callable endpoint.
Unified CM attempts to establish a new session with the
transfer target specified by the transferor. This results in
the creation of Call Leg 4. Here an INVITE message is
sent to the transfer target, and a 180 Ringing message is
received by Unified CM. This 180 Ringing message is
relayed to the transferor. The transferor now hears
ringback and knows the transfer target has been called
successfully.
The transferor may elect to wait until the transfer target

answers rather than press the Transfer key again to
confirm the transfer and start the blind/unattended
transfer process. When the transfer target answers, the
SIP three-way handshake is complete, and media is
negotiated between the transferor and the transfer
target.
Figure 9-22 starts with the original call on hold, while

the transferor and transfer target are engaged in a
session. When the transferor is ready to confirm the
transfer, the softkey may be pressed again to confirm the
transfer. A REFER message is sent to unified CM on Call
Leg 2; it contains a Refer-To header with a Replaces tag
that includes the call-id, the to header tag, and the from
header tag of Call Leg 3. Functionally, this REFER
message is the same in both blind and consult transfers.
(Examine the REFER message in Example 9-18 for more
information.) Unified CM then removes MOH on Call
Leg 1 in order to start media renegotiation. The media is
also removed on Call Leg 4 to start media renegotiation.
The two call legs involving the transferee are
disconnected with a SIP BYE message. Finally, Unified
CM updates the caller ID information for both the
transferee and the transfer target.
Figure 9-22 Unified CM Facilitating the REFER to
Remove the Transferor and Connect the Transferee and
Transfer Target
Figure 9-23 wraps up the consult transfer process by

detailing the media renegotiation, which simply involves
a SIP three-way handshake on Call Leg 1 and Call Leg 4
to determine media capabilities and connect media
between the transferee and the transfer target.
Figure 9-23 Media Renegotiation Between the

Transferee and Transfer Target
For these two transfer methods, Unified CM is

responsible for inviting the transfer target to the session
as well as for the hold and resume the transferee
experiences and also for the renegotiation of media for
the transfer target, transferee, and transferor. In some
scenarios, the transfer target may be a device on the
PSTN, which means that CUBE may be both the
transferee and the transfer target from Unified CM’s
perspective. From CUBE’s perspective, an INVITE-based
transfer makes use of two different call dialogs. The first
SIP dialog is the original call between the transferor and
the transferee. The second is a new SIP dialog between
the call agent, on behalf of the transferor, and the
transfer target. While CUBE can interwork REFER
similarly to Unified CM, Unified CM never passes
through a SIP REFER message received from a phone to
a SIP trunk, so Unified CM and CUBE remain involved
while the transferor is removed from the session.
REFER Versus INVITE Transfers

When comparing REFER and INVITE transfer methods
from CUBE’s perspective, you can quickly see the
benefits and drawbacks. With REFER-based transfers,
CUBE can be eliminated from the signaling–and even
from the media path, as noted in the previous sections.
In contrast, with INVITE-based transfers, Unified CM
and CUBE are often left in the signaling path even when
the transferee and transfer target are not on the
enterprise LAN. At this writing, Unified CM supports
only INVITE as the transfer method for SIP trunks, and
Unified CM never sends a REFER message to CUBE.
CUBE will continue to support either type of transfer
method because other vendors and other Cisco
applications, such as contact center call progress analysis
(CPA) features, support the REFER-based transfer with
CUBE.
For media interworking, CUBE can be configured with

the command media anti-trombone, as shown in
Example 9-19, to perform best-effort media loop
detection. With this command in place, CUBE looks for
matching SDP in the two SIP dialogs. If similar media
characteristics such as IP and port are found, media
anti-trombone can attempt to advertise the transferee
and transfer target’s media information to either, which
eliminates CUBE from the media path. Figure 9-24
illustrates a call transfer with and without media anti-
trombone.
Example 9-19 Enabling the Media Anti-Trombone

Feature on CUBE
!
voice service voip
media anti-trombone
!
Figure 9-24 A Visual Comparison of Operation With

and Without the Anti-Trombone Feature
UPDATE Interworking
The SIP UPDATE method, defined in RFC 3311, provides
a way for a SIP user agent to modify session
characteristics before the call is answered. The SIP
UPDATE method is similar to the SIP re-INVITE
method, but the main difference is that the SIP UPDATE
can be used to modify session characteristics before a
session is established, and a SIP re-INVITE cannot do
this. Table 9-3 shows the differences between the two
method types.
Table 9-3 Comparison of re-INVITE and UPDATE
Request Methods
A device advertises its capability to support the SIP

UPDATE method by specifying this method in the Allow
header (see Example 9-20). This can be in a request or in
a response. In addition, an UPDATE may or may not
contain SDP. UPDATE messages without SDP usually
modify session characteristics such as the caller ID and
session timers, whereas UPDATE messages with SDP
directly modify the session's media attributes.
Example 9-20 An Allow Header with the UPDATE

Method Specified
INVITE sip:7777@172.18.110.58:5060 SIP/2.0

From: <sip:1234@172.18.110.48>;tag=30489~1992ce86-77a
To: <sip:7777@172.18.110.58>
Call-ID: 990bdd00-b041b14b-f2-306e12ac@172.18.110.48
Supported: timer,resource-priority,replaces
Min-SE: 1800
CSeq: 101 INVITE
Expires: 180
Max-Forwards: 70
Content-Length: 0
SIP/2.0 183 Session Progress

From: <sip:1234@172.18.110.48>;tag=30489~1992ce86-77a
To: <sip:7777@172.18.110.58>;tag=66EF7A-1E33
Call-ID: 990bdd00-b041b14b-f2-306e12ac@172.18.110.48
CSeq: 101 INVITE
Content-Length: 0
A SIP UPDATE request may be sent by any participant in

a session. However, there are specific guidelines related
to when it is and is not appropriate to send a SIP
UPDATE. These are broken down into three key
scenarios:
• If the original offer does contain a session media

description (early offer) and this offer is answered
reliably by a PRACK exchange (as described earlier
in this chapter), an UPDATE message may be sent
for session description modification. Figure 9-25
illustrates an early offer call in which a UAS has
sent a 183 with SDP. The PRACK is exchanged, and
the offer/answer has been completed reliably.
However, the UAC wants to change the aspects of
the media session. Because the call is not yet
answered by the UAS with a final response, the
UAS sends an UPDATE message with SDP. The
UAS responds with a 200 OK with SDP. This can
continue as many times as needed until a final
response to the INVITE message is processed. If the
offer is not answered reliably with PRACK, only an
UPDATE message without SDP can be processed
for this session.
Figure 9-25 PRACK and UPDATE Between a UAC and
a UAS
• If the original offer does not contain any offer

(delayed offer), an UPDATE message for session
media modification cannot be processed unless an
answer/offer PRACK exchange occurs. In this
scenario, the provisional response (such as a 183
with SDP) would contain an offer, and the PRACK
with SDP would contain the answer. If the
aforementioned offer/answer has yet to be
finalized, only an UPDATE message without SDP
can be processed at this point in the session.
• UPDATE messages for session media modification

may be used after the initial INVITE transaction
has been completed, as long as there are no
outstanding offers (re-INVITE or UPDATE)
awaiting answers. If there is an outstanding
transaction awaiting an answer to an offer and an
UPDATE is received, this solicits a 491 response.
Similarly, if there is an outstanding transaction in
which the device receiving the UPDATE is in the
process of generating an answer, the response must
be a 5xx-level response with a Retry-After header.
This is the same response code and behavior
observed if a device attempts to send an UPDATE
message before a previous UPDATE message of any
kind has been answered with a 200 OK.
One problem that arises in the scenario of updating a

session description before a call is connected has to do
with the asymmetrical nature of PRACK. Because
PRACK is a per–call leg mechanism, from the
perspective of CUBE, a reliable provisional response
might be exchanged on one call leg and not on the other.
This scenario is depicted in Figure 9-26. In this scenario,
it is valid for the device on Call Leg A to send an
UPDATE message with SDP to the SBC. The SBC would
either need to respond to the UPDATE message on
behalf of Call Leg B or return a 491 Request Pending
message back to Call Leg A because it is unable to pass
the UPDATE message with SDP to Call Leg B.
Figure 9-26 Asymmetric PRACK, UPDDATE, and 491

Responses
For such scenarios, SBCs can be configured to locally

consume SIP UPDATE messages without passing the
request to the peer call leg. From the perspective of
CUBE, local consumption of SIP UPDATE messages can
be achieved be configuring early-media update
block, as demonstrated in Example 9-21.
Example 9-21 Configuring a CUBE Early Media Update

Block
voice service voip
sip
early-media update block
As mentioned earlier in this chapter, UPDATE messages

are commonly used to modify caller ID when a remote
device transfers a call or when additional parties are
added to the call. This can be done at any time during a
session and does not require any prerequisite signaling
exchanges, such as PRACK. Most SBCs forward these
types of UPDATE messages on the peer call leg by
default. It is common to observe this method of UPDATE
message in conjunction with the call transfer events
discussed earlier in this chapter. When a device transfers
from one party to another, often the caller ID of the new
participant is sent in an UPDATE message to the other
participants in the session. By default, CUBE passes
through mid-call UPDATE messages for caller ID
changes. The passing of these messages may lead to
additional SIP traffic being sent to the service provider,
which also increases bandwidth on the network and
could even lead to race conditions when an UPDATE
message is not expected. Thus, the default behavior of
passing caller ID updates can be changed by removing
the default command, as shown in Example 9-22.
Example 9-22 Disabling CUBE Update Caller ID
voice service voip

sip
no update-callerid
Session Refresh
It is quite common for a communication session
established over SIP to span several intermediary
devices, such as call agents, SIP proxies, and SBCs. In
such scenarios, it is vital that requests and corresponding
responses be transmitted reliably and in a timely manner
end to end to ensure that the state of the communication
session is synchronized across all devices in the call path.
Consider a situation in which a communication session is
established across the topology depicted in Figure 9-27.
Figure 9-27 Topology with UA, Call Agent, Stateful

Proxy, SBCs, and an IVR Device
The IVR device is capable of only triggered disconnects.

That is, it can terminate a communication session only
when it receives SIP BYE requests and not of its own
accord. In Figure 9-28, which uses the topology shown in
Figure 8-27, if the caller decides to end the
communication session, it transmits a SIP BYE message
or an equivalent indication. This indication is
transmitted across all devices along the call path such
that it is received at the IVR device. The IVR device then
acknowledges this request, leading to the termination of
the communication session.
Figure 9-28 A BYE Sent to All Participants in the

Session
Figure 9-29 illustrates a scenario in which the indication
to disconnect the communication session (SIP BYE) is
lost in transit or is not processed properly on one of the
downstream devices due to a transient condition, and as
a result, the state of the session is not synchronized end
to end. This leads devices along the call path that haven't
received the indication for call disconnect to believe that
the communication session is still active. This situation
would also needlessly result in resources being held up
on such devices. To overcome such situations, the IETF
standardized the constructs of RFC 4028 as a
mechanism to determine session freshness.
Figure 9-29 A Transient Condition in Which BYE Is

Not Received by All Session Participants
RFC 4028 defines many different terms. For example, a

session interval is conveyed in the Session-Expires SIP
header. This header conveys the maximum time a
session is considered active or fresh. After this timer
expires, the session is timed out, and all devices that
have agreed on the session interval disconnect the
session. This disconnection is called a session expiration.
The minimum timer is carried in the Min-SE SIP header
and is used to convey the lowest possible value for the
session interval. To modify or extend a previously agreed
upon session interval, a session refresh must occur; it is
carried out by the predetermined refresher. Figure 9-30
illustrates a sample of a session interval being negotiated
between a UAC and a UAS. Next, we break down this
signaling exchange, using Figure 9-30 as a starting point.
Figure 9-30 Session Timer Negotiation Between a UAC

and a UAS
If a UAC wants to engage in a new session with a session

interval, it must first include the timer extension in the
Supported SIP header. A Session-Expires header may
also be included in the initial INVITE request, indicating
a proposed maximum session interval. It is important to
note that the Session-Expires header sent by the UAC is
an offer and a proposed timer. Thus, this value may not
reflect the final timer value negotiated for the session.
The timer extension may be included in the Require
header to indicate that the UAC is requesting that the
UAS also support a session timer to participate in the
session. If the UAC wants to convey a minimum session
interval, the UAC may include the Min-SE header.
Finally, if the UAC wants, it may indicate that it would
like to play the role of refresher for this session by adding
the tag ;refresher=uac to the Session-Expires header. If
the UAC would like to leave this decision up to the UAS,
it may omit this tag from the Session-Expires header.
Example 9-23 shows a sample INVITE request for a new
session requesting a session interval.
Example 9-23 Sample INVITE with Session Interval

Information
INVITE sip:7777@172.18.110.58:5060 SIP/2.0

From: <sip:1024@172.18.110.48>;tag=22968~1992ce86-77a
To: <sip:7777@172.18.110.58>
Call-ID: 82535500-b00171fb-80-306e12ac@172.18.110.48
Min-SE: 900
CSeq: 101 INVITE
Expires: 180
Session-Expires: 1800;refresher=uac
Max-Forwards: 69
The UAS or midstream proxy receiving a request with a

proposed session interval may perform one of many
actions, including the following:
• If the device handling a request with a Require

header contains the timer extension but does not
support session timers or the timer extension, it
may send a 420 Bad Extension response.
• If the device handling a request that contains only a

Supported header with the timer extension and no
Session-Expires header, it may include a Session-
Expires header with its own proposed session value
in the 200 OK response to the INVITE message.
The UAC may then answer this session interval
offer in the ACK.
• If the device handling a request contains a

Supported header with the timer extension and a
Session-Expires header with a value, it may
generate a 200 OK response without a Session-
Expires header (as long as there is not a Require
timer header present). By doing this, the UAS
indicates that there is no defined session interval
for the session.
• Alternatively, if the device handling a request

contains a Supported header with the timer
extension and a Session-Expires header with a
value, the device may include a Session-Expires
with a value equal to or lower than the value
contained in the Session-Expires header sent by the
UAC. This value cannot be lower than the Min-SE
header value indicated by the UAC if the header
was present.
• Finally, as shown in Figure 9-31, if the value of the

Session-Expires header is lower than the desired
minimum session expiration for the device, it may
send a 422 Session Interval Too Small response.
The 422 response must contain a Min-SE header
specifying the minimum timer allowed by the
server rejecting the message. The UAC may attempt
to increase the timer and try the request again or
try another UAS, using local logic.
Figure 9-31 422 Response to a Request Containing a
Session Timer That Is Too Small
The minimum for any session interval is 90 seconds. In

addition, when no Min-SE header is present, the
assumed value is 90 seconds. It is recommended that you
avoid small session timers in order to avoid
oversaturating the network with session refresh
messages. The recommended session refresh timer is
1800 seconds (that is, 30 minutes).
Tip
The Min-SE header cannot be sent in any numbered response except the 422.
Continuing with the example defined in Example 9-23,

let's now examine a response to that offer in Example 9-
24. The UAS has confirmed that it will support a session
interval by responding with a Session-Expires header
containing a value equal to or less than the offer but not
less than the Min-SE in the previous offer. A Supported
header with the timer extension is mandatory when the
UAS is sending a Session-Expires answer. Finally, the
Require header with a timer extension is sent when the
UAS is selecting the UAC as the designated session
refresher. This is indicated by the tag ;refresher=uac on
the Session-Expires header. (More details about this tag
are provided shortly.)
Example 9-24 Establishing a Successful Session Timer
Sent:
SIP/2.0 200 OK
From: <sip:1024@172.18.110.48>;tag=22968~1992ce86-77a
To: <sip:7777@172.18.110.58>;tag=512A088-1C36
Call-ID: 82535500-b00171fb-80-306e12ac@172.18.110.48
CSeq: 101 INVITE
Server: Cisco-SIPGateway/IOS-15.3.3.S
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
As mentioned earlier, the refresher tag can be sent in the

Session-Expires header by either the UAC or the UAS.
This tag indicates the desired refresher for the session
but is ultimately defined and required in the
answer/response from the UAS. Table 9-4 defines the
different permutations and how the value of this tag is
derived when the Supported header in the request
contains or does not contain a timer extension and/or
the refresher value is or is not present in the initial
request.
Table 9-4 UAS Refresher Response Permutation

After a session has been established with a defined
session interval and a designated session refresher, the
timer starts for the session. At some point during the
session—normally at the midway point, as per the RFC
4028 recommendation—the designated refresher sends
either a re-INVITE message or an UPDATE message,
which operates exactly the same as in the earlier
examples in this section. Only a 200 OK response to a
session refresh request can extend the session. Failure to
properly negotiate this session refresh can lead to
premature call failure at the session refresh interval
rather than the session timer expiration. One example of
this type of failure would be the refresher modifying the
SDP through the session refresh. If this modification is
not accepted by the other devices in the session, the call
can be terminated on the spot. Figure 9-32 shows both a
successful session refresh and a refresh that fails due to
the session refresh being rejected.
Figure 9-32 Good and Bad Session Refresh Attempts

Between a UAC and a UAS
The inclusion of a session timer is entirely optional. The
absence of a Session-Expires header means the user
agent wants the session to be infinite, or without a
definite end. The Session-Expires header can be removed
mid-call during a session refresh, which results in further
session refreshing being disabled because the new
session timer is now infinite.
Tip
Any mid-call signaling UPDATE message or re-INVITE message sent for a
purpose other than a session refresh may also contain session timer
parameters. These offers/answers also refresh the session if they occur as per
the specifications defined in RFC 4028.
It is very important for an SBC to have the ability to

interwork and pass session refreshes on all call legs
requiring that the session timer be updated. Failure to
comply can lead to call failures and premature
disconnects. It may also be possible for an SBC to have
one call leg without a session timer and another call leg
with a session timer. An SBC must be able to maintain
session timers across different SIP dialogs in order to
avoid session timeout events and unwanted session
termination.
CUBE can facilitate session interval interworking across

different call legs by default without any configuration.
The command shown in Example 9-25 illustrates how to
enable session refresh interworking on CUBE. In
addition, the Min-Se and Session-Expires timer can be
configured on CUBE if something outside the default
value is required, as shown in Example 9-26.
Example 9-25 Configuring CUBE Session Refresh
voice service voip

sip
session refresh
Example 9-26 Configuring CUBE Session Timers
voice service voip

sip
min-se 1800 session-expires 1800
Managing Mid-call Signaling

The previous sections discuss many different instances in
which mid-call signaling is required for established
communication sessions. Due to the number of different
types of mid-call signaling needed and methods used to
accomplish these tasks, there is a possibility of
interoperability events occurring during mid-call
signaling. An SBC must be able to handle complex mid-
call signaling events across many different call legs and
facilitate signaling interworking for many different types
of mid-call signaling permutations and combinations. An
SBC lacking the ability to properly interwork mid-call
signaling can lead to vendor interoperability, call
failures, and session establishment issues.
By default, CUBE interworks and passes through all mid-

call signaling from one call leg to another. However, in
many cases, passing across all mid-call signaling
messages end-to-end is a hindrance. Reducing the
number of mid-call signaling messages end-to-end often
promotes smooth interoperability across device types
and networks.
CUBE provides the ability to consume all mid-call

signaling and to handle such signaling locally instead of
passing it across to the peer call leg. This flavor of mid-
call signaling is activated using the midcall-signaling
block command. Figure 9-33 illustrates the application
and operation of this command on CUBE.
Figure 9-33 CUBE Blocking All Mid-Call Signaling
While handling all mid-call signaling natively presents a

drastic improvement in terms of reducing the number of
message exchanges end to end and speeding up
transaction establishment times, it may lead to
unexpected behavior and call failures as well. Consider a
situation in which two video-capable endpoints establish
an audio-only session across CUBE by using midcall-
signaling block. With this command, neither of these
devices would be able to escalate the audio-only session
into an audio and video session. This is because CUBE
blocks any and all mid-call signaling. The re-INVITE for
video escalation would be consumed by CUBE, which
would result in no video due to the failure of the video
escalation operation.
Tip
Session refresh messages can also be blocked by the midcall-signaling
block command. It is best to avoid using this command if session interval
timers are being used as these are required to keep a session established.
To provide the flexibility of natively handling most mid-

call signaling while at the same passing across certain
mid-call signaling transactions that need to be
transmitted end to end, CUBE provides the midcall-
signaling passthru media-change command. With
this command in place, only mid-call signaling
transactions that alter the media characteristics of the
communication session are passed through. These
characteristics include codec changes and addition and
modification of media types (for example, audio, video,
image) to the communication session.
Changes to the media direction attribute (a=) and the

connection data information field (c=) of the SDP do not
qualify as sufficient conditions to pass across the
message end to end. This is the case, for example, if a
session is established between two endpoints with
bidirectional G.711ulaw audio and one party places the
call on hold. As described earlier in this chapter, the
device placing the session on hold may send a re-INVITE
message with a=sendonly, while the audio codec remains
G.711ulaw. This re-INVITE message would not be passed
through CUBE with midcall-signaling passthru
media-change present as the change in media
direction does not qualify as an event that needs to be
passed through to the peer call leg. Figure 9-34 details a
scenario with midcall-signaling passthru media-
change in which the original call was established as a
G.711ulaw audio-only session, and the session was then
put on hold briefly before returning. This hold is blocked
for the reasons just explained. Finally, the session is
escalated to include video along with audio. Because
CUBE considers this a valid media change, the re-
INVITE message is passed to the peer call leg.
Figure 9-34 CUBE Passing Mid-call Signaling with

Media Changes
SIP AUTHENTICATION WITH CUBE

CUBE is often located on the edge of the enterprise
network, acting as a demarcation point between the local
enterprise LAN and other public networks. This means
CUBE must be extra cautious when receiving session
establishment requests and must verify that the user
agent initiating a request is a trusted entity, especially if
connected to the public Internet. In a similar vein, CUBE
must be able to respond to authentication requests from
other devices when attempting to establish outbound
sessions. Failure to do either of these actions could result
in call failure or even fraudulent calls being proxied
through CUBE from an unknown source toward the
enterprise or ITSP. The different types of authentication
for inbound and outbound session creation fall into a few
broad categories, as discussed in the next few sections.
Toll Fraud Prevention

The first line of protection enforced by CUBE is toll
fraud. This feature allows you to create a static list of
IPv4 and IPv6 addresses that are permitted to send SIP
requests to CUBE. A dynamic list of IP addresses is also
gathered from the session target commands on
configured dial peers. Every incoming SIP request packet
received by CUBE is evaluated to verify that the source
IP address of the SIP packet was in fact a trusted source.
CUBE evaluates the Layer 3 source IP address rather
than the Via or Contact header as these are much easier
to spoof. If the IP address is not trusted, CUBE silently
drops the packet and never generates a response. You
can change this behavior by removing the command
silent-discard untrusted, as shown in Example 9-27.
Example 9-27 Disabling the Silent Discard of

Untrusted SIP Messages
voice service voip

sip
no silent-discard untrusted
To configure an IP address or range of IP addresses for
trusted authentication checks, use the syntax shown in
Example 9-28. The first two values define a /24 or
255.255.255.0 subnet mask for the 14.50.214.0 and
14.50.215.0 subnets. The last entry defines a single
trusted IP address. CUBE also dynamically adds IP
information for a session target to the trusted list, so you
do not have to configure this. Example 9-28 also shows a
dial peer defined with session target
ipv4:172.18.110.48, which will be added to the trusted
list dynamically, as shown in Example 9-29.
Example 9-28 Defining an IP Trusted List with CUBE
voice service voip

ip address trusted authenticate
ip address trusted list
ipv4 14.50.214.0 /24
ipv4 14.50.215.0 255.255.255.0
ipv4 14.50.216.10
!
To view the current list of statically configured and

dynamically trusted sourced gleaned from dial peer
session target commands, you can issue the command
show ip address trusted list, as shown in Example 9-
29. As you can see, if silent discard is disabled, the call-
reject reason 21 is used to generate a 403 Forbidden SIP
response.
Example 9-29 Trusted List Verification on CUBE

Router# show ip address trusted list
IP Address Trusted Authentication
Administration State: UP
Operation State: UP
IP Address Trusted Call Block Cause: call-reject (21)
VoIP Dial-peer IPv4 and IPv6 Session Targets:
Peer Tag Oper State Session Target

-------- ---------- --------------
11 UP ipv4:172.18.110.48
Configured IP Address Trusted List:

ipv4 14.50.214.0 255.255.255.0
ipv4 14.50.215.0 255.255.255.0
ipv4 14.50.216.10
Dynamic IP Address Trusted List:
IP Address Subnet M
-------------------------------------------- --------
Note
CUBE does not currently support DNS-based authentication for fully qualified
domain names configured on session targets. The resolvable IP addresses
must be statically configured to avoid toll fraud rejection.
Note
Chapter 10 goes into further detail about toll fraud operation for Unified CME
registered SIP phones that will make use of the Dynamic IP Address Trusted
List section of the show ip address trusted list command.
SIP Trunk Registration

CUBE may be required to register with a service provider
and maintain a valid registration status in order to send
calls or receive calls from a provider. Without this
registration in place, the service provider may not deliver
inbound calls to CUBE or may reject outbound calls from
CUBE. CUBE can register to a service provider with sip-
ua or to multiple service providers using voice class
tenant commands. Multi-tenant CUBE configurations
are beyond the scope of this book, but the commands
applied to sip-ua are applicable to voice class tenants.
When configuring SIP registration, you must know some

key information that is required for a valid handshake to
complete:
• The username assigned to the SIP trunk that will be

sent when a challenge response is received
• The password that will be used to create the www-

authenticate response to the challenge
• The SIP target of registration in order to send

REGISTER messages
• The SIP realm that will be used for a

username/password lookup
From a high level, a valid SIP registration looks like the

handshake outlined in Figure 9-35. In this illustration,
CUBE generates a REGISTER request toward the service
provider. The service provider responds with a 401
Unauthenticated response and includes the special
header WWW-Authenticate. This header field is used to
indicate that CUBE should retry the request and supply a
digest authentication response for the given case-
sensitive realm. Noted that for security reasons, the
actual password is not sent in plaintext. SIP leverages the
HTTP digest authentication scheme from RFC 2069 and
2617, which involves generating an MD5 hash using the
inputs from the WWW-Authenticate header along with
locally known values such as the username and
password. With the MD5 digest authentication response
generated, CUBE then sends a new REGISTER message
with the Authentication header containing the MD5 hash
response and other required information for the MD5
hash computation. Upon reception of the new
REGISTER message with the Authorization header, the
service provider performs the same MD5 computations
using the supplied inputs. If the service provider’s MD5
hash calculation matches the value found in the
Authorization header’s response field, the provider
responds with a 200 OK message to confirm that the
trunk is now registered.
Figure 9-35 Valid REGISTER Handshake
To configure registration via sip-ua or a voice class

tenant, simply define the three configuration items
shown in Example 9-30. The registrar command is
used to define the IP address of the registration target.
The authentication and credentials commands allow
CUBE to match the case-sensitive realm of the 401
Unauthenticated message and generate a new
REGISTER using the proper username and password.
Example 9-30 A Sample CUBE Registration

Configuration Along with CUBE Debugging for the Same
Call
### Sample Configuration:
!
sip-ua
registrar ipv4:172.18.110.88
credentials username cisco password 0 cisco123 realm
authentication username cisco password 0 cisco123 re
!
### CUBE Debugging
Sent:
REGISTER sip:172.18.110.88:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.110.58:5060;branch=z9hG4bK3A2

From: <sip:cisco@172.18.110.88>;tag=58551EB-18AA
To: <sip:cisco@172.18.110.88>
Call-ID: 762A1E52-206111EA-FFFFFFFF8024D377-FFFFFFFF8
User-Agent: Cisco-SIPGateway/IOS-17.1.1
Max-Forwards: 70
Timestamp: 1576627755
CSeq: 1 REGISTER
Contact: <sip:cisco@172.18.110.58:5060>
Expires: 3600
Supported: path
Content-Length: 0
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.18.110.58:5060;branch=z9hG4bK3A2

From: <sip:cisco@172.18.110.88>;tag=58551EB-18AA;tag=
To: <sip:cisco@172.18.110.88>;tag=1
CSeq: 1 REGISTER
WWW-Authenticate: DIGEST qop="auth",nonce="Xj504f7xvTnog3

7qBW",realm="kydavis.cisco.com",algorithm=MD5
Content-Length: 0
Sent:
REGISTER sip:172.18.110.88:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.110.58:5060;branch=z9hG4bK3B6

To: <sip:cisco@172.18.110.88>
User-Agent: Cisco-SIPGateway/IOS-17.1.1
Max-Forwards: 70
CSeq: 2 REGISTER
Contact: <sip:cisco@172.18.110.58:5060>
Expires: 3600
Supported: path
Authorization: Digest username="cisco",realm="kydavis.cis

co.com",uri="sip:172.18.110.88:5060",response="49a342f885
8d8824b356b7fec8e2972a",nonce="Xj504f7xvTnog37qBW",cnonce
="A2743717",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.110.58:5060;branch=z9hG4bK3B6

To: <sip:cisco@172.18.110.88>;tag=2
CSeq: 2 REGISTER
Contact: <sip:172.18.110.88:5060;transport=UDP>;expir
Content-Length: 0
Example 9-30 also includes a set of sample debugging
outputs that align with the signaling shown in Figure 9-
35. Notice that the first REGISTER message sent with
CSEQ 1 is rejected by the UAS with a 401 Unauthorized
that contains the WWW-Authenticate header. CUBE
performs a lookup of the available CLI options using the
realm found in this header. The sample configuration in
this case has a matching realm, and the username and
password are leveraged as inputs for the response
generation. (So are other values from the WWW-
Authenticate header, such as the nonce and SIP Request-
URI header. Note that the nonce is a random value
selected by the server to help defend against reply
attacks.) CUBE then sends a new REGISTER message
with CSEQ 2 and includes the Authorization header. This
header includes the generated response value along with
some information the server should use when
performing its own calculation, such as the cnonce
(client nonce), which serves a similar purpose to the
server nonce received in the 401 earlier in the session.
The server returns a 200 OK after the calculation of the
MD5 response matches the response sent in the SIP
header.
Tip
You can use registrar dns: when the service provider uses DNS redundancy.
It is important to ensure proper DNS configuration to enable CUBE to resolve
the FQDN configured on the registrar command. Please refer to Chapter 8,
“CUBE Call Routing and Digit Manipulation,” for information about DNS
Configuration on CUBE.
When troubleshooting REGISTER messages, you can use

the special debugging command debug ccsip non-call,
along with debug ccsip messages, to view SIP
messaging that is not related to calls. The command
show sip-ua register status can be issued to view the
status of all configured registrar indexes. The values can
be observed in Example 9-31. The Line column
references the username or number configured, and the
expires column details how long until a new
reregistration handshake occurs. Finally, the reg column
provides a simple yes or no for registration status.
Example 9-31 Verifying Registration Status on CUBE
CUBE# show sip-ua register status

--------------------- Registrar-Index 1 ------------
Line peer expires(se
================================ ========= ==========
myusername -1 213
SIP Digest Authentication

Like SIP trunk registration, discussed in the previous
section, SIP digest authentication may be requested by a
service provider when attempting to establish a session
through the service provider network. This may occur in
tandem with SIP trunk registration as added security or
as a standalone authentication method. Figure 9-36
illustrates a standard SIP handshake with digest
authentication. The main difference between this
handshake and the one shown in Figure 9-35 is that the
401 Unauthorized message with a WWW-Authenticate
header is sent in response to the INVITE rather than a
REGISTER request. CUBE handles the 401 in this
scenario exactly the same as in the previous example.
CUBE attempts to find username/password information
based on the case-sensitive realm found in the www
WWW-Authenticate header. Once it is found, CUBE
creates a new INVITE message with an Authentication
header. If the username/password is accepted, the call
proceeds normally.
Figure 9-36 A Sample Ad Hoc INVITE Authentication
Handshake
SIP Header–Based Authentication

As mentioned in Chapter 8, some providers require that
specific headers or even specific phone numbers be sent
in the SIP INVITE request. The presence of these
headers is enough to authenticate the call and allow the
session to be established. If a custom header or a specific
formatted header is required, SIP profiles can be
leveraged to modify the header in a SIP INVITE message
sent to the ITSP. (See Chapter 8 for more information on
SIP header modification.)
For inbound INVITE messages sent to CUBE, the host IP

or FQDN in the Request-URI header is examined to
verify that it matches a valid IP address configured on
CUBE. For FQDN entries, the sip-ua command permit
hostname must be configured to perform a valid
lookup. Example 9-32 shows a sample debug ccsip
error command output and the applicable configuration
used to define FQDN permission.
Example 9-32 Debugging and Configuration Showing
FQDN Validation on CUBE
! Debugs
Oct 1 16:20:34.547: //-1/xxxxxxxxxxxx/SIP/Error/sipSP
ReqLine IP addr does not match with host IP addr
! Configuration
sip-ua
permit hostname dns:rtp-cube.ccnpcollab.lab
!
MEDIA INTERWORKING
The types of audio and video codecs supported in a
customer’s Unified CM network often depend on a few
factors:
• The capabilities of the endpoints, such as desktop

phones and soft clients that will be handling calls
• The capabilities of applications that will be tasked

with performing call treatment functions, such as
interactive voice response (IVR) systems, call
queueing, and MOH or other messages played to a
caller
• The capabilities of third-party devices, including

the ITSP or other collaboration systems
Evaluating these three factors for a common audio and

video codec can be a laborious task, and it increases as
the enterprise grows. On the edge of the network, CUBE
can exert control over the signaling exchanged between
endpoints and can influence the negotiation of media.
Taking the interworking one step further, CUBE has the
ability to exert control over the media stream itself and
may perform media interworking functions for RTP
audio or DTMF Relay. The next sections of this chapter
discuss the ways CUBE can accomplish media
interworking at both the signaling and media planes.
Audio Codec Interworking

The most common type of session established through
CUBE is an audio-only media session. Depending on the
country and endpoint settings, various audio codecs
could be advertised. CUBE works to filter unsupported
and unconfigured audio codecs between the inbound and
outbound call legs in order to find a suitable common
codec that satisfies both parties. The next few sections
detail how audio codec interworking is performed on
CUBE.
Dial Peer Codecs

CUBE leverages the dial peer codec command to enable
a single audio codec for support on a dial peer. The
absence of any codec command indicates support for
the default audio codec, g729r8. Example 9-33 shows
how to change the audio codec to g711ulaw in addition to
the supported audio codecs on CUBE. The most common
audio codecs have been highlighted to stand out in this
example.
Example 9-33 Dial Peer Audio Codec Configuration
CUBE(config)# dial-peer voice 1000000 voip

CUBE (config-dial-peer)# codec g711ulaw
CUBE (config-dial-peer)# codec ?
aacld AACLD 90000 bps
clear-channel Clear Channel 64000 bps (No voice ca
g711alaw G.711 A Law 64000 bps
g711ulaw G.711 u Law 64000 bps
g722-48 G722-48K 64000 bps - Only supported

g722-64 G722-64K 64000 bps
g723ar53 G.723.1 ANNEX-A 5300 bps (contains b

g723r53 G.723.1 5300 bps
g723r63 G.723.1 6300 bps
g726r16 G.726 16000 bps
g726r24 G.726 24000 bps
g726r32 G.726 32000 bps
g728 G.728 16000 bps
g729br8 G.729 ANNEX-B 8000 bps (contains built-i

n vad that cannot be disabled)
g729r8 G.729 8000 bps
gsmamr-nb GSM AMR-NB 4750 - 12200 bps (contain
ilbc iLBC 13330 or 15200 bps

isac iSAC 10 to 32 kbps (variable bit-rate)
mp4a-latm MP4A-LATM upto 128 kbps
opus Opus upto 510 kbps
transparent transparent; uses the endpoint codec
When enabling g729 audio codecs on a dial peer, the

command g729 annexb-all should be configured to
allow CUBE to properly handle and interwork different
variants of g729. The configuration in Example 9-34
involves this simple one-line command. If this command
is not present, call setup involving differing variants of
g729 may fail with a 488 Not Acceptable Media and
cause code 65.
Example 9-34 Enabling All g729 Audio Flavors
voice service voip

sip
g729 annexb-all
Table 9-5 is a handy reference guide for the common

audio codec SDP attributes and the configuration
required on a dial peer to enable these codecs. The bytes
command can be postfixed to control the packetization
rate for a given audio codec. For example, codec
g711ulaw bytes 160 sets the packetization rate of
G.711ulaw as 20 ms. The bytes command can be omitted
to assume the default payload size. For a full list of audio
codec packetization rates, bandwidth consumption, and
other information, see
https://www.cisco.com/c/en/us/support/docs/voice/voi
ce-quality/7934-bwidth-consume.html.
Table 9-5 SDP Reference Table for the Dial Peer Codec
Commands
Note
Voice activity detection (VAD) is included in Table 9-5 because it is negotiated
with other audio codecs. To disable VAD, simply remove it with the command
no vad on the applicable dial peer.
The payload types iLBC, iSAC, and OPUS are in the

dynamic range. Refer to RFC 3551 (or Chapter 3) for the
list of static SDP payload types. The values included in
Table 9-5 are the dial peers’ default payload types. OPUS
was added in IOS-XE 17.3 and with that change the rtp
payload-type of 114 was repurposed from the AACLD
audio codec, which is now changed to the rtp payload-
type of 112. Similarly, when configuring the codec
command with OPUS the codec profile must be
configured to define the a=fmtp parameters detailed in
RFC 7587. The codec profile configurations will be sent
when CUBE is responsible for creating an offer, usually a
delayed offer to early offer scenario. In early offer to
early offer scenarios CUBE will pass through the received
a=fmtp parameters from the inbound call leg to the
outbound call leg. The syntax for configuring and
applying OPUS on a dial peer and the applicable codec
profile are shown in Example 9-35. Similar codec profile
configuration can be used to define clock-rate and
fmtp parameters for the other audio codecs such as
AACLD and MP4A-LATM or video codecs such as
H.263+ and H.264.
Example 9-35 OPUS Configuration on CUBE
codec profile 1 opus
fmtp “fmtp:114 maxplaybackrate=16000;sprop-maxcaptur

!
session target dns:rtp-cucm.ccnpcollab.lab
codec opus profile 1
Codec Filtering
As mentioned in Chapter 8, when processing a call,
outbound dial peers are filtered to those that have a
common audio codec for the session as the audio codec
on the inbound dial peer. The offer sent by CUBE using
the selected outbound dial peer contains a filtered list of
common audio codecs. If no matching audio codec is
found and there is no Local Transcoding Interface (LTI)
transcoder, the call fails. We’ll discuss LTI transcoders
further in a moment, but first Figure 9-37 illustrates how
CUBE filters dial peers and codecs when performing
inbound and outbound dial peer matching. The following
steps occur in this process:
Figure 9-37 CUBE Dial Peer and Offer Filtering
Step 1. An SDP offer with g711ulaw, g711alaw, and

g722 is received. There is only one inbound
dial peer in this example to keep things
simple, and this dial peer contains the codec
g711ulaw.
Step 2. Dial peer 1 is selected as the inbound dial

peer because it is the only available incoming
dial peer and also happens to contain a
matching audio codec.
Step 3. The outbound dial peers are all equal in

configuration; that is, they have the same
commands configured. The delta is the audio
codec configuration.
Step 4. After the outbound dial peer match is made,

CUBE filters the original offer list of
g711ulaw, g711alaw, and g722 based on the
inbound dial peer match with g711ulaw that is
configured. This filtering means that only dial
peer 33 with g711ulaw can be selected
because the others do not have a codec
command that matches the inbound dial peer
or inbound offer.
Step 5. An offer that contains only g711ulaw is

created and sent on the outbound call leg.
Step 6. The call proceeds normally.

When a delayed offer INVITE message is received, CUBE
selects the best matching inbound dial peer, as detailed
in Chapter 8, but the outbound dial peer list is still
filtered. For example, if Figure 9-37 showed delayed offer
and dial peer 1 were still selected, the assumed audio
codec would be g711ulaw, as per that inbound dial peer’s
configuration. As a result, Dial Peer 33 is the only eligible
outbound dial peer with g711ulaw. No offer can be sent if
this is a delayed offer interworking call, but if early offer
is being forced with the early-offer forced command,
an offer with g711ulaw would be sent.
Voice Class Codecs

With many different endpoints on a network that have
different capabilities, you might need to accept or send
offers with more than one audio codec. Depending on the
number of codecs, it might be a large administrative task
to create multiple dial peers with a single audio codec
command. Fortunately, CUBE allows you to use the
voice class codec command to create a list of
supported codecs and then apply this list to a dial peer.
Example 9-36 shows how to configure a voice class codec
with two supported codecs. The same audio codecs found
on a dial peer can be found in a voice class codec.
Example 9-36 Voice Class Codec Configuration

Example
CUBE(config)# voice class codec 1

CUBE (config-class)# codec preference ?
<1-24> Priority order (1 = Highest)
CUBE (config-class)# codec preference 1 ?

aacld AACLD 90000 bps
clear-channel Clear Channel 64000 bps (No voice ca
g722-64 G722-64K 64000 bps
g723r53 G.723.1 5300 bps
g723r63 G.723.1 6300 bps
g726r16 G.726 16000 bps
g726r24 G.726 24000 bps
g726r32 G.726 32000 bps
g728 G.728 16000 bps
g729br8 G.729 ANNEX-B 8000 bps (contains bui
g729r8 G.729 8000 bps
gsmamr-nb GSM AMR-NB 4750 - 12200 bps (contain
ilbc iLBC 13330 or 15200 bps
isac iSAC 10 to 32 kbps (variable bit-rat
mp4a-latm MP4A-LATM upto 128 kbps
opus OPUS upto 510 kbps
transparent transparent; uses the endpoint codec
Router(config-class)# codec preference 1 g711ulaw

Router(config-class)# codec preference 2 g722-64
Router# show run | section voice class codec 1

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729br8
Voice class codecs are assigned to a dial peer in much the

same way codecs are assigned with a normal codec
command. Example 9-37 shows the command required
to add a voice class codec to a dial peer. This command
can be used on either inbound or outbound dial peers to
influence answers and offers on CUBE.
Example 9-37 Application of a Voice Class Codec on a

Dial Peer

voice-class codec 1
Just as with the regular codec command, voice-class

codec is used to filter dial peer matching and influence
egress offers from CUBE. Using Figure 9-38 to illustrate
the point, the codecs in Figure 9-37 have been
consolidated into applicable voice class codec
commands:
• The first voice class codec contains g711ulaw and

g711alaw.
• The second voice class codec contains ilbc and isac.
• One of each voice class codec has been applied to

the inbound and outbound dial peers.
Figure 9-38 Incoming Offer and Dial Peer Filtering

with Voice Class Codecs
The following process occurs in Figure 9-38:
Step 1. The inbound call legs offer contains

g711ulaw, g711alaw, and g722.
Step 2. Incoming Dial Peer 2 contains an incoming

match statement and applicable codecs for
the call, so this is selected as the inbound dial
peer.
Step 3. Outbound dial peers are evaluated, based on

the inbound dial peer’s codec support, and
dial peer codec filtering occurs. This is an
easy visual exercise since Dial Peer 22’s voice
class codec does not contain any common
codecs with the offer or the inbound dial
peer. This leaves only Dial Peer 33 as an
eligible outbound dial peer.
Step 4. An outbound offer is created by CUBE, and
the list of codecs in the offer is filtered to
those that match the inbound offer, inbound
dial peer, and outbound dial peer
configuration. Thus g711ulaw and g711alaw
are send in the offer, and g722 is filtered out.
Step 5. The call proceeds normally from here.
CUBE LTI Transcoder

A CUBE equipped with digital signal processors (DSPs)
can leverage the dspfarm feature to perform audio codec
interworking when a mismatch occurs. In contrast to the
SCCP-based dspfarms commonly leveraged by Unified
CM, CUBE-based dspfarms use the Local Transcoding
Interface (LTI) and are often referred to as LTI
transcoders. This type of transcoder registers directly to
CUBE and can be used for transcoding. Transcoding is
the act of converting the audio payload of RTP packets
from one codec to another. An example of transcoding
would be the modification of g711ulaw RTP packets into
g729br8 RTP packets.
The configuration required to register an LTI transcoder

to CUBE is fairly simple:
Step 1. Verify which DSP resources are going to be

used for DSP farming by using applicable
show commands, such as show platform
or show inventory.
Step 2. Configure the DSP voice cards for DSP

farming in order to create a pool of DSP
resources for allocation in later steps.
Step 3. Define dspfarm transcoding profiles with

unique numeric tags:
• Assign or remove audio codecs that the

transcoder will interwork.
• Define the maximum number of sessions
this transcoder will handle at any given
time.
• Associate the transcoder to the CUBE
application.
• Enable the transcoder for registration with

the no shutdown command.
Example 9-38 shows the commands required to register

an LTI transcoder to CUBE. The example first shows the
verification that a DSP is installed on the motherboard
via the show inventory command. Next, the voice card
in slot 0/4, as gleaned from the show inventory
command, must be enabled for DSP farming with the
command dsp services dspfarm. Next, transcoders
can be configured because a virtual pool of DSP
resources has been created. A transcoder has two
different variants, which influence the operation and
capabilities of the transcoder:
• Standard transcoder: Can transcode g711 to any

other type of codec. One call leg must always be
g711.
• Universal transcoder: Can transcode any codec

to any other codec. Does not require either call leg
to use the g711 codec.
In Example 9-38, the universal postfix was omitted from

dspfarm profile 1 transcode, which means it is a
standard transcoder. Each transcoder needs to define the
maximum number of sessions that it can allocate. The
actual number is derived dynamically from an algorithm
that considers the current pool allocation from all other
configured dspfarms and the types of codecs configured
on the transcoder. By issuing a question mark (?) after
maximum sessions, you can see the real-time
maximum for the profile. To adjust the number, you can
either free up resources on other dspfarms or remove
codecs from the dspfarm being configured. Next, the
dspfarm is associated with the CUBE application and
enabled with no shutdown.
The second dspfarm profile in Example 9-38 shows a

similar configuration but with two main differences. The
first is that this is a universal transcoder, as indicated by
the universal postfix. Second, the max sessions
command shows a lower number than the previous
issuing of the command. This shows the new dynamic
number of maximum sessions, taking into account the
first configured dspfarm. The default audio codecs for a
transcoder are g729abr8, g729ar8, g711ulaw, and
g711alaw. New codecs can be added with the command
codec audio-codec on the transcoder or codecs can be
removed by prefixing no before the codec command. The
question mark (?) can be used to view all audio codecs
supported by the dspfarm.
Example 9-38 Configuration Steps for LTI Transcoders
sj-cube# show inventory

NAME: “PVDM subslot 0/4", DESCR: “PVDM4-64 Voice DSP
PID: PVDM4-64 , VID: V02 , SN: FOC22170MPH
sj-cube(config)# voice-card 0/4

sj-cube(config-voicecard)# dsp services dspfarm
sj-cube(config-voicecard)# exit
sj-cube(config)# dspfarm profile 1 transcode ?

universal Profile type Transcoding
<cr> <cr>
sj-cube(config)# dspfarm profile 1 transcode

sj-cube(config-dspfarm-profile)# max sessions ?
<1-48> Number of sessions assigned to this profile
sj-cube(config-dspfarm-profile)# max sessions 10

sj-cube(config-dspfarm-profile)# associate applicatio
sj-cube(config-dspfarm-profile)# no shutdown
sj-cube(config-dspfarm-profile)# exit
sj-cube(config)# dspfarm profile 2 transcode universa

sj-cube(config-dspfarm-profile)# max sessions ?
<1-31> Number of sessions assigned to this profile
sj-cube(config-dspfarm-profile)# max sessions 10

sj-cube(config-dspfarm-profile)# associate applicatio
sj-cube(config-dspfarm-profile)# no shutdown
sj-cube(config-dspfarm-profile)# codec ?
g722-64 G722r64
g729abr8 G.729ab 8000 bps
g729ar8 G.729a 8000 bps
g729br8 G.729b 8000 bps
g729r8 G.729 8000 bps
gsmamr-nb GSMAMR NB codec
ilbc ILBC codec
isac ISAC codec
pass-through Stream Pass Through
Note
codec pass-through is a special configuration that allows for non-audio
codecs to be passed seamlessly through the transcoder. This should be used
when T.38 faxing or video is an option for session negotiation.
With the initial configuration out of the way, Example 9-

39 shows the default codecs found on a dspfarm in
addition to the show dspfarm all command, which has
been truncated here to detail the outputs relevant to
dspfarm 1. This show command confirms that the DSP
is up, active, and associated to the CUBE application.
With these dspfarms in place, CUBE can now perform
media interworking for call legs that do not contain a
common audio codec.
Example 9-39 Verification for LTI Transcoders
sj-cube# show run | section card|dspfarm

voice-card 0/4
dsp services dspfarm
!
dspfarm profile 1 transcode
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
maximum sessions 10
associate application CUBE
!
dspfarm profile 2 transcode universal
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
maximum sessions 10
associate application CUBE
sj-cube# show dspfarm all

Dspfarm Profile Configuration
Profile ID = 1, Service = TRANSCODING, Resource ID =

Profile Service Mode : Non Secure
Profile Admin State : UP

Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP

Total Number of Resources Configured : 10
Total Number of Resources Available : 10
Total Number of Resources Out of Service : 0
Total Number of Resources Active : 0
Codec Configuration: num_of_codecs:4
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
Dspfarm Profile Configuration
[..truncated..]
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID
0/4 1 52.4.0 UP N/A FREE xcode 1

Voice class codecs can be leveraged with LTI transcoders

to extend the functionality and potentially to offer codecs
that are not contained in an initial ingress offer to CUBE.
Take the example in Figure 9-39, which is similar to
Figure 9-38 but with these main differences:
• g729br8 has been added as the third codec in voice

class codec 1.
• An LTI transcoder has been configured and

registered to CUBE.
• The outbound dial peer voice-class codec

commands have the offer-all keyword postfixed.
Figure 9-39 Incoming Offer and Dial Peer Filtering

with an LTI Transcoder and Voice Class Codec
The rest of the configuration in this example is the same

as the configuration we just examined. The ingress offer
contains g711ulaw, g711alaw, and g722.
Step 1. Dial Peer 2 is used as the inbound dial peer

because it has an applicable inbound match
statement and a voice class codec with codecs
applicable in the original offer.
Step 2. Outbound dial peers are examined, and a

matching Dial Peer 33 is selected because
Dial Peer 22 does not contain a common
audio codec.
Step 3. Without the offer-all keyword, CUBE

would simply offer g711ulaw and g711alaw,
and the same behavior shown in Figure 9-38
would occur. Because offer-all is present
and a CUBE LTI transcoder is configured,
g729br8 can also be offered. If this codec is
selected in the responding answer, the LTI
transcoder can be invoked to perform
interworking between the g729br8 outbound
call leg and the inbound call leg. If g711ulaw
or g711alaw is in the answer, no LTI
transcoder is required due to the matching
audio codec on the two call legs.
Codec Transparent and SDP Passthrough

The previous few sections describe how CUBE can be
configured to exert control with codec selection and
perform interworking in the event of mismatches. This
section explores two ways CUBE can allow the endpoints
to perform the negotiation. The first of the two methods
is to use the command codec transparent on VoIP dial
peers. When this command is added to a dial peer, CUBE
does not perform any of the local filtering that influences
audio codec selection that has been discussed up to this
point.
Tip
Only supported audio codecs are eligible for transparent negotiation, and those
that a dial peer does not normally support are filtered regularly.
Figure 9-40 illustrates codec transparent operations

in CUBE. In this example, CUBE interworks an offer and
an answer on both the inbound and outbound call legs.
Figure 9-40 Visualization of Codec Transparent
Operations on CUBE
Step 1. The dial peers are configured with the codec

transparent command. For this example,
Dial Peer 1 is both the inbound dial peer and
the outbound dial peer.
Step 2. An offer is received with g711ulaw, g711alaw,

and g722.
Step 3. The offer also contains a custom SDP

attribute.
Step 4. With codec transparent involved, CUBE

passes the audio codecs through in the offer
sent to the other call leg.
Step 5. CUBE drops (filters out) any custom SDP

parameter and any non-supported CUBE
audio codecs.
Step 6. The answer is passed through, with minimal

interworking by CUBE.
Step 7. Because CUBE is involved in the media

stream, the IP address and port of CUBE
replace the remote endpoint’s IP address and
port for the answer and offer.
In contrast, the command voice-class sip pass-thru

content sdp can be added to a dial peer or globally to
voice service voip and sip-subsection with pass-thru
content sdp to pass all SDP parameters through CUBE
untouched. This includes proprietary SDP attributes and
audio codecs that are not normally supported by dial
peers. CUBE still replaces media IP addresses and ports
with its own IP address and RTP port if flow-through is
configured, but the rest of the SDP is replicated from the
inbound call leg to the outbound call leg. This is a very
good method for passing SDP attributes that CUBE
would otherwise filter from the inbound call leg to the
outbound call leg.
Note
Many CUBE features do not work when SDP passthrough is configured.
Consult the CUBE Configuration Guide, at
xml/ios/voice/cube/configuration/cube-book.html, for all features that have
restrictions with voice-class sip pass-thru content sdp and pass-thru
content sdp.
Figure 9-41 illustrates codec pass-thru content sdp

operations in CUBE. In this example, CUBE interworks
an offer and an answer on both the inbound and
outbound call legs.
Figure 9-41 Visualization of Pass-through Content SDP
on CUBE
Step 1. CUBE is configured with the pass-thru

content sdp command.

and g722.

attribute.
Step 4. With codec pass-thru content sdp,

CUBE passes all SDP through from the
inbound call leg to the other call leg,
including the audio codecs and the custom
SDP attribute.
Step 5. The answer to the offer that CUBE receives

is passed through in full, including any
additional custom SDP attributes.
Step 6. CUBE is still involved in the media stream,

and CUBE’s IP address and port replace the
remote endpoint’s IP address and port for the
answer and offer.
Video Interworking and Suppression

Although most calls through CUBE are audio-only calls,
CUBE does support video session negotiation in concert
with audio. You can configure CUBE’s SIP dial peers to
support h261, h263, h263+, h264, or mpeg4 by
configuring the video codec command, as shown in
Example 9-40. The default payload type for h263+ is 118,
and for h264 it is 119. You can also see the configuration
for these static payload types by using the rtp payload-
type command.
Example 9-40 Video RTP Payload Configuration

video codec h264
rtp payload-type cisco-codec-video-h264 117
rtp payload-type cisco-codec-video-h263+ 118
Note
Unified CM and some video-enabled endpoints use payload type 97 or 126 for
h264 video. Payload type 126 is not used by any dial peer configuration and
can be freely assigned. Unfortunately, 97 is normally used by cisco fax-ack. If
you were to attempt to change CUBE’s RTP payload type for h264 to 97, an
error would appear, stating “ERROR: value 97 in use!” You must first change
cisco fax-ack to an unused value and then change h264 payload type, as
shown here:
rtp payload-type cisco-codec-fax-ack

111
rtp payload-type cisco-codec-video-
h264 97
Because most video payload types are in the dynamic

range (96 to 127), video payload negotiations are often
asymmetric, meaning that one session participant sends
media with payload type A, and the other session
participant sends media with payload type B. When these
scenarios occur, it is best to use the asymmetric
payload command, which allows CUBE to interwork
asymmetric payloads. Example 9-41 show how to enable
this command globally or on a per–dial peer basis. Either
dynamic-codecs or full can be used to enable this
feature for video.
Example 9-41 Dynamic Payload Interworking on CUBE
!
voice service voip
sip
asymmetric payload {dtmf | dynamic-codecs | full}
!
voice-class sip asymmetric payload {dtmf | dynamic-
!
Tip
For some video interworking scenarios, it might be best to use SDP
passthrough, discussed in the previous section, to replicate all video SDP from
the inbound call leg to the outbound call leg with minimal modification by
CUBE.
As indicated earlier, most sessions on CUBE are audio

only. Oftentimes service providers and other equipment
do not support video services. Even the act of advertising
video in an SDP offer can cause calls to fail. As a result,
CUBE has a command to perform audio+video to audio-
only interworking between inbound and outbound call
legs. Example 9-42 shows how to use the audio forced
command globally or on a per–dial peer basis to remove
all SDP m= lines except m=audio and m=image (fax)
from an SDP offer generated by CUBE. The call leg that
offered video receives an answer with the m=video port
set to 0, indicating that video has been disabled. This
command can also be leveraged to drop m=application
lines on CUBE.
Example 9-42 Video Suppression on CUBE
!
voice service voip
sip
audio forced
!
voice-class sip audio forced
!
Media Flow-Through Versus Media Flow-Around

At the media plane, CUBE operates in two distinct ways:
• Media flow-through: With this configuration,
CUBE is involved with the media path, and packets
are sent to CUBE, which performs a Layer 2/3
header rewrite and optional codec manipulation via
an LTI transcoder before retransmitting the media
packet to the next-hop destination. This is the
default behavior of CUBE via the command media
flow-through configured under voice service
voip.
• Media flow-around: With this configuration,

CUBE advertises the remote endpoint’s media
information as the source and destination. As a
result, CUBE is no longer involved in the media
flow post-call establishment. This can be
configured with the command media flow-
around in voice service voip. This is different
from codec transparent and SDP passthrough,
discussed previously, because CUBE still influences
media negotiation as per codec filtering, as
discussed up to this point; the main difference is
that the IP address and port are those of the remote
endpoint and not those of CUBE.
Figure 9-42 illustrates these two operational modes. In

the media flow-through illustration, a SIP session is
established between the IP phone, Unified CM, CUBE,
and the service provider. When the call connects, the
media path is between the IP phone, CUBE, and the
service provider. The IP phone sends and receives RTP
packets to/from CUBE as per the SDP offer/answer, and
so does the ITSP. As a result, both parties send and
receive packets with CUBE in the middle of the media
stream.
Figure 9-42 CUBE Media Flow-Through Versus Flow-
Around
In contrast, the media flow-around illustration shows the

same devices involved in the call setup. The main
difference is that CUBE does not advertise itself as a
source or destination for media in the SDP offer/answer
on either call leg. This results in the IP phone and ITSP
now sending and receiving media. Before enabling
media flow-around, you must confirm that the ITSP
has valid IP routing to the IP phone’s network and that
the IP phone’s network has valid routing to the ITSP.
Any routing issues may lead to one-way or no-way audio
situations. In addition, you willingly give up the ability
for CUBE to perform transcoding and transrating
because CUBE is no longer involved in the session’s
media.
Figure 9-43 further illustrates how media flow-around

affects SDP:
Figure 9-43 Offer/Answer with Flow-Around
Step 1. CUBE is configured with commands media

flow-around and codec g711ulaw on the
dial peers.

and g722.

attribute.
Step 4. Due to the media flow-around command,

CUBE advertises the remote endpoint’s IP
address and port rather than an IP address
and port on CUBE.
Step 5. CUBE still performs codec filtering, and due

to the codec g711ulaw command, only
g711ulaw is advertised.
Step 6. The custom SDP parameter and any non-

supported CUBE audio codecs are dropped.
Step 7. The remote endpoint’s IP address and port

contained in the answer to the offer
generated by CUBE are used in the answer
sent by CUBE rather than an IP address and
port from CUBE.
Tip
media flow-around and pass-thru content sdp can be leveraged to ensure
that CUBE does not perform codec filtering for a call that does not traverse
CUBE at the media plane. In this situation, all SDP information, including IP
address and port, are passed through CUBE with no modification.
Music on Hold
This chapter has already briefly discussed the concept of
MOH and how it applies within the context of hold
events. The hold music is an audio file played to a holdee
from a MOH server for the duration of a hold event.
Without MOH, the holdee would experience silence, or
dead air, for the duration of the hold event. Many
consider complete silence undesirable from the
perspective of user experience, and therefore MOH is a
widely deployed feature.
The audio file for MOH can be anything an administrator

or an organization desires, from simple beeps or a music
file to live radio or informational announcements, such
as prerecorded sales information, stock prices, or even
the current weather forecast. This information is
delivered over the unicast audio stream opened up in the
hold event discussed earlier in this chapter.
There are two methods for streaming MOH over a

network from the MOH server to the holdee: unicast
MOH and multicast MOH.
Unicast MOH is not too different from audio for a

regular call. The main difference is that a normal call has
bidirectional audio, while with unicast MOH, audio/RTP
flows in one direction: from the unicast MOH source to
the SBC and from the SBC to the upstream devices and
ultimately to the holdee.
Previous sections in this chapter depict unicast MOH

establishment between CUBE and Unified CM. First, the
call is established with bidirectional audio. Then Unified
CM makes the established audio stream inactive. Unified
CM then renegotiates media and inserts the IP address
and codecs of the unicast MOH server. (Figure 9-11
details how an SBC negotiates the same information on
the other call leg or consumes the mid-call signaling.)
After the hold and unicast MOH negotiation is complete,
the RTP packets received from the unicast MOH server
are forwarded to the next hop and all other upstream
devices.
The implementation of multicast MOH is slightly more

complicated than its unicast counterpart. The SIP
signaling for the call establishment, hold, and multicast
MOH negotiation follows the same sequence as for a
unicast MOH session, but the semantics of how SDP is
encoded in the offer/answer and the way MOH is served
up by the network differ.
Note
If Unified CM is involved, the Cisco-proprietary SDP media attribute a=X-cisco-
media:mmoh is present rather than a=X-cisco-media:umoh.
Tip
A device advertising a multicast address in SDP always sends a=recvonly in
SDP, as per RFC 3264. The answer to this offer should always mirror the
answer; for example, the answer may contain media direction attributes that
are the same as those of the offer (a=recvonly).
The complexity of multicast MOH mainly derives from

the underlying requirements of multicast. The first is
that CUBE and the LAN/WAN must be properly
configured for IP multicast capabilities in order to route
multicast traffic properly. In addition, CUBE may be
required join the multicast group specified in the SDP of
the hold event and receive multicast RTP packets. The
MOH server may also join this multicast group and will
send multicast RTP, which is then replicated to all
participants of the multicast session.
The second item is the inability of devices over the

service provider network to join multicast groups scoped
within an enterprise. Thus, CUBE must be able to
convert the received multicast RTP into unicast RTP for
transmission to the service provider network. CUBE
requires only a few configuration lines to enable
multicast-to-unicast conversion. These commands are
detailed in Example 9-43. Figure 9-44 illustrates CUBE
receiving multicast RTP packets from a multicast MOH
audio source and then converting them into unicast RTP
packets to be sent for transport over the ITSP network.
Example 9-43 Multicast MOH–to–Unicast MOH

Conversion Commands
!
ip multicast-routing distributed
!
ccm-manager music-on-hold
!
interface GigabitEthernet0/0/0.249
ip pim sparse-dense-mode
!
Tip
Underlying LAN and network infrastructure configuration to facilitate Multicast
PIM on Layer 3 devices and IGMP multicast for Layer 2 devices are not
covered in this book. In addition, the type of PIM configured on the CUBE
interfaced is dependent on the type of LAN multicast implementation.
Figure 9-44 Multicast MOH–to–Unicast MOH

Conversion on CUBE
Troubleshooting unicast MOH or multicast MOH issues

always starts with verifying the signaling involved in
setting up the unicast MOH or multicast MOH session by
running debug ccsip messages and debug ccm-
manager music-on-hold all. In addition, you can use
show commands such as show call active voice
compact and show voip rtp connections, which
display RTP connections between CUBE and the MOH
server or multicast IP address specified in the SIP
signaling. Both IOS and IOS XE use the command show
ccm-manager music-on-hold, which displays MOH
packets replicated from the ingress call leg to the egress
call leg. IOS XE can use the command show platform
hardware qfp active feature sbc mmoh global,
which shows multicast MOH packets received and
passed to the ccm-manager application. Finally, using a
packet capture (PCAP) is a great way to determine
whether packets are being received from a MOH server
or multicast IP address on the ingress CUBE interface.
Tip
With IOS XE, an IP PIM command must be defined on both the ingress and
egress Layer 3 interface, or the multicast MOH–to–unicast MOH conversion
will not occur. Without an IP PIM command on the egress interface, the output
of show ccm-manager music-on-hold displays 0 packets received, and the
output of show platform hardware qfp active statistics drop shows the
multicast MOH RTP packets dropped with the reason “UnconfiguredIpv4Fia".
Tip
When integrating Unified CM with an IOS XE CUBE, the CallManager service
parameter Duplex Media Streaming should be set to True. With this setting
enabled, Unified CM advertises a valid MOH RTP port to CUBE rather than the
dummy RTP port 4000. This is required for IOS XE source port validation
checks, which drop the MOH RTP stream when port 4000 is used.
DTMF Interworking
The ability to press a button on a device to signal an
input that is seamlessly transmitted across many
different dispersed networks and delivered to a system
that analyzes the input to perform actions with the call is
one of the most important aspects of almost every
session established in modern networks. These input
signals take the form of dual-tone multifrequency
(DTMF) and, as noted in Chapter 3, “VoIP Protocols:
RTP, RTCP, and DTMF Relay,” can be conveyed in many
different ways. Due to the number of DTMF signaling
mechanisms, CUBE must have the ability to perform two
forms of DTMF interworking:
• Interwork signaling to ensure proper

negotiation of DTMF on the inbound and
outbound call legs of a session: If CUBE does
not properly perform an offer/answer with DTMF,
there may be no DTMF at all for a given session.
• Interwork differing DTMF types when a

DTMF mismatch occurs to ensure the
proper replay and transmission of a
received digit from one DTMF type to
another: If CUBE fails to interwork DTMF from
one call leg to another, the system waiting for user
input may receive inputs in a format unknown to
that device, which results in nothing happening
when a user presses keys.
The first of these interworking scenarios starts with the

administrator’s configuration. DTMF can be defined on a
VoIP dial peer as shown in Example 9-44. The dtmf-
relay command allows an administrator to create an
ordered list of DTMF preferences on a dial peer. The
question mark (?) command can be used to view all the
supported DTMF types. A dial peer with no DTMF relay
configuration assumes the default DTMF relay
configuration, which is raw in-band audio. As discussed
in Chapter 3, this can be problematic when using
compressed audio codecs. Therefore, most Unified CM
deployments use RTP-NTE, which follows the RFC 2833
and RFC 4733 standards for DTMF. When interworking
calls with Unified CM, SIP-KPML can be leveraged as an
out-of-band (OOB) DTMF solution.
Example 9-44 Dial Peer DTMF Relay Configuration

Example
sj-cube(config)# dial-peer voice 1000 voip
sj-cube(config-dial-peer)# session protocol sipv2
sj-cube(config-dial-peer)# dtmf-relay ?
cisco-rtp Cisco Proprietary RTP
h245-alphanumeric DTMF Relay via H245 Alphanumeric
h245-signal DTMF Relay via H245 Signal IE
rtp-nte RTP Named Telephone Event RFC 2833

sip-kpml DTMF Relay via KPML over SIP SUBCRIB
E/NOTIFY
sip-notify DTMF Relay via SIP NOTIFY messag

sj-cube(config-dial-peer)# dtmf-relay rtp-nte sip-kpm
sj-cube(config-dial-peer)# do show run | section dial
dtmf-relay rtp-nte sip-kpml sip-notify
When configuring or troubleshooting DTMF relay, you

should work to confirm the DTMF capabilities of all
endpoints that will send calls through CUBE. If possible,
a common DTMF relay type should be used so that
CUBE can receive DTMF of the common type and
replicate it to the other call leg with minimal effort.
However, for instance when different DTMF relay types
must be configured or negotiated, Table 9-6 provides a
good starting point for the types of built-in DTMF relay
interworking options CUBE supports for SIP-to-SIP
calls. To view DTMF negotiation, debug ccsip
messages should be used to verify the offer/answer for
DTMF negotiation. The command debug voip rtp
session name-event does not work reliably in IOS XE
due to the change in architecture, so you should use a
PCAP to view RTP-NTE DTMF.
Table 9-6 SIP DTMF Relay Interworking Matrix

Tip
SIP-INFO has been omitted from Table 9-6. CUBE supports only SIP-INFO to
RTP-NTE conversion and does not support the opposite.
Because RTP-NTE DTMF utilizes a dynamic payload

type, there is a possibility of asymmetric payload types.
In essence, one party sends RTP-NTE DTMF with one
payload type while receiving another payload type for
RTP-NTE DTMF. The command asymmetric payload
dtmf can be used when asymmetric DTMF interworking
is required. If both video and DTMF are asymmetric, you
can use the command asymmetric payload full to
enable the full suite of asymmetric payload interworking
on CUBE.
When H.323 is used in conjunction with SIP call legs,

DTMF can only be interworked in the ways illustrated in
Table 9-7.
Table 9-7 H323-SIP DTMF Relay Interworking Matrix
Troubleshooting CUBE Media

When troubleshooting media issues with CUBE, you
should always work to verify that the session
establishment messages are negotiating the correct
media parameters in addition to the inbound and
outbound dial peers being selected, since the dial peers
can exert control over the audio and video codec
negotiation. You can use debugging commands such as
debug ccsip messages and debug voip ccapi inout
to look at the SDP offer/answer on the inbound and
outbound SIP call legs through CUBE, and you can use
CCAPI debugging to see the actual dial peers being
selected.
If troubleshooting an active call, you can use show

commands such as show call active voice compact,
show call active voice brief, and show voip rtp
connections to view the media information negotiated
by the signaling in real time. In IOS XE, the command
media bulk-stats should be enabled under voice
service voip for sent (TX) and received (RX) RTP
packet statistics in the show call active voice brief
command. This command is disabled by default in IOS
XE due to the possibility of adversely affecting
processing performance by counting every RTP packet
sent and received by CUBE when there are many calls.
You should examine the output of the show commands
to confirm that there are no more than 100 active calls
before using media bulk-stats.
Embedded packet captures (PCAPs) can be leveraged by

IOS XE CUBE to gather packets that are sent and
received by physical interfaces. Packet captures can
provide a precise look into exactly what is on the
network. Packet captures can also be used to play back
the RTP and confirm whether a given network segment is
introducing any issues into the RTP stream. You can use
packet captures at the source and destination to verify
that packet loss, jitter, and delay fall within the
acceptable g114 standards:
• One-way packet loss less than 1%
• One-way delay less than 150 ms
• One-way jitter less than 100 ms
There are several additional factors you can examine

when troubleshooting media issues with CUBE. Media
issues on the network come in many shapes and sizes.
When troubleshooting CUBE media issues, attempt to
answer the following questions with debug and show
commands and with packet captures:
• Is the issue intermittent or reproducible on

demand? Intermittent issues may require a more
in-depth analysis to find the exact cause of the
issue, while issues that are easily reproducible tend
to be easier to troubleshoot because samples can be
provided on demand. For example, for no-way or
one-way audio issues that are reproducible on
demand, you only need to establish an active call
and then use debug and show commands to
quickly determine where the audio is being lost. On
the other hand, for an intermittent one-way or no-
way audio situation, you might need to enable
Switched Port Analyzer (SPAN) at various points in
the network and send the results to a local
collection server along with applicable debugging
collected via syslog for a more granular analysis.
Typically you need more than one sample of an
intermittent audio issue in order to find a trend in
the data.
• What is the exact symptom of the audio

quality or media issue? Properly defining the
audio quality symptom in the beginning of a
troubleshooting effort will guide your
troubleshooting efforts greatly. For example,
choppy audio might be due to packet loss on a given
network segment, and your troubleshooting for this
issue would be different from troubleshooting for
one-way audio or no-way audio, which might
indicate improper packet routing, dial peer binding,
or even access control list (ACL)/firewall
permission issues. Understanding the exact
symptoms of an audio quality issue will help reduce
your troubleshooting efforts.
• Is media flowing through CUBE or around

CUBE? If CUBE is not involved in the media flow,
the media troubleshooting needs to be done on the
transit network and the endpoints.
• Which devices are involved in the call? You

can use debug and show commands to gain a
proper understanding of the devices involved in the
media path. The IP address and port information
negotiated during a session can be used to filter
packet captures, check permission rules, and check
packet routing. Similarly, you should verify that the
correct IP address for CUBE is being advertised to
the remote endpoint. A global or dial peer binding
misconfiguration can cause an incorrect IP address
to be presented. (See Chapter 8 for more
information.)
• Which media codec is being negotiated, and

is this the correct one? A quick verification that
the desired media codecs are being negotiated is
very beneficial to understanding the media issue.
For example, if g711ulaw is being negotiated rather
than g729 and the LAN has not been properly
optimized, there may be a potential for
oversubscribed links, leading to packet loss.
• Are there any media resources being

allocated? LTI or SCCP media resources may be
invoked by CUBE or Unified CM to perform media
interworking. The inclusion of these devices
changes how packets route through the network
and adds another variable to the equation. You
should work to verify whether media resources are
involved and whether they are the correct media
resources for the job. Invoking media resources
from another geographic region can lead to RTP
packets taking a different network path, which may
not be optimized for voice traffic. If possible, work
to eliminate variables by removing the media
resource from the media path and checking to see if
the issue remains.
• Is quality of service (QoS) being leveraged,

and are RTP packets being marked and
queued accordingly? RTP packets should be
marked with the Differentiated Services Code Point
(DSCP) value Expedited Forwarding (EF) so that
QoS and policing policies on the network can treat
them with priority. The lack of markings or an
incorrect QoS strategy could lead to the
mishandling of RTP packets and various audio
quality issues.
• What is the bandwidth of the interfaces

being used? The type of links and the bandwidth
of the links should be examined in conjunction with
the total traffic expected. Oversaturation can lead
to a variety of audio quality issues. Refer to the
following site for more information on VoIP call
bandwidth calculation:
https://www.cisco.com/c/en/us/support/docs/voi
ce/voice-quality/7934-bwidth-consume.html.
• Are there any access control lists (ACLs) on

the interfaces that are used for media? The
IP addresses and ports for RTP media should be
allowed through ACLs to avoid being dropped on
the ingress or egress of an interface. For example, if
you see packets in a packet capture but do not see
packets incrementing in show call active voice
brief, you need to examine the interface for errors.
You can also use show platform hardware qfp
active statistics drop to see the ACL drop reason
increasing the packets per second for the active
session with media issues.
• Are there any local zone-based firewalls

(ZBFWs) or other firewalls in the media
path? Similarly, incorrect zone pairings or
firewalls that have not allowed the proper media IP
addresses and ports can cause audio issues. With a
ZBFW, you can examine the ingress and egress
zone pairing to ensure that packets are allowed via
the command show zone-pair security source
inbound-zone destination outbound-zone. You
can also use show platform hardware qfp
active statistics drop to verify why the number
of packets per second is increasing for the active
session with media issues.
• Is IP routing on CUBE configured to send

the packet out the correct interface toward
the remote destination, as instructed by the
signaling? For no-way and one-way audio issues,
you should examine the packet routing to verify
that packets are being sent to the remote
destination negotiated by the signaling. This
includes verifying both the next-hop IP address for
Layer 3 routing and the egress interface. You can
use commands such as show ip route a.b.c.d and
show ip cef a.b.c.d, where a.b.c.d is the remote IP
address toward which CUBE has been instructed to
send packets. For the reverse direction, ensure that
the media binding, if configured, is correct.
Incorrect media binding configurations can cause
CUBE to advertise the incorrect IP to a remote
device, which in turn results in the remote device
sending packets to an IP that is not routable from
their local subnet. Refer to Chapter 8 for more
information about both application signaling and
media binds on CUBE.
There is not a one-size-fits-all approach to
troubleshooting media issues. The topic alone could fill
an entire Cisco Press book. This information presented
in this chapter is by no means exhaustive but does
provide a good starting point for any media issue. With a
bit of diligent troubleshooting and by systematically
working through the aforementioned questions, you
should be able to narrow the scope of an issue
significantly.
OTHER CUBE FEATURES

CUBE has many other features that you can use for
interworking and interoperability for session
establishment at both the signaling and media planes—
for example, CUBE high availability, CUBE security with
TLS/SRTP, CUBE call admission control, CUBE call
recording through dial peers, and XMF Unified CM API
services. These topics are not included in the CLACCM
300-815 certification blueprint, so they are not included
in this book. For a fully comprehensive list of features,
see the Cisco CUBE Configuration Guide, at
xml/ios/voice/cube/configuration/cube-book.html.
REFERENCES
Press, 2018.
“Cisco Unified Border Element Configuration Guide,”

xml/ios/voice/cube/configuration/cube-book.html
“Voice Over IP - Per Call Bandwidth Consumption,”
https://www.cisco.com/c/en/us/support/docs/voice/
voice-quality/7934-bwidth-consume.html
RFC 2069, “An Extension to HTTP : Digest Access

Authentication,” https://tools.ietf.org/html/rfc2069
RFC 2617, “HTTP Authentication: Basic and Digest

Access Authentication,”

Tones and Telephony Signals,”

RFC 3262, “Reliability of Provisional Responses in the

Session Initiation Protocol (SIP),”
RFC 3264, “An Offer/Answer Model with the Session

RFC 3311, “The Session Initiation Protocol (SIP)

UPDATE Method,” https://tools.ietf.org/html/rfc3311
RFC 3515, “The Session Initiation Protocol (SIP) Refer

Method,” https://tools.ietf.org/html/rfc3515
RFC 3551, “RTP Profile for Audio and Video

Conferences with Minimal Control,”
RFC 3892, “The Session Initiation Protocol (SIP)

Referred-By Mechanism,”
RFC 4028, “Session Timers in the Session Initiation
Protocol (SIP),” https://tools.ietf.org/html/rfc4028

Tones, and Telephony Signals,”
RFC 7587, “RTP Payload Format for the Opus Speech

and Audio Codec,” https://tools.ietf.org/html/rfc7587



MEMORY
chapter and complete the tables and lists from memory.
to check your work.
DEFINE KEY TERMS

transferee
transfer target
transferor
Chapter 10. Unified CME and SRST
• Introduction to Unified CME and Unified

SRST: This section provides an overview of
Unified CME operation and Unified SRST
operation with Unified CM for remote site
redundancy.
• Unified CME Initial Configuration: This

section discusses the items required to perform the
initial configuration and registration of SIP IP
phones with a Unified CME system, including
manual and auto-registration of IP phones.
• Unified CME Dial Design: This section covers

the main items required to understand and deploy
a Unified CME dial plan, including Unified CME
virtual dial peers and a refresher on IOS call
routing for SIP trunks with Unified CME.
• Unified CME Call Coverage Features: This

section details how to implement Unified CME
features such as voice hunt groups, multicast
paging, and call park.
• Survivable Remote Site Telephony (Unified

SRST): The chapter ends with an overview of
Unified SRST, along with the applicable
configurations and items required to verify that the
feature is working as expected.

exam topics:
• 2.1 Configure Cisco Unified Communications

Manager Express for SIP phone registration
• 2.2 Configure Cisco Unified CME dial plans
• 2.3 Implement toll fraud prevention
• 2.4 Configure these advanced Cisco Unified CME

features
• 2.4.a Hunt groups

• 2.4.b Call park
• 2.4.c Paging
• 2.5 Configure SIP SRST gateway
When deploying Unified Communications Manager

(Unified CM) in an enterprise, there are various types of
sites or locations, with varying sizes and user
requirements. One of the most common types of
locations is the enterprise remote branch office. Cisco
Unified Communications Manager Express (Unified
CME) provides call processing to Cisco IP phones for
distributed enterprise branch office environments and
retail deployments. Even branch offices within the same
enterprise can have different communication needs and
requirements. Unified CME meets this need by providing
local call control, mobility, and conferencing alongside
data applications on Cisco Integrated Services Router
(ISR) devices.
As an enterprise extends its IP telephony deployments

from central sites to remote branch offices and
teleworkers, a critical factor in achieving a successful
deployment is the capability to support backup call
control at these remote locations. Cisco Unified
Survivable Remote Site Telephony (Unified SRST) and
Cisco Unified Enhanced Survivable Remote Site
Telephony (Unified E-SRST) provide solutions for
supporting redundant call control in remote branch
offices and the homes of teleworkers for Unified CM
registered endpoints.
This chapter covers topics related to Unified CME and
Unified SRST configuration, implementation, and
troubleshooting that are important to the CCNP
CLACCM 300-815 exam. It discusses the initial
configuration of SIP IP phones that register with Unified
CME, provides a refresher on IOS call routing as it
pertains to Unified CME (including Unified CME toll
fraud prevention features), and examines a select few
supplementary call features used by these IP phones. The
chapter closes with an overview of Unified SRST and the
configuration required for and the IOS Unified SRST
gateway. This chapter includes relevant configuration
snippets and debugging output to illustrate the topics
covered.

Table 10-1 “Do I Know This Already?” Foundation

Topics Section-to-Question Mapping
1. Which Cisco product provides backup call agent
redundancy to remote branch IP phones in the event
of a WAN failure?
a. Unified CM
b. Unified CME
c. Unified SRST
d. Cisco Unified Border Element
2. Which configuration commands are required for

registering SIP IP phones with Unified CME? (Choose
three.)
a. max-dn
b. max-ephone
c. max-pool
d. source-address
e. ip source-address
3. For each of the following descriptions, provide the

appropriate IOS command.
4. When utilizing SIP IP phone auto registration with

Unified CME, what is the first file provided by
Unified CME to the IP phone with the MAC address
AAAA.BBBB.CCCC via TFTP?
a. CTLAAAABBBBCCCC.tlv
b. ITLAAAABBBBCCCC.tlv
c. ITLFile.tlv
d. SEPAAAABBBBCCCC.cnf.xml
e. XMLDefault.cnf.xml
5. Which show command can be used to view

information about Unified CME virtual dial peers
created for SIP IP phones?
a. show running-config
b. show voice register global
c. show voice register dn
d. show voice register pool
6. Which command is required before registered SIP IP

phones can call other SIP IP phones or endpoints
behind a SIP trunk?
a. ip address trusted list
b. allow-connections sip to sip
c. registrar server
d. telephony-service
7. When implementing voice hunt groups with Unified

CME, which operational mode starts ringing all hunt
group members at the same time?
a. Sequential
b. Peer
c. Longest idle
d. Parallel
8. Which SIP message is used to instruct SIP IP phones

to join a specific multicast paging IP address and port
in order to receive an inbound page?
a. INVITE
b. NOTIFY
c. REFER
d. UPDATE
9. Which actions are performed to park a call in a basic

call park slot and then pick up that call? (Choose
two.)
a. Click the Transfer softkey and transfer the call to
the call park extension.
b. Click the Park softkey and let the system select a

park slot.
c. Dial the applicable feature access code (FAC) along

with the call park extension to retrieve the parked
call.
d. Dial only the call park extension to retrieve the

parked call.
10. Which of the following supplementary features does

Unified Enhanced SRST (E-SRST) provide? (Choose
two.)
a. Shared-line support
b. Voice hunt groups
c. Voicemail
d. LDAP directory services
11. When configuring Unified SRST parameters on

Unified CM, which enterprise parameter is used to
define how long an IP phone remains registered with
the Unified SRST gateway before re-attempting
communication with the Unified CM cluster?
a. Maximum Hold Duration Timer
b. Connection Monitor Duration
c. Hold Reversion Duration
d. Gateway Poll Timer

12. Which voice register global commands are required
when configuring Unified SRST on an IOS gateway?
(Choose two.)
a. max-ephone
b. max-pool
c. max-dn
d. mode cme
e. source-address
FOUNDATION TOPICS
INTRODUCTION TO UNIFIED CME AND

UNIFIED SRST
Many enterprises have remote branches that interface
with the enterprise over a wide area network (WAN)
connection. With this deployment option, Cisco Unified
Communication Manager (Unified CM) endpoints may
register with a remote Unified CM server over the WAN
connection, as shown in Figure 10-1.
Figure 10-1 Remote Phone Registering to the

Enterprise over the WAN
Depending on the size of the remote branch, there may

be alternative deployment options that limit WAN
utilization and dependency. For example, these locations
may already have a Cisco IOS gateway performing
routing, security, or other function, and the same Cisco
ISR device can be leveraged to run Unified CME to
provide local call agent and PSTN interoperability. In
this scenario, the remote IP phones only use the WAN
connection when calling endpoints on the enterprise, as
Figure 10-2 Remote Unified CME with Optional WAN

Connection to the Enterprise
If a WAN and Unified CM deployment option is

implemented, the local IOS gateway can still offer
Unified SRST functionality. With Unified SRST, the local
ISR acts as a backup call agent, and in the event of WAN
outage, remote branch IP phones can register to the IOS
Unified SRST gateway and continue with limited
functionality, thus enabling continued business
operation and customer satisfaction. Figure 10-3
illustrates the same deployment as Figure 10-2 except
that the IP phone registers to Unified CM, with the
Unified SRST gateway acting as a backup call agent in
the event of an unexpected outage.
Figure 10-3 Remote Phone Registering to Enterprise

with Backup Unified SRST Gateway
UNIFIED CME INITIAL
CONFIGURATION
Unified CME operates in IOS or IOS XE voice gateways
on the ISR series of hardware routers or the Cloud
Service Router (CSR) virtual machine. As a result, the
Unified CME version is directly tied to the IOS version
running on the platform. A single Unified CME system
can register a finite number of SIP or SCCP IP phones,
with the limiting factor being the hardware platform. For
example, the largest ISR device that can run Unified
CME at this writing is the ISR 4461, which can register
450 IP phones and manage 1200 directory numbers
(DNs). You can configure Unified CME to provide many
supplementary call features, including voice hunt groups,
call park, paging, ad hoc conferencing, Music on Hold,
Single Number Reach, Extension Mobility, and call
queuing. Unified CME also provides access for enterprise
IP phones to connect with public networks and external
parties by way of traditional analog, digital, and IP
connections; this chapter focuses on SIP trunks. As you
read, you might notice that many of the dial plan and call
routing commands used with Unified CME are like those
used with CUBE, as described in earlier Chapter 8,
“CUBE Call Routing and Digit Manipulation.”
Before starting a fresh Unified CME configuration, you

should check the IOS–to–Unified CME compatibility
matrix to verify the Unified CME version running on a
given IOS version. For example, IOS XE Version 16.12.1a
runs Unified CME Version 12.6. The given Unified CME
version dictates the supported IP phone models and even
the minimum supported firmware version that should be
running on a given endpoint. Knowing this information
before starting a deployment is crucial to avoiding issues
with version and hardware incompatibility that might
result in an IP phone not registering to Unified CME and
losing valuable time during the implementation phase of
a project. Be sure to consult the Unified CME roadmap to
verify when specific features have been implemented to
ensure that the right version has been selected to meet
your business needs.
Note
Unified CME with the CSR platform supports only SIP IP phones and has a
different feature set than the Unified CME counterpart that runs on ISR
hardware. Refer to the official Virtual Unified CME documentation for more
information about CSR features.
The Unified CM IOS Matrix can be found here:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/requirements/gui
de/33matrix.html
The Unified CME Roadmap can be found here:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configurat
ion/manual/cmeadm/cmeroad.html
Virtual CME guide can be found here:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configurat
ion/manual/cmeadm/cmevir.html
When you perform the initial configuration of SIP

Unified CME, you need to complete a sequence of action
items to enable the successful handling of SIP
REGISTER requests from IP phones and, ultimately,
successful registration of SIP IP phones:
• Global SIP application configuration: Global

SIP parameters for registration and SIP-to-SIP
calling should be enabled in the voice service
voip configuration section. The registrar server
command is required to allow a SIP application to
process SIP REGISTER requests; without it,
incoming SIP REGISTER requests from IP phones
will be rejected with a “SIP/2.0 503 Service
Unavailable - registrar unavail or not enabled”
error. In addition, the allow-connections sip to
sip command is required to allow SIP IP phones to
call other SIP IP phones and place or receive calls
from a service provider SIP trunk. Omitting this
command results in a “404 Not Found” SIP error
with Q.850 cause code 3 (indicating incompatible
protocols) when attempting a SIP-to-SIP call.
With older versions of Unified CME, the IP address

range of the IP phones should be defined in the ip
address trusted list section under voice
service voip to prevent the IOS toll fraud
prevention feature from silently discarding (that is,
dropping) the SIP REGISTER packet that is
received from an untrusted source. With newer
Unified CME versions (12.6 and later), the dynamic
IP trusted list feature creates an entry in the IP
trusted list based on the SIP Contact header
observed during a successful SIP registration.
When an IP phone unregisters, the entry in the
trusted list is removed. Example 10-1 shows the
static configuration required for older Unified
CMEs, which involves defining the IP phone subnet
14.50.214.0 /24 as trusted. Later sections of this
chapter highlight the dynamic IP trusted list feature
in debugging examples and show command output
to cover both scenarios.
• Global SIP CME configuration: SIP Unified

CME should be enabled by using the mode cme
voice register global command and defining a
source address for SIP Unified CME traffic. In
addition, the total number of IP phones and DNs
needs to be configured by using max-pool and
max-dn, respectively. The IP address defined by
the source-address command should be a valid
IP address of an interface that is up and active on
the local router.
Example 10-1 Unified CME Initial Configuration Steps
! Step 1
voice service voip

ipv4 14.50.214.0 255.255.255.0
sip
registrar server
!
! Step 2
voice register global

mode cme
source-address 172.18.110.42
max-pool 50
max-dn 200
To confirm any custom or default configurations with

SIP Unified CME, you can issue the command show
voice register global. This command is also useful for
finding the version of SIP Unified CME that is running
on a device if the IOS–to–Unified CME compatibility
matrix is not handy. Example 10-2 shows a truncated
sample of output from this command. This command
can also be used to view active registration statistics and
other useful information about IP phones.
Example 10-2 Verification of Unified CME Global

Configuration Parameters
rtp-cube# show voice register global

CONFIG [Version=12.6]
========================
Version 12.6
Mode is cme
Max-pool is 50
Max-dn is 200
[..truncated for brevity..]
Source-address is 172.18.110.42 port 5060

Tftp path is system:/cme/sipphone
Generate text file is disabled
Tftp files are not created
Active registrations : 0
Total SIP phones registered: 0
With the global configuration complete, the Unified CME

is ready to start registering SIP IP phones. One of two
methods for registering phones can be leveraged, based
on preference:
• Manual registration: This registration method

involves creating one or many voice register dn
entries for the directory numbers along with a
unique voice register pool for each IP phone.
This pool is also used to define other phone-level
settings for each individual phone that will register
with Unified CME. The DN and pool association
must be done manually by a Unified CM
administrator. With manual registration, the
provisioning for each phone can be greatly
customized before the phone registers.
• Auto-registration: This registration method

involves defining a list of DNs to hand out to
endpoints attempting to initiate SIP registration
with Unified CME. The use of the voice register
dn and voice register pool commands is
automated by Unified CME, and the association of
the two commands is also automatic. Once a phone
is registered, you can create a tailored configuration
by modifying the configuration settings created
automatically by the system.
The following sections cover these two registration

methods.
SIP Phone Manual Registration
To manually register a SIP IP phone, you need to
configure a few key configuration sections. The process
Step 1. Define a voice register dn with an

extension. You can also define optional
values, such as caller ID, phone display, and
call forwarding settings, where needed. In
addition, you can add shared line and max
call information, although it is not required.
You need to define a single unique voice
register dn for each unique extension
required.
Step 2. Create a voice register pool that

references the MAC address of the endpoint
requiring registration. The model of the
endpoint registering using this pool and a
mapping of the extension to a button on the
phone’s display are also required for proper
registration. A username and password
should be configured to facilitate ad hoc
authentication checks with CME during
registration. Finally, you can modify optional
parameters on the pool, such as the audio
codec, DTMF relay, Layer 4 transport
protocol, and phone display.
Step 3. Instruct Unified CME to generate a

configuration file for the endpoint. Create the
configuration file by issuing the create
profile command under voice register
global. This will create phone configurations
files which take the name of SEP<mac-
address>.cnf.xml. Without this step, Unified
CME does not provide the configuration file
requested by the IP phone during the TFTP
phase of the phone boot process. Any time a
voice register Unified CME command is
modified, removed, or added to the system,
you must re-issue the create profile
command to instruct Unified CME to
regenerate the TFTP configuration files from
scratch. If you do not perform this step after a
modification is made to the voice register
configuration, the cnf.xml file becomes out of
sync with the Unified CME voice register
configuration, and the modification is not
properly made on the IP phone.
Example 10-3 shows the configuration for three different

voice register dn entries. The first entry defines the
extension number 7777, and the name command
defines the caller ID entry KYDAVIS-7777. The caller ID
information is used in SIP messaging when establishing
calls with other endpoints and remote parties. The label
command controls the text for a given line on the display
of the IP phone. The second voice register DN entry
consists of the same commands, but this DN will be used
as the primary extension of a second IP phone.
The last voice register dn entry defines the number

9999 and establishes call forwarding settings for busy
and no answer (noan). These settings indicate that
during a busy condition (that is, when the max number
of calls have been surpassed), the attempted call
forwards to 8888 rather than attempting to ring the
9999 extension. The timeout factor on the no answer
call-forward setting is in seconds, and Example 10-3
indicates that after three 6-second ring cycles, the call is
forwarded from extension 9999 to extension 8888. The
caller ID name and line appearance label are defined in
the same way as the previous two DNs. Finally, the DN is
set to a shared line with a maximum number of
concurrent calls set to maximum value of 16. The shared
line functionality enables you to apply this voice
register dn as a line appearance on more than one IP
phone; this is illustrated in upcoming examples.
Example 10-3 Sample Configuration for Two Primary

Extensions and One Shared Line Extension
!
voice register dn 1
number 7777
name KYDAVIS-7777
label SIP-7777
!
voice register dn 2
number 8888
name PKINANE-8888
label SIP-8888
!
voice register dn 3
number 9999
call-forward b2bua busy 8888
call-forward b2bua noan 8888 timeout 18
name SIP-SHARED
label SIP-SHARED-9999
shared-line max-calls 16
!
Example 10-4 shows two voice register pool entries

configured. The first entry is for extension 8865, with a
MAC address ending in A017, as defined by the id mac
and type commands.
Note
You must use the id mac command before using the type command, or you
will get the error “Please configure voice-register-pool id first.”
Next, the phone lines are associated with the voice

register dn commands used earlier. The syntax of this
association is as follows:
number line-appearance-number dn voice-register-dn-ta

In Example 10-4, you can see that the first phone defined
for the pool has associated line appearance 1 (number 1)
with voice register dn 1; in addition, it has line
appearance 2 (number 2) with voice register dn 3, the
shared line created previously. Likewise, phone 2 has
associated line appearance 1 (number 1) with voice
register dn 2 and line appearance 2 (number 2) with
the shared line voice register dn 3.
Next, a username and password are defined on the

phone. The IP phone uses the username and password in
two different ways:
• The password defined on the pool is requested

when attempting to enter the Admin Settings menu
for the IP phone.
• The username and password are provided to

answer ad hoc registration challenges in Unified
CME when the IP phone sending a SIP REGISTER
does not reside on the same subnet as the Unified
CME voice register global source address. Even
when the IP phones and Unified CME reside on the
same subnet, the act of defining individual
usernames and passwords should be completed as a
best practice.
With the MAC address, phone type, and number

association complete, optional parameters can be
configured. In Example 10-4, you can see a description
defined; this description influences the value displayed
in the top left of the IP phone’s display, and the codec
command changes the audio codec from the default of
g728r8 to g711ulaw. If you want to define more than one
codec, you can use voice-class codec instead of codec.
(Refer to Chapter 9, “CUBE Interworking Features,” for
more information on voice class codecs.) IP phones
registered to SIP Unified CME default to UDP as the
transport protocol type rather than TCP for registration.
You can use the command session-transport tcp on a
voice register pool to enable TCP transport and
change the default value. Finally, you can define the
dual-tone multifrequency (DTMF) relay mechanisms by
using the dtmf-relay command.
Example 10-4 Sample Configuration for Two SIP IP

Phones
!
voice register pool 1
id mac C4B3.6ABA.A017
type 8865
number 1 dn 1
number 2 dn 3
username phone-one password C1sc0Vo1p
description PHONE ONE
codec g711ulaw
!
id mac D0EC.35FF.6503
type 8865
number 1 dn 2
number 2 dn 3
username phone-two password C1sc0Vo1p
description PHONE TWO
codec g711ulaw
session-transport tcp
dtmf-relay rtp-nte
!
With the voice register DN commands and voice

register pool commands configured, you need to
instruct Unified CME to create the configuration XML
files that the IP phone will request. Example 10-5 shows
this process and also the verification of the configuration
file generation. The output of the show voice register
global command indicates whether TFTP files have
been created and the locations of the system-generated
files. You can further verify the TFTP configuration files
by issuing the show voice register tftp-bind
command, which details the location and alias of the
TFTP files on the system.
Example 10-5 Creating and Verifying Configuration

Files for SIP IP Phones
rtp-cme# conf t
rtp-cme (config)# voice register global
rtp-cme (config-register-global)# create profile
rtp-cme# show voice register global | include Tftp

Tftp path is system:/cme/sipphone
Tftp files are created, current syncinfo 1300381319
rtp-cme# show voice register tftp-bind

tftp-server url system:/cme/sipphone/syncinfo.xml ali
tftp-server url system:/cme/sipphone/SIPDefault.cnf a
tftp-server url system:/cme/sipphone/softkeyDefault_k
tftp-server url system:/cme/sipphone/softkeyDefault.x
tftp-server url system:/cme/sipphone/skPublicConf_kpm
tftp-server url system:/cme/sipphone/skPublicConf.xml
tftp-server url system:/cme/sipphone/skPersonalConf_k
tftp-server url system:/cme/sipphone/skPersonalConf.x
tftp-server url system:/cme/sipphone/featurePolicyDef
tftp-server url system:/cme/sipphone/SEPC4B36ABAA017.
tftp-server url system:/cme/sipphone/SEPD0EC35FF6503.
You can view the contents of a file by entering the more

command in conjunction with the absolute path of the
file, as shown in Example 10-6. The output in this
example has been trimmed down greatly to illustrate the
items configured earlier and show how the IOS
commands translate to the XML configuration file that
will be downloaded by the IP phone. Compare and
contrast the output in Example 10-6 with the output in
Example 10-1, Example 10-3, and Example 10-4 to get a
better idea of exactly which items the IOS commands
change.
Example 10-6 Verifying the Content of a SIP IP Phone
Configuration File
rtp-cme# more system:/cme/sipphone/SEPC4B36ABAA017.cn

<sipPort>5060</sipPort>
<processNodeName>172.18.110.42</processNodeName>
<line button="1” lineIndex="1">

<featureLabel>SIP-7777</featureLabel>
<name>7777</name>
<displayName>KYDAVIS-7777</displayName>
<authName>phone-one</authName>
<authPassword>C1sc0Vo1p</authPassword>
<sharedLine>false</sharedLine>
<line button="2” lineIndex="2">

<featureLabel>SIP-SHARED-9999</featureLabel>
<name>9999</name>
<displayName>SIP-SHARED</displayName>
<authName>phone-one</authName>
<authPassword>C1sc0Vo1p</authPassword>
<sharedLine>true</sharedLine>
<preferredCodec>g711ulaw</preferredCodec>
<phoneLabel>PHONE ONE</phoneLabel>
<phonePassword>C1sc0Vo1p</phonePassword>
<versionStamp>1300381319824539</versionStamp>
In Unified CME Version 12.6 and above, the password

for the IP phone username command should be a value
between 6 and 15 alphanumeric characters; the password
should include no special characters but should have at
least one uppercase letter, one lowercase letter, and one
numeric character. A password that does not meet these
guidelines, such as cisco (as shown in Example 10-7),
fails to be accepted, and IOS issues a guidance message
about the proper password format.
Example 10-7 IP Phone Password Restrictions
rtp-cme(config-register-pool)# username cisco passwor

Error: The password you have entered is invalid.
Your password must contain:
1. A minimum of 6 and a maximum of 15 alphanumeric ch
excluding symbols and special characters.
2. A minimum of one numeral, one uppercase alphabet,
lowercase alphabet.
In the versions of IOS XE greater than 16.11, the

password for voice features should be encrypted with
AES and a master secret. You configure this by using the
commands shown in Example 10-8. This command set
will applies an extra level of password encryption to
running configuration SIP password commands in the
sip-ua, voice register global, and voice register
pool configuration sections.
Example 10-8 Cisco Recommended AES Master-Key

Configuration Password Encryption
!
password encryption aes
key config-key password-encrypt CISCO123
!
Tip
Before downgrading a Unified CME or CUBE deployment with password
encryption, you should issue the command no password encryption;
otherwise, older IOS-XE versions will be unable to decrypt the password in the
running configuration.
Unified CME IP Phone Registration Overview

With the global configurations in place via voice
service voip and voice register global along with the
applicable configurations for each extension and IP
phone defined by the respective voice register dn and
voice register pool, you should be ready to register the
endpoint. The following sequence of events occur with a
phone registering to Unified CME:
Step 1. The IP phone requests the TFTP
configuration file from Unified CME. This IP
phone will be provided a TFTP server by way
of Option 150, Option 66, or manual
Alternate TFTP configuration via the phone
settings. The TFTP file contains
username/password, line information, and
the call agent where registration should be
attempted. (Review Example 10-6 for more
information on the contents of the CNF.XML
TFTP file.)
Step 2. The IP phone generates a SIP REGISTER

message to Unified CME, based on the call
agent information in the configuration file it
received from Unified CME via TFTP.
Step 3. Unified CME performs trusted list

verification to ensure that the IP phone’s IP
address falls within an IP subnet that is
permitted to be processed by the SIP
application. If the IP phone’s subnet passes
this check, the SIP REGISTER message is
processed.
Step 4. If Unified CME and the IP phone are in

different subnets, Unified CME challenges
the IP phone for authentication by sending a
SIP “401 Unauthorized” response that
includes a SIP WWW-Authenticate header.
Step 5. The IP phone leverages the

username/password from the TFTP
configuration file received in step 1 to
generate a new SIP REGISTER message and
embed this credential information into the
SIP Authorization header.
Step 6. Unified CME verifies that the information
provided in the second SIP REGISTER
message is valid. If the check passes, the
registration is successful, and a SIP “200 OK”
response is sent to the IP phone.
Step 7. The IP phone is now registered and

performs periodic registration renewals to
confirm registration.
When troubleshooting SIP Unified CME registration

issues, the following debug commands can be very
beneficial in understanding the steps just listed:
!
debug tftp events
!
debug voip iptrust
debug voip iptrust detail
!
debug ip tcp transaction
!
debug ccsip error
!
debug voice register event
debug voice register error
debug voice register session
!
Example 10-9 illustrates the configuration steps just

presented and these debug commands.
Example 10-9 Good Registration Based on the Previous

Examples and Debug Commands
! Step 1, TFTP CNF.XML Download
Nov 16 18:25:02.717 EST: TFTP: Looking for SEPC4B36AB

Nov 16 18:25:02.717 EST: TFTP: Opened system:/cme/sip
Nov 16 18:25:02.728 EST: TFTP: Finished system:/cme/s
! Step 2, REGISTER from IP Phone to Unified CME

Nov 16 18:25:09.729 EST: //-1/xxxxxxxxxxxx/SIP/Msg/cc
Received:
REGISTER sip:172.18.110.42 SIP/2.0
From: <sip:7777@172.18.110.42>;tag=c4b36abaa017000409
To: <sip:7777@172.18.110.42>
Call-ID: c4b36aba-a0170002-61182edd-1c72ffa8@14.50.21
Max-Forwards: 70
Session-ID: ff6075ea00105000a000c4b36abaa017;remote=0
CSeq: 101 REGISTER
Contact: <sip:BE556202-630@14.50.214.117:5060;transpo
Content-Length: 0
Reason: SIP;cause=200;text="cisco-alarm:25 Name=SEPC4
Expires: 3600
! Step 3, Trusted List Check
Nov 16 18:25:09.722 EST: iptrust_silent_discard_authe

Nov 16 18:25:09.722 EST: iptrust_authenticateDynamicL
Nov 16 18:25:09.722 EST: iptrust_silent_discard_authe
! Step 4, Register processed and auth check + 401 Unautho

rized
Nov 16 18:25:09.731 EST: VOICE_REG_POOL: Register req

Nov 16 18:25:09.731 EST: auth absent
Nov 16 18:25:09.731 EST: VOICE_REG_POOL: Contact does
Nov 16 18:25:09.731 EST: //53/2A615A7B806E/SIP/Error/
Registration Authorization failed with authorization
Nov 16 18:25:09.732 EST: //53/2A615A7B806E/SIP/Msg/cc

Sent:
To: <sip:7777@172.18.110.42>;tag=BEB7362B-1B18
CSeq: 101 REGISTER
WWW-Authenticate: Digest realm="",nonce="032AD1371312
Content-Length: 0
! Step 5, New Register with Authorization header
Nov 16 18:25:09.745 EST: //-1/xxxxxxxxxxxx/SIP/Msg/cc

Received:
Via: SIP/2.0/UDP 14.50.214.117:5060;branch=z9hG4bK7ff
To: <sip:7777@172.18.110.42>
Max-Forwards: 70
Session-ID: ff6075ea00105000a000c4b36abaa017;remote=0
CSeq: 102 REGISTER
Contact: <sip:BE556202-630@14.50.214.117:5060;transpo
Authorization: Digest username="phone-one",realm="",u
Content-Length: 0
Expires: 3600
! Step 6, Validate and Successful Registration
Nov 16 18:25:09.747 EST: VOICE_REG_POOL: Register req

Nov 16 18:25:09.747 EST: function :: voice_reg_valid
Nov 16 18:25:09.748 EST: VOICE_REG_POOL: Registration
Nov 16 18:25:09.751 EST: //53/2A615A7B806E/SIP/Msg/cc

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 14.50.214.117:5060;branch=z9hG4bK7ff
To: <sip:7777@172.18.110.42>;tag=BEB7362B-1B18
CSeq: 102 REGISTER
Supported: X-cisco-cme-sis-9.0.0
Supported: X-cisco-srtp-fallback
Contact: <sip:7777@14.50.214.117:5060>;expires=3600;x
Expires: 3600
Content-Length: 0
In addition to debug commands, you can use multiple

show commands to view the registration status of IP
endpoints and gather useful information when
troubleshooting Unified CME IP phone registration
issues. The command show voice register global
(shown in Example 10-10) details the total number of
registered devices and some other statistics about
registration. The show voice register pool all brief
command provides an at-a-glance view of Unified CME
IP phone registration. This command also shows the line
appearances and DN mapping along with the pool
number, MAC address, and IP information of the
registered endpoint. Finally, you can use the show ip
address trusted list command to view the trusted list
information, including the dynamic trusted list discussed
earlier.
Example 10-10 Verification Commands for SIP IP

Phone Registration
rtp-cme# show voice register global

Total Registration Statistics

Registration requests : 12
Registration success : 12
Registration failed : 0
unRegister requests : 0
unRegister success : 0
unRegister failed : 0
Auto-Register requests : 0
Attempts to register
after last unregister : 0
Last register request time : 18:25:09.754 EST S
Last unregister request time :
Register success time : 18:25:09.755 EST S
Unregister success time :
rtp-cme# show voice register pool all brief

Pool ID IP Address Ln DN Number St
==== =============== ============== == === ======= ==
1 C4B3.6ABA.A017 14.50.214.117 1 1 7777$ REGIST

ERED
2 3 9999$ RE
2 D0EC.35FF.6503 14.50.214.118 1 2 8888$ REGIST

ERED
2 3 9999$ RE
rtp-cme# show ip address trusted list
Operation State: UP

-------- ---------- --------------
IP Address Subnet M
-------------------------------------------- --------
ipv4:14.50.214.117
2 Phone Registered
ipv4:14.50.214.118
2 Phone Registered
SIP Phone Auto-Registration

Consider the task of registering 450 IP phones, each with
a unique DN. Using the steps shown in the previous
section for two IP phones, you can see that while it is not
an impossible task, it is very laborious and time-
consuming. Furthermore, due to the number of required
inputs, there is a very great chance for an input error.
Simply mistyping a MAC address or another value could
derail a deployment and lead to a lot of time spent
troubleshooting the issue. Fortunately, Unified CME
auto-registration exists to handle some of the
configuration tasks for you and speed up initial Unified
CME deployments.
Auto-registration begins the same way as manual

registration: You configure voice service voip and
voice register global the same way. However, then
you use the auto-register configuration option under
voice register global. First, you need to define the
range of DNs that will be assigned on a first-come, first-
served, round-robin basis. Next, you need to create a
password for these phones. If needed, you can optionally
define a template and tie it to the auto-register
configuration by using the voice register template feature
to provide even more default configurations to an auto-
registered endpoint.
Example 10-11 shows the configuration for manual

registration of phones and also the auto-registration
configuration, which is highlighted in this example to
stand out. You can see that AES password encryption
with a master secret has been defined to ensure that the
password for auto-registration is sufficiently encrypted
in the running configuration. voice service voip is
configured to enable the subnet for the IP phones, and
SIP-to-SIP calling is enabled. The SIP registrar server
command is enabled to allow the SIP application to
process SIP REGISTER messages. The voice register
global section is configured for mode cme, and the
maximum number of pools (phones) and DNs
(extension) are defined, along with the source address
for Unified CME. Finally, the auto-registration
configurations are enabled with service-enable, the
password is enabled, and the first and last extension
range is defined with the auto-assign command.
Example 10-11 SIP IP Phone Auto-Registration

Configuration
!
password encryption aes
key config-key password-encrypt CISCO123
!
voice service voip
ipv4 14.50.214.0 255.255.255.0
sip
registrar server
!
mode cme
source-address 172.18.110.62 port 5060
max-dn 200
max-pool 50
auto-register
service-enable
password C1sc0Vo1p
auto-assign 7000 to 7050
create profile
!
With the global auto-registration configurations in place,

you should be ready to register the endpoints. Phone
auto-registration to Unified CME involves the following
events, and Examples 10-12 through 10-19 show debug
command output that goes with these steps:
Step 1. The IP phone requests the TFTP

configuration file from Unified CME. This IP
phone will be provided a TFTP server by way
of Option 150, Option 66, or manual
Alternate TFTP configuration on the phone.
With auto-registration, the SEP<mac-
address>cnf.xml file is not created because
no pool or DN information exists yet. As a
result, the IP phone downloads the
XMLDefault.cnf.xml file provided by Unified
CME’s TFTP service. This file contains
enough information to keep the registration
process moving along, such as the Unified
CME IP address for accepting SIP REGISTER
messages (see Example 10-12).
Example 10-12 Debug Snippet 1 for Good SIP IP Phone

Auto-Registration
! Step 1, download XMLDefault.cnf.xml
018102: Nov 16 20:05:49.882 EST: TFTP: Looking for XM

018103: Nov 16 20:05:49.883 EST: TFTP: Opened system:
018104: Nov 16 20:05:49.890 EST: TFTP: Finished syste
Step 2. The IP phone generates a SIP REGISTER

message to Unified CME, based on the
information in the configuration
XMLDefault.cnf.xml file it received in the
previous step (see Example 10-13).

Auto-Registration
! Step 2, Register sent from IP Phone to Unified CME
018132: Nov 16 20:05:51.485 EST: //-1/xxxxxxxxxxxx/SI

Received:
Via: SIP/2.0/UDP 14.50.214.118:5060;branch=z9hG4bK4ad
From: <sip:AUTO-REG@172.18.110.62>;tag=d0ec35ff650300
To: <sip:AUTO-REG@172.18.110.62>
Call-ID: d0ec35ff-65030008-77ae28e3-244b600b@14.50.21
Max-Forwards: 70
Session-ID: ec61d2cf00105000a000d0ec35ff6503;remote=0
CSeq: 164 REGISTER
Contact: <sip:AUTO-REG@14.50.214.118:5060;transport=u
Content-Length: 0
Expires: 3600
Step 3. Unified CME performs trusted list

verification to ensure that the IP phone’s IP
address falls within an IP subnet that is a
source trusted by the SIP application (see
Example 10-14).

Auto-Registration
! Step 3, Verify IP Trusted List
018127: Nov 16 20:05:51.476 EST: iptrust_silent_disca

018128: Nov 16 20:05:51.476 EST: iptrust_silent_disca
Step 4. Unified CME begins the process of

automatically creating a voice register dn
and voice register pool for the phone,
based on the MAC address information
received in the SIP REGISTER message and
the information provided by the
administrator in the auto-register, voice
register global command. In addition,
Unified CME automatically creates a
SEP<mac address>cnf.xml configuration file
for the MAC address of the phone (see
Example 10-15).

Auto-Registration
! Step 4, Create pool and dn
018133: Nov 16 20:05:51.486 EST: voice_reg_get_reg_ex

018136: Nov 16 20:05:51.487 EST: VOICE_REG_POOL: Regi
018137: Nov 16 20:05:51.487 EST: VOICE_REG_POOL: Auto
018155: Nov 16 20:05:51.495 EST: VOICE_REG_POOL: auto
018156: Nov 16 20:05:51.495 EST: VOICE_REG_POOL: 2 ou
Step 5. Unified CME sends a 200 OK (see Example
10-16).

Auto-Registration
! Step 5, 200 OK to Register
018163: Nov 16 20:05:51.496 EST: //93/3B8C28998114/SI

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 14.50.214.118:5060;branch=z9hG4bK4ad
From: <sip:AUTO-REG@172.18.110.62>;tag=d0ec35ff650300
To: <sip:AUTO-REG@172.18.110.62>;tag=797A1512-E50
Call-ID: d0ec35ff-65030008-77ae28e3-244b600b@14.50.21
CSeq: 164 REGISTER
Contact: <sip:AUTO-REG@14.50.214.118:5060>;expires=36
Expires: 3600
Content-Length: 0
Step 6. Unified CME sends an out-of-dialog (OOD)

SIP NOTIFY message that includes
action=restart in the SIP message body to
instruct the IP phone to restart. The phone
replies with a 200 OK message and restarts,
as instructed (see Example 10-17).

Auto-Registration
! Step 6, Reset the IP Phone
018173: Nov 16 20:05:51.636 EST: VOICE_REG_POOL: Pool

018176: Nov 16 20:05:51.638 EST: //0/000000000000/SIP
Sent:
NOTIFY sip:AUTO-REG@14.50.214.118:5060;transport=udp
From: <sip:AUTO-REG@172.18.110.62>;tag=797A15A9-26CD
To: <sip:AUTO-REG@14.50.214.118>
Call-ID: 3BA332C4-80D11EA-8115E8A5-F2283ACD@172.18.11
CSeq: 101 NOTIFY
Max-Forwards: 70
User-Agent: Cisco-SIPGateway/IOS-16.12.1a
Event: service-control
Contact: <sip:AUTO-REG@172.18.110.62:5060>
Content-Type: text/plain
Content-Length: 185
action=restart
RegisterCallId={d0ec35ff-65030008-77ae28e3-244b600b@1
ConfigVersionStamp={2513463472421178}
DialplanVersionStamp={}
SoftkeyVersionStamp={2513463472421178}
018177: Nov 16 20:05:51.641 EST: //0/000000000000/SIP

Received:
SIP/2.0 200 OK
From: <sip:AUTO-REG@172.18.110.62>;tag=797A15A9-26CD
To: <sip:AUTO-REG@14.50.214.118>
Call-ID: 3BA332C4-80D11EA-8115E8A5-F2283ACD@172.18.11
CSeq: 101 NOTIFY
Content-Length: 0
Step 7. Because the phone has performed a restart,

as requested by Unified CME, the boot
process starts again. This, in turn, means the
phone re-requests the SEP<mac-
address>cnf.xml file, just like in step 1. This
file, which Unified CME created in step 4, is
now provided to the IP phone by Unified
CME’s TFTP service (see Example 10-18).

Auto-Registration
! Step 7, TFTP File Provided
018227: Nov 16 20:05:56.570 EST: TFTP: Looking for SE

018228: Nov 16 20:05:56.570 EST: TFTP: Opened system:
018229: Nov 16 20:05:56.579 EST: TFTP: Finished syste
Step 8. The rest of the SIP registration process
proceeds just like the manual registration
process described earlier (refer to Example
10-9). However, note that the 401
Authentication request is not optional for
auto-registered IP phones, and it always
occurs (see Example 10-19).
Example 10-19 Debug Snippet 8 for Good SIP IP

Phone Auto-Registration
! Step 8, Normal Registration

Received:
From: <sip:7001@172.18.110.62>;tag=d0ec35ff6503005f54
To: <sip:7001@172.18.110.62>
Call-ID: d0ec35ff-65030009-437ecf65-5850577b@14.50.21
Max-Forwards: 70
CSeq: 166 REGISTER
Contact: <sip:797A1518-96C@14.50.214.118:5060;transpo
Content-Length: 0
Expires: 3600

018278: Nov 16 20:06:03.692 EST: VOICE_REG_POOL: Cont
018279: Nov 16 20:06:03.692 EST: auth absent
018285: Nov 16 20:06:03.694 EST: //95/42D27E11811A/SI

Sent:
To: <sip:7001@172.18.110.62>;tag=797A44BF-191B
CSeq: 166 REGISTER
WWW-Authenticate: Digest realm="",nonce="E2BA9BDC25BF
Content-Length: 0

Received:
To: <sip:7001@172.18.110.62>
Max-Forwards: 70
CSeq: 167 REGISTER
Contact: <sip:797A1518-96C@14.50.214.118:5060;transpo
Authorization: Digest username="auto2",realm="",uri="
Content-Length: 0
Expires: 3600

018291: Nov 16 20:06:03.701 EST: function :: voice_r
018292: Nov 16 20:06:03.701 EST: function :: voice_r
018294: Nov 16 20:06:03.701 EST: VOICE_REG_POOL: No e
018295: Nov 16 20:06:03.701 EST: VOICE_REG_POOL: key(
018296: Nov 16 20:06:03.701 EST: VOICE_REG_POOL: No e
018297: Nov 16 20:06:03.702 EST: voice_register_creat
018298: Nov 16 20:06:03.702 EST: iptrust_addDynamicLi
018299: Nov 16 20:06:03.702 EST: iptrust_findDynamicL
018300: Nov 16 20:06:03.702 EST: iptrust_findDynamicL
018301: Nov 16 20:06:03.702 EST: iptrust_addDynamicLi

018311: Nov 16 20:06:03.704 EST: VOICE REGISTER POOL-
018312: Nov 16 20:06:03.704 EST: %SIPPHONE-6-REGISTER
018320: Nov 16 20:06:03.706 EST: //95/42D27E11811A/SI

Sent:
SIP/2.0 200 OK
To: <sip:7001@172.18.110.62>;tag=797A44BF-191B
CSeq: 167 REGISTER
Contact: <sip:7001@14.50.214.118:5060>;expires=3600;x
Expires: 3600
Content-Length: 0
Tip
To view the OOD SIP NOTIFY message to reset the phone, you use debug
ccsip non-call in addition to the debug commands mentioned earlier in this
chapter.
You can use the same show commands as before to view

the auto-registered information (see Example 10-20).
Note the asterisk (*) beside the REGISTERED state in
the show voice register pool all brief command
output; this indicates that this phone’s pool information
was created automatically during the auto-registration
process.
Example 10-20 Verification of SIP Auto-Registered IP

Phones
sj-cme# show voice register pool all brief

Pool ID IP Address Ln DN Number
==== =============== ============== == === ==========
1 C4B3.6ABA.A017 14.50.214.117 1 1 7000$

REGISTERED*
2 D0EC.35FF.6503 14.50.214.118 1 2 7001$
REGISTERED*
* Pool is created automatically with auto-registration
sj-cme# show voice register global


Registration failed : 2
unRegister requests : 0
unRegister success : 0
unRegister failed : 0
Auto-Register requests : 2
sj-cme# show ip address trusted list

Operation State: UP

Peer TagOper StateSession Target
--------------------------------

ipv4 14.50.214.0 255.255.255.0
IP Address Subnet Mask Count Reason

----------------------- --------------- ----- -------
ipv4:14.50.214.117 1 Phone Regis

tered
ipv4:14.50.214.118 1 Phone Regis
tered
In the running configuration shown in Example 10-21,

you can see the auto-generated voice register DN and
pool. This configuration is persistent through reloads if
you save the configuration issuing copy running-
config startup-config or simply write memory.
From here, you can manually apply custom
configurations to the voice register dn and voice
register pool sections. Remember to apply the changes
to the phone by issuing the create profile command in
voice register global configuration mode.
Example 10-21 IOS-Generated Auto-Register

Configuration
!
voice register dn 1
number 7000
no-reg
!
voice register dn 2
number 7001
no-reg
!
busy-trigger-per-button 2
id mac C4B3.6ABA.A017
type 8865
number 1 dn 1
dtmf-relay rtp-nte
username auto1 password 6 EfYghCf[f\YL\NicME^BGIcXQ\
description AUTO-REG
codec g711ulaw
!
busy-trigger-per-button 2
id mac D0EC.35FF.6503
type 8865
number 1 dn 2
dtmf-relay rtp-nte
username auto2 password 6 EfYghCf[f\YL\NicME^BGIcXQ\
description AUTO-REG
codec g711ulaw
!
UNIFIED CME DIAL DESIGN

With the IP phone registration complete, you can now
start creating a dial plan for the system. Unified CME
uses traditional basic telephone service and VoIP dial
peers for routing calls to and from service providers and
other third-party networks. This means the configuration
commands used to establish SIP trunk call routing on
Unified CME are the same as those used for CUBE (refer
to Chapter 8). The main difference is that Unified CME
automatically creates VoIP dial peers for each registered
voice register dn and voice register pool
combination. These automatic Unified CME virtual dial
peers are used as the inbound dial peers for calls
originating from the IP phone and as the outbound dial
peers for calls from Unified CME destined to a given
directory number.
Unified CME Virtual Dial Peers
Example 10-22 uses the IP phones registered manually
earlier in this chapter to illustrate the dial peers
generated by the system. The output of the command
show dial-peer voice summary shows the virtual
Unified CME dial peers created for the extensions
defined earlier in the chapter. The IPv4 address used as
the session target is the IPv4 address of the registered
SIP IP phone. Notice that the directory number 9999
shows up with two dial peers. This is due to the use of the
shared-line command (refer to Example 10-3) along
with the association of this DN with multiple voice
register pool commands.
Example 10-22 Verification of Unified CME Virtual

Dial Peers
rtp-cme# show dial-peer voice summary

dial-peer hunt 0
AD PRE PASS
40001 voip up up 8888$ 0 syst
Note that these dial peers do not show up in the running

configuration. You need to issue the command show
voice register pool with a particular pool tag to view
the virtual dial peer configuration for the DNs associated
with that pool. Example 10-23 shows a truncated version
of this command and illustrates the configuration values
and default configurations defined on voice register
pool 1; it also includes the virtual dial peers created by
Unified CME. These dial peer tag IDs match the show
dial-peer voice summary output from Example 10-
22. In addition to using show voice register pool, you
can use the command show voice register dial-peers
to examine all Unified CME virtual dial peers.
Example 10-23 Viewing Virtual Dial Peer

Configuration
rtp-cme# show voice register pool 1

Pool Tag 1
Config:
Mac address is C4B3.6ABA.A017
Type is 8865
Number list 1 : DN 1
Number list 2 : DN 3
Description is PHONE ONE
username phone-one password R^CHIaLfF[ShU]LTYFeDFIW
registration Call ID is c4b36aba-a0170006-4117dad5-
contact IP address: 14.50.214.117 port 5060
Dialpeers created:
Dial-peers for Pool 1:
destination-pattern 7777$
session target ipv4:14.50.214.117:5060
digit collect kpml
codec g711ulaw bytes 160
after-hours-exempt FALSE
digit collect kpml
codec g711ulaw bytes 160
call-fwd-busy 8888
call-fwd-noan-timeou 18
call-fwd-noan 8888
Example 10-24 shows show call active voice brief |
include pid being issued to make a simple test call from
extension 7777 to extension 8888. You can see that dial
peers from Example 10-23 are used in this call. The
inbound call leg (Answer) is bound to inbound dial peer
40003, which was confirmed to be associated to
extension 7777 on voice register pool 1. The outbound
call leg (Originate) is using outbound dial peer 40001,
which is the dial peer for voice register pool 2 and
extension 8888, as confirmed by Example 10-23.
Remember that the allow-connections sip to sip
command is required in voice service VoIP
configuration; if it is not used, a call from one SIP IP
phone to another fails with a “404 Not Found” SIP error
with Q.850 cause code 3 (indicating incompatible
protocols).
Example 10-24 A Call Between Two SIP IP Phones,

Showing the Virtual Dial Peers
rtp-cme# show call active voice brief | include pid

<ID>:<CallID> <start>ms.<index> +<connect> pid:<peer
1297 : 101 3270477390ms.1 +1850 pid:40003
1297 : 102 3270477400ms.1 +1820 pid:40001
When Unified CME receives a call for a shared line

extension, such as the one configured in previous
examples (9999), Unified CME attempts to send the call
to all the IP phones simultaneously. If you issue show
call active voice brief | include pid during the call
setup, you see multiple outgoing dial peers for this call.
The moment an IP phone answers the call, the other
session establishment attempts are terminated with a
SIP CANCEL message sent by Unified CME. If you
reissue the command show call active voice brief |
include pid after the call has connected, you now see
one active outbound call and the dial peer of the
endpoint that answered the call (see Example 10-25).
Example 10-25 A Call to a SIP Shared-Line Extension

Detailing Two Outbound Virtual Dial Peers

12A2 : 107 3273858320ms.1 () +-1 pid:2 Answer 1111 co
12A2 : 108 3273858340ms.1 () +-1 pid:40002 Originate
12A8 : 109 3273858340ms.2 () +-1 pid:40004 Originate

12A2 : 107 3273858320ms.1 () +12930 pid:2 Answer 1111
12A2 : 108 3273858340ms.1 () +12900 pid:40002 Origina
You can use the command show shared-line details

to view more information about shared line details in
Unified CME, as shown in Example 10-26. The output of
this command shows the status of the shared line on
each phone, the total number of active calls, and other
information.
Example 10-26 Verification of SIP Shared Line Status
rtp-cme# show shared-line details
Shared-Line info details:
Shared-Line: '9999', subscribed users: 2, max calls

Index Users sub_id pe
===== ===== ====== ==
1 9999@14.50.214.118 10 4
2 9999@14.50.214.117 11 4
Free call queue size: 16, Active call queue size: 0
Message queue size: 20, Event queue size: 64
Unified CME SIP Trunking

To make or receive calls to a service provider, you need
to create a dial plan. The dial plan implementation
depends greatly on your configuration and integration
with the service provider. Chapter 8 covers IOS call
routing and digit manipulation for SIP trunks. The same
concepts detailed in that chapter can be applied to SIP
trunks with Unified CME. Example 10-27 and Example
10-28 illustrate a simple North American Unified CME
dial plan that can be used as a starting point for SIP
trunking with a service provider on with Unified CME.
The outbound call configuration assumes that the

outbound dialing code 9 will be used to indicate the call
is for the PSTN networks. Local, long-distance,
international, and emergency match statements are
configured via e164-pattern-map. A translation rule is
created to strip the leading 9 and prefix a leading + to
provide +E.164 formatting for the PSTN call. The first
rule matches the emergency 911 number and ensures
that the number is not incorrectly modified. The
remaining three rules match local seven-digit numbers,
and then long-distance and international calls are
converted to the appropriate +E.164 format.
Next, translation rule 10 modifies the local four-digit

directory number to an +E.164 number for caller ID
purposes. Rule 99 of translation rule 10 serves as a
catchall to modify any number value not modified by the
other rules into an +E.164 toll-free number. The two
translation rule sets are then applied to the calling and
called party with the translation profile STRIP-9-FIX-
DN. Finally, dial-peer voice 1 is created, with e164-
pattern-map as the outbound matching criteria
statement. The translation profile is configured in the
outgoing direction so that the calling and called numbers
are modified on outbound calls. session protocol
sipv2 defines SIP as the signaling protocol for the dial
peer, and session-target points to a DNS entry for the
service provider.
Example 10-27 Sample Call Routing Configuration for
an Inbound SIP Trunk with Unified CME
! OUTBOUND Calls from Unified CME to ITSP

e164 9[2-9]......$
e164 91[2-9]..[2-9]......$
e164 9011T
e164 911$
!
rule 1 /^911$/ /911/
rule 2 /^9$.......$$/ /+1919\1/
rule 3 /^9011$.*$/ /+\1/
rule 4 /^9$.*$/ /+\1/
!
rule 1 /^7777$/ /+14085267209/
rule 2 /^8888$/ /+14085267209/
rule 99 /.*/ /+18005532447/
!
voice translation-profile STRIP-9-FIX-DN
translate called 9
translate calling 10
!
description Outbound from Unified CME to PSTN
translation-profile outgoing STRIP-9-FIX-DN
session target dns:myITSP.itspDomain.com
codec g711ulaw
!
Example 10-28 shows a sample configuration for calls

from a service provider to Unified CME. Starting at the
top, you can see e164-pattern-map 2 defining ranges
of phone numbers that are owned by Unified CME. Next,
voice translation-rule 2 changes full direct inward
dialing (DID) numbers into the respective four-digit
extensions that were configured previously on voice
register dn entries. The last rule of this translation
profile serves as a catchall to strip any number down to
the last four digits. This is then applied to the called
number by way of translation-profile DID-TO-DN.
These settings are then combined on Dial Peer 2, which
will be used as the inbound dial peer for calls from the
service provider. The match statement e164-pattern-
map 2 is used, and the translation profile is applied in
the incoming direction.
Example 10-28 Sample Call Routing Configuration for

an Outbound SIP Trunk with Unified CME
! INBOUND CALLS from ITSP to Unified CME

e164 1408.......$
e164 18005532447$
e164 +1T
!
rule 1 /14085267209/ /7777/
rule 2 /18005532447/ /9999/
rule 99 /.*$....$$/ /\1/
!
voice translation-profile DID-TO-DN
translate called 2
!
description Incoming from PSTN to Unified CME
translation-profile incoming DID-TO-DN
codec g711ulaw
!
Tip
For more detailed information about the commands shown in Example 10-27
and Example 10-28, refer to Chapter 8.
UNIFIED CME CALL COVERAGE

FEATURES
Unified CME has numerous features that you can use to
enhance the calling capabilities of the system. These
features range from mobility features such as Extension
Mobility and Single Number Reach to call coverage
features such as night service, call pickup, call waiting,
and voice hunt groups with optional call queuing. End
users can even leverage features such as call park,
transfer, hold/resume, paging intercom lines, and ad hoc
conferencing if these features have been configured.
Unified CME can also be integrated with Cisco Unity
Connection (CUC) or Cisco Unity Express (CUE) via SIP
or SCCP to provide voicemail functionality and
additional features.
The following sections of cover the implementation and

verification of the three features noted in the blueprint
for the CLACCM 300-815 exam: voice hunt groups, call
park, and paging. Some features discussed in the
following sections use telephony-service and
ephone-dn configuration parameters. Historically,
these two configuration modes deal with SCCP
endpoints, but features like call park and paging use
these commands to provide services for both SIP and
SCCP endpoints.
Configure Unified CME Hunt Groups

You can use Unified CME hunt groups to direct an
inbound call to a pilot number that is assigned to a voice
hunt group. A hunt group contains a list of member
directory numbers that should receive a call when the
pilot number is dialed. Voice hunt groups have a few
different operational modes, each of which greatly
changes the behavior of the hunt group’s calling logic.
The first hunt group mode is the sequential operational

mode. Example 10-29 shows a sample configuration for
this hunt group mode. This configuration contains the
pilot number 1111 that, when called, sequentially calls the
listed members. The members list consists of the list
command with comma-separated directory numbers. A
sequential hunt group always starts hunting with the first
listed member. This means every call to a sequential
hunt group in Example 10-29 starts with extension 7777.
Each member of the hunt group is rung for the duration
of the defined timeout value, in seconds. With the
configuration shown in Example 10-29, extension 7777 is
called for 18 seconds, and if there is no answer, Unified
CME cancels the call to 7777 and extends the call to
8888. When all members of the hunt group have been
attempted, and there is no answer, the final hunt group
extension is presented the call. The phone-display
command and the name command work together to
ensure that the hunt group name is presented to the
members of the hunt group. This process differentiates
calls to different hunt groups when an extension belongs
to multiple hunt groups. The final command shown in
this example is the statistics collect command, which
enables the collection of statistical information in the
show voice hunt-group hunt-group-tag statistics
command.
Example 10-29 Sample Configuration for a Sequential

Hunt Group
!
voice hunt-group 1 sequential
phone-display
final 9999
list 7777,8888
timeout 18
statistics collect
pilot 1111
name SEQUENTIAL
!
The second hunt group mode, illustrated in Example 10-
30, is the peer hunt group operational mode. With the
peer operational mode, calls are directed to the member
list in a circular or round-robin manner. The difference
between sequential and peer is that with the peer
operational mode, for each new call to the pilot number,
the hunt group presents the call to the next member in
the hunt list. For example, the first call to pilot 2222
rings extension 7777. The next call to pilot 2222 rings
8888. A third call to the pilot 2222 starts over and rings
7777 again. If 7777 is unable to answer after 18 seconds,
as per the timeout value, extension 8888 is presented the
call. Similarly, if 8888 cannot answer the call, the final
extension, 9999, is rung. The settings for displaying the
hunt group name on IP phones and enabling collection of
statistics are the same as for sequential mode.
Note
The final extension can be the pilot of another hunt group. This means you can
ring a list of members in hunt group A, and if there is no answer, you ring the
pilot of hunt group B, which contains another set of members.
Example 10-30 Sample Configuration for a Peer Hunt

Group
!
voice hunt-group 2 peer
phone-display
final 9999
list 7777,8888
timeout 18
statistics collect
pilot 2222
name PEER
!
The third hunt group mode is the parallel hunt group

operational mode, sometimes also referred to as call
blast mode in documentation (see Example 10-31). With
parallel mode, all members of the hunt group have the
call presented (or blasted) at the same time. When the
timeout value is observed, the call is presented to the
final extension. In Example 10-24, when the pilot 3333 is
dialed, the call is presented to both 7777 and 8888. After
18 seconds, the call is presented to the final extension,
9999. The rest of the settings shown in Example 10-31
operate the same as the settings for the previous two
examples.
Example 10-31 Sample Configuration for a Parallel

Hunt Group
!
voice hunt-group 3 parallel
phone-display
final 9999
list 7777,8888
timeout 18
statistics collect
pilot 3333
name PARALLEL
!
Example 10-32 shows the last hunt group operational

mode, longest idle, which is somewhat self-explanatory.
Hunting with this type of hunt group starts with the
member that has been on-hook for the longest time. You
can use the hops command to limit the number of times
the call can forward to the next member of the hunt
group list. Because a voice hunt group can contain up to
32 members, it may be beneficial to limit the total
number of hops to a value such as two in order to speed
up the process of reaching the final extension. With
hops 2 in place, only the two longest idle hunt group
members are presented the call, and if they do not
answer, the call is presented to the final extension. The
rest of the configuration settings in Example 10-32
operate the same as the settings in the previous three
examples.
Example 10-32 Sample Configuration for Longest Idle
Hunt Group
!
voice hunt-group 4 longest-idle
phone-display
final 9999
list 7777,8888
timeout 18
statistics collect
pilot 4444
name LONGEST-IDLE
hops 2
!
Tip
To change the operational mode of hunt groups, you need to completely
remove the original hunt group by prefixing no in front of the voice hunt-group
command.
You might need to give hunt group members the ability

to log in and out of the hunt group with the softkey. This
can be useful when using the hunting modes sequential
and longest idle. Rather than ring a hunt group member
who is not at his or her device, you can indicate that
when a device is logged out, the device is omitted from
the voice hunt group’s operational logic. By default, all
members are logged in to the hunt group and can log out
only by clicking the DND (Do Not Disturb) softkey.
Example 10-33 illustrates how to enable the HLOG hunt
group softkey as an alternative to the DND softkey for
SIP phones and the configuration required to ensure that
the default state of hunt group members is the logout
state, through the command members logout. In
addition, the command auto logout is used to ensure
that after three rings with no answer, the hunt group
member is placed in a logout state. This is useful for
scenarios in which an agent has forgotten to click the
DND or HLOG softkey when stepping away from his or
her device. The show voice hunt-group command
displays information about the hunt group and the login
states of agents.
Example 10-33 Configuration Required for HLOG

Softkey Usage
rtp-cme# show run | s telephony|hunt-group 5

!
telephony-service
hunt-group logout HLog
!
voice hunt-group 6 sequential
members logout
phone-display
final 9999
list 7777,8888
timeout 18
statistics collect
auto logout 3
pilot 6666
name HLOG-VHG
!
rtp-cme# show voice hunt-group 6

Group 6
type: sequential
pilot number: 6666, peer-tag 2147483643
pilot name: HLOG-VHG
secondary name: HLOG-VHG
list of numbers:
Member Used-by State Login/Logo
====== ======= ===== ==========
7777 7777 up logout

8888 8888 up login
preference: 0
preference (sec): 0
timeout: 18
final_number: 9999
auto logout: 3
stat collect: yes
phone-display: yes
hlog-block: no
calls in queue: 0
overwrite-dyn-stats: no
members logout: yes
present-call idle-phone: no
To perform debugging or verification of voice hunt

groups, you can use the following commands:
show voice hunt-group vhg-tag
debug ccsip message

debug ccsip error
debug voice register error
debug voice register event
debug voice application
Configure Unified CME Multicast Paging

Unified CME paging allows a single IP phone to establish
a one-way audio channel with many different endpoints
simultaneously for short broadcasted messages. Whereas
the Unified CME intercom feature is a one-to-one
feature, Unified CME paging is a one-to-many feature.
Unified CME paging makes use of a multicast address
and port for distributing the audio from one SIP IP
phone to all SIP IP phones listening on the specified
multicast IP and port.
Note
The IP phones do not support multicast addresses in the 224.x.x.x range and
support only ports with even numbers in the range 20480 to 32768.
The configuration of SIP paging is a straightforward

four-step process (see Example 10-34):
Step 1. Configure telephony service with the max-
dn command. This command makes it
possible to use the ephone-dn command in
step 2. If you fail to issue the max-dn
command and then attempt step 2, you get
the error “dn 1 exceeds max-dn 0.”
Step 2. Configure ephone-dn to reference the

paging extension and multicast IP address
and port.
Step 3. Apply the paging-dn command to the

voice register pool endpoints that should
receive pages from the extension created in
step 2
Step 4. Re-create the TFTP configuration files by

issuing create profile voice register global
command and then applying the
configuration to registered endpoints with
apply-config.
Example 10-34 Multicast Paging Configuration

Example
! Step 1
telephony-service
max-dn 50
!
! Step 2
ephone-dn 1
number 5555 no-reg primary
paging ip 239.1.1.1 port 20480
!
! Step 3

paging-dn 1
!
paging-dn 1
!
! Step 4

create profile
apply-config
!
If the IP phones are on the same VLAN, no additional

configuration is required. If the IP phones traverse
multiple Layer 2 subnets and three hops, additional
multicast routing configuration may be required. The
configuration of IGMP and PIM are beyond the scope of
this book. Therefore, for the upcoming Unified CME
examples, all the IP phones and Unified CME on the
same subnet.
To test the configuration in Example 10-34, either of the

IP phones should dial 5555. Unified CME receives the
call and invokes ephone-dn with the paging extension.
A SIP REFER message is then sent to all endpoints that
have paging-dn configured. This SIP message, detailed
in Example 10-35, instructs the endpoint to join the
multicast IP address and port specified in the XML SIP
message body. The call is answered on speakerphone
with the MUTE button selected automatically. You can
use debug ccsip non-call to view these messages.
Example 10-35 Multicast Paging REFER Message with

XML Message Body and Multicast IP
Sent:
REFER sip:7777$@14.50.214.117:50132 SIP/2.0
From: <sip:14.50.214.42>;tag=C3CFD61A-24A4
To: <sip:7777$@14.50.214.117>
Call-ID: 3C48C264-8C611EA-8243BCE2-A2E64DB9@14.50.214
CSeq: 101 REFER
Max-Forwards: 70
Contact: <sip:14.50.214.42:5060;transport=tcp>
User-Agent: Cisco-SIPGateway/IOS-16.12.1a
Refer-To: cid:0328505328
Content-ID: <0328505328>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Referred-By: <sip:14.50.214.42>
Content-Length: 640
--uniqueBoundary
Content-Type:application/x-cisco-remotecc-request+xml
<datapassthroughreq>
<applicationid>1</applicationid>
<transactionid>1</transactionid>
<stationsequence>StationSequenceLast</stationsequence
<displaypriority>2</displaypriority>
<appinstance>0</appinstance>
<routingid>0</routingid>
<confid>0</confid>
</datapassthroughreq>
--uniqueBoundary
Content-Type:application/x-cisco-remotecc-cm+xml
<?xml version="1.0"encoding="ISO-8859-1” ?><CiscoIPPh

--uniqueBoundary--
You can use the command show ephone-dn paging to

view information about the paging extension during an
active page or even when the paging extension is idle (see
Example 10-36).
Example 10-36 Verification of the Multicast Paging

Feature on Unified CME
rtp-cme# show ephone-dn paging
Paging Configuration
ephone-dn 1 ( IDLE )
number 5555
voice reg pool 1 paging-dn 1 (OFF)
voice reg pool 2 paging-dn 1 (OFF)
Paging Control Info

skinnyPC[0] ephone-paging-dn 1 ( IDLE ) count 0
rtp-cme#
rtp-cme#
rtp-cme#
rtp-cme# show ephone-dn paging
Paging Configuration
ephone-dn 1 (ACTIVE)
number 5555
voice reg pool 1 paging-dn 1 (ON )
voice reg pool 2 paging-dn 1 (ON )
Paging Control Info

skinnyPC[0] ephone-paging-dn 1 (ACTIVE) count 1
phone ip address next
pool#[peertag] 1[40003] 239.1.1.1 239.1.1.1

20480
sccp(ephone#[phone]): None
sip (pool[peer tag]): 1[40003](mcast) 1[40004](mcast)
Configure Unified CME Call Park

The Unified CME call park feature makes it possible to
transfer a call to a predefined extension defined as a call
park extension. The act of transferring the original call to
the call park extension is known as parking. While a call
is parked, the parked participant should hear hold music.
If Music on Hold is not configured, tone on hold beeps
may be played instead. At any point, the original
extension or any other IP phone extension may retrieve
the parked call and continue the call.
Call parking is often used as a mechanism to transfer

calls between departments. For example, one
department might receive a call and engage in
conversation. For one reason or another, the call may
need to be sent to another department. In this case, the
user could simply transfer the call to the other
department’s extension, or they might park the call and
notify the other department through another means,
such as with a page all, that a call has been parked and
should be picked up. From here, another person can
retrieve the parked call and resume the conversation.
Parking a Call
A call can be parked in two different ways:
• Basic call park: This involves parking a call via

the Park softkey, which is included by default on
most modern IP phones. With basic call park, the
first available park slot is used to park the call, and
the park-slot extension is shown on the IP phone
screen as confirmation that the call has been
parked successfully.
• Directed call park: This method of parking a call

involves pressing the Transfer softkey and then
dialing the desired park extension. Directed call
park allows the park originator to direct the call to a
specified park extension.
Tip
Attempting to transfer a call to a basic call park extension results in a park
failure. Similarly, attempting to use the Park softkey when only directed call
park is configured results in park failure.
The call park feature uses the ephone-dn CLI command

set to define the call park extension parameters. A
number command is used to define the extension that
will hold the parked call while the call park command is
leveraged to define call park parameters. Example 10-37
shows the syntax of the ephone-dn and park-slot
commands, and Table 10-2 describes the different
command options.
Example 10-37 IOS Command Syntax for ephone-dn

and park-slot
ephone-dn dn-tag [dual-line | octo-line]

park-slot [directed] [reservation-group group-number
Table 10-2 ephone-dn and park-slot Attributes

Explained
Note
The reservation-group and reserved-for attributes cannot be configured at
the same time by IOS CLI as they are mutually exclusive. These attributes are
checked only when parking a call, which means any device in Unified CME can
any parked call. In addition, the only attribute cannot be used with the recall
attribute because the two commands contradict each other.
Before you start the call park extension configuration,
you need to enable call park globally for all IP phones on
the Unified CME system by using the configuration
shown in Example 10-38. The fac standard command
is required only for directed call park, as described
shortly. Remember that the max-dn command is also
required; without it, the CLI does not allow the use of
ephone-dn commands.
Example 10-38 Sample Global Configurations for Basic

and Directed Call Park Features
! Basic Call Park
telephony-service
max-dn 50
call-park system application
!
! Directed Call Park
telephony-service
max-dn 50
call-park system application
fac standard
!
Example 10-39 shows a basic call park configuration and

a directed call park configuration for two ephone-dn
entries. The first, ephone-dn 2, specifies a basic call
park slot with no optional attributes. The name of the
park slot is used for caller ID purposes if a recall,
transfer, or alternate transfer occurs. The second park
slot, ephone-dn 3, is a directed call park slot with no
optional attributes. The number command for both
park slots defines the park slot extension used to retrieve
the parked call.
Example 10-39 Sample Basic and Directed Call Park
Configurations
! Basic, uses park softkey
ephone-dn 2
number *7777
park-slot
name 7777-PARK
!
! Directed, uses transfer softkey
ephone-dn 3
number *8888
park-slot directed
name 8888-PARK
!
Example 10-40 shows the same two park slots as

Example 10-39 but with additional optional parameters
added to the park-slot command. Here park slot
extension 7777 would attempt to notify extension 8888,
and then, after the call had been parked for 10 seconds, it
would attempt to notify the original extension (7777) that
parked the call. This timeout notification occurs twice,
and the third timeout results in the parked call
attempting to transfer to extension 1111. If this transfer
cannot be completed, an alternate transfer to 9999
occurs.
For the second park slot extension, 8888, the call parked
on the directed call park slot times out after 120 seconds.
The first timeout results in notification of only 7777
(because the only attribute is specified). On the second
timeout, which is 120 seconds, the parked call attempts
to transfer to extension 2222.
Example 10-40 Sample Advanced Use of the park-

slot Command for Basic and Directed Call Park
! Basic, uses park softkey
ephone-dn 2
number *7777
park-slot timeout 10 limit 3 notify 8888 transfer 11
name 7777-PARK
!
! Directed, uses transfer softkey
ephone-dn 3
number *8888
park-slot directed timeout 120 limit 2 notify 7777 o
name 8888-PARK
!
As one can see, there are many ways to configure the

park slot extension and ensure that a call is not parked
indefinitely. You can use the information in Example 10-
37 and Table 10-2 along with the question mark
command (?) to find the exact configuration that works
for your business needs.
Typically, the customer can choose the number to use for

the call park extension. For example, a customer might
choose to use a one-to-one mapping so that each
extension on the system has a call park extension. With
this configuration, the call park extension is usually
prefixed by some value, such as * or #, to differentiate it
from the actual extension. Alternatively, a customer
might carve out a range of extensions that are entirely
dedicated to parking calls, and they might then be
assigned to specific departments or sections of the
organization.
Call Park Retrieval
As mentioned in the previous section, any device can

retrieve an active parked call; however, the actions
required to retrieve a parked call depend on the type of
park slot being used. For example, a call parked using the
basic call park feature can be retrieved by either clicking
the Resume softkey on the IP phone that parked the call
or dialing the call park extension directly. Unified CME
works to unpark the call and connect it to the IP phone.
To retrieve a call parked using the directed call park

feature, you dial the directed call park retrieval feature
access code (FAC), along with the call park extension,
from the phone where you would like to retrieve the call.
The default directed call park retrieval FAC is *0, which
means a call that was parked by being transferred to the
directed call park extension *8888 would be retrieved
by using *0*8888 (the directed call park retrieval FAC
plus the directed call-park extension). Example 10-41
shows how to verify the current FAC configuration by
using show telephony-service fac. This example also
shows that the default can be changed to any value, as
defined with the fac custom dpark-retrieval
command via telephony-service. If fac standard is
already configured, you need to remove it by using the
no prefix. Attempting to configure fac custom along
with fac standard prompts an error message that
instructs you to remove fac standard before
proceeding.
Example 10-41 Verification and the Configuration

Required to Change the FAC for Directed Call Park
Retrieval
rtp-cme# show telephony-service fac

telephony-service fac standard
callfwd all **1
callfwd cancel **2
pickup local **3
pickup group **4
pickup direct **5
park **6
dnd **7
redial **8
voicemail **9
ephone-hunt join *3
ephone-hunt cancel #3
ephone-hunt hlog [N/A for SIP] *4
ephone-hunt hlog-phone *5
trnsfvm *6
dpark-retrieval *0
cancel call waiting *1

ephone-hunt unjoin #4
rtp-cme(config)# telephony-service
rtp-cme(config-telephony)# fac custom dpark-retrieval
Remove fac standard first!
rtp-cme(config-telephony)# no fac standard
fac standard has been disabled!
rtp-cme(config-telephony)# fac custom dpark-retrieval
fac dpark-retrieval code has been configurated to #5!
rtp-cme# show telephony-service fac

telephony-service fac custom
dpark-retrieval #5
When troubleshooting issues related to both basic call

park and directed call park, you can use the following
show and debug commands to gather information
about the issue:
!
show ephone-dn park
!
debug ephone park-pickup
debug voip application park-pickup
debug ccsip mess
debug ccsip error
!
SURVIVABLE REMOTE SITE
TELEPHONY (UNIFIED SRST)
Unified SRST serves as a backup call agent for endpoints
that reside at remote locations. These endpoints are
likely to register with Unified CM over a WAN
connection for normal operations. In the event of a
connection outage with the remote Unified CM servers,
an IP phone may register with the Unified SRST gateway.
The Unified SRST gateway provides limited services and
features to ensure business continuity while mitigating
customer satisfaction issues that arise from network
down situations.
Unified SRST has two modes of operation, which have

different feature sets:
• Traditional Unified SRST: This is the default

voice register global mode when no mode
command has been enabled. This operational mode
offers basic calling features for IP phones and no
feature support.
• Unified Enhanced SRST (Unified E-SRST):

This is an updated version of Unified SRST that
includes new features such as shared lines, voice
hunt groups, Busy Lamp Field (BLF), and video
support. For modern deployments, this is the mode
that should be used.
Figure 10-3, shown earlier in this chapter, shows a

simple network design with a centralized Unified CM
server. The remote branch location also leverages a Cisco
IOS gateway that doubles as a Unified SRST gateway.
Here the IP phones register with Unified CM over the
WAN connection. Unified CM is configured to advertise
its primary, secondary, and tertiary call agents for
registration as per the Unified CM group configuration
assigned to a phone’s device pool. In addition to these
three points of redundancy, the device pool can also be
configured with a Unified SRST reference as a backup. If
an IP phone is unable to communicate with any of the
provided call agents, the Unified SRST reference is
contacted, and the IP phone initiates the registration
process with the IOS gateway.
The following sections discuss how to configure Unified

SRST on both Unified CM and the IOS gateway and the
commands you can use to verify proper Unified SRST
failover.
Implement SIP Unified SRST on Unified CM

The task of implementing Unified SRST on Unified CM is
a straightforward one that involves a few key steps:
Step 1. Create a Unified SRST reference by

navigating to System > Unified SRST and
configuring the reference as shown in Figure
10-4. The key items are the IP Address and
SIP Network/IP Address fields. The IP
Address Field is used for SCCP IP phones,
and the SIP Network/IP Address field is
utilized by SIP IP phones. These IP Address
fields should reference an IP address
assigned to an active interface on the Unified
SRST gateway.
Figure 10-4 Unified CM Unified SRST Reference
Configuration Page
Step 2. Assign the Unified SRST reference to the SJ-

Unified SRST-DP device pool, as shown in
Figure 10-5. Leave all the other settings at
their defaults.
Figure 10-5 Unified CM Unified SRST Reference

Application on Device Pool
Step 3. Assign the device pool to all the Unified CM

IP endpoints that might need to use this
Unified SRST gateway. Figure 10-6 shows the
addition of the SJ-Unified SRST-DP device
pool to a test phone.
Figure 10-6 Device Pool Application to an IP Phone
Step 4. Save IP phone page and apply the

configuration so the endpoint pulls the new
configuration.
Implement SIP Unified SRST on an IOS Gateway
Example 10-42 shows the full configuration required to

implement Unified SRST for SIP IP phones. A few
settings should look familiar from earlier in the chapter,
when you saw how to manually register a SIP phone. For
older versions of Unified CME (before Version 12.6), you
configure the ip address trusted list command to
allow SIP message processing on the IOS gateway. Next,
you use the allow-connections command to enable
SIP-to-SIP calling functionality. Finally, you use the
registrar server command to allow the processing of
SIP REGISTER requests on the Unified SRST gateway.
Next, you set voice register global to the Unified E-

SRST (esrst) mode and define the maximum number of
phones (max-pool) and directory numbers (max-dn).
Next, you need to define the optional system message
that appears on the IP phone display during Unified
SRST registration.
Note
Refer to the Unified SRST compatibility matrix for detailed information about
the total number of IP phone registrations different IOS gateways can handle:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/requirements/gui
de/33matrix.html.
Finally, you need to create a voice register pool that

references an IP address network where the IP phones
reside. In modern Unified CME versions, this is used to
dynamically update the IP trusted list feature when
running debug voip iptrust, as shown in Example 10-
43. With this configuration in place, if a SIP IP phone
attempts to register from this IP subnet, Unified CME
automatically creates dial peer information and registers
the endpoint.
Example 10-42 Configuration for Unified SRST on an

IOS Gateway
! Step 1
voice service voip

ipv4 14.50.214.0 255.255.255.0
sip
registrar server
!
! Step 2

mode esrst
system message Unified SRST MODE
max-dn 50
max-pool 50
!
! Step 3
id network 14.50.214.0 mask 255.255.255.0
!
Tip
There are no major differences between the configuration of Unified CME hunt
groups and the configuration of Unified SRST hunt groups. When configuring
Unified SRST hunt groups, always enable the members logout command on
all voice hunt groups. Because the Unified SRST gateway and Unified CM do
not share stateful information about hunt groups, there is a chance that without
this command, an agent will be logged in upon failover to Unified SRST
although that agent was originally logged out before the Unified SRST
registration. With the members logout command in place, all agents start in
the logout state.
Verify and Troubleshoot SIP Unified SRST Failover

To perform verification of Unified SRST configurations,
you can simulate a WAN outage by applying an ACL used
to block TCP traffic to specific Unified CM servers close
to the phone. This forces the IP phone to initiate
registration with the Unified SRST gateway. In a lab
network, you can simply disable the CallManager service
to disable SIP registration and force the IP phone to fail
over to the Unified SRST gateway.
Before attempting Unified SRST testing, you should

ensure that the IP phone has downloaded the latest
configuration and knows about the Unified SRST
reference. The easiest way to verify whether this has
occurred is through the IP phone web page and the
Network Setup tab. In order to view the IP phone web
page, you set the Web Access option in the Product
Specific Configuration Layout section of the IP phone
configuration page in Unified CM to Enabled. On the
Network Setup tab, the last Unified CM server should
reference the IP address of the Unified SRST gateway.
Figure 10-7 shows an IP phone web page with the active
Unified CM and Unified SRST designated as Standby.
Figure 10-7 Verifying the IP Phone Registration Pre-
Unified SRST Failover
You can examine the Unified SRST configuration by

issuing the show voice register global command.
Example 10-43 shows the verification of the Example 10-
42 configuration. To view the dynamic trusted list
feature, you use the command show ip address
trusted list can be leveraged, which is also included
in Example 10-43.
Example 10-43 Verifying Unified SRST and the

Dynamic Trusted List
sj-srst# show voice register global

CONFIG [Version=12.6]
========================
Version 12.6
Mode is esrst
Max-pool is 50
Max-dn is 50
System message is Unified SRST MODE
sj-srst# show ip address trusted list

Operation State: UP

-------- ---------- --------------

ipv4 14.50.214.0 255.255.255.0
IP Address Subnet M
-------------------------------------------- --------
ipv4:14.50.214.0 255.255.255.
0 1 Pool Configured
sj-srst# show log

Nov 19 18:54:21.258 EST: %PARSER-5-CFGLOG_LOGGEDCMD:
Nov 19 18:54:32.479 EST: iptrust_findDynamicListEntry
Nov 19 18:54:32.479 EST: iptrust_findDynamicListEntry
Nov 19 18:54:32.479 EST: iptrust_addDynamicListEntry:
Nov 19 18:54:32.479 EST: %PARSER-5-CFGLOG_LOGGEDCMD:
After the failover has occurred, you can consult the same
IP phone web page to verify whether the Unified SRST
gateway is now the active device. Figure 10-8 provides a
screenshot of a phone that has now registered with the
Unified SRST gateway. You can use the command show
voice register pool all brief to view registered SIP
endpoints and the show voice register pool pool-tag
command to view registration information and other
useful information for the Unified SRST reference pool.
Example 10-44 provides a truncated version of this
command’s output.
Figure 10-8 Verifying IP Phone Registration After

Unified SRST Failover
Example 10-44 Verifying Unified SRST Failover from
the IOS CLI
sj-srst# show voice register pool 1

Pool Tag 1
Config:
Network address is 14.50.214.0, Mask is 255.255.255
Dialpeers created:
Dial-peers for Pool 1:

digit collect kpml
Statistics:

sj-srst# show voice register pool all brief

Pool ID IP Address Ln DN Numbe
==== ================= ================= == === =====
1 14.50.214.0 14.50.214.108 1000$

REGISTERED
Cisco IP phones registered to an Unified SRST gateway

attempt to open a TCP connection with the original call
agents every 120 seconds, as defined by the Unified CM
Connection Monitor Duration enterprise parameter or
device pool parameter. This means that when an IP
phone registers with an Unified SRST gateway, the
device does not attempt to reregister with any of the
original three call agents until the Connection Monitor
Duration timer has expired. One issue that may arise
with a lossy WAN connection is “flapping” of IP phone
registration between the Unified CM servers and the
Unified SRST gateway. In this situation, the Connection
Monitor Duration timer should be set to a much higher
value to reduce the number of back-and-forth
registrations experienced by the IP phones.
REFERENCES
Cisco Unified Communications Manager Express 11.5
Data Sheet,
https://www.cisco.com/c/en/us/products/collateral/u
nified-communications/unified-communications-
manager-express/datasheet-c78-737647.html

System Administrator Guide,
mm/cucme/admin/configuration/manual/cmeadm.ht
ml

System Administrator Guide, “Cisco Unified CME
Features Roadmap,”
mm/cucme/admin/configuration/manual/cmeadm/c
meroad.html

System Administrator Guide, “Virtual CME,”
mm/cucme/admin/configuration/manual/cmeadm/c
mevir.html
Cisco Unified SCCP and SIP SRST System

Administrator Guide,
mm/cusrst/admin/sccp_sip_srst/configuration/guide
/SCCP_and_SIP_SRST_Admin_Guide.html
Cisco Unified Survivable Remote Site Telephony Data

Sheet,
https://www.cisco.com/c/en/us/products/collateral/u
nified-communications/unified-survivable-remote-
site-telephony/data-sheet-c78-744126.html
Unified CME, Unified SRST, and Cisco IOS Software

Version Compatibility Matrix,
mm/cucme/requirements/guide/33matrix.html



DEFINE KEY TERMS
There are no key terms for this chapter.

MEMORY
Chapter 11. Final Preparation
The first 10 chapters of this book cover the technologies,
protocols, design concepts, and considerations required
to be prepared to pass the Implementing Cisco Advanced
Call Control and Mobility Services (CLACCM) 300-815
exam. While these chapters supply the detailed
information, most people need more preparation than
simply reading the first 10 chapters of this book. This
chapter details a set of tools and a study plan to help you
complete your preparation for the exams.
This short chapter has three main sections. The first

section helps you get ready to take the exam, and the
second section lists the exam preparation tools useful at
this point in the study process. The third section
provides a suggested study plan you can use now that
you have completed all the earlier chapters in this book.
GETTING READY
Here are some important tips to keep in mind to ensure
that you are ready for this rewarding exam:
• Build and use a study tracker: Consider using

the exam objectives shown in this chapter to build a
study tracker for yourself. Such a tracker can help
ensure that you have not missed anything and that
you are confident for your exam. As a matter of
fact, this book offers a sample study planner as a
website supplement.
• Think about your time budget for questions

on the exam: When you do the math, you will see
that, on average, you have one minute per question.
While this does not sound like a lot of time, keep in
mind that many of the questions will be very
straightforward, and you will take 15 to 30 seconds
on those. This leaves you extra time for other
questions on the exam.
• Watch the clock: Check in on the time remaining

periodically as you are taking the exam. You might
even find that you can slow down pretty
dramatically if you have built up a nice block of
extra time.
• Get some earplugs: The testing center might

provide earplugs but get some just in case and
bring them along. There might be other test takers
in the center with you, and you do not want to be
distracted by their screams. I personally have no
issue blocking out the sounds around me, so I never
worry about this, but I know it is an issue for some.
• Plan your travel time: Give yourself extra time

to find the center and get checked in. Be sure to
arrive early. As you test more at a particular center,
you can certainly start cutting it closer time-wise.
• Get rest: Most students report that getting plenty

of rest the night before the exam boosts their
success. All-night cram sessions are not typically
successful.
• Bring in valuables but get ready to lock

them up: The testing center will take your phone,
your smartwatch, your wallet, and other such items
and will provide a secure place for them.
• Take notes: You will be given note-taking

implements and should not be afraid to use them. I
always jot down any questions I struggle with on
the exam. I then memorize them at the end of the
test by reading my notes over and over again. I
always make sure I have a pen and paper in the car,
and I write down the issues in my car just after the
exam. When I get home—with a pass or fail—I
research those items!
TOOLS FOR FINAL PREPARATION

This section lists some information about the available
tools and how to access the tools.
Pearson Cert Practice Test Engine and Questions on

the Website
Register this book to get access to the Pearson Test Prep
practice test software (software that displays and grades
a set of exam-realistic multiple-choice questions). Using
the Pearson Test Prep practice test software, you can
either study by going through the questions in study
mode or take a simulated (timed) exam.
The Pearson Test Prep practice test software comes with

two full practice exams. These practice tests are available
to you either online or as an offline Windows application.
To access the practice exams that were developed with
this book, please see the instructions in the card inserted
in the sleeve in the back of the book. This card includes a
unique access code that enables you to activate your
exams in the Pearson Test Prep software.
Accessing the Pearson Test Prep So ware Online

The online version of this software can be used on any
device with a browser and connectivity to the Internet,
including desktop machines, tablets, and smartphones.
To start using your practice exams online, simply follow
these steps:
Step 1. Go to http://www.PearsonTestPrep.com.
Step 2. Select Pearson IT Certification as your

product group.
Step 3. Enter your email and password for your
account. If you don’t have an account on
PearsonITCertification.com or
CiscoPress.com, you need to establish one by
going to PearsonITCertification.com/join.
Step 4. In the My Products tab, click the Activate

New Product button.
Step 5. Enter the access code printed on the insert

card in the back of your book to activate your
product. The product is then listed in your
My Products page.
Step 6. Click the Exams button to launch the exam

settings screen and start the exam.
Accessing the Pearson Test Prep So ware Offline

If you wish to study offline, you can download and install
the Windows version of the Pearson Test Prep software.
You can find a download link for this software on the
book’s companion website, or you can just enter this link
in your browser:
http://www.pearsonitcertification.com/content/do
wnloads/pcpt/engine.zip
To access the book’s companion website and the

software, simply follow these steps:
Step 1. Register your book by going to

PearsonITCertification.com/register and
entering the ISBN: 9780136575542.
Step 2. Respond to the challenge questions.
Step 3. Go to your account page and select the

Registered Products tab.
Step 4. Click on the Access Bonus Content link

under the product listing.
Step 5. Click the Install Pearson Test Prep
Desktop Version link in the Practice
Exams section of the page to download the
software.
Step 6. When the software finishes downloading,

unzip all the files onto your computer.
Step 7. Double-click the application file to start the

installation and follow the onscreen
instructions to complete the registration.
Step 8. When the installation is complete, launch

the application and click the Activate Exam
button on the My Products tab.
Step 9. Click the Activate a Product button in the

Activate Product Wizard.
Step 10. Enter the unique access code from the card
in the sleeve in the back of your book and
click the Activate button.
Step 11. Click Next, and then click Finish to

download the exam data to your application.
Step 12. You can now start using the practice exams
by selecting the product and clicking the
Open Exam button to open the exam
settings screen.
Note that the offline and online versions sync together,

so saved exams and grade results recorded on one
version will be available to you in the other version as
well.
Customizing Your Exams

When you are in the exam settings screen, you can
choose to take exams in one of three modes:
• Study mode
• Practice Exam mode
• Flash Card mode
Study mode allows you to fully customize an exam and

review answers as you are taking the exam. This is
typically the mode you use first to assess your knowledge
and identify information gaps. Practice Exam mode locks
certain customization options in order to present a
realistic exam experience. Use this mode when you are
preparing to test your exam readiness. Flash Card mode
strips out the answers and presents you with only the
question stem. This mode is great for late-stage
preparation, when you really want to challenge yourself
to provide answers without the benefit of seeing
multiple-choice options. This mode does not provide the
detailed score reports that the other two modes provide,
so it is not the best mode for helping you identify
knowledge gaps.
In addition to these three modes, you will be able to

select the source of your questions. You can choose to
take exams that cover all of the chapters, or you can
narrow your selection to just a single chapter or the
chapters that make up specific parts in the book. All
chapters are selected by default. If you want to narrow
your focus to individual chapters, simply deselect all the
chapters and then select only those on which you wish to
focus in the Objectives area.
You can also select the exam banks on which to focus.

Each exam bank comes complete with a full exam of
questions that cover topics in every chapter. You can
have the test engine serve up exams from all four banks
or just from one individual bank by selecting the desired
banks in the exam bank area.
There are several other customizations you can make to

your exam from the exam settings screen, such as the
time allowed for taking the exam, the number of
questions served up, whether to randomize questions
and answers, whether to show the number of correct
answers for multiple-answer questions, and whether to
serve up only specific types of questions. You can also
create custom test banks by selecting only questions that
you have marked or questions on which you have added
notes.
Updating Your Exams

If you are using the online version of the Pearson Test
Prep software, you should always have access to the
latest version of the software as well as the exam data. If
you are using the Windows desktop version, every time
you launch the software, it will check to see if there are
any updates to your exam data and automatically
download any changes that made since the last time you
used the software. This requires that you be connected to
the Internet at the time you launch the software.
Sometimes, due to a number of factors, the exam data

might not fully download when you activate your exam.
If you find that figures or exhibits are missing, you might
need to manually update your exams.
To update a particular exam you have already activated

and downloaded, simply select the Tools tab and click
the Update Products button. Again, this is only an issue
with the desktop Windows application.
If you wish to check for updates to the Windows desktop

version of the Pearson Test Prep exam engine software,
simply select the Tools tab and click the Update
Application button. Doing so allows you to ensure that
you are running the latest version of the software engine.
Premium Edition
In addition to the free practice exam provided on the
website, you can purchase additional exams with
expanded functionality directly from Cisco Press. The
Premium Edition of this title contains an additional two
full practice exams and an eBook (in both PDF and ePub
format). In addition, the Premium Edition title has
remediation for each question to the specific part of the
eBook that relates to that question.
Because you have purchased the print version of this

title, you can purchase the Premium Edition at a deep
discount. There is a coupon code in the book sleeve that
contains a one-time-use code and instructions for where
you can purchase the Premium Edition.
To view the premium edition product page, go to

www.informit.com/title/9780136591160.
Chapter-Ending Review Tools

Chapters 1 through 10 each have several features in the
“Exam Preparation Tasks” section at the end of the
chapter. You might have already worked through these in
each chapter. It can also be useful to use these tools
again as you make your final preparations for the exam.
SUGGESTED PLAN FOR FINAL

REVIEW/STUDY
This section lists a suggested study plan from the point at
which you finish reading through Chapter 10, until you
take the CLACCM 300-815 exam. You can ignore this
plan, use it as is, or take suggestions from it.
The plan involves two steps:
Step 1. Review key topics and “Do I Know

This Already?” (DIKTA?) questions:
You can use the table that lists the key topics
in each chapter or just flip the pages, looking
for key topics. Also, reviewing the DIKTA?
questions from the beginning of the chapter
can be helpful for review.
Step 2. Use the Pearson Test Prep practice
test software to practice: The Pearson
Test prep practice test engine allows you to
study using a bank of unique exam-realistic
questions available only with this book.
SUMMARY
The tools and suggestions listed in this chapter have
been designed with one goal in mind: to help you develop
the skills required to CLACCM 300-815 exam. This book
has been developed from the beginning to not just tell
you the facts but to also help you learn how to apply the
facts. No matter what your experience level leading up to
when you take the exam, it is our hope that the broad
range of preparation tools, and even the structure of the
book, will help you pass the exam with ease. We hope
you do well on the exam.
Appendix A. Answers to the “Do I
Know This Already?” Questions
CHAPTER 1
1. B, C. Both the CUBE and Expressway-C products
exist at the collaboration edge and usually interface
with public networks such as the Internet or the
public switched telephone network (PSTN).
2. B. SIP trunks are leveraged by nearly every device

within the Cisco collaboration ecosystem for call
routing and supplementary features.
3. A, B. Endpoint registration and ad hoc conferencing

are features offered natively by Unified CM. The other
options listed here are best left to Expressway and
CUBE.
4. C, D. SIP and H.323 are VoIP protocols for which

CUBE can perform interworking. MGCP and SCCP
are used to control analog and TDM endpoints on
voice gateways, and WebRTC is not supported on
CUBE.
5. A. A numbering plan area (NPA) code, often

referenced simply as an area code, is a three-digit
code that is usually mapped to a location such as a
city.
6. D. +1 is the country code for the United States, and

4085267209 is the national number in this case.
7. D. Most users within the United States dial the

steering code followed by 011, which is the country
code, and the phone number.
CHAPTER 2
1. D. A back-to-back user agent (B2BUA) or session
border controller (SBC) is a device that can act as a
UAS to answer incoming requests and then perform
call routing functions and reoriginate requests by
operating as a UAC.
2. B, E. 5xx-level messages are server error final

responses.
3. A, E. Of the headers mentioned, only Call-ID and

Contact are required during a SIP INVITE request.
4. A, C. During an early offer call, the SIP INVITE and

200 OK messages carry the SDP message body to
complete the offer/answer.
5. C, D. OPUS audio and H.264 video both utilize

dynamic payload numbers (96 through 127) and must
therefore leverage the a=rtpmap SDP attribute.
6. A, C. Both INVITE and UPDATE can be used in

concert with SDP to perform mid-call session updates
to modify SDP session parameters.
7. B. H.245 is used to negotiate the characteristics of a

media session, such as media format, the method of
DTMF relay, the media type (audio, video, fax, and so
on), and the IP address/port pair for media.
8. B. TCP port 1720 is used for non-secure signaling

with the H.225 protocol.
9. B. When fast start is utilized, H.245 signaling is

tunneled within the H.225 signaling and completes
before the call connects.
CHAPTER 3
1. A. 8 kHz equals 8000 Hz, which is the sampling rate
for the G.711 audio codec.
2. C, D, and E. Dynamic RTP payload types are 96

through 127.
3. D. The Sequence Number header is a 16-bit field that

facilitates built-in loss detection for RTP packets
4. C. The SSRC value for a given RTP stream might

change when the RTP network address and port pair
change. The other scenarios do not have any bearing
on the SSRC value.
5. A. The recommended percentage of bandwidth

allocation for RTCP is 5%, and active senders are
allocated one-quarter of the total RTCP bandwidth.
6. A, B. Both of these SDP attributes are used to signal

the RTCP port that will be used for the stream.
7. B. RTP-NTE packets are RTP packets carrying the

specialized named telephony event (NTE) DTMF
payload.
8. D, E. Both 99 and 101 fall within the dynamic payload

type number range that is used by RTP-NTE DTMF.
9. A. The initial SIP INVITE message contains the first

digit dialed by the user. Subsequent digits are sent
through the KPML subscription using SIP NOTIFY
messages.
10. C. OOB DTMF is signaled through the call setup

signaling. For SIP and H.323, the signaling should be
examined to determine if there are any issues with
negotiation or transmission of digits.
CHAPTER 4
1. B. The X character represents the digits 0 through 9
as a wildcard in Unified CM.
2. B, C, and E. A is invalid because masks do not use a

leading backslash before a plus sign. B is a valid
mask. C is valid because * is a character, not a
wildcard, so the digits in those positions will be
replaced with the * character. D is invalid because
bracket notation is not allowed in a mask. E is valid.
3. A, B, and E. The Use Calling Party’s External Phone

Number Mask parameter appears in the
configuration pages for each of these dial plan
elements.
4. B, D. Top Down and Circular are the two options

available for a route group. Line groups also have the
Longest Idle option, but this is not available on a
route group.
5. C, D, and E. Digit discard instructions apply to

patterns with the @ sign where numbering plan–
specific instructions can be applied or to any pattern
with a dot (.) or trailing pound symbol (#).
6. B. Call queuing can only be configured on a hunt

pilot.
7. D. Calling search spaces are ordered lists of

partitions. Route patterns and directory numbers are
placed into partitions, not into calling search spaces.
8. B. Patterns in the < None > partition can be reached

by any calling search space, including the < None >
calling search space.
9. A, C, and D. All these parameters are available on the

configuration for a translation pattern but not on a
route pattern.
10. C. The translation pattern transforms the original

called party number to 2000. When a transformation
pattern is applied, it uses the original called party
number to find a match for the transformation and as
the input into any configured transformations; hence
2XXX is matched, and the called party number is
transformed to 2222.
11. C. The order of operations is digit discard

instructions, transformation mask, and then prefix
digits, in this order, so 456888 becomes 8888 after
discarding PreDot, it then becomes 118888 after
applying the mask, and finally it becomes 123118888
after prefixing the digits.
12. C. The first step in a global dial plan with TEHO

should be to globalize the calling and called party
numbers so they can be routed in globalized form and
then localized, depending on the egress gateway or
trunk.
13. A, C. Only local directory URIs are placed into

partitions. Learned URIs are not placed in a partition.
SIP route patterns are also placed into a partition
when configured. The CFQDN and OTLD parameters
only apply to numeric URIs and are not applicable to
non-numeric URIs.
14. B, C. A cluster can be either a hub or a spoke if it is in

an ILS network. It can also be configured to be a
Stand Alone Cluster, but in that case, it is not part of
an ILS network.
15. C, D, and E. TranslatorX, RTMT, and CSA all have the

ability to display a SIP ladder diagram for calls.
16. E. Options A, C, and D are possible outcomes, but the

one line does not tell you which one is correct. This
line just indicates that there are potential matches if
the user continues to dial more digits but does not tell
you if there has been a match. You must look for a
digit analysis result to know if a call will be routed or
not.
CHAPTER 5
1. B, D, and E. CUC, IM&P, and CUBE can integrate
with Unified CM by utilizing a SIP trunk.
2. D. The inbound device is the SIP trunk that assumes

the role of the calling device.
3. C. You define a port by using the Inbound Incoming

Port option on the SIP trunk security profile applied
the SIP trunk.
4. C. SIP OPTIONS ping can be used to monitor the

reachability status of a remote device.
5. C. The behavior during an MTP allocation error

depends on the Unified CM Fail Call Over SIP Trunk
if MTP Allocation Fails service parameter. By default,
the call proceeds rather than fails.
6. C. The Run On All Active Unified CM Nodes

checkbox allows all Unified CM nodes, with the
CallManager service enabled, to monitor and process
calls with the SIP trunk, thus adding more
redundancy.
7. B, D. Both of these methods allow you to gather

information about the TCP handshake failure.
8. B. Unified CM writes information about SIP trunk

operation to the CallManager SDL traces.
CHAPTER 6
1. A, B, C. The IOS-based media resources include
MTPs, transcoders, and conference bridges.
2. B, C, D. Media resources either register using SCCP

or, for some conference resources, a combination of
SIP and HTTPS.
3. A, E. The IP Voice Media Streaming App service
supports the G.711 and Wideband 256k codecs for
audio conferencing.
4. B. The CMS certificate must be imported into the

CallManager-Trust trust store.
5. C, D, E. Unified CM supports ad hoc, Meet-Me, and

Conference Now as native conference types.
6. B. Most of the configuration for the Conference Now

feature is done on the end-user configuration page.
7. B, D. The two hold source types are user hold and

network hold.
8. D. You can configure up to 500 audio sources besides

the fixed audio source.
9. C. A media resource group list configured on a device

overrides the configuration from the device pool.
10. C. The Call Park Reversion timer is set to 60 seconds

by default.
11. B. To retrieve a call parked on a directed call park

number, the user must first dial the retrieval prefix
and then dial the park number or use a directed park
BLF button (not a standard speed dial button).
12. B, D, E. Unified CM supports pickup, group pickup,

other pickup, and directed call pickup.
13. B. An audio codec preference list allows an

administrator to reorder the list of codecs advertised
by Unified CM, but the codecs cannot be removed
from the list. There are service parameters that
control removing some codecs.
14. A, B, E. Regions allow administrators to define

bandwidth limits for audio, video, and immersive
video calls.
15. B, C, D. ELCAC requires configuration of locations,
links, and weights. LBM groups are recommended
but not required, and the default region is all that is
needed, although adding additional regions to match
the locations being configured is highly
recommended.
16. B, C, D. The Hub_None, Phantom, and Shadow

locations are all preconfigured on Unified CM.
CHAPTER 7
1. B. Single Number Reach is a Unified Mobility
solution provided by Unified CM that allows calls to a
desk phone to ring a remote destination, such as a
mobile phone, simultaneously.
2. C. Unified CM invokes Intelligent Session Control to

avoid sending a call to the remote destination, where
possible, and instead ring the desk phone when a call
originates from an on-premises device.
3. B, D. A common misconception is that the calling

search space is used to perform call routing
operations when invoking the Single Number Reach
feature. However, the rerouting calling search space
is the correct CSS for this scenario. Another common
issue is not checking the line association checkbox on
the remote destination configuration page.
4. A. Unified CM performs digit analysis in tandem with

digit analysis for the endpoint. The call to the Single
Number Reach endpoint is then made when the
Delay Before Ringing timer expires.
5. C. Move to Mobile is a Single Number Reach

configuration that allows desk phone users to click a
softkey to transition a call from the local desk phone
to a remote destination seamlessly.
6. C. The Move to Mobile feature is invoked through the
use of the Mobility softkey, which must be added to
an IP phone because it is not a default softkey.
7. B. Simply missing the Enable Move to Mobile

checkbox means the Move to Mobile feature does not
work.
8. D. Extension Mobility is a key feature of Unified

Mobility. The ability to log in to an IP phone and have
settings applied dynamically is a great feature for any
mobile worker.
9. A. An IP phone’s configuration page has a dynamic

portion that shows information about the currently
logged in Extension Mobility user.
10. A. Failing to select the Enable Mobility checkbox on

the end-user page causes problems with Extension
Mobility login.
11. C. This is a very common real-world scenario that

many have encountered. The absence of an Extension
Mobility subscription on a device profile causes some
issues with logging out.
12. B. Device Mobility allows an end user to move his

entire phone from one physical location to another.
13. D. To configure Device Mobility, you need to

understand when roaming sensitive settings or
Device Mobility–related information settings are
applied to a phone.
14. B. The main part of this output, where the Unified

CM trace logs states “added mobile device to Device
Mobility Route Table,” indicates that the phone is
roaming and is now using Device Mobility settings.
CHAPTER 8
1. B. CUBE always has an inbound call leg and an
outbound call leg when a call traverses the SBC.
2. C, D. A call flow diagram shows Layer 7 application

protocols and sometimes Layer 4 transport
information. Layers 1, 2, and 3 are often included in
topology diagrams but are not often included in call
flow diagrams.
3. B. CUBE filters inbound dial peers based on a VRF

instance on the ingress interface.
4. D. Dial peer–level configurations always have

precedence over all other configurations when
multiple variants exist.
5. B. CUBE always evaluates the topmost Via header in

a SIP message before evaluating other URI matches
and even before calling and called number match
criteria commands.
6. B, C. For a dial peer to be eligible for outbound dial

peer matching, both an outbound matching
command and next-hop session information must be
defined.
7. A, B, D. dial-peer hunt 0 defines an outbound dial

peer match that uses longest match in phone number,
explicit preference, and random selection.
8. B, E. e164-pattern-maps can be configured to

summarize destination-pattern and incoming
called-number statements, which leads to fewer
dial peers in the configuration.
9. B, E. show call active voice brief can be used to

view information about active calls such as total time
of the call, send/received media packets, dial peer
used on each call leg, and many other identifiers.
show voip rtp connections can be leveraged to
view local and remote media information that was
negotiated by the signaling.
10. C, D. Packets do not naturally egress through virtual

interfaces such as loopback and VLAN SVIs. This
means in order to source packets from these types of
interfaces, application signaling and media binding
must be defined to spoof the sources of the packets.
11. B, C. The numeric calling number and numerical

called number can be modified with translation
profiles.
12. B. Outbound SIP profiles are used to change egress

SIP messaging on a given call leg.
CHAPTER 9
1. C. You can use early-offer forced to force CUBE to
send an early offer if a delayed offer is received.
2. B, D. The inclusion of SDP in a 18X message

generally indicates that ringback will be in-band, as
per the SDP attributes.
3. B, C, D. SIP devices use sendonly, inactive, and zero

out IP (0.0.0.0) to remove media and signal a call
hold.
4. D. The Refer-To header is used for dial peer lookups

when CUBE has been configured to consume REFER
requests.
5. C. Consult, or attended, transfers allow the transferor

to connect a call with the transfer target that can be
used to discuss the transfer before the transfer is
completed.
6. C. A PRACK is required to confirm the offer/answer

before the call is connected (answered), at which
point an UPDATE with SDP can be used to change
media parameters.
7. C. CUBE performs a silent discard and drops the

packet.
8. A, B. Only IPv4 and IPv6 addresses are explicitly

configurable using the IP trusted list feature.
9. B. G729r8 is the default audio codec for VOIP dial

peers.
10. B. audio forced disables video and application SDP

on CUBE.
11. A. To enable asymmetric payload support for DTMF,

audio codes, and video codecs, you use the command
asymmetric payload dtmf.
CHAPTER 10
1. C. Unified SRST provided a call agent to remote
branch IP phones for local registration in the event of
a WAN failure or outage that deems the remote
Unified CM unreachable.
2. A, C, D. To register SIP IP phones with Unified CME,

you need to define the maximum number of
extensions (max-dn), the maximum number of
phones (max-pool), and the source IP address for
voice register global (source-address).
3.
4. E. With auto-registration, the
SEPAAAABBBBCCCC.cnf.xml file does not get
generated until a later step; as a result, the file
XMLDefault.cnf.xml is handed out instead.
5. D. Virtual dial peer information (along with many

other outputs about the IP phone) is detailed in the
output of the show voice register pool command.
6. B. Without the command allow-connections sip

to sip, the SIP application rejects SIP-to-SIP calls.
7. D. Parallel hunt groups, also known as call blast hunt

groups, ring all members at the same time.
8. C. Unified CME sends an out-of-dialog SIP REFER to

the IP phone with a multipart/mixed message body
that contains information about the multicast paging
IP address and port the phone should join.
9. B, D. To park the call in a basic park slot, simply click

the Park softkey and let Unified CME pick an
available park slot. To retrieve this call, simply dial
the park slot directly.
10. A, B. Unified E-SRST supports for both shared lines

and voice hunt groups when in Unified SRST mode.
11. B. Connection Monitor Duration is a timer that

specifies “a common link qualifying time period for
all the devices using a specific Unified SRST
reference.”
12. B, C. The default mode for voice register global is

Unified SRST, so only the max-pool and max-dn
commands need to be defined.
Appendix B. CCNP Implementing
Cisco Advanced Call Control and
Mobility Services CLACCM 300-815
Exam Updates
Over time, reader feedback allows Pearson to gauge
which topics give our readers the most problems when
taking the exams. To assist readers with those topics, the
authors create new materials clarifying and expanding
on those troublesome exam topics. As mentioned in the
Introduction, the additional content about the exam is
contained in a PDF on this book’s companion website, at
http://www.ciscopress.com/title/9780136575542.
This appendix is intended to provide you with updated

information if Cisco makes minor modifications to the
exam upon which this book is based. When Cisco
releases an entirely new exam, the changes are usually
too extensive to provide in a simple update appendix. In
those cases, you might need to consult the new edition of
the book for the updated content. This appendix
attempts to fill the void that occurs with any print book.
In particular, this appendix does the following:
• Mentions technical items that might not have been

mentioned elsewhere in the book
• Covers new topics if Cisco adds new content to the

exam over time
• Provides a way to get up-to-the-minute current

information about content for the exam
ALWAYS GET THE LATEST AT THE

BOOK’S PRODUCT PAGE
You are reading the version of this appendix that was
available when your book was printed. However, given
that the main purpose of this appendix is to be a living,
changing document, it is important that you look for the
latest version online at the book’s companion website. To
do so, follow these steps:
Step 1. Browse to
www.ciscopress.com/title/9780136575542.
Step 2. Click the Updates tab.
Step 3. If there is a new Appendix B document on

the page, download the latest Appendix B
document.
Note
The downloaded document has a version number. Comparing the version of
the print Appendix B (Version 1.0) with the latest online version of this
appendix, you should do the following:
• Same version: Ignore the PDF that you downloaded from the
companion website.
• Website has a later version: Ignore this Appendix B in your book and
read only the latest version that you downloaded from the companion
website.
TECHNICAL CONTENT
The current Version 1.0 of this appendix does not
contain additional technical coverage.
Appendix C. Memory Tables
CHAPTER 1
World
CHAPTER 2

CHAPTER 8
Dial Peers

Wildcards and Regex

CHAPTER 9
Appendix D. Memory Tables
Answer Key
CHAPTER 1
World
CHAPTER 2

CHAPTER 8
Dial Peers

Wildcards and Regex

CHAPTER 9
Appendix E. Study Planner
This content is currently in development.
Glossary
A
access list A Unified CM setting that can applied to a
remote destination to allow or block calls.
ad hoc The ability to join three parties into a conference

without a prescheduled meeting and without requiring
each of the three parties to dial in to a meeting.
alphanumeric uniform resource identifier (URI)

dialing Dialing in which a call is placed using an
alphanumeric URI in the form user@host.
alternate match A match for a dialed number that is a

valid match but that is not a good match compared to the
pattern that actually matched based on closest-match
routing.
alternate number An alias for a directory number in

an alternate format, such as an enterprise-specific
globally unique number or the number in +E.164 format.
annunciator A media resource that plays recordings to

users.
audio codec preference list An ordered list of codecs

that determines Unified CM’s preference for which
codecs to negotiate for a call.
B
back-to-back user agent (B2BUA) A device that has
both UAC and UAS functionality and is capable of
forwarding requests and processing them.
back-to-back user agent (B2BUA) A device that
assumes the role of both an UAC and UAC in SIP
sessions to interwork call legs.
bandwidth allocation An ELCAC configuration

component that represents the amount of bandwidth
allocated in the model for each type of traffic: audio,
video, and immersive video. Deductions are taken based
on the region configuration as well as the codecs that are
actually negotiated for a call.
C
call admission control (CAC) A feature that allows
an administrator to restrict the number of calls allowed
between two network locations to ensure that network
links are not oversubscribed, which could lead to
potential voice and video quality issues.
call flow A high-level overview of the known devices

and call legs involved with establishing multimedia
sessions.
call leg A logical identifier for inbound or outbound call

signaling on a given hop of a call flow.
call park A feature that allows a user to place a call on

hold in such a way that the call can be retrieved from a
phone other than the one that placed the call on hold by
dialing a number associated with the parked call.
call park monitoring An advanced feature that is

available on a limited set of IP phone models that allows
the user to know when a call is still parked and to
retrieve the call without having to remember the number
where the call was parked.
call park reversion An event that occurs when a

parked call has stayed parked too long and ends up
reverting back to the user who parked the call.
call pickup A feature that allows a user to answer a
ringing phone on behalf of another user.
calling search space An order list of partitions.
central office exchange (NXX) code A three-digit

code that maps to the central office. A city may have
more than one central office code, depending on the size
of the city.
closest-match routing The process of searching for

the best match, based on the match that results in the
fewest possible matches.
Collaboration Solutions Analyzer (CSA) A Cisco

tool that allows administrators to upload SDL trace files
and post-process them to diagnose issues with calls.
Conference Now A feature that allows users to join a

multi-party conference by dialing in through an IVR
menu.
conferencing The ability for three or more participants

to communicate on the same audio and/or video call.
country code An E.164-specific number that identifies

phone numbers in a country; it may be up to three digits
in length and may start with a plus (+).
D
Device Mobility A Unified CM feature that allows a
user to take his or her device to a different site and
inherit settings that are specific to the site the user is
visiting.
Device Mobility group A means to link a device pool

to a geographic area while being mindful of dialing
requirements. Device Mobility groups are typically
created on a per country basis. Globalized dial plans
coupled with local route groups eliminate the need for
Device Mobility groups.
Device Mobility information Information about
which device pool is associated with a subnet.
Device Mobility mode A setting that determines

whether a device is enabled to use Device Mobility.
Device Mobility–Related Information Device pool

settings that remain constant when a user changes
Device Mobility group and that allow user dialing habits
to be maintained. This is typically dependent on whether
a user has moved from one country to a different country
as there are different dialing habits internationally. The
key thing to understand is this setting helps allow users
to dial numbers the way they are accustomed to dialing.
Dialed Number Analyzer (DNA) A tool that allows

administrators to select a device and see what would
happen if that device were to place a call to an
administrator-provided string of digits without having to
actually place the call.
digit analysis The core call processing function in the

Cisco CallManager service running on a Unified CM
cluster, which is responsible for matching digits with
configured patterns and translations/digit manipulation.
digit discard instruction An instruction that discards

specific parts of a number based on certain
preestablished rules.
directed call park A feature that allows a user to park

a call at a specific phone number instead of allowing the
system to dynamically select the park number.
directed call pickup A feature that is similar to group

call pickup in that it allows a user to answer a call ringing
on another phone by pressing the Group Pickup softkey,
but instead of dialing the pickup group number, the user
dials the extension of the phone that is ringing.
directory number The number that appears on a

phone line.
dual-tone multifrequency (DTMF) The combination
of two tones, a high-frequency tone and low-frequency
tone interleaved to represent a digit on the keypad (0–9,
*, #) or a letter (A–D).
E–F
E.164 number An international phone number format
that can be a maximum of 15 digits in length with the
country code included.
+E.164 format A number format that identifies a

calling or called user by formatting the number with the
plus symbol (+) followed by the country code and then
the national number to create a globally unique number
on the public switched telephone network (PSTN).
effective path An ELCAC configuration component

that is the end-to-end path with the least cumulative
weight. As far as Unified CM is concerned, all traffic
between two locations only traverses the effective path.
enbloc A type of calling that involves sending a string of

digits all at once, as opposed to digit-by-digit
transmission.
enhanced location call admission control

(ELCAC) A static call admission control feature in
Unified CM that allows administrators to model the
network topology and assign bandwidth limits to links on
that topology.
Extension Mobility A Unified CM feature that enables

users to share phones while maintaining their own
phone settings, including their directory numbers.
G
Global Dial Plan Replication (GDPR) A service that
makes use of ILS to distribute numbers and patterns
between Unified CM clusters.
group call pickup A feature that allows a phone to

answer a call ringing on a phone in a different pickup
group by pressing the Group Pickup button or softkey
and then dialing the pickup group number where a
phone is ringing.
H
H.225 A protocol that handles call setup and teardown
between H.323 endpoints and is also responsible for
peering with H.323 gatekeepers via the Registration
Admission Status (RAS) protocol.
H.245 A peer protocol to H.225 that is used to negotiate

the characteristics of the media session, such as media
format, the method of DTMF relay, the media type
(audio, video, fax, and so on), and the IP address/port
pair for media.
H.323 A VoIP call control protocol from the ITU-T that

allows for the establishment, maintenance, and teardown
of multimedia sessions across H.323 endpoints.
hunt list An ordered list of line groups.
hunt pilot A number that can route calls to a hunt list

for the purpose of distributing calls to phones registered
to the cluster.
I–K
in-band DTMF relay The transmission of tones within
the RTP (media) stream.
inbound dial peer The logical name for a dial peer that
is associated to an inbound call leg. Configurations on
this dial peer are leveraged to control signaling, media,
and other aspects of the associated call leg.
Intelligent Session Control A Unified CM feature
that allows calls to the remote destination number to be
redirected to the enterprise phone.
interactive voice response (IVR) A media resource

that plays prompts and collects input from the user.
Intercluster Lookup Service (ILS) A service that is

responsible for replicating a variety of data between
Unified CM clusters, including dial plan information
with Global Dial Plan Replication.
international call A call that traverses international

borders and utilizes E.164 number formatting.
Internet telephony service provider (ITSP) A

service provider that offers a SIP trunk for connecting to
the PSTN over public networks, such as the Internet.
IP Voice Media Streaming App service The Unified

CM service that is responsible for Music on Hold, media
termination point, annunciator, software conference,
and interactive voice response media resources.
L
LHS The user portion of a URI in user@host format.
Stands for left-hand side.
line group A grouping of directory numbers and rules

that describe how calls should be distributed to a group.
link An ELCAC configuration component that

interconnects locations and is used to define the
bandwidth available between the locations. Links
logically represent the amount of bandwidth available for
different types of calls between two locations.
local call A call that is often within the same city and
may not require an area code.
local route group A virtual route group that is
matched with a real route group at the time a call is
routed, based on the route group configured on the
device pool of the calling device.
location An ELCAC configuration component that

represents LAN or an aggregation point in a network. It
could contain endpoints or simply serve as a transit
location between links for WAN network modeling.
Location Bandwidth Manager (LBM) The service

responsible for managing call admission control
reservations for the enhanced location call admission
control feature.
long-distance call A call that stays within the same

country. Also known as a national call.
M
media resource A software or hardware component
that provides media processing capabilities to Unified
CM, such as a conference, media termination point,
Music on Hold, interactive response, or annunciator
services.
media resource group (MRG) An unordered list of

media resources.
media resource group list (MRGL) An ordered list

of media resource groups, ranked in priority order.
media termination point (MTP) A media resource

that can be used to terminate media when a device
involved in the call is not able to.
Meet-Me A multi-party conference call in which users

dial in to a specific number to speak on the conference.
This feature requires that an IP phone user initiate the
conference with the Meet-Me button or softkey.
Mobile Connect An older name for Single Number
Reach that may appear in documentation.
Move to Mobile A Unified CM feature that allows a

user to move an active call to a remote destination via a
single click of a softkey.
music on hold A media resource that plays live or

prerecorded content to callers who have been placed on
hold.
N
named telephony event (NTE) A payload format and
specification for the transmission of DTMF tones within
the media stream.
network hold The audio source heard when a system

places a call on hold in order to invoke another feature,
such as transfer, conference, or park.
numbering plan area (NPA) code A three-digit code

that is usually mapped to a location such as a city. Often
referred to simply as an area code.
O
OnNet Internal enterprise calls that remain on the
enterprise network.
on-network (on-net) calling Calling in which calls

route from the source to the destination entirely within
the enterprise network or enterprise WAN.
OffNet External calls that leave the enterprise network.
off-network (off-net) calling Calling in which calls

route from the enterprise to public networks such as the
PSTN or Internet.
other call pickup A feature that allows administrators
to associate multiple pickup groups so that a caller can
answer a call ringing on a pickup group other than the
pickup group of the phone without having to enter the
pickup group number.
out-of-band (OOB) DTMF relay A DTMF

transmission method that relies on the signaling channel
to transmit DTMF information.
outbound dial peer The logical name for a dial peer

that is used to create an outbound call leg.
Configurations on this dial peer are used to control
signaling, media, and other aspects of the new call leg.
P–Q
path An ELCAC configuration component that is a
sequence of links and intermediate locations connecting
a pair of locations. Unified CM calculates least-cost paths
(lowest cumulative weight) from each location to all
other locations and builds a map of the various paths.
Only one effective path is used between any pair of
locations.
partition A logical grouping of callable patterns.
pattern A string of digits and wildcards that represents

a sequence of digits to match for call routing purposes.
physical location A means to link a device pool to a

site while being mindful of site-specific settings such as
date/time groups, media resources, and SRST
references.
public switched telephone network (PSTN) An

interconnected system of circuit-switched telephone
networks operated by a variety of telephony operators.
R
Real-Time Monitoring Tool (RTMT) The primary
method to get real-time diagnostic data from Unified
CM, including SIP signaling information and
downloading of trace files.
Real-Time Transport Control Protocol (RTCP) A

protocol that provides media reception feedback for the
related RTP stream.
Real-Time Transport Protocol (RTP) A framework

for the end-to-end transport of voice and video IP
networks using UDP.
regions A logical grouping of devices and the definition

of maximum bit rates allowed for audio, video, and
immersive video calls between groups.
remote destination The phone number of a device

that is called when the remote destination profile’s
associated line is called.
remote destination profile (RDP) A device that is

created and linked to an end user and a specific line.
RHS The host portion of a URI in user@host format.

Stands for right-hand side.
roaming device pool A device pool that is associated

with a phone due to the phone being in a new subnet.
Roaming Sensitive settings Settings of a device pool

that include region, date/time group, and many more.
These settings are typically related to the local resources.
For example, the date and time of the person is
dependent on where they are. When they moved from
one side of a country to another side of the same country,
they time zone might change.
route group A group of one or more gateways or trunk

devices that are logically grouped for the purpose of
distributing calls to an external destination.
route list An ordered list of route groups used to route
calls to an external system.
route pattern A pattern that allows an administrator to

associate a called number with a route to an outbound
gateway or trunk.
S
SDL trace file The primary trace file used when
troubleshooting issues with Unified CM, which contains
call signaling protocol–related messages as well as dial
plan–related messages.
Session Description Protocol (SDP) A protocol

designed to provide session details (such as the media
types, media codec, and IP/port pair for media) and
session metadata (such as the purpose of the session and
the originator of the session) to participants.
Session Initiation Protocol (SIP) A communications

protocol used for session setup, modification, and
teardown between SIP user agents (UAs).
session target The Layer 3 addressing information of

the next-hop device used by an outbound dial peer.
Single Number Reach (SNR) A Unified CM feature

that allows a user to receive calls at home when someone
calls the user’s desk phone.
static device pool A device pool that is configured on a

device's configuration page.
subscriber number A four-digit extension that maps

to a station.
T
tail-end hop off (TEHO) A process that intelligently
routes calls to the PSTN over an IP network to a remote
destination before sending the call to the PSTN to avoid
paying toll charges for a call.
time period A period of time, either by hour, day, or

date.
time schedule A grouping of time periods.
transcoder A media resource that converts one audio

codec to another, such as from G.711 to G.729.
transfer target The party receiving the transfer request

from the transferor. This participant will be connected to
the transferee when the transfer is complete.
transferee The party being transferred to the transfer

target. In a call this participant will be connected to the
transfer target when the transfer is complete.
transferor The party initiating the transfer sequence

and will be removed from the session when the transfer
is complete.
transform mask A string of characters that can be

used to manipulate a string of digits passed into the
mask by either removing digits, replacing digits, or
allowing digits from the original number to pass through
to the result.
transformation A generic term that describes any of

many different digit manipulations that can be
performed on a digit string, such as transform masks,
digit discard instructions, or prefixing digits.
transformation pattern A call routing element used

to transform either the calling party number or called
party number in various scenarios.
translation pattern A call routing element used to

perform transformations on the calling party number
and called party number prior to rerouting the call
through digit analysis.
TranslatorX A third-party tool that can be used to
parse SDL trace files and extract diagnostic data.
U–Z
urgent priority Indicates that a pattern that matches
should be used immediately, even if potential matches
exist.
user agent client (UAC) A SIP node that generates a

request.
user agent server (UAS) A SIP node that processes a

request and sends out at least one response.
user hold The audio source that is heard when a user

presses the Hold button or softkey on his or her phone.
weight An ELCAC configuration component that

provides the relative priority of a link in forming the
effective path between any pair of locations. The effective
path is the path used by Unified CM for the bandwidth
calculations, and it has the least cumulative weight of all
possible paths. Weight is used on a link to provide a cost
for the effective path and is relevant only when there is
more than one path between any two locations.
wildcard A special character in a pattern that matches

more than one digit or character.

CiscoPress - CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CiscoPress - CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide

Uploaded by

Copyright:

Available Formats

CCNP Collaboration Call

Control and Mobility

Kyzer Davis, CCIE No. 54735

Kyzer Davis, Paul Giralt, Patrick Kinane, Gonzalo

Copyright © 2021 Cisco Systems, Inc.

All rights reserved. No part of this book may be

Library of Congress Control Number: 2020945984

Warning and Disclaimer

This book is designed to provide information about the

The information is provided on an “as is” basis. The

The opinions expressed in this book belong to the author

All terms mentioned in this book that are known to be

For information about buying this title in bulk quantities,

For government sales inquiries, please contact

For questions about sales outside the U.S., please contact

At Cisco Press, our goal is to create in-depth technical

Readers' feedback is a natural continuation of this

We greatly appreciate your assistance.

Alliances Manager, Cisco Press

Director, ITP Product Management

Senior Project Editor

Prior to writing this book, Kyzer co-authored the Cisco

Paul Giralt, CCIE R&S, CCIE Voice, CCIE

Paul is the author of the classic Cisco Press title

Patrick Kinane, CCIE Collaboration No. 58284, is

Gonzalo Salgueiro, CCIE No. 4541, is a

Gonzalo is an established member of numerous industry

Gonzalo previously co-authored three Cisco Press books

Michael Mendoza, CCIE No. 34300, is based in

To my beautiful wife, who has always supported me and

This book is affectionately dedicated to my family.

To my brilliant and beautiful wife, Becky, whose infinite

To our wonderful children, Alejandro, Sofia, Gabriela,

A smaller personal thank you to Joseph House,

From Patrick Kinane: Thank you to all the other

Thank you to the TLs, PEs, DSEs, and managers within

From Gonzalo Salgueiro: Thanks to all my co-

Thanks to my management and leadership teams for

Thanks to all the technical editors and reviewers who

A hearty thanks to all the customers, developers,

Finally, thank you to everyone at Cisco Press for all the

1 Introduction to Unified Collaboration and Dial

2 VoIP Protocols: SIP and H.323

3 VoIP Protocols: RTP, RTCP, and DTMF Relay

4 Unified CM Call Routing and Digit

5 Unified CM SIP Trunk Configuration

6 Unified CM Call Control Features

8 CUBE Call Routing and Digit Manipulation

9 CUBE Interworking Features

10 Unified CME and SRST

A Answers to the “Do I Know This Already?”

B CCNP Implementing Cisco Advanced Call

D Memory Tables Answer Key

In addition to the features in each of the core chapters,

Practice exams: The companion website contains an

Interactive exercises and quizzes: The companion

Glossary quizzes: The companion website contains

To access this additional content, simply register your

Who Should Read This Book?

The Companion Website for Online Content

How This Book Is Organized

Chapter 1. Introduction to Unified Collaboration

Unified CME and Unified SRST

North American Numbering Plan (NANP)