Claccm 300-815 [PDF]

Zitiervorschau

From the Library of Green Systems LLC

CCNP Collaboration Call Control and Mobility

CLACCM 300-815 Official Cert Guide

Enhance Your Exam Preparation Save 80% on Premium Edition eBook and Practice Test The CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Premium Edition and Practice Test provides three eBook files (PDF, EPUB, and MOBI/Kindle) to read on your preferred device and an enhanced edition of the Pearson Test Prep practice test software. You also receive two additional practice exams with links for every question mapped to the PDF eBook. See the card insert in the back of the book for your Pearson Test Prep activation code and special offers.

From the Library of Green Systems LLC

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

Cisco Press

From the Library of Green Systems LLC

9780136575542_BOOK.indb 1

23/10/20 3:58 PM

ii    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, 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 authors 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 [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected].

From the Library of Green Systems LLC

9780136575542_BOOK.indb 2

23/10/20 3:58 PM

iii

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 [email protected]. 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 Executive Editor: Nancy Davis Managing Editor: Sandra Schroeder Development Editor: Ellie Bru Senior Project Editor: Tonya Simpson

Technical Editors: M  ichael Mendoza Guzman, Esteban Valverde Editorial Assistant: Cindy Teeters Cover Designer: Chuti Prasertsith Composition: codeMantra Indexer: Timothy Wright Proofreader: Donna Mulder

Copy Editor: Kitty Wilson

Americas Headquarters Cisco Systems, Inc. San Jose, CA

Asia Pacific Headquarters Cisco Systems (USA) Pte. Ltd. Singapore

Europe Headquarters Cisco Systems International BV Amsterdam, The Netherlands

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 3

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 4

23/10/20 3:58 PM

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 5

23/10/20 3:58 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 6

23/10/20 3:58 PM

vii

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. —Gonzalo I dedicate this to my wife, Archana, and my children, Rohen and Maya, for always supporting me and putting up with mountains of IP Phones, video devices, and network gear found around the house enabling me to do things like write this book. —Paul

From the Library of Green Systems LLC

9780136575542_BOOK.indb 7

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 8

23/10/20 3:58 PM

ix 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. From Paul Giralt: Thank you to Kyzer for coming up with the idea to write this book and having the dedication to keep everything moving along to get it to the finish line. Also thank you to the other authors, who have been incredibly passionate about producing the best quality publication possible. It’s been a pleasure working with all of you. I’d also like to thank all our customers, who have supported our journey from the first IP phone more than 20 years ago. For those of you I have had the pleasure of working with, who read my previous books or attended Cisco Live sessions to learn more about how you can design, deploy, and troubleshoot Cisco’s collaboration portfolio, we couldn’t have gotten here without you. Keep challenging us to improve and evolve. Thanks to all the reviewers for your excellent feedback, and to the Cisco Press team, who made the authoring process seamless. All your work makes us look good, and I appreciate the dedication and attention to detail.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 9

23/10/20 3:58 PM

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

Contents at a Glance Introduction  xxiv Chapter 1

Introduction to Unified Collaboration and Dial Plans  2

Chapter 2

VoIP Protocols: SIP and H.323  28

Chapter 3

VoIP Protocols: RTP, RTCP, and DTMF Relay  72

Chapter 4

Unified CM Call Routing and Digit Manipulation  120

Chapter 5

Unified CM SIP Trunk Configuration  226

Chapter 6

Unified CM Call Control Features  264

Chapter 7

Unified CM Mobility  316

Chapter 8

CUBE Call Routing and Digit Manipulation  386

Chapter 9

CUBE Interworking Features  468

Chapter 10

Unified CME and SRST  552

Chapter 11

Final Preparation   606

Appendix A Answers to the “Do I Know This Already?” Quiz Questions  612 Appendix B CCNP Implementing Cisco Advanced Call Control and Mobility Services CLACCM 300-815 Exam Updates  620 Glossary  623 Index  632 Online Elements Appendix C Memory Tables Appendix D Memory Tables Answer Key Appendix E

Study Planner



Glossary

From the Library of Green Systems LLC

9780136575542_BOOK.indb 10

23/10/20 3:58 PM

xi

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. Key Term flash cards: 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 11

23/10/20 3:58 PM

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

Contents

Introduction  xxiv

Chapter 1

Introduction to Unified Collaboration and Dial Plans  2 “Do I Know This Already?” Quiz  2 Foundation Topics   4 Introduction to Cisco Unified Collaboration Components  4 Unified CM  9 Cisco Unified Border Element  12 Unified CME and Unified SRST  14 Dial Plan Design Overview  14 Why Dial Plan Design Is Difficult  14 North American Numbering Plan (NANP)  17 International Dial Plans with E.164  18 Case Study: Building a Globalized Dial Plan  20 Task 1: On-Net Calling Between IP Phones  22 Task 2a: Abbreviated Dialing Between Locations  23 Task 2b: Abbreviated Dialing Within the Location  23 Task 2c: Forced On-Net Calling  23 Task 3: Outbound PSTN Calls  23 Task 4: Inbound PSTN Calls  24 Task 5: PSTN Dial Plan Redundancy  24 Task 6: Emergency Calling  25 Task 7: URI Dialing  25 Closing Remarks  25 References  26 Exam Preparation Tasks  26 Review All Key Topics  26 Complete Tables and Lists from Memory  27 Define Key Terms  27

Chapter 2

VoIP Protocols: SIP and H.323  28 “Do I Know This Already?” Quiz  29 Foundation Topics  31 Overview of SIP  31 Brief Introduction to and History of SIP  31 SIP Operation  32 SIP Methods  35

From the Library of Green Systems LLC

9780136575542_BOOK.indb 12

23/10/20 3:58 PM

Contents     xiii Breaking Down a SIP Call  36 Forming a Request  37 Forming a Response  41 Analyzing a Basic SIP Call  45 Introduction to SDP  48 The Offer/Answer Framework  52 Operation of the Offer/Answer Framework  52 Generating the SDP Offer and Answer  52 Modifying a Session  59 Adding a Media Stream  62 Removing a Media Stream  66 Modifying the Address, Port, Transport, or Media Format  66 Overview of H.323  67 H.323 Components  67 H.323 Call Flow  68 References  70 Exam Preparation Tasks  70 Review All Key Topics  70 Complete Tables and Lists from Memory  71 Define Key Terms  71 Chapter 3

VoIP Protocols: RTP, RTCP, and DTMF Relay  72 “Do I Know This Already?” Quiz  73 Foundation Topics  75 Introduction to Real-Time Media  75 Real-Time Transport Protocol  78 Real-Time Transport Control Protocol  86 RTCP Sender Report (SR)  88 RTCP Receiver Report (RR)  89 RTCP Source Description (SDES) Packet  91 RTCP Goodbye (BYE) Packet  92 RTCP Application-Defined Packet (APP)  93 Other RTCP Packet Types  93 RTCP Transport  93 DTMF Relay  93 Introduction to DTMF Relay  94 Variants of DTMF Relay  95 In-Band DTMF Relay  96 Named Telephony Events  96 From the Library of Green Systems LLC

9780136575542_BOOK.indb 13

23/10/20 3:58 PM

xiv    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Raw In-Band Tones  100 Out-of-Band DTMF Relay  101 SIP INFO  102 SIP KPML  103 SIP Notify  113 H.245 Alphanumeric and Signal  116 Other DTMF Relay Variants  116 References  116 Exam Preparation Tasks  117 Review All Key Topics  118 Complete Tables and Lists from Memory  118 Define Key Terms  118 Chapter 4

Unified CM Call Routing and Digit Manipulation  120 “Do I Know This Already?” Quiz  121 Foundation Topics   125 Pattern Matching  125 Numeric Matching  126 Closest-Match Routing  128 Digit-by-Digit Versus Enbloc Calling  129 Alphanumeric URI Dialing  130 Transformations and Masks  131 Digit Discard Instructions  131 Transform Masks  131 Prefix Digits  132 Combining Transformations  132 Pattern Configuration and Device Selection  133 Directory Numbers  134 Route Patterns, Route Lists, and Route Groups  136 Route Patterns  137 Route Lists  143 Route Groups  146 Local Route Group  148 Hunt Pilots, Hunt Lists, and Line Groups  150 Line Groups  150 Hunt Lists  152 Hunt Pilots  152

From the Library of Green Systems LLC

9780136575542_BOOK.indb 14

23/10/20 3:58 PM

Contents     xv Partitions and Calling Search Spaces  155 Time of Day Routing  162 Translation Patterns  164 Transformation Patterns  168 Putting It All Together: Tail-End Hop Off (TEHO)  177 Alphanumeric URI Routing  184 Intercluster Dial Plan Replication  188 Intercluster Lookup Service (ILS)  188 Global Dial Plan Replication  191 Troubleshooting Call Routing and Digit Manipulation  198 Dialed Number Analyzer  198 Real-Time Monitoring Tool   204 Troubleshooting Call Routing by Using SDL Trace Files  207 TranslatorX  215 Collaboration Solutions Analyzer  220 Exam Preparation Tasks  223 Review All Key Topics  223 Complete Tables and Lists from Memory  224 Define Key Terms  225 Chapter 5

Unified CM SIP Trunk Configuration  226 “Do I Know This Already?” Quiz  227 Foundation Topics  229 SIP Trunk Overview and Configuration  229 SIP Trunk Configuration  232 Device Information Section  232 Call Routing Information Section  236 SIP Information Section  244 SIP Trunk Security Profile Configuration  247 Incoming Transport Type  248 Outgoing Transport Type  248 Incoming Port  249 Accept Unsolicited Notification  249 Accept Replaces Header  249 SIP Profile Information Configurations  250 SIP Rel1XX Options  251 Session Refresh Method  252 Reject Anonymous Incoming Calls  252 Reject Anonymous Outgoing Calls  253 From the Library of Green Systems LLC

9780136575542_BOOK.indb 15

23/10/20 3:58 PM

xvi    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide SIP Trunk Features  254 SIP Early Offer Versus SIP Delayed Offer   254 SIP OPTIONS Ping  255 Media Termination Point Required  257 Run On All Active Unified CM Nodes  258 Verify and Troubleshoot Unified CM SIP Trunks  260 Packet Captures (PCAPs)  260 OPTIONS Ping  261 Changing Transport Types  261 CallManager SDL Traces  261 Reset the Trunk  261 References  262 Exam Preparation Tasks  262 Review All Key Topics  262 Complete Tables and Lists from Memory  263 Define Key Terms  263 Chapter 6

Unified CM Call Control Features  264 “Do I Know This Already?” Quiz  265 Foundation Topics  268 Media Resources  268 Ad Hoc and Meet-Me Conferencing  269 Music on Hold (MOH)  280 Media Resource Groups and Media Resource Group Lists  286 Call Park  287 Call Pickup  291 Regions and Codec Preferences  293 Regions  293 Audio Codec Preference Lists  295 Configure Interregion and Intraregion Policies  296 Call Admission Control (CAC)  299 Location Bandwidth Manager Service  300 Configure Enhanced Location Call Admission Control (ELCAC)  301 Automated Alternate Routing (AAR)  306 Troubleshooting and Monitoring Enhanced Location Call Admission Control  309 Exam Preparation Tasks  313 Review All Key Topics  313

From the Library of Green Systems LLC

9780136575542_BOOK.indb 16

23/10/20 3:58 PM

Contents     xvii Complete Tables and Lists from Memory  314 Define Key Terms  314 Chapter 7

Unified CM Mobility  316 “Do I Know This Already?” Quiz  317 Foundation Topics  320 Unified Mobility  320 Configure and Verify Single Number Reach  320 Configure Single Number Reach  322 Advanced Single Number Reach Configuration  328 SNR Timers  328 SNR Ring Schedule  330 SNR Access Lists  331 Inbound Remote Destination Caller ID and Intelligent Session Control  332 Troubleshoot Single Number Reach  334 Configure and Verify Move to Mobile  345 Troubleshoot Move to Mobile  348 Configure and Verify Extension Mobility  355 Troubleshoot Extension Mobility  363 Configure and Verify Device Mobility  371 Troubleshoot Device Mobility  382 References  384 Exam Preparation Tasks  384 Review All Key Topics  384 Complete Tables and Lists from Memory  384 Define Key Terms  384

Chapter 8

CUBE Call Routing and Digit Manipulation  386 “Do I Know This Already?” Quiz  387 Foundation Topics  389 Understanding Call Legs and Call Flows  389 IOS Dial Peers  392 Inbound Dial Peer Matching  393 Tiebreakers and Longest and Most Specific Matching Logic  394 Dial Peer Wildcards and Regex  395 Dial Peer Filtering  396 Dial Peer 0, the Default Inbound Dial Peer  397

From the Library of Green Systems LLC

9780136575542_BOOK.indb 17

23/10/20 3:58 PM

xviii    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Matching Inbound Call Legs Using incoming called-number Commands  398 Matching Inbound Call Legs Using URIs  399 Outbound Dial Peer Matching  402 Outbound Dial Peer Hunting Logic and Tiebreakers  403 Routing Calls with destination-pattern and session target  404 Matching Outbound Dial Peers Using URIs  408 Dial Peer Aggregation and Summarization Techniques  410 E.164 Pattern Maps  410 Session Server Groups  412 DNS SRV Load Balancing  413 Putting It Together  415 Advanced Call Routing Techniques  417 Dial Peer Groups (DPGs)  417 Sourced-Based Call Routing with Dial Peer Groups  418 Dial Peer Provision Policy Routing  419 Dial Peer Groups Versus Dial Peer Provision Policies  421 Intercluster Lookup Service (ILS) Call Routing on CUBE  421 Next-Hop Availability Through SIP OPTIONS  424 Verify and Troubleshoot IOS Call Routing  426 Basic CUBE Call Routing Debug Analysis  428 Application Signaling and Media Binding  433 Digit, Header, and URI Manipulation  441 Digit Manipulation  442 Voice Translation Rules and Profiles  442 Understanding Match and Modify Statements  444 Blocking Calls with Translation Rules  446 Troubleshooting Voice Translations  447 SIP Header Interworking  448 SIP Normalization  450 SIP Profile Configuration  451 Outbound SIP Profiles  454 Inbound SIP Profiles  457 SIP Copylist  460 Common SIP Profiles  461 Troubleshooting SIP Profiles  464 References  465 Exam Preparation Tasks  465

From the Library of Green Systems LLC

9780136575542_BOOK.indb 18

23/10/20 3:58 PM

Contents     xix Review All Key Topics  466 Complete Tables and Lists from Memory  466 Define Key Terms  467 Chapter 9

CUBE Interworking Features  468 “Do I Know This Already?” Quiz  469 Foundation Topics  471 SIP–SIP Interworking  471 Early Offer and Delayed Offer Interworking  471 Reliable Handling and Interworking of Provisional Responses  472 Ringback and Provisional Response Interworking  477 Mid-call Signaling  481 Hold/Resume  481 Call Transfer  489 REFER Transfer  489 INVITE Transfer  495 REFER Versus INVITE Transfers  504 UPDATE Interworking  505 Session Refresh  509 Managing Mid-call Signaling  515 SIP Authentication with CUBE  518 Toll Fraud Prevention  518 SIP Trunk Registration  520 SIP Digest Authentication  523 SIP Header–Based Authentication  524 Media Interworking  524 Audio Codec Interworking  525 Dial Peer Codecs  525 Codec Filtering  527 Voice Class Codecs  528 CUBE LTI Transcoder  531 Codec Transparent and SDP Passthrough  535 Video Interworking and Suppression  537 Media Flow-Through Versus Media Flow-Around  539 Music on Hold  541 DTMF Interworking  543 Troubleshooting CUBE Media  545

From the Library of Green Systems LLC

9780136575542_BOOK.indb 19

23/10/20 3:58 PM

xx    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Other CUBE Features  548 References  548 Exam Preparation Tasks  549 Review All Key Topics  549 Complete Tables and Lists from Memory  550 Define Key Terms  550 Chapter 10 Unified CME and SRST  552 “Do I Know This Already?” Quiz  553 Foundation Topics   556 Introduction to Unified CME and Unified SRST  556 Unified CME Initial Configuration  557 SIP Phone Manual Registration  560 Unified CME IP Phone Registration Overview  565 SIP Phone Auto-Registration  570 Unified CME Dial Design  579 Unified CME Virtual Dial Peers  580 Unified CME SIP Trunking  583 Unified CME Call Coverage Features  585 Configure Unified CME Hunt Groups  585 Configure Unified CME Multicast Paging  589 Configure Unified CME Call Park  592 Parking a Call  593 Call Park Retrieval  596 Survivable Remote Site Telephony (Unified SRST)  597 Implement SIP Unified SRST on Unified CM  598 Implement SIP Unified SRST on an IOS Gateway  600 Verify and Troubleshoot SIP Unified SRST Failover  601 References  604 Exam Preparation Tasks  604 Review All Key Topics  604 Complete Tables and Lists from Memory  605 Define Key Terms  605 Chapter 11 Final Preparation   606 Getting Ready  606 Tools for Final Preparation  607 Pearson Cert Practice Test Engine and Questions on the Website  607

From the Library of Green Systems LLC

9780136575542_BOOK.indb 20

23/10/20 3:58 PM

Contents     xxi Accessing the Pearson Test Prep Software Online  607 Accessing the Pearson Test Prep Software Offline  608 Customizing Your Exams  608 Updating Your Exams  609 Premium Edition  609 Chapter-Ending Review Tools  610 Suggested Plan for Final Review/Study  610 Summary  610 Appendix A Answers to the “Do I Know This Already?” Quiz Questions  612 Appendix B CCNP Implementing Cisco Advanced Call Control and Mobility Services CLACCM 300-815 Exam Updates  620 Glossary  623 Index  632 Online Elements Appendix C Memory Tables Appendix D Memory Tables Answer Key Appendix E

Study Planner



Glossary

From the Library of Green Systems LLC

9780136575542_BOOK.indb 21

23/10/20 3:58 PM

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

Icons Used in This Book

Phone/IP Phone

Media Control Unit

Cisco Instant Message and Presence

Enterprise

Unified Border Element

Cisco Video Communications Server Control

Server

Firewall

Unified CM

Unified CM

SIP Proxy Server

Cisco SRST Manager

Unified CM

Voice Gateway

Router

Telephony Router

Cloud

Cisco Unity Connection

V Cisco Prime Collaboration

Voice Router

From the Library of Green Systems LLC

A01_Davis_FM_i-xxxi.indd 22

23/10/20 7:43 PM

xxiii

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 23

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 24

23/10/20 3:58 PM

Introduction     xxv 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:

From the Library of Green Systems LLC

9780136575542_BOOK.indb 25

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 26

23/10/20 3:58 PM

Introduction     xxvii

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 vendorneutral 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 content 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 27

23/10/20 3:58 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 28

23/10/20 3:58 PM

Introduction     xxix Table I-1  CCNP CLACCM 300-815 Exam Topics and Chapter References Exam Topic

Chapter(s) in Which Topic Is Covered

1.1 Troubleshoot these elements of a SIP conversation

2, 5, 6, 9

1.1.a Early media

2, 5, 9

1.1.b PRACK

9

1.1.c Mid-call signaling (hold/resume, call transfer, conferencing)

2, 6, 9

1.1.d Session timers

5, 9

1.1.e UPDATE

2, 9

1.2 Troubleshoot these H.323 protocol elements

2, 3, 9

1.2.a DTMF

3, 9

1.2.b Call set up and tear down

2, 9

1.3 Troubleshoot media establishment

3, 5, 6, 9

2.1 Configure Cisco Unified Communications Manager Express for SIP phone registration

10

2.2 Configure Cisco Unified CME dial plans

10

2.3 Implement toll fraud prevention

10

2.4 Configure these advanced Cisco Unified CME features

10

2.4.a Hunt groups

10

2.4.b Call park

10

2.4.c Paging

10

2.5 Configure SIP SRST gateway

10

3.1 Configure these Cisco Unified Border Element dial plan elements

8, 9

3.1.a DTMF

3, 9

3.1.b Voice translation rules and profiles

8

3.1.c Codec preference list

9

3.1.d Dial peers

8

3.1.e Header and SDP manipulation with SIP profiles

8

3.1.f Signaling and media bindings

8

3.2 Troubleshoot these Cisco Unified Border Element dial plan elements

8, 9

3.2.a DTMF

3, 9

3.2.b Voice translation rules and profiles

8

3.2.c Codec preference list

9

3.2.d Dial peers

8

3.2.e Header and SDP manipulation with SIP profiles

8

3.2.f Signaling and media bindings

8

4.1 Configure these globalized call routing elements in Cisco Unified Communications Manager

4, 5

From the Library of Green Systems LLC

9780136575542_BOOK.indb 29

23/10/20 3:58 PM

xxx    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Exam Topic

Chapter(s) in Which Topic Is Covered

4.1.a Translation patterns

4

4.1.b Route patterns

4

4.1.c SIP route patterns

4

4.1.d Transformation patterns

4

4.1.e Standard local route group

4

4.1.f TEHO

4

4.1.g SIP trunking

5

4.2 Troubleshoot these globalized call routing elements in Cisco Unified Communications Manager

4, 5

4.2.a Translation patterns

4

4.2.b Route patterns

4

4.2.c SIP route patterns

4

4.2.d Transformation patterns

4

4.2.e Standard local route group

4

4.2.f TEHO

4

4.2.g SIP trunking

5

5.1 Troubleshoot Call Admission Control (exclude RSVP)

6

5.2 Configure ILS, URI synchronization, and GDPR

4

5.3 Configure hunt groups

4

5.4 Configure call queuing

4

5.5 Configure time of day routing

4

5.6 Configure supplementary functions

6

5.6.a Call park

6

5.6.b Meet-me

6

5.6.c Call pick-up

6

6.1 Configure Cisco Unified Communications Manager Mobility

7

6.1.a Unified Mobility

7

6.1.b Extension Mobility

7

6.1.c Device Mobility

7

6.2 Troubleshoot Cisco Unified Communications Manager Mobility

7

6.2.a Unified Mobility

7

6.2.b Extension Mobility

7

6.2.c Device Mobility

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 30

23/10/20 3:58 PM

Introduction    xxxi 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 https://learningnetwork.cisco.com/s/ claccm-exam-topics. Note also that, if needed, Cisco Press might post additional preparatory content on the web page associated with this book at 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 Credit Figure 3-6, screenshot of Wireshark ptime example © Wireshark

From the Library of Green Systems LLC

A01_Davis_FM_i-xxxi.indd 31

23/10/20 7:45 PM

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 Foundation Topics Section

Questions

Introduction to Cisco Unified Collaboration Components

1–4

Dial Plan Design Overview

5–7

From the Library of Green Systems LLC

9780136575542_BOOK.indb 2

23/10/20 3:58 PM

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 3

23/10/20 3:58 PM

4    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 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 onpremises 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 4

23/10/20 3:58 PM

9780136575542_BOOK.indb 5

Cisco Prime Collaboration Provisioning

Conferencing

Telepresence Management Suite

Collaboration Edge

Integrated/Aggregated Services Router

Cisco Meeting Server

Unified Communications Manager

Expressway-C

DMZ

Expressway-E

Figure 1-1  Cisco UC Architecture Overview

Endpoints

Voice Messaging

Unity Connection

Call Control

IM and Presence

Collaboration Management Services

Cisco Prime Collaboration Deployment

Headquarters

PSTN

MPLS WAN

Internet

Remote Site

V

Integrated Services Router

Cloud Collaboration

Mobile/Teleworker

Chapter 1: Introduction to Unified Collaboration and Dial Plans     5

1

From the Library of Green Systems LLC

23/10/20 3:58 PM

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

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 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-premises 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 applications 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 6

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     7 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.)

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 7

23/10/20 3:58 PM

9780136575542_BOOK.indb 8 On Prem Endpoints

SIP

SIP

SIP

SIP

Meeting Telepresence Server Management Server

Unified CM Cluster

IM&P Cluster

V

SIP

Unified CM Cluster

On Prem Endpoints

SCCP

IOS Media Resources

SIP

SIP/H.323

V

SIP

Expressway with Unified Edge

CUBE

MPLS

SIP

Remote Site

Figure 1-2  A Common Cisco UC Topology with Collaboration Components

CUC Voicemail Clusters

Shared Services

SIP

SIP

SIP

Mobile and Remote Workers

Internet

PSTN

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

From the Library of Green Systems LLC

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     9 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 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.

1

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 9

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 10

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     11 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. Unified CM Cluster

1

Publisher

TFTP First Call Processing Nodes Second Call Processing Nodes

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 11

23/10/20 3:58 PM

12    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Unified CM Cluster (SJ)

SME

Unified CM Cluster (RTP)

Unified CM Cluster (London)

Figure 1-4  Three-Cluster SME Design

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 is 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 12

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     13 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.

1

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/standby high-availability pair to provide redundancy and failover of ongoing calls in the event of a link failure. SIP Trunk with PSTN Access via CUBE ITSP

Centralized Deployment

Distributed Deployment ITSP

ITSP

WAN

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 13

23/10/20 3:58 PM

14    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 provides 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 14

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     15 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 that 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.

1

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 15

23/10/20 3:58 PM

16    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 16

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans    17 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.

1

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 IP Phone, Application, or another endpoint.

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.

From the Library of Green Systems LLC

M01_Davis_C01_p002-p027.indd 17

23/10/20 7:26 PM

18    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 1-2  Sample NPA and NXX Numbers from Cisco Systems NPA (Area Code)

NXX

XXXX

408

526

7209

408

525

6800

919

392

2000

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.

408-526-7209 408-525-6800

919-392-2000

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 18

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     19 Table 1-3  International Cisco Numbers Country Code

National Destination Code

Subscriber

+1

408

526 7209

+32

2

704 55 55

+49

89

51657 2000

+90

212

366 7636

1

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 NXXXXXX. 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 Country Code

Country

+1

North America

+20

Egypt

+27

South Africa

+32

Belgium

From the Library of Green Systems LLC

9780136575542_BOOK.indb 19

23/10/20 3:58 PM

20    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Country Code

Country

+44

United Kingdom

+49

Germany

+52

Mexico

+55

Brazil

+61

Australia

+7

Russia

+81

Japan

+86

China

+90

Turkey

+91

India

+299

Greenland

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

+299 +7 +1

+44 +49 +90

+1

+20

+52

+86

+81

+91

+55 +27

+61

Figure 1-7  World Map Showing the Country Codes from Table 1-4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 20

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     21 +1 408 525 6800 +32 2 704 5555

PSTN

1

Remote Site (Turkey) SJ CUBE

V

197

RTP CUBE

+90 212 366 7636

140 SJ Unified CM Cluster

+1 408 526 72XX

191 MPLS

SJ Endpoint

RTP Unified CM Cluster

+1 919 392 2XXX

RTP Endpoint

+1 408 526 7209 [email protected]

+1 919 392 2000 [email protected]

SIP

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 21

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 22

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans    23

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.

1

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 knows 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 off-net 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.

From the Library of Green Systems LLC

M01_Davis_C01_p002-p027.indd 23

23/10/20 7:26 PM

24    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 1-5  PSTN Call Samples Sourced from RTP Cluster Call Type

Dial Habit

Example(s)

Local call

9 + 7 digits

95256800

National call, 10-digit dialing

9 + 10 digits

94085256800

National call, 11-digit dialing

91 + 10 digits

914085256800 919193922000

International call

9011 + country code + number

90113227045555 9011902123667363

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 Call Type

Dial Habit

Example(s)

National call

9 + number

92123667636

International call

900 + country code + number

90014085256800 90014085267209 90019193922000 9003227045555

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 24

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     25 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.

1

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 uniform resource identifier (URI) dialing, and it is especially useful when using soft clients that allow for user directory searches and click-todial. 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 [email protected], 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 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 25

23/10/20 3:58 PM

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

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/CVD/Collaboration/ enterprise/12x/120/collbcvd/control.html Cisco, “Cisco Collaboration System 12.x Solution Reference Network Designs (SRND),” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12.html Inamdar, Kaustubh, Steve Holl, Gonzalo Salgueiro, Kyzer Davis, and Chidambaram Arunachalam. Understanding Session Border Controllers: Comprehensive Guide to Designing, Deploying, 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: 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 Key Topic Element

Description

Page

Figure 1-2

A Common Cisco UC Topology with Collaboration Components

8

List

List of Unified CM features

9

Figure 1-5

CUBE Integrating with a Service Provider and Unified CM for Different Deployment Scenarios

13

List

Aspects of poor dial-plan design

16

List

NPA-NXX explained

17

Table 1-4

Sample Country Codes from Around the World

19

Paragraph

How to dial local, long-distance, national, and international calls

23

Paragraph

Emergency calling

25

From the Library of Green Systems LLC

9780136575542_BOOK.indb 26

23/10/20 3:58 PM

Chapter 1: Introduction to Unified Collaboration and Dial Plans     27

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.

1

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 (off-net), public switched telephone network (PSTN), Internet telephony service provider (ITSP)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 27

23/10/20 3:58 PM

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 28

23/10/20 3:58 PM

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 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 is 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 HTTPlike 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.

“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 2-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.”

From the Library of Green Systems LLC

9780136575542_BOOK.indb 29

23/10/20 3:58 PM

30    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 2-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Overview of SIP

1–3

Introduction to SDP

4–6

Overview of H.323

7–9

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 30

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    31 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

2

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 use cases 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)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 31

23/10/20 3:58 PM

32    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. UAS

UAC

INVITE Transaction 1 200 OK ACK

Transaction ACK

SIP Dialog Session Established

BYE Transaction 2 200 OK

Figure 2-1  Sample SIP Dialog with Two Transactions

From the Library of Green Systems LLC

9780136575542_BOOK.indb 32

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    33 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 sends 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.)

2

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 33

23/10/20 3:58 PM

34    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.”

From the Library of Green Systems LLC

9780136575542_BOOK.indb 34

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    35 ■■

Location server: A location server contains a mapping between a user agent’s AOR and location; it does not need to be 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.

2

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 SIP Request

Description

INVITE

A caller sends out this message to request another entity to establish a SIP session.

ACK

This indicates that the client has received a final response to an INVITE request.

OPTIONS

This request queries the server for its capabilities.

BYE

This is used by the UAC to indicate to the server that it wishes to terminate the established SIP session. (Note that this request can be issued by the caller or the callee.)

CANCEL

This is used to cancel a pending request and can be sent only if the server has not replied with a final response.

REGISTER

A client uses this message to register the address listed in the To header field with a SIP registrar server.

PRACK

This provisional acknowledgment is used to ensure that provisional responses are received reliably. (For more details on this message, see Chapter 9.)

SUBSCRIBE

This creates a subscription for important event notification. (For more details about this message, see Chapter 3, “VoIP Protocols: RTP, RTCP, and DTMF Relay.”)

NOTIFY

This notifies the subscriber of the occurrence of an event. (For more details about this method, see Chapter 3.)

INFO

This allows the exchange of application-level information among communicating entities. Information is exchanged without affecting the state of the SIP transaction or dialog.

PUBLISH

This publishes an event to the server.

REFER

This instructs the recipient to contact another entity, using the information specified in this request. (For more details about this message, see Chapter 9.)

UPDATE

This modifies the state of the session without changing the state of the dialog. (For more details about this message, see Chapter 9.)

MESSAGE

This transports instant messages using SIP.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 35

23/10/20 3:58 PM

36    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Class of Response

Meaning

Type of Response

1XX

Informational: The request has been received and is being processed.

Provisional

2XX

Success: The request has been received, understood, and accepted.

Final

3XX

Redirection: Further action needs to be taken to complete the request. For example, the UAC needs to contact another server to process the request.

Final

4XX

Client error: The request contains bad syntax (such as malformed headers) or could not be fulfilled at the server (for example, if the server could not find the number referenced in the requested URI).

Final

5XX

Server error: A server failed to fulfill a valid request.

Final

6XX

Global failure: The request could not be fulfilled at any server.

Final

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 36

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    37

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

2

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 RemoteParty-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:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP 14.50.214.109:49850;branch=z9hG4bK43660dee From: "+14085557890" ;tag=c4b36abac To: Call-ID: [email protected] Session-ID: 735c6c0600105000a000c4b36abaca23;remote=00000000000000000000000000000000 Max-Forwards: 70 CSeq: 101 INVITE Contact: Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer Accept: application/sdp User-Agent: Cisco-CP8865/12.7.1 Expires: 180 Remote-Party-ID: "+14085557890" ; party=calling;id-type=subscriber;privacy=off;screen=yes

From the Library of Green Systems LLC

9780136575542_BOOK.indb 37

23/10/20 3:58 PM

38    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 final 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 38

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    39 ■■

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. User agents must ensure that this header field is generated in such a way 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. 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:

2

CSeq: where 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 39

23/10/20 3:58 PM

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

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: Allow: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 universally supported 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.)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 40

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    41 ■■

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 primarily used for caller identification. The data from this header field often supersedes 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.

2

Table 2-4 summarizes the mandatory, method-dependent, and optional headers for a SIP INVITE message. As mentioned previously, different SIP methods have different methoddependent and optional headers. Table 2-4  Classification of Headers in SIP INVITE Messages Header Fields

Requirement

Request-URI, Via, From, To, Call-ID, Max-Forwards, CSeq

Mandatory for all SIP messages

Contact, Allow, Supported, Accept

Required for INVITE messages and optional for other methods

Require, Expires, Diversion, Remote-Party-ID, P-Asserted-Identity

Optional for 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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 41

23/10/20 3:58 PM

42    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Receive Request

Method Supported?

No

405 Method Not Allowed

Check To and Request-URI

Target Domain?

Send Relevant 4XX Response

No

Yes

Has the Request Been Looped?

Send 482 Loop Detected Response

Yes

No Special Handling of Request Required

Extension Supported?

Yes

No

Send 420 Bad Extension Response

Yes

Message Body Understood?

No

Reject Request

Yes

Server Extensions Supported?

No

Send 421 Extension Required Response

Send Provisional or Final Response

Figure 2-2  SIP Request Processing Logic

From the Library of Green Systems LLC

9780136575542_BOOK.indb 42

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    43 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 correct formatting 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.

2

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 43

23/10/20 3:58 PM

44    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 44

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    45 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.

2

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 Via: SIP/2.0/TCP 14.50.214.109:49850;branch=z9hG4bK43660dee From: "+14085557890" ;tag=c4b36abac To: ;tag=279932 Call-ID: [email protected] CSeq: 101 INVITE Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Server: Cisco-CUCM12.5 Remote-Party-ID: ;party=called;screen=yes;privacy=off Session-ID: 0f3add4b00105000a000d0ec35ffeafe;remote=735c6c0600105000a000c4b36abaca23 Contact:

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 45

23/10/20 3:58 PM

46    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 in the middle of the signaling for both phones and aids in the establishment of the communication session. Phone A

Phone B

Unified CM

INVITE (with SDP) 100 Trying

INVITE (with SDP) 100 Trying 180 Ringing

180 Ringing 200 OK (with SDP) 200 OK (with SDP) ACK

ACK RTP

Figure 2-3  Analyzing a Basic SIP Call The SIP call in Figure 2-3 involves the following steps: 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.

From the Library of Green Systems LLC

M02_Davis_C02_p028-p071.indd 46

23/10/20 7:34 PM

Chapter 2: VoIP Protocols: SIP and H.323    47 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

2

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 47

23/10/20 3:58 PM

48    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 for most scenarios 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 their 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 relies on 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 it is leveraged by 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 leveraged by several 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: =[CRLF] From the Library of Green Systems LLC

9780136575542_BOOK.indb 48

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    49 Attributes are the primary means of extending SDP. Over time, to enable several application use cases 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=. A property attribute conveys a simple Boolean meaning for media or the session.

■■

Value attributes: These attributes are in the format a=:.

2

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= 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, G.711, H.264)

■■

Optionally, the IP address and port pair for media

From the Library of Green Systems LLC

9780136575542_BOOK.indb 49

23/10/20 3:58 PM

50    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Field/Attribute

Description

Mandatory or Optional?

Session Description v=

Protocol version

Mandatory

o=

Originator and session identifier

Mandatory

s=

Session name

Mandatory

i=

Session information

Optional

u=

URI of description

Optional

e=

Email address

Optional

p=

Phone number

Optional

c=

Connection information; not required if included in all media

Optional

b=

Zero or more bandwidth information lines

Optional

z=

Time zone adjustments

Optional

k=

Encryption key

Optional

a=

Zero or more session attribute lines

Optional

t=

Time the session is active

Mandatory

r=

Zero or more repeat times

Optional

Time Description

Media Description (If Present) m=

Media name and transport address

Mandatory

i=

Media title

Optional

c=

Connection information; optional if included at the session level

Optional

b=

Zero or more bandwidth information lines

Optional

k=

Encryption key

Optional

a=

Zero or more media attribute lines

Optional

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 50

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    51 Example 2-3  SDP Body Carried Within a SIP Message v=0 o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94.64.12 s=SIP Call

2

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 medialevel 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 o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94.64.12 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=sendrecv a=ptime:20

From the Library of Green Systems LLC

9780136575542_BOOK.indb 51

23/10/20 3:58 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 52

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    53 Delayed Offer UAC

Early Offer UAS

UAC

UAS

INVITE with SDP

Offer

Offer

200 OK with SDP

Answer

Answer

ACK without SDP

INVITE without SDP 200 OK with SDP ACK with SDP

Session Established

2

Session Established

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= The 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 subfield is used to advertise the port number on which media reception is expected. It is a common misconception that the port number signifies the port number from which media is sourced. Although most implementations utilize symmetric RTP, which does source RTP from the same port advertised by SDP for RTP reception, some implementations may utilize asymmetric RTP, which may use another source port. For media transport protocols such as RTP, the peer protocol Real-Time Transport Control Protocol (RTCP)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 53

23/10/20 3:58 PM

54    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94.64.12 s=SIP Call c=IN IP4 10.1.1.1 t=0 0 a=recvonly m=audio 16590 RTP/AVP 8 101 a=rtcp:53020 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 54

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    55 Table 2-6  Mapping Between Payload Numbers and Media Formats for Common Audio Codecs Payload Type

Encoding Name

Clock Rate (Hz)

0

PCMU

8000

4

G723

8000

8

PCMA

8000

9

G722

8000

15

G728

8000

18

G729

8000

2

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 well adopted practice. 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:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:114 opus/48000/2 a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000 ;stereo=0;sprop-stereo=0;usedtx=0

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 55

23/10/20 3:58 PM

56    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 meaning of each Direction Attribute. Table 2-7  SDP Direction Attributes Description Direction Attribute

Direction of Media

sendonly

The sender wishes to only send media to its peer.

recvonly

The sender wishes to only receive media from its peer.

sendrecv

The sender wishes to send and receive media.

inactive

The sender wishes to set up the session but not transmit or receive media.

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 56

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    57 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

2

[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:0 PCMU/8000 a=rtpmap:8 PCMA/8000 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=1;level-asymmetry-allowed=1; max-mbps=108000;max-fs=3600;max-rcmd-nalu-size=256000 a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50] a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=428016;packetization-mode=0;level-asymmetry-allowed=1; max-mbps=108000;max-fs=3600;max-rcmd-nalu-size=256000 a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50]

[Answer] v=0 o=CiscoSystemsCCM-SIP 279932 1 IN IP4 172.18.110.91 s=SIP Call c=IN IP4 14.50.214.107 b=AS:384 t=0 0 m=audio 49172 RTP/AVP 8 a=rtpmap:8 PCMA/8000 m=video 0 RTP/AVP 126 a=rtpmap:126 H264/90000

NOTE  If there are no media formats in common for all streams, the entire offer session is rejected.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 57

23/10/20 3:58 PM

58    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Direction Attribute in Offer

Direction Attribute in an Answer

sendonly

recvonly/inactive

recvonly

sendonly/inactive

sendrecv

sendrecv/sendonly/recvonly/inactive

inactive

inactive

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 58

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    59

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. User Agent 1

2

User Agent 2

SDP Offer

SDP Answer

Session Established Updated SDP Offer

Application Interaction Requiring a Session Modification

SDP Answer

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 can be simple or 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 ContentLength SIP header fields.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 59

23/10/20 3:58 PM

60    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 2-8  Incrementing the SDP Originator Version Number [Original SIP+SDP] Content-Type: application/sdp Content-Length: 283 v=0 o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94.64.12 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

[Modified SIP+SDP] Content-Type: application/sdp Content-Length: 227 v=0 o=CiscoSystemsSIP-GW-UserAgent 1597 5835 IN IP4 10.94.64.12 s=SIP Call c=IN IP4 10.1.1.1 t=0 0 a=recvonly m=audio 16590 RTP/AVP 0 a=rtpmap:0 PCMA/8000 a=ptime:20 m=video 51372 RTP/AVP 126 a=rtpmap:126 H264/90000

It is 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 60

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    61 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.

2

UAS

UAC

INVITE with SDP

Offer

200 OK with SDP

Answer

ACK without SDP

Session Established Application Interaction Requiring a Session Modification INVITE with SDP

Offer

200 OK with SDP

Answer

ACK without SDP

Updated Session Application Interaction Requiring a Session Modification UPDATE with SDP

Offer

200 OK with SDP

Answer

Newly Updated Session

Figure 2-6  SIP re-INVITE and UPDATE Session Modifications

From the Library of Green Systems LLC

9780136575542_BOOK.indb 61

23/10/20 3:58 PM

62    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 videocapable 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-Type: application/sdp Content-Length: 707 v=0 o=CiscoSystemsCCM-SIP 280365 1 IN IP4 172.18.110.91 s=SIP Call c=IN IP4 14.50.214.107 b=TIAS:64000

From the Library of Green Systems LLC

9780136575542_BOOK.indb 62

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    63 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:114 opus/48000/2 a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000; stereo=0;sprop-stereo=0;usedtx=0

2

a=rtpmap:9 G722/8000 a=rtpmap:124 iSAC/16000 a=rtpmap:113 AMR-WB/16000 a=fmtp:113 mode-change-capability=2 a=rtpmap:115 AMR-WB/16000 a=fmtp:115 octet-align=1;mode-change-capability=2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:116 iLBC/8000 a=maxptime:20 a=fmtp:116 mode=20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

[Initial Call (SIP+SDP) - Answer] Content-Type: application/sdp Content-Length: 416 v=0 o=CiscoSystemsCCM-SIP 405281 1 IN IP4 172.18.110.61 s=SIP Call c=IN IP4 14.50.214.106 b=TIAS:64000 b=AS:80 t=0 0 m=audio 21040 RTP/AVP 114 101 b=TIAS:64000 a=rtpmap:114 opus/48000/2 a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000; stereo=0;sprop-stereo=0;usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=trafficclass:conversational.audio.aq:admitted

From the Library of Green Systems LLC

9780136575542_BOOK.indb 63

23/10/20 3:58 PM

64    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide [Video Escalation (SIP+SDP) - New Offer] Content-Type: application/sdp Content-Length: 1499 v=0 o=CiscoSystemsCCM-SIP 405281 5 IN IP4 172.18.110.61 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:114 opus/48000/2 a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000; stereo=0;sprop-stereo=0;usedtx=0 a=rtpmap:9 G722/8000 a=rtpmap:124 iSAC/16000 a=rtpmap:113 AMR-WB/16000 a=fmtp:113 mode-change-capability=2 a=rtpmap:115 AMR-WB/16000 a=fmtp:115 octet-align=1;mode-change-capability=2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:116 iLBC/8000 a=maxptime:20 a=fmtp:116 mode=20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=trafficclass:conversational.audio.avconf.aq:admitted 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=1;max-mbps=108000; max-fs=3600;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=428016;packetization-mode=1;max-mbps=108000; max-fs=3600;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=428016;packetization-mode=0;max-mbps=108000; max-fs=3600;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1 a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50] a=content:main

From the Library of Green Systems LLC

9780136575542_BOOK.indb 64

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    65 a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=trafficclass:conversational.video.avconf.aq:admitted

2 [Video Escalation (SIP+SDP) - New Answer] Content-Type: application/sdp Content-Length: 830 v=0 o=CiscoSystemsCCM-SIP 280365 5 IN IP4 172.18.110.91 s=SIP Call c=IN IP4 14.50.214.109 b=TIAS:384000 b=AS:384 t=0 0 m=audio 25106 RTP/AVP 114 101 b=TIAS:64000 a=rtpmap:114 opus/48000/2 a=fmtp:114 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000; stereo=0;sprop-stereo=0;usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=trafficclass:conversational.audio.avconf.aq:admitted m=video 28130 RTP/AVP 100 b=TIAS:320000 a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=640C16;packetization-mode=1;max-mbps=108000; max-fs=3600;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1 a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50] a=content:main a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=trafficclass:conversational.video.avconf.aq:admitted

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 65

23/10/20 3:58 PM

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

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. The way in which a user agent changes the media format midsession is achieved 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 SDP in the answer.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 66

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    67

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.

2

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 Plain Old Telephone Service (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-topeer 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 67

23/10/20 3:58 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 68

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    69 GW1

Slow Start

GW2

H.225 TCP Connection (Port 1720) Setup Call Proceeding H.225

2

Alerting Connect TCP Keepalives Terminal Capability Set Master-Slave Determination Terminal Capability Set Master-Slave Determination Terminal Capability Set ACK Master-Slave Determination ACK

H.245

Terminal Capability Set ACK Master-Slave Determination ACK Open Logical Channel Open Logical Channel ACK Open Logical Channel Open Logical Channel ACK Release Complete Release Complete

TCP

H.245

H.225

Figure 2-7  Basic H.323 Slow Start Call

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 69

23/10/20 3:58 PM

70    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide H.323 Gateway PSTN

H.323 Gateway IP

V 1.1.1.1

H.225 Call Setup with H.245 Information Contained in fastStart element(s)

1.1.1.2

PSTN

V

H.225 Setup (with fastStart element + Open Logical Channel) H.225 Call Proceeding H.225 Alerting H.225 Connect (with fastStart element + Open Logical Channel)

Any of these response messages may “accept” FastConnect by including the fastStart element(s) and populating the necessary data fields.

RTP/RTCP Media Stream

Figure 2-8  H.323 FastConnect Call Setup

References Inamdar, Kaustubh, Steve Holl, Gonzalo Salgueiro, Kyzer Davis, and Chidambaram Arunachalam. Understanding Session Border Controllers: Comprehensive Guide to Designing, Deploying, Troubleshooting, and Maintaining Cisco Unified Border Element (CUBE) Solutions. Hoboken: Cisco 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),” https:// tools.ietf.org/html/rfc3264 RFC 4566, “SDP: Session Description Protocol,” https://tools.ietf.org/html/rfc4566 RFC 5853, “Requirements from Session Initiation Protocol (SIP) Session Border Controller (SBC) Deployments,” https://tools.ietf.org/html/rfc5853

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: 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 2-9 lists these key topics and the page number on which each is found. Table 2-9  Key Topics for Chapter 2 Key Topic Element

Description

Page

Figure 2-1

Sample SIP Dialog with Two Transactions

32

List

List of SIP components

34

Table 2-2

SIP Requests

35

Table 2-3

SIP Response Classes

36

From the Library of Green Systems LLC

9780136575542_BOOK.indb 70

23/10/20 3:58 PM

Chapter 2: VoIP Protocols: SIP and H.323    71 Key Topic Element

Description

Page

Figure 2-3

Analyzing a Basic SIP Call

46

Table 2-5

Fields and Attributes in SDP Bodies

50

Figure 2-4

SIP Delayed Offer Versus SIP Early Offer

53

Table 2-7

SDP Direction Attributes Description

56

Table 2-8

Different Ways of Setting the Direction Attribute in an Answer

58

Figure 2-6

SIP re-INVITE and UPDATE Session Modifications

61

List

H.323 components

67

Figure 2-7

Basic H.323 Slow Start Call

69

Figure 2-8

H.323 FastConnect Call Setup

70

2

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: 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 71

23/10/20 3:58 PM

CHAPTER 3

VoIP Protocols: RTP, RTCP, and DTMF Relay This chapter covers the following topics: 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. This chapter covers the following CLACCM 300-815 exam topics: ■■

1.2 Troubleshoot these H.323 protocol elements ■■

1.2.a DTMF

■■

1.3 Troubleshoot media establishment

■■

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 72

23/10/20 3:58 PM

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.

“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 3-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 3-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Introduction to Real-Time Media

1

Real-Time Transport Protocol

2–4

Real-Time Transport Control Protocol

5, 6

DTMF Relay

7–10

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

From the Library of Green Systems LLC

M03_Davis_C03_p072-p119.indd 73

23/10/20 7:37 PM

74    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 74

23/10/20 3:58 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    75 10. W  hen 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

3

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 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:

From the Library of Green Systems LLC

9780136575542_BOOK.indb 75

23/10/20 3:58 PM

Amplitude

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

(A) Analog Waveform

Time

(B) Sampling Time

7 6 5 4 3 2 1 0

(C) Quantization

Time

001

011

110

100

010

001

011

110

111

(D) Encoding

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 76

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    77

Sampling Rate

3 2x Sampling Rate

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 higherquality (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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 77

23/10/20 3:59 PM

78    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 digitalto-analog conversion and plays back a reconstruction of Alice’s original analog signal out to Bob.

Analog Signal

Digital Signal

Digital Signal Encapsulation

IP Packet

IP Packet Alice

DSP 1. 2. 3. 4.

Sampling Quantization Encoding Compression

Analog Signal

De-encapsulation

IP Network

DSP Bob 1. Decompression 2. Decoding 3. Reconstruct Analog Waveform

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 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, RealTime Control Protocol (RTCP), which 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 78

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    79 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. V

PX

CC

M

PT

Sequence Number Timestamp

3

Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers Header Extensions (Optional) Payload Header (Dependent on Payload Format)

Media Payload Optional Padding

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 79

23/10/20 3:59 PM

80    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK531305 From: ; To: ;tag=53A7B00-628 Call-ID: [email protected] [..Omitted for brevity..] Content-Type: application/sdp Content-Length: 221 v=0 o=CiscoSystemsSIP-GW-UserAgent 7031 5812 IN IP4 192.0.2.2 s=SIP Call c=IN IP4 192.0.2.2 t=0 0 m=audio 16512 RTP/AVP 0 c=IN IP4 192.0.2.61 a=rtpmap:0 PCMU/8000 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 80

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    81 Table 3-2  Payload Type-to-Format Mapping for RTP/AVP Payload Type

Encoding Name

Clock Rate (Hz)

0

PCMU

8000

4

G723

8000

8

PCMA

8000

9

G722

8000

15

G728

8000

18

G729

8000

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

3

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 realtime communication session.

Packets Dropped in Transit

P RT

R

RTP Transmit Queue

TP

RT

P

Internet

RT

P

RTP Receive Queue

16-Bit RTP Sequence Number

16-Bit RTP Sequence Number

52940

52940

52941

52942

52942

52944

52943 52944

Packets with Sequence Numbers 52941 and 52943 Are Missing

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. From the Library of Green Systems LLC

9780136575542_BOOK.indb 81

23/10/20 3:59 PM

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

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 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 both media 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 82

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    83 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 acknowledgments. 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.

3

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 83

23/10/20 3:59 PM

84    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 3-3  Default Packetization Periods of Common Audio Codecs Codec

Default Packetization Period (in milliseconds)

G.723

30

G.722

20

G.729

20

PCMU

20

PCMA

20

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 application data being sent, amounting to higher consumption of bandwidth. 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.711 (PCMU) 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.711 (PCMU) 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 84

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    85 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

3

INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK531305 Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ; To: ;tag=53A7B00-628 Date: Sat, 04 Feb 2017 07:11:33 GMT Call-ID: [email protected] [..Omitted for brevity..] Content-Type: application/sdp Content-Length: 221 v=0 o=CiscoSystemsSIP-GW-UserAgent 7031 5812 IN IP4 192.0.2.2 s=SIP Call c=IN IP4 192.0.2.2 t=0 0 m=audio 16512 RTP/AVP 0 c=IN IP4 192.0.2.61 a=rtpmap:0 PCMU/8000 a=ptime:20

The ptime (or maxptime) attribute is encoded in SDP using the following format: a=ptime: a=maxptime: 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 packets, 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 85

23/10/20 3:59 PM

86    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

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.

Figure 3-6  Wireshark Ptime Example

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 86

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    87 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.

3

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

P RC/SC

PT

Length

RTCP Packet Type Specific Information

Optional Padding

Figure 3-7  Common RTCP Packet Format

From the Library of Green Systems LLC

9780136575542_BOOK.indb 87

23/10/20 3:59 PM

88    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. V

P

RC

PT=200

Length

Reporter SSRC NTP Timestamp RTP Timestamp Sender’s Packet Count Sender’s Octet Count Zero/One or More Receiver Report Blocks

Figure 3-8  RTCP Sender Report Format

From the Library of Green Systems LLC

9780136575542_BOOK.indb 88

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    89 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.

3

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 89

23/10/20 3:59 PM

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

P

RC=1

PT=201

Length

SSRC of Sender SSRC of Source_N Loss Fraction

Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter LSR DLSR

Figure 3-9  RTCP Receiver Report Format 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 65,535 (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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 90

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    91 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/65,536 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.

3

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

P

SC

PT=202

Length

SSRC/CSRC 1 Chunk 1

SDES Items ... SSRC/CSRC 1

Chunk 2

SDES Items ...

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

Length

Value

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 91

23/10/20 3:59 PM

92    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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, [email protected]). 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.”

From the Library of Green Systems LLC

9780136575542_BOOK.indb 92

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    93 V

P

SC

PT=203

Length SSRC 1 ... SSRC n

Optional

Length

Reason for Leaving

3

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: 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 person. 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 endto-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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 93

23/10/20 3:59 PM

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

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. 1209 Hz

1336 Hz

1477 Hz

1633 Hz

697 Hz

1

2

3

A

770 Hz

4

5

6

B

852 Hz

7

8

9

C

941 Hz

*

0

#

D

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 inband (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. IP Phone

IVR IP Network

RTP Media: “Press one for sales…”

DTMF Digit: 1

RTP Media: “We will transfer your call…”

Figure 3-14  Sample Ladder Diagram for DTMF From the Library of Green Systems LLC

9780136575542_BOOK.indb 94

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    95 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.

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.

ITSP

CUBE

Unified CM

3

UCCX

RTP Media: “Press one for sales…”

RTP-NTE (Digit:1) SIP-KPML (Digit:1)

JTAPI (Digit:1)

RTP Media: “We will transfer your call…”

Figure 3-15  DTMF Relay Along Multiple Call Legs 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. From the Library of Green Systems LLC

9780136575542_BOOK.indb 95

23/10/20 3:59 PM

96    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. That is why 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 96

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    97 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. V=2

P

X

CC

M

PT

3

Sequence Number

Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifiers (CSRC) 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. Event

E

R

1 Byte

Volume

Duration

6 Bits

2 Bytes

1 Bit

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 DTMF Event

Event ID

0

0

1

1

2

2

3

3

4

4

From the Library of Green Systems LLC

9780136575542_BOOK.indb 97

23/10/20 3:59 PM

98    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide DTMF Event

Event ID

5

5

6

6

7

7

8

8

9

9

*

10

#

11

A

12

B

13

C

14

D

15 Letters A through D are for military applications 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 audioencoded 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 98

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    99 Example 3-3  SDP Advertisement of Named Telephony Events // SIP message omitted for brevity// v=0 o=CiscoSystemsSIP-GW-UserAgent 1597 5834 IN IP4 10.94.64.12 s=SIP Call c=IN IP4 10.1.1.1 t=0 0 a=recvonly

3

m=audio 17389 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 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. UAC

UAS

INVITE sip:[email protected] ... m=audio 5006 RTP/AVP 8 96 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15

SIP /2.0 200 OK ... m=audio 1046 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

Figure 3-18  Asymmetric Payload Type Negotiation for NTE

From the Library of Green Systems LLC

9780136575542_BOOK.indb 99

23/10/20 3:59 PM

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

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.

■■

Not widely adopted 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. SIP

RTP

SIP

NTE Event ID: 4 RTP

SIP

SIP

RTP

NTE Event ID: 4

Digit: 4 RTP

Digit: 4

Figure 3-19  End-to-End Transmission of NTE and Raw In-Band DTMF From the Library of Green Systems LLC

M03_Davis_C03_p072-p119.indd 100

23/10/20 7:38 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    101 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.

3

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.

INF

Os

ip:

IVR

CUBE

Unified CM INFO sip:

INFO sip: INFO sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP CSeq: 5 INFO Content-Type: application/dtmf-relay Signal=5 Duration=160

Unified CM

CUBE with Media Flow Around

RTP NTE Header

IVR

RTP SIP

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 101

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 102

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    103 Example 3-4  SIP Message Output for a SIP INFO Message INFO sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.1.1.2:5060 From: ;tag=43 To: ;tag=9753.0207 Call-ID: [email protected] CSeq: 25634 INFO Supported: 100rel

3

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 103

23/10/20 3:59 PM

104    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide SUBSCRIBE (Event: A) 200 OK (Cseq: SUBSCRIBE)

Event

NOTIFY (Event: A) 200 OK

Subscriber

Notifier

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 104

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    105 SUBSCRIBE (Event: A) 200 OK (Expires: 600)

Event

NOTIFY (Event: A)

3

200 OK 600 Seconds About to Elapse SUBSCRIBE (Event: A) 200 OK (Expires: 600) Subscriber

Notifier

Figure 3-22  Refreshing Subscriptions Drawing from the concepts discussed, the operation of the subscribe/notify framework can be summarized as follows: Step 1.

A user agent 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 dialogcreating 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 when 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 105

23/10/20 3:59 PM

106    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. SUBSCRIBE (Event: A) 200 OK (Expires: 600) NOTIFY (Event: A); Subscription-State: Terminated

200 OK Dialog Terminated

Event

SUBSCRIBE (Event: A) 200 OK (Expires: 600) New Dialog Initiated

Subscriber

Notifier

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 106

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    107

SUBSCRIBE (Event: A) 200 OK (Cseq: SUBSCRIBE) NOTIFY (Event: A) Event A

200 OK

SUBSCRIBE (Event: B)

Event B Buffered

nt B

Eve

3

200 OK (Cseq: SUBSCRIBE) NOTIFY 2 (Event: B) 200 OK

Subscriber

Notifier

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.

SUBSCRIBE (Event: A) 200 OK (Cseq: SUBSCRIBE)

Event A NOTIFY (Event: A) 200 OK

nt B

Eve NOTIFY 2 (Event: B) 200 OK

Subscriber

Notifier

Figure 3-25  Continuous Subscription KPML documents sent in SIP SUBSCRIBE messages indicate patterns of interest for an application. Each KPML document contains a element; embedded within this element is a series of elements that indicates individual digit maps. The use of multiple 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). From the Library of Green Systems LLC

9780136575542_BOOK.indb 107

23/10/20 3:59 PM

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

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 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 \n \n \n \n [x*#ABCD]\n \n \n \n \r\n

In Example 3-5, the element encloses the digit map against which DTMF event notifications are sent. The actual digit map string is included in the element. For the notifier to distinguish between persistent and one-time subscriptions (described previously), the persist attribute of the 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 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 element and is operationally redundant as there is only a single digit map specified for DTMF patterns.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 108

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    109 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: [email protected] !! Message truncated for brevity!! Event: kpml

3

Subscription-State: active Content-Type: application/kpml-response+xml Content-Length: 113 Message Body \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:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.1.1.1:5060;branch=z9hG4bK6BE90 Call-ID: [email protected] Event: kpml Subscription-State: terminated Content-Type: application/kpml-response+xml Content-Length: 109 Message Body \r\n

From the Library of Green Systems LLC

9780136575542_BOOK.indb 109

23/10/20 3:59 PM

110    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP 14.50.214.122:51851;branch=z9hG4bK237b00c1 From: "1008" ;tag=2c31246a214b001e70267f66-4e773ec7 To: sip:[email protected] Call-ID: [email protected] [..truncated..] Allow-Events: kpml,dialog ### Step 2, KPML SUBSCRIBE SUBSCRIBE sip:[email protected]:51851; transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK39f3915f65e35 From: ;tag=512298967 To: sip:[email protected]

From the Library of Green Systems LLC

9780136575542_BOOK.indb 110

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    111 Call-ID: [email protected] CSeq: 101 SUBSCRIBE Event: kpml; [email protected]; from-tag=2c31246a214b001e70267f66-4e773ec7 Expires: 7200 Contact: sip:[email protected]:5060;transport=tcp Accept: application/kpml-response+xml Max-Forwards: 70 Content-Type: application/kpml-request+xml

3

Content-Length: 424

[x#*+]|bs

### Step 3, KPML Subscription Active NOTIFY sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 14.50.214.122:51851;branch=z9hG4bK3cdda3dd To: ;tag=512298967 From: ;tag=2c31246a214b0020180d09b3-1a336107 Call-ID: [email protected] CSeq: 1000 NOTIFY Event: kpml Subscription-State: active; expires=7200 Max-Forwards: 70 Contact: ;+u.sip!devicename.ccm.cisco.com="SEP2C31246A214B" Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE Content-Length: 0 ### Step 4, NOTIFY DIGIT and 200 OK NOTIFY sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 14.50.214.122:51851;branch=z9hG4bK3fb50fc1 To: ;tag=512298967 From: ;tag=2c31246a214b0020180d09b3-1a336107 Call-ID: [email protected] CSeq: 1001 NOTIFY

From the Library of Green Systems LLC

9780136575542_BOOK.indb 111

23/10/20 3:59 PM

112    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Event: kpml Subscription-State: active; expires=7200 Max-Forwards: 70 Contact: ;+u.sip!devicename.ccm.cisco.com="SEP2C31246A214B" Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE Content-Length: 205 Content-Type: application/kpml-response+xml Content-Disposition: session;handling=required

SIP/2.0 200 OK Via: SIP/2.0/TCP 14.50.214.122:51851;branch=z9hG4bK3fb50fc1 From: ;tag=2c31246a214b0020180d09b3-1a336107 To: ;tag=512298967 Call-ID: [email protected] CSeq: 1001 NOTIFY Server: Cisco-CUCM12.5 Content-Length: 0 NOTIFY sip:[email protected]:5060;transport=tcp SIP/2.0 CSeq: 1002 NOTIFY

NOTIFY sip:[email protected]:5060;transport=tcp SIP/2.0 CSeq: 1003 NOTIFY

### Step 5, KPML teardown SUBSCRIBE sip:[email protected]:51851;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.48:5060;branch=z9hG4bK39f3a438a29b4 From: ;tag=512298967 To: ;tag=2c31246a214b0020180d09b3-1a336107 Call-ID: [email protected] CSeq: 102 SUBSCRIBE Event: kpml; [email protected]; from-tag=2c31246a214b001e70267f66-4e773ec7 Expires: 0 Contact: sip:[email protected]:5060;transport=tcp Max-Forwards: 70 Content-Length: 0

From the Library of Green Systems LLC

9780136575542_BOOK.indb 112

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    113 Figure 3-26 shows a SIP ladder diagram with the events discussed in the previous steps and shown in Example 3-8. IP Phone - 1008

Unified CM

IP Phone - 1010

INVITE (101 INVITE) Digit: 1 100 TRYING (101 INVITE) SUBSCRIBE (101 SUBSCRIBE) 200 OK (101 SUBSCRIBE)

3

NOTIFY (1000 NOTIFY) Subscription-State: Active; Expires=7200 200 OK (1000 NOTIFY) NOTIFY (1001 NOTIFY) Digit: 0 200 OK (1001 NOTIFY) NOTIFY (1002 NOTIFY) Digit: 1 200 OK (1002 NOTIFY) NOTIFY (1003 NOTIFY) Digit: 0 200 OK (1003 NOTIFY) SUBSCRIBE (102 SUBSCRIBE) INVITE (101 INVITE) 100 TRYING (101 INVITE)

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 113

23/10/20 3:59 PM

114    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.2:5060;branch=z9hG4bKBC3516C !!! Message truncated for brevity!!! CSeq: 101 INVITE Contact: Call-Info: ;method="NOTIFY;Event=telephoneevent;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: Call-Info: ;method="NOTIFY;Event=telephoneevent;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. From the Library of Green Systems LLC

9780136575542_BOOK.indb 114

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    115 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. Event

E

R

1 Byte

Unused

Duration

6 Bits

2 Bytes

1 Bit

3

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 115

23/10/20 3:59 PM

116    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Inamdar, Kaustubh, Steve Holl, Gonzalo Salgueiro, Kyzer Davis, and Chidambaram Arunachalam. Understanding Session Border Controllers: Comprehensive Guide to Designing, Deploying, Troubleshooting, and Maintaining Cisco Unified Border Element (CUBE) Solutions. Hoboken: Cisco Press, 2018.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 116

23/10/20 3:59 PM

Chapter 3: VoIP Protocols: RTP, RTCP, and DTMF Relay    117 RFC 2198, “RTP Payload for Redundant Audio Data,” https://tools.ietf.org/html/rfc2198 RFC 2833, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” https://tools.ietf.org/html/rfc2833 RFC 2976, “The SIP INFO Method,” https://tools.ietf.org/html/rfc2976 RFC 3261, “SIP: Session Initiation Protocol,” https://tools.ietf.org/html/rfc3261 RFC 3388, “Grouping of Media Lines in the Session Description Protocol (SDP),” https:// tools.ietf.org/html/rfc3388 RFC 3550, “RTP: A Transport Protocol for Real-Time Applications,” https://tools.ietf.org/ html/rfc3550

3

RFC 3551,” RTP Profile for Audio and Video Conferences with Minimal Control,” https:// tools.ietf.org/html/rfc3551 RFC 4571, “Framing Real-Time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport,” https://tools.ietf.org/html/rfc4571 RFC 4585, “Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF),” https://tools.ietf.org/html/rfc4585 RFC 4730, “A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML),” https://tools.ietf.org/html/rfc4730 RFC 4733, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals,” https://tools.ietf.org/html/rfc4733 RFC 5761, “Multiplexing RTP Data and Control Packets on a Single Port,” https://tools. ietf.org/html/rfc5761 RFC 6086, “Session Initiation Protocol (SIP) INFO Method and Package Framework,” https://tools.ietf.org/html/rfc6086 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,” https://tools.ietf.org/html/rfc6665 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

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: Chapter 11, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 117

23/10/20 3:59 PM

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

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 3-5 lists these key topics and the page number on which each is found. Table 3-5  Key Topics for Chapter 3 Key Topic Element

Description

Page

List

Analog-to-digital conversion

76

Figure 3-4

RTP Packet Format

79

List Item

Payload Type header field

80

List Item

Sequence Number header field

81

List Item

SSRC Header field

82

Paragraph

SDP ptime and maxptime attributes

84

Figure 3-13

4 × 4 DTMF Grid

94

List

Variants of DTMF relay

95

List

RTP-NTE packet scheme

96

Example 3-3

SDP Advertisement of Named Telephony Events

99

List

SIP KPML for Cisco IP phone digit presses

110

Complete Tables and Lists from Memory There are no memory tables or lists for this chapter.

Define Key Terms Define the following key terms from this chapter and check your answers in the glossary: 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 118

23/10/20 3:59 PM

This page intentionally left blank

From the Library of Green Systems LLC

CHAPTER 4

Unified CM Call Routing and Digit Manipulation This chapter covers the following topics: 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 120

23/10/20 3:59 PM

This chapter covers the following CLACCM 300-815 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.

“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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 121

23/10/20 3:59 PM

122    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide move ahead to the “Exam Preparation Tasks” section of the chapter. Table 4-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 4-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Pattern Matching

1

Transformations and Masks

2

Pattern Configuration and Device Selection

3–6

Partitions and Calling Search Spaces

7, 8

Translation Patterns

9

Transformation Patterns

10, 11

Putting It All Together: Tail-End Hop Off (TEHO)

12

Alphanumeric URI Routing

13

Intercluster Dial Plan Replication

14

Troubleshooting Call Routing and Digit Manipulation

15, 16

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 122

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     123 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. @

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 123

23/10/20 3:59 PM

124    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

■■

25XX transforms the called party to 2555

■■

30XX transforms the called party to 3333

■■

35XX transforms the called party to 3555

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. W  hat 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 124

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     125 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. W  hat 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

4

e. Server 15. W  hich 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 [email protected]). 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 125

23/10/20 3:59 PM

126    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Wildcard

Description

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, #, A, B, C, D

These are not really wildcards in that each one just matches a single digit. (Note that the * character is not a wildcard, as it is in regular expressions.) Each of these characters matches exactly one occurrence of the character. You may be wondering what the letters A through D are doing here. When the DTMF system was designed in the 1960s, it was designed with a fourth column of digits (for a total of 16 digits). The four “digits” A, B, C, and D are fully supported in Unified CM for legacy reasons, mainly for supporting voicemail systems that would use these digits to signal each other over the PSTN for the purposes of voicemail networking. These digits are rarely used anymore, although it was common practice to use them in the early days of Unified CM.

[xyz]

This notation allows you to specify a set of matching digits. For example, [357] matches one occurrence of either the digit 3, 5, or 7. Note that in the example here, x, y, and z represent a single digit and have nothing to do with the X wildcard.

[y-z]

Placing a hyphen between any two digits within square brackets causes one occurrence of any digits within the range to match, including the digits themselves. You can use range notation along with set notation. For example, [3-69] matches one occurrence of a digit 3, 4, 5, 6, or 9.

[^y-z]

If the first character after the open bracket is a caret, the expression matches one occurrence of any digit (including * and #) except those specified. For example, [^1-8] matches one occurrence of a digit 9, 0, *, #, A, B, C, or D.

?

A question mark following any wildcard or bracket expression matches zero or more occurrences of any digit that matches the previous wildcard. For example, 9[12]? matches the empty string, 9, 91, 92, 912, 9122, 92121, and many others.

+

A plus sign following any wildcard or bracket expression matches one or more occurrences of any digit that matches the previous wildcard. For example, 3[1-4]+ matches 31, 3141, 3333, and many others.

\+

This describes a single instance of the character + in a number string. Note that this is different from the + wildcard, which does not have a backslash (\) in front of it. This plus variant is often used at the beginning of a pattern such as \+14085267209.

X

The X wildcard is a convenience wildcard that matches one occurrence of any digit in the range 0 to 9. This wildcard is functionally equivalent to the range expression [0-9].

From the Library of Green Systems LLC

9780136575542_BOOK.indb 126

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     127 Wildcard

Description

!

The ! wildcard is a convenience wildcard that matches one or more occurrences of any digit in the range 0 to 9. This wildcard is functionally equivalent to the range expression [0-9]+.

@

The @ wildcard does not represent any particular set of matching characters. The @ wildcard causes Unified CM to add the set of national route patterns for the numbering plan you specify in the Numbering Plan field on the Route Pattern or Translation Pattern Configuration pages in the Unified CM Administration user interface. One way to think of the @ pattern is that it matches any number you can dial from a standard land-line phone in the country specified by the numbering plan. For example, specifying the @ pattern along with the North American Numbering Plan (NANP) allows users to dial 911, 555 1212, 1 800 555 1212, and 011 33 12 34 56 78 90, along with many others. In addition, the @ symbol is used as a delimiter for the PreAt digit discard described later in this chapter.

.

4

The . wildcard is unlike other wildcards in that it does not match digits at all. The . wildcard functions solely as a delimiter. When it appears in a route pattern, it divides the dial string into PreDot and PostDot sections. This has no effect on what digit strings the route pattern matches. Rather, you use the . wildcard in conjunction with digit discarding instructions (discussed later in this chapter). Note that this is different from IOS pattern matching and regular expressions, where . is a wildcard. For more information on IOS dial peer wildcards, refer to Chapter 9, “CUBE Interworking Features.” 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#*ABCD] because #, *, A, B, C, and D 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 127

23/10/20 3:59 PM

128    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 128

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     129 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 129

23/10/20 3:59 PM

130    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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, [email protected]). 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 Wildcard

Description

0-9, A-Z, a-z, -, .

These are not really wildcards in that each one just matches a single character. These characters match exactly one occurrence of the character. Notice that the hyphen (-) and dot (.) characters appear here as just characters in the string. The dot (.) separates different sections of the domain.

[abc]

This notation allows you to specify a set of matching characters. For example, [abc123] matches one occurrence of either the letters a, b, or c or the digits 1, 2, or 3.

[x-y]

Placing a hyphen between any two characters within square brackets causes one occurrence of any characters within the range to match, including the characters themselves. In addition to digits, you can specify ranges of letters. You can use range notation along with set notation. For example, [012A-Ca-c] matches one occurrence of 0, 1, 2, A, B, C, a, b, or c.

*

Matches one or more valid characters, 0-9, A-Z, a-z, ., or -. This wildcard can only be used on its own before a period (for example, *.example. com) or between periods (for example, test.*.com). More than one * may appear in an alphanumeric pattern (for example, *.*.com)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 130

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     131 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.

4

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 rightaligned and then the digits in the number and mask are compared to determine the result.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 131

23/10/20 3:59 PM

132    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 number

  2000

Mask

408555XXXX

Final result

4085552000

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: Original number

94085551234

Mask

+1XXXXXXXXXX

Final result

+14085551234

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 number

2000

Mask

+1XXXXXXXXXX

Final result

+1??????1234

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 uses 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 132

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     133 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 that 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 +: Dialed number

94085267209

Route pattern

9.[2-9]XX[2-9]XXXXXX

Discard

PreDot

New number

4

4085267209

Transform mask

1XXXXXXXXXX

New number

14085267209

Prefix

+

Final number

+14085267209

NOTE  This example is 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 133

23/10/20 3:59 PM

134    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 134

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     135 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.”

4

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 Calling Party Display Name

Called Party Display Name

Name Shown on Calling Phone While Ringing (alerting name)

Name Shown on Calling Phone When Connected (connected name)

Phone A 1000

Phone B 2000

Line Name 2000

Phone B 2000

Phone A 1000

Phone C 2000

Line Name 2000

Phone C 2000

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 135

23/10/20 3:59 PM

136    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. Route Pattern \+1[2-9]XX[2-9]XXXXXX

Route Pattern \+[2-9]!

Route List PSTN_RL

Route Group DC1-SIP

SIP Trunk DC1-CUBE1-SIP

SIP Trunk DC1-CUBE2-SIP

Route Group DC2-SIP

SIP Trunk DC2-CUBE1-SIP

SIP Trunk DC2-CUBE2-SIP

Figure 4-2  Relationships Between Route Patterns, Route Lists, Route Groups, Gateways, and Trunks

From the Library of Green Systems LLC

9780136575542_BOOK.indb 136

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     137

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.

4

Figure 4-3  Route Pattern Configuration From the Library of Green Systems LLC

9780136575542_BOOK.indb 137

23/10/20 3:59 PM

138    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Parameter Name

Description

Pattern Definition Section Route Pattern

Specifies the pattern to be matched by this route pattern.

Route Partition

Specifies the partition into which this pattern will be placed. Partitions (and calling search spaces) are covered later in this chapter.

Description

Allows an administrator to provide a description.

Numbering Plan

Specifies the numbering plan that applies to the pattern. This field is applicable (and therefore only configurable) only if the pattern contains the @ sign. This field specifies which numbering plan the @ in the pattern represents.

Route Filter

Specifies a route filter to apply to the pattern. This field is also only applicable to patterns containing the @ sign.

MLPP Precedence

Indicates the priority of this call for customers using the Multilevel Precedence and Preemption (MLPP) feature. This feature is typically enabled only in specific government deployments and is beyond the scope of this book.

Apply Call Blocking Percentage

Specifies the percentage of calls matching this route pattern that will be blocked. For example, if set to 50, every other call will be rejected by Unified CM. This setting is only configurable when MLPP is set to Immediate, Priority, Routine, or Default.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 138

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     139 Parameter Name

Description

Pattern Definition Section Resource Priority Namespace Network Domain

Specifies the resource priority namespace for customer using the MLPP feature, which is beyond the scope of this book.

Route Class

Specifies the MLPP route class. Again, this feature is beyond the scope of this book.

Gateway/Route List

Specifies either a single gateway/trunk to which calls matching this route pattern are routed or a route list that will be used to select the destination device by searching through the route list and route groups contained in the route list. It is highly recommended to always route calls through a route list, even if the route list contains only a single gateway, because any change to a route pattern pointing directly to a gateway or trunk results in all active calls on that gateway/trunk being dropped because the change results in the gateway or trunk being reset. Furthermore, when a route pattern specifies a single gateway/trunk, the specified device is excluded from configuration on a route group. The reverse is also true: Devices within a route group do not show up here by themselves.

Route Option

Determines whether a match on this pattern results in the call being extended or blocked. If Block This Pattern is selected, the administrator can select which reason code will be returned to the originator to indicate why the call was blocked. Remember that patterns are always matched using closestmatch logic, described earlier in this chapter. If the best match indicates to block the pattern, the call is blocked, even if there is another less-specific pattern that permits the call.

Call Classification

Whether a call matching this pattern is considered to be on-net or off-net. This distinction is used with other features, such as the service parameters that block on-net to off-net transfers or conferences, as detailed in Chapter 5.

External Call Control Profile

An external call control profile used if an administrator wants to enable the external call control (ECC)/Cisco Unified Routing Rules Interface (CURRI) API for calls that match this pattern. If a profile is selected, calls matching this route pattern trigger an HTTPS request to the configured route server to determine whether the call should be allowed or not and whether any modifications to the calling or called number are necessary.

Allow Device Override

Determines whether the call classification setting on a gateway or trunk can override the call classification setting on the route pattern. This parameter works in conjunction with the Call Classification setting.

4

From the Library of Green Systems LLC

9780136575542_BOOK.indb 139

23/10/20 3:59 PM

140    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Parameter Name

Description

Pattern Definition Section Provide Outside Dial Tone

Indicates whether Unified CM should provide a secondary or outside dial tone for calls that match this pattern. Unified CM plays an outside dial tone at the point where all potential matches have this option selected. In other words, if a cluster has only two patterns configured, 1000 and 1XXX, with only the 1XXX pattern specifying to play outside dial tone, a user would have to dial a 1 and any digit other than 0 to receive an outside dial tone. This is because after dialing a 1, both 1000 and 1XXX are potential matches, but they don’t both have the Provide Outside Dial Tone setting enabled, and Unified CM does not play the outside dial tone until the only remaining potential matches have this setting enabled.

Allow Overlap Sending

Allows for calls to a gateway that supports overlap sending to continue sending additional digits after the pattern configured on this route pattern is matched. Overlap sending is used only on ISDN trunks connected to MGCP gateways. Note that when this option is enabled, the Require Forced Authorization Code and Require Client Matter Code options are no longer selectable.

Urgent Priority

Determines whether Unified CM should continue collecting additional digits if there are still potential matches after matching this route pattern. If Urgent Priority is enabled, Unified CM forgoes any potential matches and routes the call immediately.

Require Forced Authorization Code

Requires that a user placing a call that matches this route pattern enter a forced authorization code (FAC) to complete the call. Note that when this option is enabled, the Allow Overlap Sending and External Call Control Profile options are no longer selectable.

Authorization Level

If the Require Forced Authorization Code setting is enabled, determines the minimum authorization level required to extend the call.

Require Client Matter Code

Requires that the caller dial a client matter code (CMC) before the call is extended. This code is logged in the call detail record and is typically used for billing purposes. Note that when this option is enabled, the Allow Overlap Sending and External Call Control Profile options are no longer selectable.

Calling Party Transformations Section Use Calling Party’s External Phone Number Mask

Determines whether Unified CM will apply the external phone number mask configured on the line of the endpoint placing the call to the directory number configured on the line.

Calling Party Transform Mask

Applies a mask to the calling party number. If the Use Calling Party’s External Phone Number Mask parameter is enabled, the number with the external phone number mask is used as the input to the mask configured on this field.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 140

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     141 Parameter Name

Description

Calling Party Transformations Section Prefix Digits (Outgoing Calls)

Prefixes the digits configured here to the number obtained after applying the calling party transform mask.

Calling Line ID Presentation

Determines whether the calling line information should be extended to the destination.

Calling Name Presentation

Determines whether the calling name information should be extended to the destination.

Calling Party Number Type

Sets the ISDN Q.931 number type on the calling party number to the selected value. If the value is set to Cisco CallManager, the number type is affected only on patterns with an @ in them, in which case the numbering plan file indicates which type to use, based on which specific pattern in the @ pattern was matched.

Calling Party Numbering Plan

4

Sets the ISDN Q.931 numbering plan to the selected value. Much like the number type parameter, the Cisco CallManager parameter selects the plan based on the numbering plan file.

Connected Party Transformations Section Connected Line ID Presentation

Works like the Calling Line ID Presentation parameter but applies to the connected number, which is the number a caller sees on his or her phone after dialing a number. This can be used to block callers from knowing whether the called device has been forwarded to another number and you do not want the caller to see the actual destination he or she is connected to.

Connected Name Presentation

Works like the Connected Line ID Presentation parameter but applies to the display of the connected name.

Called Party Transformations Section Discard Digits

Discards certain parts of the matched number, depending on the rule selected. This option is grayed out unless the configured pattern has one of the characters needed to apply one of these instructions—either a dot (.), an at (@) symbol, or a pound sign (#). The most commonly used digit discard instruction (DDI) is the PreDot option, which discards all digits that appear to the left of a dot in the pattern. For example, configuring PreDot on the pattern 9.1[2-9]XX[2-9] XXXXXX results in the leading 9 being discarded. Some options are specific to the numbering plan selected and apply only to patterns matching the @ sign.

Called Party Transform Mask

Applies a mask to the called party number. This transformation is applied after the Digit Discard setting has been applied to the matched pattern.

Prefix Digits (Outgoing Calls)

Prefixes the digits configured to the called party number after applying the called party transform mask.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 141

23/10/20 3:59 PM

142    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Parameter Name

Description

Called Party Transformations Section Called Party Number Type

Sets the ISDN Q.931 number type on the called party number to the selected value. If the value is set to Cisco CallManager, the number type is affected only on patterns with an @ in them, in which case the numbering plan file indicates which type to use based on which specific pattern in the @ pattern was matched.

Called Party Numbering Plan Sets the ISDN Q.931 numbering plan of the called party number to the selected value. Much like the Number Type parameter, the Cisco CallManager parameter selects the plan based on the numbering plan file. ISDN Network-Specific Facilities Information Element Section Network Service Protocol

Specifies the ISDN Q.931 Network Specific Facilities (NSF) information element (IE). This setting is applicable only to MGCP PRI gateways, and this field must match the switch type configured on the outbound MGCP gateway port, as these information elements are specific to the ISDN variant that applies to that particular switch. These are all extensions to the standard Q.931 specification. With the advent of SIP trunking, these fields are rarely used.

Carrier Identification Code

Specifies 0, 3, or 4 as the digit carrier identifier. This field is typically used to identify a specific carrier to which you would like a call routed.

Network Service

Specifies the network service to send in the NSF IE. These fields are different, depending on the Network Service Protocol option selected.

Service Parameter Name

If the selected network service permits an additional value or qualifier, indicates what the parameter is. This field cannot be changed, and it updates automatically, based on the network service selected.

Service Parameter Value

Specifies the value for the parameter indicated in the Service Parameter Name field, if one exists.

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 142

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     143 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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 143

23/10/20 3:59 PM

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

Figure 4-4  Route List Configuration Page in the Unified CM Administration User Interface 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).

From the Library of Green Systems LLC

9780136575542_BOOK.indb 144

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     145 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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 145

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 146

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     147

4

Figure 4-6  Route Group Configuration Page in the Unified CM Administration User Interface 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 147

23/10/20 3:59 PM

148    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 locationspecific route group that will be used in its place. Because the multiple local route group

From the Library of Green Systems LLC

9780136575542_BOOK.indb 148

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     149 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 149

23/10/20 3:59 PM

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

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 navigating to Unified CM Administration > Call Routing > Route/Hunt > Line Group.

Figure 4-8  Line Group Configuration in the Unified CM Administration User Interface

From the Library of Green Systems LLC

9780136575542_BOOK.indb 150

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     151 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 151

23/10/20 3:59 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 152

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     153

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.

4

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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 153

23/10/20 3:59 PM

154    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. 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 page 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 154

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     155

4

Figure 4-12  Route Plan Report

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 155

23/10/20 3:59 PM

156    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 locationspecific 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. Phone_Lines_PT DN: 1000 DN: 1001 Internal_Only_CSS

DN: 1002

US_Emergency_PT RP: 9.911 RP: 911

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 156

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     157 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. Phone_Lines_PT DN: 1000 DN: 1001 DN: 1002

4 US_Emergency_PT NC_919_984_Local_Calling_CSS

RP: 9.911 RP: 911

NC_919_984_Local_PT RP: 9.919[2-9]XXXXXX RP: \+1919[2-9]XXXXXX RP: 9.984[2-9]XXXXXX RP: \+1984[2-9]XXXXXX

Figure 4-14  Partition and Calling Search Space 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 157

23/10/20 3:59 PM

158    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Phone_Lines_PT DN: 1000 DN: 1001 DN: 1002

US_Emergency_PT RP: 9.911 RP: 911

NC_919_984_Local_PT RP: 9.919[2-9]XXXXXX NC_919_984_National_Calling_CSS

RP: \+1919[2-9]XXXXXX RP: 9.984[2-9]XXXXXX RP: \+1984[2-9]XXXXXX

US_National_PT RP: 9.1[2-9]XX[2-9]XXXXXX RP: \+1[2-9]XX[2-9]XXXXXX

US_Block_CC1_Intl_PT RP: 9.1264XXXXXXX

Block

RP: \+1264XXXXXXX

Block

RP: 9.1242XXXXXXX

Block

RP: \+1242XXXXXXX

Block

Figure 4-15  Partition and Calling Search Space Example for National Dialing This figure shows the two new partitions that have been 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 158

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     159 (NANP) works, several countries all share the same country code, so the patterns in the US_Block_CC1_Intl_PT partition are 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 159

23/10/20 3:59 PM

160    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Phone_Lines_PT DN: 1000 DN: 1001 DN: 1002

US_Emergency_PT RP: 9.911 RP: 911

NC_919_984_Local_PT RP: 9.919[2-9]XXXXXX NC_919_984_International_Calling_CSS

RP: \+1919[2-9]XXXXXX RP: 9.984[2-9]XXXXXX RP: \+1984[2-9]XXXXXX

US_National_PT RP: 9.1[2-9]XX[2-9]XXXXXX RP: \+1[2-9]XX[2-9]XXXXXX

US_International_PT RP: 9.011! RP: 9.011!# RP: \+! RP: \+!#

Figure 4-17  Partition and Calling Search Space 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. From the Library of Green Systems LLC

9780136575542_BOOK.indb 160

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     161 Phone_Lines_PT DN:1000 DN:1001 DN:1002

US_Emergency_PT Internal_Only_CSS

RP: 9.911 RP: 911

NC_919_984_Local_Calling_CSS

4

NC_919_984_Local_PT RP: 9.919[2-9]XXXXXX RP: \+1919[2-9]XXXXXX RP: 9.984[2-9]XXXXXX

NC_919_984_National_Calling_CSS

RP: \+1984[2-9]XXXXXX

US_National_PT NC_919_984_International_Calling_CSS

RP: 9.1[2-9]XX[2-9]XXXXXX RP: \+1[2-9]XX[2-9]XXXXXX

US_International_PT RP: 9.011! RP: 9.011!# RP: \+! RP: \+!#

US_Block_CC1_Intl_PT RP: 9.1264XXXXXX

Block

RP: \+1264XXXXXX

Block

RP: 9.1242XXXXXX

Block

RP: \+1242XXXXXX

Block

Figure 4-18  Partition and Calling Search Space Example

From the Library of Green Systems LLC

9780136575542_BOOK.indb 161

23/10/20 3:59 PM

162    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide You can see how the relationships between partitions and calling search spaces are a manyto-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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 162

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     163

4

Figure 4-20  Work Hours Time Schedule Configuration Example

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 163

23/10/20 3:59 PM

164    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 come 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. 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 convert 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 164

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     165

4

Figure 4-22  Translation Pattern Configuration in the Unified CM Administration User Interface In Figure 4-23 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 165

23/10/20 3:59 PM

166    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Line: 1000 External Phone Number Mask: +1984555XXXX User Dials 95551234 Calling Search Space: PSTN_Access_919 Partitions: - Phone_Lines_PT - Local_AC_919

Translation Pattern Pattern: 9.[2-9]XXXXXX Pattern: Local_AC_919 Calling Party Transformations: - Use Calling Party External Phone Number Mask: True Called Party Transformations: - Called Party Transformation Mask: +1919XXXXXX Calling Search Space: Full_PSTN_Access

Calling Party Number: +19845551000 Called Party Number: +19195551234

Calling Search Space: Full_PSTN_Access Partitions: - PSTN_Routes

Route Pattern Pattern: \+! Partition: PSTN_Routes Gateway/Route List: PSTN_SIP_Trunk_RL

Hunt through route groups in the PSTN_SIP_Trunk_RL route list and attempt to route the call.

Figure 4-23  Example Translation Pattern Call Routing Flow 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 166

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     167 Notice that the IP phone does not have direct access to 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 167

23/10/20 3:59 PM

168    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 168

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     169

4

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 digitby-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 navigating to Unified CM Administration > Call Routing > Transformation > Transformation Patterns > Called Party Transformation Pattern. 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).

From the Library of Green Systems LLC

9780136575542_BOOK.indb 169

23/10/20 3:59 PM

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

Figure 4-25  Called Party Transformation Pattern Configuration in the Unified CM Administration User Interface 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 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. 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 Transformation CSS, where 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 170

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     171

4

Figure 4-26  Transformation CSS Configuration on a SIP Trunk in the Unified CM Administration User Interface

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 171

23/10/20 3:59 PM

172    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

■■

25XX transforms the called party to 2555.

■■

30XX transforms the called party to 3333.

■■

35XX transforms the called party to 3555.

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 172

23/10/20 3:59 PM

9780136575542_BOOK.indb 173

Called Party Number: 2500

Route List Details > Route Group Called Party Transform: X5XX

Route List: CUBE

Called Party Number: 3000

Route Pattern: 2XXX Called Party Transform: 3XXX

Figure 4-27  Called Party Transformation Logic

Called Party Number: 2000

Translation Pattern: 1XXX Called Party Transform: 2XXX

Dial 1000

Called Xform Pattern: 35XX Called Party Transform: 3555

Called Xform Pattern: 30XX Called Party Transform: 3333

Called Xform Pattern: 25XX Called Party Transform: 2555

Called Xform Pattern: 2XXX Called Party Transform: 2222

Called Xform Pattern: 15XX Called Party Transform: 1555

Called Xform Pattern: 1XXX Called Party Transform: 1111

SIP Trunk: CUBE Called Party Transformation CSS: CCNP

INVITE sip:2222@cube

Chapter 4: Unified CM Call Routing and Digit Manipulation     173

4

From the Library of Green Systems LLC

23/10/20 3:59 PM

9780136575542_BOOK.indb 174

Called Party Number: 2500

Route List Details > Route Group Called Party Transform: X5XX

Route List: CUBE

Called Party Number: 3000

Route Pattern: 2XXX Called Party Transform: 3XXX

SIP Trunk: CUBE

Figure 4-28  Called Party Transformation Logic Without Transformation Patterns

Called Party Number: 2000

Translation Pattern: 1XXX Called Party Transform: 2XXX

Dial 1000

INVITE sip:2500@cube

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

From the Library of Green Systems LLC

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     175

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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 175

23/10/20 3:59 PM

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

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 labeled 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 176

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     177 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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 177

23/10/20 3:59 PM

178    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. Calling Phone Extension: 1000 External Phone Number Mask: +1408555XXXX

32960 +446 Send

86

UK PSTN

3

02

DC1 SBC

46

86

96

UK SBC

+4

02

32

Se

nd

6 29

46

1

86

14

:0

02

01

nd

96

nd

Se

2 63

Se

286

Dial 9 011 44 1632 960286 #

Branch Gateways (x100)

DC2 SBC

V

V

US PSTN

UK Cell Phone 0 1632 960286

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 178

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     179 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.

4 Calling Search Spaces

Partitions and Patterns

Route List/Route Groups

NANP_International_PSTN TP: 9011.! International_With_TEHO_CSS

TP: 9011.!# TP: \+! TP: \+!# UK_DC1_DC2_LRG

Global_PSTN_Patterns_CSS

Global_TEHO_Patterns

UK_SBC_RG

RP: \+44!

US_DC_RG

Global_to_UK_Called_Xform UK_Called_Xform_CSS

Local Route Group

Called Xform: \+44.! Global_to_UK_Calling_Xform

UK_Calling_Xform_CSS

Calling Xform: \+.1! Global_to_US_Called_Xform

UK_Called_Xform_CSS

Called Xform: \+[2-9]! Global_to_US_Calling_Xform

US_Calling_Xform_CSS

Calling Xform: \+.1!

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 179

23/10/20 3:59 PM

180    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.!#

■■

Partition: NANP_International_PSTN

■■

Calling Search Space: Global_PSTN_Patterns_CSS

■■

Provide Outside Dial Tone: selected

■■

Do Not Wait for Interdigit Timeout on Subsequent Hops: selected

■■

Calling Party Transformations: ■■

■■

Use Calling Party’s External Phone Number Mask: selected

Called Party Transformations: ■■

Discard Digits: PreDot Trailing-#

■■

Prefix Digits (Outgoing Calls): +

From the Library of Green Systems LLC

9780136575542_BOOK.indb 180

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     181 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: \+!

■■

Partition: NANP_International_PSTN

■■

Calling Search Space: Global_PSTN_Patterns_CSS

■■

Calling Party Transformations: ■■

4

Use Calling Party’s External Phone Number Mask: selected

Finally, the last translation profile needs to be configured as follows: ■■

Pattern: \+!#

■■

Partition: NANP_International_PSTN

■■

Calling Search Space: Global_PSTN_Patterns_CSS

■■

Do Not Wait for Interdigit Timeout on Subsequent Hops: selected

■■

Calling Party Transformations: ■■

■■

Use Calling Party’s External Phone Number Mask: selected

Called Party Transformations: ■■

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 181

23/10/20 3:59 PM

182    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 this 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 that 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

■■

Called Party Transformations: ■■

Discard Digits: PreDot

■■

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

■■

Calling Party Transformations: ■■

Discard Digits: PreDot

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 182

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     183 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

■■

Called Party Transformations: ■■

Discard Digits: PreDot

■■

Prefix Digits: 011

4

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

■■

Calling Party Transformations: ■■

Discard Digits: PreDot

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 183

23/10/20 3:59 PM

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

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 businessto-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. 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 CM will treat 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 184

23/10/20 3:59 PM

9780136575542_BOOK.indb 185

No

No

Yes

Offer Call

Yes

Does LHS find a match?

Yes

Does RHS match organization toplevel domain (OTLD)?

Does RHS match cluster fully qualified DN (CFQDN)?

Yes

Does whole URI match one in ILS?

Offer Call

No

No

Route Using SIP Route Patterns Based on Route String for ILS Entry

Yes

Does whole URI match a URI in the CSS and URI table?

Figure 4-32  URI Routing in Unified CM

Route or Block

Analyze LHS

Yes

Is RHS the IP address or hostname of a cluster member?

Yes

Is LHS Numeric?

Does RHS match a SIP route pattern?

Yes

Route Based on RHS

Yes

Does RHS match a SIP route pattern? No Match

No

No

No

No

No

Block Call

Chapter 4: Unified CM Call Routing and Digit Manipulation     185

4

From the Library of Green Systems LLC

23/10/20 3:59 PM

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

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 for 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 [email protected] and a user dials [email protected], the call will fail. Most administrators relax this policy to make URI matching case-insensitive so that [email protected], [email protected], and [email protected] all match the same URI ([email protected]). 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).

From the Library of Green Systems LLC

9780136575542_BOOK.indb 186

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     187

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 187

23/10/20 3:59 PM

188    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 [email protected] 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 [email protected] 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 [email protected] has a device registered to Unified CM Cluster A and [email protected] 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 Cluster B indicates the URI is not found, 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).

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 188

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     189 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.

4

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.

Spoke 1A

Spoke 2A

Spoke 1B

Spoke 2B

Hub 1

Hub 3

Hub 2

Hub 4

Spoke 4B

Spoke 3A

Spoke 3B

Spoke 4A

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 189

23/10/20 3:59 PM

190    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 190

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     191 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 appears 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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 191

23/10/20 3:59 PM

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

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 [email protected]. 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 [email protected], 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 [email protected]. 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 192

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     193 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 [email protected], 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:[email protected] SIP/2.0 Via: SIP/2.0/TLS 10.122.249.71:5061;branch=z9hG4bK4f5b1d81b7c0 From: "Paul Giralt" ;tag=151770~c1c9b4c0 To: Date: Thu, 21 May 2020 16:43:29 GMT

4

Call-ID: [email protected] Supported: 100rel,timer,resource-priority,replaces Min-SE:

1800

CSeq: 101 INVITE Session-Expires:

1800

X-cisco-dest-route-string: Contact: ;video;audio Max-Forwards: 69 Content-Type: application/sdp 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 193

23/10/20 3:59 PM

194    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 three-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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 194

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     195 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.

4

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 [email protected] 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 195

23/10/20 3:59 PM

196    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 partitions. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 196

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     197

4 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 choose 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 197

23/10/20 3:59 PM

198    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 198

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     199 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:///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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 199

23/10/20 3:59 PM

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

Figure 4-41  Dialed Number Analyzer Phone Analysis

From the Library of Green Systems LLC

9780136575542_BOOK.indb 200

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     201

4

Figure 4-42  Dialed Number Analyzer Phone Analysis 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 201

23/10/20 3:59 PM

202    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

Figure 4-43  Dialed Number Analyzer Phone Analysis Results Summary

From the Library of Green Systems LLC

9780136575542_BOOK.indb 202

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     203 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 shown in Figure 4-44.

4

Figure 4-44  Dialed Number Analyzer Phone Analysis 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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 203

23/10/20 3:59 PM

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

Figure 4-45  Dialed Number Analyzer Phone Analysis Results Route List 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 204

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     205 Once installed, launch the application and log in. You should see a window similar to the one in Figure 4-46.

4

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 time frame, 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 205

23/10/20 3:59 PM

206    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 time frame 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 206

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     207 File Options page. This is where you can specify the time frame 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 time frame 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 time frame 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 postprocessing tools make this task much easier.)

4

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: match(pi="2",fqcn="+ 19199943782", cn="89943782", plv="5", pss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines", TodFilteredPss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns: Internal:International:Local:LongDistance:PhoneLines", dd="4",dac="1")

From the Library of Green Systems LLC

9780136575542_BOOK.indb 207

23/10/20 3:59 PM

208    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 02102283.009 |21:21:54.310 |AppInfo tchesExist

|Digit analysis: potentialMatches=NoPotentialMa

02102284.000 |21:21:54.310 |SdlSig |DaRes |setup_da |Cdcc(2,100,39,35) |Da(2,100,47,1) |2,100,251,51.1319^10.122.251.105^SEP885A92D9BCA8 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=49629837 Block NoPotentialMatchesExist OnNetpatternUsage =2requestID =0

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 02102559.008 |21:21:58.612 |AppInfo |Digit analysis: match(pi="2",fqcn="+ 19199943782", cn="89943782", plv="5", pss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines", TodFilteredPss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns: Internal:International:Local:LongDistance:PhoneLines", dd="8",dac="1") 02102559.009 |21:21:58.612 |AppInfo MatchesExist

|Digit analysis: potentialMatches=Potential

From the Library of Green Systems LLC

9780136575542_BOOK.indb 208

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     209 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:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP 10.122.251.105:49369;branch=z9hG4bK2e7256b7 From: "Test Phone 2" ; tag=885a92d9bca81de3071848f1-47f71bef To:

4

Call-ID: [email protected] Max-Forwards: 70 Session-ID: 47dbbea900105000a000885a92d9bca8;remote=00000000000000000000000000000000 Date: Fri, 22 May 2020 01:21:49 GMT CSeq: 101 INVITE User-Agent: Cisco-CP7841/12.6.1 Contact: ;+u.sip!devicename.ccm.cisco.com="SEP885A92D9BCA8" Expires: 180 Accept: application/sdp Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO Remote-Party-ID: "Test Phone 2" ;party=calling;id-type=subscriber;privacy=off;screen=yes Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer, X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control, X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-ciscoxsi-8.5.1 Allow-Events: kpml,dialog Recv-Info: conference Recv-Info: x-cisco-conference Content-Length: 689 Content-Type: application/sdp 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 4-6 details the next digit, 9, being sent from the IP phone to Unified CM.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 209

23/10/20 3:59 PM

210    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 4-6  SIP NOTIFY Message with the KPML Digit 9 NOTIFY sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.122.251.105:49369;branch=z9hG4bK1c17832c To: ;tag=1670742895 From: ;tag=885a92d9bca81de51405294e-6f84d4a8 Call-ID: [email protected] Session-ID: b8ce549500105000a000885a92d9bca8;remote=00000000000000000000000000000000 Date: Fri, 22 May 2020 01:21:50 GMT CSeq: 1001 NOTIFY Event: kpml Subscription-State: active; expires=7200 Max-Forwards: 70 Contact: ;+u.sip!devicename.ccm.cisco.com="SEP885A92D9BCA8" Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE Content-Length: 205 Content-Type: application/kpml-response+xml Content-Disposition: session;handling=required

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 02102591.008 |21:21:59.385 |AppInfo |Digit analysis: match(pi="2",fqcn= "+19199943782", cn="89943782", plv="5", pss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines: Block_Check", TodFilteredPss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines:Block_Check", dd="89",dac="1") 02102591.009 |21:21:59.385 |AppInfo MatchesExist

|Digit analysis: potentialMatches=Potential

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 210

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     211 Example 4-8  Digit Analysis Showing Analysis Results for 89915678 02103238.011 |21:22:11.970 |AppInfo |Digit analysis: match(pi="2", fqcn="+19199943782", cn="89943782",plv="5", pss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines: Block_Check", TodFilteredPss="Directory URI:Global Learned E164 Numbers:Global Learned E164 Patterns:Global Learned Enterprise Numbers:Global Learned Enterprise Patterns:Internal:International:Local:LongDistance:PhoneLines:Block_Check", dd="89915678",dac="1") 02103238.012 |21:22:11.970 |AppInfo

|Digit analysis: analysis results

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

4

02103238.012 |21:22:11.970 |AppInfo

|Digit analysis: analysis results

02103238.013 |21:22:11.970 |AppInfo

||PretransformCallingPartyNumber=89943782

|CallingPartyNumber=89943782 |DialingPartition=Internal |DialingPattern=8XXXXXXX |FullyQualifiedCalledPartyNumber=89915678 |DialingPatternRegularExpression=(8[0-9][0-9][0-9][0-9][0-9][0-9][0-9]) |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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 211

23/10/20 3:59 PM

212    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide |ConnectedPartyNumberPi=NotSelected |CallingPartyNamePi=NotSelected |ConnectedPartyNamePi=NotSelected |CallManagerDeviceType=NoDeviceType |PatternPrecedenceLevel=Routine |CallableEndPointName=[a2b59152-1bfe-d81e-2b27-379fe16e2727] |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 CallManager |Called Party Number Type=Cisco Unified CallManager |Called Party Numbering Plan=Cisco Unified CallManager |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) configure 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 212

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     213 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.

4

Example 4-10  Unified CM SQL Query for Device PKID Based on CallableEndPointName admin: run sql select name from device where pkid='a2b59152-1bfe-d81e -2b27-379fe16e2727' 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 |RouteListControl::idle_CcSetupReq RouteList(vnt-cm1-cluster-rl), numberSetup=0 numberMember=2 vmEnabled=0 02103254.007 |21:22:11.972 |AppInfo

|RouteList - RouteGroup count=''1''

02103254.008 |21:22:11.972 |AppInfo

|RouteListCdrc - RouteGroup count = 1

02103254.009 |21:22:11.972 |AppInfo

|RouteListCdrc - Device count = 2

02103258.003 |21:22:11.972 |AppInfo CDRC_SERIAL_DISTRIBUTION type=1

|RouteListCdrc::algorithmCategorization --

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 213

23/10/20 3:59 PM

214    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 4-12  Digit Manipulation on the Route Group 02103258.006 |21:22:11.972 |AppInfo |RouteListCdrc::createPartyTransformedCcSetupRe qMsg - before DAapplyCdpnXform() preXformCdpn=89915678 preTag=SUBSCRIBER prePos= 89915678 crCdpnMask=83922900 crPrefixDigit= crDDI=0 02103258.007 |21:22:11.972 |AppInfo |RouteListCdrc::createPartyTransformedCcSetup ReqMsg - after DAapplyCdpnXform() xformCdpn=83922900 xformTag=SUBSCRIBER xformPos=89915678 02103258.008 |21:22:11.972 |AppInfo |RouteListCdrc::transformed cdpn (without unconsumpt digits) = 83922900, unconsumed digit=

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::findLocalDevice - Name=vntcm1b Key=cb9c24be-3d11-2003-cca8-ae393967ef64 isActvie=1 Pid=(2,181,13) found

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 [email protected], 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_SdlSPISignal: Outgoing SIP TCP message to 172.18.106.59 on port 5061 index 68 [333047,NET] INVITE sip:[email protected]:5061 SIP/2.0 Via: SIP/2.0/TLS 10.122.249.71:5061;branch=z9hG4bK53603d10240 From: "Test Phone 2" ;tag=159601~c1c9 b4c0-de76-4127-bdc8-97f098ac0580-49629843 To: Date: Fri, 22 May 2020 01:22:11 GMT Call-ID: [email protected] Supported: 100rel,timer,resource-priority,replaces Min-SE:

1800

User-Agent: Cisco-CUCM12.5 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence, kpml Supported: X-cisco-srtp-fallback,X-cisco-original-called Call-Info: ; security= Unknown; gci= 2-1037; isVoip, ;method="NOTIFY;Event=telephone-event;Duration=500" Call-Info: ;x-cisco-video-traffic-class=DESKTOP Session-ID: 3a72348700105000a000885a92d9bca8;remote=00000000000000000000000000000000 Cisco-Guid: 2815633664-0000065536-0000000026-1207532042

From the Library of Green Systems LLC

9780136575542_BOOK.indb 214

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     215 Session-Expires:

1800

P-Asserted-Identity: "Test Phone 2" Remote-Party-ID: "Test Phone 2" ;party=calling;scree n=yes;privacy=off Contact: ;+u.sip!devicename.ccm. cisco.com="SEP885A92D9BCA8" Max-Forwards: 69 Content-Type: application/sdp 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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 215

23/10/20 3:59 PM

216    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 216

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     217 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.

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 217

23/10/20 3:59 PM

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

Figure 4-53  TranslatorX Raw Trace File View

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 218

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     219

4

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 219

23/10/20 3:59 PM

220    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 files 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 220

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     221

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.

4

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 221

23/10/20 3:59 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 222

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     223

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.

4

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.

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: 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 4-6 lists these key topics and the page number on which each is found. Table 4-6  Key Topics for Chapter 4 Key Topic Element

Description

Page

Table 4-2

Wildcard Characters for Numeric Patterns

126

Paragraph

Closest-match routing with variable-length patterns

128

Paragraph

Interdigit timeout and urgent priority

130

Table 4-3

Wildcard Characters for Alphanumeric URI Patterns

130

List

Types of transformations

131

From the Library of Green Systems LLC

9780136575542_BOOK.indb 223

23/10/20 3:59 PM

224    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Key Topic Element

Description

Page

Paragraph

Order of operations for transformations

132

Paragraph

External phone number mask

135

Figure 4-2

Relationships Between Route Patterns, Route Lists, Route Groups, Gateways, and Trunks

136

Table 4-5

Parameters on the Route Pattern Configuration Page

138

Paragraph

Transformations on route list details

143

Paragraph

Stop routing parameters

145

Paragraph

Local route groups

148

List

Line group distribution algorithms and hunt options

151

Paragraph

Route plan report usage

154

Paragraph

Partitions and calling search spaces

155

Figure 4-18

Partition and Calling Search Space Example

161

Paragraph

Device/line calling search space interaction

162

Figure 4-23

Example Translation Pattern Call Routing Flow

166

Paragraph

Calling search space selection on a translation pattern

167

Paragraph

Transformation pattern operations on original calling/ called party numbers

171

Paragraph

Understanding transformation priorities

172

Paragraph

Building a tail-end hop off dial plan

178

Figure 4-32

URI Routing in Unified CM

185

Paragraph

Cluster ID significance in ILS

190

Paragraph

Use of route strings for call routing

192

Paragraph

Alternate number types

194

Paragraph

PSTN failover with GDPR

195

Section

Dialed Number Analyzer

198

Paragraph

Session Trace Log View feature

205

Paragraph

Collecting call routing traces

206

Paragraph

Digit analysis logging

207

Paragraph

Logging of potential matches

208

Example 4-9

Digit analysis results in an SDL trace

211

Paragraph

Digit Analysis Complexity parameter

212

Section

TranslatorX

215

Section

Collaboration Solutions Analyzer

220

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 224

23/10/20 3:59 PM

Chapter 4: Unified CM Call Routing and Digit Manipulation     225

Define Key Terms Define the following key terms from this chapter and check your answers in the glossary: 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, Intercluster Lookup Service (ILS), 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

4

From the Library of Green Systems LLC

9780136575542_BOOK.indb 225

23/10/20 3:59 PM

CHAPTER 5

Unified CM SIP Trunk Configuration This chapter covers the following topics: 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. 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.d Session timers

■■

1.3 Troubleshoot media establishment

■■

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 that 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 226

23/10/20 3:59 PM

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.

“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 5-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 5-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

SIP Trunk Overview and Configuration

1–3

SIP Trunk Features

4–6

Verify and Troubleshoot Unified CM SIP Trunks

7–8

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 227

23/10/20 3:59 PM

228    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. Perform 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 multinode 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 228

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    229

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.

5

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. 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 that 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 process.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 229

23/10/20 3:59 PM

230    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Unity Connection

CUBE

SIP

SIP Unified CM

SIP

SIP

IM&P

Unified CM

Figure 5-1  Various SIP Trunk Integrations with Unified CM 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 230

23/10/20 3:59 PM

9780136575542_BOOK.indb 231

INVITE sip:2000@rtp-cucm:5060 SIP/2.0 From: ;tag=6463 To: Call-ID: [email protected] Contact: Content-Length: 0

Inbound INVITE

Send Egress Message Based on Outbound Called Device Configuration

Unified CM Digit Analysis Occurs

Determine Inbound Calling Device Based on Remote IP and Port

Unified CM

Figure 5-2  Inbound Call to a Unified CM SIP Trunk Device

1.1.1.1

INVITE sip:[email protected]:5060 SIP/2.0 From: ;tag=20268 To: Call-ID: 5caff700-10001-40-0@sj-cucm Contact: Content-Length: 0

Outbound INVITE

2.2.2.2

Chapter 5: Unified CM SIP Trunk Configuration    231

5

From the Library of Green Systems LLC

23/10/20 3:59 PM

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

SIP Trunk Configuration The SIP trunk configuration page is separated 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 232

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    233 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.

5

NOTE  Retry Video Call as Audio relies on call admission control (CAC), which is a topic covered in Chapter 6.

IP Phone

SJ Unified CM

RTP Unified CM

IP Phone

INVITE m=audio, a=sendrecv m=video, a=recvonly INVITE m=audio, a=sendrecv m=video, a=recvonly

INVITE m=audio, a=sendrecv m=video, a=inactive INVITE m=audio, a=sendrecv m=video, a=inactive

Figure 5-4  Sample Call That Starts as Video and Falls Back to Audio After Failure

From the Library of Green Systems LLC

9780136575542_BOOK.indb 233

23/10/20 3:59 PM

234    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Figure 5-4 illustrates the following process: 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 user at phone number 1000 calls the other user at phone number 2000. At this point the SJ Unified CM already received the SIP INVITE from the phone and is processing the call. 01814796.011 |06:39:11.254 |AppInfo |: match(pi="2", fqcn="1000", cn="1000",plv="5", pss="", TodFilteredPss="", dd="2000",dac="0") ##### Step 2: We see this call is going to traverse the trunk which connects the SJ cluster to the RTP cluster. 01814818.003 |06:39:11.287 |AppInfo |SMDMSharedData::findLocalDevice - Name=SIP_ TRUNK_TO_RTP_CLUSTER Key=a6c9f500-89da-67e7-8521-76c611498886 isActvie=1 Pid=(1,181,5) found ##### Step 2: A little later there is an LBM request and part of the request includes bandwidth for video. 01814824.000 |06:39:11.293 |SdlSig |LBMRegisterReq |active |LBMInterface(1,100,83,1) |ReservationMgr(1,100,152,1) |1,100,251,385.39^14.50.214.108^SEPC4B36ABA1B5A |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0] ci=18585432 location=0 locName=Hub_None locPkid=29c5c1c4-8871-4d1e-8394-0b9181e8c54d fateShareId=sjcluster:18585432 bearerless=F videoCall=T videoCap=T videoClass=4 videoKbp=384 retryAsAudio=T ipMode=0 mediaEP=F precedence=5 nonPreemptable=F region=g711_region regState=0 XferMode=16 cacPartyState=0 ##### Step 2: The request fails 01814825.002 |06:39:11.396 |AppInfo |LBMIF: CI: 18585432 BW RSV

dev 0xe45f3ab8

01814825.006 |06:39:11.396 |AppInfo |LBMIF: RSV XML> (41) 1568600405292613661 no_ video_location|Hub_None A:Y,80 V:N,0 I:N,0 Force:0 Prec:5 Dpl:5

From the Library of Green Systems LLC

9780136575542_BOOK.indb 234

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    235 ##### Step 4: Eventually the SJ Unified CM sends a SIP INVITE to the RTP Unified CM and the call moves forward. 01814858.001 |06:39:11.429 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.91 on port 5060 index 20 [60444,NET] INVITE sip:[email protected]:5060 SIP/2.0 From: ;tag=20268~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe718585432 To: Call-ID: [email protected] CSeq: 101 INVITE Content-Length: 575 c=IN IP4 14.50.214.108 m=audio 16466 RTP/AVP 114 101 a=sendrecv m=video 0 RTP/AVP 31 34 96 97 a=inactive

5

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. Example 5-2  CallManager SDL Trace Analysis for Unchecked Retry Video Call as Audio ##### The LBM registration request is sent with video. 01811704.000 |06:08:42.592 |SdlSig |LBMRegisterReq |active |LBMInterface(1,100,83,1) |ReservationMgr(1,100,152,1) |1,100,251,385.16^14.50.214.108^SEPC4B36ABA1B5A |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0] ci=18585430 location=0 locName=Hub_None locPkid=29c5c1c4-8871-4d1e-8394-0b9181e8c54d fateShareId=sjcluster:18585430 bearerless=F videoCall=T videoCap=T videoClass=4 videoKbp=384 retryAsAudio=F ipMode=0 mediaEP=F precedence=5 nonPreemptable=F region=g711_region regState=0 XferMode=16 cacPartyState=0 ##### The request fails. 01811706.002 |06:08:42.646 |AppInfo |LBMIF: CI: 18585430 BW RSV 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/.

5

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 247

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 248

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    249

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 to Unified CM listening on 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:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.12:5065;branch=z9hG4bK12a9341f7ac6ec

5

Contact:

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.

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 249

23/10/20 3:59 PM

250    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Cisco Unity Connection

Unified CM

INVITE without SDP 100 Trying 180 Ringing 200 OK with SDP ACK with SDP

SIP Dialog 1

Bidirectional RTP BYE 200 OK NOTIFY (MWI) 200 OK

SIP Dialog 2

Figure 5-14  Sample Call to Cisco Unity Connection with Subsequent Unsolicited SIP NOTIFY for MWI

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 250

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    251

Figure 5-15  Standard SIP Profile

5

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 251

23/10/20 3:59 PM

252    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 that 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): Supported: 100rel,timer,resource-priority,replaces 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 252

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    253 Example 5-6  CallManager SDL Trace Analysis for Call Rejected Based on Anonymous Caller ID ##### The SIP trunk receives an INVITE which is from an anonymous source. 01563228.002 |14:46:30.299 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.18.110.91 on port 33615 index 12 with 2904 bytes: [213830,NET] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 172.18.110.91:5060;branch=z9hG4bK1d1450ac71 From: "Anonymous" ;tag=9112~594cd2d2-a0cb-41cd93ca-ed8ff9be0241-24527014 To: Call-ID: [email protected] User-Agent: Cisco-CUCM12.5 CSeq: 101 INVITE X-Cisco-Presentation: "anonymous" ;party=internal P-Asserted-Identity: Privacy: id Remote-Party-ID: ;party=calling;screen=yes;privacy=full

5

Contact: ;video;audio;+u.sip!devicename.ccm. cisco.com="SEPC4B36ABACA23" ##### After the parameter is checked, the server prints a log entry stating we need to reject the call due to anonymous calling party. 01563242.016 |14:46:30.302 |AppInfo |SIPCdpc(9) - processSIPSetupMsg: Incoming anonymous call is rejected with reason: Caller's Number is not available value 1 ##### The response to the INVITE is seen below and it is a SIP 433 Anonymity Disallowed. We also see there is a reason code 21 associated with the failed call. 01563244.001 |14:46:30.302 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.91 on port 33615 index 12 [213832,NET] SIP/2.0 433 Anonymity Disallowed Via: SIP/2.0/TCP 172.18.110.91:5060;branch=z9hG4bK1d1450ac71 From: "Anonymous" ;tag=9112~594cd2d2-a0cb-41cd-93ca-ed8ff9be0241-24527014 To: ;tag=102437~bbab2af3-f2b4-4a8c-a020a2cc3e6cebe7-24527079 Date: Mon, 02 Dec 2019 19:46:30 GMT Call-ID: [email protected] CSeq: 101 INVITE Server: Cisco-CUCM12.5 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 253

23/10/20 3:59 PM

254    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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) - null0_CcSetupReq: Call from anonymous caller is rejected reason=2

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. Unified CM

IP Phone

CUBE INVITE with SDP

INVITE with SDP

Unified CM

IP Phone INVITE without SDP

CUBE INVITE without SDP

Figure 5-17  Using Best Effort (No MTP Inserted) with a Unified CM SIP Trunk

From the Library of Green Systems LLC

9780136575542_BOOK.indb 254

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    255 ■■

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

5 NOTE  Unified CM can also be configured to utilize local, software MTPs that can be used in place of the MTP on the voice gateway.

Unified CM

IP Phone

INVITE with SDP

INVITE with SDP

IP Phone

Unified CM

1

CUBE

CUBE

3 INVITE with SDP

INVITE without SDP

2

SCCP

RTP 4

RTP 4

V MTP on Voice Gateway Used for Early Offer

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 255

23/10/20 3:59 PM

256    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 destination 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 destination 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 destination marked as in service. For IP Phones registered to Unified CM Server B, outbound calls that should be routed to the problematic SIP Trunk destination will fail. Unified CM Server B will not hand the call over to Unified CM Server A in this scenario. That being said, if there are other reachable destinations configured on the SIP trunk then Unified CM Server B will attempt to route the outbound call using those remote peers. 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 256

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    257 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.

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

5

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.

Figure 5-20  SIP Trunk Status Reported Through 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 257

23/10/20 3:59 PM

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

Figure 5-21  Media Termination Point Required 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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 258

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    259 Unified CM Cluster

INVITE sip: +18005532447 Node 1

SDL

INVITE sip: +18005532447 Node 2

Node 3

5

SIP Trunk’s UCM Group

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. SIP Trunk with Run On All Active Unified CM Nodes Unified CM Cluster

INVITE sip: +18005532447

INVITE sip: +18005532447 Node 1

Node 2

Node 3 SIP Trunk’s UCM Group

Figure 5-23  Sample Call with Run On All Active CM Nodes Enabled

From the Library of Green Systems LLC

9780136575542_BOOK.indb 259

23/10/20 3:59 PM

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

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 cucmpcap admin: utils network capture-rotate ? Syntax: utils network capture-rotate [options] options

mandatory

file fname

options optional size bytes,sizePerFile megabytes, maxFiles num,src addr,dest addr,port num,host protocol addr

From the Library of Green Systems LLC

9780136575542_BOOK.indb 260

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    261 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 ip 192.168.120.5 port 5060 file filteredcucmpcap Executing command with options: size=ALL

count=1000

interface=eth0

src=

dest=

port=5060

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.

5

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 261

23/10/20 3:59 PM

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

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,” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/ admin/12_5_1SU1/systemConfig/cucm_b_system-configuration-guide-1251su1/ cucm_b_system-configuration-guide-1251su1_restructured_chapter_01001.html Cisco, “Cisco Collaboration System 12.x Solution Reference Network Designs (SRND),” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12.html Cisco, “Feature Configuration Guide for Cisco Unified Communications Manager, Release 12.5(1)SU1,” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/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,” http://www.rfcreader.com/#rfc3515_line96 Network Working Group, “Session Timers in the Session Initiation Protocol (SIP),” http://www.rfcreader.com/#rfc4028_line648 Network Working Group, “Reliability of Provisional Responses in the Session Initiation Protocol (SIP),” https://tools.ietf.org/html/rfc3262

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: 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 5-2 lists these key topics and the page number on which each is found. Table 5-2  Key Topics for Chapter 5 Key Topic Element

Description

Page

List

SIP trunk configuration components

230

Paragraph

The value of call classification

232

Paragraph

Retrying a video call as audio

233

Paragraph

Significant digits

236

Paragraph

Prefix DN parameter

237

Paragraph

Incoming called party settings

239

Paragraph

Remote destinations

245

From the Library of Green Systems LLC

9780136575542_BOOK.indb 262

23/10/20 3:59 PM

Chapter 5: Unified CM SIP Trunk Configuration    263 Key Topic Element

Description

Page

Paragraph

Incoming port

249

Paragraph

Rejecting anonymous incoming calls

252

Paragraph

SIP early offer and SIP delayed offer

254

Paragraph

SIP trunk status

257

Paragraph

Running on all active CM nodes

259

Complete Tables and Lists from Memory There are no memory tables or lists for this chapter.

Define Key Terms Define the following key terms from this chapter and check your answers in the glossary: OnNet, OffNet

5

From the Library of Green Systems LLC

9780136575542_BOOK.indb 263

23/10/20 3:59 PM

CHAPTER 6

Unified CM Call Control Features This chapter covers the following topics: 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.

This chapter covers the following CLACCM 300-815 exam topics: ■

1.1 Troubleshoot these elements of a SIP conversation ■

1.1.c Mid-call signaling (hold/resume, call transfer, conferencing)

■

1.3 Troubleshoot media establishment

■

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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 264

23/10/20 3:59 PM

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.

“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 6-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 6-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Media Resources

1, 2

Ad Hoc and Meet-Me Conferencing

3–6

Music on Hold (MOH)

7, 8

Media Resource Groups and Media Resource Group Lists

9

Call Park

10, 11

Call Pickup

12

Regions and Codec Preferences

13, 14

Call Admission Control (CAC)

15, 16

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)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 265

23/10/20 3:59 PM

266    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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, into 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 266

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    267 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 groups that are in the list that is configured on the phone. b. The media resource groups from the two lists are combined, with preference for the groups that are in 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 267

23/10/20 3:59 PM

268    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 268

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    269 ■

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 toneon-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).

6

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 269

23/10/20 3:59 PM

270    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 270

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    271 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 allow these codecs to be used between other endpoints and the media resource or you have an appropriate transcoding resource available.

6

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 an 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 271

23/10/20 3:59 PM

272    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Module" PID: PVDM4-64 , VID: V01 , SN: FOCXXXXXXXXXX ISR-4451-X# show run | section sccp|voice-card|dspfarm ! 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 272

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    273 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 , 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. 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.

6

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 ondemand 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 associate 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 273

23/10/20 3:59 PM

274    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 274

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    275 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 275

23/10/20 3:59 PM

276    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 6-2  Conference Configuration Parameter Details Parameter

Description

Suppress MOH to Conference Bridge

This parameter controls whether MOH is played toward participants in a conference if a participant places the call on hold. In general, you should leave this set to the default value of True, which means MOH is suppressed when a participant places a call on hold.

Drop Ad Hoc Conference

This parameter has three options: ■

Never: An ad hoc conference is not dropped, even if the conference controller leaves or if all remaining participants are off-net.

■

When Conference Controller Leaves: If the user who initiated the ad hoc conference hangs up, the conference is ended, and the call is ended for any participants remaining in the conference.

■

When No OnNet Parties Remain in the Conference: This parameter helps prevent toll fraud by ensuring that at least one on-net participant remains on a conference at all times.

Maximum Ad Hoc Conference

This parameter indicates the maximum number of participants allowed to be added to a particular ad hoc conference. IOS conference resources support up to eight participants in a conference, and in order to get eight participants, you must change this parameter to at least eight. The maximum supported for each type of conference resource may differ from this value, so the maximum is this value or the maximum supported by the resource, whichever is lower.

Maximum MeetMe Conference Unicast

This parameter indicates the maximum number of participants allowed to join a particular Meet-Me conference. The maximum supported for each type of conference resource may differ from this value, so the maximum is this value or the maximum supported by the resource, whichever is lower.

Advanced Ad Hoc Conference Enabled

Without this parameter set, a conference call has a single conference controller—the person who initiated the ad hoc conference—and no one else is allowed to add or drop parties in the conference. This parameter allows others in the conference to add or drop participants as well as join other conferences to this conference.

Non-linear Ad Hoc Conference Linking Enabled

By default, if the Advanced Ad Hoc Conference Enabled parameter is set to true, more than one conference can be linked, as long as it is done in a linear fashion; in other words, a conference bridge can be linked to at most two other conferences. This parameter permits three or more conferences to be linked to a single conference. Note that this can result in conference resources never being released, and it should therefore be enabled with caution. In most real-world scenarios, this parameter is not necessary.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 276

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    277 Parameter

Description

Choose Encrypted Audio Conference Instead of Video Conference

When a device supports encryption, and video and conference resources support either only encrypted audio or unencrypted video, this parameter determines which resource takes priority when there is no resource supporting both encryption and video available.

Minimum Video Capable Participants to Allocate Video Conference

When an ad hoc conference is started, there are initially three participants. This parameter determines how many of those three participants must be video capable for Unified CM to prefer a video-capable conference resource. If you want Unified CM to always select a video resource as long as one of the devices is video capable, change this parameter to 1.

Allocate Video Conference Bridge for Audio Only Conferences When the Video Conference Bridge Has Higher Priority

Media resource group lists (MRGLs) allow an administrator to prioritize media resources. By default, Unified CM uses the Minimum Video Capable Participants to Allocate Video Conference parameter to determine whether to prefer an audio resource that has a lower priority over a higher-priority video resource with the intent of saving video resources for only video-capable devices. This parameter removes that logic and strictly selects resources based on the MRGL priority, without consideration of whether the resource is an audio or video resource. Setting this parameter makes the Minimum Video Capable Participants to Allocate Video Conference parameter irrelevant.

Cluster Conferencing Prefix Identifier

This is similar to the conference bridge prefix identifier available on the conference resource configuration page, but this parameter is global and applies to all SIP conference resources.

6

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, 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 on 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 277

23/10/20 3:59 PM

278    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 278

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    279 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, “VoIP Protocols: RTP, RTCP, and DTMF Relay.”

6

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 navigating to Unified CM Administration > Call Routing > 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 279

23/10/20 3:59 PM

280    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 280

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    281 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.

6

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.711μlaw is supported. You can multiselectall 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 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 281

23/10/20 3:59 PM

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

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 four 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 282

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    283 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 Audio Source

Codec

Increment on IP Address

Increment on Port Number

Destination IP Address

Destination Port

Destination IP Address

Destination Port

1

G.711ulaw

239.1.1.1

16384

239.1.1.1

16384

1

G.711alaw

239.1.1.2

16384

239.1.1.1

16386

1

G.729

239.1.1.3

16384

239.1.1.1

16388

1

Wideband

239.1.1.4

16384

239.1.1.1

16390

2

G.711ulaw

239.1.1.5

16384

239.1.1.1

16392

2

G.711alaw

239.1.1.6

16384

239.1.1.1

16394

2

G.729

239.1.1.7

16384

239.1.1.1

16396

2

Wideband

239.1.1.8

16384

239.1.1.1

16398

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 283

23/10/20 3:59 PM

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

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. Audio Source Device (for Example, Media Player or CD Player)

Analog Audio

IP Audio Streaming Device

Multicast IP

IP Network Unicast IP

Figure 6-12  Music on Hold Multicast Rebroadcasting From the Library of Green Systems LLC

9780136575542_BOOK.indb 284

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    285

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.

6

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, which 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 285

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 286

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    287 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 287

23/10/20 3:59 PM

288    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 288

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    289 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 a 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 289

23/10/20 3:59 PM

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

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 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 park 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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 290

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    291 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.

6

From the Library of Green Systems LLC

9780136575542_BOOK.indb 291

23/10/20 3:59 PM

292    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 292

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    293 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 293

23/10/20 3:59 PM

294    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 6-4  Conference Configuration Parameter Details Region A

Region B

Region C

Region D

Region A

Intraregion, 64 kbps

Interregion, 8 kbps

Interregion, 8 kbps

Interregion, 8 kbps

Region B

Intraregion, 8kbps

Intraregion, 64 kbps

Interregion, 8 kbps

Interregion, 8 kbps

Region C

Intraregion, 8kbps

Intraregion, 8kbps

Intraregion, 64 kbps

Interregion, 8 kbps

Region D

Intraregion, 8kbps

Intraregion, 8kbps

Intraregion, 8kbps

Intraregion, 64 kbps

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. Communications 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. Site/Region B

Site/Region A G.729

G.722

G.722

G.729

G.729 WAN

G.729

G.729

Site/Region C

Site/Region D G.722

G.729

G.722

Figure 6-19  Codec Selection Between Four Regions

From the Library of Green Systems LLC

9780136575542_BOOK.indb 294

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    295 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.

6

Figure 6-20  Factory Default Lossy Audio Codec Preference List From the Library of Green Systems LLC

9780136575542_BOOK.indb 295

23/10/20 3:59 PM

296    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 is 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 296

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    297 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 six 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 bit rate 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.

6

From the Library of Green Systems LLC

9780136575542_BOOK.indb 297

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 298

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    299 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.

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 299

23/10/20 3:59 PM

300    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 300

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    301

Publisher LBM Group 1

LBM Group 2

Primary

Secondary

LBM Group 3

Primary

Unified CM 1

Secondary Unified CM 3

Primary

Secondary

LBM Group 4

Unified CM 2

Primary

Secondary Unified CM 4

Figure 6-23  LBM Group Topology

6

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 301

23/10/20 3:59 PM

302    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 intralocation 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 302

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    303 Remote Site 1

Remote Site 2

V

V 2 Mbps Weight: 10

4 Mbps Weight: 10 MPLS WAN

100 Mbps Weight: 10

200 Mbps Weight: 5

V

V

Campus 1

V

1 Gbps Weight: 10

V

1 Gbps Weight: 10

Campus 2

1 Gbps Weight: 10

V 6 Campus 3

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 303

23/10/20 3:59 PM

304    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 lowerspeed 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 higherbandwidth 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 through ­ 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. 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 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 304

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    305

6 Figure 6-26  Location Configuration 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 305

23/10/20 3:59 PM

306    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. Remote Site 1

1

V

85551000

V

Remote Site 2

Call from 85551000 to 85552000

V

128k Available

3

MPLS WAN

Reroute to +19195552000 2 Mbps Available

2 Mbps Available

V

V

PSTN Campus 1 0 kbps Available

V

V

Campus 2

V 2 1 Mbps Available

85552000

1 Mbps Available

V

Campus 3

Figure 6-28  AAR in Action Example

From the Library of Green Systems LLC

9780136575542_BOOK.indb 306

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    307 The figure shows the following steps: 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 307

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 308

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    309 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 is 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.

6

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 309

23/10/20 3:59 PM

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

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,

From the Library of Green Systems LLC

9780136575542_BOOK.indb 310

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    311 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 Via: SIP/2.0/TCP 10.122.251.105:49820;branch=z9hG4bK02a02cad From: "Test Phone 2" ;tag=885a92d9bca 800772f938f9b-61ae84eb To: ;tag=836~c1c9b4c0-de76-4127-bdc8-97f098ac0580-43759214 Call-ID: [email protected] CSeq: 101 INVITE Allow-Events: presence Server: Cisco-CUCM12.5 Session-ID: 00000000000000000000000000000000;remote=565dd44100105000a000885a92d9bca8 Warning: 370 10.122.249.71 "Insufficient Bandwidth" Reason: Q.850; cause=125 Remote-Party-ID: "Test Phone 1" ;part y=x-cisco-original-called;privacy=off 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.

6

Example 6-3  CAC Failure Messages in SDL Trace 00018315.001 |00:24:09.958 |AppInfo |LBMIF: CI: 43759215 REGISTER 2,100,180,32 dev 0xf5f08e60 00018315.002 |00:24:09.958 |AppInfo |LBMIF: device 0xf5f08e60 A:Y V:N I:N ; peer 0xf5f07af8 A:Y V:N I:N | UV:T QoS:F 00018315.004 |00:24:09.958 |AppInfo |LBMIF: CI: 43759215 BW RSV> dev 0xf5f08e60 13210859295534481424 audio 24 00018315.005 |00:24:09.958 |AppInfo |LBMIF: RSV XML> (35) 13210859295534481424 Remote Site 1|Campus 1 A:Y,24 V:N,0 I:N,0 Force:0 Prec:5 Dpl:5 00018315.006 |00:24:09.958 |AppInfo |LBMIF: Sending to ACTIVE LBM (svs-uc-alphatest-cm1b.cisco.com) 00018316.001 |00:24:09.960 |AppInfo |LBMIF: RSV XML< (35) 13210859295534481424 FA:Y,24 V:Y,0 I:Y,0 00018316.002 |00:24:09.960 |AppInfo |LBMIF: CI: 43759215 BW RSVRemote Site 1 00001152.002 |00:40:15.963 |AppInfo |LBM: RES_REC Enough for 24 on Vertex=Campus 1. Left=0, Calls=1 00001152.003 |00:40:15.963 |AppInfo |LBM: RES_REC Enough for 24 on Vertex=MPLS WAN. Left=0, Calls=1 00001152.004 |00:40:15.963 |AppInfo |LBM: RES_REC Enough for 24 on Vertex=Remote Site 1. Left=0, Calls=1 00001152.005 |00:40:15.963 |AppInfo |LBM: RES_REC Enough for 24 on Edge Campus 1->MPLS WAN. Left=1976, Calls=1 00001152.006 |00:40:15.963 |AppInfo |LBM: RES_REC NOT Enough for 24 on Edge MPLS WAN->Remote Site 1. Left=0, Calls=1. FAIL. (ProcessLocationHelper.cpp:163)

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: AlarmName = LocationOutOfResource, subFac = Location Bandwidth ManagerKeyParam = , severity = 4, AlarmMsg = Name : MPLS WAN->Remote Site 1 ResourceType : 1 AppID : Cisco Location Bandwidth Manager

6

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.

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: 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 6-5 lists these key topics and the page number on which each is found.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 313

23/10/20 3:59 PM

314    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 6-5  Key Topics for Chapter 6 Key Topic Element

Description

Page

Paragraph

IP Voice Media Streaming App service

269

List

Types of ad hoc conference resources

270

Paragraph

Software conference bridge parameters

271

Example 6-1

IOS configuration for conference resources

272

Note

Certificates for CMS ad hoc conferencing

275

Table 6-2

Conference configuration parameter details

276

Paragraph

How to initiate a Meet-Me conference

278

Paragraph

Conference Now feature

278

Note

IVR DTMF support

279

Paragraph

MOH-supported codecs

281

Paragraph

MOH audio sources with multicast

282

Paragraph

Types of hold

285

Paragraph

Understanding the default MRG

286

Paragraph

MRGL selection

287

Paragraph

Unified CM selection for call park numbers

288

Paragraph

Call park monitoring feature support

289

Paragraph

BLF for directed call park

290

Paragraph

Retrieval prefix

291

List

Types of call pickup

291

Paragraph

Audio codec preference lists

295

Paragraph/list

Parameters to enable/disable codecs

297

Paragraph

Deduct Audio Bandwidth Portion from Audio Pool for a Video Call parameter

299

Paragraph

CallManager association with LBM service

300

Paragraph

Locations with no links lead to call failures

302

Figure 6-28

AAR example

306

Note

AAR requires external phone number mask or AAR destination mask

308

Paragraph

Effective path troubleshooting tool

309

Example 6-2

SIP response for being out of bandwidth

311

Complete Tables and Lists from Memory There are no memory tables or lists for this chapter.

Define Key Terms Define the following key terms from this chapter and check your answers in the glossary: 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 314

23/10/20 3:59 PM

Chapter 6: Unified CM Call Control Features    315 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

6

From the Library of Green Systems LLC

9780136575542_BOOK.indb 315

23/10/20 3:59 PM

CHAPTER 7

Unified CM Mobility This chapter covers the following topics: 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.

This chapter covers the following CLACCM 300-815 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 316

23/10/20 3:59 PM

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.

“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 7-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 7-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Unified Mobility

1–7

Configure and Verify Extension Mobility

8–11

Configure and Verify Device Mobility

12–14

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 317

23/10/20 3:59 PM

318    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 318

23/10/20 3:59 PM

Chapter 7: Unified CM Mobility    319 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

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 319

23/10/20 3:59 PM

320    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. 20E, DeviceName=SEPD0EC35FFB4C4, DeviceType=36225 IpAddr=6AD63 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).

From the Library of Green Systems LLC

9780136575542_BOOK.indb 320

23/10/20 3:59 PM

Chapter 7: Unified CM Mobility    321 2 Remote Destination Profile Remote Destination: 408-555-7890

4 5 PSTN/ITSP

DN: 1001

1

Remote Destination +14085557890

3

DN: 1000

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 occurs: ■

The called party answers the call on the IP phone 1000.

■

The remote destination 408-555-7890 answers the call.

7

From the Library of Green Systems LLC

9780136575542_BOOK.indb 321

23/10/20 3:59 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 322

23/10/20 3:59 PM

Chapter 7: Unified CM Mobility    323 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.

7

Figure 7-4  Remote Destination Profile Configuration Page

From the Library of Green Systems LLC

9780136575542_BOOK.indb 323

23/10/20 3:59 PM

324    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 ­c alling 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 324

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    325

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

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 325

23/10/20 4:00 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 326

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    327

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

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 327

23/10/20 4:00 PM

328    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 328

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    329 desk phone. This timer 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 either the Answer Too Soon timer or Answer Too Late timer is set to 0, the respective timer is disabled. Delay Before Ringing Answer Too Soon

Answer Too Late Forward No Answer

0

6

12

24

18

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.

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 329

23/10/20 4:00 PM

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

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 330

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    331

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

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 331

23/10/20 4:00 PM

332    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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: 3 Remote Destination Profile

2

Remote Destination: 408-555-7890

1

4

5

PSTN/ITSP Remote Destination +14085557890

DN: 1001

DN: 1000

Figure 7-18  Inbound Call from a Remote Destination

From the Library of Green Systems LLC

9780136575542_BOOK.indb 332

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    333 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 seven 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.

7

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 Administration > System > Service Parameters > Server > 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 333

23/10/20 4:00 PM

334    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide updated with the latest information from Unified CM. Figure 7-21 shows a call flow using Intelligent Session Control: 2 Remote Destination Profile Remote Destination: 408-555-7890

3 PSTN/ITSP DN: 1000

1

Remote Destination +14085557890

DN: 1001

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 could be considered a security concern because someone with access to Unified CM 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. From the Library of Green Systems LLC

9780136575542_BOOK.indb 334

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    335 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.

SJ Unified CM/MOH Server

IP Phone A - 1001

INVITE sip:1000@sj-cucm:5060

IP Phone B - 1000

Remote Destination +14085557890

SJ CUBE

INVITE sip:1000@deskphone:5060

After the Delay Before Ringing Timer expires, Unified CM extends the call to the remote destination. INVITE sip:+14085557890@cube

INVITE sip:+14085557890@remdest:5060 200 OK

200 OK

200 OK

7

CANCEL RTP

RTP BYE

BYE

Some time passes. The remote destination hangs up.

INVITE (a=inactive) 200 OK (a=inactive) IP Phone A Is Put on Hold Until IP Phone B Answers

NOTIFY (Desk Pickup) 200 OK IP Phone B Taken Off-Hook Media Renegotiation

Media Renegotiation RTP

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 335

23/10/20 4:00 PM

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

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 04827703.002 |15:37:30.842 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP ­ message from 14.50.214.106 on port 50322 index 20687 with 2962 bytes: [606276,NET] INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP 14.50.214.106:50322;branch=z9hG4bK3381acac From: "1001" ;tag=d0ec35ffebc4041c57238fa0-47656c2c To: Call-ID: [email protected] CSeq: 101 INVITE Contact: ;+u. sip!devicename.ccm.cisco.com="SEPD0EC35FFEBC4";video Remote-Party-ID: "1001" ;party=calling;id-type= subscriber;privacy=off;screen=yes Content-Type: application/sdp Content-Disposition: session;handling=optional o=Cisco-SIPUA 11557 0 IN IP4 14.50.214.106 m=audio 16598 RTP/AVP 114 9 124 113 115 0 8 116 18 101 c=IN IP4 14.50.214.106 a=sendrecv 04827733.007 |15:37:31.027 |AppInfo |Digit analysis: match(pi="2", fqcn="+14085251001", cn="1001",plv="5", pss="partition_for_dn_1000", TodFilteredPss="partition_for_dn_1000", dd="1000", dac="1") 04827733.008 |15:37:31.028 |AppInfo |Digit analysis: analysis results 04827733.009 |15:37:31.028 |AppInfo ||PretransformCallingPartyNumber=1001 |CallingPartyNumber=1001 |DialingPartition=partition_for_dn_1000 |DialingPattern=1000 |FullyQualifiedCalledPartyNumber=1000 |DialingPatternRegularExpression=(1000) |RouteBlockFlag=RouteThisPattern

From the Library of Green Systems LLC

9780136575542_BOOK.indb 336

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    337 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.

Example 7-2  CallManager SDL Trace Analysis for SNR, Snippet 2 04827752.001 |15:37:31.042 |AppInfo |LineCdpc(39): -dispatchToAllDevices-, sigName=CcSetupReq, device=84085557890_pkinane_RDP 04827752.002 |15:37:31.042 |AppInfo |LineCdpc(39): -dispatchToAllDevices-, sigName=CcSetupReq, device=SEPC4B36ABA1B5A

Step 3.

Unified CM checks the time zone, date, and day of the week and 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.

Example 7-3  CallManager SDL Trace Analysis for SNR, Snippet 3 04827753.004 |15:37:31.049 |AppInfo |TODAccessHelper - isTODAccessAllowed: found todPkid = 7ac14ce7-93d6-6081-d2c6-0efdc15a32de, timezone = 22 for remdest [84085557890] ­ 04827753.005 |15:37:31.049 |AppInfo |TODAccessHelper - isTODAccessAllowed: checking against time = 1/17/120 15:37:31 DayOfWeek [5] 04827753.006 |15:37:31.049 |AppInfo |TODAccessHelper - isTODAccessAllowed: no active access list is found, call is allowed for given cpgn 04827753.007 |15:37:31.050 |AppInfo |SNRD::wait_CcSetupReq (0000011) Caller[1001] is allowed to call [84085557890]

7

04827754.006 |15:37:31.060 |AppInfo |DbMobility - RemDest dump: cnumber = 84085557890, devicePkid = 6cc74fac-d7c2-77ab-e416-55919bd9e131, remDestProfilePkidStr = 08efe16769c1-0bf4-8bee-778a2eeab494, isMobilePhone = 1, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 1, answerTooSoonTimer = 1500, answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = pkinane, timeZoneIndex = 0, ­ requireThirdPartyRegistration = 0, blockIncomingCallsWhenRoaming = 0, homeNetworkID = , description = Mobile Number From SRND, url = , D vorVMAPolicy = 0 SNRVMAvoidancePolicy = 0, ­

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 337

23/10/20 4:00 PM

338    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 7-4  CallManager SDL Trace Analysis for SNR, Snippet 4 04827765.010 |15:37:31.090 |AppInfo |Digit analysis: match(pi="2", fqcn="+14085251001", cn="1001",plv="5", pss="partition_for_call_to_mobile_and_home", TodFilteredPss="partition_for_call_to_mobile_and_home", dd="84085557890",dac="1") 04827765.011 |15:37:31.091 |AppInfo |Digit analysis: analysis results 04827765.012 |15:37:31.091 |AppInfo ||PretransformCallingPartyNumber=+14085251001 |CallingPartyNumber=+14085251001 |DialingPartition= |DialingPattern=+! |FullyQualifiedCalledPartyNumber=+14085557890 |DialingPatternRegularExpression=(+[0-9]+) |RouteBlockFlag=RouteThisPattern

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.

Example 7-5  CallManager SDL Trace Analysis for SNR, Snippet 5 04827823.001 |15:37:31.163 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.108 on port 51621 index 20489 ­ [606281,NET] INVITE sip:[email protected]:51621;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK46f96487a292 From: ;tag=313455~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545485 To: Call-ID: [email protected] CSeq: 101 INVITE Remote-Party-ID: ;party=calling; screen=yes;privacy=off

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

Example 7-6  CallManager SDL Trace Analysis for SNR, Snippet 6 04827855.000 |15:37:35.107 |SdlSig |DelayBeforeRingTimer |delayBeforeRing |CellProxyCdpc(1,100,40,19) |SdlTimerService(1,100,3,1) |1,100,251,760.606^14.50.214.106^SEPD0EC35FFEBC4 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] 04827902.001 |15:37:35.215 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.62 on port 5060 index 21615 [606284,NET] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK46f971b12b3ed

From the Library of Green Systems LLC

9780136575542_BOOK.indb 338

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    339 From: ;tag=313456~bbab2af3-f2b4-4a8ca020-a2cc3e6cebe7-20545485 To: Call-ID: [email protected] CSeq: 101 INVITE P-Asserted-Identity: Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact: ;video;audio;+u.sip!devicename. ccm.cisco.com="SEPD0EC35FFEBC4" 04827963.002 |15:37:43.728 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.18.110.62 on port 5060 index 21615 with 1135 bytes: [606292,NET] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK46f971b12b3ed From: ;tag=313456~bbab2af3-f2b4-4a8c-a020a2cc3e6cebe7-20545485 To: ;tag=B7CEC149-2237 Call-ID: [email protected] CSeq: 101 INVITE Contact: Server: Cisco-SIPGateway/IOS-16.12.1a Content-Type: application/sdp o=CiscoSystemsSIP-GW-UserAgent 9198 1184 IN IP4 172.18.110.62 c=IN IP4 172.18.110.62 m=audio 8094 RTP/AVP 0 19

7

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.

Example 7-7  CallManager SDL Trace Analysis for SNR, Snippet 7 04828241.003 |15:37:56.436 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.18.110.62 on port 13030 index 21616 with 598 bytes: [606308,NET] BYE sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.62:5060;branch=z9hG4bK1A423B7 From: ;tag=B7CEC149-2237 To: ;tag=313456~bbab 2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545485 Call-ID: [email protected] CSeq: 101 BYE Reason: Q.850;cause=16

From the Library of Green Systems LLC

9780136575542_BOOK.indb 339

23/10/20 4:00 PM

340    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.”

Example 7-8  CallManager SDL Trace Analysis for SNR, Snippet 8 04828249.000 |15:37:56.441 |SdlSig |CcHoldInd |restart0 |LineControl(1,100,85,14) |CellProxyCdpc(1,100,40,19) |1,100,251,766.2^172.18.110.62^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=20545485 CI.branch=16777235 StreamId= 04828274.001 |15:37:56.444 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.106 on port 50322 index 20687 [606309,NET] INVITE sip:[email protected]:50322;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK46f9d5fcc36e5 From: ;tag=313453~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545484 To: "1001" ;tag=d0ec35ffebc4041c57238fa0-47656c2c Call-ID: [email protected] CSeq: 102 INVITE Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact: Content-Type: application/sdp o=CiscoSystemsCCM-SIP 313453 2 IN IP4 172.18.110.61 c=IN IP4 0.0.0.0 m=audio 8094 RTP/AVP 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.

Example 7-9  CallManager SDL Trace Analysis for SNR, Snippet 9 04828338.001 |15:37:56.573 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.108 on port 51621 index 20489 ­ [606313,NET] NOTIFY sip:[email protected]:51621;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK46f9fe785ed8 From: ;tag=1610814960

From the Library of Green Systems LLC

9780136575542_BOOK.indb 340

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    341 To: Call-ID: [email protected] CSeq: 101 NOTIFY Max-Forwards: 70 Date: Fri, 17 Jan 2020 20:37:56 GMT User-Agent: Cisco-CUCM12.5 Event: dialog Subscription-State: active Contact: Content-Type: application/dialog-info+xml Content-Length: 971

confirmed 1 From unlocked 25 1-6020

7

sip:[email protected]:5060



sip:[email protected]:5060



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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 341

23/10/20 4:00 PM

342    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 7-10  CallManager SDL Trace Analysis for SNR, Snippet 10 04828397.002 |15:37:58.414 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 14.50.214.108 on port 51621 index 20489 with 3125 bytes: [606316,NET] INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP 14.50.214.108:51621;branch=z9hG4bK23819e86 From: "pkinane desk phone" ;tag=c4b36aba1b5a027b16a55a5c3a3c09cd To: Call-ID: [email protected] CSeq: 101 INVITE Contact: ;+u. sip!devicename.ccm.cisco.com="SEPC4B36ABA1B5A";video Replaces: [email protected];to-tag=bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545485; from-tag=bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545485 Remote-Party-ID: "pkinane desk phone" ; party=calling;id-type=subscriber;privacy=off;screen=yes Content-Type: application/sdp o=Cisco-SIPUA 23364 0 IN IP4 14.50.214.108 m=audio 25846 RTP/AVP 114 9 124 113 115 0 8 116 18 101 c=IN IP4 14.50.214.108 a=sendrecv 04828562.001 |15:37:58.541 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.108 on port 51621 index 20489 [606325,NET] SIP/2.0 200 OK Via: SIP/2.0/TCP 14.50.214.108:51621;branch=z9hG4bK23819e86 From: "pkinane desk phone" ;tag=c4b36aba1b5a027b16a55a5c3a3c09cd To: ;tag=313464~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-20545485 Call-ID: [email protected] CSeq: 101 INVITE Remote-Party-ID: ;party=called;screen=yes;privacy=off Contact: ;+u.sip!devicename.ccm.cisco.com= "SEPD0EC35FFEBC4";video Content-Type: application/sdp o=CiscoSystemsCCM-SIP 313464 1 IN IP4 172.18.110.61 c=IN IP4 14.50.214.106 m=audio 16598 RTP/AVP 114 101

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 342

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    343 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 canceled. 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 00392292.006 |11:17:03.061 |AppInfo |DbMobility - RemDest dump: cnumber = 5555, ­ devicePkid = a379e10f-7d80-f405-3ecd-1a675206e1e4, remDestProfilePkidStr = 70690b51-30c9-58e8-4bab0c9140a9fc35, isMobilePhone = 1, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 1, answerTooSoonTimer = 1500, answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = SNR_USER, timeZoneIndex = 0, requireThirdPartyRegistration = 0, blockIncomingCallsWhenRoaming = 0, homeNetworkID = , description = TEST_RD, url = , ­ SNRVMAvoidancePolicy = 0, DvorVMAPolicy = 0 ­ ### 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 - startCFNATimer (12000) for line entry 1008 - callKey= 0x7 00392344.001 |11:17:03.064 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.122 on port 50761 index 407 INVITE sip:[email protected]:50761;transport=tcp SIP/2.0

7

### 4 seconds later, the Delay Before Ringing timer ends and Unified CM extends the call to SNR RD 00392374.000 |11:17:07.073 |SdlSig |DelayBeforeRingTimer |delayBeforeRing |CellProxyCdpc(1,100,40,8) |SdlTimerService(1,100,3,1) |1,100,251,10.1587^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:1,N:0,L:0,V:0,Z:0,D:0] 00392393.001 |11:17:07.076 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.65 on port 5060 index 413 INVITE sip:[email protected]:5060 SIP/2.0 ### Answer Too Soon Timer Ends 00392415.000 |11:17:08.577 |SdlSig |Answer2SoonTimer |active |CellProxyCdpc(1,100,40,8) |SdlTimerService(1,100,3,1) |1,100,251,10.1587^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] ### The Call Forward No Answer ends at 12 seconds and Unified CM sends a SIP CANCEL all devices 00392425.000 |11:17:15.066 |SdlSig |ForwardNoAnswerTimer |awaitingCallResponse |Forwarding(1,100,60,7) |SdlTimerService(1,100,3,1) |1,100,251,10.1587^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0]

From the Library of Green Systems LLC

9780136575542_BOOK.indb 343

23/10/20 4:00 PM

344    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 00392466.001 |11:17:15.067 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.122 on port 50761 index 407 CANCEL sip:[email protected]:50761;transport=tcp SIP/2.0 00392468.001 |11:17:15.067 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.65 on port 5060 index 413 CANCEL sip:[email protected]:5060 SIP/2.0 ------------------------------------------------------------------### Test Call 2, default SNR Timers but 36 second Call Forward No Answer Timer ### Default SNR Timers are set 00393260.006 |11:20:05.226 |AppInfo |DbMobility - RemDest dump: cnumber = 5555, devicePkid = a379e10f-7d80-f405-3ecd-1a675206e1e4, remDestProfilePkidStr = ­ 70690b51-30c9-58e8-4bab-0c9140a9fc35, isMobilePhone = 1, isDualMode = 0, i ­ ­sSmartPhone = 0, isSNREnabled = 1, answerTooSoonTimer = 1500, answerTooLateTimer = 1 9000, delayBeforeRingingCellTimer = 4000, userId = SNR _ USER, timeZoneIndex = 0, ­ requireThirdPartyRegistration = 0, blockIncomingCallsWhenRoaming = 0, homeNetworkID = , ­ description = TEST _ RD, url = , SNRVMAvoidancePolicy = 0, DvorVMAPolicy = 0 ### 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 - startCFNATimer (36000) for line entry 1008 - callKey= 0x8 00393311.001 |11:20:05.229 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.122 on port 50761 index 407 INVITE sip:[email protected]:50761;transport=tcp SIP/2.0 ### 4 seconds later, the Delay Before Ringing timer ends and Unified CM extends the call to SNR RD 00393343.000 |11:20:09.241 |SdlSig |DelayBeforeRingTimer |delayBeforeRing |CellProxyCdpc(1,100,40,9) |SdlTimerService(1,100,3,1) |1,100,251,10.1597^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] 00393365.001 |11:20:09.244 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.65 on port 5060 index 413 INVITE sip:[email protected]:5060 SIP/2.0 ### After 19 seconds the SNR Answer Too Late Timer expires 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 |AnswerTooLateTimer |active |CellProxyCdpc(1,100,40,9) |SdlTimerService(1,100,3,1) |1,100,251,10.1597^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] 00393427.001 |11:20:28.249 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.110.65 on port 5060 index 413 CANCEL sip:[email protected]:5060 SIP/2.0 ### The Call Forward No Answer ends at 36 seconds and Unified CM sends a SIP CANCEL to the IP Phone 00393468.000 |11:20:41.242 |SdlSig |ForwardNoAnswerTimer |awaitingCallResponse |Forwarding(1,100,60,8) |SdlTimerService(1,100,3,1) |1,100,251,10.1597^14.50.214.100^SEPF8A5C59E0F52 |[R:H-H:1,N:0,L:0,V:0,Z:0,D:0] 00393505.001 |11:20:41.243 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.122 on port 50761 index 407 CANCEL sip:[email protected]:50761;transport=tcp SIP/2.0

From the Library of Green Systems LLC

9780136575542_BOOK.indb 344

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    345

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

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 345

23/10/20 4:00 PM

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

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 346

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    347

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.

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 347

23/10/20 4:00 PM

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

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. IP Phone A -1001

IP Phone B -1000

SJ Unified CM

Remote Destination +14085557890

SJ CUBE

RTP REFER sip:sj-cucm:5060

2

REFER sip:sj-cucm:5060

4

1

REFER sip:1000@deskphone:5060

3

INVITE sip:+14085557890@cube

INVITE sip:+14085557890@remdest:5060 200 OK 200 OK

INVITE (a=inactive) 200 OK (a=inactive)

6 6

5

INVITE (a=inactive) 200 OK (a=inactive)

7

BYE 200 OK (BYE)

UPDATE sip:callingphone:5060

8

200 OK (UPDATE) INVITE (a=sendrecv) 200 OK (a=sendrecv)

9

RTP

RTP

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 348

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    349 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).

Example 7-12  CallManager SDL Trace Analysis for Move to Mobile, Snippet 1 00225644.002 |09:40:09.384 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 14.50.214.108 on port 50463 index 1135 with 1799 bytes: [21878,NET] REFER sip:172.18.110.61 SIP/2.0 Via: SIP/2.0/TCP 14.50.214.108:50463;branch=z9hG4bK7099f5b2 From: ;tag=c4b36aba1b5a001f1cefd8b2-414b495b To: Call-ID: [email protected] CSeq: 101 REFER Referred-By: Refer-To: cid:[email protected] Content-Type: application/x-cisco-remotecc-request+xml

Mobility

Step 2.

7

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.

Example 7-13  CallManager SDL Trace Analysis for Move to Mobile, Snippet 2 00225673.002 |09:40:09.426 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.108 on port 50463 index 1135 ­ [21880,NET] REFER sip:[email protected]:50463;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27ad1797b8a2 From: ;tag=587273788 To: Call-ID: [email protected] CSeq: 101 REFER Refer-To: cid:[email protected] Content-Id:

From the Library of Green Systems LLC

9780136575542_BOOK.indb 349

23/10/20 4:00 PM

350    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Referred-By: Content-Type: multipart/mixed; boundary=uniqueBoundary --uniqueBoundary Content-Type: application/x-cisco-remotecc-cm+xml MobileConnect On Make Your SelectionSend call to Mobile PhoneUserCallDataSoftKey:Exit:0:0:29154853:16777240:101 Exit1UserCallDataSoftKey:Exit:0:0:2 9154853:16777240:UpdateSelect3 SoftKey:Select --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.

Example 7-14  CallManager SDL Trace Analysis for Move to Mobile, Snippet 3 00225695.004 |09:40:11.434 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 14.50.214.108 on port 50463 index 1135 with 1698 bytes: [21887,NET] REFER sip:sj-cucm.ccnpcollab.lab SIP/2.0 Via: SIP/2.0/TCP 14.50.214.108:50463;branch=z9hG4bK37566d80 From: "pkinane desk phone" ;tag=c4b36aba1b5a0022169179d6-2f3fe6ea To: Call-ID: [email protected] CSeq: 1000 REFER Accept: application/x-cisco-remotecc-response+xml Referred-By: "pkinane desk phone" Refer-To: cid:[email protected] Content-Id: Content-Type: multipart/mixed; boundary=uniqueBoundary --uniqueBoundary Content-Type: application/x-cisco-remotecc-request+xml Content-Disposition: session;handling=required

0 16777240

From the Library of Green Systems LLC

9780136575542_BOOK.indb 350

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    351 StationSequenceLast 0 0 0 29154853

--uniqueBoundary Content-Type: application/x-cisco-remotecc-cm+xml Content-Disposition: session;handling=required 101 --uniqueBoundary— ##### 09:40:11.434 || Unified CM to Perform CellPickup(Send a call to Mobile Phone) 00225706.002 |09:40:11.434 |AppInfo |MKI::( 3)waitUserSelection_SsDeviceToUserData-option = 101 Perform CellPickup(Send a call to Mobile Phone)

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.

Example 7-15  CallManager SDL Trace Analysis for Move to Mobile, Snippet 4 00225706.003 |09:40:11.435 |AppInfo |DbMobilityHelper::endUserAndDnMatchFunc - Matched RD: DN [1000], Partition [8ebc1102-c0e2-5cb9-8950-2cd90f6f74b6], End User [pkinane], Destination [84085557890]

7

00225706.004 |09:40:11.435 |AppInfo |DbMobilityHelper::endUserAndDnMatchFunc - Found [1] records for End User [pkinane] and DN [1000] 00225751.010 |09:40:11.446 |AppInfo |Digit analysis: match(pi="2", fqcn="+14085251001", cn="1001",plv="5", pss="partition_for_call_to_mobile_and_home", TodFilteredPss="partition_for_call_to_mobile_and_home", dd="84085557890",dac="1") 00225751.011 |09:40:11.446 |AppInfo |Digit analysis: analysis results 00225751.012 |09:40:11.446 |AppInfo ||PretransformCallingPartyNumber=+14085251001 |CallingPartyNumber=+14085251001 |DialingPartition= |DialingPattern=+! |FullyQualifiedCalledPartyNumber=+14085557890 |DialingPatternRegularExpression=(+[0-9]+) |RouteBlockFlag=RouteThisPattern 00225805.001 |09:40:11.470 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP ­ message to 172.18.110.62 on port 5060 index 1150

From the Library of Green Systems LLC

9780136575542_BOOK.indb 351

23/10/20 4:00 PM

352    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide [21889,NET] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27ae2ea187d2 From: ;tag=11449~bbab 2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154855 To: Call-ID: [email protected] CSeq: 101 INVITE P-Asserted-Identity: Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact: ;isFocus

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

Example 7-16  CallManager SDL Trace Analysis for Move to Mobile, Snippet 5 00225859.002 |09:40:18.141 |AppInfo |SIPTcp - wait _ SdlReadRsp: Incoming SIP TCP message from 172.18.110.62 on port 5060 index 1150 with 1586 bytes: ­ [21894,NET] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27ae2ea187d2 From: ;tag=11449~bbab 2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154855 To: ;tag=EF2D80B2-1668 Call-ID: [email protected] CSeq: 101 INVITE Remote-Party-ID: ;party=called;screen=yes;privacy=off Contact: Content-Type: application/sdp o=CiscoSystemsSIP-GW-UserAgent 7044 8923 IN IP4 172.18.110.62 c=IN IP4 172.18.110.62 m=audio 8182 RTP/AVP 0 19 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).

Example 7-17  CallManager SDL Trace Analysis for Move to Mobile, Snippet 6 00226153.001 |09:40:18.492 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.106 on port 51439 index 12 ­ [21902,NET] INVITE sip:[email protected]:51439;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27b46f52d794

From the Library of Green Systems LLC

9780136575542_BOOK.indb 352

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    353

From: ;tag=11430~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154852 To: "1001" ;tag=d0ec35ffebc4026f7681d8b6-23ebe644 Call-ID: [email protected] CSeq: 101 INVITE Remote-Party-ID: "pkinane desk phone" ;party=calling;screen= yes;privacy=off Contact: ;+u. sip!devicename.ccm.cisco.com="SEPC4B36ABA1B5A" Content-Type: application/sdp o=CiscoSystemsCCM-SIP 11430 2 IN IP4 172.18.110.61 c=IN IP4 0.0.0.0 m=audio 24042 RTP/AVP 114 101 a=inactive a=trafficclass:conversational.audio.avconf.aq:admitted 00226154.001 |09:40:18.492 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP ­essage to 14.50.214.108 on port 50463 index 1135 m [21903,NET] INVITE sip:[email protected]:50463;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27b5232dc5f6 From: ;tag=11431~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154853 To: ;tag=c4b36aba1b5a001e79ec2975-2d4af571 Call-ID: [email protected]

7

CSeq: 102 INVITE Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact: ;+u. sip!devicename.ccm.cisco.com="SEPD0EC35FFEBC4" Content-Type: application/sdp o=CiscoSystemsCCM-SIP 11431 2 IN IP4 172.18.110.61 c=IN IP4 0.0.0.0 m=audio 23500 RTP/AVP 114 101 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).

Example 7-18  CallManager SDL Trace Analysis for Move to Mobile, Snippet 7 00226250.001 |09:40:18.638 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.108 on port 50463 index 1135 ­ [21910,NET] BYE sip:[email protected]:50463;transport=tcp SIP/2.0

From the Library of Green Systems LLC

9780136575542_BOOK.indb 353

23/10/20 4:00 PM

354    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27b880c371b From: ;tag=11431~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154853 To: ;tag=c4b36aba1b5a001e79ec2975-2d4af571 Call-ID: [email protected]

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

Example 7-19  CallManager SDL Trace Analysis for Move to Mobile, Snippet 8 00226288.001 |09:40:18.655 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP ­essage to 14.50.214.106 on port 51439 index 12 m [21912,NET] UPDATE sip:[email protected]:51439;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27ba297ae69f From: ;tag=11430~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154852 To: "1001" ;tag=d0ec35ffebc4026f7681d8b6-23ebe644 Call-ID: [email protected] CSeq: 102 UPDATE Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact:

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.

Example 7-20  CallManager SDL Trace Analysis for Move to Mobile, Snippet 9 ##### 09:40:18.659 || Unified CM sends 1001 an invite 00226336.001 |09:40:18.659 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 14.50.214.106 on port 51439 index 12 ­ [21917,NET] INVITE sip:[email protected]:51439;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.18.110.61:5060;branch=z9hG4bK27bd7e10f279 From: ;tag=11430~bbab2af3-f2b4-4a8c-a020-a2cc3e6cebe7-29154852 To: "1001" ;tag=d0ec35ffebc4026f7681d8b6-23ebe644 Call-ID: [email protected] CSeq: 103 INVITE Remote-Party-ID: ;party=calling;screen=yes;privacy=off Contact: ;video;audio

From the Library of Green Systems LLC

9780136575542_BOOK.indb 354

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    355

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

7

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 and 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 that 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 355

23/10/20 4:00 PM

356    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide The service URL for Extension Mobility is http://:8080/emapp/EMAppServlet?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 and Apply Config. Next, select Subscribe/Unsubscribe Services from the Related Links dropdown and click Go.

Figure 7-32  Related Links From the Library of Green Systems LLC

9780136575542_BOOK.indb 356

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    357 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.

7

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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 357

23/10/20 4:00 PM

358    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 358

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    359 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 shown in Figure 7-38.

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

7

Figure 7-39  Gear Icon Button Step 2.

When the Applications screen opens, select the phone service, as shown in ­Figure 7-40.

Step 3.

Enter the credentials for the user, as shown in Figure 7-41, and press the Submit button. 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 359

23/10/20 4:00 PM

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

Figure 7-40  Applications Screen Phone UI

Figure 7-41  User Login Credentials

Figure 7-42  Phone Screen Successful Login

From the Library of Green Systems LLC

M07_Davis_C07_p316-p385.indd 360

23/10/20 8:23 PM

Chapter 7: Unified CM Mobility    361 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.

7 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

From the Library of Green Systems LLC

M07_Davis_C07_p316-p385.indd 361

23/10/20 8:23 PM

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

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=SEPC4B36ABA1B5 A&userid=test_em&seq=134679 You can use this URL to log out: http://sj-cucm.ccnpcollab.lab/emapp/EMAppServlet?device=SEPC4B36ABA1B5 A&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 Administration > System > Service Parameters > Server > Cisco Extension Mobility and clicking Advanced. The page should look as shown in Figure 7-46.

Figure 7-46  Extension Mobility Service Parameters

From the Library of Green Systems LLC

9780136575542_BOOK.indb 362

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    363 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 Extension Mobility service.

■

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

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 363

23/10/20 4:00 PM

364    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

EM EM http://sj-cucm.ccnpcollab.lab:8080/emapp/EMAppServlet?device=#DEVICENAME#

Figure 7-47  Services Provisioning Enterprise Parameter Cisco Unified CM Cisco IP Phone Services Service

1: HTTP GET 2: HTTP 200 OK 3: HTTP GET 4: HTTP 200 OK

Cisco EMApp Service

5: HTTP GET

5: Pin + Submit

8: HTTP 200 OK 8

6

Cisco Extension Mobility Service

7 Cisco Unified CM Database

Cisco TFTP Service Cisco CallManager Service

9: TFTP GET 9: File: cnf.xml.sgn 10: SIP REGISTER 10: SIP 200 OK

Figure 7-48  EM Login Flow

From the Library of Green Systems LLC

9780136575542_BOOK.indb 364

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    365

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] EMAppServlet - EMApp Request# ----->10 2020-01-29 14:57:11,355 INFO [http-bio-8080-exec-9] EMAppServlet - EMAppServlet: Request protocol is :http 2020-01-29 14:57:11,360 INFO [http-bio-8080-exec-9] EMAppServlet - EMApp Request parameters: Logout=null Device Name=SEPD0EC35FFEBC4 User Id=null Device Profile=null ­ Refresh=null Remote Host IP Address = 14.50.214.106 Via Header Set = false getClusterInfo = null Lang = en_US Charset=utf-8,;q=0.8 Emcc = null LoginType = null

7

##### 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] EMServiceCommunicator - Posting to EM Service:

CCMSysUser xxxxxxx

SEPD0EC35FFEBC4 14.50.214.106

2020-01-29 14:57:11,407 INFO [http-bio-8080-exec-9] EMServiceCommunicator - Posting to EM Query Service:https://localhost:8443/emservice/EMServiceServlet ##### EM Trace - The EM service receives the request from EMApp 2020-01-29 14:57:11,536 INFO [http-bio-8443-exec-1] EMServiceServlet - EMService Request# ----> : 6

From the Library of Green Systems LLC

9780136575542_BOOK.indb 365

23/10/20 4:00 PM

366    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide ##### EM Trace - We see the request is to determine the device to user association "deviceUserQuery" 2020-01-29 14:57:11,540 DEBUG [http-bio-8443-exec-1] EMServiceServlet - 6:Query->

CCMSysUser *****

SEPD0EC35FFEBC4 14.50.214.106

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.

Example 7-23  CallManager SDL Trace, EMApp Trace, Extension Mobility Trace, and Cisco TFTP Trace Analysis, Part 3 ##### EMApp Trace - The login page is sent to the phone 2020-01-29 14:57:11,712 INFO [http-bio-8080-exec-9] EMAppServlet - Sent login page for device SEPD0EC35FFEBC4

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.

Example 7-24  CallManager SDL Trace, EMApp Trace, Extension Mobility Trace, and Cisco TFTP Trace Analysis, Part 4 ##### EMApp Trace - EMApp gets another request from the phone. This time the phone is sending the user credentials 2020-01-29 14:57:33,236 INFO [http-bio-8080-exec-11] EMAppServlet - EMApp Request# ----->11 2020-01-29 14:57:33,236 INFO [http-bio-8080-exec-11] EMAppServlet - EMAppServlet: Request protocol is :http 2020-01-29 14:57:33,237 INFO [http-bio-8080-exec-11] EMAppServlet - EMApp Request parameters: Logout=null Device Name=SEPD0EC35FFEBC4 User Id=test_em Device Profile=null Refresh=null Remote Host IP Address = 14.50.214.106 Via Header Set = false getClusterInfo = null Lang = en_US Charset=utf-8,;q=0.8 Emcc = null LoginType = null

From the Library of Green Systems LLC

9780136575542_BOOK.indb 366

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    367 Step 6.

As shown in Example 7-25, the EMApp service proxies the information to the Extension Mobility service.

Example 7-25  CallManager SDL Trace, EMApp Trace, Extension Mobility Trace, and Cisco TFTP Trace Analysis, Part 5 ##### EMApp Trace - The EMApp service sends the information to the EM Service ##### EMApp Trace - This is going to the login service specifically 2020-01-29 14:57:33,342 DEBUG [http-bio-8080-exec-11] EMServiceCommunicator - Posting to EM Service:

CCMSysUser xxxxxxx

SEPD0EC35FFEBC4 test_em test_em_dev_pro 14.50.214.106 false

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

7

##### EM Trace – The login to the device is successful 2020-01-29 14:57:33,877 INFO [http-bio-8443-exec-18] EMServiceServlet - 7:Request succeeded returning ­



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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 367

23/10/20 4:00 PM

368    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 7-27  CallManager SDL Trace, EMApp Trace, Extension Mobility Trace, and Cisco TFTP Trace Analysis, Part 7 ##### At this point the phone is coming back online and needs to contact TFTP for its configuration file ##### TFTP Trace - TFTP Trace - The device requests the config file from TFTP after login 00022631.003 |14:57:40.200 |AppInfo | HTTPConnection::wait_SdlDataInd Printing the HTTPRequest : msgBuffer size [70] --: GET /SEPD0EC35FFEBC4.cnf.xml.sgn HTTP/1.1 Host:172.18.110.61:6970 ##### TFTP Trace - TFTP builds the config file with the understanding the EM user is logged with profile test_em_dev_pro 00022634.059 |14:57:40.283 |AppInfo |CXMLSIPLines::BuildFromRecord(), Device[SEPD0EC35FFEBC4] Id[9d728269-56fe-43ae-bd99-02b77a14d572], EM Loged in using DeviceProfile[test_em_dev_pro], Id[4dc5e067-e181-6b9f-4ce6-a7c988a9c28f]

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 which DN to use ##### CallManager SDL Trace - CCM receives REGISTER message from the phone, now using extension 3333 00558862.004 |14:57:44.589 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP m ­essage from 14.50.214.106 on port 49907 index 2895 with 2589 bytes: [54911,NET] REGISTER sip:sj-cucm.ccnpcollab.lab SIP/2.0 From: ;tag=d0ec35ffebc4002313443e01-78d68621 To: Call-ID: [email protected] CSeq: 121 REGISTER Reason: SIP;cause=200;text="cisco-alarm:23 Name=SEPD0EC35FFEBC4 ActiveLoa d=sip8845_65.12-7-1-0001-393.loads InactiveLoad=sip8845_65.12-1-1SR1-4.loads Last=reset-restart"

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 368

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    369 Table 7-2  EM Service Error Codes Error Code

Phone Display Quick Description

5

Login is unavailable(5) Logout is unavailable(5)

6

Login is unavailable(6)

Description/Scenario

Device logon A user logs in to a device that has Enable Extension disabled Mobility unchecked in the Phone Configuration window. Database error

Logout is unavailable(6)

Whenever the database returns an exception while executing a query or stored procedure that the Extension Mobility service requests (login/logout or device/user query), the Extension Mobility service sends that error code to EMApp.

22

Login is unavailable(22)

Device logon Occurs when Extension Mobility is not enabled disabled on the device, and the request is sent via Extension Mobility API or when the Services button on the phone is pressed.

25

MultiLogin Not Allowed(25)

User logged in elsewhere

The user is currently logged in to some other phone, in either the local cluster or a remote cluster.

28

Login is unavailable(28)

Untrusted IP error

Occurs when the Validate IP Address service parameter is set to True and the user tries to log in to or log out from a machine whose IP address is not trusted (for example, if a third-party application or Extension Mobility API from a machine is not listed in the Trusted List of IPs service parameter).

Logout is unavailable(28) 41

PIN change is required

PIN change is Occurs when User Must Change at Next Login for required PIN is enabled. In that case, the user is redirected to the Change Credentials page.

7

Note: This is an internal error code. 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_comm/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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 369

23/10/20 4:00 PM

370    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 7-3  Phone Display Messages from EMApp Error Phone Display Code 201

Quick Description

Please try to login Authentication again(201) error

Reason If the user is an Extension Mobility Cross Cluster user, this error can occur if “EMCC” is not activated on the Intercluster Service Profile window. Another cause can be a typo in the user ID or PIN.

202

Please try to login Blank user ID or again(202) PIN

The user enters a blank user ID or PIN.

204

Login is unavailable(204)

Directory server error

EMApp sends this error to the phone when IMS cannot authenticate the user with the given PIN.

205

Login is unavailable(205)

User profile absent

Occurs when the user profile information cannot be retrieved from the cache or the database.

Device name empty

Occurs when the device or name tag is missing in the request URI. This cannot happen with real devices and can occur only if the request is sent from a third-party application.

Extension Mobility service connection error

The visiting EMApp cannot connect to any visiting Extension Mobility service. (The service is down or not activated.)

Logout is unavailable(205) 207

Login is unavailable(207) Logout is unavailable(207)

208

Login is unavailable(208) Logout is unavailable(208)

210

Login is unavailable(210)

Initialization failure; contact administrator

An error (such as a database connection failure) occurred while initializing EMApp. Such an error can occur because of a failure to connect to the database during startup.

Logout is unavailable(211)

Extension Mobility Cross Cluster not activated

Occurs when the PSTN is not activated in the Intercluster Service Profile window of the visiting cluster.

Login is unavailable(212)

Cluster ID is invalid

Occurs when a remote cluster update fails and an incorrect cluster ID is sent to the remote cluster.

Logout is unavailable(210) 211

212

The visiting Extension Mobility service cannot connect to the home Extension Mobility service. (The WAN is down or certificates are not trusted.)

Login is unavailable(211)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 370

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    371 Error Phone Display Code

Quick Description

Reason

213

Device does not support Extension Mobility Cross Cluster

Occurs when a device does not support Extension Mobility Cross Cluster.

Login type is invalid

Occurs when the login type is invalid. The allowed values are

Login is unavailable(213) Logout is unavailable(213)

215

LoginType invalid(215)

216

DN has multiple users(216)

Directory number has multiple users

■

SP: For Self-Service User ID

■

DN: For Primary Extension

■

UID: For User ID

Occurs when the extension used for Extension Mobility login is assigned for multiple users as primary.

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

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 371

23/10/20 4:00 PM

372    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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. San Jose (SJ) Subnet: 14.50.214.0 /24 Device Mobility Info: SJ_NETWORK_DMI Device Pool: SJ_DP Physical Location: SJ_PL Device Mobility Group: US_DMG

New York (NY)

6315555555

Richardson (RCH) Subnet: 10.10.10.0 /24 Device Mobility Info: RCH_NETWORK_DMI Device Pool: RCH_DP Physical Location: RCH_PL Device Mobility Group: US_DMG Mexico City (CDMX) Subnet: 14.48.38.0 /24 Device Mobility Info: CDMX_NETWORK_DMI Device Pool: CDMX_DP Physical Location: CDMX_PL Device Mobility Group: MEX_DMG

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 highlevel areas. Typically, Device Mobility groups are made per country.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 372

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    373 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.

An endpoint from Richardson, Texas, moves to San Jose, California.

Unified CM selects SJ_DMI due to the IP address used by the phone.

Unified CM selects SJ_DP as the roaming device pool because SJ_DMI is configured to use SJ_DP.

Unified CM compares the roaming device pool (SJ_DP) to the endpoint’s static device pool (RCH_DP). The specific settings compared are the physical location and the DMG.

7 SJ_DP and RCH_DP are configured with different physical locations; therefore, the RSS are applied to the phone in this scenario. SJ_DP and RCH_DP are configured with the same DMG; therefore, the DMRI are applied to the phone in this scenario.

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,

From the Library of Green Systems LLC

9780136575542_BOOK.indb 373

23/10/20 4:00 PM

374    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 374

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    375

Figure 7-53  Physical Location Configuration Page

7

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 375

23/10/20 4:00 PM

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

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 Roaming Sensitive Setting

Device Mobility–Related Information

Primarily impacts settings related to local resources and call admission control by ensuring the use of media resources that are local to the roaming device as well as ensuring the proper use of region/location settings.

Primarily impacts settings related to call routing by modifying the device CSS in order to route calls out the local gateway for the roaming device.

Solves the problem of traffic being sent from one site to another while there are local resources available.

When a device moves between Device Mobility groups, the device CSS is not changed to solve the problem of users needing to change their dialing habits.

Applied when a device moves between physical locations and the new physical location is associated with a device pool that is different from the endpoint’s statically assigned device pool.

Applied when a device moves between physical locations; however, the Device Mobility group associated with the roaming device pool is the same as the Device Mobility Group associated with the device’s static device pool.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 376

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    377 Roaming Sensitive Setting

Device Mobility–Related Information

Ensures the use of local media resources, local date and time, local paths to the telephone company, local SRST references, and so on. This essentially prevents traffic from needlessly traversing the network and heightens SRST availability by using a local SRST reference.

Ensures that users who move between countries can maintain their dialing habits (for example, use the same PSTN access codes and dialing formats they typically use) while also making sure users who move within a country send calls out a local gateway when roaming. The trade-off for maintaining dialing habits of a user who roams between Device Mobility groups is that the external call will use a gateway or trunk that exists at the user’s home site.

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.

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 377

23/10/20 4:00 PM

378    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 they change 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. Normally 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 378

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    379 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 oneto-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. Device Mobility Information

Device Pool

DMI “A” Subnet “A”

Device Pool “A”

DMI “B” Subnet “B”

Device Pool “B”

DMI “C” Subnet “C”

Device Pool “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. Is the physical location on the roaming device pool the same as the physical location on the static device pool? No Identify the roaming device pool that is configured for the DMI associated with the phone’s current subnet.

Is the roaming device pool the same as the static device pool?

Yes

7

No Use the roaming sensitive settings from the roaming device pool; then check if the DMG on the roaming device pool is the same as the DMG on the static device pool.

Yes Yes Yes Is Device Mobility enabled for this device? No

Is the device’s IP address from a subnet associated with a DMI? No Stop the process. Use the static device pool.

Is the DMG on the roaming device pool the same as the DMG on the static device pool? No Ignore the DMRI settings.

Yes Use the DMRI settings from the roaming device pool.

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 379

23/10/20 4:00 PM

380    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 380

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    381

Figure 7-63  Current Device Mobility Settings for a Roaming Device

7

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 381

23/10/20 4:00 PM

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

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-29 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-29  CallManager SDL Trace ##### Step 1 01998705.049 |22:45:30.974 |AppInfo |SIPStationD(28) - setIPAddr: Registering phone IP: 14.50.214.111 01998726.002 |22:45:30.987 |AppInfo |mMobileDevice = 1 ##### Step 2 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 382

23/10/20 4:00 PM

Chapter 7: Unified CM Mobility    383 ##### Step 3 01998737.001 |22:45:30.999 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 14.50.214.111:[5060]: [196878,NET] REFER sip:[email protected]:5060;transport=udp SIP/2.0 From: ;tag=2090933714 To: Call-ID: [email protected] CSeq: 101 REFER Content-Type: application/x-cisco-remotecc-request+xml Referred-By:

notify_display Device In Roaming Location 10 1

##### Step 4 01998750.001 |22:45:31.013 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 574 from 14.50.214.111:[5060]: ­ [196879,NET]

7

SIP/2.0 200 OK From: ;tag=2090933714 To: ;tag=D0EC35FFB4C40010685a1a39-5bc62693 Call-ID: [email protected] 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-30, which indicates the phone is localizing the string and provides and ENUM value 24. Example 7-30  Phone Console Logs from the Problem Reporting Tool (PRT) 5268 DEB Feb 03 21:45:29.253878 (3982-4172) JAVA-SIPCC-SIP_CC_PROV: ccsnap_EscapeStrToLocaleStr: Localized string: [Device In Roaming Location]. (status_index=[0]. stringId enum=[24])

NOTE  The test phone’s Phone Log Profile parameters were set to Default, Preset, Telephony, SIP, and UI.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 383

23/10/20 4:00 PM

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

References Cisco, “Feature Configuration Guide for Cisco Unified Communications Manager, Release 12.5(1)SU1,” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/ admin/12_5_1SU1/cucm_b_feature-configuration-guide-for-cisco1251SU1/cucm_b_ feature-configuration-guide-for-cisco1251SU1_chapter_010.html Cisco, “Cisco Collaboration System 12.x Solution Reference Network Designs (SRND),” https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/ mobilapp.html

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: 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 7-5 lists these key topics and the page number on which each is found. Table 7-5  Key Topics for Chapter 7 Key Topic Element

Description

Page

Figure 7-1

Single Number Reach Overview

321

Figure 7-14

Remote Destination Timer Information

329

Figure 7-18

Inbound Call from a Remote Destination

332

Figure 7-21

Intelligent Session Control Call Flow

334

Figure 7-30

Move to Mobile Sample Call Flow

348

Figure 7-48

Extension Mobility Login Flow

364

Figure 7-60

Device Mobility Logic Diagram

379

Complete Tables and Lists from Memory There are no memory tables or lists for the chapter.

Define Key Terms Define the following key terms from this chapter and check your answers in the glossary: 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 384

23/10/20 4:00 PM

This page intentionally left blank

From the Library of Green Systems LLC

CHAPTER 8

CUBE Call Routing and Digit Manipulation This chapter covers the following topics: 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.

This chapter covers the following CLACCM 300-815 exam topics: ■■

■■

3.1 Configure these Cisco Unified Border Element 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 Troubleshoot these Cisco Unified Border Element dial plan elements ■■

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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 386

23/10/20 4:00 PM

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

“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 8-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 8-1  “Do I Know This Already?” Foundation Topics Section-to-Question Mapping Foundation Topics Section

Questions

Understanding Call Legs and Call Flows

1, 2

IOS Dial Peers

3–9

Application Signaling and Media Binding

10

Digit, Header, and URI Manipulation

11, 12

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 From the Library of Green Systems LLC

9780136575542_BOOK.indb 387

23/10/20 4:00 PM

388    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 388

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    389 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

8

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 Layers 1, 2, and 3, but these layers are usually omitted from a call flow diagram.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 389

23/10/20 4:00 PM

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

Enterprise LAN

Service Provider

SIP Call Leg 1

SIP Call Leg 2

SIP Call Leg 3

SIP/TCP/RTP

SIP/UDP/RTP

SIP/TLS/SRTP

ITSP

Call Direction

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.

Call Direction UAC

UAS

UAS | UAC SIP Inbound Call Leg

SIP Outbound Call Leg

SIP INVITE SIP INVITE 200 OK 200 OK ACK ACK Call Is Connected

Figure 8-2  B2BUA Operation with Inbound and Outbound Call Legs From the Library of Green Systems LLC

9780136575542_BOOK.indb 390

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    391 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 useragent (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.

8

From the Library of Green Systems LLC

9780136575542_BOOK.indb 391

23/10/20 4:00 PM

392    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 allows 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 392

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    393 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 acknowledgment 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.

8

Table 8-2 shows 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 393

23/10/20 4:00 PM

394    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Preference

Match Criteria

Dial Peer Match Criteria Commands

1

Via URI (topmost)

incoming uri via uri-class-tag

2

Request URI

incoming uri request uri-class-tag

3

To URI

incoming uri to uri-class-tag

4

From URI

incoming uri from uri-class-tag

5

Called number

incoming called-number pattern incoming called e164-pattern-map pattern-map-class-id

6

Calling number

incoming calling e164-pattern-map pattern-map-class-id answer-address pattern

7

Calling number

destination-pattern pattern

8

Carrier ID

carrier-id source target

9

Default

dial-peer voice tag voip system dial-peer voice 0

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 394

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    395 Example 8-2  Sample Configuration for Inbound Dial Peer Matching Based on Called Number ! dial-peer voice 1000 voip incoming called-number 1... ! dial-peer voice 1001 voip 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 Regex Character

Description

Example(s)

. (period)

Matches any one of the digits and characters 0–9, A–F, and #.

9193926...

Indicates a list that is allowed to match a single digit or character.

919392600[079]

[ ] (brackets)

The character - inside the brackets indicates a range—that is, a sequence of characters enclosed in the brackets; only alphanumeric characters 0–9 and A–F are allowed in a range.

8

Matches 10-digit directory numbers beginning with a 9193926 prefix. Matches the 10-digit directory numbers 9193926000, 9193926007, and 9193926009. 919392600[0-9] Matches 10-digit directory numbers from 9193926000 to 9193926009.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 395

23/10/20 4:00 PM

396    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Regex Character

Description

Example(s)

+ (plus symbol)

Indicates that the preceding digit occurred one or more times. The plus symbol, when present as the first character in the value of the destinationpattern command, represents an E.164 number.

2600[0-9]+

? (question mark) Indicates that the preceding digit occurred zero or one time. Note: To enter the question mark in IOS CLI, you must press Ctrl+V and then enter ?. $ (dollar sign)

Defines the end of the input string.

Matches directory numbers such as 26000, 26001 to 26009, 260000, and so on. +19193926009 Matches the E.164 number +19193926009. 26000? Matches the directory numbers 2600 and 26000.

3926...$ Matches seven-digit numbers beginning with 3926000 to 3926999.

T (interdigit timeout)

A Cisco IOS router configured as a TDM gateway waits to collect additional digits until the expiration of the interdigit timeout. In the case of CUBE, all digits of the called party number are received in the SIP INVITE message at the same time, and hence T is used as to match any string of digits of length 0 or more.

9T

^ (circumflex)

When used inside brackets, it indicates that the digit following ^ will not be considered a match. When used as the first character in the regex pattern, it indicates that the matched string begins with the alphanumeric character that follows ^.

1[^8]00.......

Indicates a sequence of digit and character patterns that are grouped and matched together.

9193926(0[1-9])0

( ) (parentheses)

Matches directory numbers of all lengths and starting with the digit 9 (for example, 9, 911, and 9911).

Matches 11-digit numbers beginning with a 1, except for 1800 numbers. ^2...$ Matches 4-digit numbers that begin with 2. Matches the 11-digit numbers 9193926010, 9193926020, 9193926030, 9193926040, 9193926050, 9193926060, 9193926070, 9193926080, and 9193926090 but not 9193926000.

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 396

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    397 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).

Interface VRF Filter Via Header Match Request Match To Header Match From Header Match Called Party Match Calling Party Match Carrier ID

INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 172.18.172.218:5060;branch=z9hG4bK1805ed69aeb From: "1234 - My Phone" ;tag=1234 To: Call-ID: [email protected] CSeq: 101 INVITE Expires: 180 Contact: Max-Forwards: 69 Content-Type: application/sdp Content-Length: 267 v=0 o=CiscoSystemsCCM-SIP 675484 1 IN IP4 172.18.172.218 s=SIP Call c=IN IP4 172.18.172.218 b=TIAS:64000 b=AS:80 t=0 0 m=audio 24634 RTP/AVP 0 8 101 b=TIAS:64000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

Default

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.

8

From the Library of Green Systems LLC

9780136575542_BOOK.indb 397

23/10/20 4:00 PM

398    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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, information type = voice,

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:[email protected]:5060 SIP/2.0

■

INVITE sip:[email protected]: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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 398

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    399 Example 8-4  A Sample Configuration Showing Inbound Dial Peers rtp-cube# show run | section dial-peer ! dial-peer voice 2 voip session protocol sipv2 incoming called-number . ! dial-peer voice 22 voip session protocol sipv2 incoming called-number 91[2-9]..[2-9]...... ! rtp-cube# show dial-peer voice summary dial-peer hunt 0 AD TAG

TYPE

MIN

PRE PASS SESS-SER-GRP\ OPER PREFIX

DEST-PATTERN FER THRU SESS-TARGET

OUT STAT PORT KEEPALIVEVRF

2

voip

up

up

0

syst

NA

22

voip

up

up

0

syst

NA

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. Table 8-4  Voice Class URI Match Preference Order Used by CUBE Match Preference

URI Match Check

URI Example

1

Host

@172.18.110.42 @[2000::245:1DFF:FED2:991]

8

@rtp-cube.ccnpcollab.lab 2

User ID

sip:14085267209 sips:14085267209

3

Telephone number URI

tel:14085267209 tel:+14085267209

4

Full URI

sip:[email protected] sip:[email protected]

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 399

23/10/20 4:00 PM

400    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 ! voice class uri name sip user-id regexMatch ! voice class uri name sip phone regexMatch ! voice class uri name sip 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. The phone, pattern, and user-id commands only allow 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:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 172.18.110.65:5060;branch=z9hG4bKBB1BE5 From: ;tag= 4FD707ED-1319 To:

From the Library of Green Systems LLC

9780136575542_BOOK.indb 400

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    401 ! Voice Class URI Configuration voice class uri viaHeader sip host ipv4:172.18.110.65 ! dial-peer voice 2 voip session protocol sipv2 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 oneline 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

8

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.* !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 401

23/10/20 4:00 PM

402    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 dial-peer voice 2222 voip session protocol sipv2 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 402

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    403 Table 8-5  Outbound SIP Dial Peer Selection Preference Preference

Match Criteria

Dial Peer Match Criteria Commands

1

Dial peer group (DPG)* destination dpg dpg-tag

2

Dial peer provision policy*

destination uri uri-class-tag destination uri-from uri-class-tag destination uri-to uri-class-tag destination uri-via uri-class-tag destination uri-diversion uri-class-tag destination uri-referred-by uri-class-tag destination-pattern pattern destination e164-pattern-map pattern-map-class-id destination calling e164-pattern-map pattern-map-class-id carrier-id target

3

ILS route string

destination route-string route-string-tag

4

URI and carrier ID

destination uri uri-class-tag AND carrier-id target target

5

Called number and carrier ID

destination-pattern pattern AND carrier-id target target

6

URI

destination uri uri-class-tag

7

Called number

destination-pattern pattern destination e164-pattern-map pattern-map-class-id dnis-map dnis-map-tag

8

Calling number

destination calling e164-pattern-map pattern-map-class-id

* Configured on the inbound dial peer

8

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 more 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 403

23/10/20 4:00 PM

404    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 ? Dial-peer hunting choices, listed in hunting order within each choice: 0 - Longest match in phone number, explicit preference, random selection. 1 - Longest match in phone number, explicit preference, least recent use. 2 - Explicit preference, longest match in phone number, random selection. 3 - Explicit preference, longest match in phone number, least recent use. 4 - Least recent use, longest match in phone number, explicit preference. 5 - Least recent use, explicit preference, longest match in phone number. 6 - Random selection. 7 - Least recent use. rtp-cube# show dial-peer voice summary dial-peer hunt 0    PRE PASS SESS-SER-GRP\ OUT

AD

TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF 3

voip up

up

1408.......

0

syst ipv4:172.18.110.91

NA

33

voip up

up

9T

 0

syst ipv4:172.18.110.65

NA

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:[email protected]:5060 SIP/2.0

■

INVITE sip:[email protected]: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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 404

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    405 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 dial-peer voice 3 voip destination-pattern 1408.......$ session protocol sipv2 session target ipv4:172.18.110.91 session transport tcp ! dial-peer voice 33 voip preference 2 destination-pattern 9..........$ session protocol sipv2 session target ipv4:172.18.110.65 huntstop ! dial-peer voice 333 voip preference 1 destination-pattern 9..........$ session protocol sipv2

8

session target ipv4:172.18.110.66 !

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 405

23/10/20 4:00 PM

406    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 Command Syntax

Description

session protocol sipv2

Defines the VoIP dial peer protocol as SIP. Without this command defined, the dial peer assumes the default protocol, H.323.

session target target-address Defines the Layer 3 addressing information of the nexthop peer for this dial peer when establishing outbound connections. This command is covered in Table 8-7. session transport {udp | tcp | tcp tls)

Defines the egress Layer 4 transport type for the dial peer when creating a new outbound connection. This command does not affect inbound transport type. The default transport type is UDP.

preference number

Specifies the weight used as a tiebreaker when two or more dial peers could be selected. The lower the number, the more desirable the preference. number can be any number from 0 through 10, and the default is 0.

huntstop

Controls whether CUBE attempts to hunt to the dial peer with the next best preference or alternative matches upon receiving a failure in the initial call signaling. By default, this command is disabled, which means hunting always occurs on initial call setup failure.

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 406

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    407 Table 8-7  Inputs for the session target target-address Command target-address Options

Description

ipv4:a.b.c.d:port

Layer 3 IPv4 address and optional port. If no port is defined, the default ports for SIP UDP/TCP (5060) and TLS (5061) are assumed.

ipv6:[global-unicast]:port

Layer 3 IPv6 address wrapped in brackets ([]) as delimiters, with an optional port. If no port is defined, the default ports for SIP UDP/TCP (5060) and TLS (5061) are assumed.

dns:west.example.com

DNS entry that CUBE resolves using DNS SRV, A, and AAAA records to return a routable IPv4 or IPv6 address.

sip-server

A predefined string referencing the sip-server command configured in global sip-ua or the applicable assigned voice class tenant configuration. The sip-server command has an IPv4, IPv6, or DNS entry.

sip-uri

A predefined string that instructs IOS to use the RequestURI host from the ingress SIP message as the session target for this dial peer’s connection.

dhcp

A predefined string that instructs IOS that DHCP will provide the next-hop routing information via DHCP options 120 and 125.

saf

A predefined string that instructs IOS to use Service Automation Framework (SAF) information for the target or outbound connections.

registrar

A predefined string that instructs IOS to use the registrar information for a legacy CUBE line-side feature. (Note that this is not referencing the registrar that would be configured in global sip-ua or the applicable assigned voice class tenant configuration.)

loopback:rtp

A predefined string that instructs IOS to loop back RTP toward the source. Used for loopback testing.

enum:enum-table

Instructs IOS to perform a lookup on the defined enumeration table. Values are 1 through 15.

8

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 407

23/10/20 4:00 PM

408    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 8-8  DNS Wildcards Wildcard

Definition

Sample Usage

$s$

Source destination pattern is used as part of the domain name.

session target dns:$s$.cisco.com

$d$

Destination number is used as part of the domain name.

session target dns:$d$.cisco.com

$e$

Digits in the called number are reversed, and periods are added between the digits of the called number. The resulting string is used as part of the domain name.

session target dns:$e$.cisco.com

$u$

The unmatched portion of the destination session target pattern (such as a defined extension number) is dns:$u$.cisco.com used as part of the domain name.

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 [email protected]. 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 408

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    409 requri-passing ! voice class uri CUCM sip host dns:rtp-cucm.ccnpcollab.lab ! dial-peer voice 777 voip session protocol sipv2 destination uri CUCM session target sip-uri ! ### Debugging 005275: *Apr 9 18:11:42.529: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:[email protected]:5060 SIP/2.0 005560: *Apr 9 18:11:42.537: //-1/824242DB804A/DPM/dpMatchPeersCore: Match Rule=DP_MATCH_DEST_URI; URI=sip:[email protected]:5060 005562: *Apr 9 18:11:42.537: //21/824242DB804A/CCAPI/ccCallSetupRequest: [..truncated..] Guid=824242DB-79C9-11EA-804A-B636EC901AA2, Outgoing Dial-peer=777 005622: *Apr 9 18:11:42.538: //16/665021018033/SIP/Info/verbose/16384/sipSPI_ipip_ TargetTypeIsSipUri: Session Target is 'sip-uri' 005626: *Apr 9 18:11:42.539: //-1/xxxxxxxxxxxx/SIP/Info/verbose/5120/ sipSPIGetOutboundHostAndDestHost: CCSIP: DNS resolution required..session target is 'sip-uri' 005978: *Apr 9 18:11:42.547: //16/665021018033/SIP/Info/verbose/16384/sipSPI_ipip_ CopyUriFromIncToOutLeg: requri-passing: Req-URI is passed from Incoming to Outgoing Leg 005980: *Apr 9 18:11:42.547: //16/665021018033/SIP/Info/verbose/16384/sipSPI_ipip_ GetReqUriFromTDContainer: Incoming Req-URI = sip:[email protected]:5060

8

005984: *Apr 9 18:11:42.547: //16/665021018033/SIP/Info/verbose/16384/sipSPI_ipip_ CopyUriFromIncToOutLeg: Outgoing request-uri = sip:[email protected]:5060 005985: *Apr 9 18:11:42.547: //16/665021018033/SIP/Info/verbose/16384/sipSPI_ipip_ CopyUriFromIncToOutLeg: requri-passing: To Hdr is passed from Incoming to Outgoing 006042: *Apr 9 18:11:42.549: //16/665021018033/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:[email protected]:5060 SIP/2.0

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 409

23/10/20 4:00 PM

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

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 steering code 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$ !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 410

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    411 dial-peer voice 1 voip description Incoming from CUCM to CUBE incoming called e164-pattern-map 1 session protocol sipv2 ! dial-peer voice 11 voip description Outbound from CUBE to PSTN destination e164-pattern-map 1 session protocol sipv2 session target ipv4:172.18.110.65 ! ! INBOUND CALLS voice class e164-pattern-map 2 description E164 Pattern Map for DID Number Ranges e164 1408.......$ e164 1919574....$ e164 1919392....$ e164 +1T ! dial-peer voice 2 voip description Incoming from PSTN to CUBE incoming called e164-pattern-map 2 session protocol sipv2 ! dial-peer voice 22 voip description Outbound from CUBE to CUCM destination e164-pattern-map 2 session protocol sipv2 session target ipv4:172.18.110.48

8

!

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 leveraged 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 thirdparty 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.)

From the Library of Green Systems LLC

9780136575542_BOOK.indb 411

23/10/20 4:00 PM

412    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 8-12  A Sample Showing Kron and E.164 Pattern Map Usage ! voice class e164-pattern-map 11 url http://http-host/config-files/pattern-map.cfg ! dial-peer voice 11 incoming called e164-pattern-map 11 Session protocol sipv2 ! kron occurrence e164-pattern-load at 0:00 Sun recurring 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 ipv4 172.18.110.61 port 5060 preference 2 ipv6 2000::245:1DFF:FED2:991 port 5060 preference 3 ! voice class e164-pattern-map 2 description E164 Pattern Map for DID Number Ranges e164 1408.......$ e164 1919574....$ e164 1919392....$ e164 +1T !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 412

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    413 dial-peer voice 2 voip description Incoming from PSTN to CUBE incoming called e164-pattern-map 2 session protocol sipv2 ! dial-peer voice 22 voip description Outbound from CUBE to CUCM destination e164-pattern-map 2 session protocol sipv2 session server-group 22 !

DNS SRV Load Balancing As you might have noticed, there is not a DNS entry available in the voice class servergroup 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 Port Target 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.

8

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 413

23/10/20 4:00 PM

414    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 8-14  A Sample Configuration for DNS SRV Usage with Dial Peers ! _sip._udp. DNS SRV Query on port 5060 dial-peer voice 1 voip session protocol sipv2 session transport udp session target dns:ccnpcollab.lab ! ! _sip._tcp. DNS SRV Query on port 5060 dial-peer voice 1 voip session protocol sipv2 session transport tcp session target dns:ccnpcollab.lab ! ! _sip._tcp. DNS SRV Query on Port 5061 dial-peer voice 1 voip session protocol sipv2 session transport tcp tls session target dns:ccnpcollab.lab ! ! _sips._tcp. DNS SRV Query on port 5061 dial-peer voice 1 voip session protocol sipv2 session transport tcp tls session target dns:ccnpcollab.lab 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 414

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    415 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.ccnpcollab.lab ip host _sip._udp.ccnpcollab.lab srv 1 50 5060 2.ccnpcollab.lab ip host _sip._udp.ccnpcollab.lab srv 1 50 5060 3.ccnpcollab.lab ! ip host _sip._tcp.ccnpcollab.lab srv 1 50 5060 1.ccnpcollab.lab ip host _sip._tcp.ccnpcollab.lab srv 1 50 5060 2.ccnpcollab.lab ip host _sip._tcp.ccnpcollab.lab srv 1 50 5060 3.ccnpcollab.lab ! ip host _sip._tcp.ccnpcollab.lab srv 1 50 5061 1.ccnpcollab.lab ip host _sip._tcp.ccnpcollab.lab srv 1 50 5061 2.ccnpcollab.lab ip host _sip._tcp.ccnpcollab.lab srv 1 50 5061 3.ccnpcollab.lab ! ip host _sips._tcp.ccnpcollab.lab srv 1 50 5061 1.ccnpcollab.lab ip host _sips._tcp.ccnpcollab.lab srv 1 50 5061 2.ccnpcollab.lab ip host _sips._tcp.ccnpcollab.lab srv 1 50 5061 3.ccnpcollab.lab ! ip host 1.ccnpcollab.lab 10.10.10.1 ip host 2.ccnpcollab.lab 10.10.10.2 ip host 3.ccnpcollab.lab 10.10.10.3 !

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:

8

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 415

23/10/20 4:00 PM

416    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 8-16  A Reference Configuration That Leverages the Aggregation and ­Summarization Techniques Presented So Far ! OUTBOUND Calls from LAN to ITSP 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$ ! dial-peer voice 1 voip description Incoming from CUCM to CUBE incoming called e164-pattern-map 1 session protocol sipv2 ! dial-peer voice 11 voip description Outbound from CUBE to PSTN destination e164-pattern-map 1 session protocol sipv2 session target dns:myITSP.itspDomain.com ! ! INBOUND CALLS from ITSP to LAN voice class e164-pattern-map 2 description E164 Pattern Map for DID Number Ranges e164 1408.......$ e164 1919574....$ e164 1919392....$ e164 +1T ! voice class server-group 22 description CUCM Servers hunt-scheme round-robin ipv4 172.18.110.91 port 5060 preference 1 ipv4 172.18.110.61 port 5060 preference 2 ! dial-peer voice 2 voip description Incoming from PSTN to CUBE incoming called e164-pattern-map 2 session protocol sipv2 ! dial-peer voice 22 voip description Outbound from CUBE to CUCM destination e164-pattern-map 2 session protocol sipv2 session server-group 22 !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 416

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    417

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.

8

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 417

23/10/20 4:00 PM

418    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 8-17  A Sample Dial Peer Group Configuration ! voice class dpg 400 dial-peer 400 preference 1 ! dial-peer voice 4 voip session protocol sipv2 destination dpg 400 incoming called-number 14085267209 ! dial-peer voice 400 voip destination-pattern AAAAA session protocol sipv2 session target dns:sj-cucm.ccnpcollab.lab session transport tcp !

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 ! dial-peer voice 5 voip session protocol sipv2 destination dpg 500 incoming uri from 5 !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 418

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    419 dial-peer voice 500 voip session protocol sipv2 session target ipv4:172.18.110.91 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 First Match Criteria Attribute

Second Match Criteria Attribute

diversion

from, referred-by, to, uri, via

from

diversion, referred-by, to, uri, via

referred-by

diversion, from, to, uri, via

to

diversion, referred-by, from, uri, via

uri

diversion, referred-by, to, from, via, carrier-id

via

diversion, referred-by, to, uri, from

called

calling, carrier-id

calling

called

carrier-id

called, uri

8

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 419

23/10/20 4:00 PM

420    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Table 8-10  The Mapping of Dial Peer Match Criteria Commands to the Dial Peer Policy Syntax DPP Match Criteria Attribute

Dial Peer Match Criteria Command

called

destination-pattern pattern destination e164-pattern-map pattern-map-class-id

calling

destination calling e164-pattern-map pattern-map-class-id

carrier-id

carrier-id target

uri

destination uri uri-class-tag

via

destination uri-via uri-class-tag

to

destination uri-to uri-class-tag

from

destination uri-from uri-class-tag

diversion

destination uri-diversion uri-class-tag

referred-by

destination uri-referred-by uri-class-tag

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 urito 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:[email protected]:5060 SIP/2.0 From: ;tag=1 To: ### 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 called number preference 1 from to

From the Library of Green Systems LLC

9780136575542_BOOK.indb 420

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    421 preference 2 called ! dial-peer voice 1234 voip session protocol sipv2 destination provision-policy 1 incoming called-number . ! dial-peer voice 12345 voip destination uri-from FROM destination uri-to TO session protocol sipv2 session target ipv4:172.18.110.48 ! dial-peer voice 11111 voip destination-pattern 14085267209 session protocol sipv2 session target ipv4:172.18.110.48 !

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.

8

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 421

23/10/20 4:00 PM

422    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide ! voice class sip-hdr-passthrulist 1 passthru-hdr x-cisco-dest-route-string ! dial-peer voice 1 voip description INBOUND dial-peer session protocol sipv2 incoming uri request CISCO voice-class sip call-route url voice-class sip requri-passing voice-class sip pass-thru headers 1 ! dial-peer voice 2 voip description OUTBOUND dial-peer session protocol sipv2 session target ipv4:10.122.249.70 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 counterpart 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 numericonly user portion of the Request-URI header. Without this command configured, you would see a 484 Address Incomplete error along with cause code 28.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 422

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    423 ■

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 [email protected] 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 [email protected] 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 [email protected] rather than [email protected], along with the full x-cisco-dest-route-string, which has been successfully passed from the inbound call leg to the ­outbound call leg.

8

From the Library of Green Systems LLC

9780136575542_BOOK.indb 423

23/10/20 4:00 PM

424    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Example 8-21  ILS Route String Debugging Sample on CUBE Received: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP 10.122.249.59:5060;branch=z9hG4bK4416af0eda From: ;tag=438~393fe797-c548-472f-baf3-3bcafad7a475-18924723 To: Call-ID: [email protected] X-cisco-dest-route-string: Aug 2 00:35:12.198: //-1/054FE5800000/CCAPI/cc_api_call_setup_ind_common: [..truncated..] Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE Present=TRUE, Aug 2 00:35:12.200: //-1/054FE5800000/DPM/dpMatchPeersCore: Match Rule=DP_MATCH_DEST_ROUTE_STR; Destination Route-string=svs-alpha-c1.cisco.com Aug 2 00:35:12.201: //-1/054FE5800000/DPM/dpMatchPeersMoreArg: Result=SUCCESS(0) List of Matched Outgoing Dial-peer(s): 1: Dial-peer Tag=2 Aug 2 00:35:12.201: //49/054FE5800000/CCAPI/ccCallSetupRequest: [..truncated..] Guid=054FE580-0001-0000-0000-00293BF97A0A, Outgoing Dial-peer=2 *Aug 2 00:35:12.206: //50/054FE5800000/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.18.110.58:5060;branch=z9hG4bK883D From: ;tag=9A9706-1298 To: Call-ID: [email protected] X-cisco-dest-route-string:

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 424

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    425 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 voip|options-keepalive ! voice class sip-options-keepalive 33 down-interval 30 up-interval 60 retry 5 ! voice class server-group 33 ipv4 172.18.110.48 ipv4 172.18.110.65 !

8

dial-peer voice 33 voip destination-pattern 1234 session protocol sipv2 session server-group 33 voice-class sip options-keepalive profile 33 ! rtp-cube# show dial-peer voice summary dial-peer hunt 0 AD

PRE PASS SESS-SER-GRP OUT

TAG

TYPE

MIN

OPER DEST-PATTERN FER THRU SESS-TARGET

33

voip

up

up

1234

0

STAT

syst SESS-SVR-GRP:33

PORT KEEPALIVE active

rtp-cube# show voice class sip-options-keepalive 33 Voice class sip-options-keepalive: 33

AdminStat: Up

Description: Transport: system

Sip Profiles: 0

Interval(seconds) Up: 60

Down: 30

Retry: 5

From the Library of Green Systems LLC

9780136575542_BOOK.indb 425

23/10/20 4:00 PM

426    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Peer Tag -------33

Server Group ------------

----------

----------

OOD Stat

IfIndex

--------

-------

Active

9

33

Server Group: 33 OOD SessID

OOD SessID

OOD Stat: Active

OOD Stat --------

3

Busy

4

Active

OOD SessID: 3

OOD Stat: Busy

Target: ipv4:172.18.110.48 Transport: system OOD SessID: 4

Sip Profiles: 0 OOD Stat: Active

Target: ipv4:172.18.110.65 Transport: system

Sip Profiles: 0

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 426

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    427 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

8

service timestamps debug datetime msec localtime show-timezone year service timestamps log datetime msec localtime show-timezone year service sequence-numbers logging buffered 10000000 no logging console no logging monitor logging queue-limit 10000 logging rate-limit 10000 voice iec syslog

From the Library of Green Systems LLC

9780136575542_BOOK.indb 427

23/10/20 4:00 PM

428    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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 : ms. () + pid: 362B : 109 2251638910ms.1 (*20:01:46.396 EDT Tue Sep 17 2019) +2510 pid:1 Answer 7777 active 362B : 110 2251638930ms.1 (*20:01:46.416 EDT Tue Sep 17 2019) +2470 pid:11 Originate 1234 active

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 [email protected]. 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 dial-peer voice 1 voip session protocol sipv2 incoming called-number . codec g711ulaw !

From the Library of Green Systems LLC

9780136575542_BOOK.indb 428

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    429 dial-peer voice 2 voip preference 1 destination-pattern 1408526....$ session protocol sipv2 session target dns:sj-cucm.ccnpcollab.lab session transport tcp codec g711ulaw ! dial-peer voice 3 voip huntstop preference 2 destination-pattern 1408.......$ session protocol sipv2 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/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:[email protected]:5060 SIP/2.0 Call-ID: [email protected] ! Debugs, VRF Checking 010314: Oct 14 14:54:40.961 EDT: //-1/000000000000/SIP/Info/info/8192/resolve_sig_ip_ address_to_bind: VRF id = 0 010315: Oct 14 14:54:40.962 EDT: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/resolve_sig_ip_ address_to_bind: ip_best_local_address 172.18.110.62 for SIP

8

! Debugs, Inbound dial-peer searching 010370: Oct 14 14:54:40.968 EDT: //-1/E9A61FCE80DD/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match incoming dialpeer for Calling number: : 18005532447 010388: Oct 14 14:54:40.969 EDT: //-1/E9A61FCE80DD/DPM/dpAssociateIncomingPeerCore: Calling Number=18005532447, Called Number=14085267209, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH 010409: Oct 14 14:54:40.970 EDT: //-1/E9A61FCE80DD/DPM/dpAssociateIncomingPeerCore: Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=14085267209 010414: Oct 14 14:54:40.971 EDT: //-1/E9A61FCE80DD/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=1 010578: Oct 14 14:54:40.984 EDT: //-1/E9A61FCE80DD/CCAPI/cc_api_call_setup_ind_common: Interface=0x7FDF3EC2BF48, Call Info(

From the Library of Green Systems LLC

9780136575542_BOOK.indb 429

23/10/20 4:00 PM

430    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Calling Number=18005532447,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed), Called Number=14085267209(TON=Unknown, NPI=Unknown), Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE Present=TRUE, Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=71 ! Debugs, Outbound dial-per selection 010629: Oct 14 14:54:40.989 EDT: //-1/E9A61FCE80DD/DPM/dpMatchPeersMoreArg: Result=SUCCESS(0) List of Matched Outgoing Dial-peer(s): 1: Dial-peer Tag=2 2: Dial-peer Tag=3 010633: Oct 14 14:54:40.990 EDT: //-1/E9A61FCE80DD/DPM/MatchNextPeer: Result=Success(0); Outgoing Dial-peer=2 Is Matched (8 digits) 010634: Oct 14 14:54:40.990 EDT: //-1/E9A61FCE80DD/DPM/MatchNextPeer: Result=Success(0); Outgoing Dial-peer=3 Is Matched (5 digits) 010716: Oct 14 14:54:40.995 EDT: //71/E9A61FCE80DD/CCAPI/ccCallSetupRequest: Calling Number=18005532447(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed), Called Number=1000(TON=Unknown, NPI=Unknown), Redirect Number=, Display Info= Account Number=18005532447, Final Destination Flag=TRUE, Guid=E9A61FCE-EDEA-11E9-80DD-E8A5F2283ACD, Outgoing Dial-peer=2 ! DNS SRV and A Record Query 011005: Oct 14 14:54:41.018 EDT: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_ srv_query: TYPE SRV query for _sip._tcp.sj-cucm.ccnpcollab.lab and type:1 011006: Oct 14 14:54:47.024 EDT: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_ aaaa_query: DNS query for sj-cucm.ccnpcollab.lab and type:1 011009: Oct 14 14:54:47.026 EDT: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_ aaaa_query: IP Address of sj-cucm.ccnpcollab.lab is: 011010: Oct 14 14:54:47.026 EDT: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_ aaaa_query: 172.18.110.61 ! Sent INVITE 011129: Oct 14 14:54:47.037 EDT: //72/E9A61FCE80DD/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:[email protected]:5060 SIP/2.0 Call-ID: [email protected]

From the Library of Green Systems LLC

9780136575542_BOOK.indb 430

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    431 Service Provider

sj-cube.ccnpcollab.lab 172.18.110.62

Inbound Call Leg Inbound Dial Peer 1 Called: 14085267209 Calling: 18005532447

Outbound Call Leg Outbound Dial Peer 2 Called: 14085267209 Calling: 18005532447

Backup Outbound Dial Peer 3

sj-cucm.ccnpcollab.lab 172.18.110.61

rtp-cucm.ccnpcollab.lab 172.18.110.91

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 ­ xample 8-25, Showing Similar Information E sj-cube# show call active voice brief 12C6 : 71 3459414160ms.1 (14:54:40.987 EDT Mon Oct 14 2019) +8780 pid:1 Answer 18005532447 active

8

dur 00:00:23 tx:1140/228000 rx:1100/228000 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 172.18.110.65:6000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw ­extRelay: off Transcoded: No ICE: Off T media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 LocalUUID:867251d0ebfc5155adc48564c2cff41b RemoteUUID:54e59c8c00105000a000c4b36aba1b5a VRF: NA 12C6 : 72 3459420210ms.1 (14:54:47.037 EDT Mon Oct 14 2019) +2690 pid:2 Originate 14085267209 active

From the Library of Green Systems LLC

9780136575542_BOOK.indb 431

23/10/20 4:00 PM

432    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide dur 00:00:23 tx:1100/228000 rx:1140/228000 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 14.50.214.108:28968 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw ­extRelay: off Transcoded: No ICE: Off T media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a 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

   RemoteIP

MPSS

VRF

1

71

72

8046

 6000

    172.18.110.62

172.18.110.65

  NO

NA

2

72

71

8048

  28968

   172.18.110.62

14.50.214.108

  NO

NA

Peer Address

 IP R:

Found 2 active RTP connections sj-cube# show call active voice compact

A/O FAX T Codec

type

VRF

Total call-legs: 2 71 ANS

T30

g711ulaw

VOIP

P18005532447

      172.18.110.65:6000

NA

72 ORG

T30

g711ulaw

VOIP

P14085267209

      14.50.214.108:28968

NA

sj-cube# show sip-ua calls calling-number 18005532447 Total SIP call legs:2, User Agent Client:1, User Agent Server:1 SIP UAC CALL INFO Call 1 SIP Call ID

: [email protected]

State of the call

: STATE_ACTIVE (7)

Substate of the call

 : SUBSTATE_NONE (0)

Calling Number

 : 18005532447

Called Number

 : 14085267209

Called URI

      : sip:[email protected]:5060

Bit Flags

 : 0xC04018 0x90000100 0x80

CC Call ID

 : 72

Local UUID

 : 54e59c8c00105000a000c4b36aba1b5a

Remote UUID

 : 867251d0ebfc5155adc48564c2cff41b

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 432

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    433 Destination Name Number of Media Streams

 : sj-cucm.ccnpcollab.lab : 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 QoS ID

 : 0      : -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 round-trip 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.

8

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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 433

23/10/20 4:00 PM

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

Device 1

Device 2 9.9

Gig0: 9.9.

WAN

Gig1: 10.1

12.12.12.12

0.10.10

Figure 8-5  A Sample Topology 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: Request Device 1

Device 2 9.9

Gig0: 9.9.

Request: Source: 9.9.9.9 Destination: 12.12.12.12 Egress: Gig0 9.9.9.9

WAN

Gig1: 10.1

0.10.10

12.12.12.12

Response Device 2

Device 1 9

9. Gig0: 9.9.

Gig1: 10.1

0.10.10

WAN

Response: Source: 12.12.12.12 Destination: 9.9.9.9

12.12.12.12

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 and 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 involves the following steps: 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

From the Library of Green Systems LLC

9780136575542_BOOK.indb 434

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    435 sourced from Device 2 and sent to Device 1 must be sent to the local default gateway for Device 2. Step 2.

Device 2’s default gateway receives the 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 round-trip 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: Request Device 1

Device 2 9.9 Gig0: 9.9.

Request: Source: 10.10.10.10 Destination: 12.12.12.12 Egress: Gig1 10.10.10.10

Gig1: 10.1

12.12.12.12 WAN

0.10.10

Response Device 2

Device 1 9.9

Gig0: 9.9.

WAN

Gig1: 10.1

0.10.10

12.12.12.12

Response: Source: 12.12.12.12 Destination: 10.10.10.10

8

router# show ip route 10.10.10.10 % Network not in table router# show ip cef 10.10.10.10 0.0.0.0/0 no route

Figure 8-7  An Example of Bad Network Response 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 to use as the exit interface for IP address 12.12.12.12. The results show that Gig1 should be used for routing packets to the remote IP address of 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 435

23/10/20 4:00 PM

436    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide Step 5.

Device 2’s default gateway receives the packet and forwards it to Device 2 since they are on the same LAN segment.

Step 6.

The request is received successfully, and a response should be generated.

In the scenario illustrated in Figure 8-7, the response involves the following steps: 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 436

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    437 Request Device 1

Device 2 9.9

Gig0: 9.9.

Request: Source: 9.9.9.9 Destination: 12.12.12.12 Egress: Gig1 10.10.10.10

12.12.12.12 WAN

Gig1: 10.1

0.10.10

Response Device 2

Device 1 9.9

Gig0: 9.9.

WAN

Gig1: 10.1

0.10.10

12.12.12.12

Response: Source: 12.12.12.12 Destination: 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 involves the following steps: 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 to use as the exit interface for IP address 12.12.12.12. The results show that Gig1 should be used for routing packets to the remote IP address of Device 2.

Step 2.

Because the administrator leveraged application protocol binding for Gig0, 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 request 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 response should be generated.

In the scenario illustrated in Figure 8-8, the response involves the following steps: 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.

Step 3.

Device 2’s default gateway receives the 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

8

From the Library of Green Systems LLC

9780136575542_BOOK.indb 437

23/10/20 4:00 PM

438    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 438

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    439

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 dial-peer voice 9999 voip session protocol sipv2 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 ! dial-peer voice 8888 voip session protocol sipv2

8

voice-class sip tenant 8888 ! ! Global Bind, applies to all call-legs if the first two do not exist 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,

From the Library of Green Systems LLC

9780136575542_BOOK.indb 439

23/10/20 4:00 PM

440    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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

Status

Protocol

GigabitEthernet0/0.206

14.50.206.50

YES

manual

up

up

Loopback0

172.18.110.68

YES

NVRAM

up

up

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 [..Truncated for brevity..]

From the Library of Green Systems LLC

9780136575542_BOOK.indb 440

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    441 -------------- 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 [..Truncated for brevity..] -------------- SIP Transport Layer Listen Sockets --------------Conn-Id ===========

Local-Address =============================

0

[0.0.0.0]:5060:

1

[::]:5060:

rtp-cube# show sip-ua connections tcp tls brief [..Truncated for brevity..] -------------- SIP Transport Layer Listen Sockets --------------Conn-Id ===========

Local-Address =============================

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.

8

From the Library of Green Systems LLC

9780136575542_BOOK.indb 441

23/10/20 4:00 PM

442    CCNP Collaboration Call Control and Mobility CLACCM 300-815 Official Cert Guide 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:

Step 3.

■

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, RemoteParty-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.

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.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 442

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    443 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 | redirect-called | callback-number} numeric-tag !

Example 8-31  The Application of Translation Profiles to Global Configuration or Dial Peers ! voip-incoming translation-profile word ! dial-peer voice tag voip session protocol sipv2 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.

8

Table 8-11  Translation Rule Match Statement Wildcards and Regex Character

Definition

* (star)

Regex indicating zero or more of the previous character.

\ (backslash)

Escape character to force literal matches of regex commands. Example: To match the literal *, use an escape character: \*

(

Items wrapped in parentheses are considered a set. Escape characters should be used to avoid matching literal ( and ). Example: \( \)

) (parenthesis) ^ (circumflex)

Defines the explicit start of a string. Unlike dial peers, translation rules do not define the start of the match statement. This means defining a match string without a ^ can possibly match anywhere in the input string, which might lead to unwanted modifications in the middle of a number.

From the Library of Green Systems LLC

9780136575542_BOOK.indb 443

23/10/20 4:00 PM

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

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 111222333444555 Matched with rule 1 Original number: 111222333444555 Translated number: 222444 Router# test voice translation-rule 777 14085267209 Matched with rule 2 Original number: 14085267209 Translated number: +14085267209 Router# test voice translation-rule 777 4085267209 Matched with rule 3 Original number: 4085267209 Translated number: +14085267209 Router# test voice translation-rule 777 918005532447 Matched with rule 4 Original number: 918005532447 Translated number: 18005532447 Router# test voice translation-rule 777 +14085267209 Matched with rule 5 Original number: +14085267209 Translated number: 14085267209 Router# test voice translation-rule 777 14085151111 Matched with rule 6 Original number: 14085151111 Translated number: 1111

From the Library of Green Systems LLC

9780136575542_BOOK.indb 444

23/10/20 4:00 PM

Chapter 8: CUBE Call Routing and Digit Manipulation    445 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 222444.

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