ffirs.indd ii
9/21/11 11:51:43 AM
CVOICE 8.0 Implementing Cisco Unified Communications Voice over IP and QoS v8.0 Study Guide
ffirs.indd i
9/21/11 11:51:42 AM
ffirs.indd ii
9/21/11 11:51:43 AM
CVOICE 8.0 Implementing Cisco Unified Communications Voice over IP and QoS v8.0 Study Guide
Andrew Froehlich
John Wiley & Sons, Inc.
ffirs.indd iii
9/21/11 11:51:43 AM
Disclaimer: This eBook does not include ancillary media that was packaged with the printed version of the book. Senior Acquisitions Editor: Jeff Kellum Development Editor: Jim Compton Technical Editors: Scott Morris and Tyler Owen Production Editor: Dassi Zeidel Copy Editor: Linda Recktenwald Editorial Manager: Pete Gaughan Production Manager: Tim Tate Vice President and Executive Group Publisher: Richard Swadley Vice President and Publisher: Neil Edde Media Project Manager 1: Laura Moss-Hollister Media Associate Producer: Doug Kuhn Media Quality Assurance: Shawn Patrick Book Designers: Judy Fung and Bill Gibson Proofreaders: James Saturnio and Paul Sagan, Word One New York Indexer: Ted Laux Project Coordinator, Cover: Katherine Crocker Cover Designer: Ryan Sneed Copyright © 2012 by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-91623-0 ISBN: 978-1-118-18143-0 (ebk.) ISBN: 978-1-118-18141-6 (ebk.) ISBN: 978-1-118-18142-3 (ebk.) No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002. Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com. Library of Congress Control Number: 2011938572 TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book. 10 9 8 7 6 5 4 3 2 1
ffirs.indd iv
9/21/11 11:51:53 AM
Dear Reader, Thank you for choosing CVOICE 8.0: Implementing Cisco Unified Communications Voice over IP and QoS v8.0 Study Guide. This book is part of a family of premium-quality Sybex books, all of which are written by outstanding authors who combine practical experience with a gift for teaching. Sybex was founded in 1976. More than 30 years later, we’re still committed to producing consistently exceptional books. With each of our titles, we’re working hard to set a new standard for the industry. From the paper we print on, to the authors we work with, our goal is to bring you the best books available. I hope you see all that reflected in these pages. I’d be very interested to hear your comments and get your feedback on how we’re doing. Feel free to let me know what you think about this or any other Sybex book by sending me an email at
[email protected]. If you think you’ve found a technical error in this book, please visit http://sybex.custhelp.com. Customer feedback is critical to our efforts at Sybex. Best regards,
Neil Edde Vice President and Publisher Sybex, an Imprint of Wiley
ffirs.indd v
9/21/11 11:51:53 AM
ffirs.indd vi
9/21/11 11:51:54 AM
Acknowledgments I would like to take this opportunity to thank the many people who collaborated with me on the completion of this book as well as those who provided much-needed support along the long path to completion. Many thanks to my acquisitions editor, Jeff Kellum. Jeff has given me the opportunity to write my second book for Sybex, and I very much appreciate his confidence in me. Additionally, I’d like to thank my development editor, Jim Compton; technical editors, Scott Morris and Tyler Owen; production editor, Dassi Zeidel; and copyeditor, Linda Recktenwald. I’ve worked with all of these great people on both of my Sybex publications, and knowing their working styles and habits has greatly helped in the development of this book and making it technically sound, well structured, and well written. I’d also like to thank my family and friends for all of their support and encouragement. 2010 and 2011 have been a fruitful period for me both personally and professionally. Moving overseas to Thailand and getting married, as well as consulting, freelance writing, and publishing this book created an environment that was highly rewarding. Yet there was no way I could have done it without the support of my friends and family. Specifically, I would like to thank my mother and father, Ron and Elaine Froehlich, and my friends Angie Barbini, Adriana Castro, Matt and Fabiana Liska, Kevin and Ruth Ann McQuire, and Sean and Heather Uhles. Finally, I want to thank my wife, Manta Froehlich. She is the one person who saw the daily effort put into writing this book and gave me the freedom to do what I needed to get the job done. That includes many late nights and weekend work. I have learned a great deal from her patience, and I know that having her by my side makes me a better person.
ffirs.indd vii
9/21/11 11:51:54 AM
About the Author Andrew Froehlich, CCNA, CCDA, CCNA Voice, CCNP, CCSP, CCDP, F5 systems engineer, is the president of West Gate Networks, a network and IT consulting fi rm based in Chicago. Andrew has performed network design and support for large organizations including the University of Chicago Medical Center, State Farm Insurance, and United Airlines. In addition to having more than 14 years of network architecture experience, he holds a degree in management information systems from Northern Iowa University and a master of business administration degree from Northern Illinois University. He is also a freelance writer and blogger for IT publications including Network World and Enterprise Efficiency. Andrew also authored Sybex’s CCNA Voice Study Guide.
ffirs.indd viii
9/21/11 11:51:54 AM
Contents at a Glance Introduction
xxi
Assessment Test
xxx
Chapter 1
An Introduction to Traditional Telephony and Cisco Unified Communications
1
Chapter 2
Understanding Analog and Digital Voice
33
Chapter 3
VoIP Operation and Protocols
77
Chapter 4
The VoIP Path-Selection Process
103
Chapter 5
VoIP Design Options
145
Chapter 6
Configuring Voice Gateway Ports and DSPs
179
Chapter 7
Configuring Voice Gateway Signaling Protocols
223
Chapter 8
Configuring and Managing CUCM Express
281
Chapter 9
Advanced Voice Gateway Features
353
Chapter 10
Configuring and Managing CUBE and H.323 Gateways
395
Chapter 11
Introduction to Quality of Service
439
Chapter 12
Configuring Quality of Service
473
Appendix
About the Companion CD
529
Index
ffirs.indd ix
533
9/21/11 11:51:55 AM
ffirs.indd x
9/21/11 11:51:55 AM
Contents Introduction
xxi
Assessment Test
xxx
Chapter
Chapter
ftoc.indd xi
1
2
An Introduction to Traditional Telephony and Cisco Unified Communications
1
Understanding Traditional Telephony Components Telephony Edge Devices Phone Switches The Central Office The Local Loop Trunks National and International Calling PSTN Understanding Private Telephony Phone Systems Key System PBX Understanding the Unified Communications Model Endpoints Applications Call Processing Agents Network Infrastructure Unified Communications Deployment Models The Centralized Services Deployment Model The Distributed Services Deployment Model The Inter-Networking of Services Deployment Model The Geographical Diversity Deployment Model Summary Exam Essentials Written Lab 1.1 Review Questions Answers to Review Questions Answers to Written Lab 1.1
2 3 3 4 5 6 8 9 10 10 11 11 15 15 20 20 20 21 22 22 23 24 25 26 30 32
Understanding Analog and Digital Voice
33
Understanding Analog Voice Ports and Signaling Analog Voice Port Types Analog Voice Signaling Basic Configuration of Analog Voice Ports Understanding Digital Voice Ports and Signaling An Overview of the Analog-to-Digital Conversion Process
34 34 35 47 51 51
9/20/11 4:59:58 PM
xii
Chapter
Chapter
Contents
3
4
Digital Voice Port Types Digital Voice Multiplexing, Framing, and Physical Transport Digital Voice Signaling Basic Configuration of Digital Voice Ports Summary Exam Essentials Written Lab 2.1 Review Questions Answers to Review Questions Answers to Written Lab 2.1
56 60 63 66 66 67 69 73 75
VoIP Operation and Protocols
77
Voice Media Transmission Protocols Introduction to the Real-Time Transport Protocol Introduction to the Real-time Transport Control Protocol Introduction to Compressed RTP Introduction to Secure RTP Voice Gateway Signaling Protocols H.323 Session Initiation Protocol Media Gateway Control Protocol Skinny Client Control Protocol Voice Gateway Signaling Protocol Comparison An Introduction to Gatekeepers and Other H.323 Components Gatekeeper H.323 Proxy Server H.323 Multipoint Control Unit A Typical H.323 Network Choosing the Appropriate Voice Gateway Signaling Protocol Summary Exam Essentials Written Lab 3.1 Review Questions Answers to Review Questions Answers to Written Lab 3.1
78 78
The VoIP Path-Selection Process Understanding the Dial Plan Path-Selection Process Understanding Voice Call Types Path Selection and Call Routing
ftoc.indd xii
56
81 82 83 83 84 85 87 88 88 89 89 91 91 92 93 94 94 95 96 100 102 103 104 104 108
9/20/11 4:59:59 PM
Chapter
5
Contents
xiii
POTS and VoIP Dial Peers Call Legs Path-Selection Strategies Introduction to PSTN and Private Numbering Plans Using Wildcards to Simplify Dial-Peer Configurations Site-Code Dialing Dial-Plan Digit Manipulation Digit Stripping Forwarding the Last X Digits Prefix Adding Number Substitution Translation Rules and Profiles Verifying Dial-Plan Configurations Summary Exam Essentials Written Lab 4.1 Review Questions Answers to Review Questions Answers to Written Lab 4.1
108 110 111 113 117 122 123 123 124 125 126 127 132 135 135 136 137 141 143
VoIP Design Options
145
Voice Gateway DSP Functions Understanding Voice and VoIP Quality Considerations Audio Fidelity Echo and Echo Cancellation Background Noise Voice over IP Quality Considerations Defining Voice Codecs Voice Codec Types Understanding Codec Complexity Quantifying Voice Codec Clarity Mean Opinion Score Perceptual Speech Quality Measure Perceptual Evaluation of Speech Quality Perceptual Objective Listening Quality Analysis Choosing the Right Codec Hardware Compatibility Network Capacity Codec Complexity Endpoint Uses Call Clarity Calculating IP Voice Bandwidth Consumption Frame and Bandwidth Calculations Determining Packet and Frame Size Information
ftoc.indd xiii
146 147 148 148 149 151 153 153 156 160 161 162 163 163 163 163 164 164 164 164 164 165 165
9/20/11 4:59:59 PM
xiv
Contents
Additional Voice Packet and Frame Size Factors Codec Bit Rate Frame and Bandwidth Calculation Example Summary Exam Essentials Written Lab 5.1 Review Questions Answers to Review Questions Answers to Written Lab 5.1 Chapter
ftoc.indd xiv
6
166 166 167 170 170 171 172 176 178
Configuring Voice Gateway Ports and DSPs
179
Analog Port Configurations Configuring an FXS and an FXO PLAR OPX Port Configuring FXS/DID Inbound and FXO Outbound Configuring E&M to Bridge Legacy PBX with VoIP Networks Configuring CAMA Digital Port Configurations Configuring a T1 CAS to Analog Cross-Connect Configuring a T1 PRI Configuring DSP Resources Enabling a DSP Farm on a Voice Gateway Creating DSP Profiles Configuring SCCP Communications Configuring the CUCM Voice Port and Dial-Peer Verification Commands show voice port show controller show voice dsp test voice port csim start debug dialpeer Summary Exam Essentials Written Lab 6.1 Hands-On Labs Hands-On Lab 6.1: Configuring a T1 PRI Hands-On Lab 6.2: Configuring a CAMA Port for E911 Services Hands-On Lab 6.3: Configuring an Outbound Dial Peer to the PSTN Hands-On Lab 6.4: Configuring an Outbound Dial Peer to the PSAP
180 180 184 187 188 191 191 195 198 198 199 200 201 203 203 205 205 206 209 209 210 210 211 212 212 213 214 214
9/20/11 5:00:00 PM
Contents
Review Questions Answers to Review Questions Answers to Written Lab 6.1 Chapter
Chapter
ftoc.indd xv
7
8
xv
215 220 222
Configuring Voice Gateway Signaling Protocols
223
Configuring H.323 Configuring an H.323 Gateway H.323 show Commands Configuring SIP Determine the Endpoint Locations Determine the Endpoint Capabilities Determine Endpoint Availability Establish a Session Configure SIP between IP Voice Gateways Configure Secure SIP Communications Modify SIP Voice Gateway Settings SIP show Commands Configuring MGCP Residential Gateways Trunking Gateways Configure an MGCP Residential Gateway Configure an MGCP Trunking Gateway MGCP show Commands Summary Exam Essentials Written Lab 7.1 Hands-On Labs Hands-On Lab 7.1: Configuring Basic SIP Hands-On Lab 7.2: Modifying SIP Timers and Retries Review Questions Answers to Review Questions Answers to Written Lab 7.1
224 227 234 236 237 237 239 239 239 241 243 249 253 254 255 257 259 260 265 266 267 268 269 270 272 277 279
Configuring and Managing CUCM Express
281
Voice Network Infrastructure Considerations Power Options for IP Phones Configuring VLANs and Voice VLANs Network Infrastructure Services for VoIP Support An Overview of CUCM Express Understanding CUCM Express Capabilities Understanding CUCM Express Hardware Requirements Understanding CUCM Express Software Licensing New Software-Activated Voice Licensing
282 282 286 290 293 294 295 296 297
9/20/11 5:00:00 PM
xvi
Contents
Initial CUCM Express Configuration Configuring CUCM Express as a TFTP Server Configuring the Mandatory CUCM Express System Settings Using SCCP Signaling Configuring the Mandatory CUCM Express System Settings Using SIP Signaling Configuring SCCP and SIP Phones and Directory Numbers Configuring Basic SCCP Ephone and Ephone-DNs Configuring Basic SIP Voice Register Pools and Voice Register DNs SCCP Ephone-DN Line Configuration Options Configuring Ephone-DN Shared Lines Configuring Two Ephone-DNs with One Number Configuring Ephone-DN Dual- and Octo-lines Configuring SCCP Individual Lines Configuring Ephone Button Options Configuring CUCM Express Telephony Service Features Configuring User Locale and Network Locale Configuring the Date and Time Format Modifying the Cisco IP Phone Keepalive Timer Cisco IP Phone Restart versus Reset Using CUCM Express Verification and Troubleshooting Commands Troubleshooting Cisco Phone Registrations Determining the State of an Ephone Summary Exam Essentials Written Lab 8.1 Hands-On Labs Hands-On Lab 8.1: Configuring CUCM Express as a TFTP Server Hands-On Lab 8.2: Configuring CUCM Express for Basic SCCP Phone Operation Hands-On Lab 8.3: Verifying the Configuration and Status of Your Ephones Review Questions Answers to Review Questions Answers to Written Lab 8.1 Chapter
9
Advanced Voice Gateway Features Configuring DTMF Relay Support Configuring H.323 DTMF Relay Configuring SIP DTMF Relay Configuring MGCP DTMF Relay
ftoc.indd xvi
297 298 300 305 307 308 310 311 312 314 315 317 318 325 325 328 329 329 332 332 334 339 340 341 342 342 343 344 346 350 352 353 354 354 355 356
9/20/11 5:00:01 PM
Contents
Configuring Fax Support Understanding Fax Relay Configuring Cisco Fax Relay Configuring T.38 Fax Relay Understanding Fax Pass-through Configuring Fax Pass-through Understanding T.37 Store-and-Forward Fax Configuring Modem Support Configuring Modem Pass-Through Configuring Modem Relay Configuring Voice Backup Paths Configuring a WAN-to-PSTN Fallback Configuring MGCP-to-H.323 Fallback Understanding and Configuring COR and SRST Toll Bypass and TEHO Configuring Call Blocking Summary Exam Essentials Written Lab 9.1 Hands-On Labs Hands-On Lab 9.1: Configuring Toll Bypass and PSTN Redundancy Hands-On Lab 9.2: Configuring TEHO Review Questions Answers to Review Questions Answers to Written Lab 9.1 Chapter
10
Configuring and Managing CUBE and H.323 Gateways What Is an H.323 Gatekeeper? H.323 Gatekeeper Mandatory Features H.323 Gatekeeper Optional Features Understanding Gatekeeper Signaling RAS Gatekeeper Discovery Messages RAS Gateway Registration Messages RAS Call Admission Messages The H.323 Gatekeeper Discovery, Registration, and Admission Process RAS Location Messages RAS Resource Availability Messages RAS Bandwidth Messages Configuring an H.323 Gatekeeper Configuring Local Zones Configuring Remote Zones
ftoc.indd xvii
xvii
357 357 359 359 364 364 365 367 367 368 368 369 370 372 377 380 382 382 384 384 385 386 387 391 393
395 396 397 398 399 399 400 400 401 402 404 404 405 406 406
9/20/11 5:00:01 PM
xviii
Contents
Configuring Zone Prefixes Configuring Technology Prefixes Voice Gateway Interoperation with Gatekeepers Configuring H.323 Interface Commands Configuring Dial Peers for Gatekeeper Interoperation Enabling the H.323 Service on a Voice Gateway Configuring Call Admission Control on H.323 Gatekeepers Understanding the CAC Bandwidth Control on H.323 Gatekeepers Configuring CAC Bandwidth Control on H.323 Gatekeepers Gatekeeper Verification and Troubleshooting Commands Introducing the Cisco Unified Border Element CUBE Features CUBE Media Flow Options CUBE Signaling Protocol Interoperation CUBE RSVP-CAC CUBE Call Flow Differences Configuring the CUBE Configuring Protocol Interoperation Configuring Media Flow-Around Configuring Codec Transparency Configuring H.323 Fast-to-Slow-Start Signaling Configuring SIP Delayed-to-Early-Offer Signaling CUBE Verification and Troubleshooting Commands Summary Exam Essentials Written Lab 10.1 Hands-On Labs Hands-On Lab 10.1: Configuring GB_Gatekeeper_1 Hands-On Lab 10.2: Configuring London_gw1 and Glasgow_gw1 Review Questions Answers to Review Questions Answers to Written Lab 10.1 Chapter
11
Introduction to Quality of Service Problems with Voice/Video on IP Networks Mitigating IP Network Voice Issues Providing Sufficient Bandwidth for a Newly Converged Network
ftoc.indd xviii
407 408 409 409 410 411 411 411 412 414 416 417 417 419 420 421 422 422 423 424 424 425 425 427 427 428 429 430 430 432 436 438 439 440 441 441
9/20/11 5:00:02 PM
Contents
Chapter
12
Reduce End-to-End Delay Reduce Jitter Eliminate Packet Loss Putting the Pieces Together The Three-Step QoS Process Traffic Classification Traffic Marking Traffic Queuing QoS Policy Considerations The Three-Step QoS Policy Development Process Methods of Configuring QoS Policies QoS Classification Models The Best-Effort Model The IntServ Model The DiffServ Model Comparing the QoS Models Understanding the DiffServ ToS/DS Byte DiffServ Service Quality Features Layer 2 Class of Service and QoS Trust Boundaries Layer 2 Classification and Marking with CoS Identifying QoS Trust Boundaries QoS Baseline Models Comparing the Cisco QoS Baseline Model Recommended Cisco Baseline Classification Markings Recommended Cisco Baseline CongestionManagement and -Avoidance Tools Summary Exam Essentials Written Lab 11.1 Review Questions Answers to Review Questions Answers to Written Lab 11.1
442 442 443 444 444 444 445 445 445 445 446 447 447 447 448 449 449 453 459 459 460 461 461
Configuring Quality of Service
473
Configuring QoS Policies Using AutoQoS Configuring AutoQoS for VoIP on a Router Configuring AutoQoS for VoIP on a Switch Configuring AutoQoS for the Enterprise on a Router Configuring QoS Policies Using MQC Configuring Class Maps Configuring Policy Maps
ftoc.indd xix
xix
462 463 464 464 465 466 470 472
474 475 479 483 488 490 493
9/20/11 5:00:02 PM
Contents
xx
Applying Policy Maps to Interfaces with a Service Policy MQC QoS Configuration Show Commands Configuring Congestion-Avoidance Techniques Configuring Class-Based Traffic Policing and Shaping Understanding Token Buckets Understanding Traffic-Policing Token Buckets Configuring Class-Based Traffic Policing Configuring Class-Based Traffic Shaping Configuring Link Efficiency Techniques Configuring Link Fragmentation and Interleaving for MLP and Frame Relay Configuring Class-Based Header Compression Configuring Trust Boundaries Configuring CoS-to-DSCP Mappings Summary Exam Essentials Written Lab 12.1 Hands-On Labs Hands-On Lab 12.1: Configuring a Switchport to Trust Cisco IP Phone QoS Markings Hands-On Lab 12.2: Modifying CoS-to-DSCP Mappings Hands-On Lab 12.3: Configuring a Router for QoS Using MQC Review Questions Answers to Review Questions Answers to Written Lab 12.1 Appendix Index
ftoc.indd xx
About the Companion CD
495 495 498 500 500 501 504 506 508 509 512 513 515 517 517 518 518 519 519 520 522 526 528 529 533
9/20/11 5:00:03 PM
Introduction Welcome to CVOICE 8.0: Implementing Cisco Unifi ed Communications Voice over IP and QoS v8.0 Study Guide, a comprehensive guide that covers everything you need for Cisco’s new exam 642-437. This particular exam will meet one requirement on the path to achieve two different Cisco certification goals. Cisco has multiple levels of certifications, most of which build upon each other, as shown here:
Architect Expert Professional Associate Entry
Specialist
This book covers one exam that is part of either the five-exam CCNP Voice certification or the two-exam Cisco Rich Media Communications Specialist certification, both of which are highlighted. Currently, the five exams to become CCNP Voice certified are:
642-437 CVOICE v8.0
642-447 CIPT1 v8.0
642-457 CIPT2 v8.0
642-427 TVOICE v8.0
642-467 CAPPS v8.0
The CCNP Voice certification track has the prerequisite that the test taker must currently be CCNA Voice (640-461 or 640-460) certified. Specialist certifications are for network professionals with a very focused certification goal in mind. Specifically, the Cisco Rich Media Communications Specialist certification is for IT professionals who must be proficient in the design, implementation, and support of voice, video, and web collaboration services on a converged IP network. Note that the technology involved with these specialized certifications is likely to change rapidly, and therefore most specialist certifications are valid for only two years. The two exams to become Cisco Rich Media Communications Specialist certified are:
642-437 CVOICE v8.0
642-481 CRMC
The prerequisite for this Specialist certification is that the certification candidate must currently be either CCNA certified or have any CCIE certification.
flast.indd xxi
9/20/11 10:56:04 AM
xxii
Introduction
The exams necessary to achieve either of these two Cisco certifications can be taken in any order you choose, but it is very common to start with the 642-437 CVOICE v8.0 exam, because it provides a solid foundation for the remainder of the exams.
A Closer Look at Cisco’s Voice Certifications Probably most readers of this study guide will be looking to achieve their CCNP Voice certification, because it is part of Cisco’s “core” structure for voice. Cisco offers three distinct levels of core voice certifications. The following diagram shows that the CCNA Voice certification is a building block to the professional- and expert-level voice certifications:
CCIE Voice CCNP Voice CCNA Voice
As of the writing of this book, the CVOICE v8.0 (642-437) exam costs $250 USD. The exam tests your knowledge a great deal in areas both theoretical and technically specific to Cisco hardware and software. Once you use this book to pass the CVOICE v8.0 exam, you can choose to continue on the CCNP Voice path and pass the other four exams to achieve the CCNP Voice certification. If you choose to achieve the CCNP Voice certification, you may want to further your education and attempt to pass the CCIE Voice certification. But even if you stop after achieving your CCNP Voice certification, you will have demonstrated to your current or prospective employers that you have professional-level knowledge of the interoperations of legacy PSTN and Cisco voice technologies. This assurance to employers will make it easier for you to land that dream job you’ve always wanted!
What Skills Do You Need to Pass the CVOICE v8.0 Exam? To pass the 642-437 exam, you should be proficient in the following areas:
flast.indd xxii
A thorough knowledge of analog, digital, and IP voice technologies including but not limited to FXS, FXO, T1/E1, CAMA, voice trunks, voice packetization, codecs, transcoding, PBX, key systems, multiplexing, IP-to-IP gateways, and QoS.
The ability to install, configure, and support Cisco voice gateways and gatekeepers. This includes functions including, but not limited to, dial peers, digit manipulation, path selection, calling privileges, signaling protocols, DSP farms, and analog and digital ports.
9/20/11 10:56:05 AM
Introduction
xxiii
The ability to install, configure, and support a Cisco Unified Communications Manager Express (CUCM Express) system and endpoints. This also includes preparation of CUCM Express support components, including DHCP, NTP, and TFTP.
The ability to install, configure, and support a Cisco Unified Border Element (CUBE) for functionality including address hiding, protocol/media internetworking, and call admission control.
A solid understanding of QoS fundamentals and how to implement them on Cisco routers and Catalyst switches. This includes topics such as QoS requirements, IntServ/ DiffServ models, and link efficiency techniques.
What Does This Book Cover? This book covers everything you need to know in order to pass the CVOICE v8.0 (642-437) exam. In addition to studying this book, having the ability to study and practice with Cisco router/switch hardware and software will provide you the confidence to complete the simulation questions found in the exam. You will learn the following information in this book:
flast.indd xxiii
Chapter 1, “An Introduction to Traditional Telephony and Cisco Unified Communications,” covers traditional telephony concepts and components that are found in PSTN networks and legacy voice systems. Additionally, you are given an introduction to Cisco’s Unified Communications model and the best-practice deployment models.
Chapter 2, “Understanding Analog and Digital Voice,” provides you with the background covering traditional analog and digital telephony ports that are commonly installed on voice gateways that connect to the PSTN or legacy PBX systems. Topics such as network signaling, interface types, and the analog-to-digital conversion process are covered in detail along with the basics of configuring many of these interfaces on Cisco hardware.
Chapter 3, “VoIP Operation and Protocols,” introduces you to voice transport over an IP network. Topics in this chapter include voice media transmission and control protocols, voice gateway signaling protocols, and an introduction to common H.323 network components.
Chapter 4, “The VoIP Path-Selection Process,” provides you with the path-selection process that a voice gateway goes through each time a call needs to be routed through it. This includes a thorough understanding of the dial-plan selection process and on- versus off-network calling. Additionally, we cover the differences between POTS and VoIP dial peers and how to modify voice gateway path selections based on dial-peer strategies and dial-peer wildcards, translations, and manipulation techniques.
Chapter 5, “VoIP Design Options,” exposes readers to VoIP network design considerations. This includes voice quality topics such as fidelity, latency, delay, and jitter, and it introduces you to some of the popular voice codecs used on VoIP networks.
9/20/11 10:56:05 AM
xxiv
Introduction
This chapter also shows you how to calculate voice bandwidth consumption on an IP network and how to choose the optimal codec based on network specifications.
flast.indd xxiv
Chapter 6, “Configuring Voice Gateway Ports and DSPs,” dives into more complex voice gateway configuration techniques that show readers how to set gateway features such as PLAR FXS/FXO DID, E&M bridge, and CAMA and explores several T1 scenarios. Additionally, you will learn how to configure a voice gateway as a DSP farm for the offloading of services such as transcoding, conferencing, and MTP services.
Chapter 7, “Configuring Voice Gateway Signaling Protocols,” is an in-depth look at voice gateway signaling protocols and how to configure them in multiple scenarios. Those scenarios include the need to modify default settings, configuring protocols for redundancy, using secure-mode communications, and best-practice configuration and verification methods for production networks.
Chapter 8, “Configuring and Managing CUCM Express,” introduces you to the world of the CUCM Express router and the functionality it can provide small to medium-size businesses and remote-site offices. Those preparing for the CVOICE v8.0 exam must know not only how to configure the CUCM Express router but also how to prepare the IP network for voice communications with CUCM Express. This includes topics such as PoE for Cisco IP phones, voice VLAN configuration best practices, and network services for the support of IP phones including DHCP, TFTP, and NTP.
Chapter 9, “Advanced Voice Gateway Features,” shows readers several of the valueadded features and functionalities of voice gateways. Some of these features help to facilitate the exchange of calls between IP and legacy PSTN networks, as is the case with DTMF and fax/modem relay. You’ll also see how to configure fallback functionality on networks that operate both IP and PSTN networks between sites. Lastly, we take a look at some cost-saving features inherent when you configure features such as TEHO and call blocking.
Chapter 10, “Configuring and Managing CUBE and H.323 Gateways,” is an introduction to how to configure and manage both an H.323 gatekeeper and the Cisco Unified Boarder Element (CUBE). An H.323 gatekeeper is a value-added component on large H.323 networks that helps to manage H.323 endpoints and zones. The CUBE device is a router that acts as an IP-to-IP gateway between two different networks. You will learn several methods of installing and maintaining these hardware/software components.
Chapter 11, “Introduction to Quality of Service,” fully introduces the concepts of QoS and shows you why QoS is necessary on IP networks. It also details bestpractice policy methodologies and models. You will be introduced to three different QoS implementation methods. Finally, we cover some techniques for avoiding link congestion; these techniques also aid in the efficient transport of time-sensitive traffic, especially across low-speed WAN connections.
Chapter 12, “Configuring Quality of Service,” continues our coverage of QoS, showing how to implement AutoQoS, MQC, and traffic policing/shaping and
9/20/11 10:56:06 AM
Introduction
xxv
congestion-avoidance techniques, including LFI and compression. You will also learn how to set QoS trust boundaries at various points within a network.
How to Use This Book CVOICE 8.0: Implementing Cisco Unifi ed Communications Voice over IP and QoS Study Guide is designed to prepare a reader to pass the 642-437 exam, one of five stages on the way to the professional-level certification in Cisco voice technologies. To get the most out of this book, I recommend you use the following study method:
flast.indd xxv
1.
Take the assessment test provided to you prior to Chapter 1 of this book. Try to answer each question without looking at the answers and explanations found in the back of the book. This should give you an indication of your skill level prior to reading the book. Once you have completed the assessment test and graded yourself, take time to carefully read over the explanations for any question you get wrong and note the chapters in which the material is covered. This information should help you identify sections of the book that you need to spend additional time on. Keep in mind, however, that the book was designed for you to read each chapter in order. Much of the material found in the chapters builds on knowledge learned from previous chapters.
2.
Before reading each chapter, make sure to review the test objectives listed at the beginning. These objectives are what the exam taker must ultimately know in order to pass the CVOICE v8.0 (642-437) exam.
3.
Complete each written lab at the end of each chapter. These labs are created to make sure the reader fully understands key topics that are contained within that chapter. Using a written format instead of multiple-choice format forces the reader to know the answers off the top of their head instead of just eliminating options, as we often do with multiple-choice questions.
4.
Work through and fully understand the commands found in the hands-on labs in the chapter. Not all chapters have hands-on labs, but the book focuses on the important tasks necessary for aspiring CCNP Voice–certified network engineers. See the accompanying sidebar for a recommended lab setup.
5.
Answer all of the review questions related to each chapter. Once you have finished answering the questions, review the answers and explanations to not only understand the correct answers but also understand why the incorrect answers are actually incorrect! Keep in mind that these review questions will not be the exact questions you will find on the exam, but they will help you to understand the material from which Cisco creates the actual exam questions.
6.
Take time to review the bonus practice exams that are included on the companion CD. Questions in these exams appear only on the CD.
7.
Test yourself using all the flashcards on the included CD.
9/20/11 10:56:06 AM
xxvi
8.
Introduction
Finally, make sure your mindset is in the right place. G. K. Chesterton said it best: “There is a great deal of difference between the eager man who wants to read a book and the tired man who wants a book to read.” So become that eager person when you prepare for your exam. You’ll see the payoff of your hard work before you know it!
Recommended Home Lab Setup As stated earlier, it is critical to get some hands-on experience with Cisco voice routers that can operate as voice gateways, H.323 gatekeepers, and CUCM Express. Additionally, some time spent working with a Cisco Catalyst switch to configure QoS policies is highly recommended. If you are in a classroom environment, the training center should provide you with this equipment or a similar configuration to get you hands-on experience. Otherwise, you will have to find the hardware and software yourself. The following is a list of equipment I suggest you try to acquire for your home lab studies. If you are concerned about the high cost of purchasing the equipment, keep in mind that Cisco hardware can be easily resold on used markets such as Craigslist or eBay. Combine that fact with adding an extremely hot certification to your resume, and it’s an investment well worth the initial cost.
Qty
Item
2
Cisco ISR 2900 series router with two Fast Ethernet interfaces and one T1 serial interface
1
Cisco Router IOS with Voice Gateway and H.323 Gatekeeper services
1
Cisco Router IOS that can operate as a Cisco Unified Communications Manager Express
1
Cisco Catalyst switch
2
Cisco 7940 IP phones
2
Analog telephones
1
Windows PC loaded with terminal emulation software such as PuTTY or SecureCRT
The router and switch equipment should give you the ability to practice configuring all of the example configurations and practice labs in this study guide. The two IP phones I recommend can also be supplemented with two Windows PCs running the Cisco IP Communicator softphone. The analog phones in your lab are useful for testing FXS configurations. You should also acquire the necessary analog, Ethernet, and T1 crossover cabling for interconnecting hardware. Finally, it is important to use a terminal emulator on which you are comfortable with both configuring Cisco hardware and using copy and paste functions, so you can save any configurations and command outputs that will help you with your studies.
flast.indd xxvi
9/20/11 10:56:07 AM
Introduction
xxvii
What’s on the CD? The CD included with this book includes many supplemental tools that you can use to further your studies and achieve your goal of becoming a CCNP Voice–certified administrator. The following content is provided for you to use to further your study.
The Sybex Test Engine The Sybex test engine software lets readers practice all of the review and assessment questions found in the book as well as two bonus practice exams that are found only on the CD. The exams let potential test takers practice in an electronic test-taking environment that is similar to the actual Cisco exam.
Electronic Flashcards In addition to the Sybex test engine software, the CD includes over 200 electronic flashcards with which to test yourself. These flashcards are designed to help you quickly recognize and recall important CVOICE information that will be useful when taking the 642-437 exam.
Glossary of Terms in PDF The CD contains a searchable Glossary of terms in PDF format. This includes an exhaustive list of terms and defi nitions any CCNP Voice candidate should be familiar with.
Tips for Taking the CVOICE Exam According to Cisco’s website at https://learningnetwork.cisco.com/community/ certifications/ccvp/cvoicev8?tab=overview, the CVOICE exam contains anywhere from 60 to 70 questions and must be completed in 90 minutes or less. English is currently the only language in which the exam is available. A passing score varies according to the types of questions found in the exam, but it is probably best to assume you need to get approximately 85 percent of the questions correct to pass the exam. When taking the exam, thoroughly read each question to make sure you know what answer it is looking for. Cisco exam questions tend to have answers that look identical. You will fi nd, however, that there are small differences in the answers that can determine a correct or incorrect answer. Also, keep in mind that you should choose the answer that Cisco believes is correct as opposed to what you or other vendors believe. This is a Cisco exam, after all, so the right answer is the one that Cisco recommends! The format of the 642-437 exam questions might include any of the following:
flast.indd xxvii
Multiple-choice single-answer
Multiple-choice multiple-answer—Cisco will always tell you to choose two or three, depending on the proper number of multiple correct responses.
Drag-and-drop
9/20/11 10:56:07 AM
xxviii
Introduction
Fill-in-the-blank
Cisco voice router gateway/gatekeeper/CUCM Express, switch or CUBE simulations
Because of the limitations inherent in the Sybex test engine, this study guide cannot include several of the exam types that you are likely to experience on the real exam. But rest assured that if you fully understand the material contained in the text and all the lab and practice questions, you should have the knowledge to answer any question type you come across on the actual exam.
Test-Day Tips for Certification Success
Arrive at least 30 minutes early to the exam center. That way you can check in and mentally prepare for the exam without having to rush.
Take the Cisco exam tutorial found within the Cisco exam software on test day. This tutorial is offered prior to the official start of each exam before the test timer starts. In this tutorial you will be given an interactive lesson as to the format of the exam and how to navigate through the different question types, including multiple-choice, drag-and-drop, fill-in-the-blank, and simulation questions. Even if you have taken many Cisco exams, I highly recommend going through the tutorial in case there is something new to the exam format since the last time you took an exam.
Read both the questions and answers very carefully. Cisco often will intentionally lead the hasty test taker, who simply glosses over a question, to quickly choose the incorrect answer. Patience and careful thinking pay off greatly when taking Cisco exams!
Be aware that you cannot go back to change an answer once you have moved on to the next question. Make sure that the answer you choose is the one you want to stick with, because there is no way to change it later on.
Conventions Used in This Book This book uses certain typographic styles in order to help you quickly identify important information and to avoid confusion over the meaning of words such as on-screen prompts. In particular, look for the following styles:
Italicized text indicates key terms that are described at length for the first time in a chapter and are defined in the book’s Glossary.
A monospaced font indicates the contents of configuration files, messages displayed at a command prompt, filenames, text-mode command names, and Internet URLs.
Italicized monospaced text indicates a variable—information that differs from one
system or command run to another, such as the name of a client computer or a process ID number.
flast.indd xxviii
9/20/11 10:56:08 AM
Introduction
xxix
Bold monospaced text is information that you’re to type into the computer, usually at a
command prompt. In addition to these text conventions, which can apply to individual words or entire paragraphs, a few conventions highlight segments of text:
A note indicates information that’s useful or interesting but that’s somewhat peripheral to the main text. A note might be relevant to a small number of networks, for instance, or it may refer to an outdated feature.
A tip provides information that can save you time or frustration and that may not be entirely obvious. A tip might describe how to get around a limitation or how to use a feature to perform an unusual task.
Warnings describe potential pitfalls or dangers. If you fail to heed a warning, you may end up spending a lot of time recovering from a bug, or you may even end up restoring your entire system from scratch.
Sidebars A sidebar is like a note but longer. The information in a sidebar is useful, but it doesn’t fit into the main flow of the text.
Real World Scenario A real world scenario is a type of sidebar that describes a task or example that’s particularly grounded in the real world. This may be a situation that I or somebody I know has encountered, or it may be advice on how to work around problems that are common in real, working Cisco environments.
How to Contact Sybex Sybex strives to keep you supplied with the latest tools and information you need for your work. Please check our website at www.sybex.com/go/cvoice, where we’ll post additional content and updates that supplement this book should the need arise.
flast.indd xxix
9/20/11 10:56:08 AM
Assessment Test 1.
After the AutoQoS for the Enterprise implementation phase has been completed, what final step should be done? A. Disable the discovery phase process within every interface it is running by issuing the no auto discovery qos command.
2.
B.
Disable the discovery phase process globally by issuing the no auto discovery qos command.
C.
Schedule the autodiscovery phase process to run every week within every interface by issuing the auto discovery qos 7 command.
D.
Schedule the autodiscovery phase process to run every week globally by issuing the auto discovery qos 7 command.
Which of the following DTMF relay methods transmit tones in an ASCII format? (Choose all that apply.) A. h245-signal
3.
B.
h245-alphanumeric
C.
cisco-rtp
D.
rtp-nte
Given the following information, what UC deployment model should you choose if your business has six large (1,000 users or more) and geographically dispersed campuses that are interconnected together by a 3 Mbps WAN link? A. Centralized services model
4.
B.
Distributed services model
C.
Inter-networking of services model
D.
Geographical diversity model
Which of the following commands is the correct syntax and interface mode to configure AutoQoS for VoIP on a Cisco router? A. Router(config-if)#auto qos voip
5.
B.
Router(config-if)#auto qos voip cisco-phone
C.
Router(config)#auto qos voip
D.
Router(config)#auto qos voip cisco-phone
What is the correct command used to configure loop-start signaling on an FXS port? A. Router(config-voiceport)#dial-type loopstart
flast.indd xxx
B.
Router(config-controller)#dial-type loopstart
C.
Router(config-controller)#signal loopstart
D.
Router(config-voiceport)#signal loopstart
9/20/11 10:56:09 AM
Assessment Test
6.
xxxi
Which of the following is not a feature of a Cisco Unified Border Element (CUBE)? A. Call admission control (CAC) B.
7.
Secure deployment
C.
IP address hiding
D.
Zone management
Dr. Nyquist discovered that analog samples taken at times the highest frequency would produce high-quality sound when reconstructed using only the taken samples. A. Three B.
8.
Two
C.
Five
D.
Four
Which of the following is not a voice gateway signaling protocol? A. MGCP B.
9.
SCCP
C.
Q.931
D.
H.323
What type of voice trunk directly connects a private switch to a public switch? A. CO trunk B.
Interoffice trunk
C.
Tie trunk
D.
Tandem trunk
10. What H.323 device maintains a database of telephone extensions to IP address mappings? A. Proxy server B.
MCU
C.
Gateway
D.
Gatekeeper
11. A phone call enters a voice gateway. What happens if no incoming dial peer is matched? A. The call is routed out the PSTN by default.
flast.indd xxxi
B.
The call is dropped.
C.
The voice gateway sends a redirect signal to the calling phone.
D.
The call will match the default dial peer.
9/20/11 10:56:10 AM
Assessment Test
xxxii
12. How are the voice and native data VLANs treated differently on the link between the Cisco switch and the Cisco IP phone? A. The voice VLAN is tagged using 802.1Q and the data VLAN is not tagged. B.
The voice VLAN is tagged using ISL and the data VLAN is tagged using 802.1Q.
C.
The voice VLAN is not tagged and the data VLAN is tagged using ISL.
D.
The voice VLAN is not tagged and the data VLAN is tagged using 802.1Q.
13. The following destination pattern is configured in a dial peer: Router(config-dial-peer)# destination-pattern 34.?
Which of the following dial strings will be matched? (Choose all that apply.) A. 3484 B.
34
C.
342
D.
3433
14. According to the ITU-T G.114 specification, packet delay for voice should not exceed ms. A. 30 B.
50
C.
150
D.
250
15. What is the correct configuration command for setting a voice gateway to use ISDN switch type primary-5ess? A. Router(config)#isdn switch-type primary-5ess B.
Router(config-controller)# isdn signaling switch-type primary-5ess
C.
Router(config-controller)# isdn switch-type primary-5ess
D.
Router(config)# isdn signaling switch-type primary-5ess
16. What voice gateway feature replaces lost packets with ones that are intelligently generated? A. PESQ B.
DSP
C.
PLC
D.
iSAC
17. What codec quality tool has been developed to better test and grade next-generation codecs that use wideband? A. MOS
flast.indd xxxii
B.
POLQA
C.
PSQM
D.
PESQ
9/20/11 10:56:10 AM
Assessment Test
xxxiii
18. Which of the following are limitations inherent in loop-start signaling? (Choose all that apply.) A. It is unable to properly transition on-hook for inbound calls when FXO interfaces are used. B.
Glare.
C.
It is unable to properly transition off-hook for inbound calls when FXO interfaces are used.
D.
Gleam.
E.
It is unable to properly transition on- or off-hook for inbound calls when FXO interfaces are used.
19. What FXS config-voiceport command can be used to adjust the analog ring tone? A. ring frequency B.
ring cadence
C.
ring type
D.
cptone
20. How many simultaneous calls can an E1 CAS circuit support? A. 24 B.
31
C.
32
D.
30
21. Which of the following commands can be used to verify the line coding of a T1 interface? A. show voice port B.
show voice port summary
C.
show controller t1
D.
show interface
22. When an H.323 gatekeeper receives an ARQ message from a registered H.323 device, what two decisions does the gatekeeper make about a requested call? A. What codec should be used B.
What type of H.323 device is attempting to make the call
C.
Whether the call is permitted to go through
D.
How the call should be routed
23. What voice signaling protocol is used by default when configuring dial peers on a router with an IP voice gateway IOS? A. SIP B.
flast.indd xxxiii
SCCP
C.
H.323
D.
MGCP
E.
SIPv2
9/20/11 10:56:10 AM
xxxiv
Assessment Test
24. Which of the following best describes an on-net to off-net call? A. An internal user calling a telephone accessed through the PSTN B.
An internal user calling a remote site through the secondary PSTN path during a WAN failure
C.
An external user calling a remote site through the secondary PSTN path during a WAN failure
D.
An internal user calling a telephone accessed through the IP WAN
25. Which of the following is a common reason for adjusting the maximum number of SIP retries? A. If a high-compression codec is being used. B.
If the network is unreliable.
C.
If the SIP gateway connects to an ISDN circuit.
D.
If the SIP gateway accepts both TCP and UDP messages.
26. You are reviewing a router’s configuration and see the following: ephone 1 mac-address 0033.1c43.2533 type 7965 codec g729r8 button 1:1 What does the codec g729r8 command mean? A. This ephone will operate only with the codec specified. B.
This is the preferred codec for the ephone.
C.
This is the only codec that the IP phone understands.
D.
DSP resources have been specifically set aside for this ephone.
27. Voice packets reach the destination IP phone with a delay variance between 15 and 50 ms. What is the result? A. The packets will be dropped.
flast.indd xxxiv
B.
Queuing buffers in the phone will smooth out any jitter.
C.
The destination phone will reject the call by sending back a reorder signal to the calling party.
D.
The stream may sound garbled because it exceeds best-practice limits.
9/20/11 10:56:11 AM
Assessment Test
xxxv
28. When viewing show ephone output like the following, what does SEIZE mean on the extension? ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 16 max_line 6 button 1: dn 2 number 4002 CH1 SIEZE Preferred Codec: g711ulaw Active Call on DN 2 chan 1 :4002 0.0.0.0 0 to 0.0.0.0 0 via 0.0.0.0 G711Ulaw64k 160 bytes no vad Tx Pkts 0 bytes 0 Rx Pkts 0 bytes 0 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn -1 A. The phone is currently in a call. B.
The phone is on-hook.
C.
The phone is off-hook and unregistered.
D.
The phone is off-hook.
E.
The phone is receiving a call.
29. CAMA interfaces physically connect to what destination? A. A PBX B.
The PSTN
C.
The PSAP
D.
A DID
30. Which of the following correctly configures a call-block profile (called block_976) for incoming calls on a POTS dial peer? A. call-block translation-profile block_976 incoming B.
call-block translation-profile incoming block_976
C.
translation-profile call-block incoming block_976
D.
translation-profile call-block block_976 incoming
31. What two methods are used to transmit RAS location messages? A. Round-robin B.
flast.indd xxxv
Sequential
C.
FIFO
D.
Blast
9/20/11 10:56:11 AM
Assessment Test
xxxvi
32. Which of the following QoS variable-delay reduction techniques might use CBWFQ? A. Prioritize time-sensitive traffic B.
Link fragmentation and interleaving
C.
Compression
D.
Bandwidth upgrades to eliminate bottlenecks
33. What markings can Cisco Catalyst L2 switches use to enforce QoS? A. DSCP B.
IP Precedence
C.
CoS
D.
RSVP
34. When configuring MQC, what command is used to associate traffic class types with one or more QoS operations? A. class-map B.
policy-map
C.
traffic-map
D.
qos-map
35. Which telephony edge device converts voice into a binary stream? A. PBX B.
Digital telephone
C.
CO trunk
D.
Tie trunk
36. What must be carefully watched when cRTP is configured between two voice gateways? A. Packet fragmentation B.
Gateway CPU utilization
C.
Packet delay
D.
Packet jitter
37. What is the process of translating between two different codecs? A. Transcoding B.
MTP
C.
Translation
D.
DSP
38. What is the proper name for the international numbering plan that was developed by the ITU? A. G.711 B.
flast.indd xxxvi
NANP
C.
E.164
D.
E.711
9/20/11 10:56:12 AM
Answers to Assessment Test
xxxvii
Answers to Assessment Test 1.
A. As soon as you have implemented AutoQoS for the Enterprise policies, you no longer need to waste CPU resources by keeping the discovery phase running on an interface. To disable the autodiscovery process, you should go into interface configuration mode of each interface the processes is running and issue the no auto discovery qos command. See Chapter 12.
2.
A, B. Both the h245-alphanumeric and h245-signal DTMF relay methods convert tones to ASCII for transmission on IP networks. See Chapter 9.
3.
C. The best choice would be the inter-networking of services model because of the distributed nature of the multisite network and the fact that the WAN links (3 Mbps) are likely to be too small to transport voice traffic to a centralized call-processing agent. See Chapter 1.
4.
A. The correct syntax for AutoQoS for VoIP on a router is auto qos voip. This command is performed while in interface configuration mode. See Chapter 12.
5.
D. Because an FXS port is an analog connection, you will be in config-voiceport mode. The correct command while in this mode is signal loopstart. See Chapter 2.
6.
D. Zone management is a feature of an H.323 gatekeeper and not a CUBE. See Chapter 10.
7.
B. Sampling at a rate of twice the highest frequency to be represented follows the Nyquist sampling theorem. See Chapter 2.
8.
C. Q.931 is not a voice gateway signaling protocol. See Chapter 3.
9.
A. A CO trunk is the name used to describe a circuit that connects a private PBX switch to a public switch at the central office. See Chapter 1.
10. D. An H.323 gatekeeper is a server that maintains a database of telephone extensions to IP address mappings. Before a call is made, the gatekeeper must be queried to identify the location of the destination H.323 endpoint. See Chapter 3. 11. D. If a call is not matched against configured incoming dial peers, it is matched against the default dial peer (dial peer 0) and processed accordingly. See Chapter 4. 12. A. Voice VLANs are tagged with 802.1Q and the native data VLAN is left untagged. See Chapter 8. 13. B, C. The . means that any digit can be used. The ? means that the previous digit or group will occur 0 or one time. That means that 34 and 342 will be the two choices that match this destination pattern. See Chapter 4. 14. C. The ITU-T recommends that end-to-end delay should not exceed 150 milliseconds for voice packets. See Chapter 5. 15. A. The ISDN switch type is configured globally in config mode. The correct command is isdn switch-type primary-5ess in order to set the ISDN switch the voice gateway will connect to. See Chapter 2.
flast.indd xxxvii
9/20/11 10:56:12 AM
xxxviii
Answers to Assessment Test
16. C. Packet loss concealment is a software process that replaces lost packets with ones intelligently derived by the router. See Chapter 5. 17. B. The Perceptual Objective Listening Quality Analysis tool is an ITU-T standard that is being developed to test and score high-fidelity codecs. See Chapter 5. 18. B, C. Glare can be a big problem for telephone loop-start users who make and receive frequent telephone calls. Also, there is not a proper way for FXO ports to properly go off-hook at the end of a call that came inbound on the interface. See Chapter 2. 19. B. The ring cadence command is used to adjust the ring tone. See Chapter 6. 20. D. Although it uses robbed-bit signaling, an E1 CAS circuit uses 2 of its 32 channels for framing and synchronization. Therefore it can support up to 30 simultaneous calls. See Chapter 2. 21. C. The show controller t1 command displays configuration information for T1 and E1 ports. See Chapter 6. 22. C, D. When an H.323 device attempts to make a call that utilizes an H.323 gatekeeper, that call request goes to the gatekeeper. The gatekeeper fi rst determines if the call is permitted and then uses the E.164 destination address to determine what IP address the call should be routed to. See Chapter 10. 23. C. H.323 is the default voice gateway signaling protocol. If you want to use a different signaling protocol, you must manually specify it. See Chapter 7. 24. B. On-net to off-net calls occur when a call is made to a remote site but for some reason the call cannot be completed on the IP WAN. A secondary path is used to establish the call instead using the PSTN network. See Chapter 4. 25. B. If your network is prone to packet drops and/or congestion, it is common to raise the maximum number of SIP retry messages to help ensure that SIP messages are properly received between endpoints. See Chapter 7. 26. B. The codec command specifies the preferred codec for an ephone when this phone is calling another phone that is also configured on CUCM Express. The command can be used while configuring individual ephones. See Chapter 8. 27. D. The maximum jitter is 30 ms between voice packets. Because this call exceeds those limits, the result may be a voice stream that sounds garbled at the destination phone. See Chapter 11. 28. D. When a user picks up the phone handset, the phone goes into an off-hook state. This is referred to as a line seizure. See Chapter 8. 29. C. CAMA interfaces are used to connect to the PSAP for E911 calling. See Chapter 6. 30. B. The proper syntax is call-block translation-profile incoming block_976. This command is performed while in config-dial-peer configuration mode. See Chapter 9.
flast.indd xxxviii
9/20/11 10:56:12 AM
Answers to Assessment Test
xxxix
31. B, D. The sequential method sends an LRQ to remote gatekeepers one at a time and waits for a response before sending another message. The blast method sends LRQ messages to all remote gatekeepers at one time. See Chapter 10. 32. A. Traffic prioritization techniques can use CBWFQ as a way to segment traffic on a network and give one class higher priority over another. See Chapter 11. 33. C. Cisco Layer 2 switches can read and enforce QoS using CoS markings found in Ethernet frames. See Chapter 11. 34. B. The policy-map command associates traffic classes (segmented using class maps) and applies QoS operations to them. See Chapter 12. 35. B. The two types of traditional telephony edge devices are analog and digital telephones. Digital telephones take an analog stream and digitize it for transport. See Chapter 1. 36. B. cRTP is very CPU intensive and can cause the CPU to spike, which can end up causing packet drops. See Chapter 3. 37. A. Transcoding is the process of translating between two codecs. DSP resources are used to offload transcoding. See Chapter 5. 38. C. The ITU International numbering plan is formally known as E.164. See Chapter 4.
flast.indd xxxix
9/20/11 10:56:13 AM
flast.indd xl
9/20/11 10:56:13 AM
Chapter
1
An Introduction to Traditional Telephony and Cisco Unified Communications THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the components of a gateway. ■
Describe the function of gateways.
Describe a dial plan. ■
c01.indd 1
Describe a numbering plan.
9/21/11 12:09:10 PM
Evolution is the process of something changing over time into a more complex state where it can better adapt to its environment. Evolution typically is triggered only when outside forces require changes to be made. Technology also evolves into newer and more useful tools over time. While the analog phone is still around, advances have been made and telephones have evolved into fully digital devices. Even more recently, we’ve seen more and more voice running over IP networks that share the same cabling and routing functions with data networks. But throughout this telephone evolution process, many of the traditional interfaces, signaling protocols, and setups remain unchanged. In order to understand voice networks of today, we must fi rst take a step back in time to discuss traditional telephony topics. Once you have a solid foundation, you can see how many of these elements have either remained the same or evolved over time to improve voice networks as they transition from circuitswitched networks to packet-switched networks. Chapter 1 will start off covering traditional telephony devices. This includes legacy analog and digital phones as well as a look at components within public telephone networks. We will then move on to the two private telephone network types in most organizations. Lastly, this chapter will cover Cisco’s take on IP telephony networks and how it breaks down components into separate functionality categories and deployment models.
Understanding Traditional Telephony Components In 1875, Alexander Graham Bell invented the telephone, a device that transmits and receives sound, most commonly human speech. The telephone houses a microphone that callers speak into. With a standard analog telephone, the speech is then transported across a pair of copper wires in the form of an electrical signal. As the popularity of telephones grew, companies began providing a telephone network that was used to interconnect multiple phones throughout a region. Today, public telephone networks are a mixture of analog and digital circuits and trunks that interconnect and cover the globe. Telephone systems can be split into public and private sections. The private side consists of equipment owned and maintained by an individual user or business. The public side is owned and maintained by the telephone company, and this service is paid for by the
c01.indd 2
9/21/11 12:09:11 PM
Understanding Traditional Telephony Components
3
individual or business owner who wants to use public phone services. The public switched telephone network (PSTN) is the network that interconnects telephones found in homes and businesses throughout towns, cities, countries around the world. It used to be that the PSTN consisted solely of analog circuits. The fi rst analog circuit was just two wires, and it was responsible for carrying a single telephone call. As technology improved, both the public- and private-side equipment became more sophisticated. Private businesses could own and maintain their own phone switches. These phone switches could then be interconnected by trunk lines that were specifically designed for the transport of voice services between phone switches. In this fi rst section, we will investigate the traditional telephony components that make up the private and public telephone network.
Telephony Edge Devices The edge is the part of the phone system that end users interact with to make and receive calls in their purest form. Traditional telephony edge devices can be divided into two categories: analog and digital telephones. But even traditional telephony devices have evolved to include more advanced features to make the calling experience a better one. Here is a closer look at each of these phone types.
Analog Telephones Analog edge devices are still somewhat common in homes and small business environments. The analog telephone is commonly directly connected to the PSTN, so all of the backend intelligence is the responsibility of the service provider, and the phone user is simply responsible for purchasing and maintaining their analog telephone, which is a very simple device. Some businesses still use analog PBX (private branch exchange) systems, although they are becoming rare. Connecting an analog phone to a PBX provides additional capabilities to the phone such as voicemail with message-waiting indicators, call hold, and personalized ringtones. Other than that, the features of analog telephones are very limited.
Digital Telephones Digital telephone devices use special hardware to convert analog voice streams into a digital data stream. Most legacy PBX systems are digital. It is also important to note that the digital handsets of most of these digital PBX systems are proprietary. It is rare to be able to mix and match different digital phones within a single digital PBX.
Phone Switches On the public side of the overall telephony, there are public phone switches and private phone switches. A PBX or key system can be installed by a private party to provide a multitude of private telephone services to phones located within this private network. The differences between a PBX and a key system are detailed later in this chapter. Extension-to-extension
c01.indd 3
9/21/11 12:09:12 PM
4
Chapter 1
■
An Introduction to Traditional Telephony and Communications
dialing, multiple lines, voicemail, call waiting, and call forwarding are just a few of the services that private switches can provide. A private switch does nothing when a call needs to be placed to a phone that is located outside the private network. This is where a connection to the PSTN comes into play. Privately owned phones and/or private switches connect to public telephone switches. These switches handle public call routing and signaling.
The Central Office A PSTN central office is the fi rst major stop where a public telephone line terminates. Central office (CO) is a term used to describe a geographically located office that houses PSTN switch equipment. Home and business lines are run back to the central office and connect to the PSTN switches. The CO has large trunk lines that further multiplex the phone lines and interconnect this central office with the larger national and global telephone network. In spite of the name, most modern central offices are not really offices at all but underground bunkers of sorts. The switches and cabling are built underground for two main reasons:
To help protect the cabling and switch equipment from lightning strikes
To limit the amount of electromagnetic radiation emitted by the lines and equipment, which can interfere with analog radio and over-the-air television signals
To better understand where the CO fits into the PSTN, imagine that you are at your office and need to call a customer of yours who is right down the street. Their telephone number is 555-1717. If you are connected to the same CO (which is likely), then your call would be directed out of your office on the PSTN line and reach the central office switch equipment. That switch equipment would then look up the destination number of your customer and discover that the destination terminates within the CO. The switch would then use telephony signaling protocols to complete the connection and ring your customer’s phone, as shown in Figure 1.1.
F I G U R E 1 .1
A PSTN call within the same central office
555 -1
717
Calling party
1717
555-
PSTN central office
Called party
c01.indd 4
9/21/11 12:09:12 PM
Understanding Traditional Telephony Components
5
CO switches can also be compared to IP routers in a sense. From an IP router perspective, packets enter a router interface, and they contain an IP address that identifies the destination device. The router uses the IP address to perform a routing table lookup to see which router interface is the shortest path to the destination. A CO switch is similar in that it too contains a table. But instead of IP addresses, the table consists of telephone digits. These digits have a hierarchical structure similar to IP addresses. A hierarchical structure helps to reduce the lookup table size and makes decision making faster and more efficient. When calls enter a switch, the destination number is efficiently matched within the CO switch lookup table.
The Local Loop The local loop is the physical connection that connects a customer’s private telephone equipment to the PSTN central office. The loop is typically copper wiring and carries single phone lines or multiple lines in the form of T1/E1 connections. The local loop is sometimes referred to as the “outside plant” in very large businesses with multiple connections to the CO.
Figure 1.2 shows an example of a business that has its private telephone equipment connecting to the PSTN CO through the local loop wiring.
F I G U R E 1. 2
A local loop
Local loop
PBX
PSTN demarc
PSTN Central office
The customer’s site has a termination point called the demarcation point (demarc). This point separates the customers’ house wiring from the PSTN’s wiring and assigns the physical cabling responsibilities accordingly. If a problem occurs on the PSTN lines, the PSTN may visit the customer’s site and will troubleshoot up to the demarc. If the problem is on the customer’s side of the demarc, it is the responsibility of the customer to fi x.
c01.indd 5
9/21/11 12:09:13 PM
6
Chapter 1
■
An Introduction to Traditional Telephony and Communications
Trunks Traditional telephony trunks are circuits that interconnect voice switches. There are three distinct types of trunk lines:
Tie trunks
Central office trunks
Interoffice trunks
The trunks themselves are similar for the most part except for the types of phone switches (either public or private) they interconnect with. The following sections describe each telephony trunk type in more detail.
Tie Trunks A tie trunk (or tie line) is a dedicated voice circuit that directly connects two PBX switches. This point-to-point connection is commonly used within private organizations to tie multiple telephone systems together, as shown in Figure 1.3.
A tie trunk
4
F I G U R E 1. 3
4 10 Tie trunk
4104
Calling party
4104
PBX-A 3XXX
PBX-B 4XXX
Called party
So why would a business ever need to have more than one PBX? There many reasons, but these are some of the more popular ones:
Migrating from one PBX system to another
A merger of two or more businesses resulting in the need to combine PBX systems
A business or organization with multiple voice management groups that control their own independent PBX systems
As a CVOICE candidate, you probably have an IP networking background, so these reasons can be best compared to the migration and merging of IP networks. For example, a merger between two separate PBX systems is similar to a merger of two separate IP networks. The networks may not use the same routing protocols and therefore must either be reconfigured so they use the same routing protocol or configured to redistribute into one another. At a very high level, the same challenges found in migrating two IP systems are
c01.indd 6
9/21/11 12:09:14 PM
Understanding Traditional Telephony Components
7
similar to merging two PBX systems. In both situations, similar planning methodologies are required to successfully merge the two systems.
Central Office Trunks Central office trunks are the circuits that connect a private business PBX to the PSTN. When organizations have large PBX systems, having many users increases the number of simultaneous calls, which requires multiple outside lines to the PSTN. The most efficient and economical method is to have a trunk connection from the private PBX to the local PSTN CO switch, as shown in Figure 1.4.
F I G U R E 1. 4
A CO trunk External calls CO trunk External calls
Calling party
PBX PSTN Central office
Again, keep in mind that the physical wiring between the private PBX and the CO is known as the local loop. In a large-business scenario, the local loop can be also referred to as the central office trunk.
Interoffice Trunks Interoffice trunks are the backhauled connections that interconnect central offices. Central offices that are connected with interoffice trunk lines are considered to be interexchange connections. It’s easiest to understand interoffice trunks in terms of local vs. long-distance charges; a call whose routing goes no higher than an interoffice trunk is considered local. For example, imagine you are in your office and need to call someone on the other side of the city with the number 555-1717. You pick up the phone and dial the 7-digit (or sometimes 10-digit) number. The dialed digits (known as DTMF, or dual-tone multi-frequency, as discussed in Chapter 2, “Understanding Analog and Digital Voice”) are interpreted by your local CO telephone switch, which determines that the destination phone does not reside within the local CO but at a CO that is accessible through an interoffice trunk connection. The phone switch seizes one of the lines on the interoffice trunk and communicates with the neighboring CO switch to help terminate the call at the correct phone across the city. Figure 1.5 depicts the call process flow using an interoffice trunk between COs.
c01.indd 7
9/21/11 12:09:14 PM
8
Chapter 1
An Introduction to Traditional Telephony and Communications
An Interoffice trunk connection
55 5
F I G U R E 1. 5
■
17 -17 Interoffice trunk
555-1717
555-1717 PBX 4XXX
Calling party
PSTN Central office
PBX 4XXX PSTN Central office
Called party
This type of interoffice trunk would likely be considered a local call instead of a long-distance call because the call uses the interoffice trunk line to complete the call as opposed to moving farther up the PSTN hierarchy. In North America, it used to be that local calls were strictly defi ned by the area code they belong in. Only 7-digit dialing was considered to be a local call and therefore did not incur long-distance charges. Over time, and due to the U.S. government stepping in and breaking up the AT&T monopoly, it became obvious that the area code method for determining local vs. long distance would not be able to function in the future, for two reasons:
The deregulation of AT&T by the U.S. government meant that the FCC must decide what would and would not be considered a long-distance call. The FCC came up with the concept of Local Access and Transport Areas (LATAs). These LATAs were supposed to be used by the newly formed “Baby Bell” companies to determine what was considered long distance and what was not. LATAs were broken up mainly by population and oftentimes overlapped state lines. LATAs oftentimes broke cities and towns into multiple zones that would have necessitated the need for a long-distance call that may have been right across the street.
The rapid growth of telephone number usage in large cities required multiple area codes to overlap in a single geographical area. It became possible that a telephone in one office might have a different area code than a different telephone in the same building. No longer did area codes actually mean a different geographical area as they were fi rst intended.
Because of the LATA and overlapping number confusion found in the U.S. telephone numbering system, you will fi nd that certain 10-digit dialing is now considered to be local.
National and International Calling PSTN For the bigger picture, we need to distinguish between, local, long distance, and international long distance. This network setup varies from country to country, but at its core, there is a three-step PSTN hierarchy, as shown in Figure 1.6.
c01.indd 8
9/21/11 12:09:15 PM
Understanding Private Telephony Phone Systems
F I G U R E 1.6
9
The PSTN local-to-international hierarchy
Local to International call flow
International network (international long distance)
Interexchange network (long distance calling)
Central office (local calling)
Telephone calls between COs that have interoffice trunks are considered to be local calling. If the telephones are on different networks that are not interconnected using interoffice trunks but fall within some type of border (such as by phone company, state, or nation), the call is considered to be at the next level of the PSTN hierarchy, called the interexchange network. Typically, long-distance charges begin to apply. Lastly, if the call is placed between two international borders, it is considered to fall within the highest level of the PSTN hierarchy, called the international network. International long-distance charges begin to apply at this level.
Understanding Private Telephony Phone Systems In a business environment with multiple employees, you will quickly see that having individual telephone lines run in from the PSTN is not the most efficient or economical method for providing voice services. It would be extremely rare to find a time when every employee needed to access the PSTN at once. In fact, calculations show that the telephoneto-PSTN line ratio is quite low. Therefore, business environments often implement some sort of intelligence that allows multiple employees to have their own telephone handsets while sharing PSTN lines. The two traditional telephone systems available are the key system and the PBX. The next two sections briefly explain the differences between these two systems.
c01.indd 9
9/21/11 12:09:15 PM
10
Chapter 1
■
An Introduction to Traditional Telephony and Communications
Key System Very small businesses may choose to implement a key system, which is a simpler solution and easier to manage than a PBX but offers fewer features. All of the telephone handsets in a system are identical, and each phone shares the same small group of PSTN external numbers, indicated by lights and selected by pressing buttons. Key systems do not assign unique telephone numbers to individual phones. This ensures that anyone in the office can answer an incoming call to any line. The key system is often called a shared-line system, because of how lines are configured on the phones.
PBX A private branch exchange (PBX) system is similar to PSTN switches owned and operated by the PSTN. In fact, many PBX systems found in very large organizations use identical switching equipment. Traditionally, businesses with employees of 20 or more will choose to implement a PBX because of the more advanced features available to end users and the scalability to grow both internally by adding additional handsets and externally by connecting to other PBX systems using tie trunks or to the PSTN using CO trunks. While PBX systems can either be analog or digital in nature, most legacy PBX systems in use today use a digital transport method. One of the major usage differences between PBX and key systems is where the calls that originate within them are going. With key systems, because the businesses are typically small, very few internal-to-internal calls are made. By contrast, a large percentage of calls made on a PBX system are employee-to-employee calls. That is why it is very common for PBX systems to use truncated numbers for internal dialing. These truncated numbers are called extensions and are typically three to five digits in length.
When Is It Time to Upgrade a Key System? Kevin began his language service business back in the spring of 1998. When his business was just starting up, his only employees were himself and four other persons, who each took a portion of the sales and accounting duties. Kevin decided at that time to implement a key system. To Kevin, this was a logical choice because he needed only three phone lines for all his calls. Each employee had all three telephone numbers configured on their phone. When a call came inbound from the PSTN (which was rare), any one of the employees could answer the line. If the caller needed to speak to someone directly, it was a simple process of placing the call on hold and yelling to the other side of the small office for the proper person to pick up the line. Over the years, Kevin’s business grew and with it the office space and number of employees. The key system continued to be sufficient until an interesting phenomenon
c01.indd 10
9/21/11 12:09:16 PM
Understanding the Unified Communications Model
11
occurred. After a while, the inbound calls that were directed to a specific employee increased significantly. This is because as the business grew, employees became specialists in a specific part of the organization. No longer could any employee handle any request. In addition, as the number of employees increased, a need arose to have individual voicemail boxes, which a key system cannot handle, because no employee has a dial-in number or extension. Because of this, Kevin had to migrate to a new Cisco CUCM Express solution, which he implemented as a PBX switching system. Now Kevin has the PBX set up so each one of his 22 employees has their own unique telephone extension to make and receive both internal and external calls. The migration from a key system to a PBX system let Kevin’s business better adapt to growth.
Understanding the Unified Communications Model The Cisco CVOICE exam requires that students have a basic understanding of the end-to-end Cisco components involved in Internet Protocol Telephony (IPT), which is a method used to transport voice communications over an IP network, and Voice over IP. Cisco groups its components into four categories:
Endpoints
Applications
Call processing agents
Network infrastructure
Endpoints Cisco has a plethora of both hardware- and software-based IP phones for nearly any voice situation. In Cisco’s Unified Communications model, an endpoint can be any end device or software that interacts with Unified Communications hardware and/or software. This is because Cisco lumps together multiple communications methods, including voice, videoconferencing, and instant messaging, under one umbrella of services. The following section is meant to give a broad overview of many of the different product features. It is not a complete list of all of the phones available, however. These models are also continuously being updated. While Cisco does not make analog telephones, it does offer hardware
c01.indd 11
9/21/11 12:09:16 PM
12
Chapter 1
■
An Introduction to Traditional Telephony and Communications
solutions that convert analog into IP for use on modern networks. This section examines the following categories of IP phone endpoints:
Wired IP phones
Wireless IP phones
Software IP phones
Videoconferencing phones
Analog-to-IP adapters
This should give you an understanding of the wide spectrum of Unified Communications devices available for implementation.
Wired IP Phones When most people think of IPT, the first type of IP phone endpoints that they think of are standard wired IP phones. This is likely because they most closely resemble analog telephones of old. However, newer IP phones are beginning to look more like computers than telephones, with the LCD displays, soft keys, and user-programmable features. Cisco divides its wired IP phone systems into two major categories: small-business and enterprise-class phones.
Wired IP Phones for Small Business Cisco’s small-business IP phones include the SPA 300 and 500 series. These entry-level phones are designed to work only with the Cisco Communications Manager Express call agent solution. They are part of the Cisco Smart Business Communications System (SBCS) suite of products and fully interoperate with products such as the UC500 series CUCM Express and Unity Express voicemail products. This is because the phones specifically support the Cisco proprietary Smart Phone Control Protocol (SPCP), which only the UC500 series platform call agents support. In addition, the 300 and 500 series phones also support the Session Initiation Protocol (SIP) for call signaling on an IP network for connecting to an Internet Telephony Service Provider (ITSP). An ITSP is a fairly new service in which small businesses can pay a monthly fee to have a service provider manage the backend IPT hardware while enjoying the added features and cost savings that IP phones provide over PSTN solutions. All that is needed is a high-speed Internet connection to the ITSP. Calls are routed to the ITSP across the Internet, and the ITSP then routes calls out to the PSTN on its end.
Wired IP Phones for the Enterprise The majority of Cisco IP phone offerings can be found in the enterprise class of hardware. These X900 phones are further categorized by a numbering system in which X is the number of a specific series. Within these categories, there are minor differences between the features the individual phones offer. As of the writing of this book, the enterprise-class IP phones include the following:
c01.indd 12
9900 series
8900 series
7900 series
9/21/11 12:09:17 PM
Understanding the Unified Communications Model
6900 series
3900 series
13
Each of these phone series is designed to meet a specific market niche. For example, the 3900 series phones offer basic functionality and do not include many of the add-on bells and whistles that some of the high-end models tout. Cisco markets this line of phones for use in lobbies, manufacturing floors, and retail-outlet floors where a basic-use phone may be needed by employees and people in public-access areas. It is not necessary to know all the wired/wireless IP phones that Cisco offers. There simply are too many to list here, so we chose to discuss only the most unique. If you want to investigate all of Cisco’s IP phone offerings, you can refer to Cisco’s IP phone product web page at http://www.cisco .com/en/US/products/sw/voicesw/index.html#~all-prod and begin your research under the “IP Communications” section.
Wireless IP Phones The Cisco 7900 series of phones offers the majority of different models. This includes the two models of wireless IP phones currently: 7921G Wireless IP Phone
This phone can operate on 802.11a/b/g networks.
7925G and 7925G-EX Wireless IP Phones These phones can operate on 802.11a/b/g networks. In addition, they offer Bluetooth 2.0 support and a hermetically sealed and ruggedized case for heavy-use situations.
Unified Communications IP Soft Phones Cisco has several software-based IP phones that let users make and receive voice calls on computer hardware. The requirements are a compatible PC, a microphone, and speakers/headphones. Once one of the following applications is installed and connected to a compatible version of Cisco Unified Communications Manager (CUCM) server, you can make and receive phone calls without an actual telephone handset. Here are the three primary Cisco software IP phones available: Cisco IP Communicator This software-based IP phone behaves just like a 7970 hardwarebased phone. That means that everything a hardware phone can do, the IP Communicator can do as well. The application can be installed on Microsoft Windows XP, Vista, and Windows 7 operating systems. Cisco Unified Personal Communicator This software application integrates, voice, voicemail, instant messaging, and other features into a single application that can be installed on the latest Microsoft Windows and Mac OS–compatible computers. Cisco Unified Mobile Communicator With the increased mobility of business phone users, thanks to 3G and 4G availability, Cisco created the Unified Mobile Communicator software package to run on popular smartphones such as Apple’s iPhone and the RIM Blackberry. The software lets users interact with the Cisco Unified Communications
c01.indd 13
9/21/11 12:09:17 PM
14
Chapter 1
■
An Introduction to Traditional Telephony and Communications
platform remotely to accomplish tasks such as retrieve missed calls, join MeetingPlace conferences, and even make and receive calls on a mobile phone, giving the impression to the called/calling party that you are making the call from your desk phone extension. Not only does the Mobile Communicator software make life easier on the mobile user, but it can also dramatically decrease mobile phone bills by limiting roaming charges, because calls made and received through the software run through the office telephony infrastructure over the phone’s wireless data connection.
Video Phones and Tablets Some hardware- and software-based phones integrate voice and video. The four primary Cisco endpoints in this category are as follows: 7985G IP Video Phone This phone features a large, color LCD display and built-in high-resolution camera for videoconferencing to other 7985G phones as well as all of Cisco’s other video hardware and software applications. 9951 IP Video Phone This phone features a touchscreen color display, built-in high-resolution camera for videoconferencing and collaboration applications, and Ethernet or Wi-Fi connectivity. Cisco Video Advantage This products works with the Cisco VT Camera II USB hardware to make and receive videoconference calls on a desktop PC running Microsoft Windows software. The VT Camera II plugs into a PC through a USB port. Users make and receive the video calls using their Cisco Unified IP desktop phones or the Cisco IP Communicator software installed on the same PC as the Cisco Video Advantage software. Cisco Cius Tablet The Cius is a new product from Cisco that combines Unified Communications voice and video functionality with additional PC functionality. The tablet can connect to a Cisco Unified Communications system, either wired or wireless, from inside the enterprise. An optional 3G/4G wireless option is available to use the tablet as a mobile communications tool from outside the office. Figure 1.7 shows the Cisco Cius tablet. F I G U R E 1.7
The Cisco Cius tablet device
Courtesy of Cisco Systems, Inc. Unauthorized use not permitted.
c01.indd 14
9/21/11 12:09:18 PM
Understanding the Unified Communications Model
15
Analog-to-IP Adapters Some people just can’t let go of their analog endpoints for one reason or another. Much of it has to do with the high cost of replacing all phones within a system. Another important reason is that many businesses still rely on analog fax machines for their day-to-day business operations. Cisco has anticipated this and has two major analog-to-IP adapters to get these incompatible systems to interact on an IP phone network. Analog telephony adapters (ATAs) are appliances that have an Ethernet port to connect to an IP LAN. They then have two or more RJ-11 ports for connecting to analog telephones. The appliances then use software to convert the analog signal into a digital IP packet for proper transport on any IP network. The two primary solutions available from Cisco are these: ATA 180 Series These are small point-solution appliances for connecting two analog desk phones, conference phones, or fax machines to an IP network. These devices are good for small businesses or anywhere only two analog phones are needed in one geographic location. VG200 Series The VG200 series appliances are Cisco’s newest analog-to-IP devices that offer additional integration to the Unified Communications features available. The form factors of these stand-alone analog gateways include the ability to connect 2, 4, 24, or even 48 analog devices to a single appliance. The two- and four-port models are scheduled to completely replace the ATA 180 series once the 180 series goes end-of-life. The VG224 and 248 are high-density appliances that run on special IOS software that runs on ISR (Integrated Services Router) equipment.
Applications In addition to the Unified Communications platform calling features, Cisco provides value-added Unified Communications applications that seamlessly integrate into the product lineup. These applications include voicemail functionality with Cisco’s Unity lineup, Emergency Responder for 911 services, conference call applications in the form of the Cisco Conference Connection suite, and billing applications. These add-on telephony applications reside on dedicated hardware and software platforms and bolt into the Unified Communications call processing agents that are described next.
Call Processing Agents Call processing agents are the brains behind IP call-processing and call-control mechanisms on a LAN. From a Cisco prospective, call agents are Cisco Unified Communications Manager solutions. These were previously called Cisco Call Managers. Our discussion of call agents will look at the three different Cisco call agent call-control responsibilities:
c01.indd 15
Call agents are responsible for the setup and teardown of telephone endpoints on the local network.
Call control agents are used for IP telephone endpoint registration to the call agent.
Voice gateways are used to bridge voice networks.
9/21/11 12:09:18 PM
16
Chapter 1
■
An Introduction to Traditional Telephony and Communications
Cisco Call Agent Solutions Cisco offers three primary call agents to handle call processing for small, medium, and large organizations. It is important to know the primary differences between the three solutions. In addition, the 642–437 exam requires that you be able to configure basic settings on the Unified Communications Manager Express. This material is covered in Chapter 8, “Configuring and Managing the CUCM Express,” of this study guide. Here’s a brief look at the three call agent solutions: Cisco Unified Communications Manager Cisco Unifi ed Communications Manager (CUCM) is Cisco’s flagship call agent. It is a hardware appliance that runs on a hardened Linux operating system. The current CUCM version is 8.0, which includes a number of feature enhancements over versions 6 and 7. Each server appliance is capable of handling up to 7,500 endpoints and can be clustered to support up to 30,000 endpoints. Cisco Unified Communications Manager Business Edition Cisco Unifi ed Communications Manager Business Edition (CUCMBE), Cisco’s medium-sized solution, is basically the full-blown CUCM solution except for some key differences. The fi rst is a limit of 500 endpoints on each appliance. It also does not offer the high-availability redundancy features found in the CUCM. One major benefit of the CUCMBE is that it offers an integrated voicemail system, called Unity Connection, which runs on the same hardware as the call agent software. This helps lower customer costs by allowing one piece of hardware to be used for both purposes. Cisco Unified Communications Manager Express The Cisco Unifi ed Communications Manager Express (CUCME) call agent differs greatly from the CUCM and CUCMBE in the fact that the express software runs on Cisco routers. That means that the CUCME runs a specialized version of the Cisco IOS. In addition, specialized cards or interfaces can be installed into Cisco routers for voicemail access using Unity Express software. This solution lets small businesses have a fully functional IP data, voice, and voicemail solution contained in a single appliance. The CUCM Express is geared to small businesses with up to 250 endpoint devices.
Cisco Call Control Agent Solutions Call agents are responsible for handling IP phone endpoint setups so that the phones receive extension numbers and other calling features unique to each phone. The IP phone endpoints register to the call agent and communicate with it each time a call is placed on the network. These are all functions of call control. When a user picks up an IP phone that is registered to a call agent, that phone relies on the call agent for things such as dial tone and other supervisory and informational signals (discussed in Chapter 2). When the end user dials in a telephone number, the address-signaling information is sent from the phone to the call agent. The call processing agent then has various settings and rules in place to either permit the phone to call this number or deny it. For example, if the end user attempts to call an international number on their desk phone, the call agent may deny this request so the business does not incur expensive long-distance charges. If the call is allowed, the call
c01.indd 16
9/21/11 12:09:19 PM
Understanding the Unified Communications Model
17
agent performs signaling between the source IP phone and the voice gateway, as shown in Figure 1.8. F I G U R E 1. 8
Call setup signaling through the call agent
g
alin
M
n Sig
Sig
na
ling
Call agent
V
PSTN Off-network phone
IP phone
From a Cisco hardware perspective, call agents and Cisco IP endpoints can communicate call setup information using either the Cisco proprietary Skinny Client Control Protocol (SCCP) or the IETF-defi ned Session Initiation Protocol (SIP) method. By default, Cisco call agents and most Cisco IP phones are configured for SCCP signaling. Signaling between the call agent and the voice gateway (as shown in Figure 1.8) can be H.323, SIP, MGCP (Media Gateway Control Protocol), or SCCP. Once the call signaling is established between the source and destination phones, the voice stream is transported directly between the phone and the voice gateway, which is the fi nal hop on the IP network before it must be converted for proper transport on the PSTN. The transport of voice on an IP network uses a separate protocol, as shown in Figure 1.9. By using a separate and direct protocol for voice transport, voice packets are sent on the most direct and efficient path. F I G U R E 1. 9
Voice transport
g
alin
n Sig
M
Sig
na
ling
Call agent
V
IP phone
IP voice packet transport
PSTN Off-network phone
The protocol used to transport voice is the Real-Time Protocol (RTP) and is discussed in detail in Chapter 4, “The VoIP Path-Selection Process,” of this book. When the phone conversation is fi nished, both phones will again communicate call control information with the call agent to end the call, just as they did with the setup signaling information shown in Figure 1.8.
c01.indd 17
9/21/11 12:09:19 PM
Chapter 1
18
■
An Introduction to Traditional Telephony and Communications
Cisco Voice Gateway Solutions One major topic of the CVOICE exam is the functions of voice gateways on an IP network and how to configure them. Voice gateways are a critical component of an IP network for several reasons. Primarily, a voice gateway sits on the border between an internal IP voice network and the public switched telephone network or a legacy PBX. Because these two networks are incompatible with each other, it is the responsibility of the voice gateway to translate between them. In order to accomplish this task, the voice gateway uses various hardware ports to connect to the PSTN. It uses special hardware called digital signal processors (DSPs) to translate from one medium to another for proper interoperation. In addition, voice gateways are configured to speak one or more signaling protocols that are used to properly route calls to and from the IP call agent, which may be one of the Cisco Unified Communications solutions described earlier in this chapter. These signaling protocols are as follows:
H.323
SIP
MGCP
SCCP
Each of these protocols has benefits and drawbacks. Careful consideration must be made during the voice network design phase to choose the signaling protocol that best fits the following:
Call agent hardware and software
Voice gateway hardware and software
Legacy hardware that needs to interact with the IP solution
DSPs are also used to facilitate other responsibilities (such as offloading call conferencing duties) for the proper operation of voice on an IP network as well as for value-added features. All of these topics will be covered in depth in Chapters 5, “VoIP Design Options,” and 6, “Configuring Voice Gateway Ports and DSPs.”
Voice Gateway Hardware Components Cisco voice gateways are routers that have special IOS software designed to support voice interface cards and voice signaling protocols. Specifically, voice gateway IOS software operates on some older router platforms, including these:
1700 series
2600XM series
3700 series
In addition, voice gateway IOS runs on newer Cisco Integrated Services Routers (ISRs). These include the following router platforms:
c01.indd 18
1800 ISR series
2800 ISR series
3800 ISR series
9/21/11 12:09:20 PM
Understanding the Unified Communications Model
19
The ISR router series platform is slated to become end-of-life soon and will be replaced by the ISR G2 (Generation 2) series platform as follows:
2900 ISR G2 series
3900 ISR G2 series
While there is a 1900 ISR G2 platform to replace the 1800 series, voice services will not be available. Table 1.1 compares the 2900 and 3900 ISR G2 voice-capable routers and the Unified Communications voice capabilities they offer.
TA B L E 1 .1
Comparison of the 2900 and 3900 series ISR G2 platforms
UC Feature
2900 Series ISR
3900 Series ISR
Conference call support
Yes
Yes
DSP support
PVDM 2/3
PVDM 2/3
Max SRST calls
250
1500
Max SIP sessions
600
2500
Max digital voice calls
400
660
Max FXO ports
40
60
Max BRI ports
24
38
Lastly, voice services can be integrated into large enterprise and service provider hardware, including these series:
1000 ASR series
9000 ASR series
6500 series
7200 series
7600 series
12000 series
AS5400 series
AS5800 series
The actual implementation of voice on the hardware listed here is different from the ISR platform and is outside the scope of this study guide.
c01.indd 19
9/21/11 12:09:20 PM
20
Chapter 1
■
An Introduction to Traditional Telephony and Communications
The primary focus of the CVOICE exam is on the ISR series of router equipment. It is important to understand which equipment is considered to be part of the ISR lineup.
Network Infrastructure The fi nal Unified Communications model component in Cisco’s design is the IP network itself. This consists of standard IP devices, such as routers, layer 2/3 switches, and fi rewalls, that transport both regular IP data and Unified Communications traffic over the same physical network. The major point to note in a Unified network infrastructure is the importance of Quality of Service (QoS) techniques that must be understood and properly deployed to ensure proper transport of time-sensitive traffic such as voice and video.
Unified Communications Deployment Models Cisco presents four different deployment models that it recommends for use within a production network for the entire Unified Communications version 8.X suite. These models have remained fairly static over the years, but the terminology has changed to reflect the fact that Unified Communications offers more than just voice services in today’s networks. Although this section discusses placement of the call processing agents, in reality other UC servers and services can be centralized or distributed to perform the same way for the services they provide. Each deployment has its benefits and potential drawbacks. The primary differences between the four models discussed next depend mostly on the following characteristics:
Number of users supported
Physical location of users
Amount of WAN bandwidth and QoS controls
Ability to offer alternative methods to achieve high availability (HA)
The Centralized Services Deployment Model The centralized services deployment model is ideal when a single building or a group of buildings in a campus is interconnected in a LAN environment. A single call processing agent can be used, or multiple call processing agents can be clustered to provide scalability and high availability to voice services. The benefits of this model derive from having a single administration point with which to manage the Unified Communications (UC) services. A major drawback is the lack of scalability if your UC needs extend outside the single location site. Figure 1.10 shows a typical centralized services deployment model.
c01.indd 20
9/21/11 12:09:21 PM
Unified Communications Deployment Models
F I G U R E 1 .1 0
21
The centralized services deployment model
Campus
PSTN
M
V
The Distributed Services Deployment Model The distributed services model is useful when you have a large campus site and a handful of smaller remote sites that are connected to the primary site using high-speed WAN connections. This model often represents the classic hub-and-spoke look. While this is a great model in many instances, you should plan for high availability in case of a WAN outage. Cisco commonly suggests using either Survivable Remote Site Telephony (SRST) or a CUCME in SRST fallback mode. Both of these features allow the remote sites to route calls to outbound PSTN links in the event of a WAN failure, at which point the remote site cannot access the call processing agent. Figure 1.11 shows the distributed services deployment model. F I G U R E 1 .11
The distributed services deployment model
Branch
Branch
V
V
IP WAN
Campus
M
V
PSTN
SRST
c01.indd 21
9/21/11 12:09:21 PM
22
Chapter 1
■
An Introduction to Traditional Telephony and Communications
The Inter-Networking of Services Deployment Model The inter-networking of services model is used for organizations with multiple large and geographically dispersed locations. In this situation, call processing agents are distributed and located at the various sites and act largely as independent single-site deployments. Local calling therefore never traverses over WAN links, which conserves bandwidth. This model is also useful when WAN links are not reliable or do not have enough bandwidth for handling voice traffic in addition to data traffic. Calling between sites can be sent either across an IP WAN or through the PSTN. Figure 1.12 shows this model, also called multisite with distributed call processing.
F I G U R E 1 .1 2
The inter-networking of services model
Campus
Campus
M
M
V
V
IP WAN
PSTN
Campus
M
V
The Geographical Diversity Deployment Model The fi nal deployment model is the geographical diversity deployment model. In this model, the organization again has multiple geographically dispersed locations with a large number of users. The call processing agents are distributed as in the case of the inter-networking of
c01.indd 22
9/21/11 12:09:22 PM
Summary
23
services model. The difference this time is that the geographical diversity call-processing agents work as a single cluster across interconnecting IP WAN links. As with the distributed services model, it is extremely important to have WAN connections with ample bandwidth and QoS enabled for voice. One benefit in this model is that local site calling is contained within the LAN and does not traverse the WAN. In addition, WAN links in a mesh design can provide some form of redundancy to the point where SRST is not required. Figure 1.13 shows this model, also called clustering over IP WAN. F I G U R E 1 .1 3
The geographical diversity model
Campus
Campus
M
V
M
V
IP WAN
PSTN
Campus
M
V
Cluster
Summary You should now have a solid understanding of the hardware and software components involved in traditional telephony systems. In addition, this chapter covered the two different types of private telephone equipment and when a business might choose to implement a key system or a PBX based on internal vs. external calling patterns. Lastly, we covered Cisco’s IPT component and deployment models. We’ll cover many of these same topics again throughout this book in much more detail. This chapter was written to give you a 30,000-foot view of traditional telephony so that
c01.indd 23
9/21/11 12:09:22 PM
24
Chapter 1
■
An Introduction to Traditional Telephony and Communications
when we cover newer and more advanced topics on voice in future chapters, you’ll be able to understand how the voice network has evolved to the point where it is today. Many things have changed while some things remain the same.
Exam Essentials Know the two different types of traditional telephony edge devices. The two main types of edge devices are analog and digital phones. Besides the obvious difference of handling voice services as analog or digital formats, digital telephones often offer additional service features and are more commonly found in legacy business PBX systems. Know what a phone switch is. Phone switches are responsible for routing calls throughout a voice network. They can be privately owned as is the case with a PBX, or they can be part of the PSTN. Know what a central office is and where it is located in relation to a business. The central office is the fi rst telephone switch that personal and business telephones reach on the PSTN. The physical cabling between the privately owned telephone equipment and the CO is called the local loop. Understand the difference between tie, central office, and interoffice trunks. Tie trunks connect two PBX systems. Central office trunks connect a PBX to the CO. Interoffice trunks interconnect two COs. Understand the three-tiered PSTN hierarchy. The PSTN routes calls based on central office, interexchange, and international networks. The PSTN uses a hierarchical network structure where local calls are routed through the central office, national calls through the central office, and interexchange and international calls through all three tiers—the central office, interexchange, and international networks. Understand the difference between a key system and a PBX. Key systems are used in smaller environments, have few features, and do not have unique extensions. PBX systems are found in large businesses, have many features, and pool external numbers while having unique internal extension numbers. Know the four Unified Communications model tiers and which products fall within each tier. The endpoints tier contains hardware and software the end user interacts with. The applications tier contains various value-added applications used in the UC lineup. The call-processing layer is the brains where call processing takes place. This is where the UC Manager resides. Lastly, the network infrastructure is the IP network equipment that transports voice and data as well as employs QoS. Understand the four Unified Communications deployment models. Know the four models and when they should be implemented. Understand that choosing one model over another depends on several factors, including number of users, physical location of users, amount of bandwidth, and alternative methods to achieve HA.
c01.indd 24
9/21/11 12:09:23 PM
Written Lab 1.1
25
Written Lab 1.1 Write the answers to the following questions: 1.
These PSTN sites house telephone switch equipment that directly connects to personal telephones and/or office PBX switches.
2.
In large environments, the local loop is also called the outside
3.
Name the three types of voice trunks in a traditional telephony network.
4.
What are the four categories of the Cisco Unified Communications model?
5.
What is a private phone system that uses shared-line extensions?
6.
The Cisco IP Communicator software resides in which UC model category?
7.
What hardware interconnects two incompatible voice networks?
8.
A CUCM is also called a
9.
What hardware device allows a user to connect analog telephone devices to an IP network?
.
agent.
10. What UC deployment model is useful when you have a large campus site and a handful
of smaller remote sites that are connected to the primary site using high-speed WAN connections? (The answers to Written Lab 1.1 can be found following the answers to the review questions for this chapter.)
c01.indd 25
9/21/11 12:09:23 PM
Chapter 1
26
■
An Introduction to Traditional Telephony and Communications
Review Questions 1.
What is the name of the first major stop that a public telephone line makes when leaving the customer site? A. Tie trunk
2.
B.
CO trunk
C.
Local loop
D.
Central office
There is a specific point within a customer’s site that defines the physical cabling responsibilities between the private owner and the telephone company. What is this point referred to as? A. Demarc B.
3.
Inside wiring
C.
Outside wiring
D.
Local loop
E.
House wiring
What type of voice trunk directly connects two PBX systems? A. Demarc
4.
B.
Tie trunk
C.
CO trunk
D.
Interoffice trunk
What type of voice trunk directly connects two central offices? A. CO trunk B.
5.
Interoffice trunk
C.
Tie line
D.
Interexchange trunk
Central offices maintain pools of what numbers? A. Subscriber code B.
c01.indd 26
E.164 code
C.
Area code
D.
Interexchange code
9/21/11 12:09:24 PM
Review Questions
6.
27
At what point of the PSTN hierarchy described in this Study Guide will a caller begin incurring long-distance charges? A. Central office
7.
B.
Local loop
C.
International network
D.
Interexchange network
Which Cisco IP phone does not support Cisco’s proprietary SCCP signaling protocol? A. 7925G series wireless phone
8.
B.
SPA 500 series phone
C.
Cisco IP Communicator softphone
D.
All Cisco phones support SCCP
The Cisco Emergency Responder belongs in what UC model category? A. Network infrastructure
9.
B.
Applications
C.
Call processing agents
D.
Endpoints
What is an analog-to-IP adapter used for? A. To translate between analog and IP signaling protocols for proper transport on the PSTN B.
To translate between analog and IP signaling protocols for proper transport on an IP network
C.
To translate between voice and data signaling protocols for proper transport on the PSTN
D.
To translate between voice and data signaling protocols for proper transport on an IP network
10. Which of the following does not reside in the call-processing agent UC model category? A. Call agents B.
PBX agents
C.
Voice gateways
D.
Call control agents
11. Which signaling protocol that is compatible with Cisco IP phones is an IETF standard? A. MGCP
c01.indd 27
B.
H.323
C.
SIP
D.
SCCP
9/21/11 12:09:24 PM
Chapter 1
28
■
An Introduction to Traditional Telephony and Communications
12. Which of the following is not a signaling protocol that can be configured on voice gateways? A. SPCP B.
MGCP
C.
H.323
D.
SIP
13. Which of the following Cisco routers cannot act as a Cisco voice gateway? A. 2900 series ISR B.
1800 series ISR
C.
1900 series ISR G2
D.
2600XM series
14. A 2900 Series ISR G2 with a voice gateway IOS and the proper modules can do all the following functions except what? A. Conference call offloading B.
SRST
C.
Connect analog phones
D.
Emergency Responder offloading
15. At which segment of the Cisco Unified Communications model is QoS handled? A. Network infrastructure B.
Applications
C.
Call processing agents
D.
Endpoints
16. Which of the following is not a consideration when choosing a voice gateway signaling protocol? A. Call agent hardware and software B.
Legacy hardware used
C.
Voice gateway hardware and software
D.
Quality of Service requirements
17. What UC deployment model uses dispersed call agents that act as a single clustered voice system? A. Centralized services model
c01.indd 28
B.
Distributed services model
C.
Inter-networking of services model
D.
Geographical diversity model
9/21/11 12:09:24 PM
Review Questions
29
18. When using the distributed services UC deployment model, what additional feature is often recommended? A. WAN links 5 Mbps or higher B.
SRST
C.
H.323 signaling
D.
MGCP signaling
19. Which UC deployment models recommend QoS on WAN links? (Choose all that apply.) A. Inter-networking of services model B.
Centralized services model
C.
Distributed services model
D.
Geographical diversity model
20. When would a network administrator choose the inter-networking of services model over the other three UC deployment models? A. If there is a single building or campus site and only a few small remote offices.
c01.indd 29
B.
If there are several large dispersed campus sites and WAN links are slow and/or unreliable.
C.
If there are several large dispersed campus sites and WAN links are large enough to handle voice traffic.
D.
If there is a single building or campus site and WAN links are large enough to handle voice traffic.
9/21/11 12:09:25 PM
30
Chapter 1
■
An Introduction to Traditional Telephony and Communications
Answers to Review Questions 1.
D. The central office is a geographically located office that houses PSTN switch equipment.
2.
A. The demarc is the point where the wiring responsibilities are split between the private owner and the phone company.
3.
B. A tie trunk is the name used to describe a circuit that connects two PBX switches.
4.
B. An interoffice trunk is the name used to describe a circuit that connects two PSTN switches located in separate COs.
5.
A. Central offices today have one or more area codes assigned to them and they maintain pools of subscriber code numbers.
6.
D. In the three-tiered PSTN hierarchy, CO-to-CO calling over interoffice trunks would be considered local calling. Long-distance charges would apply if a call needed to be sent to the interexchange network.
7.
B. The Cisco SPA 300 and SPA 500 series phones do not support SCCP.
8.
B. The Cisco Emergency Responder falls within the applications category of the Unified Communications model.
9.
B. Analog-to-IP adapters sit on the edge of an IP network and translate analog signaling into IP for proper transport on an IP network. This lets people continue to use analog telephone hardware on an IP network.
10. B. PBX agents are not one of the three Cisco call-processing agents as defi ned by Cisco. 11. C. Most current Cisco phones can run either SCCP or SIP signaling protocols. SCCP is Cisco proprietary while SIP is an IETF open standard. 12. A. SPCP is a modification of the Cisco proprietary SCCP signaling protocol that is used only for communications between a CUCM Express call agent and Cisco SPA 300 and 500 series phones. Voice gateways cannot be configured with SPCP signaling. 13. C. The 1900 series ISR G2 cannot run voice IOS software and therefore can’t be used as a voice gateway. 14. D. The Cisco ISR can support numerous voice gateway functions, but it cannot offload Cisco Emergency Responder duties. 15. A. QoS is configured and maintained on network infrastructure hardware. 16. D. Quality of Service requirements are not a factor when choosing between voice gateway signaling protocols. 17. D. The geographical diversity model clusters call agents that communicate as a single unit over WAN links.
c01.indd 30
9/21/11 12:09:25 PM
Answers to Review Questions
31
18. B. SRST is recommended when deploying the distributed services UC deployment model. SRST is used when WAN links fail and remote sites need to make outbound calls. 19. C, D. The WAN is a critical component in the distributed services and geographical diversity models. Because these two models have voice traffic sent across the WAN, QoS is therefore recommended. 20. B. The inter-networking of services model is used in situations where there are several dispersed buildings or campus sites and WAN links are not capable of handling voice traffic.
c01.indd 31
9/21/11 12:09:25 PM
Chapter 1
32
■
An Introduction to Traditional Telephony and Communications
Answers to Written Lab 1.1 1.
Central office
2.
Plant
3.
Tie trunk, CO trunk, and interoffice trunk
4.
Endpoints, applications, call-processing agents, and network infrastructure
5.
Key system
6.
Endpoints
7.
Voice gateway
8.
Call processing
9.
Analog-to-IP adapter
10. Distributed services
c01.indd 32
9/21/11 12:09:26 PM
Chapter
2
Understanding Analog and Digital Voice THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the components of a gateway. ■
Describe the different types of voice ports and their usage.
Implement a gateway.
c02.indd 33
■
Configure analog voice ports.
■
Configure digital voice ports.
9/21/11 11:47:48 AM
Unified Communications today still relies heavily on the ability to connect to both legacy PBX systems and the public telephone network. While it would be great to have an end-to-end IP voice solution for every situation, that is simply not possible in many businesses today. In reality, you will probably need to support legacy analog or digital endpoints and circuits at some point. This chapter provides a thorough introduction to analog and digital voice ports and signaling protocols. We will also cover the analog-to-digital conversion process needed to transform analog waveforms into binary code for transport on digital circuits. Once we’ve covered the details of analog and digital telephony, you will learn how to configure the basic settings on various analog and digital ports that are available on Cisco voice gateway hardware.
Understanding Analog Voice Ports and Signaling Analog voice was the method used by the very fi rst telephones. The technology captures sound and places it onto the wire using electrical currents. The process is fairly simple and has worked now for 130 years or so, ever since the telephone was invented. While analog ports are becoming extinct, there still are a number of situations where you’re likely to encounter analog devices and analog ports in your career. The following section covers analog voice ports and their signaling techniques.
Analog Voice Port Types From a Cisco perspective, there are three analog ports that you need to become familiar with: FXS, FXO, and E&M. While many more analog port types are available out in the wild, these are the three port types available as modules on Cisco voice gateway hardware.
Foreign Exchange Station Ports Foreign Exchange Station (FXS) ports are used to connect plain old telephone service (POTS) end devices to a voice gateway. FXS ports are also found in homes that directly connect to the PSTN. FXS ports use two-wire cabling with RJ11 connectors.
c02.indd 34
9/21/11 11:47:49 AM
Understanding Analog Voice Ports and Signaling
35
Foreign Exchange Office Ports Foreign Exchange Office (FXO) ports connect the PSTN to a voice gateway. FXO ports use the same two-wire RJ11 cabling that FXS ports utilize.
E&M Ports E&M ports interconnect two PBX systems. The cabling uses either six or eight wires, which are bundled into pairs of two. Unlike FXS and FXO ports, E&M ports can either use one pair (two-wire) or two pairs (four-wire) for signaling purposes. This leaves two pairs for the transport of voice communication. If you are not familiar with RJ48 cabling, it uses the same eight-position, eight-contact (8P8C) modular connector that Ethernet uses. The difference between RJ48 and RJ45 is in how the pins are wired. See “E&M Signaling” later in the chapter for more about this signaling type.
Analog Voice Signaling One of the fi rst technical objectives CVOICE candidates need to understand is how analog telephones work on the PSTN. Telephones and telephone switches use signaling methods to communicate various stages in the setup, transport, and teardown of a telephone call. Three analog signaling categories will be covered in this section. Briefly, they can be described as the following: Address Signaling Address signaling is the transmission of telephone digits from the calling party phone to the called party phone. A unique sequence of digits identifies each individual phone on the network so the call reaches the correct destination. Informational Signaling Informational signaling is feedback generated from the telephone switch to the user in the form of tones or voice messages to inform the phone user what state a call is in. Supervisory Signaling Supervisory signaling detects changes in the status of the telephone physical loop or trunk. The signaling is then used to set up and tear down calls. Loop-start and ground-start analog signaling fall within this signaling category. In addition to these three analog signaling categories that deal with signaling from the customer premise equipment (CPE) to the PSTN, a separate set of signaling categories will be detailed that cover signaling specifically for E&M ports.
Address Signaling A telephone number consists of a string of digits that uniquely identifies a specific telephone or telephone system on a voice network. When someone wishes to call another user, they pick up a telephone handset and dial the unique digits that specify the telephone of the person they wish to talk to. The interpretation and handling of the dialed digits are the responsibility of address signaling. Two main methods are used to input telephone numbers using a telephone:
c02.indd 35
Pulse dialing
DTMF dialing
9/21/11 11:47:49 AM
36
Chapter 2
■
Understanding Analog and Digital Voice
Pulse dialing was the original method for dialing numbers on analog phones. Pulse dialing is also known as rotary dialing because of the method used to input the numbers using the phone handset. Figure 2.1 shows the design of a rotary phone pad.
A rotary dial pad
D
F I G U R E 2 .1
l ia 4 GHI
3 DEF
2 ABC
1
5 JKL 6 MNO 7 PRS 8 TUV
9 XYZ
9 OPER
Dial stopper
As you can see, the digits are organized in a circle on a rotating disk. To dial a digit, the user puts a fi nger in the numbered hole and turns the disk clockwise until the fi nger hits the rotary dial stopper at the lower right of the disk. The user then releases the disk, and it rotates on its own in a counterclockwise direction to its original starting position. During this counterclockwise rotation the phone performs a series of on- and off-hook transitions. The terms on-hook and off-hook refer to a mechanical switch that connects the telephone circuit to power and disconnects it. The power is detected by the telephone company and translated into dialed digits. Depending on how far the disk was rotated (based on the digit that the user wanted to indicate) the number of on- and off-hook transitions will specify a single number in the overall telephone number that the user wants to ring. Each additional digit is entered this way until the complete number has been entered. The PSTN phone switch then has the complete number of the phone that should be called, and the other signaling steps are performed until the call has been established. As you can see, this is a fully mechanical method of identifying digits of a phone number. It also can be timeconsuming to rotate the disk for so many digits. There is an old joke in the phone business that if you never want to be bothered with people calling you, always request a phone number with as many 9s and 0s in it as possible. That way, it takes so long to call you on a rotary phone that people won’t bother! Analog telephone dialing evolved from the rotary disk to a DTMF or touch-tone pad. DTMF stands for dual-tone multi-frequency. This method of entering telephone number digits uses specific audible tones that are produced when a user presses a button on the dial pad. A single button press emits two different tones simultaneously. The DTMF pad and tone frequencies emitted for each button are shown in Figure 2.2.
c02.indd 36
9/21/11 11:47:50 AM
Understanding Analog Voice Ports and Signaling
FIGURE 2.2
37
DTMF pad and corresponding frequencies DTMF frequencies 1209 Hz 1336 Hz 1477Hz 1633 Hz 697 Hz
1
2 ABC
3 DEF
A
770 Hz
4 GHI
5 JKL
6 MNO
B
852 Hz
7 PQRS
8 TUV
9 WXYZ
C
941 Hz
*
0
#
D
The A, B, C, and D tones in the diagram are simply additional tones that function in the exact same way that the other tones do. The primary difference is that you don’t typically have these buttons on telephone handsets. The tones can be used for a variety of reasons depending on the voice network being used.
The PSTN phone switch will recognize both of the simultaneous frequencies being emitted and translate the combination into the digit that the user wishes to call. The switch has timers for how fast or slow each number can be input into the dial pad before timeout occurs and the user must hang up and redial the entire phone number. The least duration between dialed digits is 45 milliseconds and the longest is 3000 milliseconds. As you can imagine, touch-tone dialing is the far more efficient method of entering a telephone number and is now used almost 100 percent of the time.
Informational Signaling Many telephone users take informational signaling for granted until they make their fi rst international call. Why is this, you ask? Since the telephone has been around for well over 100 years, most of us have grown up knowing what dial tones and ring-back tones sound like in the part of the world we happen to reside in. Some people are surprised to fi nd out, however, that the tones and cadences used to inform the calling party of the call progress are very different around the world. When an overseas call is made, the user fi rst hears their normal dial tone because they are connected to their local PBX or PSTN switch. The caller then enters the international long-distance number and waits to hear the familiar ring-back tone they are accustomed to. But because they are connecting to an international telephone system, that ring-back tone will likely sound very different from what they are used to. The remote-end switch always returns informational signaling, which may be
c02.indd 37
9/21/11 11:47:51 AM
38
Chapter 2
■
Understanding Analog and Digital Voice
located in a different country. The user may be confused by this and unsure if the call is actually progressing as it should. It is at this time that many people realize just how important and useful informational signals can be. Information signaling consists of audible tones or recordings that indicate to the phone user the status of the phone system and progress being made to place a call. Informational signals are also commonly referred to as call progress (CP) tones. Table 2.1 lists the more common informational signals and their functions. TA B L E 2 .1
Common informational signals
Informational Signal Type
Signal Function
Dial tone
Phone is in an off-hook state and ready to accept user input with the keypad.
Busy
Called number phone is currently in use.
Number not in service
Called number is not available on the phone network.
Call waiting
An incoming call is being made to line 2 on the phone; line 1 is in use.
Ring-back
The phone company is attempting to establish the connection to the called party.
Reorder
All local circuits are busy; thus the call cannot be completed.
Congestion
The telephone network is unable to complete the call.
Receiver off-hook
Someone has picked up the handset of a phone from the cradle.
Supervisory Signaling An analog telephone has two wires that connect it to the PSTN. One is the ground wire (or lead) and is called the tip wire. The other is the ring wire, which connects the phone to a battery for power. This power source is a ⫺48-volt DC battery. When a telephone handset sits in the cradle and is not in use, the phone is considered to be on-hook. This means that the circuit between the ring and tip is severed, and the battery (ring) cannot power the tip side and therefore cannot signal to the PSTN that a user wants to use the phone. When the circuit transitions to an off-hook state, the circuit is complete and the ring powers the tip, signaling that digits will soon be entered into the handset that the PSTN switch must listen for and process. The final supervisory signal once the line is secured at both ends of the connection is to send an electrical current to the receiving end’s phone, which causes the telephone ringer to go off.
c02.indd 38
9/21/11 11:47:51 AM
Understanding Analog Voice Ports and Signaling
39
There are three main types of analog supervisory signaling; each handles the on-hook and off-hook process differently. Table 2.2 lists these methods, where they are commonly used, and the analog interfaces they operate with on Cisco equipment. TA B L E 2 . 2
Supervisory signaling methods
Supervisory Signaling Method
Common Usage
Interface Types
Loop-start
Home telephones
FXS/FXO
Ground-start
Business telephones
FXS/FXO
E&M
PBX to PBX
E&M
The following sections cover each signaling technique to detail how on-hook and offhook transitions are handled.
Loop-Start Signaling Most home analog telephones use loop-start signaling along the local loop. Signaling takes place between the telephone handset and the PSTN switch. When the telephone handset is in the phone cradle, the ring and tip connections are separated, as shown in Figure 2.3. FIGURE 2.3
The on-hook status in loop-start signaling
Tip Ring Analog phone
–48 volt PSTN central office switch
With an FXS port, when the telephone user picks up the handset, a mechanical lever on the phone lifts and completes the ring-and-tip circuit. If an FXO port is used, the interface is responsible for completing the circuit loop. Figure 2.4 illustrates the off-hook status. FIGURE 2.4
The off-hook status in loop-start signaling
Tip Ring Analog phone
c02.indd 39
–48 volt PSTN central office switch
9/21/11 11:47:52 AM
40
Chapter 2
■
Understanding Analog and Digital Voice
Once the circuit is complete, the ⫺48-volt DC battery on the ring powers the tip. This electricity is detected by the PSTN switch, and the switch monitors the line for telephone number digits to be entered (either through pulse dialing or DTMF). From a PSTN standpoint, this is known as a telephone line seizure. Loop-start signaling suffers from two major limitations, which can cause problems for users who make and receive frequent calls and are the reasons loop-start signaling is not recommended for business phones. The fi rst is the possibility that both the phone handset and the PSTN switch could attempt to seize (use) the line at the same time. This is known as glare. For example, suppose you have a home phone that uses loop-start signaling. On the other side of town, your friend picks up the phone and calls you. Once your friend enters your telephone number, the PSTN switch performs a lookup and determines that your phone line needs to be seized so that the circuit can be completed between your friend’s phone and yours. The CO switch seizes your line, but unfortunately, it takes up to four seconds from the time the switch seizes your line to the time your phone actually rings to indicate that someone is calling. Now suppose that during these four seconds, you decide to use your phone to call your mother. You pick up your handset, but to your surprise, instead of hearing a dial tone, you hear someone on the other end of the line. After a few seconds of confusion and clarification, you and your friend realize that you’ve just experienced glare. Also, when an FXO port is used with loop-start signaling, calls coming into the FXO port may not properly disconnect. Remember that FXO ports are responsible for the onhook and off-hook transitions instead of the analog telephone itself. To the PSTN switch, the FXO port looks like and is therefore treated just like an analog phone. The FXO port can properly handle on- and off-hook transitions for outbound calls, but the same cannot be said for inbound calls coming from the PSTN. The result is that the line sits in an offhook state long after the call ended and the circuit should have been severed. Most businesses tend to make and receive more calls than home users. The increased call frequency means there is a higher probability of experiencing glare. To avoid these two problems with loop-start signaling, it is highly recommended that business analog phones use ground-start signaling, discussed next.
Ground-Start Signaling Ground-start signaling is used primarily on PBX-to-PBX or PBX-to-PSTN switch connections. The major difference from loop-start is that ground-start signaling requires grounding end to end before the ring and tip circuits are connected and the line is seized. This requirement that the full path be free prevents the potential for glare found in loop-start signaling, which does not verify the circuit path from the source to the destination. Figure 2.5 details the process of transitioning a phone using ground-start signaling from an idle on-hook state to an off-hook state. In each diagram, a PBX is connected to the PSTN switch using ground-start signaling. Figure 2.5, Step 1, shows the PBX in an on-hook state, with the tip and ring circuits severed at the PBX side. Also notice that the local ring has a second severed connection on the ring wire, and the PSTN switch side has a severed connection that feeds into a ring ground. This means that both the ring and tip wires are disconnected from the ground.
c02.indd 40
9/21/11 11:47:52 AM
Understanding Analog Voice Ports and Signaling
41
When an outside caller on the PSTN wants to call our local PBX, the PSTN switch will ground the wire. This grounding is detected by the local PBX switch, which proceeds to ground its ring wire, as shown in Figure 2.5, Step 2. At this point the circuit is not yet completed, but the line is completely free from usage end to end, so that when the line is seized, no glare will occur. The fi nal step in the process is for the PBX to complete the circuit by connecting the tip and ring circuits together, which transitions the circuit into an off-hook state. The PBX also removes the ring wire from the ground. Figure 2.5, Step 3, details the completed circuit using ground-start signaling.
FIGURE 2.5
Ground-start signaling Step 1: Idle state
Tip
Ring ground
Ring
–48 volt
PBX PSTN central office switch Step 2: The ring grounded
Tip
Ring ground
Ring
–48 volt
PBX PSTN central office switch Step 3: The loop closed
Tip
Ring ground
Ring
–48 volt
PBX PSTN central office switch
E&M Signaling E&M signaling is a supervisory signaling type that is used to connect PBX switches. E&M uses trunk lines for transport. You’ll fi nd more detail about trunk types later in this chapter. For now, note that E&M signaling is used on trunk connections. A second important difference between E&M
c02.indd 41
9/21/11 11:47:53 AM
42
Chapter 2
■
Understanding Analog and Digital Voice
signaling and loop-start/ground-start signaling is that E&M signaling can separate voice from the signaling onto separate wiring.
E&M Physical Wiring Types A great deal of discussion about E&M concerns the name itself. Many books and white papers argue that E&M refers to “earth” and “magnet”; others argue that it means “ear” and “mouth” as names for the wiring leads. For the purposes of this book, we will stick with the terms “earth” and “magnet” for the leads. Regardless of the name debate, it is important to note that there are six physical wiring methods for E&M signaling used throughout the world. E&M specifies eight different wires, listed in Table 2.3.
TA B L E 2 . 3
E&M wiring labels
E&M Wire
Usage
E
Signaling output
M
Signaling input
SG
Signal ground
SB
⫺48 volt signal battery
T
Audio input
R
Audio output
T1
Secondary audio input (on four-wire E&M)
R1
Secondary audio output
E&M Type I Uses one pair of wires for E&M signaling. The PBX supplies battery power for both the earth and the magnet leads. In an on-hook state, the earth lead is in an open position and the magnet lead is connected to the ground. The PBX transitions from an on-hook state to an off-hook state by connecting the magnet to the battery. The remote line side then connects the earth lead to the ground, which completes the circuit. This is the most common E&M method used in North America. E&M Type II Uses two pair of wires for E&M signaling. It also offers the advantage of producing a low amount of radiated interference, which can be beneficial in environments where there are many radio transmissions that are susceptible to interference. One of the four E&M wires is used for the earth lead and a second wire is used as the magnet lead. The other pair of wires is used as a signal ground (SG) and a signal battery (SB). Both
c02.indd 42
9/21/11 11:47:54 AM
Understanding Analog Voice Ports and Signaling
43
the earth and magnet leads are in an open state when on-hook. When transitioning to an off-hook state, the PBX connects the magnet lead to the SB lead, and the remote line side connects the earth lead to the SG lead, completing the circuit. You may come across E&M type II signaling when working with legacy PBX systems. E&M Type III Uses two pairs of wires for E&M signaling. Like types II and IV, it uses one pair as the earth and magnet leads and the other pair for the SB and SG leads. The main difference with E&M type II is that in the idle state for type III, the magnet lead is already connected to the SB lead when on-hook. The PBX indicates an off-hook state by moving the magnet lead from the SB lead to the SG lead. The remote line side will then ground the earth lead, completing the circuit. E&M type III circuits are rarely used in production. E&M Type IV Uses two pairs of wires for E&M signaling. Like types II and III, it uses one pair as the earth and magnet leads and the other pair for the SB and SG leads. Also like type II, E&M type IV signaling has both the earth and magnet leads in an open state when on-hook. The PBX moves to an off-hook state by connecting the magnet lead to the SB lead. The remote line then connects the earth lead to the SG lead, which is already grounded, completing the circuit. E&M type IV is not widely used, and you are not likely to see it in production. E&M Type V Uses one pair of wires for E&M signaling. Similar to type I, this type uses one wire lead for earth and the other lead for magnet. When the circuit is idle and on-hook, both the earth and magnet leads are open. The PBX will go off-hook by grounding the magnet lead. The remote line goes off-hook by grounding the earth lead. E&M type V signaling is the most popular type outside North America. SSDC5 Predominantly found in England, SSDC5 signaling uses one pair of wires and is similar to E&M type V signaling except that the on-hook and off-hook states are fl ipped. This is done so that if the trunk line breaks, the E&M interface defaults to an off-hook state indicated by a busy signal. Cisco hardware supports only E&M types I, II, III, and V.
While Cisco technically does not support E&M type IV on its hardware, it operates identically to E&M type II except that the magnet lead operates as a battery in type II when off-hook and as a ground when using type IV. Cisco equipment can interface with type IV equipment if the necessary magnet lead rewiring is done to account for this difference.
E&M Line-Seizure Signaling Types In addition to the different physical wiring types, E&M has three on- and off-hook statuses and line-seizure signaling methods: immediate-start, wink-start, and delay-dial. These methods are illustrated in the following figures using the example of an E&M trunk between two PBX systems. For the purposes of this example, the PBX on the left will always initiate
c02.indd 43
9/21/11 11:47:54 AM
44
Chapter 2
■
Understanding Analog and Digital Voice
(the sending side) the off-hook status to the PBX on the right (the receiving side), which will react to the change in status according to the signaling type detailed here: Immediate-start The immediate-start signaling method is the easiest method to comprehend. Figure 2.6 shows the process. In step 1, both PBX systems are in an idle and on-hook state. Then, in step 2, the sending-side PBX wants to seize a line between the two PBX systems, moves into an off-hook state, and informs the receiving-side PBX of this state change. In step 3, after sending the off-hook notification to the receiving-side PBX, the sending-side PBX waits 150 milliseconds before transmitting DTMF digits across the trunk. This pause potentially gives the receiving-side PBX time to be notified so it can begin listening for DTMF digits to be collected and processed. Finally, the receiving-side PBX collects the DTMF digits, transitions to an off-hook state, and notifies the sending-side PBX of the transition change and line seizure. FIGURE 2.6
Immediate-start E&M signaling Step 1: The idle state On-hook
On-hook
Sending PBX
Receiving PBX
Step 2: The sending side off-hook Off-hook
On-hook Going off-hook Receiving PBX
Sending PBX
Step 3: The pause before DTMF transmission Off-hook
On-hook DTMF digits after 150 ms pause Receiving PBX
Sending PBX
Step 4: The remote side off-hook Off-hook
Off-hook Going off-hook
Sending PBX
Receiving PBX
Wink-start This type of E&M signaling is very popular around the world. It is also the default E&M signaling method on Cisco equipment. This type of signaling is different from immediate-start signaling mainly because the sending PBX must receive feedback from the
c02.indd 44
9/21/11 11:47:55 AM
Understanding Analog Voice Ports and Signaling
45
receiving PBX before sending any digits. This ensures that the receiving switch is ready and able to collect and process digits. Figure 2.7 shows the process: In step 1, the two PBX switches are in an idle and on-hook state. The sending PBX then (step 2) goes off-hook and notifies the receiving PBX. At this point, the sending-side PBX sits and waits for feedback from the receiving-side PBX. When the receiving-side PBX sees the off-hook notification from the sending-side PBX, it quickly transitions the trunk line off-hook and back on-hook. This quick off-hook-to-on-hook transition is called a wink and lasts between 140 and 200 milliseconds. The remote-side wink is depicted in step 3. When the wink is sent across the trunk to the sending-side PBX, that serves as a notification to go ahead and send the DTMF digits across the trunk to the receiving-side PBX, as shown in step 4. The fi nal step is when the remote-side PBX collects the DTMF digits and transitions to an off-hook state. F I G U R E 2 .7
Wink-start E&M signaling Step 1: The idle state On-hook
On-hook
Sending PBX
Receiving PBX
Step 2: The serving side goes off-hook Off-hook
On-hook Going off-hook
Sending PBX
Receiving PBX Step 3: The remote side wink
Off-hook
On-off-on hook Wink off/on
Sending PBX
Receiving PBX
Step 4: DTMF transmission after receiving wink Off-hook
On-hook DTMF digits after receiving wink Receiving PBX
Sending PBX
Step 5: The remote side goes off-hook Off-hook
Off-hook Going off-hook
Sending PBX
c02.indd 45
Receiving PBX
9/21/11 11:47:56 AM
46
Chapter 2
■
Understanding Analog and Digital Voice
Delay-dial This line-seizure signaling method is similar to wink-start in the fact that the sending-side PBX waits to see if the receiving-side PBX is able to receive address information in the form of DTMF digits. Figure 2.8 steps through the complete delay-dial process. In step 1, both of the PBX switches are in an idle and on-hook state. In step 2, the sending PBX goes off-hook and indicates this status change to the receiving-side PBX. Step 3 differs from the other two E&M signaling methods in that the sending PBX is responsible for checking to see if the receiving PBX is in an off-hook or on-hook state. If the receiving-side PBX is off-hook already, the sending-side PBX will not send the DTMF digits and will terminate the call accordingly. If the receiving-side PBX is on-hook, the sending side will proceed to send address information across the trunk, as shown in step 4. As with all E&M signaling, the final step in the process is the receiving-side PBX going offhook after receiving DTMF addressing and seizing the line. FIGURE 2.8
Delay-dial E&M signaling Step 1: The idle state On-hook
On-hook
Sending PBX
Receiving PBX Step 2: Sending side off-hook
Off-hook
On-hook Going off-hook
Sending PBX
Receiving PBX
Step 3: Sending side status check On- or off-hook
Off-hook
Sending PBX
Checks to see if receiving PBX is onor off-hook
Receiving PBX
Step 4: DTMF transmission after receiving side on-hook verification Off-hook
DTMF digits
On-hook
if Receiving PBX is on-hook Sending PBX
Receiving PBX
Step 5: The remote side goes off-hook Off-hook
Off-hook Going off-hook
Sending PBX
c02.indd 46
Receiving PBX
9/21/11 11:47:57 AM
Understanding Analog Voice Ports and Signaling
47
Basic Configuration of Analog Voice Ports There are literally dozens of options to choose from when configuring analog voice ports. For many situations, you can get by with just using the default settings and changing only a few options. This section will go through the most basic FXS, FXO, and E&M port configurations. Chapter 6, “Configuring Voice Gateway Ports and DSPs,” will cover voice-port configuration options in greater detail.
Basic FXS Port Configuration An FXS port most commonly connects to an analog telephone or fax machine. The primary configuration option for this type of setup is whether the signaling type is loopstart or ground-start. FXS ports connecting to analog phones typically use loop-start, while specialized phones (such as pay phones) and FXS ports that connect a PBX to the PSTN use ground-start. For example, these commands demonstrate how to configure an FXS port for loop-start signaling on FXS port 0/0/0 of a Cisco router: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#signal loopstart Router(config-voiceport)#
Additionally, depending on the phone type used and the country you reside in, you may wish to configure settings that are specific to the PSTN standards in that area. These include call progress tone and ring frequency. The call progress tone settings modify the audible informational signaling tones, such as the ring-back tone or busy signal. These tones vary widely depending on the part of the world. To modify these settings, you can use the cp-tone command, as shown here: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#cptone ? locale 2 letter ISO-3166 country code AR AU AT BE BR CA CN CO C1 C2
c02.indd 47
Argentina Australia Austria Belgium Brazil Canada China Colombia Custom1 Custom2
IN ID IE IL IT JP JO KE KR KW
India Indonesia Ireland Israel Italy Japan Jordan Kenya Korea Republic Kuwait
PE PH PL PT RU SA SG SK SI ZA
Peru Philippines Poland Portugal Russian Federation Saudi Arabia Singapore Slovakia Slovenia South Africa
9/21/11 11:47:59 AM
48
Chapter 2
■
Understanding Analog and Digital Voice
CY Cyprus LB Lebanon CZ Czech Republic LU Luxembourg DK Denmark MY Malaysia EG Egypt MX Mexico FI Finland NP Nepal FR France NL Netherlands DE Germany NZ New Zealand GH Ghana NG Nigeria GR Greece NO Norway HK Hong Kong OM Oman HU Hungary PK Pakistan IS Iceland PA Panama Router(config-voiceport)#cptone
ES SE CH TW TH TR AE GB US VE ZW
Spain Sweden Switzerland Taiwan Thailand Turkey United Arab Emirates United Kingdom United States Venezuela Zimbabwe
Another attribute international users may need to configure along with the call progress tone is impedance, used to adjust the resistive strength that the attached analog device is expecting in ohms. This example shows the different configuration options for setting impedance on an FXS port: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#impedance ? 600c 600 Ohms complex 600r 600 Ohms real 900c 900 Ohms complex 900r 900 ohms real complex1 220 ohms + (820 ohms || 115nF) complex2 270 ohms + (750 ohms || 150nF) complex3 370 ohms + (620 ohms || 310nF) complex4 600r, line = 270 ohms + (750 ohms || 150nF) complex5 320 + (1050 || 230 nF), line = 12Kft complex6 600r, line = 350 + (1000 || 210nF) Router(config-voiceport)# impedance
Analog input gain and output attenuation settings deal with how to adjust the volume of the analog call in decibels (dB). (For reference, you should know that +3 dB = 2⫻ power/ volume and –3 dB = ½ power/volume for voice.) You should test carefully using these settings, because you can make them either too high or low. This example shows an FXS port being configured to add 2 dB of input gain and –1 dB output attenuation: Router#configure terminal Router(config)#voice-port 0/0/0
c02.indd 48
9/21/11 11:47:59 AM
Understanding Analog Voice Ports and Signaling
49
Router(config-voiceport)# Router(config-voiceport)#input gain 2 Router(config-voiceport)#output attenuation -1 Router(config-voiceport)#
Lastly, if you configure your FXS port with loop-start signaling, you know that you have a risk of glare on the line. To help reduce instances of this, you can adjust the echo cancellation coverage timer so that the voice port will wait the longer time it takes for the router to keep a waveform in its memory. Here is an example of how to set echo cancellation to 32 milliseconds: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)# Router(config-voiceport)#echo-cancel coverage 32 Router(config-voiceport)#
Basic FXO Port Configuration Because FXO ports commonly connect to the PSTN, they should be configured with ground-start signaling (although it is possible to have them configured with loop-start if the device you are connecting to requires it). Here is an example configuring of groundstart signaling on an FXO at port 0/1/0 on a Cisco router: Router#configure terminal Router(config)#voice-port 0/1/0 Router(config-voiceport)#signal groundStart Router(config-voiceport)#
There are two other FXO configuration settings that you should be familiar with. The fi rst setting deals with how the line will handle dialed digits. The two options are pulse dialing and DTMF, and you configure them using the dial-type command, as shown here: Router#configure terminal Router(config)#voice-port 0/1/0 Router(config-voiceport)#dial-type ? dtmf touch-tone dialer pulse pulse dialer Router(config-voiceport)#
The other basic FXO command to consider determines the number of rings the local voice router detects before answering an incoming call. When a voice gateway uses an FXO port to connect to the PBX, it is the FXO port that actually answers the call as opposed to an analog phone in an FXS port situation. Because of this, the FXO port can wait a certain
c02.indd 49
9/21/11 11:47:59 AM
50
Chapter 2
■
Understanding Analog and Digital Voice
number of rings before answering the call. To change the number of rings that a router waits to answer the call, you can use the ring number command, as shown here: Router#configure terminal Router(config)#voice-port 0/1/0 Router(config-voiceport)#ring number ? <1-10> The number of rings detected before closing the loop Router(config-voiceport)#
As you can see, the voice gateway can be configured to wait anywhere between 1 and 10 rings before answering the call (closing the loop).
Basic E&M Port Configuration As you have seen in the preceding discussion, there are multiple ways to configure an E&M port. Fortunately, as long as you know the settings your Cisco voice gateway requires to connect two PBX systems, the basic configuration has only three primary options. The fi rst option is to determine the E&M interface type that should be used. Again, although there are multiple types, Cisco hardware supports only E&M types I, II, III, and V. Here is an example of how to configure the E&M type on port 2/1/0 to use E&M type II: Router#configure terminal Router(config)#voice-port 2/1/0 Router(config-voiceport)#type 2
Next, you should configure which physical wiring setup needs to be used on the interface. Your choices are two-wire or four-wire. This is configured using the operation configuration command as shown here: Router#configure terminal Router(config)#voice-port 2/1/0 Router(config-voiceport)#operation two-wire
Lastly, the E&M signaling type must be set according to what the PBX is expecting. Your choices are wink-start, immediate, or delay-dial. To configure immediate signaling, use the signal command and then choose an E&M signaling type, as shown here: Router#configure terminal Router(config)#voice-port 2/1/0 Router(config-voiceport)#signal immediate
c02.indd 50
9/21/11 11:48:00 AM
Understanding Digital Voice Ports and Signaling
51
Understanding Digital Voice Ports and Signaling Pure analog circuits are becoming extinct. After all, we live in a digital age. After the long reign of analog telephone circuits, we entered a digitized circuit phase, which is now itself being superseded by the contemporary Voice over IP stage, where we combine voice and data on an IP network. In this section, we will fi rst look at how analog signals are converted into digital signals. This is a three-step process: sample, quantize, encode. A fourth step is often used on IP voice networks to compress the signal, which helps voice to operate properly on links with low latency and high bandwidth utilization. The remainder of this section will cover the most popular digital circuits and the types of signaling they utilize.
An Overview of the Analog-to-Digital Conversion Process As the PSTN grew both in numbers of phone lines and the geographical coverage across nations and globally, the analog telephone suffered from this growth spurt in both of these areas. The problem for coverage is that analog lines cannot travel long distances. Remember that analog signals convert voice into electrical pulses. As these electrical pulses are sent over a wire, they tend to get weaker and weaker the farther they travel. To help with this problem, analog signal repeaters are installed on analog lines. These devices take in the electrical pulses and add additional power to them, which helps them to travel longer distances. Unfortunately, while the voice pulses are amplified, so is the background noise that is inherently found on the line. Over time and multiple signal amplifications, this noise becomes so great that the voice quality suffers greatly. Alternatively, when voice signals are sent in a digital format, instead of transmitting electrical pulses over the wire, binary code in the form of 1s and 0s is transmitted. These bits can much more easily and accurately be collected and retransmitted. Therefore, the distance limitation is overcome with the use of digital circuits. The other benefit of transporting voice digitally is the ability to send more information than you can in an analog format. Once analog signals are sampled, converted into binary, and optionally compressed, multiple voice signals can share the same wire simultaneously, whereas an analog signal requires the use of a dedicated pair of wires for transport. The transmission of multiple voice calls on a single pair of wires lets digital systems scale much more when compared to analog. The following four sections cover the analog-to-digital conversion process. Technically, only three steps are required: 1.
Sample
2.
Quantize
3.
Encode This process is often referred to as pulse-amplitude modulation (PAM).
c02.indd 51
9/21/11 11:48:00 AM
52
Chapter 2
■
Understanding Analog and Digital Voice
But because this is a VoIP study guide, there is a fourth step that is often performed when discussing IP voice codecs. The VoIP steps for digitizing voice are as follows: 1.
Sample
2.
Quantize
3.
Encode
4.
Compress (optional depending on codec used) Let’s look at each of these four steps so you can understand how this process works.
Sample the Voice Signal Dr. Harry Nyquist, a Bell labs engineer working in the 1920s, is credited with determining the optimal method for sampling the human voice—the fi rst step in digitizing voice on digital telephone systems. This method is known as the Nyquist Sampling Theorem. Dr. Nyquist knew that most of human speech falls within the range of 200 to 2800 Hz. Telephones have what’s known as a low-pass fi lter, which restricts the range of audio from 300 to 3300 Hz. For manufacturing cost reasons, these fi lters are not entirely accurate, so Nyquist used the maximum collected frequency to be 4000 Hz. His research concluded that if a sample is taken at two times the highest frequency, this sample could almost perfectly replicate the full analog signal when reconstructed. This results in the following: sample_size = 2 × 4000 Hz (cycles per second) or sample_size = 8,000 cycles (times) per second The result of this sampling is referred to as a discrete signal. Figure 2.9 shows an analog signal and the Nyquist sampling algorithm at work. FIGURE 2.9
Discrete signal of an analog wave
Frequency
Samples
Time
c02.indd 52
9/21/11 11:48:01 AM
Understanding Digital Voice Ports and Signaling
53
Using this sampling method we can accurately sample voice and move onto the next step of the process, which is quantization.
Quantize the Collected Samples Now that we have our discrete signal by sampling our analog waveform, we must translate the samples into some type of numbering sample. This process is called quantization or pulse-code modulation (PCM). For voice, each of the collected samples is assigned a numerical value based on a reference scale of 0 to 255. This process of quantifying each sample is shown in Figure 2.10.
F I G U R E 2 .1 0
Quantizing each sample
59
62 62
54
54
43 Frequency
59 43
32
32
Time
Now we have our samples and we have quantized them into 8-bit numbers; next we need to encode the signal.
Encode the Quantized Samples Even though we have quantized our samples into a numbering system using the range 0 to 255, computers understand only binary numbers, which are series of 1s and 0s. Encoding is the process of taking the quantized samples and translating them into binary. It is no coincidence that PCM uses a range for quantizing analog samples between 0 and 255. This nicely translates into an 8-bit binary format. It is much like IP version 4 addresses, which use four 8-bit octets to specify the address of a network device. Figure 2.11 shows the encoding process in action.
c02.indd 53
9/21/11 11:48:01 AM
54
Chapter 2
F I G U R E 2 .11
■
Understanding Analog and Digital Voice
Encoding the quantized sample
59
62 62
59
54
54
Frequency
43
43
32 0 0 1 0 0 0 0 0
32 0 0 1 0 1 0 1 1
0 0 1 1 0 1 1 0
0 0 1 1 1 0 1 1
0 0 1 1 1 1 1 0
0 0 1 1 1 1 1 0
0 0 1 1 1 0 1 1
0 0 1 1 0 1 1 0
0 0 1 0 1 0 1 1
0 0 1 0 0 0 0 0
Time
As stated earlier, legacy digital systems stop at this point. The result is a 64 Kbps digital voice stream that can easily be replicated accurately over and over, which overcomes the analog distance limitation. We arrive at the 64 Kbps number because we are sampling our analog signal 8,000 times per second. These 8,000 samples are then converted into an 8-bit binary number. Doing the math, we arrive at the following: bit_rate_per_second = 8,000 samples per second × 8 bits bit_rate_per_second = 64,000 bits_per_second 64,000 bits_per_second = 64 Kbps In addition, digital streams can be multiplexed over a single cable. Multiplexing is the process of transporting multiple signals over the same cable medium. When multiple streams are transported across a single cable, the cable is known as a digital trunk. Using multiplexed digital trunks helps overcome the growth limitation of analog signals. The fi nal step we will investigate briefly is the optional fourth step of compression, which is found in most VoIP codecs in use today. The only popular voice codec that does not use compression is G.711, which sends voice packets in uncompressed 64 Kbps streams. All other codecs described in the book use compression of some kind.
Compression of the Encoded Sample Bandwidth on a given network is fi xed for the most part. Sure, upgrades can be performed to increase bandwidth, but networks are built to be in place for multiple years. Because networks typically grow over time, voice and data applications are constantly being required to use less and less bandwidth, a limited commodity. The move from analog to digital helped to allow multiple voice calls to share the copper medium. The 64 Kbps stream is great, but eventually it also was too large. This required an additional step called compression, which attempts to eliminate redundant 8-bit binary samples on the
c02.indd 54
9/21/11 11:48:02 AM
Understanding Digital Voice Ports and Signaling
55
receiving end by using a known sample or group of samples, which then is turned into a smaller representation of the signal and sent across the wire to the remote end. When the compressed signal is then decoded, it is approximately the same signal as prior to compression. Obviously, some compression methods are better than others. You probably can identify voice codecs that use a high amount of compression. The voice sample after being decoded on the other side turns a human voice into a much choppier and more robotic sound. This means that compression has a definite tradeoff between bandwidth savings and voice quality.
What in the World Is Companding and Where Does It Fit In? Oftentimes when discussing the analog voice and analog-to-digital conversion, the topic of companding arises. It is a difficult concept to grasp because it has multiple uses depending on the type of voice signal that the process is being used on. The process of companding was originally used in analog systems to increase the signal-to-noise ratio (SNR). With voice transmissions, the algorithm helped to amplify the signal of a human voice while reducing background noises that are picked up by the microphone. In the migration from transporting analog signals to transporting digital, it was discovered that the biggest benefit to using companding methods was not so much to increase SNR but instead to reduce the total number of bits that were required for the digital circuit to be encoded and transported. The number of bits used to represent a moment of voice over a period of time is called a sample size. Therefore, the more modern definition of companding in a digital sense consists of first compounding the analog voice signal before it is input to an analog-to-digital converter (ADC) and then, after the signal is digitized and transported, expanding it on the other end of the call by a second ADC. The expanded signal is then sent to the receiver part of the phone. (From compounding and expanding, we get the term companding.) One popular companding algorithm is u-law, which is performed primarily on T1 circuits in North America and J1 circuits in Japan. In regions such as Europe, the A-law algorithm is used instead; it is similar to the u-law algorithm but performed on E1 circuits. It was discovered that by using u-law and A-law, the sample size could be made as small as 8 bits per sample. In a way, it is the earliest form of compression but is technically not considered as such. These u-law and A-law algorithms are defined in the G.711 (aka pulse-code modulation (PCM)) standard. Companding is the only compression-like technique used by PCM.
c02.indd 55
9/21/11 11:48:03 AM
56
Chapter 2
■
Understanding Analog and Digital Voice
Digital Voice Port Types Cisco offers several digital voice interface types that can be installed on voice gateways. The major differences between these interfaces involve the number of simultaneous calls an interface can handle and the geographic region where some interfaces are more likely to be found than others. In addition, there are other differences such as the signaling, framing, and line coding, which will be explained in the next section. For now, let’s briefly look at the major differences between the T1, E1, and ISDN (Integrated Services Digital Network) BRI ports.
T1 Port A T1 port consists of 24 separate channels, each operating at 64 Kbps. Depending on the signaling type used, a T1 can provide either 24 simultaneous calls using Channel Associated Signaling (CAS) or 23 simultaneous calls using Common Channel Signaling (CCS). A T1 using CCS is often called an ISDN PRI. You may jump to the conclusion at this point that CAS is the better option because it offers the ability to use one additional line. Make sure to read the next section, which describes how CAS and CCS signaling work. In fact, CCS signaling is much more popular in PSTNs today. T1 circuits are used in public networks in North America (United States, Canada, and parts of the Caribbean).
E1 Port An E1 port is closely related to the T1 in many ways. In fact, the E1 interface is used instead of T1 almost everywhere outside North America and Japan. An E1 port has 32 channels, which operate at 64 Kbps. Also, similar to the T1, an E1 port can use either CCS (E1 PRI) or CAS signaling. E1 and T1 ports differ in the type of framing used to transport data across the wire. An E1 port is capable of sending 30 simultaneous voice calls using either CAS or CCS.
ISDN BRI Port The ISDN Basic Rate Interface (BRI) is a three-channel 64 Kbps port. Two of the 64 Kbps channels are for the transport of voice/data, and the third 16 Kbps channel is for signaling. An ISDN BRI can be thought of as the smaller version of the ISDN T1/E1 PRI, because it operates identically using CCS. ISDN ports are in use by public telephone companies all around the world.
Digital Voice Multiplexing, Framing, and Physical Transport As stated earlier, one of the primary benefits of digital circuits over analog is their ability to transport multiple calls on a single pair of wires. This is known as multiplexing. The most common type of digital circuit multiplexing is known as time-division multiplexing (TDM). All the previously mentioned circuits (T1, E1, and ISDN BRI) use TDM. TDM is a strict timebased method for sharing a single cable to transport multiple voice signals. Let’s take a T1
c02.indd 56
9/21/11 11:48:03 AM
Understanding Digital Voice Ports and Signaling
57
circuit that uses 24 logical TDM channels, for example. Each channel is assigned a timeslot, which reoccurs in a specific order. The timeslot is how TDM functions. It is the time that each channel within a trunk has to transport voice. When voice data from channel 1 is sent, the next portion of that voice call must wait until the timeslots for the other 23 channels have had their opportunity to send data on the same wire. This is true even if the channels have nothing to send. When each channel’s time is finished, the circuit moves to the next channel to either send voice data or wait until the time limit expires and moves on to the next channel. Each channel on a T1 circuit can send 8 bits of data at a time, as shown in Figure 2.12.
F I G U R E 2 .1 2
T1 TDM channels
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
24 timeslots – 8 bits
Recall from earlier in the chapter that using the Nyquist theorem, we need to be able to send 8,000 samples each second for a single voice call. Each TDM cycle on a T1 is 193 bits. To get to this number we multiply 8 bits for each sample sent per channel by the number of channels, which is 24. This gives us 192 bits. Then we add 1 additional bit for framing and we come to 193 bits for each TDM cycle. We can then take the 8,000 sample size and multiply it by 193 bits to get the total bandwidth of a T1 circuit: T1_throughput = 193_bits ⫻ 8,000 samples per second T1_throughput = 1,544,000 bps T1_throughput = 1.544 Mbps So that is how multiplexing works to send 24 separate voice streams simultaneously over a single copper cable. But the voice gateways need some method to package all these TDM channels together for proper transport to the next voice gateway. This is where framing comes into play. Historically there are two types of voice framing, but only one is in almost universal use today. The fi rst framing type is called Super Frame (SF). This bundles 12 TDM channel cycles together in a single frame. Each frame is 193 bits in size. Super frames are the older framing type and are almost never seen today. Because each TDM channel is 8 bits and we
c02.indd 57
9/21/11 11:48:04 AM
Chapter 2
58
Understanding Analog and Digital Voice
■
bundle 12 of them together, that comes out to 192 bits. SF uses the extra bit to signal the end of a TDM cycle. It does this by sending a special 12-bit pattern using bit 193 twelve times, as shown in Figure 2.13. F I G U R E 2 .1 3
Super Frame
193 bits C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
TDM cycle 1 + 1 signal bit
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
TDM cycle 2 + 1 signal bit
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
TDM cycle 11 + 1 signal bit
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
TDM cycle 12 + 1 signal bit
12 TDM cycle super frame
Extended Super Frame (ESF) has replaced SF because it requires less synchronization between gateway endpoints and it includes a cyclic redundancy check (CRC) feature for more reliable transport. Unlike SF, ESF bundles 24 TDM channel cycles together in a single frame. Again, the last bit of the 193-bit cycle is used. Because ESF is bundling 24 cycles together in a frame, it has the benefit of 24 bits per channel for framing and other purposes. I say “other purposes” because ESF requires only 18 bits for framing 24 TDM cycles instead of the 12 bits for each 12 TDM cycle required by SF. This frees up 6 bits that are used for the CRC. More specifically, ESF frames are used in the following manner: Framing pattern: 4, 8, 12, 16, 20, 24 Data link control: 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23 CRC: 2, 6, 10, 14, 18, 22 Figure 2.14 shows how an Extended Super Frame is constructed. F I G U R E 2 .1 4
Extended Super Frame
193 bits C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
TDM cycle 1 + 1 signal bit
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
TDM cycle 2 + 1 signal bit
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
193 bits C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
TDM cycle 23 + 1 signal bit
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
1 2 3 4 5
C h a n n e I
C h a n n e I
C h a n n e I
C h a n n e I
21 22 23 24
TDM cycle 24 + 1 signal bit
24 TDM cycle extended super frame
c02.indd 58
9/21/11 11:48:04 AM
Understanding Digital Voice Ports and Signaling
59
One fi nal digital circuit parameter to mention is the circuit’s physical layer line-coding characteristics. Choosing a line code type dictates how bits are sent across the digital wire, that is, how 1s and 0s are represented electrically. On digital copper circuits such as a T1, no change in voltage during a time frame represents binary 0, and either a positive or negative voltage on the wire represents a binary 1. There are two common standards in use today. The older standard is called alternate mark inversion (AMI). AMI logically is transferred across electrical copper wiring, as shown in Figure 2.15.
F I G U R E 2 .1 5
AMI Transport
0
1
0
Bits 1 0
1
1
0
V +1 o l t 0 a g e –1
Notice how the multiple 1s in a row are sent using alternating polarity. This is done to avoid bipolar violations, which means that you cannot have consecutive 1s that use the same electrical polarity. Along those lines, 0s in AMI line coding are always represented with a 0 current. This method works sufficiently for up to seven 0s in a row. But if the eighth bit is also a 0, you will receive an error on the line, because of the fact that bipolar switch equipment has difficulties dealing with 8 bits in a row with 0 voltage. Because of this limitation, a new method of line coding was developed. Bipolar 8-bit Zero Substitution (B8ZS) was created to eliminate the AMI method’s 8-bit 0 problem. As the name states, this line-coding method will substitute for a series of eight 0s on the wire (which would create an error) a specific pattern that is known by both the sending and receiving voice gateways. There are two possible patterns that B8ZS will use to display 8 bits of consecutive 0s, depending on the polarity of the previous bit sent. Therefore, you will see one of the polarity patterns shown in Figure 2.16 to represent eight 0s using B8ZS.
c02.indd 59
9/21/11 11:48:05 AM
60
Chapter 2
F I G U R E 2 .1 6
■
Understanding Analog and Digital Voice
B8ZS polarity patterns
0
0
0
Bits 1 1
0
1
1
0
0
0
Bits 1 1
0
1
1
V +1 o l t 0 a g e –1
V +1 o l t 0 a g e –1
Digital Voice Signaling Just as with analog signaling, there are several types of digital voice signaling that you need to understand; each method operates differently and affects the number of simultaneous calls allowed on a single circuit. We briefly discussed CAS and CCS earlier in this chapter. This section will cover these two in greater detail and introduce two signaling subtypes, Q.931 and QSIG.
Channel Associated Signaling Channel Associated Signaling (CAS) is a PSTN signaling type that allows for up to 24 simultaneous calls. In order to squeeze 24 calls into an SF or ESF frame, CAS uses what’s known as in-band or robbed-bit signaling (RBS). RBS will take bits from SF framing channels 6 and 12 and ESF framing channels 6, 12, 18, and 24 for sending signaling data from one end of the digital circuit to the other. This stealing of bits is done to maximize the number of calls a CAS T1 can handle. The downside to stealing a bit used for voice is that the quality of the call suffers because you are only able to use 56 Kbps as opposed to 64 Kbps. While this does indeed degrade the quality of the digital voice signal, the difference between the two is slight to the ear. CAS can also be used on E1 circuits, but it operates there very differently than with T1. Of the thirty-two 64 Kbps channels an E1 circuit has, channel 1 is used for framing and synchronization and channel 17 is used for signaling. Therefore, even though an E1 CAS uses RBS, it still requires a dedicated channel on 17 for signaling. The difference between a T1 CAS and an E1 CAS boils down to the fact that E1s do not use SF or ESF. Instead they use a multiframe method (the details of which are outside the scope of this book) that
c02.indd 60
9/21/11 11:48:06 AM
Understanding Digital Voice Ports and Signaling
61
bundles channels into groups of 16. In this way, channel 1 is used to designate the start of the first 16-multiframe group, while channel 17 is used to designate the second grouping of 16.
Common Channel Signaling Unlike CAS digital circuits that sacrifice voice quality to maximize the number of simultaneous calls, Common Channel Signaling (CCS) sets aside one or two dedicated channels for signaling, a method known as out-of-band signaling. This means that these signaling channels cannot be used for voice calls. However, the benefits are that the remaining channels use a full 64 Kbps for higher call quality, and the CCS channels have additional bandwidth that can be used to provide additional value-added services to voice circuits. By far the most common digital circuit transport standard that uses CCS is Integrated Services Digital Network (ISDN). ISDN is a standard suite of protocols that operates on layers 1–3 of the OSI model. ISDN utilizes PSTN circuits running CCS for the transport of voice, data, and video. ISDN differs greatly from other analog and digital methods in the fact that it can transport voice and data on the same circuit-switched connection. There are two types of ISDN in use within phone companies today. ISDN BRI An ISDN Basic Rate Interface (BRI) consists of three 64 Kbps digital channels. Two 64 Kbps channels are called B, or “bearer,” channels. ISDN BRI circuits are commonly found at remote sites or other locations where only two voice/data connections are needed. These channels are responsible for transporting voice, data, or video on the circuit. The other channel is called the D, or “delta,” channel. But this channel is further broken down. 16 Kbps of the D channel are used for signaling, while the other 48 Kbps of bandwidth are used for framing and synchronization. Table 2.4 outlines the segmentation of the 192 Kbps ISDN BRI bit rate:
TA B L E 2 . 4
ISDN BRI channels
ISDN Segment
Purpose
Bandwidth Allocated
B channel 1
Voice/data transport
64 Kbps
B channel 2
Voice/data transport
64 Kbps
D channel
CCS signaling
16 Kbps
D channel
Framing and synchronization
48 Kbps
It is important to understand that while an ISDN circuit has a bit rate of 192 Kbps, you cannot count framing and synchronization as bandwidth. Therefore, an ISDN BRI actually has a bandwidth of 144 Kbps.
c02.indd 61
9/21/11 11:48:06 AM
Chapter 2
62
■
Understanding Analog and Digital Voice
ISDN PRI An ISDN Primary Rate Interface (PRI) circuit is the big brother of the ISDN BRI. It is found in larger environments where multiple voice and/or data connections are needed. Depending on the interface type used, a PRI can carry 23 (T1) or 30 (E1) simultaneous B channels for voice or data transport. Again, out-of-band signaling is used in ISDN, and a 24-channel T1 circuit will set aside a full 64 Kbps for D channel signaling. But unlike the ISDN BRI circuit, PRI requires the full 64 Kbps to support the transport of 23 voice/data channels. The D channel of a T1 circuit is almost always the last one, channel 24 when all channels are numbered. The larger ISDN E1 interface has 32 channels for use. With PRI, ISDN uses 30 B channels for the transport of voice or data and 1 D channel. Channel 17 is used for the single D channel, while channel 1 is designated for framing and synchronization, similar to an ISDN BRI circuit.
Q.931 Signaling The D channel of both ISDN PRI and BRI circuits uses the Q.931 signaling protocol. Q.931 is an ITU-T (International Telecommunications Union Telecommunication Standardization Sector) standard that is responsible for the setup and teardown of B channel connections whether they are voice or data connections. The protocol uses signaling messages between voice gateways, including commonly used signaling messages such as these:
Call setup
Call in process
Remote end ringing
Call connected
Call disconnected
Release channel
QSIG You may run into situations where a PBX hardware vendor uses a proprietary ISDN signaling protocol. Unless you have the same PBX on both ends of your circuit, you need a way so the two PBXs or voice gateways can properly communicate signaling information back and forth. Q signaling (QSIG) is an open standard protocol designed to overcome this exact issue. QSIG uses Q.931 as its underlying signaling protocol but “tweaks” it so that other proprietary ISDN signaling protocols can also be used and understood. These additional proprietary signals can then be used within a network that has different PBX systems but with the appearance of one unified system with uniform services across the board. QSIG not only helps in the administration process of operating different PBX systems in a single organization, it also helps the end users because every phone operates the same way and they can utilize the same voice services no matter what PBX they are connected to. Some examples of QSIG signaling messages include these:
c02.indd 62
Caller ID
Call transfer
9/21/11 11:48:07 AM
Understanding Digital Voice Ports and Signaling
Call redirect
Do not disturb
63
Basic Configuration of Digital Voice Ports When working through the FXS, FXO, and E&M analog configuration ports, you may have noticed that all of these ports were configured by issuing the voice-port command. Similarly, digital voice ports are configured using the controller command. The next section will go through how to configure basic settings for a T1 CAS and ISDN T1 PRI port.
Basic T1 CAS Configuration T1 CAS circuits can be configured with either Super Frame or Extended Super Frame, using the framing command. You need to set the framing type to match what your PSTN provider has configured on its end. As was stated earlier, ESF is used almost exclusively everywhere in the world. Here is an example of choosing ESF framing on T1 port 2/1: Router#config t Router(config)#controller t1 2/1 Router(config-controller)#framing ? esf Extended Superframe sf Superframe Router(config-controller)#framing esf Router(config-controller)#
Next, you need to choose the type of T1 CAS linecoding you wish to use, with the linecode command. The two options are AMI and B8ZS. We will configure our T1 for B8ZS: Router#config t Router(config)#controller t1 2/1 Router(config-controller)#linecode ? ami AMI encoding b8zs B8ZS encoding Router(config-controller)#linecode b8zs Router(config-controller)#
Next, you need to determine how the T1 interface will receive its clocking for TDM, using the clock source command. The two options are internal, which uses the router’s local clock, and line, which will receive clocking from the remote-side router. The
c02.indd 63
9/21/11 11:48:07 AM
64
Chapter 2
■
Understanding Analog and Digital Voice
command to set one of these clocking options is clock source. We will configure internal clocking for our T1 here: Router#config t Router(config)#controller t1 2/1 Router(config-controller)#clock source ? internal Internal Clock line Recovered Clock Router(config-controller)#clock source internal Router(config-controller)#
Lastly, a very functional feature for a T1 CAS is the ability to break a 24-channel T1 into two or more DS0 groups. A DS0 is the name for a single 64 Kbps channel of a CAS. The T1 can be logically split using the ds0-group command so different signaling can be used and the different channels can ultimately serve multiple uses. To do this, you create separate DS0 group numbers and specify the timeslots. You then configure the signaling type that you wish these timeslots to utilize. The following configuration shows a new DS0 group (group 0) using timeslots 1–12 and the different signaling types available: Router#configure terminal Router(config)#controller t1 2/1 Router(config-controller)#ds0-group 0 timeslots 1-12 type ? e&m-delay-dial E & M Delay Dial e&m-fgd E & M Type II FGD e&m-immediate-start E & M Immediate Start e&m-wink-start E & M Wink Start ext-sig External Signaling fgd-eana FGD-EANA BOC side fgd-os FGD-OS BOC side fxo-ground-start FXO Ground Start fxo-loop-start FXO Loop Start fxs-ground-start FXS Ground Start fxs-loop-start FXS Loop Start none Null Signalling for External Call Control
Router(config-controller)#
Basic ISDN PRI Configuration Because a T1 PRI uses ISDN with Q.931 signaling, you must know what type of ISDN switch you are connecting the port to. To set the ISDN type, use the isdn switch-type command. Please note that configuring the switch type is a global configuration command
c02.indd 64
9/21/11 11:48:08 AM
Understanding Digital Voice Ports and Signaling
65
and not a config-controller command. Listed in the following code snippet are the various switch-type options available. In our example, we will configure the switch to use primary-5ess. Router#configure terminal Router(config)#isdn switch-type ? primary-4ess Lucent 4ESS switch type for the U.S. primary-5ess Lucent 5ESS switch type for the U.S. primary-dms100 Northern Telecom DMS-100 switch type for the U.S. primary-dpnss DPNSS switch type for Europe primary-net5 NET5 switch type for UK, Europe, Asia and Australia primary-ni National ISDN Switch type for the U.S. primary-ntt NTT switch type for Japan primary-qsig QSIG switch type primary-ts014 TS014 switch type for Australia (obsolete) Router(config)#isdn switch-type primary-5ess Router(config)#
The primary ISDN type used by PSTNs in the United States is the primary-5ess option. Also note the primary-qsig option, which is used when connecting to PBX systems that use proprietary signaling, as we discussed earlier in the chapter. Next, just as with T1 CAS, the framing, linecoding, and clock source must be configured on an ISDN PRI port. Here is an example of a T1 PRI configured for ESF framing, B8ZS as the linecode type, and receiving the clocking from the remote router: Router#configure terminal Router(config)#controller t1 2/1 Router(config-controller)#framing esf Router(config-controller)#linecode b8zs Router(config-controller)#clock source line Router(config-controller)#
Lastly, an ISDN T1 PRI port must be configured to designate which timeslots of the PRI will be used, by using the pri-group timeslots command. This setting is important when you order a fractional T1 PRI from the PSTN. A fractional PRI is a circuit that looks and acts like a standard 24-channel T1 but in fact has a smaller number of channels available for use. PSTNs often offer fractional PRI circuits to customers who need between 5 and 15 digital lines but not a full 24 channels. Here is an example of how to configure a T1 PRI to use all 24 channels: Router#configure terminal Router(config)#controller t1 2/1 Router(config-controller)#pri-group timeslots 1-24 Router(config-controller)#
c02.indd 65
9/21/11 11:48:08 AM
66
Chapter 2
■
Understanding Analog and Digital Voice
Summary Chapter 2 gave you a bit of a history lesson about how analog and digital voice circuits function at a physical level, along with transport and signaling methods. You also went through the three required steps necessary for the analog-to-digital transformation to occur. Lastly, you were shown the basic configuration commands necessary to configure various analog and digital voice ports that are available on a Cisco voice gateway. While future chapters in this book will expand on configuration methods used in configuring legacy ports, Chapter 2 gives a detailed insight into how analog and digital circuits work. Everything from electrical transport to the various signaling methods used is important for every CVOICE candidate to understand. The more you understand how underlying protocols work, the better you can understand why you are configuring specific settings and how the circuit will operate differently.
Exam Essentials Know the three different analog ports used on Cisco gateways. are FXS, FXO, and E&M ports.
The three analog ports
Understand the three analog signaling types. Address signaling controls the transmission of telephone numbers. Informational signaling instructs callers as to how a call is progressing on the network. Supervisory signaling controls the on- and off-hook status of a telephone connection. Know the difference between loop-start and ground-start signaling. Loop-start signaling is primarily used on ports that connect to analog endpoints and use a simple method for telephone line seizure. It is also prone to glare. Ground-start signaling overcomes glare by requiring an end-to-end grounding before the line is seized. Ground-start signaling is often used between PBX systems or between a PBX and the PSTN. Understand the six types of E&M physical wiring. E&M is a signaling protocol used between PBX systems. While all six wiring schemes use RJ-48 connections, the wiring differs in the number of pairs used for signaling and the method used for signaling on- and off-hook transitions. Know the three different types of E&M supervisory signaling. E&M immediate-start, wink-start, and delay-dial signaling differ in the way the calling switch sends address information to the receiving switch. Immediate-start does a simple pause before sending, wink-start waits for an on-off-on signal from the receiving switch, and delay-dial checks the status of the trunk to the receiving switch before sending DTMF digits. Understand and be prepared to configure analog voice ports. Analog voice ports are configured within the config-voiceport mode on a Cisco voice gateway. There are several options that are unique to each analog voice port that you should familiarize yourself with.
c02.indd 66
9/21/11 11:48:09 AM
Written Lab 2.1
67
Know the three required and one optional step in the analog-to-digital conversion process. In order to transport voice on a digital circuit, the analog signal must first be sampled. Second, each sample must be quantized. Third, the quantized sample must be encoded into binary. And the fourth, optional step is compressing the encoded data. Know the three different digital ports used on Cisco gateways. T1, E1, and ISDN BRI.
The three digital ports are
Understand the purpose of TDM. TDM is a multiplexing method that uses time-based slots for transport of multiple voice signals across the same wire. Understand the difference between SF and ESF. SF bundles 12 TDM cycles together on a T1 and uses 12 bits for framing. ESF bundles 24 TDM cycles together on a T1 and uses 18 bits for framing. The additional 6 bits inside the ESF are used for CRC. Understand how B8ZS overcame the 8-zero problem found in AMI linecoding. B8ZS uses a unique positive/negative voltage pattern to represent 8 binary 0s in a row. Know the primary difference between CAS and CCS signaling. CAS uses in-band or robbed-bit signaling, while CCS uses out-of-band signaling. There are pros and cons to each signaling type, although you are more likely to see CCS circuits in use today because of their ability to transport both voice and data, whereas a CAS circuit can only transport voice. Understand and be prepared to configure digital voice ports. Digital voice ports are configured while within the config-controller mode on a Cisco voice gateway. There are several options that are unique to each digital voice port that you should familiarize yourself with.
Written Lab 2.1
c02.indd 67
1.
What is the type of analog port that commonly connects a PBX to the PSTN?
2.
Which supervisory signal type connects the ring to the tip?
3.
What term describes an occurrence found in loop-start signaling in which a phone line is seized several seconds before a ring notifies the called party of an inbound call on their phone?
4.
Pulse dialing and DTMF are what type of signaling?
5.
Which E&M signaling protocol waits 150 ms before sending address information to the telephone switch?
6.
Write the config-voiceport command used to change an FXS or FXO port to use loop-start signaling.
7.
Write the command used to increase the output strength of an analog signal by +2 dB while in config-voiceport mode.
9/21/11 11:48:09 AM
68
Chapter 2
■
Understanding Analog and Digital Voice
8.
Write the command used to configure a T1 controller to use the remote-side gateway for clocking while in config-controller mode.
9.
Write the command used to configure Extended Super Frame (ESF) on a T1 while in config-controller mode.
10. Write the command used to enable channels 1–24 on a T1 PRI port while in configcontroller mode.
(The answers to Written Lab 2.1 can be found following the answers to the review questions for this chapter.)
c02.indd 68
9/21/11 11:48:09 AM
Review Questions
69
Review Questions 1.
Which supervisory signaling type is most recommended for connecting a business PBX to the CO? A. Loop-start
2.
B.
E&M
C.
Ground-start
D.
Local-loop
What process does DTMF use to specify dialed digits? A. Combining two audio tones to specify a single digit
3.
B.
Using rapid on-hook and off-hook transitions to specify a single digit
C.
Using a single audio tone to specify a single digit
D.
Grounding the tip to ring in rapid succession to specify a single digit
Which type of analog signaling is used to alert a phone user to the progress a telephone call is making? A. Address
4.
B.
E&M
C.
Informational
D.
Relation
E.
Supervisory
Ground-start signaling requires what before the ring and tip circuits are connected for line seizure? A. The local side is grounded.
5.
B.
The remote side is grounded.
C.
Both the local and remote sites are grounded.
D.
The trunk line is grounded.
Which E&M signaling methods verify that the remote switch is ready to receive address signaling? (Choose all that apply.) A. Wink-start
c02.indd 69
B.
Immediate-start
C.
Monitor-start
D.
Delay-start
9/21/11 11:48:10 AM
Chapter 2
70
6.
■
Understanding Analog and Digital Voice
An E&M switch sends a notification to the remote side switch indicating its off-hook status. The switch then waits for an on-off-on hook response prior to sending DTMF digits across the trunk. Which E&M signaling type is being used? A. Delay-start
7.
B.
Immediate-start
C.
Ground-start
D.
Loop-start
E.
Wink-start
What informational signaling type specifically indicates that the telephone network is unable to complete the call? A. Dial tone B.
8.
Reorder tone
C.
Receiver off-hook
D.
Congestion
Which of the following E&M wiring types is not supported on Cisco voice gateways but is very similar to type II? A. Type III B.
9.
Type IV
C.
Type V
D.
SSDC5
What is the config-voiceport command used to configure an analog voice port to use the standard informational signals used in Taiwan (TW)? A. signal TW B.
impedance TW
C.
cptone TW
D.
dial-type TW
10. What is the config-voiceport command used to adjust the volume on an incoming analog voice signal? A. input gain
c02.indd 70
B.
input impedance
C.
input attenuation
D.
input cptone
9/21/11 11:48:10 AM
Review Questions
71
11. What FXS port command is used to adjust the resistive strength to 600r, which the attached analog phone is expecting? A. Router(config-voiceport)#input gain 600r B.
Router(config-voiceport)#impedance 600r
C.
Router(config-voiceport)#input 600r
D.
Router(config-voiceport)#impedance gain 600r
12. Which of the following is not an E&M signaling type? A. Router(config-voiceport)#signal delay-dial B.
Router(config-voiceport)#signal groundStart
C.
Router(config-voiceport)#signal wink-start
D.
Router(config-voiceport)#signal immediate
13. In the analog-to-digital process, what is the name of the step that assigns a number to a specific sample? A. Compound B.
Encode
C.
Quantize
D.
Compand
14. In the analog-to-digital process, what is the name of the step that converts the samples into binary? A. Compand B.
Encode
C.
Compound
D.
Quantize
15. What is the name for the process that allows multiple call streams to be transported on a single pair of wires? A. Framing B.
Linecoding
C.
Multiplexing
D.
Companding
16. What problem found in AMI linecoding does B8ZS fix? A. The problem with sending 8 binary 0s in a row on the wire
c02.indd 71
B.
The problem with sending 8 binary 1s in a row on the wire
C.
The problem with sending 24 binary 0s in a row on the wire
D.
The problem with sending 24 binary 0s in a row on the wire
9/21/11 11:48:11 AM
Chapter 2
72
■
Understanding Analog and Digital Voice
17. What ISDN signaling subtype is used when attempting to connect a PBX that uses proprietary signaling? A. B8ZS B.
Q.931
C.
QSIG
D.
Type II
18. Which of the following commands correctly configures Extended Super Frame on a T1 port? A. Router(config-voiceport)#linecode esf B.
Router(config-controller)#linecode esf
C.
Router(config-controller)#framing esf
D.
Router(config-voiceport)#framing esf
19. You are configuring a T1 port on a voice gateway. Which of the following commands is not correct? A. Router(config-controller)#isdn switch-type primary-5ess B.
Router(config-controller)#framing esf
C.
Router(config-controller)#linecode b8zs
D.
Router(config-controller)#clock source line
20. Which of the following is the correct command used to configure an E&M port as a type II interface? A. Router(config-voiceport)#signal 2
c02.indd 72
B.
Router(config-controller)#type 2
C.
Router(config-controller)#signal 2
D.
Router(config-voiceport)#type 2
9/21/11 11:48:11 AM
Answers to Review Questions
73
Answers to Review Questions 1.
C. Ground-start signaling is recommended to avoid glare problems that occur with loop-start signaling.
2.
A. DTMF stands for dual-tone multi-frequency. Two audio tones are combined to represent a single telephone number digit.
3.
C. Informational signaling is used to notify end users of the status a call resides in.
4.
C. Ground-start signaling requires that grounding be performed end-to-end prior to line seizure.
5.
A, D. Both wink-start and delay-start perform a check to ensure that the remote switch is capable of receiving address signaling.
6.
E. Wink-start uses an on-off-on sequence called a “wink” as notification that the remote switch is ready to receive address signaling information in the form of DTMF digits.
7.
D. Congestion is the informational signal type used to indicate that the call is unable to be completed.
8.
B. E&M type IV is technically not supported on Cisco hardware, but if you need to connect type IV devices, you can configure them as type II and rewire them to work properly.
9.
C. The correct way to change informational signaling tones is to use the cptone command followed by the two-letter country/region code.
10. A. The input gain command controls the strength in decibels (dB) of the incoming signal on the analog port. 11. B. The impedance command is used to adjust resistive strength in ohms. Cisco offers several different choices depending on the strength the attached analog device uses. 12. B. Ground-start signaling can be configured on FXS and FXO ports. E&M signaling can be configured for wink-start, immediate, or delay-dial. 13. C. Quantizing is the process of taking a sample and assigning it a number based on the frequency within the sample. 14. B. Encoding is the process of converting the quantized samples into binary. 15. C. Multiplexing is the process used to transport multiple voice signals over a single pair of wires. The most common multiplexing used on voice circuits is time-division multiplexing (TDM). 16. A. AMI will give an error when a source attempts to send 8 binary 0s in a row using electrical signals. B8ZS overcomes this problem by sending an alternating series of positive and negative polarity to represent all 8 0s in a row.
c02.indd 73
9/21/11 11:48:11 AM
74
Chapter 2
■
Understanding Analog and Digital Voice
17. C. Q signaling (QSIG) uses Q.931 as its underlying signaling protocol but modifies the signals so other proprietary ISDN signaling protocols can also be used and understood. 18. C. A T1 port is configured within config-controller mode. The correct command to configure Extended Super Frame is framing esf. 19. A. The ISDN switch type is a global configuration command and is not set when within config-controller mode. 20. D. An E&M port is analog, so you must be in config-voiceport mode. The correct command is type 2, which specifies that the E&M interface type is II.
c02.indd 74
9/21/11 11:48:12 AM
Answers to Written Lab 2.1
75
Answers to Written Lab 2.1 1.
FXO
2.
Loop-start
3.
Glare
4.
Address
5.
Immediate-start
6.
signal loopstart
7.
output attenuation 2
8.
clock source line
9.
framing esf
10. pri-group timeslots 1-24
c02.indd 75
9/21/11 11:48:12 AM
c02.indd 76
9/21/11 11:48:12 AM
Chapter
3
VoIP Operation and Protocols THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the basic operation and components involved in a VoIP call. ■
Describe VoIP call flows.
■
Describe RTP, RTCP, cRTP, and sRTP.
■
Describe H.323.
■
Describe MGCP.
■
Describe Skinny Call Control Protocol.
■
Describe SIP.
■
Identify the appropriate gateway signaling protocol for a given scenario.
c03.indd 77
9/21/11 11:16:21 AM
The last chapter covered the process of taking an analog signal and processing it so it can be transported over digital circuits. This process gets us one step closer to Voice over IP. Because voice packets are already in a digital format, all we have to do is wrap the voice payload in an IP packet, and it is ready for transport on an IP network. That is the first topic of discussion for Chapter 3. This process of packetizing voice signals for transport over an IP packet is accomplished using RTP and RTCP. In addition, there are extensions to RTP that can be used to decrease the header size of an IP voice packet and to transport the payload in a secure manner. We’ll discuss these extensions, cRTP and sRTP, in detail, and you’ll see how and when they can be used to improve call quality and secure transmissions. Next, we will cover the four voice gateway signaling protocols: SIP, MGCP, SCCP, and H.323. That discussion will also include an introduction to H.323 gatekeeper hardware and common components specifically found in H.323 networks. Lastly, we will cover various situations in which one gateway signaling protocol would be preferred over another.
Voice Media Transmission Protocols When you have a voice sample that has been converted to a digital format, you need to include additional information so the voice payload can be sent to the intended destination over an IP network. The information needed includes details such as the source and destination IP address and transmission protocol and port used. Also, real-time traffic such as voice requires additional protocol assistance for proper transport to a destination over IP. The primary two protocols that accomplish this goal are RTP and its helper protocol, RTCP. In addition, there are certain situations where the information stored within an RTP packet header can be reduced so it can be more efficiently sent over low-speed serial connections. This is an extension of RTP called cRTP. Finally, we’ll discuss how to configure voice gateways to provide for secure transport of IP voice packets using sRTP.
Introduction to the Real-Time Transport Protocol The Real-time Transport Protocol (RTP) was originally defi ned in IETF RFC 1889 and revised to its current standard, which is RFC 3550. The protocol was developed to transport streaming data. By streaming data, we are specifically talking about real-time transport of voice and video. Because real-time transport of streaming data occurs instantly, lost or damaged packets have no need to be resent. If the packets were
c03.indd 78
9/21/11 11:16:22 AM
Voice Media Transmission Protocols
79
resent, they would arrive at their destination late and/or out of order, and would be essentially useless by the time the packet arrived. Therefore, RTP was designed to be used with the User Datagram Protocol (UDP) instead of the Transmission Control Protocol (TCP). UDP is a transport mechanism for IP packets that, unlike TCP, does not attempt to retransmit or reorder packets that never arrive or are late to the destination. For this reason and because UDP packets, lacking these features, are smaller than in TCP, UDP is an ideal Layer 4 transport mechanism for both voice and video. UDP also offers multiplexing capabilities for easy replication using multicasting protocols at upper layers of the OSI model. In addition, UDP provides error-detection mechanisms that help make it both fast and efficient on an IP network. RTP functions strictly as an end-to-end protocol. This means that the IP source and destination devices communicate RTP directly with each other, unlike those voice signaling protocols that communicate with intermediary systems. For example, Figure 3.1 shows a small network with two IP phones attached to it. They are using the Cisco proprietary SCCP signaling protocol. When IP-phoneA wants to call IP-phoneB, the phone communicates to the Cisco call processing agent (a CUCM). The CUCM then finds the location of IP-phoneB and is responsible for the call setup. But as soon as the CUCM has established an end-to-end call, the actual transport of voice packets goes directly between endpoints.
F I G U R E 3 .1
RTP end-to-end transport CUCM
ng
ali
P CC
M
n sig
CP
sig
na
lin
g
S
IP-phoneA
SC
Switch
IP-phoneB
RTP packet flow
The RFC for RTP does not specify the actual UDP ports that RTP should utilize. The one requirement stated is that the UDP port must be an even number. Most voice networks are set to use default RTP settings, which use random even-numbered UDP ports in the range of 16384 to 32767 for the purpose of RTP transport. The RFC specifies that RTP must always use even-numbered ports while RTCP uses odd-numbered ports. When a connection is made between IP voice endpoints such as two IP phones, an even-numbered UDP port is selected for the RTP packets to use from the source IP to the destination IP.
c03.indd 79
9/21/11 11:16:23 AM
80
Chapter 3
■
VoIP Operation and Protocols
This UDP port is then used for the entire duration of the call. Once the call is disconnected, that port is released and can be reused by another RTP stream later. Also keep in mind that an RTP stream is only a one-way communication. Therefore, a voice call must have two separate RTP connections established in order to achieve two-way communication.
Don’t Firewall Your VoIP Brett was experiencing a problem at a remote site where some VoIP calls were connecting but others were not. After eliminating various voice gateway configuration problems, he narrowed the root cause to a misconfigured firewall that sits on the edge of the WAN connection. A firewall rule was configured to allow only a portion of UDP ports for RTP. A quick rule change to allow the proper range of UDP ports, and the remote site no longer had intermittent call connection problems. Because RTP UDP port selection is random and uses a large range of UDP ports, you must account for this if your RTP traffic traverses a firewall. You must take proper care to ensure that your firewall is sufficiently opened to allow RTP streams for a wide range of UDP ports. Otherwise, you will find yourself in a situation where some RTP sessions are allowed and others are denied.
So now that you understand how RTP uses UDP as its upper-layer transport mechanism, let’s look at the information contained within RTP. The RTP header is a variable size and has a minimum size of 12 bytes without any optional fields. Within the RTP header are various fields that hold all kinds of information related to the proper transport of real-time, streaming data. These specific RTP header fields are listed here: Version The version field is two bits in size and specifies the version of RTP that is being used. While there are technically two versions of RTP, only version 2 is in use today. If future versions of RTP are developed, you will be able to differentiate between version numbers in this field. Padding The padding field is one bit. If this bit is set (binary 1), it indicates that this RTP packet has one or more octets at the end that are not part of the voice or video payload. Padding is often used for encrypting RTP payloads using sRTP. Extension The extension field is one bit. If this bit is set (binary 1), it indicates that the fi xed RTP header is followed by a single header extension. CSRC Counter The CSRC counter is four bits in size. It tells you the number of CSRC headers (if any) that will be in the fi xed header.
c03.indd 80
9/21/11 11:16:23 AM
Voice Media Transmission Protocols
81
Marker The marker field is one bit. If this bit is enabled (binary 1), it indicates a unique event that is identified by the application using the RTP stream. Depending on the application, the marker field can mean many different things. Payload Type The payload field is seven bits in size. This field identifies the type of RTP data that is inside the payload. This field allows RTP to communicate the transport of voice, data, and other streaming protocols. Sequence Number The sequence field is 16 bits in size. This field is a counter that increments by one for each RTP packet in a particular stream. This information can be used by upper layers of an application to detect packets that are lost or that arrived unordered. Timestamp The timestamp field is 32 bits in size. This field holds the exact time (sourced by NTP) when the voice payload was encapsulated in the IP packet. This information can then be used by the application to better transport time-sensitive payloads and to avoid jitter. Synchronization Source Identifier (SSRC) The SSRC is 32 bits in size. This field uniquely marks multiple RTP streams differently that are originating from the same source. The SSRC can then be used to differentiate among multiple RTP streams. Contributing Source (CSRC) The CSRC is 32 bits in size. This optional field is similar to SSRC in that it is used to identify the source of streaming data. The difference is that this field specifically identifies contributing sources to streams that come from multiple sources as opposed to the source itself.
Introduction to the Real-time Transport Control Protocol The Real-time Transport Control Protocol (RTCP) is a supporting protocol for RTP. RTCP is defi ned in the same RFC 1889 and 3050 standards along with RTP. RTCP is an out-of-band protocol in the sense that RTCP information is sent in separate, independent packets from RTP. In addition, RTCP packets never contain a voice payload. Instead, RTCP contains information about the specific RTP stream it is paired with. Whereas RTP chooses a random even-numbered UDP port within the range of 16384 to 32767, RTCP will choose the next-highest odd-numbered UDP port after RTP has randomly chosen its port. For example, if an RTP connection is established and the protocol selects the random UDP port of 18408, RTCP will then use the next-highest odd number, which is 18409. The RTP conversation is always set up fi rst, followed by the RTCP conversation. There are several types of RTCP packets. These include the following: Sender Report stream.
Provides reception quality feedback from the sending device of the RTP
Receiver Report Provides reception quality feedback from the receiving device of the RTP stream. It contains the same information as the sender report except that it lacks a 20-byte sender information section used by senders.
c03.indd 81
9/21/11 11:16:24 AM
82
Chapter 3
■
VoIP Operation and Protocols
Source Description Contains information about the source host including CNAME, username, email address, location, and other identifying information that is available. Goodbye RTCP
Indicates that at least one source of an RTP stream is no longer active.
Application-Specific Used as experimental packets for new applications that utilizes RTP. This allows developers to try new features easily without modification of the protocol. The purpose of RTCP is primarily to collect the following information:
Packet count for a single RTP stream
Packet loss for a single RTP stream
Packet delay for a single RTP stream
Variation in time between packets (jitter)
Because RTCP can collect information for a single RTP stream, it is a powerful mechanism that can pinpoint where quality of service (QoS) problems may reside. This information can be used by upper-layer protocols so they can adjust settings such as the codec type used for most efficient transport at any given time on a network.
Introduction to Compressed RTP If you look at the size of an IP packet carrying voice traffic, you may be surprised to see just how small the payload of the voice data is compared to the size of the IP packet headers. Every voice packet contains 20 bytes of IP information, 12 bytes of RTP fields, and 8 bytes of UDP information. That adds up to 40 bytes for a complete IP/UDP/RTP header. With voice payloads ranging (depending on the codec and compression used) between 20 and 160 bytes on average, headers that are 40 bytes seems like a great deal of added bulk. Compressed RTP (cRTP) was developed to shrink the size of this header information down from 40 bytes to a much more manageable 2–5 bytes. Different aspects of cRTP are described in IETF RFCs 2508, 2509, and 3545. It is important to note that cRTP doesn’t actually compress anything but instead relies on the fact that much of the information contained within IP/RTP and UDP headers is static for a specific stream. cRTP will stop sending this redundant information after the first transmission to the destination. The voice gateway accomplishes this by stripping out the static header information prior to sending it out the outbound interface. The process is CPU intensive and should only be used on serial links where bandwidth is sparse. In addition, cRTP operates on a Layer 2–by–Layer 2 basis, meaning that you will have to configure cRTP at every Layer 2 hop that requires it between two endpoints. It is recommended that cRTP only be enabled on connections that are at T1 speeds or lower. Also, cRTP can be used on serial connections that use ISDN, Frame Relay, HDLC, and PPP connections. The ideal situation in which cRTP should be used is on a reliable yet low-speed serial connection where voice packets use a high-compression voice codec, which commonly shrinks payload sizes between 20 and 50 bytes. Otherwise, the amount of CPU processing power required to run cRTP overshadows its benefits. With the continuing
c03.indd 82
9/21/11 11:16:24 AM
Voice Gateway Signaling Protocols
83
growth of high-speed WAN connections, you will fi nd that cRTP is being used less and less in the real world.
Introduction to Secure RTP Secure RTP (sRTP) is a fairly new protocol compared to RTP. Similar to the RTP/RTCP partnership, sRTP has a secure helper protocol in sRTCP, which performs all of the same RTCP functions in a secure manner. It was developed as described in IETF RFC 3711. The purpose of the protocol was to provide RTP packets with the following: Authentication and Message Integrity HMAC-SHA1 authentication can be configured to ensure the authentication and assure message integrity between two RTP endpoints. Payload Encryption Single-cipher AES encryption is used to encrypt streaming data payloads. One of two cipher modes can be utilized, either Segmented Integer Counter Mode (Segmented ICM) or f8. The default AES cipher mode is Segmented ICM. A NULL cipher can also be configured, which essentially disables encryption but allows use of other sRTP features such as authentication. Replay Protection In a replay attack, an unauthorized user captures RTP packets in transit (such as a one-way RTP stream of a telephone conversation) with the intent to play them and/or modify them to be placed back on the wire for eventual delivery to the destination. Replay protection checks to ensure that voice packets have not been previously played. If it determines that the voice packet has been intercepted and played in transit, the packet is dropped and a log message is triggered to notify network administrators. The RTP stream receiver keeps an index of previously received RTP packets and compares each new packet against the index. If any new packets do not match sequencing found within the index, those packets are assumed to be tampered with and are not sent to the destination. If sRTP and sRTCP are configured on a voice gateway, they replace the use of standard RTP and RTCP. However, sRTP and sRTCP can be configured to use cRTP if desired.
Voice Gateway Signaling Protocols Voice gateways are just one component in a Voice over IP solution. As you learned in Chapter 1, “An Introduction to Traditional Telephony and Cisco Unified Communications,” voice gateways are primarily responsible for bridging an IP network with the PSTN. From an IP network perspective, the voice gateway must be integrated very closely with the IP call-processing agent such as one of the Cisco Unified Communications Manager solutions. If a voice network is small, a CUCM Express solution can be installed; this enables you to have a fully integrated call-processing agent and voice gateway solution on one router appliance, as shown in Figure 3.2.
c03.indd 83
9/21/11 11:16:25 AM
Chapter 3
84
FIGURE 3.2
■
VoIP Operation and Protocols
Integrated call-processing agent and voice gateway
PSTN IP phone
Analog phone
Call agent/voice gateway
On larger networks that require the use of the CUCMBE or CUCM, the voice gateway must be separated from the call-processing agent, as shown in Figure 3.3.
FIGURE 3.3
Separated call-processing agent and voice gateway Signaling protocol
M IP phone
Call agent
PSTN V Voice gateway
Analog phone
Because the two voice appliances are separated, they need to be able to communicate call routing and other information to each other. This is where voice gateway signaling protocols come into play. There are four voice gateway protocols used on Cisco call-processing agents and voice gateways to communicate signaling information:
H.323
SIP
MGCP
SCCP
The following sections detail how each protocol works and provide a general understanding of how these protocols came to be and how they function. This information should help you to understand the architectural differences among the four protocols.
Always keep in mind that these voice gateway signaling protocols simply provide signaling mechanisms so voice has the proper communications path. The actual transport of the voice stream for each of the protocols mentioned is handled by RTP/sRTP.
H.323 H.323 is the oldest of the signaling protocols. It is an ITU-T standard for the transport of voice, video, and data using a peer-to-peer architecture. A peer-to-peer architecture means
c03.indd 84
9/21/11 11:16:25 AM
Voice Gateway Signaling Protocols
85
that sender and receiver are peers in the sense that both have intelligence to route calls from one point to another. It is also a distributed call control architecture, meaning that H.323 peers operate independently of each other and do not rely on any other peer for the handling and control of call signaling. The H.323 protocol paints in very broad strokes; because it doesn’t provide a lot of specifics about what it transports, it is used in a much greater variety (compared to other voice gateway signaling protocols described in this study guide) of applications, including voice, video, and real-time data. H.323 also has the benefit of interacting well in both IP and PSTN environments. It can translate between IP and PSTN addressing. This function is commonly referred to as an H.323 gatekeeper and is explored later in this chapter. H.323 is still widely deployed and is the default signaling protocol on Cisco voice gateways and call-processing agents. H.323 is known as a protocol “suite” because it actually comprises multiple sub-protocols that are also defi ned by the ITU-T. For example, the H.225 sub-protocol specifies call setup and codec negotiations for endpoints, H.245 performs call control signaling between endpoints. Table 3.1 lists some of the more common H.323 sub-specifications. TA B L E 3 .1
H.323 sub-specifications
Sub-specification
Description
H.225 Call Setup
Call setup and teardown for H.323-speaking devices. Can also reformat ISDN Q.931 messages to interoperate with H.225 messages.
H.225 Call Routing
Uses the Registration, Administration, and Status (RAS) protocol for call routing.
H.235
Security specification between H.323 gateway and gatekeeper devices.
H.245
Logical multimedia transport channel. Also performs a capabilities exchange between endpoints.
H.450
Controls H.323 supplementary services between H.323 speaking devices, including call divert (H.450.3), call hold (H.450.4), call park/pickup (H.450.5), and call waiting (H.450.6).
H.323 is based on the ISDN Q.931 protocol and therefore can be integrated easily with PSTN networks because they speak similar languages, which means that little translation needs to be done for native H.323 devices and legacy PSTN devices to interoperate.
Session Initiation Protocol The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard protocol. SIP has gone through numerous RFC revisions, beginning with RFC 2543.
c03.indd 85
9/21/11 11:16:26 AM
86
Chapter 3
■
VoIP Operation and Protocols
There are several new RFCs regarding SIP, but most people still usually reference RFC 3261 as the SIP standard, while newer RFCs are considered to be minor updates. To read the full RFC on SIP, use the following URL:
http://tools.ietf.org/html/rfc3261
SIP was designed to transport both voice and video over IP networks using either UDP or TCP, although UDP is the preferred method. SIP transports messages by default on UDP 5060. It is considered to be a peer-to-peer protocol, which means that both endpoints offer SIP routing intelligence. SIP endpoints are called SIP user agents (UA). User agent clients (UAC) send INVITE messages when they wish to establish a connection with another UA. User agent servers (UAS) reply to INVITE messages. SIP messages are structured in a simple manner. The messages are actually sent in ASCII format. As stated earlier, SIP by default runs over UDP. If you are concerned about someone being able to read your SIP signaling messages because they are sent in cleartext ASCII, you can implement Transport Layer Security (TLS).
Most of you are probably most familiar with TLS and its predecessor SSL, which you encounter whenever you visit a secure website by entering https://.
TLS most often runs on connection-oriented protocols. Because UDP is connectionless, when running SIP with TLS, it will use TCP for transporting signaling information instead of UDP. SIP endpoints are also addressed as Uniform Resource Locators (URLs). In fact, SIP’s text-based format closely resembles that of HTTP, which is widely used by web browser clients who wish to view web pages on web servers. This resemblance is not by coincidence but instead uses the same addressing functions. For example, consider the following SIP UA address: sip:[email protected];user=phone
The fi rst part of the address (5555) is the unique number for a SIP endpoint. This is commonly the telephone extension number of an endpoint such as a SIP-enabled IP phone. The second part of the address, after the @ symbol, is the IP network address of the nexthop location of where the endpoint can be located on a network. The user=phone portion specifies that the number 5555 is a phone extension. SIP uses a distributed call-processing architecture. Many components come together to make a complete SIP network. When dealing with SIP from a call agent–to–voice gateway perspective, the two components are peers. Both of them require independent configurations to properly send and receive SIP information to one another and, ultimately, route RTP streams inbound and outbound. Two additional components found in many SIP environments are SIP proxy servers and SIP registrar servers. SIP proxy servers take the responsibility of forwarding INVITE
c03.indd 86
9/21/11 11:16:26 AM
Voice Gateway Signaling Protocols
87
messages for the UACs. SIP register servers maintain a database of UA locations (numberto-IP mapping) on a SIP network. The Cisco CUCM lineup provides both of these functions when using SIP on IP phone endpoints.
Media Gateway Control Protocol A second IETF (RFC 3435) standard protocol for call signaling and call setup between a packet network and the traditional PSTN is Media Gateway Control Protocol (MGCP). MGCP is the newest protocol of the bunch and uses a client-server architecture that was standardized in 2003. When you compare it to a protocol such as H.323, you will quickly fi nd that MGCP is far more limited in the things it can do. It essentially handles only multimedia call control. But if this is all you need, it is an excellent choice because it is extremely simple to configure and maintain. Being a client-server architecture, MGCP has two different roles of responsibility: Call Control Device This is the call-processing agent (CUCM). All control of how calls are routed across the network is handled at the CUCM. A voice gateway running MGCP has no knowledge of call control. IP to PSTN Translation This is the voice gateway that runs MGCP. It receives call-control instructions and performs the translation between IP and PSTN components. As you can see, the call-control information is completely contained on the call-processing agent, so this is a centralized call-control structure. The voice gateway must communicate with the CUCM to know where to route the call. This methodology differs greatly from the H.323 and SIP protocols, in which multiple devices contain call-routing intelligence. If the MGCP voice gateway cannot communicate with the call-processing agent, it has no knowledge of where it should route calls. MGCP endpoint addresses have two segments: Local Name This is the unique name of the MGCP speaking endpoint such as a CUCM or voice gateway. Domain Name This is the universal domain name the MGCP endpoints belong to. This domain name must match before MGCP endpoints can begin communicating.
A potential single point of failure is that the MGCP voice gateway may not be able to communicate with the MGCP call-control device. To eliminate this risk, a feature called MGCP fallback can be configured to let gateways fall back to the H.323 protocol when communication is lost. H.323 can then be configured with call-control information directly on the gateway and can properly route calls between networks.
MGCP signaling messages are sent in cleartext and use TCP and UDP port 2427. Both the call-control server and the voice gateway client send MGCP messages to each other.
c03.indd 87
9/21/11 11:16:27 AM
Chapter 3
88
■
VoIP Operation and Protocols
These messages must be acknowledged to ensure receipt of every message. The messages communicate information such as the following:
Codec used
QoS settings
Cleartext or encrypted voice streams
Amount of bandwidth reserved for each call
Keep in mind that while call control for the IP network is strictly located on the callprocessing agent, off-network addressing information to the PSTN must still be located on the voice gateway itself. Despite this, call control for the PSTN addressing dial peers is still controlled by the call-processing agent, which in a Cisco environment is a CUCM.
Skinny Client Control Protocol The Skinny Client Control Protocol (SCCP) is Cisco’s proprietary voice signaling protocol. It is primarily used as an endpoint-to-call-agent protocol for signaling. It can be used on voice gateways, however, for various reasons, such as the configuration of a DSP farm or communication with an analog-to-IP VG200, which only runs SCCP. In addition, FXS/FXO ports can be configured on a voice gateway to act like any other Cisco IP phone configured with SCCP. Obviously, since it is a proprietary protocol, both the call processing agent (CUCM) and voice gateway must be Cisco equipment. SCCP is a client-server architecture with centralized call control. In this regard, it is similar to MGCP rather than SIP or H.323. SCCP messages are transported over TCP port 2000. Because SCCP uses TCP for transport, messages can utilize TCP functionality built into the protocol, such as error correction and a guaranteed delivery of packets.
Voice Gateway Signaling Protocol Comparison To summarize the differences between the voice gateway protocols we’ve just examined, we can categorize them by their organizational standard, architecture, and call-control method. Table 3.2 compares the four voice gateway protocols. TA B L E 3 . 2
c03.indd 88
Voice gateway signaling protocols at a glance
Protocol
Standard
Architecture
Call Control
H.323
ITU-T
P2P
Distributed
SIP
IETF
P2P
Distributed
MGCP
IETF
Client-server
Centralized
SCCP
Cisco
Client-server
Centralized
9/21/11 11:16:28 AM
An Introduction to Gatekeepers and Other H.323 Components
89
An Introduction to Gatekeepers and Other H.323 Components Because H.323 is a distributed architecture, many devices that utilize H.323 have their own intelligence. Much of this intelligence is offloaded to specialized hardware that handles specific functions. This section will cover the functions of gatekeepers and other H.323 components and how they interact with each other.
Gatekeeper A gatekeeper is most commonly found in very large enterprise H.323 environments. Its primary function is to maintain a database of telephone extensions–to–IP address mappings. Why are gatekeepers mainly found in large enterprise environments? Let’s explore that question. When a Cisco voice environment has thousands of users and/or uses a distributed callprocessing scheme, multiple CUCM servers and voice gateways will be used. These servers will then be clustered together. Having a distributed call-processing structure forces administrators to configure dial information for each of the clustered servers/gateways. Figure 3.4 shows a cluster of CUCMs that must be configured to know the telephone numbers and IP mappings of each clustered location. FIGURE 3.4
A call-processing cluster
CUCM
CUCM
M
M Sharing of dial information
c03.indd 89
M
M
CUCM
CUCM
9/21/11 11:16:29 AM
90
Chapter 3
■
VoIP Operation and Protocols
H.323 gatekeepers are commonly implemented for call admission control (CAC). A CAC-enabled gatekeeper keeps a database of telephone number extensions to authorized destination mappings. For example, a lobby telephone number extension will likely only be allowed to call internal extensions, while an employee desk phone can dial off-network destinations. Additionally, call admissions can be further broken down to admit some phones to dial long-distance or internationally while limiting others to local dialing. Another point has to deal with the administration of a large telephone network with hundreds or thousands of telephone numbers. As you can imagine, managing all these extension number–to–IP address mappings can become a daunting and complex administrative task. To remedy this issue, many organizations implement a gatekeeper, a single source of dial information that any of the CUCM servers and H.323-speaking gateways can access. Once it is implemented, the CUCMs and gateways access the gatekeeper when they are looking for a specific location to send calls to other member clusters. The CUCM knows the extension number but not the IP location of destination phone. The gatekeeper responds with the IP address of where the phone is located within the network. Figure 3.5 shows multiple call-processing agents communicating with a gatekeeper in a single zone. FIGURE 3.5
Call-processing cluster with a gatekeeper
Zone 1 CUCM
CUCM
M
M
Sharing of dial information
M
M
CUCM
CUCM
Gatekeeper
The CUCM servers must register with the gatekeeper before it can begin querying the gatekeeper database. Gatekeepers can divide voice networks into gatekeeper zones that help to segment the locations of phones on the network.
c03.indd 90
9/21/11 11:16:29 AM
An Introduction to Gatekeepers and Other H.323 Components
91
Cisco routers can be configured as gatekeepers that do this exact process. The CUCM servers/H.323 gateways and the gatekeeper will then use H.323 (H.225 RAS sub-protocol) signaling to facilitate the queries and responses between the two. Gatekeepers also provide more functionality than just extension-to-IP mappings. Table 3.3 lists some of the additional services that Cisco gatekeepers provide. TA B L E 3 . 3
Gatekeeper functions
Functions
Description
Calling privileges
Permits or denies calls based on source/ destination extension
Call admission control (CAC)
Limits number of calls based on bandwidth usage
Endpoint management using zones
Categorizes endpoints into zones for ease of management
Networks that implement H.323 gatekeepers will also have other H.323-specific devices to properly process steaming voice, video, and data on IP networks and bridging to PSTN signaled networks. Some additional components you should be familiar with include the following:
H.323 proxy server
H.323 Multipoint Control Unit (MCU)
Let’s briefly describe each of these and then paint a picture of what a typical H.323 network looks like.
H.323 Proxy Server H.323 proxy servers are servers that work as a head end for call setup and teardown of one or more H.323 endpoints. A proxy server provides the following benefits:
It adds security by hiding the identity of H.323 endpoints.
It can provide Quality of Service (QoS) functionality.
It can provide bandwidth reservation, using the Resource Reservation Protocol (RSVP).
It can be configured to route based on the application being used, a capability known as application-specific routing (ASR).
H.323 Multipoint Control Unit Another popular H.323 component that CVOICE candidates should be familiar with is the H.323 Multipoint Control Unit (MCU). These devices are used to control and facilitate multimedia content such as audio and video for point-to-multipoint communication.
c03.indd 91
9/21/11 11:16:30 AM
92
Chapter 3
■
VoIP Operation and Protocols
This type of communication is more commonly known as “conference calling.” An MCU is actually two separate components. One of these components is called the Multipoint Controller (MC). This is where the H.245 logical channels are set up and torn down. The Multipoint Processor (MP) is the component of the MCU that performs the convergence of audio/video streams, combining them into one stream. It also performs the translation between various codecs for compatibility. Cisco offers several Multipoint Control Units in its Videoconferencing 3500 series of products. These devices are fully compatible with Cisco IOS H.323 gatekeepers.
Cisco also offers BRI and PRI MCU gateways that connect ISDN (H.320)compatible videoconferencing systems with H.323 or SIP-compatible systems.
A Typical H.323 Network We’ve now covered the topics of H.323 gateways, gatekeepers, proxy servers, and MCUs. Figure 3.6 shows an example network layout in which these components would reside and interoperate with each other. FIGURE 3.6
Common H.323 network components
Headquarters
POTS phone
M CUCM-1
IP phone
M CUCM-2
H.323 ISDN video V H.323 proxy
PSTN H.323 ISDN terminal
H.323 terminal H.323 MCU H.323 video H.323 gatekeeper
V H.323 voice gateway
IP WAN
V H.323 voice gateway
H.323 terminal
H.323 video
IP phone
c03.indd 92
9/21/11 11:16:30 AM
Choosing the Appropriate Voice Gateway Signaling Protocol
93
In this diagram, you see a CUCM cluster that maintains IP phones. In addition, the headquarters has H.323 terminals and video hardware. An H.323 gatekeeper controls addressing information, call-admission control (CAC), and calling permissions. CAC is a feature that monitors the amount of bandwidth on a path and either permits or denies a call being established, based on the amount of bandwidth available. Once the addressing information is known via the gatekeeper, the H.323 devices at the headquarters use the H.323 proxy to place calls on behalf of them. The MCU controls multimedia conferencing applications, and the H.323 gateway communicates H.323 for transport to the remote site and translates between H.323- and H.320-capable devices located on the PSTN.
Choosing the Appropriate Voice Gateway Signaling Protocol Choosing the right voice gateway signaling protocol for a particular environment is an important decision to make. There are several factors to consider when making this decision, including these:
Voice/video equipment and vendors that will be used
Call control distribution desired
Voice signaling architecture desired
Looking at the fi rst factor, you must take a look at the endpoints and voice/video hardware that you will be using on your network. Do you have endpoints that will only support H.323, such as some legacy videoconference equipment? Will this be an all-Cisco implementation or a mixed-vendor environment? If it is a mixed environment, then you should avoid using SCCP as your gateway signaling protocol, because it is proprietary Cisco technology. Second, do you want to have a centralized or distributed call-control design model? Centralized call-control systems are nice because of their ease of management. Most large voice networks use a centralized call-control model. On the other hand, distributed callcontrol models help to prevent failure because call-control information is pushed out to multiple voice gateways instead of being centralized. Distributed call-control models also allow for more flexibility and allow for call control to act differently for each area of your voice network. Finally, you must consider how you want your signaling protocol to act between devices. In point-to-point architectures, the protocol treats every voice device as a client, and signaling is performed directly between the two. By contrast, client-server architectures require all devices to fi rst speak to a centralized server (usually a PBX or, in Cisco’s case, a CUCM) to receive the necessary information to talk to a peer device. Also keep in mind, however, that the two P2P signaling protocols (H.323 and SIP) can be configured to act as client-server architectures using proxy servers and gatekeepers.
c03.indd 93
9/21/11 11:16:31 AM
94
Chapter 3
■
VoIP Operation and Protocols
Summary VoIP is the process of taking digitized voice, packetizing it, and placing it on an IP network for transport. There are many different protocols required to packetize voice, as you learned here. Each protocol has a role in either transporting the voice payload from the source to the destination, monitoring the voice transport stream, or providing the necessary signaling protocols required for a voice call setup and teardown. On fi nishing this chapter, you should have a solid understanding of how digital voice signals are transported in IP packet payloads using RTP and RTCP. You also learned about the various information contained within header fields and its uses. You also learned that in certain situations, you can use cRTP to shrink the IP packet header over low-speed serial links and secure packet information and data using sRTP. We then moved on to describe the four different voice gateway signaling protocols, how they work, and how they differ from each other. You also learned about the various components found within an H.323 network. Finally, you learned the various situations where one signaling protocol would be preferred and should be implemented when compared to the other.
Exam Essentials Understand RTP and RTCP with respect to voice transport. RTP and RTCP are IETF standard protocols used for the purpose of transporting real-time data over IP networks. Understand why UDP is a better Layer 4 protocol over TCP for the transport of real-time data. UDP does not provide error correction by resending lost or corrupt packets. This is ideal for voice because real-time streams cannot use retransmitted packets. In addition, UDP has less header information than TCP and therefore is more efficient on heavily used networks. Understand how cRTP shrinks voice packets and when it should be implemented. IP/RTP/ UDP headers contain a certain amount of static information. cRTP shrinks packets by not sending this information across the network. cRTP should be used only on serial links T1 in size or lower. Also, you must carefully watch CPU utilization of the router running cRTP, because it can be very CPU intensive. Understand how sRTP can protect voice data. sRTP provides authentication, message integrity, encryption, and replay protection when enabled between two voice gateways. Understand the two different call agent and voice gateway models. Call agents can have either an integrated voice gateway or a separated voice gateway. In the case of a separated voice gateway, a voice gateway signaling protocol must be used for communication between the two devices. Understand the four types of gateway signaling protocols. H.323, SIP, MGCP, and SCCP are the four gateway signaling protocols found on Cisco voice gateways.
c03.indd 94
9/21/11 11:16:31 AM
Written Lab 3.1
95
Know the characteristics of H.323. H.323 is an ITU-T standard protocol that uses a point-to-point architecture with distributed call control. Know the characteristics of SIP. SIP is an IETF standard protocol that uses a point-topoint architecture with distributed call control. Know the characteristics of MGCP. MGCP is an IETF standard protocol that uses a client-server architecture with centralized call control. Know the characteristics of SCCP. SCCP is a Cisco proprietary protocol that uses a client-server architecture with centralized call control. Understand the purpose of gatekeepers. A gatekeeper’s primary function is to maintain a database of telephone extensions to IP address mappings. Understand the purpose of an H.323 proxy server. services for call setup and teardown.
An H.323 proxy server provides
Understand the purpose of an H.323 MCU. An H.323 MCU provides functionality used for point-to-multipoint conference-calling features. Know when to choose one voice gateway signaling protocol over another. Factors such as hardware used, features needed, and ease of administration factor into selecting a voice gateway signaling protocol for a particular environment.
Written Lab 3.1 1.
What protocol provides out-of-band data collection for streaming data QoS purposes?
2.
Which UDP ports are RTP packets commonly sent on?
3.
If an RTP stream resides on UDP 20012, what is the most likely UDP port number used by RTCP?
4.
cRTP shrinks which three headers?
5.
What is the H.323 sub-protocol that specifies call setup and codec negotiations?
6.
What is the IETF standard protocol that uses a P2P signaling architecture with distributed call control?
7.
In a voice gateway configured to use MGCP, where does all of the call-control information reside?
8.
A voice network uses a mixture of Cisco and non-Cisco equipment for its voice gateways. Which signaling protocol is automatically excluded from consideration when choosing a gateway signaling protocol?
9.
Which H.323 MCU component is responsible for combining multiple real-time streams from multiple sources into a single stream for transport to recipients?
10. What voice functionality monitors destination extensions for new call requests and
permits or denies them based on the amount of bandwidth available? (The answers to Written Lab 3.1 can be found following the answers to the review questions for this chapter.)
c03.indd 95
9/21/11 11:16:32 AM
Chapter 3
96
■
VoIP Operation and Protocols
Review Questions 1.
Which of the following are not information required to be inside a voice IP packet for transport on an IP network? (Choose all that apply.) A. Source and destination IP address
2.
B.
Source and destination MAC
C.
RTP header information
D.
QoS information
RTP was designed and developed by the IETF to be used with which Layer 4 transport protocol? A. Q.921
3.
B.
TCP
C.
UDP
D.
Q.931
How many RTP connections are required for a two-way voice call between IP phones? A. One
4.
B.
Two
C.
Four
D.
Eight
Which of the following voice gateway signaling protocols uses a centralized call-control model? (Choose all that apply.) A. MGCP
5.
B.
SIP
C.
SCCP
D.
H.323
An RTCP stream has set up a connection on UDP port 1955. What is its companion RTP stream UDP port likely to be? A. 20 B.
c03.indd 96
22
C.
1954
D.
1956
9/21/11 11:16:32 AM
Review Questions
6.
97
You have just implemented voice on your IP network and noticed that some calls properly connected while others were never established. Of the following choices, which one is likely to be the problem? A. Misconfiguration of a voice gateway signaling protocol.
7.
B.
A firewall between the source and destination IP phones is blocking a portion of possible RTP UDP ports.
C.
cRTP is causing the router CPU to spike and is dropping calls.
D.
The RTP connection is made but RTCP fails, which is responsible for the transport of voice payloads.
Which of the following RTCP packets contains information about the host device, including CNAME, username, email address, and other data? A. Sender Report
8.
B.
Source Description
C.
Application-Specific
D.
Receiver Report
What size is an uncompressed RTP header? A. 8 bytes
9.
B.
8 bits
C.
12 bytes
D.
12 bits
Which of the following is not an RTCP packet? A. Hello B.
Application-Specific
C.
Source Description
D.
Goodbye
10. RTCP is used for collecting all of the following except what? A. Payload size B.
Packet count
C.
Packet loss
D.
Variation delay
11. When is it recommended to implement cRTP? A. On LAN interfaces 10 Mbps and higher
c03.indd 97
B.
On LAN interfaces 10 Mbps and lower
C.
On WAN interfaces T1 speeds and higher
D.
On WAN interfaces T1 speeds and lower
9/21/11 11:16:33 AM
Chapter 3
98
■
VoIP Operation and Protocols
12. sRTP provides all of the following security features except what? A. Authentication B.
Replay protection
C.
Authorization
D.
Payload encryption
13. If an administrator wants to use sRTP for authentication, message integrity, and replay protection but does not want the payload data encrypted, what can he do? A. Disable sRTP for all RTCP packets. B.
Enable cRTP, which forces encryption to be disabled.
C.
Use a NULL cipher to disable encryption.
D.
Encryption must be enabled when using sRTP.
14. If sRTP is enabled on a voice gateway, which of the following two cannot be used? (Choose all that apply.) A. RTP B.
RTCP
C.
cRTP
D.
SIP
15. What is the purpose of a voice gateway signaling protocol? A. A signaling mechanism for call setup and teardown B.
To transport voice payloads
C.
To track statistics for QoS tuning
D.
A signaling mechanism used for call admission control
16. What H.323 sub-protocol performs a media channel setup for the transport of voice or video? A. H.225 B.
H.450
C.
H.245
D.
Q.931
17. Which of the following is true for a voice gateway configured with MGCP? A. It monitors QoS statistics. B.
c03.indd 98
It manages phone extension–to–IP address mappings.
C.
It performs call setup and signaling.
D.
It shares information with the call processing agent in a distributed call control model.
9/21/11 11:16:33 AM
Review Questions
99
18. When an IP phone initiates a call, it communicates with an intermediary server that handles the call setup and teardown of that communication. What type of voice equipment is this server? A. Gatekeeper B.
User Agent Server (UAS)
C.
Proxy
D.
MCU
E.
User Agent Client (UAC)
19. A network is configured to use SCCP as its voice gateway signaling protocol. IP phone A calls IP phone B across the voice gateway. How will the voice packets flow through the network? A. Voice packets leaving the source are sent to a proxy server and then to the destination device. B.
Voice packets leaving the source are sent to a gatekeeper server and then to the destination device.
C.
Voice packets leaving the source are sent to a call processing agent (such as a CUCM) and then to the destination device.
D.
Voice packets leaving the source are sent directly to the destination device.
20. What is the name for the feature that monitors the amount of bandwidth on a path and either permits or denies a call from being established based on the amount of bandwidth available? A. CAC
c03.indd 99
B.
QoS
C.
MCU
D.
RTCP
9/21/11 11:16:33 AM
100
Chapter 3
■
VoIP Operation and Protocols
Answers to Review Questions 1.
B, D. MAC addresses are found in frames and not packets. Additionally, while QoS information can help to ensure better call quality, it is not required information.
2.
C. RTP was developed to work with UDP because of its small header footprint and lack of retransmission functionality, and cannot be used for transporting real-time traffic.
3.
B. A single RTP stream provides real-time transport between a source and destination. If two-way communication is needed, two RTP streams must be established.
4.
A, C. Both MGCP and SCCP keep the call control information on the call-processing agent that centralizes call control.
5.
C. RTP and RTCP ports are randomly selected between UDP 163854 and 32767. RTP streams are, by default, always even numbered. The RTCP port then will choose the nexthighest odd-numbered port that the RTP port has selected.
6.
B. The most likely problem is that a fi rewall has been misconfigured and is blocking a portion of the UDP ports that a RTP/RTCP session can randomly choose when establishing new connections.
7.
B. The Source Description packet contains various items of descriptive information about the sending voice device that is transmitting an RTP stream.
8.
C. An uncompressed RTP header is 12 bytes and contains 10 fields.
9.
A. There is no Hello RTCP packet type.
10. A. RTCP tracks information useful to QoS tuning mechanisms. Keeping track of payload sizes is not one of them. 11. D. cRTP is recommended only for T1 connections and lower. 12. C. sRTP does not use authorization security features. 13. C. sRTP can be configured to use a NULL cipher, which essentially disables encryption and sends payload traffic in cleartext. 14. A, B. If sRTP is used, it automatically enables sRTCP. That means that standard RTP and RTCP cannot be used. 15. A. Voice signaling protocols are protocols used to facilitate call setup and teardown between voice gateways and between a voice gateway and a call processing agent such as a CUCM. 16. C. H.245 is the H.323 sub-protocol responsible for establishing the media channel used for the transport of voice/video. 17. C. MGCP configured on a voice gateway simply performs call setup and signaling.
c03.indd 100
9/21/11 11:16:34 AM
Answers to Review Questions
101
18. C. Proxy servers are responsible for the setup and teardown of calls for multiple endpoints for management and security purposes. 19. D. Voice payloads are sent in RTP packets, which are sent from the source device directly to the destination device regardless of the signaling protocol used. 20. A. Call admission control (CAC) is a feature in which a voice device such as a gatekeeper or proxy server can monitor the amount of available bandwidth on various links. If the amount of bandwidth required for a new call is not available, CAC will deny the call from being made as opposed to attempting to connect the call only to have poor quality as the result.
c03.indd 101
9/21/11 11:16:34 AM
Chapter 3
102
■
VoIP Operation and Protocols
Answers to Written Lab 3.1 1.
RTCP
2.
Even numbered ports between 16384 and 32767
3.
20013
4.
IP, UDP, and RTP
5.
H.225
6.
SIP
7.
At the call processing agent
8.
SCCP
9.
Multipoint processor
10. Call admission control (CAC)
c03.indd 102
9/21/11 11:16:34 AM
Chapter
4
The VoIP Path-Selection Process THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe a dial plan. ■
Describe a numbering plan.
■
Describe digit manipulation.
■
Describe path selection.
■
Describe calling privileges.
Describe the components of a gateway. ■
Describe the function of gateways.
■
Describe dial peers and the gateway call routing process.
Implement a gateway.
c04.indd 103
■
Configure dial-peers.
■
Configure digit manipulation.
■
Verify dial-plan implementation.
9/21/11 11:17:03 AM
In this chapter we begin to explore just how it is that a voice gateway makes call-routing decisions. When a call enters a voice gateway, a router must have the intelligence to use information such as source and destination telephone extensions to route the call properly out of the voice gateway to the proper destination. In addition, these telephone numbers may need to be modified on the voice gateway before forwarding the call setup information to the next destination on a voice network. This chapter will cover what dial plans and dial peers are and how to configure them. We’ll then move on to examine the difference between dial peers and call legs and explore the digit-manipulation techniques used on voice gateways.
Understanding the Dial Plan Path-Selection Process Dial plans are configured on voice gateways using dial peers to determine how calls are directed through the IP and PSTN networks. In addition to path-selection responsibilities, dial plans provide the following primary tasks: Digit Manipulation voice gateway Calling Privileges
The modification of dialed digits prior to routing a call out of the The permission or denial of a caller to certain destinations
This section will fi rst cover the different call types all voice calls can be categorized under. Next, we will examine call routing and path-selection techniques and the process of matching dial peers. Finally, we will look at path-selection strategies that can be used to streamline dial plans for ease of use and cost-savings benefits.
Understanding Voice Call Types Voice calls are categorized into call types based on the location of the source and destination phones relative to the IP and PSTN networks. Depending on the type of call being made, dial plans must be configured differently to ensure optimal paths at the lowest cost. In the following diagrams of voice call types, you will see the portion of the end-to-end calls designated within a circle. Anything outside the circle is handled by the PSTN and other voice networks outside of managerial control.
c04.indd 104
9/21/11 11:17:05 AM
Understanding the Dial Plan Path-Selection Process
105
Local Calls When the source and destination phones are connected to the same call processing agent or voice gateway, it is considered to be a local call. Figure 4.1 shows an example of an IP phone calling an analog phone. Both of these endpoints use the same voice gateway, so the call is considered to be local.
F I G U R E 4 .1
A local call
Gi1/0
IP phone
FXS0/0/0
V Voice GW
Switch
Analog phone
On-Net Calls When the source and destination phones are on the same network but traverse more than one voice gateway, it is considered to be an on-network or on-net call. Because the call is carried over a private network as opposed to the PSTN, there is no per-minute cost incurred. Figure 4.2 shows the path between two IP phones located at different locations but interconnected through an IP WAN. A call made between these two phones must be processed by two voice gateways.
FIGURE 4.2
An on-net call
IP phone
Gi1/0
Switch
c04.indd 105
IP phone
S0/1
V Voice GW
IP WAN
S0/1
Gi1/0
V Voice GW
Switch
9/21/11 11:17:05 AM
106
Chapter 4
■
The VoIP Path-Selection Process
Off-Net Calls When the source and destination phones are on different networks and no IP WAN is available, the calls must traverse the PSTN to complete the call. This is considered to be an off-network or off-net call. Typically this is a situation where you have administrative control over one phone but not the other. Figure 4.3 shows an IP phone, located within a site you control, calling an analog phone located somewhere on the PSTN. The phone could be an analog or IP phone, and it could literally be located anywhere in the world. From a management point of view, you are simply responsible for the voice gateway connection to the PSTN and the dial plan for your phones, which determines when to use the PSTN connection for off-net calls. It also means that since you are using the PSTN, a per-minute cost is incurred. Typically an off-net access code is used to signal to the voice gateway or CUCM that you wish to make an off-network call. The most common access code used in this situation is the number 9.
FIGURE 4.3
An off-net call
IP phone
Gi1/0
Switch
S0/1
V Voice GW
PSTN Analog phone
On-Net-to-Off-Net Calls In situations where an on-net call cannot be made because of a WAN failure or congestion, you can configure your voice gateways to use the PSTN as a secondary (“fall-back”) path to perform off-net calls. Figure 4.4 shows the two phones in different locations. An IP WAN is the primary path, with the PSTN configured as a backup path in case of a WAN failure. Because the WAN connection between the two sites has failed in Figure 4.4, the voice gateway will automatically detect the failure and use the alternate path out the PSTN.
c04.indd 106
9/21/11 11:17:06 AM
Understanding the Dial Plan Path-Selection Process
FIGURE 4.4
107
An on-net to off-net call
IP phone
IP phone WAN failure
Gi1/0
S0/1
S0/1
V S0/2 Voice GW
Switch
S0/2
Gi1/0
V Voice GW
Switch
PSTN
PBX-to-PBX Calls In some situations, you may need to integrate legacy PBX equipment. In fact, you may fi nd more than one PBX in use, or you may be in the process of migrating from a legacy PBX to a CUCM. In either case, a PBX-to-PBX situation will exist, in which calls have to be transported from one PBX to the other, depending on which PBX is controlling certain phones. The PBX gear is commonly interconnected using private T1 circuits in either a tie line or a trunk circuit. The difference between a tie line and a trunk is that a trunk line is dedicated and continuously in an active state, while a tie line circuit is brought up only when it is needed. Figure 4.5 shows an example of two analog phones that are supported by separate PBX systems interconnected by a T1 tie line.
FIGURE 4.5
A PBX-to-PBX call
Tie line Analog phone
c04.indd 107
PBX
PBX
Analog phone
9/21/11 11:17:06 AM
108
Chapter 4
■
The VoIP Path-Selection Process
Intercluster Trunk Calls Chapter 1, “An Introduction to Traditional Telephony and Cisco Unified Communications,” discussed various CUCM deployment models. In the “geographical diversity” deployment model, multiple CUCMs are segregated in a way similar to the inter-networking of services model, but the CUCM call-processing agents are clustered together to function as a single unit. Cisco IP phones register with the cluster, and the signaling information is sent across an intercluster trunk. Figure 4.6 shows a typical intercluster trunk call made by a phone at one site calling a phone at a second site over the IP WAN. The call setup signaling is transferred between the CUCMs at each site in order to establish the call.
FIGURE 4.6
An intercluster trunk call
M
Cluster
M
V
IP WAN
V
Path Selection and Call Routing Now that you have an understanding of the different call classifications on a network, we can begin to explore how voice gateways can be configured to fi rst select a path for a particular voice call and then route that call. Depending on the voice gateway used and the source and destination endpoints, the voice gateway will have to choose between POTS ports or IP LAN/WAN to route across. To enable the voice gateway to make the correct choice, the voice network administrator configures POTS dial peers for analog/digital interfaces and VoIP dial peers for LAN/WAN ports.
POTS and VoIP Dial Peers Voice gateway routers that use distributed call control models such as H.323 and SIP are configured with dial peers to instruct the router about where they need to send voice traffic
c04.indd 108
9/21/11 11:17:07 AM
Understanding the Dial Plan Path-Selection Process
109
based on the telephone number dialed. The two primary types of dial peers that can be configured to route calls on voice gateways are POTS and VoIP.
POTS Dial Peers A POTS dial peer provides routing information for connecting to traditional telephony devices such as analog phones, fax machines, and any off-network calls that are routed out to the PSTN using either analog or digital interfaces connected to the voice gateway. Dial peers are configured using the dial-peer voice command, followed by an identifying number that represents the rule. Keep in mind that the number indicated in the dial-peer voice command does not have to match the destination-pattern command and is simply used to distinguish between multiple dial peers configured on your voice gateway. The pots keyword is then used to specify that this is a POTS dial peer. The destination-pattern command is then used to identify the telephone number the rule is to match on. Finally, the port command is used to specify the port where the voice traffic will exit. An example of POTS dial peers looks like the following: Router#configure terminal Router(config)#dial-peer voice 5001 pots Router(config-dial-peer)#destination-pattern 5001 Router(config-dial-peer)#port 0/0/0 Router(config-dial-peer)#exit Router(config)#dial-peer voice 5002 pots Router(config-dial-peer)#destination-pattern 5002 Router(config-dial-peer)#port 0/0/1 Router(config-dial-peer)#end Router#
Here we have configured two different POTS dial peers. The fi rst dial peer is identified as 5001 and maps telephone extension 5001 to analog port 0/0/0. The second dial peer (5002) maps telephone extension 5002 to analog port 0/0/1.
VoIP Dial Peers VoIP dial peers connect to voice devices that are IP capable. A VoIP dial peer could point directly to a voice IP endpoint such as an IP phone, or it could point to a second IP voice gateway, call-processing agent, or gatekeeper connected through a LAN or WAN. Like their POTS equivalents, VoIP dial peers also use the dial-peer voice command followed by a numerical rule identifier, but they use the voip keyword (instead of pots) to identify the rule as an IP rule and not a POTS rule. The destination-pattern command is identical to its use with the POTS dial peer. Finally, the session target command is used to identify the location of the next-hop IP where the voice endpoint is known to reside. Following is an example of VoIP dial peer configurations: Router#configure terminal Router(config)#dial-peer voice 5002 voip
c04.indd 109
9/21/11 11:17:07 AM
110
Chapter 4
■
The VoIP Path-Selection Process
Router(config-dial-peer)# destination-pattern 5002 Router(config-dial-peer)#session target ipv4:192.168.1.100 Router(config-dial-peer)#exit Router(config)#dial-peer voice 5003 voip Router(config-dial-peer)# destination-pattern 5003 Router(config-dial-peer)#session target ipv4:192.168.1.101 Router(config-dial-peer)#end Router#
Here we have configured two VoIP extensions. 5002 is the fi rst VoIP dial peer extension, and it is mapped to an IP address of 192.168.1.100. The 5003 extension is mapped to 192.168.1.101. The router then uses the IP routing table to locate the LAN/WAN interface where the IP address is known to be located.
You can see that in the VoIP dial peer, the session target address must be specified as either ipv4:, ipv6:, or dns:.
The key thing to remember about POTS and VoIP dial peers is that for every voice gateway that is traversed, a physical dial-peer configuration is required so the voice gateway knows how to accept the calls coming into the gateway and where to send them as they leave it. For example, let’s use Figure 4.7 to show where dial peers are required to complete and end-to-end call. F I G U R E 4 .7
POTS and VoIP dial peer example
PSTN
IP WAN
PSTN
V
V
Analog phone
POTS dial peer
Analog phone
VoIP dial peer
VoIP dial peer
POTS dial peer
From the analog phones to the voice gateways, one dial peer is required. Yet two VoIP dial peers are needed to traverse the IP network. One VoIP dial peer is configured outbound on the voice gateway so it knows where to send the call, and a second VoIP dial peer is needed so the receiving gateway can properly accept the call.
Call Legs If dial peers are the physical representation of call routing on voice gateways, then call legs are the logical counterpart. Call legs are the one-way connection of a call setup between two voice gateways. Just like dial peers, call legs are either POTS legs or VoIP legs,
c04.indd 110
9/21/11 11:17:08 AM
Understanding the Dial Plan Path-Selection Process
111
depending on the part of the network the logical leg represents. For example, in Figure 4.8 we have Analog-Phone-A making a call to Analog-Phone-B across both the PSTN and IP networks. FIGURE 4.8
POTS and VoIP call legs
PSTN
IP WAN V
Analog-Phone-A
Inbound POTS call leg
PSTN V
Analog-Phone-B
Inbound VoIP call leg
Outbound VoIP call leg
Outbound POTS call leg
As you can see, the one-way call-leg communication follows the physical dial-peer representation. That is to say, any voice gateway must have two call legs associated with it for every call that is to be processed.
Path-Selection Strategies A voice gateway must match two dial peers in order to receive and then transmit calls to the proper destination. Both the inbound and outbound dial peers must match one of the configured dial peers. In addition, the rules used to select the best dial peer have a hierarchical order of precedence. In the event of a tie or when no match can be made using the configured dial peers, there are tie breakers and a default dial peer that can be used to make a fi nal path-routing decision.
Inbound Dial-Peer Rules When a call arrives on an interface coming into a voice gateway, an inbound dial peer must be matched. The inbound dial-peer rules that follow are checked in the order shown. As soon as a match is made, the call is immediately routed and no other rules are checked. DNIS Number Dialed Number Identification Service (DNIS) interfaces are checked in an attempt to match a dial peer with the telephone number that was dialed. When a user picks up a phone and dials 555-5555, this number is the destination telephone number that the user wishes to reach. The voice gateway will use DNIS to match the dialed number to a configured dial-peer rule. The command used to configure dial peers to match DNIS information is incoming called-number. This command is used only on inbound dial peers.
c04.indd 111
9/21/11 11:17:09 AM
Chapter 4
112
■
The VoIP Path-Selection Process
ANI Number Automatic Number Identification (ANI) is the exact opposite of DNIS. The ANI field is commonly used for billing purposes and cannot be modified. The telephone number matched against dial-peer rules here is the calling party’s number. That means that when a user picks up a phone that has the number 555-4444, the originating phone number is used for matching purposes. The answer-address command is used to configure dial peers to match ANI information. DNIS Number (again) This might sound confusing, but for inbound dial peers, DNIS information can either be configured using the incoming called-number as stated earlier, or it can be checked using the destination-pattern command. This command can be used by both inbound and outbound dial peers, and this rule is checked after any ANI rules. Inbound Port The port interface can be used to match POTS calls that come into the voice gateway. The command used to configure dial peers to match port interface information is port.
It is possible that there may be multiple dial peers configured that match, creating a tie within the rule system. If this were to occur, the voice gateway will use the dial-peer rule that is configured first. Because of this top-down rule-tie selection process, you must be careful as to the order in which you configure your various dial peers.
Default Dial Peer 0 If no inbound matches are made using configured dial-peer rules, the voice gateway will use a built-in “catch-all” rule that is often referred to as dial peer 0. While it is nice to have a default dial peer to ensure that calls are not dropped inbound, the dial-peer rules are not optimal for your voice network. For example, consider the following rules that the voice gateway will use in the event a call is only matched using dial peer 0:
It must use the g.729r8 codec for VoIP dial peers.
There is no Resource Reservation Protocol (RSVP) support for VoIP dial peers.
The QoS preference is 0.
Fax-relay is disabled.
It cannot use DTMF relay for either POTS or VoIP calls.
There is no direct inbound dial (DID) forwarding support.
There is no Interactive Voice Response (IVR) support for POTS dial peers.
As you can see from this list of dial-peer 0 rules, the voice gateway restricts many important features. That is why it is important to ensure that your voice gateways are properly set up to match real inbound dial peers.
Outbound Dial-Peer Rules Compared to inbound dial-peer rules, outbound dial-peer rules are relatively straightforward. Outbound dial peers are matched using the destination-pattern command only. In addition,
c04.indd 112
9/21/11 11:17:09 AM
Understanding the Dial Plan Path-Selection Process
113
dial peer 0 cannot be used. Again, the destination-pattern command matches the remote called number with either the remote IP address destination or outbound POTS port.
Introduction to PSTN and Private Numbering Plans Before you begin configuring a dial plan strategy for your voice network, it is important to fully understand current PSTN numbering plan rules. These rules must be properly followed if you wish to make off-net calls. PSTN numbering plans are telephone digit rules that were created at national and international levels to ensure consistency and phone number coverage where needed. As telephone systems grew over the decades, it was soon discovered that a national and international hierarchy system was needed to organize numbers for the following reasons: Conformance to Standards For telephone networks to work properly at a regional, national, and international level, dial plans must follow the same rules. Simplicity of Provisioning The implementation process will go more smoothly with a well-thought-out plan. Ease of Routing Calls Having a hierarchy within numbering plans will limit the telephone number routing tables. Numbers can be more easily routed geographically by nation or by an area within a specific country. Ease of Growth A well-planned numbering hierarchy can set aside blocks of numbers that can be used for future growth where additional telephone numbers are required. Ease of Management A hierarchical system provides for well-defined management boundaries. Control within those boundaries can be handled independently. Clarity to End Users use the system.
Your dial plan should make it easy for users to understand how to
The next two sections cover the current international and North American numbering plans. You will learn the numbering structure and rules that these plans are based on. Understanding these PSTN numbering plan concepts will also help you better understand private dial plan design concepts.
The International Numbering Plan The ITU developed a numbering plan that is currently used by all nations around the world. The International Numbering Plan is also known as the E.164 standard. This standard breaks a national telephone number into three different categories: Country Code (CC) Defi nes the country of origin National Destination Code (NDC) Subscriber Code (SC)
Defi nes an optional country- or region-specific code
Defi nes a central office code
Because the E.164 standard is a hierarchical model, the three codes are built on each other from least specific to most specific in pinpointing the location of the originating phone that has the telephone number in question, as shown in Figure 4.9.
c04.indd 113
9/21/11 11:17:10 AM
114
Chapter 4
FIGURE 4.9
■
The VoIP Path-Selection Process
The E.164 hierarchy Least specific
CC CC-NDC-SC
NDC SC
Most specific
Every recognized nation is assigned a unique country code that has been allocated by the ITU board. The remaining NDC and SC codes are the responsibility of each individual country to manage and allocate as they see fit. The format must meet the E.164 standards for the nation in terms of minimum and maximum digits allowed for each segment. The format rules are listed in Table 4.1.
TA B L E 4 .1
ITU E.164 formatting rules
Segment
Digit Min/Max
Country Code (CC)
1–3
National Destination Code (NDC)
0–15
Subscriber Code (SC)
1–15
In addition to these formatting rules, the maximum number of dialed digits for any international call must be less than or equal to 15 including the country code. Countries must follow this rule when developing their own national numbering plans.
To see the latest list of E.164 numbers, you can visit the ITU website at
http://www.itu.int/pub/T-SP-E.164D-2011.
The North American Numbering Plan As stated earlier, national plans are dictated by each individual nation as long as it falls within the international guidelines outlined by the ITU E.164 standard. The CVOICE
c04.indd 114
9/21/11 11:17:10 AM
Understanding the Dial Plan Path-Selection Process
115
exam focuses on the North American Numbering Plan (NANP) as the example national plan for use throughout the exam.
Structure of the NANP Like the E.164 standard, the NANP also uses a three-step hierarchy scheme, as shown in Figure 4.10.
F I G U R E 4 .1 0
The NANP hierarchy Least specific
Area Area-CO-Subscriber
CO Subscriber
Most specific
The NANP uses a fixed 10-digit format for all numbers throughout the region. Table 4.2 lists each of the three NANP hierarchy segments and numbering rules.
TA B L E 4 . 2
NANP structuring rules
Segment
Description
Number of Digits
Number Formatting
Area code
Defined by geographic location
3
[2–9][0–8][0–9]
Central office code
Defined by the CO the phone terminates at within a specific area
3
[2–9][0–9][0–9]
Subscriber code
A number that is locally unique within the CO code
4
[0–9][0–9][0–9][0–9]
You will notice that the number formatting for both the area code and CO code omits some digits from use. Also, there is an NANP rule that states the CO code can never be X11, where X is any number 2–9. This is because X11 codes are used for government services. Table 4.3 lists the X11 services in use today.
c04.indd 115
9/21/11 11:17:11 AM
116
Chapter 4
TA B L E 4 . 3
■
The VoIP Path-Selection Process
NANP X11 services
Reserved Number
Description
011
International access code
211
Community government information
311
City government information
411
Local/national directory assistance
511
Traffic and road conditions
611
Telephone repair service information
711
Hearing-disabled relay service
811
Underground pipe safety service
911
Emergency services
The most important and widely known X11 code in the NANP is for emergency services (E.911), which will be discussed in greater detail in Chapter 6, “Configuring Voice Gateway Ports and DSPs.” For now, simply know that they are treated differently on the PSTN.
Private Numbering Plan Considerations Private numbering plans are also critical when planning a voice network. The way you address endpoints with telephone numbers can impact dial-peer configuration complexity and scalability on your private network. The following sections identify design strategy characteristics that must be carefully addressed when planning a private numbering plan:
PSTN DID Support When planning a private numbering plan, it is usually best to work from the outside in. This means you should fi rst look at PSTN access into the private network. In many situations, companies purchase blocks of publicly routable telephone numbers from their PSTN. These numbers can often be truncated to use the last four to five digits internally as extensions. This is referred to as direct inward dial (DID). If DID is to be used, it should be the fi rst piece of the private addressing puzzle to investigate because these numbers will have to be broken into blocks as possible depending on the number of sites and endpoints on the network.
c04.indd 116
9/21/11 11:17:12 AM
Understanding the Dial Plan Path-Selection Process
117
Access Code Support The next factor that should be planned out is access code support. Access codes are special digit combinations that are used to signal the call-processing agent of a special-case dialing instruction. For example, when most businesses wish to call an off-network phone, they typically fi rst dial a 9 and then the telephone number. The number 9 therefore is an access code, and internal numbers should never begin with this particular number.
Number of Sites Next on the private numbering plan design list is determining the number of sites you need to consider in a single voice network. Large enterprises may consist of multiple campus sites and remote offices. Each of these remote sites should be accounted for when determining a private numbering plan.
Number of Endpoints at Each Site Lastly, you must determine the number of endpoints at each site. If you have a mixed IP and analog environment, all of these endpoints must be considered, because anything that requires a telephone number will have an impact on the number of private extensions reserved at every site.
When developing a private numbering plan, always be aware of future growth on your network. It is advisable to get an impression from upper management of possible business growth strategies to address situations where your main campus site expands rapidly or additional remote sites pop up. Armed with knowledge of future plans, you can better organize a numbering plan that will work both today and into the future.
Using Wildcards to Simplify Dial-Peer Configurations Dial peers can be configured to match exact telephone numbers or a range of numbers. Configuring dial peers to match a single telephone extension does not scale well when you have a network with hundreds or thousands of phones. If you were to attempt this on a large voice network, you would quickly see the benefits of dial-peer-matching multiple telephone extensions in a single rule. Cisco has developed a series of wildcard characters that can be used when configuring the destination extensions with the destination-pattern command, which can match on multiple extensions in a single rule. Using different wildcards results in different extensions being matched, so it is important to understand what each of the wildcard characters mean. Table 4.4 lists wildcard characters that are supported by the destination-pattern dialpeer command.
c04.indd 117
9/21/11 11:17:12 AM
118
Chapter 4
TA B L E 4 . 4
■
The VoIP Path-Selection Process
Destination pattern wildcard characters
Wildcard Character
Description
.
A single digit wildcard. Digits can be 0–9 and *.
[]
Either a consecutive range of digits using a hyphen (-) or a nonconsecutive range using a comma (,). A combination of - and , can be used in the same rule.
()
Matches a specific pattern. This can be used along with the ?, %, or + characters.
?
Used to show that the preceding digit occurred zero or one time only.
%
Used to show that the preceding digit occurred zero or more times.
+
Used to show that the preceding digit occurred one or more times.
T
Known as the “interdigit timeout.” It is used to show that the router will wait a period of time to collect all digits entered. The digits can be 0–9 and *. The router will collect digits for 15 seconds or until the # key is pressed.
If there are dial peers that match multiple rules, the most explicit rule is chosen over the one that utilizes more wildcard rules. Also, in most situations (SCCP and Enhanced SIP) the dial peers are matched on a digit-by-digit basis. As each digit is dialed, the voice gateway attempts to match it with the first exact dial peer possible. This can be confusing if, for example, you have 4000 as a destination pattern but are attempting to call extension 40001.
Using this wildcard information, let’s create some dial-peer rules to see how various wildcards work using a few common examples:
Example 1: Matching Digits Using . Let’s say you are working on your primary site’s voice gateway (VG1) and need to create a VoIP wildcard to support telephone extensions between the numbers 4000 and 4999, as shown in Figure 4.11.
c04.indd 118
9/21/11 11:17:13 AM
Understanding the Dial Plan Path-Selection Process
F I G U R E 4 .11
IP phone
IP phone
119
Wildcard example 1
Extensions: 5XXX V VG1
Extensions: 4XXX IP WAN
V VG2
IP phone
IP phone
IP phone
IP phone
Because all extensions in the 4XXX range are in one location, you can use the . (period) wildcard to create a single VoIP destination pattern as follows: Router#configure terminal Router(config)#dial-peer voice 4000 voip Router(config-dial-peer)# destination-pattern 4... Router(config-dial-peer)#session target ipv4:192.168.1.5 Router(config-dial-peer)#end Router#
Example 2: Matching Digits Using [ ] In our next example, you again are configuring a voice gateway (VG1) at your primary site. This time, however, the 4XXX range of numbers is not exclusive to your remote site. Only the digits 4300 to 4999 are available at the site, as shown in Figure 4.12. F I G U R E 4 .1 2
IP phone
IP phone
IP phone
c04.indd 119
Wildcard example 2
Extensions: 4000-4299 V VG1
Extensions: 4300-4999 IP WAN
V VG2
IP phone
IP phone
IP phone
9/21/11 11:17:14 AM
120
Chapter 4
■
The VoIP Path-Selection Process
In this case, you can use a combination of [ ] and . wildcards to designate the destination pattern, as shown here: Router#configure terminal Router(config)#dial-peer voice 4300 voip Router(config-dial-peer)# destination-pattern 4[3–9].. Router(config-dial-peer)#session target ipv4:192.168.1.5 Router(config-dial-peer)#end Router#
Example 3: Matching Digits Using the ( ) Wildcards with ?, %, and + The ( ) wildcard matches various patterns found within a telephone number. The best way to explain these patterns is to give you a few examples using the other wildcards that can be used in conjunction with ( ). This fi rst example uses the ? character, which means the pattern within the ( ) is matched zero or one time: Router#configure terminal Router(config)#dial-peer voice 9999 voip Router(config-dial-peer)# destination-pattern 54(11)? Router(config-dial-peer)#session target ipv4:192.168.1.5 Router(config-dial-peer)#end Router#
The pattern 54(11)? means that the dial peer will trigger a match either with 54 or 5411 only. The next example will use the % wildcard, which means that any digits inside the ( ) will occur 0 or more times: Router#configure terminal Router(config)#dial-peer voice 9999 voip Router(config-dial-peer)# destination-pattern 54(11)% Router(config-dial-peer)#session target ipv4:192.168.1.5 Router(config-dial-peer)#end Router#
So now, the dial peer will be triggered on 54, 5411, 541111, 54111111, and so on, until 32 digits have been reached. Lastly, we’ll use ( ) with the + wildcard, which means that the dial peer must match on the digits inside the ( ) at least one or more times: Router#configure terminal Router(config)#dial-peer voice 9999 voip Router(config-dial-peer)# destination-pattern 54(11)+
c04.indd 120
9/21/11 11:17:14 AM
Understanding the Dial Plan Path-Selection Process
121
Router(config-dial-peer)#session target ipv4:192.168.1.5 Router(config-dial-peer)#end Router#
In this example, a match will be made on 5411, 541111, 54111111, and so on until 32 characters have been reached.
Example 4: Matching Digits Using T The T wildcard is a bit of a catch-all and is commonly used in situations where the administrator wants to create a dial peer for off-network calls to the PSTN. This is because PSTN calls often use varying-length telephone numbers. For example, local calls usually may only be seven digits in length, while long-distance and international calls require additional digits to complete a call. Figure 4.13 describes the physical setup of our voice gateways and how we wish to use the 9 digit as our trigger for all off-network calls. F I G U R E 4 .1 3
Wildcard example 3
IP phone
9T
IP phone
V Voice gateway
PSTN
IP phone
Here is the configuration needed to forward all calls beginning with 9 out the T1 PRI circuit to the PSTN: Router#configure terminal Router(config)#dial-peer voice 9 pots Router(config-dial-peer)# destination-pattern 9T Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)#end Router#
Now, anytime a user dials 9 and then any number of digits (up to 32), the router will pause and collect those digits for 10 seconds by default. The router will then pass those digits on to the PSTN through the connected T1 PRI circuit. This technique is called sitecode dialing and is described in more detail in the next section. It is important to note that this specific site-code dialing example is referred to as an off-network access code, because it is strictly used for dialing telephones outside the local voice network.
c04.indd 121
9/21/11 11:17:15 AM
Chapter 4
122
■
The VoIP Path-Selection Process
Site-Code Dialing You may find yourself in a situation where you have DID ranges that have overlapping extensions. In instances such as this, a site code can be used to identify the site of the extension you wish to connect to. For example, Figure 4.14 shows three remote sites in our voice network. F I G U R E 4 .1 4 Site-code configuration example. This approach won’t work with overlapping extensions Site 1
Site 2
IP phone
IP phone
Extensions: 3XXX
Extensions: 3XXX IP WAN
V VG1
V VG2
IP phone
IP phone
IP phone
IP phone Site 3 V
IP phone
VG3
IP phone
IP phone
Extensions: 3XXX
In addition to the diagram, Table 4.5 shows the DID ranges and four-digit extensions that are to be used in the example. TA B L E 4 . 5
c04.indd 122
DID ranges and extensions
Site Name
DID Numbers
Four-Digit Extensions
Site 1
222–555–3XXX
3XXX
Site 2
333–555–3XXX
3XXX
Site 3
444–555–3XXX
3XXX
9/21/11 11:17:15 AM
Dial-Plan Digit Manipulation
123
Clearly, there is a problem of overlapping extensions if the company wants to use a shortened extension dialing dial plan. If a user at Site 1 were to dial 3434, the voice gateway wouldn’t know if the call is intended to be a local call or a remote call to either Site 2 or Site 3. In situations like this, it is best to configure a one-digit site code that represents each site. So calls intended for Site 1 would need to be dialed as 13XXX, and calls going to Site 3 would be dialed as 33XXX.
Dial-Plan Digit Manipulation There are several circumstances in which you will need to forward a different number string than the number originally entered by the user. You have already seen two examples of this. The first was off-network dialing, when the user enters the number 9 to indicate an offnetwork call followed by the actual phone number. The voice gateway cannot simply forward that number onto the PSTN network. Instead, it must remove the 9 prior to forwarding the digits. A second was illustrated by the site-code dialing example in the last section. Here again, the site-code digit must be stripped off before sending the extension to the remote voice gateway. Phone number strings can be manipulated to add, remove, and substitute numbers for various purposes. Voice gateways collect digits using dial-peer rules as described earlier. As you’ve seen, these rules can be exact telephone extension matches or use any possible variation of wildcards. Again, the collected telephone digits are matched using the destinationpattern command within a dial-peer rule. Within this same rule, the digits can be manipulated using a variety of commands:
Digit stripping
Forwarding the last X number of digits
Prefi x adding
Number substitution
Translation rules and profi les
The manipulated digits are then forwarded on to the POTS port or IP address, depending on whether the rule is a POTS or VoIP dial peer.
Digit Stripping Digit stripping is the process of removing digits that are explicitly defi ned in dial-peer rules. For example, consider the following POTS dial-peer rule: Router#configure terminal Router(config)#dial-peer voice 5000 pots Router(config-dial-peer)# destination-pattern 5... Router(config-dial-peer)# port 0/0/0:23
c04.indd 123
9/21/11 11:17:16 AM
124
Chapter 4
■
The VoIP Path-Selection Process
Router(config-dial-peer)#end Router#
By default, digit stripping is enabled and only the wildcard digits will be passed on. If a user were to dial 5777, the voice gateway would match on this dial peer but strip off the 5 and only pass on the digits 777 out the T1 PRI port. If you want to pass on all digits including those explicitly defi ned, you must use the no digit-strip command as follows: Router#configure terminal Router(config)#dial-peer voice 5000 pots Router(config-dial-peer)# destination-pattern 5... Router(config-dial-peer)# no digit-strip Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)#end Router#
Now when a user dials 5777, the string pattern will again be matched by this dial peer, but this time the entire 5777 string will be forwarded out the voice gateway on the T1 PRI port.
Forwarding the Last X Digits In addition to using the no digit-strip command to forward explicitly defi ned digits in your destination-pattern dial peer rule, you can use the forward-digits command. This command specifies the number of digits that should be forwarded out of the voice gateway. If the caller enters digits above the set number, it will send the last dialed digits. In the fi rst example of this technique, you will see how the previous example can use the forwarddigits command to send all four digits including the three wildcard numbers: Router#configure terminal Router(config)#dial-peer voice 5000 pots Router(config-dial-peer)# destination-pattern 5... Router(config-dial-peer)# forward-digits 4 Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)#end Router#
So as you can see, the forward digits 4 command will accomplish the exact same goal that the no digit-strip command did. A second example shows that the digit forwarding command can strip off any number of digits that the caller fi rst enters. Consider the following example: Router#configure terminal Router(config)#dial-peer voice 999 pots Router(config-dial-peer)# destination-pattern 835.......
c04.indd 124
9/21/11 11:17:16 AM
Dial-Plan Digit Manipulation
125
Router(config-dial-peer)# forward-digits 7 Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)#end Router#
In this example, we have a dial-peer pattern that will collect 10 digits. The fi rst 3 digits (835) are explicit and the other 7 digits are wildcards. Using the forward-digits 7 command, the voice gateway will only forward the last 7 wildcard digits. As you can see from this example, the forward-digits command is more flexible than the no digit-strip command; it can strip off both explicit and wildcard digits instead of only explicit digits.
Prefix Adding In the opposite direction from the forward-digits command, digits can also be added to the beginning of a number string before it is forwarded out the voice gateway. This is known as prefi x adding. A very common example of this is when the voice gateway needs to forward the destination pattern to a PBX, which in turn forwards the string out to the PSTN. If the PBX requires an off-network access code such as the number 9, you could educate your users to dial 9 for this situation. Alternatively, you can add the digit at the voice gateway using the prefix command as shown here: Router#configure terminal Router(config)#dial-peer voice 9 pots Router(config-dial-peer)# destination-pattern 1.......... Router(config-dial-peer)#no digit-strip Router(config-dial-peer)# prefix 9, Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)#end Router#
Notice the comma in the prefix 9, command here. The comma is used to trigger a pause when forwarding digits onto the destination. This is to help the destination PBX have enough time to secure an outside line prior to receiving the actual dial string.
This dial-peer rule will look for callers entering a 1 followed by a 10-digit wildcard. The no digit-strip command is used so the explicit 1 is forwarded out of the voice gateway. In addition, a 9 will be added to the beginning of the dial string with the prefix 9,
command. So, for example, if a user enters 15554441418, the dial-peer rule will match the string. The voice gateway will then forward the following string: 9,15554441418.
c04.indd 125
9/21/11 11:17:17 AM
126
Chapter 4
■
The VoIP Path-Selection Process
Number Substitution The voice gateway can collect telephone numbers and then substitute others for them before forwarding those digits to the next destination. To do this, use the num-exp command, which is also referred to as number expansion. Keep in mind that this is a global configuration command that is applied to all outbound calls. This command is often useful for when on-net calls dial the last few digits of the DID to make internal calls. But some of these calls may have to cross the PSTN and use the full-length extension. Because of this, number expansion can be used to prepend the digits so the user can continue to use shortened extension dialing. For example, let’s say you have three remote users who work from home on a full-time basis. Their PSTN numbers are as follows: 555-222 -2XXX 555-242-3XXX 555-284 - 4XXX Without number substitution, internal callers would have to dial a full 10-digit PSTN number in order to call the number. Instead, you would like them to simply dial the last 4 digits within the network. You can use num-exp to prepend the fi rst 7 digits that are required by the PSTN, as shown in Table 4.6. TA B L E 4 . 6
Number substitution example
PSTN Number
Internal Extension
555-222-2XXX
2XXX
555-242-3XXX
3XXX
555-284-4XXX
4XXX
Now that we have our internal extensions to PSTN numbers defi ned, it’s only a matter of creating number expansions and matching dial peers for each site. To do this, we use num-exp dialed-number substitution-number globally, where dialed-number is the internal extension that users will dial, and substitution-number is the number the voice gateway will actually forward on. Then we create a dial peer to match the 4-digit extension that will be dialed, matched, and modified to the full 10-digit number: Router#configure terminal Router(config)# num-exp 2... 9000 Router(config)#dial-peer voice 9000 pots Router(config-dial-peer)# destination-pattern 9000 Router(config-dial-peer)# port 0/0/2 Router(config-dial-peer)#end Router#
c04.indd 126
9/21/11 11:17:17 AM
Dial-Plan Digit Manipulation
127
This dial peer matches multiple extensions (2000 to 2999) and forwards them to a single POTS line such as an operator or automated attendant.
Protect My Internal Numbers There are some cases where you don’t want the people you are calling to know a direct telephone number but instead give a general business number. This was the case for a call center that made calls to their customers. The call center wanted to present the customer with the main telephone number to the business instead of the extension of the call center employee who happened to be calling. You can manipulate ISDN caller ID numbers using dial peers. Unique to ISDN networks is the calling-line identification, or clid, command. The ISDN Q.931 protocol is unique in that it can send two calling numbers to a voice gateway to use for caller ID purposes. The first number is the unscreened number, which the calling party actually entered into their telephone. The second is the network-provided number. Several configuration commands can be used, but the most common are shown in this example:
Router#configure terminal Router(config)#dial-peer voice 101 pots Router(config-dial-peer)#clid network-number 5555555678 second-number strip The network-number number command changes the number sent to the number provided. In this case the calling party number will be changed to 5555555678, which happens to be the primary telephone number to the business where customers are presented with an automated attendant. The second-number strip keywords will remove the network-provided number and not send anything to the PSTN. In this sense, if the customer later has a question and looks up the caller ID information, they have and can use the number provided to reach the automated attendant.
Translation Rules and Profiles A very powerful digit-manipulation rule strategy is to use translation rules and profi les. The combination of these two nested command sets lets a voice gateway administrator convert dial strings either before they are matched against an inbound dial-peer rule or after a dial-peer rule match prior to forwarding the digits out the voice gateway to the next destination. The fi rst stage is to configure translation rules, which is a two-step process. First, we defi ne translation rule sets, which can contain up to 15 individual rules. Then, once the rules are defi ned within a rule set, they can be called upon for either incoming digits before
c04.indd 127
9/21/11 11:17:18 AM
128
Chapter 4
■
The VoIP Path-Selection Process
a dial peer is matched or outgoing digits within a dial-peer rule. The translation rule must also specify which dial string (called or calling) is to be translated. Translation rule regular expressions are used within translation rules to provide an easy and structured method to match number strings. Table 4.7 lists the regular expression characters and their uses. TA B L E 4 . 7
Translation rule regular expressions
Regular Expression
Description
^
Matches at the start of a string.
$
Matches at the end of a string.
/
Designates the start and end of matching and/or replacement strings.
\
The next character in the expression rule not processed as the special character regular expression.
-
Used to indicate a range of digits.
[list]
Used to match a single character in a list.
[^list]
Used to not match a single character in a list.
.
Matches a single character.
*
Repeats the last regular expression zero or more times.
+
Repeats the last regular expression one or more times.
?
Repeats the last regular expression zero or one time.
( )
Used to group digits.
&
Indicates that all matched digits are to be added into the replacement string.
The process of creating translation rules with regular expressions can be difficult to understand at fi rst. However, once you work with them for a while, the regular expressions begin to make sense and you can see the simplified structure and true power that these rules offer. To help you better understand rule creation, we will examine some rulecreation examples.
c04.indd 128
9/21/11 11:17:18 AM
Dial-Plan Digit Manipulation
129
Translation Rule Example 1 This first example will be a simple extension-to-extension translation rule. The first command will specify the rule set identification number using the voice translation rule set-number command. The set-number is a number used to identify a translation rule set that will later be referenced by translation profiles. The second command is rule rule-number followed by the matched and translated numbers inside the / / matching and replacement regular expressions: Router#configure terminal Router(config)#voice translation-rule 1 Router(cfg-translation-rule)#rule 1 /3456/ /7890/
This rule will match the digit string 3456 and convert it to 7890.
Translation Rule Example 2 Our next example will match a NULL string. A NULL rule is used as a catch-all on voice networks to direct any unknown numbers received from the DNIS to a single extension, which is typically an operator or autoattendant. Here is the configuration to match any characters using the /^$/ regular expression that matches any digits. The rule then replaces it with extension 3000: Router#configure terminal Router(config)#voice translation-rule 2 Router(cfg-translation-rule)#rule 1 /^$/ /3000/
Translation Rule Example 3 Now things will get a bit more complex. This example will match a string and replace the middle of the collected digits. Consider the following translation rule: Router#configure terminal Router(config)#voice translation-rule 3 Router(cfg-translation-rule)#rule 1 /^\(...\)555\(....\)/ /\1792\2/
In this example we will match a 10-digit number. The / is the fi rst expression used to signify the start of the character-matching process. The ^ means that the voice gateway will look at the fi rst character entered in by the caller for matching purposes. The \ character then informs the voice gateway router to ignore the next character, which is an ( expression. Because we are not looking for an ( in the digits we are collecting, we have to tell the voice gateway to ignore it. The ( does mean the start of a digit grouping, however. Three . expressions follow, to signify that this is a wildcard where any digit can be entered for a match. That is followed by another \) set used to close the 3-digit group while telling the voice gateway to again ignore the ) from the collection process.
c04.indd 129
9/21/11 11:17:19 AM
130
Chapter 4
■
The VoIP Path-Selection Process
The next number grouping is simply looking for the exact match on the numbers 555. Lastly, we have a second grouping of four . wildcards. The / expression indicates the end of the matching statement. So in essence, our translation rule is looking to match on the following characters that are fi rst entered by a caller: (XXX)555(XXXX)
The replacement statement begins with the / expression as usual. It is then followed by \1. As you know, the \ is used to show that we will not process the next character, which is 1. The number 1 does have significance in the replacement string expression, however. This means that the first set of numbers we have inside parentheses (XXX) are to be pulled into the final replacement string as they were entered by the caller. The next digits, 792, will replace the second set of numbers, which is 555. Next we see another \ followed by a 2. This is to indicate that the second set of numbers contained within parentheses (XXXX) are also to be pulled in unmodified and are to be processed in the final number string. So if a caller were to enter in the following number: 2225554444
the output of this number would be 2227924444
If the user were to dial more than 10 digits as shown here: 112555445555
the output number would be: 1127924455
The 555 would be changed to 792 as normal, and the last two digits entered would be dropped because the ^ regular expression indicates that we begin collecting digits from the beginning of the string.
Verifying Translation Rules A great tool to verify that the translation rules you have created actually work as you want them to is the test voice translation-rule translation-rule-number test-string command. Using translation rule example 1, we can test to verify that the translationrule 1 will translate 3456 into 7890 as shown here: Router# test voice translation-rule 1 3456 Matched with rule 1 Original number: 3456 Translated number: Original number type: none Translated number type: Original number plan: none Translated number plan: Router#
c04.indd 130
7890 none none
9/21/11 11:17:19 AM
Dial-Plan Digit Manipulation
131
If we tried a number that did not match our matching rule (3456), we would receive the following: Router# test voice translation-rule 1 9999 9999 Didn’t match with any of rules Router#
Testing translation rules prior to implementing them on a production network is very important because it is easy to make a mistake. Make sure to utilize these testing methods and thoroughly test your translation rules!
Creating Translation Profiles and Applying Them to Inbound or Outbound Calls Now that you know how to configure translation rule sets and rules, you need to learn how to configure translation profi les and apply them to both inbound and outbound calls.
Configuring Translation Profiles Translation profi les reference translation rules and defi ne what number the translation rules should attempt to match against. This is accomplished using two commands. The fi rst is the voice translation-profile name command, which simply defi nes the translation profi le and uniquely identifies it with a name. Once you name the translation profile, you are then in cfg-translation-profile mode. Here you use the translate command followed by the number string type you wish to match and translate. There are three types to choose from on a voice gateway, as listed in Table 4.8. TA B L E 4 . 8
Translation profile number string types
Type
Description
called
Matches the called party’s number (DNIS)
calling
Matches the calling party’s number (ANI/CLID)
redirect-called
Matches the called party’s redirect number
Lastly, you must reference the translation rule set number that contains the translation rules you wish to use. Let’s look at an example translation profi le: Router#configure terminal Router(config)#voice translation-profile PSTN-out Router(cfg-translation-profile)#translate called 909 Router(cfg-translation-profile)#end Router#
c04.indd 131
9/21/11 11:17:20 AM
132
Chapter 4
■
The VoIP Path-Selection Process
Here we create a translation profi le named PSTN-out. Within the translation profi le configuration mode, we choose to match and translate the dial string or strings listed in translation rule set 909.
Applying Translation Profiles to Inbound and Outbound Calls A translation profi le can be assigned to POTS/VoIP dial peers or POTS interfaces. To configure translation profi les on dial peers, you must enter into dial-peer configuration mode and then use the translation-profile direction name command. The direction name can either be incoming or outgoing. The incoming option will apply the translation profi le to calls coming into the voice gateway, and outgoing will apply to calls leaving the voice gateway. The name section is where you list the name of the translation profi le you wish to use. For example, let’s configure POTS dial-peer 101 to use our PSTN-out translation profi le for outgoing calls: Router# configure terminal Router(config)# dial-peer voice 101 pots Router(config-dial-peer)# destination-pattern 2.. Router(config-dial-peer)# port 0/0/0:23 Router(config-dial-peer)# translation-profile outgoing PSTN-out Router(config-dial-peer)# end Router#
Alternatively, a translation profi le can be configured directly on a POTS port that is installed on your voice gateway. The actual translation-profile command has the exact same configuration setup and two options for application to incoming or outgoing calls on the port. In this example, we will assign translation profi le POTS-in to incoming calls of voice port 1/0:1: Router# configure terminal Router(config)# voice-port 1/0:1 Router(config-voiceport)# translation-profile incoming POTS-in Router(config-voiceport)# end Router#
Verifying Dial-Plan Configurations With all of the dial-peer configurations and numerous manipulation methods available, you need to be familiar with some show and debug commands that are useful for verifying and troubleshooting dial plans configured on your voice gateways. These commands include the following: show dial-peer voice summary
This command displays useful information about all of the configured POTS and VoIP dial peers. Here is an example of the output of this command:
c04.indd 132
9/21/11 11:17:20 AM
Dial-Plan Digit Manipulation
Router# show dial-peer voice summary dial-peer hunt 0 OPER DEST TAG TYPE ADMIN PREFIX PATTERN 10 voip up up 1.. 11 voip up up 1.. 100 pots up up 0 101 pots up up 0 Router#
PREF 1 2 0 0
PASS THRU syst syst
SESS-TARGET ipv4:192.168.10.1 ipv4:192.168.10.2
133
PORT
1/0/0 1/0/1
Using this command, you can get an overview of all your dial peers including the number tag, administrative and operational status, destination pattern, any preference configurations, and the target IP or POTS port. To get a more detailed look at a specific dial peer, you can also use the show dial-peer voice tag, where you specify the tag number. show dialplan number number-string This command displays which dial peer would be matched against a specific telephone number. This will verify that the correct dial peer will be used if you have multiple dial peers configured on a voice gateway. In this example, we will check to see which dial peer will be matched when a user dials extension 3002: Router# show dialplan number 3002 Macro Exp.: 3002 VoiceOverIpPeer6 information type = voice, tag = 2, destination-pattern = `3002’, answer-address = `’, preference=0, group = 2, Admin state is up, Operation state is up, incoming called-number = `’, connections/maximum = 0/unlimited, application associated: type = voip, session-target = `ipv4:192.168.1.2’, technology prefix: ip precedence = 5, UDP checksum = disabled, session-protocol = cisco, req-qos = best-effort, acc-qos = best-effort, dtmf-relay = cisco-rtp, fax-rate = voice,
c04.indd 133
9/21/11 11:17:21 AM
134
Chapter 4
■
The VoIP Path-Selection Process
payload size = 20 bytes codec = g729r8, payload size = 20 bytes, Expect factor = 10, Icpif = 30, signaling-type = cas, VAD = enabled, Poor QOV Trap = disabled, Connect Time = 25610, Charged Units = 0, Successful Calls = 11, Failed Calls = 0, Accepted Calls = 11, Refused Calls = 0, Last Disconnect Cause is “10 “, Last Disconnect Text is “normal call clearing.”, Last Setup Time = 84427934. Matched: 3002 Digits: 4 Target: ipv4:192.168.1.2
As you can see from the output, extension 3002 will match VoIP dial peer 6. The command output lists information including:
Operational status
Codec and QoS settings
Successful and failed calls
Destination IP address
Debug voip dialpeer If you wish to troubleshoot dial-peer matching in real time, you can use the debug voip dialpeer enable mode command to view actual calls being processed.
This is valuable when troubleshooting problems occurring on a production network. Similar to the debug voip dialpeer command, you can enable debugging on voice translations in real time to identify problems currently occurring on a production network. To turn on debugging, you can use the debug voice translation command while in enable mode.
Debug voice translation
Don’t forget to turn off debugging after you are finished with it. Debugging can use a large percentage of your router’s CPU, and it is best to disable debugging after you are finished. To disable all currently enabled debugging commands on a router, use either the no debug all or undebug all command.
c04.indd 134
9/21/11 11:17:21 AM
Exam Essentials
135
Summary As you can see from the information contained in this chapter, voice gateways play a key role in the processing and forwarding of call setup information. Voice gateways that use a distributed call control model must contain information regarding how to handle the setup of calls that come into the router. This is done by configuring dial peers that match various information contained within call-setup messages. Inbound and outbound dial-peer rules dictate what information can be used for routing. In addition, you learned how to manipulate digits before sending the information out of the voice gateway router when necessary.
Exam Essentials Understand the purpose of dial plans. Dial plans are primarily used to determine the path a voice call should take based on source and/or destination dial strings. Understand the different VoIP call types. VoIP call types differ based on location of the source and destination phones relative to the IP and PSTN networks. These include local, on-net, off-net, on-net-to-off-net, PBX-to-PBX, and intercluster trunk calls. The call types implemented typically are chosen based on the location of the source and destination phones relative to the IP and PSTN networks. Understand the difference between POTS and VoIP dial peers. POTS dial peers send traffic outbound on POTS interfaces such as FXS, FXO, and T1 interfaces. VoIP dial peers send traffic to IP network destinations. Be able to describe and Identify call legs and dial peers on a diagram. Dial peers are the physical configuration of an end-to-end call. There are VoIP and POTS dial peers. One dial peer is needed to receive incoming calls and another to route calls to a destination. Call legs, on the other hand, are logical, one-way representations of a call between two endpoints. They are also either POTS or VoIP call legs. A voice gateway must have two call legs associated for every call that is to be processed. Know the steps a voice gateway takes when choosing inbound dial-peer rules. Inbound dial peers can be matched on a number of characteristics, including DNIS, ANI, and port. If no manually configured dial peer is matched against an incoming call, dial peer 0 is matched as a last resort. Know the steps a voice gateway takes when choosing outbound dial-peer rules. Outbound dial-peer rules are matched using the destination-pattern only. There is no dial-peer 0 catch-all rule as with inbound dial-peer rules. Understand the International and NANP numbering plans. Every country follows the International Numbering Plan (E.164). This plan assigns country codes and sets the maximum number of dialed digits at 15. The NANP is the numbering plan standard used in North America, which divides a 10-digit number into three categories.
c04.indd 135
9/21/11 11:17:22 AM
136
Chapter 4
■
The VoIP Path-Selection Process
Be able to understand the different private numbering plan design considerations. Private numbering plans should always consider various organizational considerations such as DID support, access code support, number of current and future sites, and the number of current and future voice endpoints. Know how to interpret and configure dial peers using wildcards. Wildcards help to simplify dial-peer configurations by using characters to signify various dialed-number ranges. By doing so, they allow you to manually configure fewer dial peers. Know how to interpret, configure, and verify dial-peer manipulation techniques. Often, telephone number strings must be manipulated before sending them to the destination. There are several dial-peer manipulation techniques that can be used to add, remove, and replace digits to suit any need.
Written Lab 4.1 1.
When source and destination phones are connected to the same call-processing agent or voice gateway, it is considered to be what kind of call?
2.
What are the two voice-signaling protocols that require dial peers to be configured on voice gateways?
3.
What keyword is added to the end of the dial-peer voice command when the dial peer also contains the session target ipv4:192.168.1.1 command?
4.
Dial peer 0 is used when there is no specific match for what kind of dial peer?
5.
Which NANP segment is defi ned by the CO where the call terminates?
6.
Which destination pattern wildcard is used to show that a preceding digit occurs zero or one time?
7.
Using destination pattern wildcards, how can you match for the number 5 plus the number 54 that occur one or more times?
8.
Which destination pattern digit and wildcard combination is often used so users can dial off-net both nationally and internationally?
9.
Given the following destination-pattern:
Router(config-dial-peer)# destination pattern 1..........
what digit-manipulation command could you use to add a 9 and a comma before the dialed digits? 10. What command can be used to debug voice translations in real time?
(The answers to Written Lab 4.1 can be found following the answers to the review questions for this chapter.)
c04.indd 136
9/21/11 11:17:22 AM
Review Questions
137
Review Questions 1.
Which of the following is not a characteristic of a dial plan on a voice gateway? A. It determines how calls are directed through IP and PSTN networks.
2.
B.
It can provide digit-manipulation techniques.
C.
It determines how UDP is directed though IP networks.
D.
It can provide calling privilege techniques.
Which voice call type best describes when a local user inside the organization calls their home telephone number? A. Off-net
3.
B.
On-net-to-off-net
C.
PBX-to-PBX
D.
Intercluster
Which of the following does a POTS dial peer not provide routing information for? A. Local IP phones
4.
B.
Local fax machines
C.
Off-net PSTN calls
D.
Local analog phones
Given the following POTS dial peer command, what does 3030 mean? Router(config)# dial-peer voice 3030 pots
A. An identifier for the dial peer
5.
B.
The destination pattern
C.
The DNIS
D.
The ANI
Which of the following is the correct way to route outbound POTS dial peers? A. Router(config-dial-peer)# destination-pattern 4040
c04.indd 137
B.
Router(config-dial-peer)# port 1/0/1
C.
Router(config-dial-peer)# session target ipv4:192.168.1.1
D.
Router(config-dial-peer)# session target 4040
9/21/11 11:17:23 AM
Chapter 4
138
6.
■
The VoIP Path-Selection Process
Which of the following is the correct way to route outbound VoIP dial peers to 192.168.1.1? A. Router(config-dial-peer)# session target ipv4:192.168.1.1
7.
B.
Router(config-dial-peer)# session target ip:192.168.1.1
C.
Router(config-dial-peer)# destination-pattern ipv4:192.168.1.1
D.
Router(config-dial-peer)# destination-pattern ip:192.168.1.1
A VoIP call traverses a WAN connection; how many dial peers are needed to traverse the IP WAN? A. Zero
8.
B.
One
C.
Two
D.
Four
Which of the following is a one-way logical representation of a single hop along an end-to-end voice call? A. Dial peer
9.
B.
Dial plan
C.
Call leg
D.
Digit manipulation
A call is received at a voice gateway. At this point, how are inbound and outbound call legs processed? A. Only the inbound call leg is processed. B.
The outbound call leg must be matched first, followed by the inbound call leg.
C.
Only the outbound call leg is processed.
D.
The inbound call leg must be matched first, followed by the outbound call leg.
10. An IP call is received at a voice gateway. Which of the following are possible ways to match outbound dial peers? A. Default dial peer (dial peer 0) B.
answer-address
C.
incoming called-number
D.
destination-pattern
11. Which of the following number categories are required when using the E.164 numbering plan? (Choose all that apply.) A. Subscriber code B.
c04.indd 138
National destination code
C.
Country code
D.
Area code
9/21/11 11:17:23 AM
Review Questions
139
12. How many digits does a telephone number comprise within the NANP plan? A. Up to 15 digits B.
10 digits
C.
15 digits
D.
Up to 10 digits
13. What digit-manipulation technique can be used within a dial-peer statement to ensure that all digits are forwarded to the destination? A. prefix 4 B.
no digit-strip
C.
forward-digits 7
D.
destination-pattern 9T
14. What digit-manipulation technique is configured globally? A. Digit stripping B.
Translation rules
C.
Translation profiles
D.
Number expansion
15. The following destination pattern is configured in a dial peer: Router(config-dial-peer)# destination-pattern 33(22)+ Which of the following dial strings will be matched? (Choose all that apply.) A. 3322 B.
332222
C.
33
D.
33222
16. The following destination pattern is configured in a dial peer: Router(config-dial-peer)# destination-pattern 413..[3–5]. Which of the following dial strings will be matched? (Choose all that apply.) A. 4132248
c04.indd 139
B.
4134551
C.
4135328
D.
4136678
9/21/11 11:17:23 AM
Chapter 4
140
■
The VoIP Path-Selection Process
17. Which of the following are steps required to configure and implement translation rules and profiles? (Choose all that apply.) A. Configure a translation profile referencing the translation rule set. B.
Apply the translation profile to inbound and/or outbound calls.
C.
Configure a new translation rule set with rules defined.
D.
Configure an access group referencing the translation profile and apply the access group a dial peer.
18. You want to look at all of your dial peers configured on a voice gateway and issue the show dial-peer voice summary command and see the following output:
TAG 1 2 10 20
TYPE voip voip pots pots
ADMIN up up up up
OPER PREFIX up up up up
DEST-PATTERN 4... 43.. 3... 54..
PASS PREF THRU SESS-TARGET 0 syst ipv4:192.168.10.1 0 syst ipv4:192.168.10.2 0 0
PORT
1/0/0 1/0/1
Which dial peer will match 4545? A. 1 B.
2
C.
10
D.
20
19. Which of the following verification and troubleshooting commands would show information about the operational status, QoS settings, and codec used for a specific dial string? A. show dialplan number number-string B.
show dial-peer voice tag
C.
test voice translation-rule rule-number number-string
D.
debug voip dialpeer
20. Which translation rule regular expression is used to signify the start and end of a match or translation string? A. \
c04.indd 140
B.
/
C.
^
D.
[
9/21/11 11:17:24 AM
Answers to Review Questions
141
Answers to Review Questions 1.
C. UDP is a Layer 4 protocol used in the transport of IP traffic on networks. It is not a direct characteristic of dial plans.
2.
A. An internal phone that calls a phone that is not connected to the local voice network must use the PSTN. This is known as an off-net call.
3.
A. POTS dial peers handle call routing for traditional telephony devices that do not use IP. IP phones would need to use a VoIP dial peer.
4.
A. When you configure a dial peer, it must have a unique tag identifier associated with it that is used to differentiate it from other POTS and/or VoIP dial peers.
5.
B. When a call is matched, a POTS dial peer routes calls out traditional telephony connections (FXS, FXO, T1, and so on) using the port command followed by the interface number.
6.
A. The session target command is used to route VoIP dial peers to the next IP destination. Because this is an IPv4 address, it must be specified.
7.
C. A dial peer is needed to send the traffic out the IP WAN interface, and a second dial peer is needed to accept the traffic on the remote voice gateway.
8.
C. Call legs represent the logical, one-way path a voice call takes. Call legs can either be POTS or VoIP depending on the network the call is traversing.
9.
D. Both inbound and outbound call legs are required. The inbound call leg is matched fi rst. Then the outbound call leg is matched and sent to the proper destination.
10. D. Only the destination-pattern can be used to match outbound dial peers. The other choices can be used by inbound dial peers. 11. A, C. Of the three categories defi ned within the E.164 plan, only the country code and subscriber code are required. The national destination code is optional. 12. B. The NANP plan specifies that an NANP telephone number must be 10 digits in length. 13. B. The no digit-strip command ensures that all digits including those explicitly defi ned are forwarded to the destination. Digit stripping is enabled by default. 14. D. Number expansion digit manipulation is configured globally on voice gateways. 15. A, B. The ( ) means that the numbers are contained in a group. The + means that the previous digit or group will occur one or more times. That means that 3322 and 332222 will be the two choices that match this destination pattern. 16. A, B. The [ ] means that one of a range of numbers given can be used. The . means that the next digit is a single-digit wildcard. That means that 4132248 and 4134551 will be the two choices that match this destination pattern.
c04.indd 141
9/21/11 11:17:24 AM
142
Chapter 4
■
The VoIP Path-Selection Process
17. A, B, C. A translation rule set must fi rst be configured; it may contain up to 15 different matching/translation rules. A translation profi le is then configured, which references the translation rule set. Finally, the translation profi le can be applied to inbound and/or outbound calls. 18. A. The TAG specifies each unique dial peer. Dial peer 1 is the only rule that will match the string 4545, and therefore this dial peer will be used to forward the call to the correct destination. 19. A. The show dialplan number number-string command gives you detailed information about how the voice gateway will handle a particular dialed number string including dial-peer tag, operational status, QoS settings, codec used, call success/failure, and destination port or IP address. 20. B. The / expression signifies both the start and end of a match or translation string.
c04.indd 142
9/21/11 11:17:25 AM
Answers to Written Lab 4.1
143
Answers to Written Lab 4.1 1.
Local
2.
SIP and H.323
3.
voip
4.
Inbound
5.
Central office code
6.
?
7.
5(54)+
8.
9T
9.
prefix 9,
10. debug voice translation
c04.indd 143
9/21/11 11:17:25 AM
c04.indd 144
9/21/11 11:17:25 AM
Chapter
5
VoIP Design Options THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the basic operation and components involved in a VoIP call. ■
Choose the appropriated codec for a given scenario.
■
Describe and configure VLANs.
Describe the components of a gateway. ■
Describe the function of gateways.
■
Describe DSP functionality.
■
Describe different voice ports and their functionality.
■
Describe codecs and codec complexity.
Describe the need to implement QoS for voice and video.
C05.indd 145
■
Describe the causes of voice and video quality issues.
■
Describe QoS requirements for voice and video traffic.
9/21/11 11:18:46 AM
When you begin the design process for a VoIP network, there are many decisions that need to be made prior to implementation. First, you need to understand the full capabilities of voice gateway DSPs and how they can be used to offload processor-intensive tasks from the callprocessing agent. To design a network you must also understand some unique factors found in VoIP networks, including VAD and network-related issues such as latency, jitter, and packet loss. You can then choose a voice codec based on the speed/stability of your network as well as the fidelity of the voice signal you need. To help determine voice load on a network, in this chapter you will learn how to calculate the size of a frame and bandwidth consumption based on codec types and sample/payload sizes.
Voice Gateway DSP Functions Voice gateways do much more than simply route calls between networks. They can also be used to offload processor-intensive tasks from the call-processing agents. Specialized processors called digital signal processors (DSP) are used to perform multiple voice duties: PSTN Termination When voice calls must be bridged between an IP network and the PSTN, traffic is routed to the voice gateway, where a router is used to convert IP voice packets to PSTN signaling such as a T1 circuit. The conversion requires DSP processing power to translate between the two networks. Transcoding Transcoding is the process of translating between two different voice codecs. There are multiple codecs available for use on voice networks. Codecs are typically chosen based on hardware compatibility and bandwidth limitations. DSP resources are used in the translation process, allowing end devices that use different voice codecs to communicate with each other. A Cisco Unified Communications Manager can perform transcoding locally, but these can be offloaded to voice gateways with high-speed DSPs. Media Termination Point A voice gateway can be configured to be used as a media termination point (MTP) to relay voice calls that are incoming from either H.323-capable endpoints or other gateways. An MTP is used to provide endpoints running these signaling protocols with additional functionality, including:
C05.indd 146
Call hold
Call transfer
Call park
Conference calling
9/21/11 11:18:47 AM
Understanding Voice and VoIP Quality Considerations
147
MTPs must also be used in a Cisco environment when there are both SIP and SCCP phones. SIP DTMF tones are sent inside the payload (in-band), while SCCP phones only support out-of-band DTMF tones. An MTP can be configured to translate the two tones between in- and out-of-band. Conference Calling for Cisco Phones A conference call on a Cisco voice network is nothing more than the mixing of multiple audio streams (one for each phone in the conference call) into a single stream that is sent to each phone in the call. In order for this mixing of audio streams to occur, they must terminate at one point and be processed in near real time. Similar to transcoding and MTP, a Cisco Unified Communications Manager can handle some conference-calling duties locally, but doing so is very processor intensive, and for large implementations it’s recommended that conference calling be offloaded to the voice gateways where DSPs can be used to offload call-mixing duties, as shown in Figure 5.1. F I G U R E 5 .1 :
Conference call offloading
M
V
Voice gateway offloading conference calling
IP WAN
V
IP Phone
In addition, networks using a distributed services deployment model can be configured so the remote site’s voice gateway’s DSPs are used for local conference calling. This prevents conference calls from having to needlessly traverse the WAN while consuming bandwidth.
Configuring DSP settings, including DSP farms, will be covered in Chapter 6, “Configuring Voice Gateway Ports and DSPs.”
Understanding Voice and VoIP Quality Considerations Running voice over an IP network adds some complexity to the task of maintaining the overall clarity of a call. Because voice is a real-time transmission, network administrators
C05.indd 147
9/21/11 11:18:48 AM
148
Chapter 5
■
VoIP Design Options
must fully understand the terminology and issues that arise on IP networks. This section covers voice clarity terminology and quality issues that should be understood in order to design an IP network and troubleshoot voice problems on it.
Audio Fidelity You can think of a voice network as a networked photocopy machine for audio. When you speak into the telephone handset, the voice network makes a copy of your voice and processes it for transport to a destination phone where that copy is replayed. As you know, some photocopy machines are better than others, and the finished product is close to the original but not exact, because some of the fi ner details may be missing. This is also true for voice networks. The accuracy of the copied signal on a voice network is known as fidelity. When audio is sampled using narrowband (300–3400 Hz) frequencies and is then highly compressed, the audio is considered to be low fidelity, while voice samples taken with a larger range of wideband frequencies (50–7000 Hz) and transported using lower compression ratios are called high fidelity. The difference between narrowband and wideband voice collection is displayed in Figure 5.2.
Narrowband and wideband frequency collection
Gain
FIGURE 5.2
50
300 3400 Frequency (Hz)
7000
Wideband audio offers a clearer and fuller-sounding voice representation but at the cost of higher bandwidth requirements.
Echo and Echo Cancellation A second clarity issue that can cause problems in the transmission of voice is called echo. Just like yelling into a rocky cavern, echo is the reflection of sound that arrives to the listener a period of time after the direct sound is heard. A certain amount of echo is experienced on every voice call, but much of it goes unnoticed and therefore can be ignored. However, when analog signals are converted to digital signals and then compressed using codecs, echo is often amplified to the point where it severely degrades the quality of the call. Cisco states that noticeable echo becomes a distraction when the caller hears their own voice 25 milliseconds or longer after the words are spoken. Echo occurs on
C05.indd 148
9/21/11 11:18:48 AM
Understanding Voice and VoIP Quality Considerations
149
traditional voice networks primarily because of an impedance mismatch. Impedance is the ratio between voltage and electrical current. This ratio can become out of balance when voice is transported across different networks. On IP networks, echo is typically due to network delay. Most low-bandwidth codecs have echo cancellation built in using DSPs for processing power; with traditional PSTN connections, the DSP has fi rmware that handles echo cancellation. There are two primary types of echo. Talker echo occurs when the talking party’s voice is transmitted to the destination but is also picked up by the receive wires during a twowire to four-wire transfer. The result is that the voice signal is sent back to the originating talker with a delay equal to the one-way delay from source to destination. Talker echo is the most common type of echo found on voice networks. Listener echo is the second common type of echo. It occurs when the talker’s voice is echoed twice, between two two-wire to four-wire transfers. The fi rst echo is similar to the talker echo, in which the voice is leaked to the receiving pair of the originating speaker. That echo is then echoed back toward the listening party. The result is that the listening party hears the talking party’s voice twice. An echo canceller eliminates echo of a voice signal by capturing its electrical characteristics. It stores this electrical “fi ngerprint” based on the voice signals that are being received (Rx). It then uses the stored signal and subtracts it from the transmit (Tx) signal leaving the circuit. This effectively cuts off any echo that may be occurring on the line. The amount of time that an echo canceller waits to listen for echo on the Rx line of the tail circuit is called the ringing time. The ringing time required for a circuit may vary depending on the quality of the circuit and number of transfers. The following example shows how to modify the echo cancellation timer to 32 ms on voice port 1/1:0: Router#configure terminal Router(config)#voice-port 1/1:0 Router(config-voiceport)#echo-cancel enable Router(config-voiceport)#echo-cancel coverage 32
The default echo cancellation timer differs on IOS versions. As of this writing, echo-cancel coverage 64 is the default setting for IOS version 12.3(4)T and higher releases. Also, by default echo cancellation is enabled. It is shown in the example just in case it has been disabled using the no echo-cancel enable command.
Background Noise If you were to record and eliminate the silence in a typical telephone call between two parties, you might be surprised to discover that approximately 65 percent of the call has actual audio that needs to be transmitted. The rest of the call is silence and therefore can be eliminated in theory. A 35 percent reduction in the amount of useless background
C05.indd 149
9/21/11 11:18:49 AM
150
Chapter 5
■
VoIP Design Options
noise transported across an IP networks is a welcome opportunity but must be handled appropriately. Background noise of some kind is needed to let the parties know that the call is still in progress. Voice Activity Detection (VAD) can be implemented on an IP network to eliminate the transport of background noise and therefore reduce the amount of bandwidth a call consumes. VAD is built into several low-bandwidth codecs, including G.729b, G.729ab, and G.723.1 Annex A. Other, higher-bandwidth codecs, including G.711, G.726, and G.728, do not have VAD built-in.
VAD should be disabled when configuring voice gateways to handle fax machine traffic or modems. It also does not operate with music on hold (MOH). Therefore, you must choose codecs that do not have built-in VAD for these situations.
It is also important to note that VAD can have some serious drawbacks. The fi rst potential problem is voice clipping, where the first few milliseconds of speech is not transported, because of VAD. Recent VAD software is fairly good about avoiding clipping problems, but the problems increase when a caller is in a loud background situation where the software has difficulty differentiating between a caller’s voice and background noise. By default, VAD is enabled on dial peers but not on POTS interfaces. When the noise threshold is –78 dBm, VAD kicks in. To enable or disable VAD on a dial peer (running H.323) or voice port, use the vad and no vad command as shown here, where we turn off VAD on dial peer 100: Router#configure terminal Router(config)#dial-peer voice 100 voip Router(config-dial-peer)#no vad Router(config-dial-peer)#end Router#
When VAD is enabled, the detection timer can be adjusted globally on voice gateways to help to prevent clipping problems. By default, VAD waits 250 milliseconds after silence is detected before it stops sending silent packets. Figure 5.3 shows a voice signal reaching a point where only background noise is detected. VAD waits a period of time before being activated. You also can see that when voice begins to be collected, a small portion of the sound is clipped because of VAD. FIGURE 5.3
An example of VAD VAD timer
Gain
VAD
Background noise
Time
C05.indd 150
9/21/11 11:18:50 AM
Understanding Voice and VoIP Quality Considerations
151
This number can be adjusted from 250 ms to 65536 ms. Here is an example of adjusting VAD detection to 750 ms: Router#configure terminal Router(config)#voice vad-time 750 Router(config)#end Router#
A second problem with VAD is that it does not take the human element into the equation. With VAD enabled, there are often long stretches of time where there is complete silence because background noise is not being transported over the network. When a caller hears no sound at all on the line, they cannot be sure if the call is still in progress or if it has been terminated. To resolve this problem, VAD is commonly paired with “white noise” or a comfort noise synthesis. This is essentially a soft static noise that is injected at the local ends of the call. It can be enabled along with VAD by using the comfort-noise command. In this way, the caller hears a soft hissing that informs them that the call is still in progress without the need of actually transporting background noise across the network. Here is an example of enabling comfort noise synthesis on POTS ports connected to a voice gateway: Router#configure terminal Router(config)#voice-port 1/1/0 Router(config-voiceport)#comfort-noise
Notice that most of the VAD and related commands are configured on voice gateways primarily for POTS ports. This is because IP phones can natively perform VAD and white-noise generation without the aid of a voice gateway. VAD can be enabled/disabled and modified on the Cisco Unified Communications Manager, but that topic is outside the scope of this book.
Voice over IP Quality Considerations IP networks have a fi xed amount of bandwidth with which to transport voice, video, and data. Each network is unique, and the maximum amount of bandwidth end to end is only as great as the lowest bandwidth link. For example, you may have a 10 Gbps core but only a 1.5 Mbps WAN connection to 40 remote site phones and computers. That 1.5 Mbps of bandwidth can fi ll up quickly and can cause voice communication problems. When calls are made between the primary site and remote offi ce, the 1.5 Mbps WAN is the lowest bandwidth circuit and is referred to as a bottleneck. Bottlenecks on a network are often related to the following conditions, any of which can cause IP voice quality issues.
Network Delay Propagation delay is the amount of time it takes a packet to travel from source to destination on a network. Every network has a certain amount of delay, called fi xed delay.
C05.indd 151
9/21/11 11:18:50 AM
152
Chapter 5
■
VoIP Design Options
This is the amount of time it takes in an ideal situation where the only slowdown is in how fast it takes electrical and optical signals to transport IP packets. Fixed delay cannot be avoided and is so slight that it does not affect the quality of voice. The following factors contribute to fi xed delay on a network. DSP Delay The amount of time it takes for the DSP to sample, encode, and compress voice streams. Packetization Delay The amount of time it takes the router to place encoded voice inside IP packets for transport on the wire. Serialization Delay The amount of time it takes to transmit bits on a physical medium such as Ethernet or a POTS line. Variable delay, on the other hand, occurs when data transport is slowed down by bottlenecks on the network. Data in bottleneck situations must be queued and wait a period of time before being transported. A certain amount of delay (fi xed and variable combined) can occur before voice quality is affected. The ITU-T G.114 specification recommends that end-to-end delay should not exceed 150 ms. Network Delay This type of delay is due to bottlenecks on the network that cause packets to be delayed on the wire. De-jitter Buffer Delay When packets are unevenly spaced on arrival to the input interface, they must be slowed down and properly spaced before they are processed by the DSP. The playout delay buffer is responsible for this task. It is also referred to as the de-jitter buffer. Queuing and Buffering Delay This is the amount of time it takes for packets to be placed in a queue until they can be sent out of the outbound router interface.
Network Jitter Jitter on a network refers to the variation in the time between the receipt of each voice packet. Jitter is always calculated at the receiving end of the network. Variable delay causes variation in the time between packets. For example, a voice packet that is sent from the source phone to the destination phone with no variable delay may have a difference between packets of 30–50 ms. However, bottleneck conditions can create temporary variable delay in which it might take over 100 ms between receipt of voice packets, as shown in Figure 5.4.
FIGURE 5.4
Jitter variation
1
2 40 ms
C05.indd 152
3 40 ms
4 130 ms
5 55 ms
9/21/11 11:18:51 AM
Defining Voice Codecs
153
This variation in the receiving of packets can cause the voice stream to skip and stutter, which can be very annoying to the listener. It is recommended that network jitter be reduced to 30 ms or less on average.
Packet Loss Jitter is caused by bottlenecks delaying voice packets from arriving. It occurs because at the bottleneck interfaces, packets must be placed into queues and wait until it is their turn to be sent across the congested pipe. But if bottlenecks are severe enough, interface queues can fi ll up and packets are dropped because there is no place to store them. Packet loss not only is annoying but also can cause calls to fail completely. While ideally no voice packets are lost, it is recommended that the overall total of packets lost for a voice call never exceed 1 percent. Many voice codecs have what’s known as packet loss concealment (PLC) methods to assist with packet loss on voice calls. When lost packets are detected on a voice gateway, PLC analyzes the packets that did arrive at the input interface and determines what the voice payload should sound like. In essence, PLC is software that takes a guess at what the missing packet is and places it on the wire for transport. This replacement packet is far better than no packet at all. The majority of voice quality concerns can be solved by choosing the optimal codec for your network as well as properly configuring Quality of Service (QoS) settings to ensure that real-time packet transmissions such as voice are prioritized ahead of data traffic. The next section covers several voice codecs available on Cisco endpoints and voice gateways. Quality of Service considerations and configurations will be covered in Chapters 11, “Introduction to Quality of Service,” and 12, “Configuring Quality of Service,” of this book.
Defining Voice Codecs We’ve talked a little bit about codecs but have never officially defi ned them. The term codec is short for coder/decoder. A codec is an algorithm responsible for the conversion of analog waves (such as the human voice) into a digital format. The G.711 codec is special in the fact that it provides no compression of the audio sample as it is digitized. Other codecs provide compression in one form or another that sacrifices audio quality for bandwidth savings. The codec chosen should be based on the end-to-end bandwidth for all call legs as well as compatibility of endpoints involved. There are a number of voice codecs that you should become familiar with. Each codec is slightly different and can be used in various network environments to provide the optimal balance between quality voice and bandwidth reduction.
Voice Codec Types Literally dozens of voice codecs are available in the wild. It used to be that most Cisco IP phones supported only the G.711 and G.729 codecs. Times are changing, and Cisco is now
C05.indd 153
9/21/11 11:18:51 AM
Chapter 5
154
■
VoIP Design Options
delivering phones that natively understand several more codecs. New phones are designed with enhanced acoustics and the ability to understand advanced voice codecs. For example, the Cisco 9951 phone currently supports the following voice codecs:
G.711a
G.711u
G.729a
G.729ab
G.722
iLBC
In addition, your voice gateway can understand multiple other voice codecs, because it is the device that connects to the PSTN, Internet Telephony Service Providers (ITSP), legacy PBX systems, and remote sites with low-speed WAN connections. Therefore, the list of codecs Cisco voice gateway IOS software can understand and work with is large and is growing all the time. This section describes some of the more commonly used codecs on voice networks today. For the most part, voice codecs attempt to balance voice quality with lower bandwidth requirements for a call. In addition, Cisco is now supporting wideband voice codecs. Most codecs available today on PSTN and VoIP networks provide narrowband communication, in which analog signals are collected within 300 and 3400 Hz. This range of frequencies picks up most human speech and therefore has been sufficient. However, if you want to transfer other sounds (such as music) clearly, then a wider range of frequencies must be collected. Wideband codecs collect frequencies between 50 and 7000 Hz. While this results in a much richer and more natural sounding call, it also increases the amount of bandwidth required because of the larger sample sizes that are collected. Other wideband codecs compress the payload sizes, but doing so requires additional DSP resources to handle the increase of compression duties. The two wideband codecs discussed in this book are G.722 and iSAC. While wideband codecs specifications are not new (G.722 was standardized in 1988), the advancement of higher-powered DSP chips makes wideband audio possible.
G.711 The G.711 ITU-T standard is the most popular codec used on voice LANs today. The codec uses 8-bit samples at 8 kHz sampling rates and encodes audio signals in 64 Kbps streams. There are two main subsets of G.711, which use slightly different encoding schemes. The G.711u algorithm is used in North America and Japan, while the G.711a algorithm is used in the rest of the world. PSTN PRI connections utilize one of these codecs, depending on what part of the world you are in. The difference between the two is that the u-law (or mulaw) algorithm’s encoding scheme is a little more complex than the a-law algorithm used. G.711 is also commonly referred as Pulse Code Modulation (PCM).
G.723.1 The G.723.1 ITU-T standard codec uses compression to deliver very low bandwidth voice at acceptable quality. In addition, there is a G.723.1 Annex A variation that has built-in VAD.
C05.indd 154
9/21/11 11:18:52 AM
Defining Voice Codecs
155
The non-Annex A variation does not have built-in VAD support. There are two additional options when configuring this codec on Cisco voice gateways. The G.723ar53 codec option operates at 5.3 Kbps, while the G.723ar63 operates at 6.3 Kbps. Because of the loss in audio quality, DTMF and fax relay should never be attempted using G.723.1 codecs.
G.726 The G.726 ITU-T standard codec uses Adaptive Differential Pulse Code Modulation (ADPCM) to reduce bandwidth bit rates while maintaining a relatively high sound quality. The G.726 protocol officially replaces the now obsolete G.723 and G.721 protocols that were the fi rst to use ADPCM. G.726 uses samples of 2, 3, 4, or 5 bits, at data rates of 16, 24, 32, or 40 Kbps depending on the subset of the codec. The benefit of the G.726 protocol is that if the PSTN or PBX is configured to use the ADPCM codec (which sometimes happens when PSTN channels are overloaded), a Cisco voice gateway can natively be understood by both IP and legacy digital voice networks.
G.722 (Wideband) The G.722 ITU-T standard codec provides improved audio quality by taking wideband samples. The codec uses the same Adaptive Differential Pulse Code Modulation (ADPCM) found in G.726, but instead of compressing the audio payload, G.722 maintains the same data rate size but doubles the audio content found in each packet. This is known as SubBand ADPCM (SB-ADPCM) and allows for a 16 kHz sample rates at data rates of 48, 56, or 64 Kbps. A newer variation of G.722 is the G.722.2 codec, also known as Adaptive MultiRate Wideband (AMR-WB). This codec applies advanced compression techniques to the 64 Kbps stream when congestion is observed on the network. This compression requires the use of additional DSP resources during this time. When congestion is alleviated, the lesscompressed (and therefore higher-quality) stream returns.
G.728 The G.728 ITU-T standard codec provides compressed voice streams running at a fi xed 16 Kbps. This codec uses a low-delay code excited linear prediction (LD-CELP) technique that provides reasonable quality voice at lower bit rates.
G.729 The G.729 ITU-T standard codec uses 10 millisecond audio samples and compresses the audio signal into a small 8 Kbps bit rate. Because of the low bit rate, the G.729 codec is a very popular choice for transporting voice over low-speed WAN connections. Also, as with the G.723.1 codec, DTMF and fax relay should never be attempted with this codec. You will also not want to use this codec for MOH streams. There are many subsets of the G.729 protocol, referred to as annexes. Here is a breakdown showing the differences between the codec annexes used in Cisco networks: G.729a
C05.indd 155
Requires less DSP processing power but provides lower-quality audio.
9/21/11 11:18:52 AM
156
Chapter 5
■
VoIP Design Options
G.729b Higher-quality voice than G.729a but considered a high-complexity codec that will require more DSP resources. Also provides built-in voice audio detection (VAD) to limit the number of empty voice packets being sent. G.729ab The combination of G.729a and G.729b features. The result is a mediumcomplexity codec with built-in VAD.
A new ITU-T G.729 annex has been developed to support wideband audio samples that are compressed into 8–32 Kbps bit rates. This new annex is known as G.729.1. While this codec is not yet supported by Cisco IP endpoints, it may very well be supported in the future to provide highfidelity audio at low bandwidth rates.
GSM Full Rate The GSM Full Rate (GSMFR) codec was the fi rst digital codec used on GSM mobile networks. It’s a high-complexity codec that uses 20 millisecond frames at a bit rate of 13 Kbps. The codec is also used in voicemail systems, and this is where you are likely to run across it on voice networks. The quality of the audio stream is fairly poor compared to newer and more advanced codecs.
Internet Low Bit Rate Codec The Internet Low Bit Rate Codec (iLBC) is an open-standard protocol that is heavily backed by Cisco. This protocol is designed to deliver high-quality audio with a relatively low-bandwidth footprint of 13.33 Kbps using either 20 or 30 millisecond frames. One feature of iLBC that is beneficial to VoIP networks is its built-in graceful degradation of audio signals if network congestion or other issues cause dropped packets, unordered packets, or jitter on the network.
Internet Speech Audio Codec (Wideband) The Internet Speech Audio Codec (iSAC) is a proprietary codec developed by Global IP solutions but supported on Cisco voice gateways and Cisco UBE platforms. The iSAC protocol terminates at the voice gateway and can be used to communicate natively with iSAC-capable devices. It is a popular codec used for voice applications over the Internet, including AOL Instant Messenger (AIM) and Google Talk. This wideband codec uses samples of either 30 or 60 ms at 16 kHz using a sampling rate between 10 and 32 Kbps.
Understanding Codec Complexity Voice codecs use various algorithms used to compress audio signals. Some algorithms used for compression use more processing power than others. You have already learned that DSPs are used by voice gateways to offload codec processing from the main CPU. Codecs are therefore categorized by the number of simultaneous calls a single DSP can process. On Cisco
C05.indd 156
9/21/11 11:18:53 AM
Defining Voice Codecs
157
equipment, three different DSP chipsets are in use today. The older C549 DSP chipset (PVDM) can support up to eight low-complexity codec calls, four simultaneous medium-complexity codec calls, and two high-complexity codec calls per DSP. The C5510 DSP chips (PVDM2) can support 16 low-complexity codec calls, eight medium-complexity codec calls, and a maximum of six high-complexity codec calls simultaneously per DSP. Lastly, PVDM 3 chips can handle 16 low-complexity, 12 medium-complexity, and 10 high-complexity codec calls. The PVDM2 is used on all new Cisco voice gateway routers including the Cisco ISR, while the PVDM3 is currently available only on the 2900 and 3900 series ISR2 lineup. PVDM2 chips can be installed in voice gateways with the configurations shown in Table 5.1. TA B L E 5 .1
PVDM Type
PVDM2 DSP capabilities
Low-Complexity Calls
Medium-Complexity Calls
High-Complexity Calls
PVDM2–8
8
4
4
PVDM2–16
16
8
6
PVDM2–32
32
16
12
PVDM2–48
48
24
18
PVDM2–64
64
32
24
The more advanced and higher-density PVDM3 capabilities are listed in Table 5.2. TA B L E 5 . 2 PVDM Type
C05.indd 157
PVDM3 DSP capabilities Low-Complexity Calls
Medium-Complexity Calls
High-Complexity Calls
PVDM3–16
16
12
10
PVDM3–32
32
21
14
PVDM3–64
64
42
28
PVDM3–128
128
96
60
PVDM3–192
192
138
88
PVDM3–256
256
192
120
9/21/11 11:18:54 AM
Chapter 5
158
■
VoIP Design Options
Because DSPs handle a wide variety of voice duties, it can be difficult to understand how many DSPs you will need to install on your voice gateways. Fortunately, Cisco has an online DSP calculator that can be used to help identify the number of DSP resources that will be used by entering information such as the router platform, IOS version, modules used, and number of conference calls expected. If you have a Cisco account, you can log in and access the DSP calculator here:
http://www.cisco.com/cgi-bin/Support/DSP/dsp-calc.pl
There are only a few low-complexity codecs, which require no compression at all, including these:
G.711 a-law
G.711 u-law
Clear channel (used for transport of non-voice data such as fax/modem)
Some of the more popular voice codecs used today that fall under the mediumcomplexity category are these:
G.726 (all variations)
G.729a
G.729ab
These common voice codecs utilize more DSP/CPU resources and are considered high complexity:
G.723 (all variations)
G.728
G.729
G.729b
GSMFR
iLBC
iSAC
Voice complexity can be configured manually for DSP chipsets using the codec complexity type command within config-voicecard mode. On C549 DSP chips, you can configure each DSP as being either medium or high complexity, as shown here: Router#configure terminal Router(config)#voice-card 1 Router(config-voicecard)#codec high Set codec complexity medium Set codec complexity Router(config-voicecard)#codec
C05.indd 158
complexity ? high. High complexity, lower call density. medium. Mid range complexity and call density.
complexity
9/21/11 11:18:54 AM
Defining Voice Codecs
159
By default, the codec complexity for C549 chips DSPs is set to high. This is so you can use any voice codec, because low- and medium-complexity codecs will work fi ne when the DSP is configured for high-complexity mode. It does mean, however, that twice the resources actually needed will be allocated for the low- or medium-complexity codec. If you plan to use only low/medium-complexity codecs, you can statically configure the DSPs to use only a medium complexity. The downside here is that if you try to use a high-complexity codec, the call will fail.
Statically Assigning DSP Resources Can Cause Dropped Calls When voice gateways are pushed to capacity from a bandwidth perspective, many businesses choose to move from higher-quality codecs such as G.711 to lower-quality codecs like G.729. The benefi t of migrating to G.729 comes from the per-call bandwidth saving that you can achieve. This situation was exactly what happened to Wes, our resident network administrator. Wes was asked to modify the codec used on his voice gateway from G.711 to G.729b. This was to be a fairly simple modification and would be seamless to the end user. But when Wes went ahead and changed the codec type, all DSP functionality ceased to work. Wes struggled to figure out the cause of his DSP problem and had to fall back to using G.711. As soon as he did this, DSP services began functioning properly. It was only after reaching out to another network engineer that the problem was spotted. It turned out that the DSP voice card installed in the DSP farm was statically configured to use medium complexity. This was not a problem because the G.711 codec is considered to be of low complexity, but G.729b is a high-complexity codec and can only operate with DSP resources when the voice card is configured for high complexity or in variable flex mode.
The C5510 (PVDM2) and PVDM3 chipsets offer two additional configuration options that can be set as shown here: Router#configure terminal Router(config)#voice-card 1 Router(config-voicecard)#codec flex Set codec complexity high Set codec complexity medium Set codec complexity secure Set codec complexity Router(config-voicecard)#codec
C05.indd 159
complexity ? Flex. Flex complexity, higher call density. high. High complexity, lower call density. medium. Mid range complexity and call density. secure. complexity
9/21/11 11:18:55 AM
160
Chapter 5
■
VoIP Design Options
The flex option is different from the high and medium complexity settings because flex mode allows for the oversubscription of calls and allows low-, medium-, and highcomplexity calls to be processed on a DSP. While flex mode is beneficial because of the ability to support more TDM interfaces than DSP resources, it also leaves the door open for occasions when DSP resources will be exhausted, resulting in call failures. The flex option provides the ability to support any codec by automatically adjusting between medium- and high-complexity settings. For example, when a call requires G.711 codec processing, the flex option will choose to process the call using low complexity. However, a G.729b call will be processed using high complexity. The secure codec complexity option allows for the secure transport of voice streams using authentication and encryption through the support of sRTP. Adding this added layer of security obviously uses more DSP resources than processing the codec unauthenticated and unencrypted. By default, PVDM2 and PVDM3 DSPs are configured as flex resources. The show voice dsp command can be used to verify how your DSPs are currently configured, as shown in the following example: Router# show voice dsp ——————————————FLEX VOICE CARD 1——————————————— *DSP VOICE CHANNELS* DSP DSP DSPWARE CURR BOOT TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT ===== === == ======== ======= ===== ======= === == ========= C5510 001 01 modem-re 4.5.909 busy idle 0 0 1/1/0 *DSP SIGNALING CHANNELS* DSP DSP DSPWARE CURR BOOT TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT ===== === == ======== ======= ===== ======= === == ========= C5510 001 05 {flex} 4.5.909 alloc idle 0 0 1/1/3 C5510 001 06 {flex} 4.5.909 alloc idle 0 0 1/1/2 C5510 001 07 {flex} 4.5.909 alloc idle 0 0 1/1/1 C5510 001 08 {flex} 4.5.909 alloc idle 0 0 1/1/0 ————————————END OF FLEX VOICE CARD 1——————————————
PAK TX/RX TS ABRT PACK COUNT == ==== ============ 05 0 298/353 PAK TX/RX TS ABRT PACK COUNT == ==== ============ 02 0 15/0 02 0 17/0 06 0 31/0 06 0 321/0
As you can see from the output, these DSPs use the C5510 chipset and are set for flex mode.
Quantifying Voice Codec Clarity As you have learned, voice codecs offer compression that conserves bandwidth at the cost of the quality of the audio signal transferred. But to what degree are these codecs degrading audio clarity? Because VoIP has the capability to compress audio signals to allow more calls
C05.indd 160
9/21/11 11:18:55 AM
Quantifying Voice Codec Clarity
161
to be transmitted and received on a fi nite amount of bandwidth, it was quickly discovered that a method of quantifying the quality of voice was needed to show just how much codecs give up in terms of clarity versus bandwidth savings. The ITU-T has been responsible for implementing several subjective and objective methods over the years. This section presents four of its more popular methods used to quantify the quality of a voice signal:
Mean Opinion Score (MOS)
Perceptual Speech Quality Measure (PSQM)
Perceptual Evaluation of Speech Quality (PESQ)
Perceptual Objective Listening Quality Analysis (POLQA)
Because the G.711 codec is transferred uncompressed, this is considered to be the optimal voice quality that can be achieved. All other voice codecs are compared against the optimal codec. That being said, all of the voice quality measurement tools don’t consider G.711 to be 100 percent optimal, because analog voice signals do not pick up the complete spectrum of audible tones. Therefore, a perfect score within voice quality measurement tools is nearly impossible. Let’s take a look at each of these tools and compare them.
Mean Opinion Score As the name indicates, the Mean Opinion Score (MOS) test is simply a human opinion on the quality of various codecs. MOS is an ITU-T (P.800) audio quality recommendation that used a group of trained listeners to rank the perceived voice quality after digitization for a large group of audio codecs. Each listener gave the codec audio output a score between 1 and 5. A score of 1 means that the audio quality is “bad,” while a score of 5 means that the audio quality after digitization is “excellent.” Table 5.3 shows the MOS listening quality scale and subjective terminology used in the official ITU-T MOS scoring tests.
TA B L E 5 . 3
C05.indd 161
MOS listening quality scale
MOS Score
MOS Subjective Rating
5
Excellent
4
Good
3
Fair
2
Poor
1
Bad
9/21/11 11:18:56 AM
Chapter 5
162
■
VoIP Design Options
Table 5.4 shows the results of the MOS testing for several popular voice codecs. TA B L E 5 . 4
MOS codec scores
Codec
Bandwidth (Kbps)
Score
G.711
64
4.2
G.726 AD-PCM
32
3.8
G.728
16
3.6
Internet Lob Bit Rate Codec (iLBC)
15.2
4.1
GSM Full Rate (FR)
12.2
3.5
G.729a
8
3.7
G.723 r53
5.3
3.6
While the ITU-T MOS scale was performed by the ITU-T using the most scientific methods available, it still must be considered subjective because humans are being used to essentially grade each codec. Therefore, this is probably not the most accurate method for determining voice quality even though the scores are widely referenced today. But keep in mind that user perception is important and measures success or failure of an implementation. The next two voice quality methods attempt to address this problem by completely eliminating subjective opinion and objectively grading codecs using mathematical algorithms.
Perceptual Speech Quality Measure The Perceptual Speech Quality Measure (PSQM) was developed by the ITU-T (P.861) to objectively calculate the sound quality of various audio codecs. By developing an algorithm and computers to calculate scores, it eliminates subjective error inherent in MOS. This means that the tests are highly reproducible and therefore the scores are highly reliable. Without getting into the specifics of how the PSQM algorithm calculates scores, the audio is scored and graded immediately after the audio sample is digitized and compared against the original analog signal. The difference between the initial and encoded audio samples is then graded and given a number between 0 and 6.5. The ITU quickly discovered that PSQM was not an optimal method for scoring codecs on a VoIP network. This was because PSQM calculated the difference between the original and coded signal immediately after the process occurred. Therefore it did not have any way to account for QoS, packet loss, jitter, or out-of-sequence packets, which can impact various codecs differently. So while the PSQM scoring method is a sound quality
C05.indd 162
9/21/11 11:18:56 AM
Choosing the Right Codec
163
measurement tool in a vacuum, it cannot properly score codecs as they are used in real-world network scenarios. The ITU-T realized this and withdrew the P.861 recommendation and instead developed P.862, which is also known as Perceptual Evaluation of Speech Quality.
Perceptual Evaluation of Speech Quality The Perceptual Evaluation of Speech Quality (PESQ) measure is an ITU-T (P.862) recommendation that is the current standard used around the world for quantifying voice codecs by telephone equipment manufacturers such as Cisco. PSEQ is an extension of and a successor to PSQM since the same methods are used to score voice quality by comparing the unencoded audio sample with the digitized sample. The testing method takes an additional step, however, to incorporate common VoIP issues found in the transport of voice end to end on an IP network, such as jitter, latency, and unordered packets. Adding these calculations into the scoring mix provides a more realistic audio quality score for today’s networks. Another major difference between PSQM and PESQ is that the quality range matches the range used by MOS. Because PSEQ and MOS scores are both given a value between 1 and 5 (4.5 is actually the best a codec can achieve), PESQ and MOS scores can be easily compared side by side.
Perceptual Objective Listening Quality Analysis The Perceptual Objective Listening Quality Analysis (POLQA) is a new ITU-T standard being developed (P.863) for next-generation voice networks. The recommendation standard is targeted to be the replacement for PESQ. Among the primary differences between PESQ and POLQA is the ability to offer more advanced benchmarking for high-fidelity wideband codecs and voice codec operation over 3G and 4G networks.
Choosing the Right Codec With all the different codecs available, how do you choose the right codec to use for a particular environment? While there is no defi ned set of rules, there are characteristics of a network environment that you should take into consideration when choosing a codec for your network or network segment.
Hardware Compatibility Cisco voice gateways support a wide variety of codecs for connecting to non-Cisco equipment such as the PSTN or legacy voice gear. But internally, Cisco IP phones and other endpoints commonly support only a handful of the most popular codecs. The two most popular codecs in use today are G.711, which is recommended for use over Ethernet LANs, and G.729 and its variations, which use less bandwidth and are therefore recommended for use in remote sites over lower-speed WAN connections and for Cisco wireless phones that use Wi-Fi for transport.
C05.indd 163
9/21/11 11:18:57 AM
164
Chapter 5
■
VoIP Design Options
Network Capacity As you learned earlier in this chapter, bottlenecks can cause all kinds of voice quality problems. If a network has bottleneck and bandwidth congestion problems at any point on a network, it would be wise to use a low-bandwidth codec so that more calls can be made within that fi nite amount of bandwidth.
Codec Complexity As stated previously in this chapter, codecs are categorized as either medium complexity or high complexity. Those codecs that use high complexity require either additional processing power at the call processing agent and/or additional DSP usage on voice gateways that have DSP chips installed. If your DSP resources are limited, it is best to use a lower-complexity codec.
Endpoint Uses Earlier you were cautioned about using several of the highly compressed low-bandwidth codecs in situations where fax machines, DTMF tones, or MOH would be sent in-band. If this is a requirement on your network, you should use a higher-quality audio codec to ensure that tones and fax signals are properly received at the remote end.
Call Clarity Lastly, you should consider the clarity of the voice stream and choose the codec with the best clarity that can safely run on your network. When deciding between two codecs that can operate efficiently on your network, you should use the codec with the higher voice clarity quantization (such as MOS).
Calculating IP Voice Bandwidth Consumption Before you even begin thinking about Quality of Service for your network, you need to take a step back and look at your network purely from a bandwidth point of view. Your goal when designing a network is to build it with the hopes that QoS never has to be used. In order to accomplish this goal, you need to understand how much bandwidth a voice call will consume given various situations that affect packet and size. The conditions include codec used, Layer 2 and 3 overhead, header compression, security, VAD, and other factors that determine the overall size of each packet and the amount of bandwidth required for a single call.
C05.indd 164
9/21/11 11:18:57 AM
Calculating IP Voice Bandwidth Consumption
165
Frame and Bandwidth Calculations You need to understand two calculations. The fi rst calculation is to determine the size of a single voice frame. Generally speaking, this calculation can be determined using the following equation: total_frame_size = layer_2_header + IP/UDP/RTP_header + voice_payload_size We can also determine the number of packets per second (PPS) a call requires, using the following equation: PPS = codec_bit_rate / voice_payload_size Finally, using the results of the total_frame_size and PPS calculations, we can determine the amount of bandwidth consumed by a single voice call. The following calculation is used to determine bandwidth consumption: call_bandwidth = total_frame_size × PPS Let’s fi rst look at the IP/UDP/RTP_header and layer_2_header information to see how we go about finding those numbers. Then we’ll look at the voice codec used to see how we get the codec_bit_rate and voice_payload_size numbers needed to complete our calculations.
Determining Packet and Frame Size Information The total frame size consists of the following elements: IP/UDP/RTP Header Size All voice packets require IP/UDP and RTP headers for transport across any IP network. These three headers add up to 40 bytes and are broken down as the following:
IP header: 20 bytes
UDP header: 8 bytes
RTP header: 12 bytes
Layer 2 Header Size
In addition, different Layer 2 mechanisms can add further overhead:
Ethernet: 18 bytes (14 bytes for Ethernet header info and 4 bytes for FCS/CRC checks)
Multilink Point-to-Point Protocol (MLP): 6 bytes
Frame Relay Forum Standard 12 (FRF.12): 6 bytes
Voice Payload Size The voice payload size is a multiple of the codec sample size. This number represents the number of voice data bytes that are contained within a single packet. For example, a codec sample size of 10 ms is ~1⁄100 second. That works out to be 100 PPS. A 20 ms sample means that you have two samples or ~2 ⁄100 second or 50 PPS. The size of the payload can vary not only by codec but by settings within the codec. For example, the G.711 codec can be configured to have voice payload sizes of 80, 160, or 240 bytes. The default voice payload size for G.711 is 160 bytes, which works out to be 2 × 10ms codec samples.
C05.indd 165
9/21/11 11:18:58 AM
Chapter 5
166
■
VoIP Design Options
Keep in mind that the larger the payload size, the more efficient your voice stream will be. This is because you are lowering the total number of packets (and overhead) needed to transport your voice signals. The downside to increasing payload size is that the longer the packetization period, the larger the payload and, therefore, the lower the voice bandwidth.
Additional Voice Packet and Frame Size Factors Tunneling traffic through an IP network and using RTP compression techniques also add or subtract from the overall packet/frame size. Security or Tunnel Overhead Sometimes voice traffic needs to be tunneled through other protocols for security and connectivity reasons. This tunneling adds significantly to the overall size of a voice packet. Here is a list of popular tunneling methods supported by Cisco hardware and how much they add to the size of a voice packet:
IPSec VPN: 50–57 bytes
L2TP/GRE: 28 bytes
MPLS tagging: 4 bytes per tag (may be more than one tag present)
Figure 5.5 shows an example of a voice packet being encapsulated with IPSec that adds additional overhead to the head and tail of the packet. FIGURE 5.5
An example of IPSec overhead
IP
UDP RTP
New ESP IP IP head
Voice payload
UDP RTP
Voice payload
ESP tail
cRTP Header Compression If compressed RTP is enabled, it can reduce the 40-byte IP/UDP/RTP headers to 2 or 4 bytes in size. cRTP compresses the headers to 4 bytes when UDP checksums are used and 2 bytes when they are not sent. As you can see, cRTP drastically reduces the overall voice stream size and is great for low-bandwidth links. Also remember that cRTP cannot be enabled on multiaccess links.
Codec Bit Rate The codec bit rate is the number of bits per second (bps) that the codec uses to transmit to maintain a steady voice call. If you don’t know the codec bit rate but do know the codec sample size and sample interval, you can use the following equation: codec_bit_rate = codec_sample_size / codec_sample_interval
C05.indd 166
9/21/11 11:18:58 AM
Calculating IP Voice Bandwidth Consumption
167
For example, G.711 has a codec_sample_size of 80 bytes (640 bits) and a codec_sample_ interval of 10 ms (0.01 seconds). Therefore, our codec bit rate can be calculated as follows: codec_bit_rate = 640 / 0.01 codec_bit_rate = 64,000 bits per second Typically, you know the codec bit rate for the codec you want to use. For example, Table 5.5 lists the bit rates for several commonly used voice codecs. TA B L E 5 . 5
Codec bit/byte rates per second
Codec
bps
Kbps
G.711
64000
64
G.729 (all)
8000
8
G.723ar53
5300
5.3
G.723ar63
6300
6.3
G.728
16000
16
iLBC_20
15200
15.2
iLBC_30
13330
13.33
Frame and Bandwidth Calculation Example Now let’s pull together everything you have learned and calculate voice packet sizes and bandwidth consumption. In our example, consider that we were given the following voice call setting information and asked to calculate both PPS and call bandwidth for a call:
Codec: G.729a (8 Kbps)
Voice payload: 30 bytes (240 bits)
FRF.12: 6 bytes (48 bits)
IP/UDP/RTP: 40 bytes (320 bits)
Given this information, we can fi rst calculate the total frame size. It’s easiest to fi rst convert bytes into bits when doing these calculations as follows: total_frame_size = layer_2_header + IP/UDP/RTP_header + voice_payload_size total_frame_size = 48 + 320 + 240 total_frame_size = 608 bits
C05.indd 167
9/21/11 11:18:59 AM
168
Chapter 5
■
VoIP Design Options
Next, we can calculate the PPS rate for our call: PPS = codec_bit_rate / voice_payload_size PPS = 8000 / 240 PPS = 33.33 Finally, we can determine the amount of bandwidth used per voice stream, as shown here: call_bandwidth = total_frame_size × PPS call_bandwidth = 608 × 33.33 call_bandwidth = 20,264 bps call_bandwidth = 20,264 bps / 1000 call_bandwidth = 20.264 Kbps In example 2, we will use the following settings:
Codec: G.728 (16 Kbps)
Voice payload: 60 bytes (480 bits)
Ethernet: 18 bytes (144 bits)
IP/UDP/RTP: 40 bytes (320 bits)
L2TP/GRE: 28 bytes (224 bits) Let us fi rst calculate the total frame size, as shown here: total_frame_size = layer_2_header + IP/UDP/RTP_header + voice_payload_size + tunneling_overhead total_frame_size = 144 + 320 + 480 +224 total_frame_size = 1168 bits Next, we can calculate the PPS rate for our call: PPS = codec_bit_rate / voice_payload_size PPS = 16000 / 480 PPS = 30.33 Finally, we can determine the amount of bandwidth used per voice stream as shown here: call_bandwidth = total_frame_size × PPS call_bandwidth = 1168 × 33.33 call_bandwidth = 38,929 bps
C05.indd 168
9/21/11 11:18:59 AM
Calculating IP Voice Bandwidth Consumption
169
call_bandwidth = 38,929 bps / 1000 call_bandwidth = 38.93 Kbps
Don’t forget that you can approximate VAD bandwidth savings that account for approximately 35 percent of total throughput.
Cisco has an online voice codec bandwidth calculator that can be used to calculate how much bandwidth various codecs will use in network situations as explained above. Figure 5.6 shows the interface of the voice calculator.
FIGURE 5.6
The Cisco Voice Codec Bandwidth Calculator
If you have a valid CCO login, you can use the online voice codec calculator that can be found here: http://tools.cisco.com/Support/VBC/do/CodecCalc2.do
It is recommended that you learn how to calculate voice packet sizes and bandwidth consumption manually for the exam. The online calculator is a great resource to verify your manual calculations, however.
C05.indd 169
9/21/11 11:19:00 AM
170
Chapter 5
■
VoIP Design Options
Summary A man who does not plan long ahead will find trouble right at his door. —Confucius
Voice networks can be implemented properly or poorly. You need to analyze your current network to determine how to best deploy voice with the landscape you are given. Every IP network is unique, and therefore every voice deployment is unique. In this chapter we covered the technology, terminology, codec scoring techniques, and how to calculate voice packet and bandwidth requirements. These topics can be used to help you to plan for and prepare your IP network for the transport of voice.
Exam Essentials Understand the primary functions of DSPs. DSPs can be used to perform PSTN termination, transcoding, MTP functions, and call conferencing. Know the concerns you need to address when operating voice over an IP network. Issues such as fidelity, echo, background noise, network delay, jitter, and packet loss must be addressed and managed to optimize a voice network. Understand the primary differences between popular codecs. Most codecs can be differentiated by their audio clarity, compression techniques, and compatibility with types of endpoints. Understand the difference between narrowband and sideband codecs. Narrowband codecs capture audio between 300 and 3300 Hz, while wideband frequencies capture audio between 50 and 7000 Hz. Wideband audio provides higher fidelity but at the cost of added bandwidth requirements. Understand the purpose of VAD. VAD is software used to identify when packets contain no voice audio and instead contain only background noise. VAD will not send these “empty” voice payloads across the network, which can reduce bandwidth for a call by 35 percent on average. Know which codecs are medium complexity and which are high complexity. Codecs differ in the amount of processing power they require by DSP resources. Most codecs that use a complex algorithm and high rate of compression fall in the high-complexity category. Understand the various methods to quantify voice codec quality. MOS is a subjective scoring method, while PSQM and PESQ are objective. PESQ provides more accurate scores than PSQM, because its tests include network latency, jitter, and packet loss. POLQA is a new standard used to better grade next-generation codecs.
C05.indd 170
9/21/11 11:19:00 AM
Written Lab 5.1
171
Know the characteristics used to choose a voice codec. Different codecs are optimal based on their network environment. Characteristics such as hardware compatibility, network capacity, codec complexity, endpoint uses, and call clarity factor into the decision-making process. Understand how to calculate the size of a voice frame. A voice frame is calculated by the adding the Layer 2 and Layer 3 headers plus the voice payload size. Understand how to calculate the bandwidth requirements for a voice call. A voice call bandwidth is calculated by taking the total size of a single voice frame multiplied by the number of packets per second the stream will operate at. Know the different factors that can add or reduce a voice frame size. Layer 2 transport mechanisms, VPN tunneling, and cRTP can add to or reduce a voice frame size.
Written Lab 5.1 1.
What is the name for audio samples that are collected between 50 and 7000 Hz?
2.
When VAD is used, this adverse effect can prevent the fi rst few milliseconds of a person’s voice from being sent.
3.
What IOS command can be used in global configuration mode to adjust the VAD detection timer to 500 milliseconds?
4.
What are the minimum network recommendations for delay, jitter, and packet for voice networks?
5.
Which popular voice codec has a bandwidth stream of 64 Kbps and uses no compression?
6.
What voice card configuration command is used to set codec complexity to high?
7.
What show command can be used to see what complexity settings your DSPs are currently configured for?
8.
How many bytes are IP/UDP/RTP headers that are uncompressed?
9.
What two pieces of information need to be multiplied together to determine the amount of bandwidth required for a call?
10. Your voice codec bit rate is 32 Kbps and the payload is 20 bytes. What is the packet
per second (PPS) rate? (The answers to Written Lab 5.1 can be found following the answers to the review questions for this chapter.)
C05.indd 171
9/21/11 11:19:01 AM
Chapter 5
172
■
VoIP Design Options
Review Questions 1.
Why are DSP resources needed to process DTMF tones between SIP and SCCP devices? A. SCCP does not use DTMF.
2.
B.
SIP does not use DTMF.
C.
SCCP DTMF tones are sent in-band and SIP tones are sent out-of-band.
D.
SIP DTMF tones are sent in-band and SCCP tones are sent out-of-band.
On an IP network, what is the most common reason for echo? A. VAD clipping
3.
B.
Glare
C.
Network delay
D.
Impedance
Under normal conditions, VAD can eliminate what percentage of bandwidth on a network? A. 10 percent B.
4.
40 percent
C.
5 percent
D.
35 percent
When configuring a POTS port, how can you enable both VAD and comfort noise synthesis? (Choose two.) A. vad
5.
B.
VAD is enabled by default on POTS interfaces.
C.
comfort-noise
D.
voice vad-time 750
What are the two different types of network delay? (Choose two.) A. Fixed B.
6.
Variable
C.
Queuing
D.
Static
What is the definition of network jitter? A. The amount of time it takes a packet to travel from its source to the destination
C05.indd 172
B.
The variation of the amount of time it takes when sending packets from the source endpoint
C.
The variation of the amount of time it takes when receiving packets at the destination
D.
The amount of time it takes a voice gateway to transcode a packet from one codec to another
9/21/11 11:19:01 AM
Review Questions
7.
173
All Cisco IP phones support what two voice codecs? A. G.729
8.
B.
G.722
C.
iLBC
D.
iSAC
E.
G.711
Which G.729 codec operates at medium complexity and has built-in VAD? A. G.729a
9.
B.
G.729b
C.
G.729i
D.
G.729ab
Which of the following is not a codec complexity option on C5510 DSP chipsets? A. Secure B.
High
C.
Medium
D.
Low
E.
Flex
10. You configure the following: Router(config-voicecard)# codec complexity secure
What did you enable? A. IPSec B.
sRTP
C.
GRE
D.
SCCP
11. By default, C5510 DSP chips are configured for what type of codec complexity? A. High B.
Secure
C.
Medium
D.
Flex
12. Which voice codec quality measurement tool is objective in testing but does not account for network problems such as latency or jitter? A. PESQ
C05.indd 173
B.
PSQM
C.
MOS
D.
POLQA
9/21/11 11:19:02 AM
Chapter 5
174
■
VoIP Design Options
13. Which of the following codecs would you likely choose when using Cisco 7921 wireless IP phones? A. G.711 B.
iSAC
C.
G.729
D.
G.726
14. You have two voice gateways separated by a low-speed WAN. The gateways must support several simultaneous low-bandwidth calls and therefore only have DSPs to support medium-complexity codecs. Which two of the following codecs could be used? A. G.729a B.
G.729b
C.
G.729ab
D.
G.711
15. You are using the G.728 codec with 40-byte payloads. The traffic is going across a framerelay network. What is the bandwidth size for a single voice frame? A. 64 bytes B.
16 bytes
C.
118 bytes
D.
86 bytes
16. You are using the G.711 codec with 80-byte payloads. cRTP (without checksums) is enabled. The traffic is going across a frame-relay network. What is the bandwidth size for a single voice frame? A. 116 bytes B.
108 bytes
C.
88 bytes
D.
122 bytes
17. The G.729 codec uses 20-byte payloads. How many PPS will one call require? A. 20 B.
C05.indd 174
33.33
C.
50
D.
10
9/21/11 11:19:02 AM
Review Questions
175
18. Your voice network uses the following network and voice codec:
G.711 (64 Kbps) 160 bit (20 byte) voice payload samples Ethernet transport How much bandwidth is required to support five simultaneous voice calls? A. 160 Kbps B.
88 Kbps
C.
436 Kbps
D.
240 Kbps
19. Your voice network uses the following network and voice codec:
G.723 (6.3 Kbps) 72 byte voice payload samples Ethernet transport IP+GRE Tunneling Approximately how much bandwidth is required to support three simultaneous voice calls? A. 41.7 Kbps B.
32.8 Kbps
C.
22.73 Kbps
D.
18.97 Kbps
20. After you calculate the total bandwidth for a voice stream, what is one other factor that you may need to take into consideration from a bandwidth usage perspective? A. Delay
C05.indd 175
B.
Jitter
C.
Packet loss
D.
VAD
9/21/11 11:19:03 AM
176
Chapter 5
■
VoIP Design Options
Answers to Review Questions 1.
D. SIP sends DTMF tones inside the voice packet payload while SCCP sends them in separate packets. An MTP (using DSPs) can be configured to translate DTMF tones between incompatible devices.
2.
C. While impedance is commonly the reason for echo on traditional telephone networks, delay is the cause on IP networks.
3.
D. VAD can detect silence on the line and prevent empty payload packets from being sent. Up to 35 percent of a call is silence, and this is the percent of bandwidth that can be eliminated from being sent on the network.
4.
A, C. By default, VAD is disabled on POTS interfaces and must be enabled with the vad command. Once VAD is enabled, it is wise to also enable comfort noise synthesis for user feedback using the comfort-noise command.
5.
A, B. Fixed delay is built into the network because of physical layer and protocol limitations. Variable delay is caused by slowdowns on the network because of queuing of packets in bottlenecks.
6.
C. Jitter is the time it takes between the receipt of one voice packet and the next voice packet in the same voice call, which varies because of network delay. A long gap between the receipt of voice packets at the destination can cause the voice stream to stutter.
7.
A, E. While newer Cisco IP phones support multiple voice codecs, low-end and older phones typically support only G.729 and G.711.
8.
D. The G.729ab codec takes the medium-complexity quality for Annex A and the built-in VAD from Annex B.
9.
D. There is no option to configure “low” codec complexity, because all codecs are considered to be of medium or high complexity.
10. B. Using the secure codec complexity option enables secure RTP (sRTP). 11. D. The newer C5510 PVDM2 chips are configured for flex codec complexity type for oversubscription. 12. B. Perceptual Speech Quality Measure is objective because the scoring methods are computerized and are highly replicated. The problem is that the test does not factor network problems into the scoring equation. 13. C. Wi-Fi is a shared medium, and therefore a low-bandwidth codec is recommended. The two most popular codecs (and the only ones that the 7921 is compatible with) are G.711 and G.729. G.729 uses only 8 Kbps of bandwidth compared to 64 Kbps per call. 14. A, C. All G.729 codecs are low bandwidth, but only the G.729a and G.729ab codecs can operate at medium complexity.
C05.indd 176
9/21/11 11:19:03 AM
Answers to Review Questions
177
15. D. total_frame_size = 48 + 320 + 320 = 688 bits = 86 bytes 16. C. total_frame_size = 48 + 16 + 640 = 704 bits = 88 bytes 17. C. PPS = 8000 / 160 = 50 18. C. total_frame_size = 144 + 320 + 1280 = 1744 bits pps = 64000 / 1280 = 50 call_bandwidth = 1744 × 50 = 88,000 bps = 87.2 Kbps 87.2 × 5 = 436 19. A. total_frame_size = 144 + 320 + 576 + 224 = 1264 bits pps = 6300 / 576 = 10.93 = 11 call_bandwidth = 1264 × 11 = 13,904 bps = 13.9 Kbps 13.9 × 3 = 41.7 Kbps 20. D. If VAD is used on your calls, it can reduce bandwidth up to 35 percent more than was calculated.
C05.indd 177
9/21/11 11:19:03 AM
Chapter 5
178
■
VoIP Design Options
Answers to Written Lab 5.1 1.
Wideband
2.
Clipping
3.
voice vad-time 500
4.
150 ms, 30 ms, and 1 percent
5.
G.711
6.
codec complexity high
7.
show voice dsp
8.
40 bytes
9.
Total packet size and packets per second (PPS)
10. 5 PPS
C05.indd 178
9/21/11 11:19:04 AM
Chapter
6
Configuring Voice Gateway Ports and DSPs THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Implement a gateway. ■
Configure analog voice ports.
■
Configure digital voice ports.
■
Configure dial peers.
■
Verify a dial plan implementation.
Describe the components of a gateway. ■
c06.indd 179
Describe different voice ports and their functionality.
9/21/11 11:19:30 AM
This is the chapter where we begin to pull in everything you’ve learned up to this point about voice networks and voice gateways and really understand how to configure our Cisco voice gateways for operation on IP and PSTN networks. In this chapter, we’ll go through the full configuration process to set up analog and digital interfaces in various scenarios. In addition, we will go through the process of configuring a digital signal processor (DSP) farm that offloads services from a CUCM. At the end of this chapter, we will examine several show, test, and debug commands used to verify configurations and troubleshoot voice gateways.
Analog Port Configurations In this section you’ll see how to configure FXS, FXO, and E&M ports and dial peers using various example scenarios, including situations such as PLAR, DID, and CAMA.
Configuring an FXS and an FXO PLAR OPX Port Our first example will show how to configure our voice gateway to connect a single FXS port for an analog telephone with a single FXO port that connects to the PSTN. Because we have a single phone with a single FXO port, we will use off-premises extension (OPX) Private Line Automatic Ringdown (PLAR) so that the telephone connected to the FXS interface must be answered before the FXO interface answers the call, as shown in Figure 6.1. F I G U R E 6 .1
An Example of FXS and FXO PLAR OPX
0/0/0 FXS Remote office Ext: 2222
V
PLAR OPX 2222
0/1/0 FXO
PSTN 555-321-1234
FXS interfaces commonly connect analog telephones or fax machines to voice gateways. To configure an FXS port, you need to enter into config-voiceport mode by choosing the slot/port number you wish to configure. For example, if we wanted to configure FXS port 0/0/0 on our router, we would issue the following commands:
c06.indd 180
9/21/11 11:19:31 AM
Analog Port Configurations
181
Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#
Once we are in config-voiceport mode, the FXS ports can be configured for various signaling. By default, FXS ports are configured to operate identically to a POTS line in the United States. Some of the default configuration settings will need to be modified to have the ports operating properly based on locale. For example, let’s say you have a voice gateway that needs to connect FXS port 0/0/0 for a single analog phone. The phone and voice gateway are located in Thailand. You should consider modifying the following options: signal You can change the signaling from the default loopstart to groundstart. Loop-
start signaling has no current flowing through it unless it is in use. Therefore it is cheaper to use and commonly found in residential homes. Ground-start signaling uses an alternate method to help eliminate glare, as you learned, but also uses more electrical current, which makes it more expensive to run. Therefore, ground start is more commonly found in businesses and costs extra. In our example configuration, we will choose to configure loopstart signaling because it is more common. This command changes the call progress tones based on the locale of the phone. You can see the different two-letter ISO-3166 country codes by issuing the cptone ? command, as shown here: cptone
Router(config-voiceport)#cptone ? locale 2 letter ISO-3166 country code AR AU AT BE BR CA CN CO C1 C2 CY CZ DK EG FI FR DE GH
c06.indd 181
Argentina Australia Austria Belgium Brazil Canada China Colombia Custom1 Custom2 Cyprus Czech Republic Denmark Egypt Finland France Germany Ghana
IN ID IE IL IT JP JO KE KR KW LB LU MY MX NP NL NZ NG
India Indonesia Ireland Israel Italy Japan Jordan Kenya Korea Republic Kuwait Lebanon Luxembourg Malaysia Mexico Nepal Netherlands New Zealand Nigeria
PE PH PL PT RU SA SG SK SI ZA ES SE CH TW TH TR AE GB
Peru Philippines Poland Portugal Russian Federation Saudi Arabia Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey United Arab Emirates United Kingdom
9/21/11 11:19:31 AM
182
GR HK HU IS
Chapter 6
Greece Hong Kong Hungary Iceland
■
Configuring Voice Gateway Ports and DSPs
NO OM PK PA
Norway Oman Pakistan Panama
US United States VE Venezuela ZW Zimbabwe
Router(config-voiceport)#cptone
Since our example router is in Thailand, we will use TH as our country code. ring cadence This command modifies the pulse and interval times when your analog phone rings. This command fi rst looks to the cptone locale and uses the default specified for that specific locale. If you want to modify this, you can use the ring cadence patternXX command or ring cadence define pulse interval command to either choose one of the preconfigured patterns or defi ne your own pulse/interval settings. In our case, we will choose to modify our ring cadence to use pattern08.
It is rare nowadays, but sometimes phones in different parts of the world are triggered to ring using different frequencies. If you fi nd yourself wondering why a phone is not ringing or emits a soft buzzing sound when it should be ringing, you may need to adjust the ring frequency. In our example, we’ll modify the default frequency from 25 Hz to 50 Hz.
ring frequency
station-id The station-id number and station-id name are often used on FXS interfaces to add caller ID information to analog phones. In our example, we configure the FXS port that is attached to our phone to the extension 2222 and a name of Remote-Office. no shutdown This command activates the FXS port we are configuring if it is in a shutdown state. Typically, interfaces default to a shutdown state, and you must manually enable them using this command.
So our fi nal configuration for a single FXS port in Thailand would look like this: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#signal loopstart Router(config-voiceport)#cptone TH Router(config-voiceport)#ring cadence pattern08 Router(config-voiceport)#ring frequency 50 Router(config-voiceport)#station-id number 2222 Router(config-voiceport)#station-id name Remote-Office Router(config-voiceport)#no shutdown Router(config-voiceport)#end Router#
c06.indd 182
9/21/11 11:19:32 AM
Analog Port Configurations
183
Now that we have our FXS port configured, we can configure our FXO port 0/1/0. Remember that FXO ports can only send DNIS information out to the PSTN. ANI can be used to route calls internally. Configuring an FXO port is similar to configuring an FXS port. The FXO port can be configured for either loop-start or ground-start signaling. The vast majority of the time, you will configure FXO ports going out to the PSTN to use ground-start signaling, which is what we will do in our setup. There are two FXO-specific commands when configuring your voice port: dial-type and ring number. You can choose to configure your FXO port to use DTMF or pulse dialing using the dial-type command. We will configure DTMF dialing, which is the default. Remember that with FXO ports, the line terminates at the router and not a telephone endpoint; therefore, the port must answer the call for you. By default, the port will answer immediately (as soon as ring 1 is detected). You can change this setting to have the port answer the call from anywhere between 1 and 10 rings using the ring number command. This command is useful when your FXO port is split and you are sharing it between a telephone and a fax machine or an automated attendant. You can configure ring number 4 so it gives a person the chance to answer the phone. If the phone is not manually answered by three rings, a soon as the fourth ring is detected, the FXO port answers the call and handles it according to the configuration. In this scenario, we will stick with the default ring number of 1. PLAR stands for Private Line Automatic Ringdown. This is an autodialing mechanism that is used to associate a port with a single destination. PLAR can be configured on FXS interfaces in locations such as public lobbies that will automatically match the extension number attached to the PLAR command with a preconfigured dial peer that points to the location of the information operator. In this situation, as soon as the PLAR-configured phone goes off-hook, the remote extension is dialed. To configure PLAR on FXS interfaces, you would use the connection plar extension command. From an FXS “bat phone” perspective, PLAR is easy to understand. But PLAR can also be used on FXO interfaces that connect to the PSTN as shown in our example. In this case, we want to automatically forward inbound calls from the PSTN to our single telephone with the extension 2222. Technically, we could use the same connection plar extension command that we use with FXS ports. But this would cause the call to be terminated fi rst at the voice gateway, and then a second ring would initiate to our analog phone at 2222. This can cause problems with situations such as carrier billing records and a call ringback cadence “hiccup.” Instead, the connection plar opx extension command bypasses the fi rst termination at the router and simply waits until the FXS port goes off-hook. Even though many of these configuration options are default settings, this example configures them for learning purposes. Therefore, the fi nal FXO port configuration looks like this: Router#configure terminal Router(config)#voice-port 0/1/0 Router(config-voiceport)#signal groundStart Router(config-voiceport)#dial-type dtmf
c06.indd 183
9/21/11 11:19:32 AM
184
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Router(config-voiceport)#ring number 1 Router(config-voiceport)#connection plar opx 2222 Router(config-voiceport)#no shutdown Router(config-voiceport)#end Router#
Now that we have our physical ports configured, we need to configure dial peers so our router will know where to route calls that are destined to either the FXS or FXO interface. To do that, we need to fi rst determine what should trigger the dial peer. Then we need to tell the dial peer from which POTS port to forward the call. For the PSTN connection, we have it set up to operate as a PLAR line that automatically triggers extension 2222, which is our analog phone extension. We need to configure a POTS dial peer to let the router know that the device connected to voice port 0/0/0 is extension 2222. To do that, we simply use the destination-pattern command. The complete configuration for our fi rst POTS dial peer looks like this: Router#configure terminal Router(config)#dial-peer voice 2222 pots Router(config-dial-peer)#destination-pattern 2222 Router(config-dial-peer)#port 0/0/0 Router(config-dial-peer)#end Router#
Lastly, calls made from the FXS port out to the PSTN require a dial peer. We will use the number 9 as our dial-peer trigger. We then want the user to be able to dial any combination of numbers so they can dial locally, nationally, and internationally. The following dial-peer configuration triggers when the fi rst digit entered by the user is 9, collects any number of digits for up to 10 seconds, and fi nally forwards all digits (except the 9) out the FXO port to the PSTN: Router#configure terminal Router(config)#dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9T Router(config-dial-peer)#port 0/1/0 Router(config-dial-peer)#end Router#
The result of these configurations is that when a caller on the PSTN dials 555-321-1234, the voice gateway automatically routes the off-premise call to extension 2222, which belongs to the analog phone attached to our FXS port. In addition, internal phones such as our analog phone can dial 9 and then a PSTN number to make off-network calls.
Configuring FXS/DID Inbound and FXO Outbound Our second example will demonstrate a different method for using FXS ports—they have the ability to function as inbound-DID ports. This is often useful in small to medium-size
c06.indd 184
9/21/11 11:19:33 AM
Analog Port Configurations
185
offices that have a block of DIDs from their PSTN and a number of high-density FXS/DID cards. DID allows callers on the PSTN or a separate PBX to dial direct telephone extensions. This means they don’t need to first call an operator or automated attendant that switches the call internally on a call-processing agent such as the CUCM. The alternative would be to have a single PSTN line for each telephone. Obviously, a one-to-one PSTN-to-internal phone scheme does not scale well and certainly is not cost effective, so the DID option is a great alternative. One caveat to using FXS ports for DID support is that the interfaces cannot be used for outbound calling to the PSTN. In that case, separate FXO interfaces and dial peers must be configured to handle outbound calling. Figure 6.2 shows our example scenario, in which an FXS/DID interface will be used for inbound DID calling.
FIGURE 6.2
FXS/DID inbound and FXO outbound Outbound calls 0/0/1 FXS
Ext: 3005
V
1/0/0 FXO 0/0/0 FXS/DID Inbound calls
PSTN
3005
PSTN strips off 555-441
555-441-3005
Let’s say we have a small office with 10 internal phones. Our PSTN has given us the following block of numbers: 555-441-3000 to 555-441-3009. When someone on the PSTN dials 555-441-3005, the PSTN will strip off all but the last four digits and send 3005 to our voice gateway on the FXS/DID 0/0/0 port using DID wink-start signaling. The four-digit extension is matched against the 3005 dial peer, and the call is routed out to the analog phone configured on FXS interface 0/0/1. First, we will configure our FXS/DID port that connects to the PSTN and the FXS port that connects to the analog phone: Router#configure terminal Router(config)#voice-port 0/0/0 Router(config-voiceport)#signal did wink-start Router(config-voiceport)#no shutdown Router(config-voiceport)#voice-port 0/0/1 Router(config-voiceport)#signal loopstart Router(config-voiceport)#no shutdown Router(config-voiceport)#end Router#
Next, we will configure the inbound dial peer for the FXS/DID port. To accomplish this, we will use the direct-inward-dial command to enable DID for this dial peer. This command matches the DNIS destination number in the dial peer. In our case, we will use
c06.indd 185
9/21/11 11:19:33 AM
186
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
the incoming called-number .... command so we can match any four digits that come in from the PSTN: Router#configure terminal Router(config)#dial-peer voice 10 pots Router(config-dial-peer)#direct-inward-dial Router(config-dial-peer)#incoming called-number.... Router(config-dial-peer)#port 0/0/0 Router(config-dial-peer)#end Router#
Now we can configure the dial peer for our analog phone at extension 3005: Router#configure terminal Router(config)#dial-peer voice 3005 pots Router(config-dial-peer)#destination-pattern 3005 Router(config-dial-peer)#port 0/0/1 Router(config-dial-peer)#end Router#
DID configurations such as the previous dial-peer configuration highlight a classic example of one-stage dialing. When DID is configured on an inbound dial peer as you see here, our local voice gateway never terminates the call or presents a dial tone to the calling party. What happens is that the digits are simply collected using the direct-inwarddial command and matched against a dial peer. The dial peer in turn then sends the call setup signaling information out port 0/0/1. If we did not use the direct-inward-dial command and instead had an FXO port connected to our PSTN, we would need to use two-stage dialing. This means that a caller would dial an extension that terminates at the FXO port. Then the router would present a secondary dial tone at which the caller would have to dial an internal extension to reach the desired phone. Alternatively, an autoattendant can be configured on the voice network to route calls using a two-stage dialing method.
At this point, people on the PSTN can dial 555-441-3005 and reach our analog phone. However, we still need to configure off-network dialing on our FXO interface. To accomplish this goal, we will configure our physical FXO 1/0/0 interface for ground-start signaling and create a dial peer that matches a 9 followed by the common wildcard digitmatching configuration used to dial nationally within the NANP. Be sure to strip off only the 9 and send all other digits to the PSTN: Router#configure terminal Router(config)#voice-port 1/0/0
c06.indd 186
9/21/11 11:19:34 AM
Analog Port Configurations
187
Router(config-voiceport)#signal groundStart Router(config-voiceport)#no shutdown Router(config-voiceport)#exit Router(config)#dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9[2–8]......... Router(config-dial-peer)#forward-digits 10 Router(config-dial-peer)#port 1/0/0
Configuring E&M to Bridge Legacy PBX with VoIP Networks If you need to configure analog E&M trunks on a Cisco voice gateway, it is highly likely that the other end of that connection connects to a legacy PBX. Figure 6.3 shows a voice gateway that bridges an IP-based voice network with a legacy PBX phone system.
FIGURE 6.3
E&M to bridge legacy and VoIP networks Extensions 5xxx
Extensions 4xxx E&M Trunks 2/1 2/0 PBX PBX E&M settings: Type I 4-wire Immediate-start
Fa 4/0 V
IP network
To IP: 192.168.10.2
As you can see from the diagram, the IP and legacy voice networks are bridged by two E&M ports. In addition, the PBX requires this type of E&M setup: ■
E&M port type 1
■
Four-wire operation
■
Immediate-start signaling First, we will configure and enable our two E&M ports:
Router#configure terminal Router(config)#voice-port 2/0 Router(config-voiceport)#signal immediate-start
c06.indd 187
9/21/11 11:19:34 AM
188
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Router(config-voiceport)#operation 4-wire Router(config-voiceport)#type 1 Router(config-voiceport)#no shutdown Router(config-voiceport)#voice-port 2/1 Router(config-voiceport)#signal immediate-start Router(config-voiceport)#operation 4-wire Router(config-voiceport)#type 1 Router(config-voiceport)#no shutdown Router(config-voiceport)#exit
Next, we will configure dial peers that match our four-digit PBX extension numbers and forward them to our two E&M ports: Router(config)#dial-peer voice 4000 pots Router(config-dial-peer)#destination-pattern 4... Router(config-dial-peer)#forward-digits all Router(config-dial-peer)#port 2/0 Router(config-dial-peer)#dial-peer voice 4001 pots Router(config-dial-peer)#destination-pattern 4... Router(config-dial-peer)#forward-digits all Router(config-dial-peer)#port 2/1
Lastly, we can configure a dial peer for calls coming inbound from the E&M ports that are destined to our IP phones. Note that this configuration assumes that our voice gateway is properly configured for IP routing between the two voice gateways shown in Figure 6.3. Router(config-dial-peer)#dial-peer voice 5000 voip Router(config-dial-peer)#destination-pattern 5... Router(config-dial-peer)#session target ipv4:192.168.10.2
Configuring CAMA In North America, there are special port configurations that connect to Centralized Automatic Messaging Accounting (CAMA) trunks. While CAMA trunks can be used for a variety of reasons, they are primarily used for dedicated access to Enhanced 911 (E911) services. Some U.S. states require businesses over a certain size to connect directly to the E911 service. Businesses are commonly required to do so because they have large buildings or campus areas, and the CLID for outbound calls oftentimes is a centralized number as opposed to a specific extension. Therefore, the Automatic Number Identification (ANI) is used by emergency services to better pinpoint where a caller is within a business.
c06.indd 188
9/21/11 11:19:35 AM
Analog Port Configurations
189
These CAMA trunks then terminate at a local Public Safety Answering Point (PSAP). When a 911 call is made from one of the IP phones, as shown in Figure 6.4, the voice gateway should route the call out the CAMA trunk to the PSAP.
FIGURE 6.4
CAMA trunk to E911 services
Internal voice network 911 OR 9911 is dialed.
PSTN
V
Dial peer matched and 911 digits sent to PSAP.
E911 operators
CAMA 0/1
911 with ANI for reverse lolkup
PSAP KP-0-NPANXX-XXXX-ST
Normally, a PSTN call is routed based on the destination telephone number. E911, on the other hand, routes calls based on the calling party’s ANI. The ANI is for E911 call routing to help pinpoint the location of the call using a database and, ultimately, where the emergency is. Having the ANI is also useful if the emergency call has been disconnected and the E911 operator needs a callback number. Cisco FXO interface cards can be used to configure CAMA trunks such as the fourport VIC-4FXO. There are five CAMA signaling options to choose from, as shown in this example: Router(config-voiceport)#signal cama ? KP-0-NPA-NXX-XXXX-ST KP-0-NXX-XXXX-ST KP-2-ST KP-II-NPA-NXX-XXXX-ST-KP-NPA-NXX-XXXX-ST KP-NPD-NXX-XXXX-ST
Type Type Type Type Type
2 1 3 5 4
CAMA CAMA CAMA CAMA CAMA
Signaling Signaling Signaling Signaling Signaling
The different signaling types primarily have to do with ANI and the number of digits the PSAP is requesting as directed by your local emergency services. For example, when using KP-0-NPA-NXX-XXXX-ST, the PSAP expects to see all 10 of the E.164 digits, while KP0-NXX-XXXX-ST signaling will drop the area code prior to forwarding digits. The type of signaling used depends on your local PSAP. Make sure you configure your CAMA for the proper signaling it is expecting.
c06.indd 189
9/21/11 11:19:35 AM
190
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
If emergency services in your area require you to use KP-NPD-NXX-XXXX-ST signaling, one additional step is required. The NPD in the signaling name stands for Numbering Plan Digit. This is a single digit that represents the three-digit NANP area code. Therefore, the PSAP requires that our voice gateway send the NPD plus the three-digit central office and four-digit subscriber code. Because of this, we must manually configure a table that maps area codes to NPD codes that are specified by emergency services in our area. For example, NPD digit 0 represents area code 555; therefore we can use the ani mapping command as shown here:
Router(config-voiceport)#ani mapping 0 555 A full example of this configuration is found in Hands-On Lab 6.2 at the end of this chapter.
In our example, the PSAP requires that we configure KP-0-NXX-XXXX-ST signaling. In addition to the port setup, we will configure two dial peers to be routed out our CAMA port. One dial peer will be for when users dial 911 and the other for users who dial 9911, which is commonly done in environments where users are trained to dial 9 to reach an outside line. For this particular dial peer, make sure you forward only the 911 digits. The configuration of the voice port looks like this: Router#configure terminal Router(config)#voice-port 0/1 Router(config-voiceport)#signal cama KP-0-NPA-NXX-XXXX-ST Note: need to shut/no shut to complete the CAMA signal type configuration. Router(config-voiceport)#shutdown Router(config-voiceport)#no shutdown Router(config-voiceport)#exit
You can see that after we changed signaling to CAMA, the router gave us a console message stating we must perform a shutdown and no shutdown on the FXO port to put the interface into CAMA mode. Once the FXO port is configured, we can create the dial peers to send 911 and 9911 calls out the CAMA interface. Here’s how to accomplish this task: Router(config)#dial-peer voice 911 pots Router(config-dial-peer)#destination-pattern 911 Router(config-dial-peer)#forward-digits all Router(config-dial-peer)#port 0/1 Router(config-dial-peer)#exit Router(config)#dial-peer voice 9911 pots Router(config-dial-peer)#destination-pattern 9911 Router(config-dial-peer)#forward-digits 3 Router(config-dial-peer)#port 0/1 Router(config-dial-peer)#end Router#
c06.indd 190
9/21/11 11:19:36 AM
Digital Port Configurations
191
Notice that when we changed the signal type, the router asked us to perform a shut/no shut to complete the CAMA signal type configuration. Also, notice that in both dial peers, we used the forward-digits all and forward-digits 3 commands to forward either all dialed digits or just the last three digits in the case a user dials 9911. As you are aware already, different digit-manipulation methods can be used to achieve the same goal. For example, instead of the forward-digits all command, we could have chosen to use no digit-strip. Or in both the 911 and 9911 configurations, we could have used the prefix 911 command. There is no right or wrong way to do this as long as you accomplish your goal to forward 911 out the CAMA interface.
Digital Port Configurations Now we will move on to discuss various digital port configurations. Digital PSTN connections are commonly used as multichannel trunks to the PSTN. In this section, we will configure a T1 CAS, T1 PRI, and an ISDN BRI port to the PSTN in a couple of different real-world scenarios.
Configuring a T1 CAS to Analog Cross-Connect In our fi rst scenario, we are going to configure a digital T1 CAS to interoperate with analog phones. This is useful for situations where analog devices such as fax machines are still used. Figure 6.5 shows an example of a site that has one fax machine that requires a dedicated analog line. To accomplish this goal with our T1 CAS, we can take one of the 24 T1 CAS digital (DS0) channels and place it into what is known as a ds0-group. Once we carve off our single CAS channel timeslots, we can configure it to operate in a channel bank mode, where the digital circuit cross-connects to analog lines. FIGURE 6.5
A CAS channel bank example
0/0/0 FXS Fax
V
1/0 T1 CAS
PSTN
PSTN CAS settings: ESF B8ZS Clock from PSTN
To configure the T1 CAS card for channelization support, you should fi rst identify the T1 CAS slot/port and enter into config-controller mode. All T1s and E1s on a Cisco router are configured by entering config-controller mode. Compare this to how we
c06.indd 191
9/21/11 11:19:36 AM
192
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
configure analog ports, by entering config-voiceport mode. In our example, we will fi rst configure the T1 CAS settings as follows: ■
Extended Superframe (ESF) framing type
■
B8ZS line coding
■
Clock source from the PSTN (line)
■
ds0-group 0 that has one DS0 configured as FXO with ground-start signaling
The framing type sets the framing that your PSTN provider has configured on their end. You can see the options listed here while in config-controller mode: Router#config t Router(config)#controller t1 1/0 Router(config-controller)#framing ? esf Extended Superframe sf Superframe
We will configure ESF framing for the T1 CAS: Router(config-controller)#framing esf Router(config-controller)#
The line coding type you choose again depends on your PSTN provider. You have to set your linecode to match whatever coding they provide to you on the circuit. Your options are AMI or B8ZS. B8ZS is by far the most common linecoding these days, and we will configure it here: Router(config-controller)#linecode ? ami AMI encoding b8zs B8ZS encoding Router(config-controller)#linecode b8zs Router(config-controller)#
The T1 CAS is a digital TDM circuit, as you have already learned. And digital circuits must use precise clocking to determine when bits are sent across the wire. You have two configuration options for clocking, as shown here: Router(config-controller)#clock source ? internal Internal Clock line Recovered Clock
In this example, we will choose to receive clocking from the PSTN, so we will select the line option: Router(config-controller)#clock source line Router(config-controller)#
c06.indd 192
9/21/11 11:19:37 AM
Digital Port Configurations
193
One of the great advantages of a CAS circuit is the ability to break up DS0s into DS0 groups that can be used for different purposes. In our example, we will assume that we want to configure only the fi rst timeslot for a fax machine. The fax machine uses an FXS port with loop-start signaling. A second analog port will be used to connect to a legacy PBX using two-wire E&M wink start. The T1 channel for our fax will use loop start for signaling to the CO. The channel used to connect to the legacy PBX will be configured for E&M immediate start. First, let’s look at all the different ds0-group port types available: Router(config-controller)#ds0-group 0 timeslots 1 type ? e&m-delay-dial E & M Delay Dial e&m-fgd E & M Type II FGD e&m-immediate-start E & M Immediate Start e&m-wink-start E & M Wink Start ext-sig External Signaling fgd-eana FGD-EANA BOC side fgd-os FGD-OS BOC side fxo-ground-start FXO Ground Start fxo-loop-start FXO Loop Start fxs-ground-start FXS Ground Start fxs-loop-start FXS Loop Start none Null Signalling for External Call Control Router(config-controller)#ds0-group 0 timeslots 1 type
Now we will configure ds0-group 0 to include the fi rst timeslot with loop-start signaling. Ds0-group 1 will then be configured for E&M immediate start. We then individually configure our logical DS0 ports by using the T1 slot/port number, followed by a colon (:) and the ds0-group number, which is either 0 or 1 in our case: Router(config-controller)#ds0-group 0 timeslots 1 type fxo-loop-start Router(config-controller)#ds0-group 1 timeslots 2 type e&m-immediate-start Router(config-controller)#exit Router(config)#voice-port 1/0:0 Router(config-voiceport)#signal loop-start Router(config-voiceport)#no shutdown Router(config-voiceport)#exit Router(config)#voice-port 1/0:1 Router(config-voiceport)#signal wink-start Router(config-voiceport)#operation 2-wire Router(config-voiceport)#no shutdown Router(config-voiceport)#end Router#
c06.indd 193
9/21/11 11:19:37 AM
194
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
That completes our setup of our T1 CAS port for cross-connecting an analog fax and a PBX using the DS0 channel bank. The fi nal steps require us to configure the FXS ports that our analog fax machine and legacy PBX connect to along with the appropriate dial peers that map the analog extension to the FXS ports and FXO for outbound PSTN dialing. The one new global configuration command we need to use here to complete the channel bank cross-connect is connect name voice-port analog-port T1 digital-port ds0-groupnumber, which specifies that we will be mapping our DS0 channels to our two FXS ports. The name specifies a unique name identifier, while the analog-port and digital-port options specify the slot/port of the connections we are cross-connecting. The ds0-group-number is the number we use to identify the one channel DS0 group configuration, as shown here: Router#config t Router(config)#connect fax1 voice-port 0/0/0 t1 1/0 0 Router(config)#connect pbx1 voice-port 0/0/1 t1 1/0 1
And to complete the configuration we configure dial peers for our FXS and E&M analog ports. We will also configure the necessary inbound and outbound dial peers. The dial peer for the FXS port is self-explanatory. A second inbound dial peer for the E&M port will route calls in the 555200XXXX range to the legacy PBX. On the T1 port, our inbound dial peers accept calls from any number. And the outbound dial peer uses 9 as the trigger digit for the voice gateway plus 10-digit national dialing in the United States. Notice that we specify the DS0 group number when we tell the router to route off-network calls to the PSTN: Router(config)#dial-peer voice 5551 pots Router(config-dial-peer)#destination-pattern 5551003000 Router(config-dial-peer)#port 0/0/0 Router(config)#dial-peer voice 5552 pots Router(config-dial-peer)#destination-pattern 555200.... Router(config-dial-peer)#port 0/0/1 Router(config)#dial-peer voice 1 pots Router(config-dial-peer)#incoming called-number. Router(config-dial-peer)#port 1/0:0 Router(config)#dial-peer voice 2 pots Router(config-dial-peer)#incoming called-number. Router(config-dial-peer)#port 1/0:1 Router(config)#dial-peer voice 11 pots Router(config-dial-peer)#incoming called-number 555200.... Router(config-dial-peer)#port 1/0:1 Router(config-dial-peer)# dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9[2–8]......... Router(config-dial-peer)#forward-digits 10 Router(config-dial-peer)#port 1/0:0
c06.indd 194
9/21/11 11:19:38 AM
Digital Port Configurations
195
Router(config-dial-peer)# dial-peer voice 99 pots Router(config-dial-peer)#destination-pattern 9[2–8]......... Router(config-dial-peer)#forward-digits 10 Router(config-dial-peer)#port 1/0:1 Router(config-dial-peer)#end Router#
We can now verify our channel bank setup by issuing the show connection all command, which displays the list of connections, their mappings, and their current state: Router# show connection all ID Name Segment 1 Segment 2 State ========================================================================== 1 fax1 voice-port 0/0/0 T1 1/0 01 UP 2 pbx1 voice-port 0/0/1 T1 1/0 02 UP
Configuring a T1 PRI The configuration of T1/E1 PRI circuits is similar to that of T1/E1 CAS circuits. We’ll point out several differences throughout this example. For this configuration, we are asked to configure a fractional T1 circuit consisting of 12 channels. We are only asked to configure the T1 connection to the PSTN and the outbound dial peer for off-network calling, as shown in Figure 6.6.
FIGURE 6.6
An ISDN T1 PRI example
V
3/0 T1 PRI
PSTN
ISDN switch: Primary-NI PSTN PRI settings: Channels: 1-12 ESF B8ZS Clock from PSTN
Don’t forget that BRI and PRI ISDN carry Q.921 and Q.931 signaling out of band. These two signaling protocols are used between the voice gateway and ISDN switch. Several different switch types are in use on PSTNs around the world. When you are
c06.indd 195
9/21/11 11:19:38 AM
196
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
configuring a voice gateway, you must know which type of ISDN switch your PSTN is using. You configure the switch type globally on the voice gateway by issuing the isdn switch-type type command. The following output shows the different IDSN switch types; after reviewing them, we’ll configure the voice gateway to use primary-ni: Router#configure terminal Router(config)#isdn switch-type ? primary-4ess Lucent 4ESS switch type for the U.S. primary-5ess Lucent 5ESS switch type for the U.S. primary-dms100 Northern Telecom DMS-100 switch type for the U.S. primary-dpnss DPNSS switch type for Europe primary-net5 NET5 switch type for UK, Europe, Asia and Australia primary-ni National ISDN Switch type for the U.S. primary-ntt NTT switch type for Japan primary-qsig QSIG switch type primary-ts014 TS014 switch type for Australia (obsolete) Router(config)#isdn switch-type primary-ni
Once we have set our PSTN’s switch type globally, we can enter config-controller mode and begin configuring our T1 circuit. When configuring a PRI, we use the prigroup command to specify the timeslots we will be using. In our scenario, we will be using only 12 channels for voice. We also must remember to include the 24th timeslot for our signaling channel. The D timeslot is always 24 on a T1. But always remember that timeslots of a T1 are numbered 1–24. However, channels are numbered 0–23. That means that the D timeslot is 24 and the D channel is 23. And the E1 D timeslot is 16, while the D channel is 15. Here is how we configure our T1 PRI to identify the fi rst 12 timeslots for voice transport and our 24th timeslot for Q.921 and Q.931 signaling. We will also configure framing, linecoding, and the clock source: Router#configure terminal Router(config)#controller t1 3/0 Router(config-controller)#pri-group timeslots 1-12,24 Router(config-controller)#framing esf Router(config-controller)#linecode b8zs Router(config-controller)#clock source line Router(config-controller)#end Router#
We can verify that our channels were properly configured by issuing the show voice port summary command, as shown here:
c06.indd 196
9/21/11 11:19:38 AM
Digital Port Configurations
197
Router1#show voice port summary PORT =============== 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23 0/1/0:23
CH SIG-TYPE ADMIN == ============ ===== 01 xcc-voice up 02 xcc-voice up 03 xcc-voice up 04 xcc-voice up 05 xcc-voice up 06 xcc-voice up 07 xcc-voice up 08 xcc-voice up 09 xcc-voice up 10 xcc-voice up 11 xcc-voice up 12 xcc-voice up
PWR FAILOVER PORT =================
IN STATUS ======== none none none none none none none none none none none none
OPER ==== dorm dorm dorm dorm dorm dorm dorm dorm dorm dorm dorm dorm
OUT STATUS ======== none none none none none none none none none none none none
EC == y y y y y y y y y y y y
PSTN FAILOVER PORT ==================
Router#
The second column in the output of the show voice port summary command is CH, for channel, which lists all 12 of our usable voice circuits. You can also see that our logical D channel has been created as serial 0/1/0:23. We need to go into our D channel interface and configure the isdn incoming-voice voice command to specify that this T1 circuit will be used only for voice. Keep in mind that ISDN can transport voice, data, or both on a T1 or E1. If the channels are configured for voice, the voice gateway directs calls to be processed by the DSP. If they are configured for data, the voice gateway bypasses the DSPs: Router#configure terminal Router(config)#interface serial 0/0:23 Router(config-if)#isdn incoming-voice voice Router(config-if)#end Router#
Our last step is to configure an outbound dial peer for off-network national calls. Notice that since all of our signaling is handled by channel 23, we send all this information to the logical 0/1/0:23 port: Router(config-dial-peer)#dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9[2–8]......... Router(config-dial-peer)#forward-digits 10
c06.indd 197
9/21/11 11:19:39 AM
198
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Router(config-dial-peer)#port 0/1/0:23 Router(config-dial-peer)#end Router#
Configuring DSP Resources You’ve already learned how to configure your DSPs manually, to handle the termination of voice codecs that operate in low, medium, or high complexities. In addition you know what flex and secure modes are and when they should be used. In this section, we will explore how to configure the offloading of transcoding, conferencing, and media termination points (MTP) services from the call-processing agent such as the CUCM.
Enabling a DSP Farm on a Voice Gateway DSP chips can be included directly on voice card modules, or they can be independently installed onto the router motherboard on chips that look similar to PC RAM. Once you have sufficient DSP resources installed for the job, your next task is to configure your router as a DSP farm. As the name implies, the router will work to offload, or farm out, tasks such as transcoding and conferencing from the CUCM. Thus the CUCM must be configured to allow DSP farming to proceed. The only way to do this with Cisco callprocessing agents and voice gateways is to use either the Cisco proprietary SCCP protocol or MGCP. SCCP allows for more advanced configuration, and we will use this in our configuration example. Figure 6.7 shows the communication process between the callprocessing agent and the voice gateway acting as a DSP farm. F I G U R E 6 .7
SCCP communication between CUCM and DSP farm
CUCM v8.0
com SCC mu P nic atio n
Fa 4/0 V
Switch
DSP farm
SCCP is used so that when the call-processing agent receives a request for transcoding, conferencing, or MTP services, it can notify the DSP farm gateway and direct traffic away from the CUCM and instead to the DSP farm.
c06.indd 198
9/21/11 11:19:39 AM
Configuring DSP Resources
199
A DSP farm can function to support one service, such as transcoding, or a combination of services depending on what is required on the network. To enable a DSP farm operation on a voice gateway, fi rst navigate to the DSP card you wish to use and then issue the dsp services dspfarm command, as shown here: Router#configure terminal Router(config)#voice-card 1 Router(config-voicecard)#dsp services dspfarm Router(config-voicecard)#exit Router(config)#
Creating DSP Profiles Once DSP farm services are enabled, it’s time to create DSP profiles, which are used to allocate DSP resources and set their terms of usage. DSP profiles are broken into the three services that DSP farms can handle. A profile can be made for transcoding, conferencing, and MTP. Also, each profile is given a unique identifier, so it is possible to configure more than one transcoding profile, for example, if you require different profile settings to be used. Once you have chosen the profi le type and given it a unique profi le identifier number, you will be placed into config-dsp-farm-profile mode. Here you can configure the unique profi le rules, such as the codec types that can be used and the number of maximum sessions the profi le can handle at one time. Another required setting is to associate the profi le to SCCP for communication to the CUCM using the associate application SCCP command. One last thing to remember is that the profi le must be enabled by issuing no shutdown. This will activate the profile, and the DSP resources required will be allocated. For example, the following is transcoding profi le 10, which specifies a number of codecs that are allowed to be transcoded between one another. The maximum number of simultaneous sessions is set to 5, and the profile is associated with SCCP: Router(config)#dspfarm profile 10 transcode Router(config-dspfarm-profile)#codec g711ulaw Router(config-dspfarm-profile)#codec g711alaw Router(config-dspfarm-profile)#codec g729ar8 Router(config-dspfarm-profile)#codec g729abr8 Router(config-dspfarm-profile)#codec g729r8 Router(config-dspfarm-profile)#maximum sessions 5 Router(config-dspfarm-profile)#associate application SCCP Router(config-dspfarm-profile)#no shutdown
The maximum sessions command default is 0, so this number must be changed before DSP resources are allocated for a profile.
c06.indd 199
9/21/11 11:19:40 AM
200
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
The configuration of transcoding and conferencing resources is identical except for the profi le commands that identify the two. When configuring MTP resources, the maximum sessions command requires an additional keyword to be set. The hardware setting specifies that DSP resources are used, while the software setting actually uses the router processor and performs MTP in software. If you configure maximum sessions hardware, keep in mind that MTP will only work for G.711 a-law and mu-law. If you have already configured a hardware profi le and realize you need to support other codecs, you must fi rst remove the command by issuing a no maximum sessions command. Also remember that since MTP software profi les do not use DSP resources (they use the router’s CPU instead), you could exhaust your processing power if you terminate too many MTPs in software. So if we wanted to configure a DSP profi le 15 for MTP to terminate two calls using hardware and two calls using software, we would configure something similar to the following: Router(config)#dspfarm profile 15 mtp Router(config-dspfarm-profile)#codec g711ulaw Router(config-dspfarm-profile)#maximum sessions hardware 2 Router(config-dspfarm-profile)#maximum sessions software 2 Router(config-dspfarm-profile)#associate application SCCP Router(config-dspfarm-profile)#no shutdown
Configuring SCCP Communications Now that we have our DSP farm enabled and our profi les created, we can configure our DSP farm router to communicate with our CUCM, as was shown in Figure 6.7. To accomplish the SCCP configuration of the router, we fi rst must enable SCCP on the router. To do this, we need to identify the IP address and physical port that the router will use to communicate to our CUCM. In our case, the CUCM is at 10.10.10.100 and fa4/0 is the interface that will be used. When configuring the CUCM IP addresses, you can use either the IP address or the domain name. You can configure the router to do a domain lookup to retrieve the IP address using this method. Additionally, you should configure the following settings: identifier A unique identifier to specify that this configuration is used between the router interface and a specific CUCM. priority If there is a redundant pair of CUCM call-processing agents, you can use priority to create a primary connection and a backup connection in the case of a failure.
Used to identify the version of software that the CUCM is running. As this book goes to press, a CUCM running either version 7.0 or 8.0 software will use the version 7.0+ setting.
version
Next, it is time to identify the port that will be used to communicate to the CUCM. The command we use to identify the port is sccp local. Finally, we can bring up SCCP on the router by simply issuing the sccp command. Here is how to configure SCCP for our example:
c06.indd 200
9/21/11 11:19:40 AM
Configuring DSP Resources
201
Router#configure terminal Router(config)#sccp ccm 10.10.10.100 identifier 1 priority 1 version 7.0+ Router(config)#sccp local FastEthernet 4/0 Router(config)#sccp Router(config)#
We now have successfully identified our CUCM to the DSP farm gateway. The next configuration step on the voice gateway is to create a DSP farm profile that associates the farm with a CUCM call-processing agent group. The first step is to use the sccp cucm group command and give it a unique number. Once you create a group, you will be placed into configsccp-ccm mode, where you can configure settings that must match your CUCM configuration on the call-processing agent. The bind interface command specifies the interface on which the group will be active. Next, you need to configure two associate commands to specify the CUCM the group pertains to and set the priority of the call-processing unit. The first command will be associate ccm identifier-number priority priority-number. The identifiernumber must match the identifier that we configured previously in the sccp ccm 10.10.10.100 identifier 1 priority 1 version 7.0+ command. In our case, the identifier-number is 1. The priority-number specifies which CUCM is preferred if multiple units are configured for redundancy. Up to four CUCM servers can be configured, where 1 is the most preferred and 4 is the least. The associate profile command sets the group to use the profile we previously configured, which is 15. The final group command is the register device-name command. The device-name is a unique name that must be identical on both the voice gateway configuration and the CUCM configuration. In our example, we use TXDSPFARM1 as our device-name. All of the SCCP group configuration commands are shown here: Router(config)# Router(config)#sccp ccm group 1 Router(config-sccp-ccm)#bind interface FastEthernet4/0 Router(config-sccp-ccm)#associate ccm 1 priority 1 Router(config-sccp-ccm)#associate profile 15 Router(config-sccp-ccm)#register TXDSPFARM1
Configuring the CUCM At this point our DSP farm on our voice gateway has been configured and points to one or more CUCM call-processing agents. Now we must configure the CUCM to offload the media resources we want the DSP farm to handle. While the configuration of a CUCM is outside the scope of this book, you can fi nd where to configure the offloading of media services when using the CUCM version 8.0 GUI by fi rst logging into the Cisco Unified CM Administration portion of the server. Next, navigate to the Media Resources tab and select one of the three resources to offload:
c06.indd 201
■
Conference Bridge
■
Transcoder
■
Media Termination Point
9/21/11 11:19:41 AM
Chapter 6
202
■
Configuring Voice Gateway Ports and DSPs
Figure 6.8 shows the Media Resources tab’s drop-down list choices. FIGURE 6.8
The CUCM Media Resources tab
From here, you can configure the CUCM to utilize the DSP farm located on your voice gateway to handle these media resource services, which will free up CPU and memory resources on the call-processing agent to handle more calls.
Match Up Those Names! Sara and Mitch were setting up a new CUCM and DSP farm. Sara was responsible for configuring the CUCM and Mitch was responsible for configuring the DSP farm router. When the two finished their respective configurations, they discovered that the CUCM and DSP farm would not cooperate when attempting to offload conference-calling duties. Network connectivity was working properly, so the two administrators rechecked their respective configurations. As it turns out, the CUCM configuration used the following as the conference bridge name: ConfDSP1 And the DSP farm IOS listed the following when they issued a show runningconfiguration command: register CnfDSP1 The conference bridge names must match exactly on the CUCM and DSP farm configurations. The configuration was small, only one character off, but it was the difference between a working conference bridge farm and a nonworking one.
c06.indd 202
9/21/11 11:19:41 AM
Voice Port and Dial-Peer Verification Commands
203
Voice Port and Dial-Peer Verification Commands In this section, you will get to know some useful show, test, and debug commands to verify analog and digital voice port configurations and status. Some of the commands have been used previously in this book, and others are new to you. The commands you should be familiar with are these: ■
show voice port
■
show controller [t1|e1]
■
show voice dsp
■
test voice port
■
csim start
■
debug dialpeer
Let’s take a quick look at each of these to see what information they can provide.
show voice port The show voice port command is probably one of the most useful ways to verify configurations and for troubleshooting. The command can be used on its own or with one of several command options to display various port information. The show voice port command on its own displays detailed information about all voice ports installed on the voice gateway. You can also specify a specific port, as shown here, where we view the information for a single port 0/0/0 (in this case, an FXS port): Router#show voice port 0/0/0 Foreign Exchange Station 0/0/0 Slot is 0, Sub-unit is 0, Port is 0 Type of VoicePort is FXS Operation State is DORMANT Administrative State is UP The Interface Down Failure Cause is 0 Alias is NULL Noise Regeneration is enabled Non Linear Processing is enabled Music On Hold Threshold is Set to 0 dBm In Gain is Set to 0 dB Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16ms Connection Mode is Normal
c06.indd 203
9/21/11 11:19:42 AM
204
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Connection Number is Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Analog Info Follows: Region Tone is set for northamerica Currently processing none Maintenance Mode Set to None (not in mtc mode) Number of signaling protocol errors are 0 Voice card specific Info Follows: Signal Type is loopStart Ring Frequency is 25 Hz Hook Status is On Hook Ring Active Status is inactive Ring Ground Status is inactive Tip Ground Status is inactive Digit Duration Timing is set to 100 ms InterDigit Duration Timing is set to 100 ms Hook Flash Duration Timing is set to 600 ms
This command is useful to verify operational information such as operation and administration state, on/off-hook status, and ring status. In addition, you can verify configuration settings such as signal type, cptone, and ring frequency. If you want to get a quick glance at all of your voice interfaces with just a few details, you can use the show voice port summary command, as shown here: Router#show voice port summary PORT ============== 0/0/0 0/0/1 0/0/2 0/0/3 0/1/0 0/1/1 0/1/2 0/1/3
IN OUT CH SIG-TYPE ADMIN OPER STATUS STATUS == ============ ===== ==== ======== ======== — fxs-ls up dorm on-hook idle — fxs-ls up dorm on-hook idle — fxs-ls up dorm on-hook idle — fxs-ls up dorm on-hook idle — fxo-gs up dorm idle on-hook — fxo-gs up dorm idle on-hook — fxo-gs up dorm idle on-hook — fxo-gs up dorm idle on-hook
EC == y y y y y y y y
Router#
Here, you can see that this particular voice gateway has one four-port FXS and one four-port FXO card installed. The -ls in the SIG-TYPE column tells us that the FXS ports are configured with loop-start signaling, and the -gs tells us that the FXO ports are
c06.indd 204
9/21/11 11:19:42 AM
Voice Port and Dial-Peer Verification Commands
205
configured for ground-start signaling. The other columns tell us the status of our ports to ensure that they are working properly.
show controller The show controller command displays configuration and status information for digital T1 or E1 trunks. The following example output shows the status and setup of T1 1/0: Router# show controller T1 1/0 T1 1/0 is up. Applique type is Channelized T1 Cablelength is long gain36 0db No alarms detected. alarm-trigger is not set Framing is ESF, Line Code is B8ZS, Clock Source is Line. Data in current interval (180 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
From the output you can see that the circuit is up and configured for ESF/B8ZS. In addition, the clocking is set for Line, which will use clocking from the PSTN switch.
show voice dsp For troubleshooting voice problems that may be related to DSP chips, you can us the show voice dsp command to verify the codec configuration (medium, high, flex, or secure) and to view the current state of all DSP resources. Here is an example of typical output using this command: Router#show voice dsp DSP
DSP
DSPWARE CURR
TYPE NUM CH CODEC
BOOT
PAK
VERSION STATE STATE
RST AI VOICEPORT TS ABORT
TX/RX PACK COUNT
——————————————FLEX VOICE CARD 0——————————————— *DSP VOICE CHANNELS*
CURR STATE: (busy)inuse (b-out)busy out (bpend)busyout pending LEGEND
c06.indd 205
: (bad)bad
(shut)shutdown
(dpend)download pending
DSP
DSP
DSPWARE CURR
TYPE
NUM CH CODEC
VERSION STATE STATE
BOOT
PAK
TX/RX
RST AI VOICEPORT TS ABRT PACK COUNT
9/21/11 11:19:42 AM
Chapter 6
206
■
Configuring Voice Gateway Ports and DSPs
===== === == ========= ======= ===== ======= === == ========= == ==== *DSP SIGNALING CHANNELS* DSP
DSP
DSPWARE CURR
TYPE
NUM CH CODEC
VERSION STATE STATE
BOOT
PAK
TX/RX
RST AI VOICEPORT TS ABRT PACK COUNT
===== === == ========= ======= ===== ======= === == ========= == ==== C5510 003 01 {flex}
9.4.7 alloc idle
0
0
2/0/0
02
0
81/0
C5510 003 02 {flex}
9.4.7 alloc idle
0
0
2/0/1
02
0
81/0
C5510 003 03 {flex}
9.4.7 alloc idle
0
0
2/0/2
06
0
80/0
C5510 003 04 {flex}
9.4.7 alloc idle
0
0
2/0/3
06
0
81/0
C5510 003 05 {flex}
9.4.7 alloc idle
0
0
2/0/4
10
0
80/0
C5510 003 06 {flex}
9.4.7 alloc idle
0
0
2/0/5
10
0
81/0
C5510 003 07 {flex}
9.4.7 alloc idle
0
0
2/0/6
14
0
80/0
C5510 003 08 {flex}
9.4.7 alloc idle
0
0
2/0/7
14
0
81/0
C5510 003 09 {flex}
9.4.7 alloc idle
0
0
2/0/8
18
0
12/1
C5510 003 10 {flex}
9.4.7 alloc idle
0
0
2/0/9
18
0
12/1
C5510 003 11 {flex}
9.4.7 alloc idle
0
0
2/0/10 22
0
12/1
C5510 003 12 {flex}
9.4.7 alloc idle
0
0
2/0/11 22
0
12/1
C5510 003 13 {flex}
9.4.7 alloc idle
0
0
2/0/12 26
0
12/1
C5510 003 14 {flex}
9.4.7 alloc idle
0
0
2/0/13 26
0
12/1
C5510 003 15 {flex}
9.4.7 alloc idle
0
0
2/0/14 30
0
12/1
C5510 003 16 {flex}
9.4.7 alloc idle
0
0
2/0/15 30
0
12/1
————————————END OF FLEX VOICE CARD 0————————————-
Router#
Interesting information that you can see in this example includes the DSP type, whether the resource has been allocated, and the current state of each resource.
test voice port If you are having problems with specific voice ports acting erratically, you can use the test voice port commands to run specific tests to verify proper operation of your configured voice interfaces. The commands entered don’t actually run tests, but instead they configure voice ports or DS0 groups into various testing states. The five possible testing states that can be configured are shown in Table 6.1.
c06.indd 206
9/21/11 11:19:43 AM
Voice Port and Dial-Peer Verification Commands
TA B L E 6 .1
207
Testing states for the test voice port command
State
Description
Possible Values
detector
How the port detects ground on the voice port or DS0 group. This depends on the signaling type used on the port.
[ m-lead, loop, battery-reversal, ring, tip-ground, ring-ground, ring-trip] [on, off, disable]
inject-tone
Places a local or network testing tone on the voice port or DS0 group.
[local, network] [1000hz, 2000hz, 200hz, 3000hz, 300hz, 3200hz, 3400hz 500hz, quiet, disable, sweep]
loopback
Places the port or DS0 group into loopback testing mode so either the local or remote end will receive the test tone coming back to verify end-to-end operation.
local, network, disable
relay
Enables and sets the relay for testing purposes.
[ e-lead, loop, ring-ground, battery-reversal, power-denial, ring, tip-ground] [on, off, disable]
switch
Places the port or DS0 group into fax mode for specifically testing fax transmissions.
fax, disable
As an example, let us assume that you want to generate a sweep of inject tones on FXO port 0/1/0. The inject-tone test is used for a variety of reasons, including determining ideal impedance settings. As you have learned, impedance on a call can introduce annoying hissing, clicking, and volume problems because of timing issues. Analog voice ports can adjust impedance settings to help combat audio problems using the impedance command while in config-voiceport mode. We can set our voice port at different impedance levels and test them using a sweep of tones to determine echo return loss (ERL) levels. ERL measures the ratio between the power level of the transmitted signal and the power level detected in the echo signal. The lower the ERL dB levels are, the better quality your voice will be. So let’s set our FXO 0/1/0 to use an impedance setting of 600r and run our injecttone sweep. Also note that we must disable echo cancellation and issue a shutdown and no shutdown on the port prior to running these tests: Router#configure terminal Router(config)#voice port 0/1/0 Router(config-voiceport)#no echo-cancel enable Router(config-voiceport)#impedance 600r Router(config-voiceport)#shutdown Router(config-voiceport)#no shutdown
c06.indd 207
9/21/11 11:19:43 AM
208
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Router(config-voiceport)#end Router# Router#test voice port 0/1/0 inject-tone local sweep 200 0 0 Freq (hz), ERL (dB), TX Power (dBm), RX Power (dBm) 104 25 -8 -33 304 19 -7 -26 504 17 -8 -25 704 19 -8 -27 904 19 -8 -27 1104 20 -8 -28 1304 20 -8 -28 1504 21 -8 -29 1704 22 -8 -30 1904 22 -8 -30 2104 22 -8 -30 2304 22 -8 -30 2504 22 -8 -30 2704 22 -8 -30 2904 22 -8 -30 3104 22 -8 -30 3304 22 -8 -30 3404 22 -8 -30 Router#
And now let’s change the impedance to 900r and run another test: Router#configure terminal Router(config)#voice port 0/1/0 Router(config-voiceport)#impedance 900r Router(config-voiceport)#shutdown Router(config-voiceport)#no shutdown Router(config-voiceport)#end Router#test voice port 0/1/0 inject-tone local sweep 200 0 0 Freq (hz), ERL (dB), TX Power (dBm), RX Power (dBm) 104 26 -7 -33 304 20 -7 -27 504 17 -8 -25 704 20 -7 -27 904 20 -7 -27 1104 20 -7 -27 1304 20 -8 -28 1504 20 -8 -28
c06.indd 208
9/21/11 11:19:44 AM
Voice Port and Dial-Peer Verification Commands
1704 1904 2104 2304 2504 2704 2904 3104 3304 3404 Router#
20 20 20 20 20 20 20 19 19 19
-8 -8 -8 -8 -8 -8 -8 -8 -8 -8
209
-28 -28 -28 -28 -28 -28 -28 -27 -27 -27
The average ERL when impedance is set to 600r is 21.11, and it is 22.055 when impedance is set at 900r. Therefore, the better choice for this particular FXO connection (lower ERL) is 600r. Keep in mind that this type of testing is commonly done with TAC support assisting you in the process as well as suggesting optimal adjustments that you should make.
csim start You can simulate an outbound telephone call directly from the voice gateway by issuing the csim start extension enable mode command. This command is useful for testing dial-peer matching, testing translation rules, and to verify that a phone can properly make calls. For example, let’s test a phone number using this command: CME#csim start 4488 csim: called number = 4488, loop count = 1 ping count = 0 csim err:csim_do_test Error peer not found
The result of the test call is an error stating that no peer was found. If you know that this call should have been possible, then you need to look at the dial peer and adjust it so it matches the outgoing dialed number.
debug dialpeer To review dial-peer matching in real time, you can use the debug dialpeer command. This command is useful when you’re connected to the console for troubleshooting purposes. It can also be used when verifying the number that you will pass onto the next hop in the case where you used translation rules to modify the original number. Here is an example of the debug dialpeer command in use: Router# debug dialpeer Router#
c06.indd 209
9/21/11 11:19:44 AM
210
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
09:22:18: Inside dpMatchCore: 09:22:18: destination pattn: 5552003333 expanded string: 5552003333 09:22:18:MatchNextPeer:Peer 11 matched
From the output, you can see that this is an outbound dial peer that was matched against dial peer 11. The destination pattern is the pattern that was matched correctly, and the expanded string displays the number we are forwarding. Always keep in mind that when you use a debug command such as this one, you should disable it after you have fi nished looking at it. In our case, we would issue a no debug dialpeer to prevent any unwanted CPU processing on the router.
Summary In this chapter we covered how to configure analog and digital voice ports in a wide range of scenario settings including PLAR, DID, CAMA, CCS, and ISDN. In addition, we went through the process of setting up a DSP farm to offload transcoding, conferencing, and MTP services from the CUCM using SCCP as the communication signaling protocol. Finally, we went through several commands that can be used on a voice gateway to test analog/digital ports, DSP resources, and dial peers. All of these tasks will come in handy when we begin configuring the various signaling protocols in Chapter 7, “Configuring Voice Gateway Signaling Protocols.” By the end of that chapter, you will have all the tools necessary to configure, monitor, and troubleshoot a voice gateway not only to communicate with IP and analog phones internally but also to connect to the PSTN using analog and digital circuits.
Exam Essentials Know how to configure analog FXS, FXO, and E&M ports. FXS ports connect to analog endpoints, FXO ports connect to the PSTN, and E&M ports interconnect two PBX systems. Understand and know how to configure PLAR. PLAR is an autodialing mechanism that is used to associate a port with a single destination. Understand and know how to configure DID. DID is a feature a PSTN uses to strip off digits prior to sending them to a private voice gateway. Know the difference between one-stage and two-stage dialing. With a one-stage dialing setup, the call is not terminated and does not present the caller with a second dial tone. With two-stage dialing, a caller dials digits, which are accepted by a voice gateway, and the call terminates at a second hop along the connection, where a second dial tone is given. The caller must then enter a second series of digits to complete the intended call. Understand CAMA and know how to configure it. CAMA is often used in North America for E911 dialing. A separate CAMA port must be configured strictly for outbound calling for emergency services.
c06.indd 210
9/21/11 11:19:44 AM
Written Lab 6.1
211
Know how to configure digital ports including CAS and ISDN CCS circuits. T1/E1 CAS circuit DS0 timeslots can be configured to use different signaling types. CAS signaling is in-band signaling. T1/E1 PRI and ISDN BRI circuits use out-of-band signaling, and their respective timeslots must be configured to transport Q.921 and Q.931 signaling. Know how to configure a DSP farm between a voice gateway and CUCM. DSP farms can be configured on voice gateways to offload services that are handled by DSP hardware chips. Understand how to view and test voice port configurations on a voice gateway. Commands such as show voice port, show controller, and test voice port can be used for configuration verification and testing purposes.
Written Lab 6.1 1.
What is the config-voiceport command used to configure the extension 555-1234 for caller ID services?
2.
While in config-voiceport mode, you want to configure PLAR on the port that automatically forwards calls to extension 4875 as soon as the phone goes off-hook. What command performs this function?
3.
You are configuring a dial peer for an FXS port that uses DID. What command is used to enable this functionality while in config-dial-peer mode?
4.
You are configuring a dial peer for a CAMA port and have destination-pattern 9911 configured. What command is required to forward only 911 to the PSAP?
5.
You are configuring a T1 CAS and want to configure group 0 so that the fi rst 12 timeslots use E&M immediate-start signaling. While in config-controller mode, what command will you enter?
6.
A T1 PRI that you are configuring will only utilize voice services. You navigate to config-if mode and enter what command?
7.
What command do you use to enable a DSP card for DSP farm functionality while in config-voicecard mode?
8.
You are in the middle of configuring a DSP profi le for MTP services and are in configdspfarm-profile mode. What command is used to set the maximum number of hardware sessions to 5?
9.
What show command can be used to get a quick glance at all voice port interfaces installed on a voice gateway?
10. You wish to simulate a phone call to extension 5555 on your voice gateway. What
command can accomplish this? (The answers to Written Lab 6.1 can be found following the answers to the review questions for this chapter.)
c06.indd 211
9/21/11 11:19:45 AM
Chapter 6
212
■
Configuring Voice Gateway Ports and DSPs
Hands-On Labs To complete the labs in this section, you need a router with a voice-capable IOS, T1 PRI interface, and one FXS port to be used as a CAMA port. Each lab in this section builds on the previous one and will follow the logical voice gateway design shown in Figure 6.9. FIGURE 6.9
Voice gateway lab diagram Outbound NANP calls S0/1/0
Internal voice network
V
PSTN
CAMA 0/0/1
E911 operators
911 and 9911
PSAP
Here is a list of the labs in this chapter: Lab 6.1: Configuring a T1 PRI Lab 6.2: Configuring a CAMA Port for E911 Services Lab 6.3: Configuring Outbound Dial Peer to the PSTN Lab 6.4: Configuring Outbound Dial Peer to the PSAP
Hands-On Lab 6.1: Configuring a T1 PRI In this lab, we’re going to configure a voice gateway that has a single ISDN PRI interface out to the PSTN. The voice gateway has been partially configured. The task here is to configure the T1 logical and physical port sections according to the PSTN requirements found in Table 6.2. TA B L E 6 . 2
c06.indd 212
T1 PRI settings and PSTN requirements for Hands-On Lab 6.1
T1 PRI Settings
PSTN Requirements
ISDN switch type
Primary-NI
Framing
Extended Superframe
Linecoding
B8ZS
Clock source
From the PSTN
1.
Log into your voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Configure the ISDN switch type by typing isdn switch-type primary-ni.
9/21/11 11:19:45 AM
Hands-On Labs
3.
213
Enter into config-controller mode by typing controller t1 0/1/0.
4.
Configure a new PRI group specifying all T1 timeslots by typing pri-group timeslots 1–24.
5.
Configure the T1 PRI to for ESF framing by typing framing esf.
6.
Configure the T1 PRI to for B8ZS linecoding by typing linecode b8zs.
7.
Configure the T1 PRI to use clocking from the PSTN by typing clock source line.
8.
Exit config-controller mode by typing exit.
9.
Enter into the T1 config-if mode by typing interface serial 0/1/0:23.
10. Configure the T1 PRI to direct all T1 voice channels to the DSP by typing isdn incoming-voice voice.
11. Exit config-if mode by typing end.
Hands-On Lab 6.2: Configuring a CAMA Port for E911 Services In this next lab, we will focus on configuring FXO port 0/0/1 for our CAMA connection to the PSAP. Emergency services in our area want us to send a numbering plan digit (NPD) plus the three-digit CO code and four-digit subscriber code. ANI mappings were given to us as shown in Table 6.3. TA B L E 6 . 3
Area codes and numbering plan digits
Area Code
Numbering Plan Digit
312
0
773
1
630
2
850
3
1.
Log into your voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Enter into config-voiceport mode by typing port 0/0/1.
3.
Configure the correct signaling type by typing signal cama KP-NPD-NXX-XXX-ST.
4.
Reset the port by typing shutdown and then no shutdown.
5.
Configure NPD to area code mappings by typing ani mapping 0 312 ani mapping 1 773 ani mapping 2 630 ani mapping 3 850
6.
c06.indd 213
Exit config-voiceport mode by typing end.
9/21/11 11:19:46 AM
214
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Hands-On Lab 6.3: Configuring an Outbound Dial Peer to the PSTN An outbound dial peer needs to be configured for NANP calls that will point out of our T1 PRI. A dial peer needs to be created to trigger on the number 9. It will then collect a 10-digit E.164 string and forward those 10 digits onto the PSTN. 1.
Log into your voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Create a new POTS dial peer (we will use 9) by typing dial-peer voice 9 pots. This will take you to config-dial-peer mode.
3.
Configure a dial-string mapping to match 9 plus a 10-digit number according to NANP guidelines by typing destination-pattern 9[2–8]. . . . . . . . .
4.
Configure the dial peer to forward the last 10 digits to the PSTN by typing forward-digits 10.
5.
Configure the dial peer to send matched calls out our T1 port by typing port 0/1/0:23.
6.
Exit config-dial-peer mode by typing end.
Hands-On Lab 6.4: Configuring an Outbound Dial Peer to the PSAP In our fi nal hands-on lab for this chapter, we will configure outbound dial peers for E911 calling to the PSAP. Because we have internal callers dial 9 for an outbound call, we will configure emergency calls to trigger on both 911 and 9911 so callers who dial the 9 trigger prior to 911 will properly be connected. We also need to send 911 to the PSAP using translation patterns. 1. Log into your voice gateway and go into configuration mode by typing enable and then configure terminal. 2.
Create a new POTS dial peer (we will use 911) by typing dial-peer voice 911 pots. This will take you to config-dial-peer mode.
3.
Configure a dial-string mapping to match 911 by typing destination-pattern 911.
4.
Configure the dial peer to forward all three digits to the PSAP by typing forward-digits all.
5.
Configure the dial peer to send matched calls out our CAMA port by typing port 0/0/1.
6.
Create a new POTS dial peer (we will use 9911) by typing dial-peer voice 9911 pots. This will take you to config-dial-peer mode.
7.
Configure a dial-string mapping to match 9911 by typing destination-pattern 9911.
8.
Configure the dial peer to strip off the fi rst 9 so it only sends the last three digits to the PSAP by typing forward-digits 3.
9.
Configure the dial peer to send matched calls out our CAMA port by typing port 0/0/1.
10. Exit config-dial-peer mode by typing end.
c06.indd 214
9/21/11 11:19:46 AM
Review Questions
215
Review Questions 1.
How can DNIS be used on FXO ports? A. Inbound only.
2.
B.
DNIS cannot be used in either direction on FXO ports.
C.
Outbound only.
D.
Both inbound and outbound.
What is the name for an autodialing feature that is used to associate a port with a single destination? A. PSAP
3.
B.
PLAR
C.
CAMA
D.
OPX
You are configuring a PLAR on an FXO port that is connected to the PSTN. When a user calls from the PSTN, you want to automatically forward that call to extension 455. Which of the following commands will accomplish this task? A. plar opx 455
4.
B.
connection opx plar 455
C.
opx plar 455
D.
connection plar opx 455
You have configured an FXS/DID port and associated dial peer as shown in the following output. What additional dial-peer command is required if you want to accept only four digits from the PSTN? Router(config)#voice-port 0/0/0 Router(config-voiceport)#signal did wink-start Router(config-voiceport)#no shutdown Router(config)#dial-peer voice 1000 pots Router(config-dial-peer)#incoming called-number . . . . Router(config-dial-peer)#port 0/0/0
A. prefix 4
c06.indd 215
B.
forward digits 4
C.
direct-inward-dial
D.
did
9/21/11 11:19:47 AM
Chapter 6
216
5.
■
Configuring Voice Gateway Ports and DSPs
What is the name of the dialing process where a caller hears a dial tone, enters phone digits, receives another dial tone, and must enter a second set of digits to reach the intended destination? A. Direct inward dial (DID)
6.
B.
One-stage dialing
C.
Private Line Automatic Ringdown (PLAR)
D.
Two-stage dialing
You are configuring an FXO port as CAMA interface to be used for E911 services. What alert will the voice gateway send to the command line after configuring the CAMA signal type? A. A notice to verify that the signaling type configured is what the PSAP is expecting
7.
B.
A notice to verify that dial peers for 911 and 9911 should be configured on the voice gateway
C.
A notice that the interface must be administratively disabled and reenabled
D.
A notice that only 911 should be sent to the PSAP
How are E911 calls routed to the PSAP? A. By DNIS B.
8.
By destination address
C.
By ANI
D.
By area code
In situations where CAMA is required, where should internal calls to 911 be routed? A. A CUCM
9.
B.
The PSAP
C.
The PSTN
D.
The SRST
Your office requires 12 analog FXO ports to the PSTN with ground-start signaling and 12 E&M ports to the PSTN with immediate-start signaling. Which of the following is best suited to meet your needs? A. T1 PRI B.
E1 PRI
C.
T1 CAS
D.
ISDN BRI
10. What channel/timeslot is used for signaling on a T1 PRI? A. Channel 23 and timeslot 24.
c06.indd 216
B.
Timeslot 23 and channel 24.
C.
Timeslot 24 and channel 24.
D.
Channel 23 and timeslot 23.
E.
PRI uses in-band signaling.
9/21/11 11:19:47 AM
Review Questions
217
11. You are reviewing a T1 PRI configuration and are looking at interface serial 0/0:23. You see the following command: isdn incoming-voice voice
What is the purpose of this command? A. To ensure that Q.931 signaling is sent on T1 0/0 channel 23 B.
To ensure that Q.921 signaling is sent on T1 0/0 channel 23
C.
To ensure that all channels are processed by DSPs
D.
To ensure that Q.921 and Q.931 signaling is sent on T1 0/0 channel 23
12. You are asked to create a dial peer to send all NANP calls outbound on T1 PRI 1/0. The following commands are already configured: Router(config-dial-peer)#dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9[2–8]. . . . . . . . .
Which of the following commands will properly complete the configuration? A. port 1/0 B.
port 1/0:24
C.
port 1/0:1
D.
port 1/0:23
13. Which of the following can be used to offload MTP? A. SCCP B.
DSP
C.
SRST
D.
H.323
14. Which of the following commands is used to enable a DSP card for DSP farming services? A. Router(config-voicecard)#dsp services dspfarm B.
Router(config-dial-peer)#service dspfarm
C.
Router(config-dial-peer)#dsp services dspfarm
D.
Router(config-voicecard)#service dspfarm
15. You have created a DSP profile and given it a unique identifier number. At what point in the DSP farm-configuration process will the DSP profile identifier number be required? A. While in config-dsp-farm-profile mode
c06.indd 217
B.
When identifying the sccp ccm
C.
When in config-sccp-ccm mode
D.
When configuring the CUCM
9/21/11 11:19:48 AM
Chapter 6
218
■
Configuring Voice Gateway Ports and DSPs
16. Reviewing a DSP farm profile, you see the following entry: maximum sessions hardware 4
What type of profile is this? A. Translation B.
MTP
C.
Conferencing
D.
Transcoding
17. Given the following SCCP CCM group configuration, what must be configured identically on the CUCM itself? sccp ccm group 1 bind interface FastEthernet4/0 associate ccm 1 priority 1 associate profile 15 register TXDSPFARM1
A. TXDSPFARM1 B.
Profile 15
C.
Group 1
D.
Priority 1
18. You issue the following voice gateway show command: Router#show voice port 0/0/0 Foreign Exchange Station 0/0/0 Slot is 0, Sub-unit is 0, Port is 0 Type of VoicePort is FXS Operation State is DORMANT Administrative State is UP The Interface Down Failure Cause is 0 Alias is NULL Noise Regeneration is enabled Non Linear Processing is enabled Music On Hold Threshold is Set to 0 dBm In Gain is Set to 0 dB Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16ms Connection Mode is Normal Connection Number is Initial Time Out is set to 10 s
c06.indd 218
9/21/11 11:19:48 AM
Review Questions
219
Interdigit Time Out is set to 10 s Analog Info Follows: Region Tone is set for northamerica Currently processing none Maintenance Mode Set to None (not in mtc mode) Number of signaling protocol errors are 0 Voice card specific Info Follows: Signal Type is loopStart Ring Frequency is 25 Hz Hook Status is On Hook Ring Active Status is inactive Ring Ground Status is inactive Tip Ground Status is inactive Digit Duration Timing is set to 100 ms InterDigit Duration Timing is set to 100 ms Hook Flash Duration Timing is set to 600 ms
Given this information, which of the following statements is true? A. The phone is currently not in use. B.
The phone is configured for use in France.
C.
This is an E&M port.
D.
Signaling is configured for ground start.
19. You issue a show voice dsp command on your voice gateway. Which of the following might you see under the CODEC section of the output? A. g711ulaw B.
g729r8
C.
flex
D.
encoded
20. What does the csim start 5551234 command do when run on a voice gateway? A. It simulates a conference call originating from any source endpoint to a destination of 555-1234 to test DSP resources.
c06.indd 219
B.
It simulates a conference call originating from the voice gateway to a destination of 555-1234 to test DSP resources.
C.
It simulates a call originating from any source endpoint to a destination of 555-1234.
D.
It simulates a call originating from the voice gateway to a destination of 555-1234.
9/21/11 11:19:49 AM
220
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Answers to Review Questions 1.
C. FXO ports can only send DNIS information outbound toward the PSTN.
2.
B. PLAR is a feature that can be configured on a voice port to automatically dial a specific destination as soon as the phone goes off-hook.
3.
D. The proper syntax for this command is connection plar opx extension.
4.
C. The direct-inward-dial command is required to accept DIDs from the PSTN.
5.
D. Two-stage dialing requires that the voice network receive two different sets of numbers to reach the fi nal destination. The fi rst digits that are entered are processed and forwarded to a second gateway that presents the caller a second dial tone at which to enter a second set of digits.
6.
C. When configuring an FXO port to be used as a CAMA interface for E911 calling, the port must go through a shutdown and no shutdown; otherwise, outbound calling will not function.
7.
C. The calling party’s number (ANI) is used to route calls to the PSTN. By using this method, emergency services can use the ANI number and match it with their internal database to fi nd the location of the calling party. That location is then used to route the call to the nearest PSAP.
8.
B. When a business is required to use CAMA interfaces for E911, dial peers should route 911 calls to the PSAP.
9.
C. A T1 CAS can be logically broken into DS0 groups. These groups can be configured to utilize different analog FXS, FXO, and E&M signaling types.
10. A. When referring to T1 signaling channels and timeslots, you configure Q.921 and Q.931 signaling on channel 23 and timeslot 24. 11. C. The isdn incoming-voice voice command tells the router that all channels on T1 0/0 are to be used for voice and not data. All channels will then be directed to DSP resources for transcoding. 12. D. When configuring an outbound dial peer for a T1 PRI, you must specify the logical T1 channel that is used. In the case of a T1, that channel is always 23. Therefore, when configuring port information, you specify the T1 slot/port followed by a colon (:) and then the channel number used for ISDN signaling. 13. B. A DSP chip can be configured to be used as a DSP farm to offload CUCM tasks such as transcoding, conferencing, and MTP. 14. A. To enable a DSP card for DSP farming services, you must be connected to that particular voice card (in config-voicecard mode) and enter the dsp services dspfarm command.
c06.indd 220
9/21/11 11:19:49 AM
Answers to Review Questions
221
15. C. The DSP profi le number is used while in config-sccp-ccm mode to identify the profi le needed by using the associate profile 15 command. 16. B. The DSP profi le that includes either the hardware or software keyword is used only when configuring MTP DSP farm profi les. 17. A. The register TXDSPFARM1 command specifies the CUCM media resource’s device name, which must be identical on the CUCM and voice gateway configurations. 18. A. From the show command output, you can see that the phone hook status is on-hook. 19. C. When viewing DSP resources, the CODEC specifies how the DSP resource is configured. Possible options include medium, high, flex, and secure. 20. D. The csim start 5551234 command can simulate a voice call that originates from the voice gateway to any dial string destination specified.
c06.indd 221
9/21/11 11:19:50 AM
222
Chapter 6
■
Configuring Voice Gateway Ports and DSPs
Answers to Written Lab 6.1 1.
station-id number 555–1234
2.
connection plar 4875
3.
direct-inward-dial
4.
forward-digits 3 (prefix 911 is acceptable as well)
5.
ds0-group 0 timeslots 1–12 type e&m-immediate-start
6.
isdn incoming-voice voice
7.
dsp services dspfarm
8.
maximum sessions hardware 5
9.
show voice port summary
10. csim start 5555
c06.indd 222
9/21/11 11:19:50 AM
Chapter
7
Configuring Voice Gateway Signaling Protocols THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the components of a gateway. ■
Describe the function of gateways.
Describe the basic operation and components involved in a VoIP call. ■
Describe H.323.
■
Describe SIP.
■
Describe MGCP.
■
Identify the appropriate gateway signaling protocol for a given scenario.
c07.indd 223
21/09/11 11:23 AM
One of the most extensively covered topics on the CVOICE exam deals with voice gateway signaling protocols—when to use them and how to configure them. In Chapter 3, “VoIP Operation and Protocols,” you got a brief overview of the four signaling protocols used on Cisco networks: H.323, SIP, MGCP, and Cisco’s proprietary SCCP. The latter is commonly used on Cisco networks within a LAN environment, while the other protocols are used for signaling between networks. In this chapter, we will dive in deeper to cover the ins and outs of H.323, SIP, and MGCP, which are all commonly used and configured on Cisco IOS gateways that attach to the PSTN. We’ll fi rst explore some more details about each signaling protocol, including how to configure them and make common adjustments and how to use IOS show commands to verify proper configuration and for troubleshooting.
Configuring H.323 By default, Cisco voice gateway dial peers are configured to operate using the H.323 signaling protocol. As you learned in Chapter 3, H.323 is a peer-to-peer protocol, which means that the voice gateway must be configured with dial-peer information so the voice gateway knows where to route various VoIP calls that come into it. When connecting to the PSTN via an ISDN connection such as a T1 PRI, the H.323 signaling protocol is used between the voice gateway and the CUCM, while ISDN Q.921 and Q.931 signaling is used between the voice gateway and the PSTN, as shown in Figure 7.1. F I G U R E 7.1
H.323 and ISDN signaling
M
Internal IP network
CUCM H.323
PSTN
V Voice gateway
Q.921 Q.931
c07.indd 224
21/09/11 11:23 AM
Configuring H.323
225
From an operational standpoint, H.323 has two modes for call initiation, called slow start and fast start. H.323 slow start initiation mode processes a call through the following signaling stages:
Call setup
Call proceeding
Alerting
Connect
H.245 negotiation This process is illustrated in Figure 7.2.
F I G U R E 7. 2
The H.323 slow start process H.323 signaling
V
Calling party
IP network 1. Call setup
V
Called party
2. Call proceeding 3. Alerting 4. Connect 5. H.245 negotiations
As soon as the connect signaling step is complete, H.323 proceeds to perform H.245 (voice control channel) negotiation, and the call is then in progress. The H.245 channel is then responsible for the following:
Exchanging capabilities information such as encryption, flow control, and jitter management
Opening and closing media stream channels, which transport voice and video
Determining the master or responder endpoints
Handling modification requests to change the mode or capability of open media streams
So as you can see, the faster we get to H.245, the faster our media channels can be opened between two endpoints.
c07.indd 225
21/09/11 11:23 AM
Chapter 7
226
■
Configuring Voice Gateway Signaling Protocols
With H.323 fast start, on the other hand, the H.245 negotiation process kicks off during the call-setup stage and does not wait for the other three signaling stages before allocating resources for the voice transport channel. This process is illustrated in Figure 7.3. F I G U R E 7. 3
The H.323 fast start process H.323 signaling
V
Calling party
IP network
V
Called party
1. Call setup and H.245 negotiations 2. Call proceeding 3. Alerting 4. Connect
As you can imagine, the H.323 fast start method is more efficient than slow start. It should be noted that fast start is available only in equipment that supports H.323 version 2 or higher, so some legacy equipment may not be compatible. H.323 fast start is the default mode on newer Cisco voice gateways. One H.323 feature that can utilize fast start is called H.323 Early Media. This feature can be used when two voice gateways connect to each other using H.323 fast start. When the Early Media feature is also used between gateways, it allows the gateways to open up media transport channels prior to H.225 negotiation and thus prior to the call being accepted between the two parties. These early channels can be used for streaming of media such as broadcast announcements or music on hold (MOH). Figure 7.4 shows the Early Media feature in action. F I G U R E 7. 4
The H.323 fast start process with Early Media H.323 signaling
V
Calling party
IP network 1. Call setup and H.245 negotiations
V
Called party
2. Call proceeding 3. RTP stream for early media 4. Alerting 5. Connect
c07.indd 226
21/09/11 11:23 AM
Configuring H.323
227
Configuring an H.323 Gateway As stated previously, H.323 is the default signaling protocol for Cisco voice gateways. Dial peers are required so that when a call comes in, the voice gateway can match the call based on inbound dial peers and send it to the appropriate destination using outbound dial peers. To create a simple H.323 dial-peer connection to a remote H.323 gateway, it is just a matter of performing the following tasks: 1.
Enter the dial-peer voice command with a unique identifier number followed by the voip option to specify that this is a Voice over IP dial peer as opposed to a POTS dial peer.
2.
Configure a destination pattern to identify how to reach remote phones on the other side of an IP connection.
3.
Configure a destination IP address to point to the next-hop voice gateway along the path to the destination phones using the session target ipv4: command followed by the IP address of the remote voice gateway interface that your voice gateway is aware of.
Why Is My VoIP Gateway Not Processing VoIP? Did you configure your VoIP gateway but find that it doesn’t seem to be operating? It is possible that voice services have been disabled on your router. To verify this, you can issue a show gateway command to see if the gateway signaling protocol you are running is enabled or shut down. You can enable the VoIP service on IOS routers with voice software by issuing the voice service voip global configuration command. This brings you to conf-voi-serv mode. You can then issue shutdown to disable the service or no shutdown to bring it back up. One additional option is to use shutdown forced, which brings the VoIP service down regardless of any calls that may be using VoIP service on the router. Without the forced keyword, the router will stop accepting additional VoIP connections but also wait for any currently active calls to complete. VoIP is enabled by default, so typically it is not necessary to enter this command when configuring VoIP unless someone has explicitly shut down the service.
To show you how dial peers are created between two H.323 gateways, we will use Figure 7.5 as our example network.
c07.indd 227
21/09/11 11:23 AM
228
Chapter 7
F I G U R E 7. 5
■
Configuring Voice Gateway Signaling Protocols
An example H.323 network
Extensions 3000-3999
Extensions 4000-4999
192.168.1.1/24 V New York H.323 gateway
192.168.2.1/24 IP WAN
V Boston H.323 gateway
We want to route all calls between the two sites across the IP WAN using H.323 signaling. We will start by configuring the New York router using 4000 as our locally significant dial-peer identifier, as follows: NewYork(config)#dial-peer voice 4000 voip NewYork(config-dial-peer)#destination-pattern 4... NewYork(config-dial-peer)#session target ipv4:192.168.2.1 NewYork(config-dial-peer)#
Next, let’s configure the Boston router so we can properly reach phones in both directions using dial peer 3000: Boston(config)#dial-peer voice 3000 voip Boston(config-dial-peer)#destination-pattern 3... Boston(config-dial-peer)#session target ipv4:192.168.1.1 Boston(config-dial-peer)#
This example configuration setup shows you how to configure H.323 signaling using the default settings. But sometimes you will want to modify some of the defaults, depending on certain network differences that you may come across. These include settings such as:
Fast or slow start connections
Codec preference
Session transport mode
Adjusting H.225 settings
Adjusting H.225 timers
Binding a virtual H.323 gateway address The next few sections show how to modify these H.323 gateway signaling settings.
Configuring H.323 Fast or Slow Start Connections If you need to connect to a legacy H.323 that supports only slow start setups, you need to use the call start config-serv-h323 command to specify that the voice gateway uses
c07.indd 228
21/09/11 11:23 AM
Configuring H.323
229
slow start signaling, so it is compatible with equipment at the other end. To get to this mode, you must fi rst use the voice service voip command. There are actually several voice service options for POTS, VoIP, and others, as shown here: Router(config)# voice service ? pots Telephony voatm Voice over ATM vofr Voice over Frame Relay voip Voice over IP Router(config)# voice service
Once you choose voice service voip, the IOS will place you into conf-voice-serv mode. You then must specify h323 as the signaling protocol you wish to modify. The following example shows the steps required to force an H.323 gateway to use slow start globally: Router#configure terminal Router(config)# voice service voip Router(conf-voi-serv)# h323 Router(conf-serv-h323)#call start slow Router(conf-serv-h323)#end Router#
Alternatively, you can configure H.323 slow start on a specific dial peer instead of globally on the voice gateway. To accomplish this, you must fi rst create an H.323 voice class that specifies slow start signaling. The voice class can then be applied to any dial peer that you choose. The following example shows how to configure an H.323 voice class (labeled 1) for slow start connections. The voice class is then applied to dial peer 10: Router#configure terminal Router(config)#voice class h323 1 Router(config-class)#call start slow Router(config-class)#exit Router(config)#dial-peer voice 10 voip Router(config-dial-peer)#voice-class h323 1 Router(config-dial-peer)#end Router#
Configuring Codec Preference You can use signaling protocols to specify the preferred codec and other codec-specific parameters to be used in the H.323 configuration as well. To do so, you create codec voice classes and specify your preferences. To set preferences for codecs, you can use the codec
c07.indd 229
21/09/11 11:23 AM
230
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
preference command followed by a preference number and the codec in question. A lower preference number is preferred. Optionally, you can also set the following codec settings: bytes The voice packet payload size specified in bytes fixed-bytes
Whether the bytes specified are nonnegotiable between the voice gateways
transparent
To specify that the codec capabilities be passed transparently to the remote
voice gateway As an example, we will configure preferences (voice class 30) for the following three codecs and specific settings:
Highest preference: g711ulaw with a 160-byte payload
Middle preference: g726r32 with an 80-byte fi xed payload
Lowest preference: g729br8 Here is how to configure the codec preferences on a voice gateway:
Router#configure terminal Router(config)#voice class Router(config-class)#codec Router(config-class)#codec Router(config-class)#codec Router(config-class)#end Router#
codec 30 preference 1 g711ulaw bytes 160 preference 2 g726r32 bytes 80 fixed-bytes preference 3 g729br8
Once the codec preferences are specified, they can be applied to VoIP dial peers as shown in this example, where we apply voice class 30 to dial peer 15: Router#configure terminal Router(config)#dial-peer voice 15 voip Router(config-dial-peer)#voice-class codec 30 Router(config-dial-peer)#end Router#
The voice class codec commands are not H.323 specific but can be used to set codec preferences and settings for any voice gateway signaling protocol, including H.323, MGCP, and SIP.
Keep in mind that the codec preferences should be configured on both sides to ensure proper codec selection. The codec selection will be used only when the local gateway is used to initiate signaling. If a call is initiated on a different H.323 gateway inbound to the local router, the preferences will be dictated by the remote router. In addition, if no codec preferences
c07.indd 230
21/09/11 11:23 AM
Configuring H.323
231
are specified for the remote inbound dial peers, the default codec of G.729r8 with 20-byte voice payloads will be used. If no inbound dial peer is specified on the remote voice gateway, dial peer 0 is triggered, which supports all voice codecs.
Configuring the H.323 Session Transport Mode A third H.323 setting that can be modified is the H.323 session transport mode. By default, H.323 is transported over TCP. You can change the transport layer protocol for H.323 dial-peer messages to UDP by issuing the session transport udp command. This command is run while in config-serv-h323 mode. You might choose to go with UDP for transport instead of TCP, because UDP has less overhead. If you are seeking to reduce H.323 signaling bandwidth utilization, you can configure your voice gateway for UDP, as shown in the following example: Router#configure terminal Router(config)# voice service voip Router(conf-voi-serv)#h323 Router(conf-serv-h323)#session transport udp Router(conf-serv-h323)#end Router#
It is not recommended that you adjust the transport method from the default TCP unless necessary. Changing from TCP to UDP not only prevents concurrent H.323 sessions on a voice gateway but also limits the number of adjustments that can be made using the H.225 TCP commands, described next.
Modifying H.225 Settings There are a couple of H.225 settings that sometimes need to be adjusted for an H.323 gateway depending on the network you are residing on. The fi rst H.225 command we will look at can adjust the maximum number of concurrent calls on an H.225 TCP connection. The command is session transport tcp calls-per-connection followed by a numerical value for maximum concurrent calls. The default maximum is 15, and you can set the number between 1 and 9999. We will adjust this value to support 20 concurrent calls in the following example: Router#configure terminal Router(config)# voice service voip Router(conf-voi-serv)#h323 Router(conf-serv-h323)#session transport tcp calls-per-connecton 20 Router(conf-serv-h323)#end Router#
c07.indd 231
21/09/11 11:23 AM
232
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Another useful H.225 command will let you adjust the number of seconds that an H.225 idle connection will remain intact before tearing it down. This timer is modified using the h225 timeout tcp call-idle command, followed by either value and then the number of seconds you wish the timer to use (the range is 0 to 1440 seconds) or the keyword never to keep the connection established indefinitely. The default timer is set to 10 seconds. The following example shows how to adjust the H225 TCP call-idle timer to 5 seconds: Router#configure terminal Router(config)# voice service voip Router(conf-voi-serv)#h323 Router(conf-serv-h323)#h225 timeout tcp call-idle value 5 Router(conf-serv-h323)#end Router#
Adjusting H.225 Timers There are two H.225 timers that can be adjusted in configuring an H.323 gateway to help the H.225 connection process according to the physical transport medium and utilization. Over-utilized links may not function well with the default timer settings. In some situations, an increase in these timers may be beneficial. H.225 timers are adjusted by fi rst using the voice class h323 command followed by a unique number tag. The IOS will then place you in config-class mode, where you can adjust various H.323 settings, including H.225 timers. Here is an example of how to enter into the correct voice class mode for H.323 using 100 as our unique identifier: Router#configure terminal Router(config)#voice class h323 100 Router(config-class)#
The two H.225 timeout settings you must be familiar with are these: This command specifies the amount of time VoIP dial peers will wait to hear an H.225 receive response from the remote gateway. The default is 15 seconds, but this timer is often shortened when there are backup gateways that take over the transport of H.323 in the event of a connection failure on the primary connection. By shortening the timer from 15 seconds to something more practical like 3 seconds, you make it less likely that your end users will notice that a network failure has occurred. Here is an example of how to adjust the H.225 timeout to 3 seconds:
h225 timeout tcp establish
Router#configure terminal Router(config)#voice class h323 100 Router(config-class)#h225 timeout tcp establish 3 Router(config-class)#end Router#
c07.indd 232
21/09/11 11:23 AM
Configuring H.323
233
This command adjusts the number of seconds that a voice gateway will wait in response to an H.225 call setup message. The default value is 15 seconds. Again, this is sometimes reduced to speed up the backup process in the event of a network failure. The following example adjusts the timeout to 3 seconds:
h225 timeout setup
Router#configure terminal Router(config)#voice class h323 100 Router(config-class)#h225 timeout setup 3 Router(config-class)#end Router#
Any H.225 timer adjustments configured must then be applied to corresponding H.323 dial peers using the voice class h323 command followed by the unique identifier we used. For example, we will apply our H.323 voice class 100 settings to VoIP dial peer 999, as shown here: Router#configure terminal Router(config)#dial-peer voie 999 voip Router(config-dial-peer)#voice-class h323 100 Router(config-dial-peer)#end Router#
Binding a Virtual H.323 Gateway Address for Redundancy The final H.323 configuration we will look at is interface binding; we will configure it to bind the H.323 gateway source address to a virtual interface for redundancy purposes. The H.323 gateway IP address is the address used by remote routers for forwarding H.323 calls to us. If we were to use physical interfaces for this purpose, it would create a single point of failure. To prevent this, we can use multiple physical interfaces to connect to remote networks and bind them to a virtual interface we’ve created on our voice gateway. Figure 7.6 shows an example of how we can use a loopback interface configured with the IP of 10.10.10.100 to use as our H.323 voice gateway IP address: F I G U R E 7. 6
An H.323 loopback interface Interface loopback 0: 10.10.10.100/24
Switch
c07.indd 233
V Local H.323 gateway
Multiple physical interfaces
IP WAN
V Remote H.323 gateway
21/09/11 11:23 AM
234
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
By configuring a loopback interface and specifying it as our H.323 gateway IP for this router, we ensure that the address will be used as the sole-source IP address for any outbound H.323 connections. Here is how to configure loopback 0 with our IP and as our virtually bound H.323 gateway source interface: Router#configure terminal Router(config)#interface loopback0 Router(config-if)#ip address 10.10.10.100 255.255.255.0 Router(config-if)#h323-gateway voip bind srcaddr 10.10.10.100 Router(config-if)#end Router#
H.323 show Commands Now that you know how to configure H.323 signaling between two gateways, you need to familiarize yourself with two IOS show commands used to verify proper configuration and operational status.
show gateway The show gateway command displays operational information regarding signaling protocols such as H.323. Here is an example of the output of this command if configured to connect to another H.323 gateway as in previous examples: Router#show gateway H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1 H.323 service is up This gateway is not registered to any gatekeeper Alias list (CLI configured) is empty Alias list (last RCF) is empty Router#
From the output you can see that the H.323 service is up but not registered to a gatekeeper. This is because our particular setup does not require a gatekeeper. Configuration of H.323 gatekeepers is discussed in Chapter 10, “Configuring and Managing CUBE and H.323 Gateways,” of this study guide.
show h323 gateway h225 The show h323 gateway h225 command gives us H.225 signaling protocol setup information. Here is an example of the output you might see on a voice gateway:
c07.indd 234
21/09/11 11:23 AM
Configuring H.323
235
Router#show h323 gateway h225 H.225 STATISTICS AT 00:46:12 H.225 REQUESTS Setup Setup confirm Alert Progress Call proceeding Notify Info User Info Facility Release Reject Passthrough
SENT 12 48 30 29 53 0 0 0 32 44 0 0
RECEIVED 53 0 0 0 0 0 0 0 0 43 0 0
FAILED 0 0 0 0 0 0 0 0 0 1 0 0
H225 establish timeout 0 RAS failed 0 H245 failed 0 Router#
You can see that the command output displays counter information regarding H.225 messages that have been sent and received between H.323 gateways. It also shows counters for any failures. These counters can be of great use while troubleshooting H.323 signaling problems. You can clear the counters on the voice gateway by issuing the clear h323 gateway h225 command, as shown here: Router#clear h323 gateway h225 H.225 stats cleared at 00:48:29 Router#show h323 gateway h225 H.225 STATISTICS AT 00:48:34 H.225 REQUESTS Setup Setup confirm Alert Progress
c07.indd 235
SENT 0 0 0 0
RECEIVED 0 0 0 0
FAILED 0 0 0 0
21/09/11 11:23 AM
Chapter 7
236
■
Configuring Voice Gateway Signaling Protocols
Call proceeding Notify Info User Info Facility Release Reject Passthrough
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
H225 establish timeout 0 RAS failed 0 H245 failed 0 Router#
Configuring SIP Session Initiation Protocol (SIP) is a widely popular protocol thanks in part to its openstandard nature, ease of configuration, and wide support from almost all voice hardware manufacturers. In this section, we will explore the inner workings of SIP signaling and how to configure a Cisco IOS router to signal the setup of voice calls over an IP network. As you learned in Chapter 3, SIP is a peer-to-peer protocol. When connecting to the PSTN via ISDN such as a T1 PRI, SIP signaling is used between the voice gateway and the CUCM, while ISDN Q.921 and Q.931 signaling is used between the voice gateway and the PSTN, as shown in Figure 7.7.
F I G U R E 7. 7
SIP and ISDN signaling
M
Internal IP network
CUCM
PSTN
V Voice gateway
SIP
Q.921 Q.931
Specifically, the SIP voice gateway signaling protocol is responsible for the following tasks:
c07.indd 236
Determine the location of target endpoints.
Determine the capabilities of target endpoints.
21/09/11 11:23 AM
Configuring SIP
Determine whether the destination endpoint is available for a call.
Establish a session between the originating and target endpoints and handles the transfer and/or termination of the call.
237
We’ll look at each of these in order.
Determine the Endpoint Locations SIP must learn where the destination devices are located, including IP address, extension, and name. This is done in either of two ways, depending on how the voice network is set up. The methods for acquiring and resolving destination addresses are these:
A locally stored IP address–to–domain-name table.
A proxy server that seeks out SIP table information stored in SIP registrar, redirect, and location servers. In a Cisco environment, these tasks are all typically handled by a CUCM.
Determine the Endpoint Capabilities SIP performs signaling for a wide range of audio and video devices, and the protocol must determine what capabilities are compatible between endpoints that wish to communicate. This capability verification is accomplished using the Session Description Protocol (SDP). SDP is an RFC 2327 protocol that uses standard ASCII codes for describing and negotiating multimedia sessions. The protocol collects information from SIP endpoints in ASCII format and sends that information to the target in the form of a SIP invite message. The target device then receives the multimedia characteristics, determines which are compatible with itself, and then sends that information back to the originating SIP endpoint in a SIP response message. This method of exchanging SDP messages is known as SIP early offer and is shown in its basic form in Figure 7.8. F I G U R E 7. 8
A SIP early-offer SDP exchange SIP signaling
V
IP network
Calling party
V
Called party Here are the 1. SIP invite (SDP offer message) multimedia characteristics I can work with. 2. SIP OK (SDP media answer)
c07.indd 237
Here are the multimedia characteristics that match what you can work with.
21/09/11 11:23 AM
238
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
There is a second SDP method for exchanging multimedia capabilities called SIP delayed offer. Using this method, the initial SIP invite message from the initiating device does not contain SDP information. Instead, the initiating device sends an invite without the SDP capabilities. The delayed-offer process then dictates that the target device is the one responsible for sending an SDP message to the initiating device in a SIP OK message. Figure 7.9 shows the basics of the delayed-offer SDP method.
F I G U R E 7. 9
A SIP delayed-offer SDP exchange SIP signaling
V
IP network
Calling party
V
Called party 1. SIP invite
2. SIP OK (SDP media offer)
Here are the multimedia characteristics that match what you can work with.
Here are the multimedia characteristics I can work with.
3. SIP ACK (SDP media answer)
The delayed-offer method is recommended on ITSP trunks because it forces the service provider to choose the optimal audio/video codecs for their service. The default method on Cisco voice gateways is to use early offer. Regardless of the SIP offer method used, the SDP messages contain the same information, including audio/video capabilities and endpoint ownership. An example SDP description looks like the following: v=0 o=ssmith 5557843 IN IP4 192.168.10.102 s=test1 c=IN IP4 192.168.10.102 t=0 0 m=audio 3456 RTP/AVP 18 0
c07.indd 238
21/09/11 11:23 AM
Configuring SIP
239
From the example SDP message provided, you can see the following, according to Table 7.1. TA B L E 7.1
SDM example message contents
SDP Symbol
Description
Value
v=
Protocol version
0
o=
Owner
ssmith
s=
Session name
test1
c=
Connection information
Network=IN, IP=192.168.10.102
t=
Time
start= 0, stop= 0
m=
Media codes
audio, 18= G.729a/8000, 0= G.711 PCM (others include 8= PCMA, 96 = G.726–24/8000, 97= G.726–40/8000, 98= G.726–16/8000)
Determine Endpoint Availability If the intended destination phone is busy or offline or nobody picked up the ringing phone (ring-no-answer), SIP is responsible for letting the calling party know that the call cannot be completed. SIP uses various informational messages to notify the calling party.
Establish a Session If the phone is capable of accepting calls and the user picks up the ringing phone, SIP is responsible for making the initial connection between endpoints. After the connection is established, the phones use RTP streams independent of SIP for the actual voice communication. SIP is still monitoring the call, however, for any disconnects or call transfers during the call. For transfers, SIP will be responsible for establishing a secondary connection session to the new target phone. Once the transfer connection is established, SIP tears down the old connection automatically. Now that you understand what SIP needs to do when signaling, the next section will cover how to configure SIP and modify some default settings between two voice gateways on an IP network as well as when interoperating with an ISDN PSTN circuit.
Configure SIP between IP Voice Gateways Our fi rst SIP configuration example will be to connect to a remote SIP gateway in an ITSP situation. We will use Figure 7.10 as our network setup for this example.
c07.indd 239
21/09/11 11:23 AM
240
Chapter 7
F I G U R E 7.1 0
■
Configuring Voice Gateway Signaling Protocols
A SIP network configured between IP gateways SIP signaling 10.1.1.100
Extensions 4000–4999
IP
V Voice gateway
Internet
V ITSP voice gateway
PSTN
M 192.168.99.99 SCCP signaling
In order to properly connect our SIP gateway, we will need to configure our gateway as a SIP user agent (UA). Once the basic SIP foundation is set up to point to the ITSP, we will create VoIP dial peers that will direct calls out to our SIP neighbor. Let’s fi rst tackle our SIP UA configuration. For this we need to have some basic information about our internal network, namely, the IP address of the registrar/SIP server and a username/password combination so that we can perform secure MD5 authentication on the network. The username and password are entered while in config-sip-ua configuration mode by issuing the authentication username name password 0 password command. The 0 in the command indicates that the password is entered in clear text. If the password is already encrypted, you should change the 0 to 7 to let the router know not to encrypt the password a second time. In our example we will enter ssmith as our username and an unencrypted password, mypassword. Because our internal IP network is running SCCP, we will need to set our SIP UA to point to a SIP server and registrar server, which is the IP address of our CUCM, as indicated in Figure 7.10. Let’s fi rst configure our UA settings as shown here: Router#configure terminal Router(config)#sip-ua Router(config-sip-ua)#authentication username ssmith password 0 mypassword Router(config-sip-ua)#registrar 192.168.99.99 Router(config-sip-ua)#sip-server 192.168.99.99 Router(config-sip-ua)#end Router#
c07.indd 240
21/09/11 11:23 AM
Configuring SIP
241
Once we complete those changes, basic SIP is configured on our network. Next, we will need to configure inbound and outbound VoIP dial peers, which must specify that we use SIP signaling. Remember, if we don’t specify SIP signaling, then the dial peer defaults to H.323. To set the dial peer to SIP, we use the session protocol sipv2 command. We will first configure VoIP dial peer 4000, which will match any 4XXX destination number. We will then point the call to our SIP proxy server using the session target sip-server command. Note that we could also configure session target ipv4:192.168.99.99, but since we’ve already identified that IP address as our SIP proxy server with the sip-server 192.168.99.99 command while in config-sip-ua mode, we simply need to tell the dial peer to send the call to our SIP proxy to let it complete the call. If we did not have a SIP server specified, then we would be required to enter the IP address of the CUCM. Router#configure terminal Router(config)#dial-peer voice 4000 voip Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#destination pattern 4... Router(config-dial-peer)#session target sip-server Router(config-dial-peer)#end Router#
Next, we will configure outbound dial peer 9 so that all off-network calls are routed out to our SIP peer, which is the ITSP. Here is the correct configuration for this dial peer: Router#configure terminal Router(config)#dial-peer voice 9 voip Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#destination pattern 9T Router(config-dial-peer)#session target 10.1.1.100 Router(config-dial-peer)#end Router#
That’s really all there is to configure a basic SIP network to an ITSP. Different ITSPs have various requirements, however, so you will have to work with them on a case-by-case basis because they may require you to modify additional settings for your SIP connection to work properly. Some of those modifications that you may need to set are discussed in the next two sections.
Configure Secure SIP Communications SIP calls can be configured to secure the signaling protocol, the voice transmission, or both. It is highly recommended that you secure both SIP signaling and the RTP voice call. To secure SIP signaling, you must enable SIP secure (SIPS), an authentication and encryption mechanism for SIP using the Transport Layer Security (TLS) protocol. This protocol runs on top of TCP. You can enable SIPS either globally on the voice gateway or on an individual dial-peer basis.
c07.indd 241
21/09/11 11:23 AM
242
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Support for SRTP is fairly new and requires a voice gateway with IP voice IOS 12.4(15)T or higher.
In order for SIP secure to work, it must be configured end to end. To configure SIPS globally, you must enter into config-serv-sip mode and enter the url sips command. This command specifies that the router generate universal resource locators (URLs) in SIPS format for all VoIP calls on this voice gateway. Here is an example of how to configure SIPS globally: Router#configure terminal Router(config)#voice service voip Router(config-voi-serv)#sip Router(config-serv-sip)#url sips Router(config-serv-sip)#end Router#
Configuring SIPS on an individual dial-peer basis requires that you enter into config-dial-peer mode for a specific dial peer and enter the voice-class sip url sips command, as shown here with dial peer 100: Router#configure terminal Router(config)#dial-peer voice 100 voip Router(config-dial-peer)#voice-class sip url sips Router(config-dial-peer)#end Router#
Individual dial-peer SIPS configurations take precedence over any globally configured SIPS setup. Therefore, you can configure SIPS globally on the voice gateway and then disable it on specific dial peers if needed. To do this, simply enter into config-dial-peer mode for the desired dial peer and enter no voice-class sip url to disable SIPS.
Next, we want to secure the actual voice packets that run over RTP. To accomplish this, you can use SRTP in conjunction with SIPS. As with SIPS, you can configure SRTP globally or on an individual dial-peer level. To enable SRTP, you enter into config-voi-serv mode and enter the srtp command. Additionally, it is highly recommended that you also enter srtp fallback. This command specifies that if an RTP peer cannot support SRTP, the voice gateway can fall back to unencrypted RTP streams. If you don’t enter this command and you run across a device that does not support SRTP, the RTP stream cannot be set up and the call will fail. The configuration commands look like this: Router#configure terminal Router(config)#voice service voip
c07.indd 242
21/09/11 11:23 AM
Configuring SIP
243
Router(config-voi-serv)#srtp Router(config-voi-serv)#srtp fallback Router(config-voi-serv)#end Router#
To configure SRTP on a dial peer basis, you must enter the srtp and srtp fallback commands within config-dial-peer mode, as shown here with dial peer 100: Router#configure terminal Router(config)#dial-peer voice 100 voip Router(config-dial-peer)#srtp Router(config-dial-peer)#srtp fallback Router(config-dial-peer)#end Router#
Modify SIP Voice Gateway Settings There are several modifications that CVOICE candidates should be familiar with. Commonly changed default settings include these:
Configuring inbound and outbound SIP transport protocols
Modifying SIP signaling timers
Modifying SIP signaling retries
Modifying the maximum number of proxy and redirect servers
Binding a SIP source IP address
Configuring SIP for ISDN interoperation Let’s take a closer look at how to configure each of these on a Cisco voice gateway.
Configuring Inbound and Outbound SIP Transport Protocols SIP accepts UDP messages coming inbound from potential SIP peers. This can be changed so that TCP messages are accepted. To do this, you enter into config-sip-ua mode and issue the transport tcp command. This will change the router’s inbound SIP message behavior globally. Here is an example of how to modify the SIP inbound transport method: Router#configure terminal Router(config)#sip-ua Router(config-sip-ua)#transport tcp Router(config-sip-ua)#end Router#
You can also modify the transport protocol that your voice gateway uses to send SIP message to peers. Again, by default, the protocol used is UDP. You can change SIP
c07.indd 243
21/09/11 11:23 AM
244
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
outbound message protocol behavior to TCP within individual dial peers, as shown in this example using VoIP dial peer 88: Router#configure terminal Router(config)#dial-peer voice 88 voip Router(config-dial-peer)#session transport tcp Router(config-dial-peer)#end Router#
The inbound and outbound transport methods must be the same on a voice gateway. So if you change the inbound transport method to TCP, you must also change each SIP dial peer to utilize TCP as well.
Modifying SIP Signaling Timers Numerous SIP timer settings can be modified, as shown in the following output: Router(config-sip-ua)#timers ? buffer-invite Time to buffer the INVITE while waiting for display info connect Time to wait for confirmation a session connected connection Connection related timers disconnect Time to wait for confirmation a session disconnected expires Time to wait for the expiration of an INVITE request hold Time to wait during hold before disconnecting info Time to wait before INFO retransmission keepalive Options keepalive related timers notify Time to wait before NOTIFY retransmission options Time to wait before OPTIONS retransmissions prack Time to wait before starting PRACK retransmission refer Time to wait before REFER retransmission register Time to wait before REGISTER retransmission rel1xx Time to wait before starting reliable 1xx retransmission trying Time to wait for provisional response to INVITE update Time to wait before starting UPDATE retransmission Router(config-sip-ua)#timers
While the default settings work in most situations, some slower, congested, and lessreliable networks might be better off if the timers are expanded. Table 7.2 lists several of the most important SIP timer types, with each one’s purpose and default setting.
c07.indd 244
21/09/11 11:23 AM
Configuring SIP
TA B L E 7. 2
245
SIP timers
Timer Type
Purpose
Range
Default Setting
trying
Time to wait for an INVITE response
100–1000 ms
500 ms
connect
Time to wait for an ACK response
100–1000 ms
500 ms
disconnect
Time to wait for a BYE response
60000–300000 ms
180000 ms
expires
Time that an INVITE message is valid
100–1000 ms
500 ms
To modify SIP timers, you must be in config-sip-ua mode and then issue the timers command followed by the timer type and new time in milliseconds (ms). The following example adjusts the trying, connect, and expires timers to the maximum 1000 ms: Router#configure terminal Router(config)#sip-ua Router(config-sip-ua)#timers trying 1000 Router(config-sip-ua)#timers connect 1000 Router(config-sip-ua)#timers expires 1000 Router(config-sip-ua)#end Router#
Modifying SIP Signaling Retries Similar to the SIP timer options, multiple SIP retry types can be adjusted, as shown in the following output: Router(config-sip-ua)#retry ? bye BYE retry value cancel CANCEL retry value info INFO retry value invite INVITE retry value keepalive KEEPALIVE retry value notify NOTIFY retry value options OPTIONS retry value prack PRACK retry value refer REFER retry value register REGISTER retry value
c07.indd 245
21/09/11 11:23 AM
246
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
rel1xx Reliable 1xx response retry value response Response Methods retry value subscribe SUBSCRIBE retry value update UPDATE retry value Router(config-sip-ua)#retry
Again, depending on your network, it might be helpful to increase SIP retries on networks that are prone to congestion and/or dropped packets. Table 7.3 lists each retry type, its purpose, and the default setting. TA B L E 7. 3
SIP retry types
Retry Type
Purpose
Default Setting
Invite
Max number of INVITE message retries
6
Response
Max number of RESPONSE message retries
6
Bye
Max number of BYE retries
10
Cancel
Max number of CANCEL retries
10
In our example, we will modify our invite and response timers from the default of 6 retries to 8, as shown here: Router#configure terminal Router(config)#sip-ua Router(config-sip-ua)#retry invite 8 Router(config-sip-ua)#retry response 8 Router(config-sip-ua)#end Router#
If you want to reset your SIP UA configuration back to default settings, you can issue the default command followed by any of the following: max-forwards, retry {invite, response, bye, cancel}, sip-server, timers {trying, connect, disconnect, expires}, transport.
Modifying the Maximum Number of Proxy and Redirect Servers If you use SIP proxy and redirect servers on your network and have multiple servers (CUCMs in Cisco networks) for redundancy, you may need to adjust the maximum number of proxy and redirect servers. The max-forwards command specifies the maximum number of proxy or redirect servers that can forward requests. The default maximum is 70. To make
c07.indd 246
21/09/11 11:23 AM
Configuring SIP
247
these SIP modifications you must be in config-sip-ua mode. Here is an example of how to change the max proxy/redirect servers to 10: Router#configure terminal Router(config)#sip-ua Router(config-sip-ua)#max-forwards 10 Router(config-sip-ua)#end Router#
Binding a SIP Source IP Address As you’ve learned, SIP has two parts, a signaling path and a media path for the transport of voice. Many times, the two media types have different path source IP addresses. This can cause difficulties when attempting to route through a firewall that requires you to know the source IP addresses. To help eliminate configuration problems, the SIP source-bind feature can be used to statically assign an IP address to a specific voice gateway interface to be used for the signaling, media, or both signaling and media source IP addresses. To use this feature, you must be in config-serv-sip mode and issue the bind command followed by either control, media, or all. You must then specify the interface you wish to bind SIP to. This interface needs to be configured with either an IPv4 or IPv6 address for proper operation. Here is an example to configure source interface FastEthernet 0/1 to be bound for both SIP signaling and media: Router#configure terminal Router(config)#voice service voip Router(conf-voi-serv)#sip Router(conf-serv-sip)#bind all source-interface fa0/1 Router(conf-serv-sip)#end Router#
Configuring SIP for ISDN Interoperation SIP often has to interoperate with PSTN circuits such as ISDN BRI and PRI circuits. An example would be a private network that utilized SIP over WAN connections as well as out to the PSTN using an ISDN PRI, as shown in Figure 7.11. F I G U R E 7.11
Ext: 5555
SIP and ISDN interoperation
V Detroit voice gateway
SIP signaling
c07.indd 247
WAN
S1/0
PSTN
Chicago voice gateway Call coming into the Chicago voice gateway that is destined for Ext: 5555
21/09/11 11:23 AM
248
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Calls that come in from the PSTN over ISDN circuits contain valuable information, including caller ID number and display name. By default, SIP will only send the caller ID number that the call originated from. There is a two-step process to forward display names on to the terminating gateway. If you wish to receive the calling name, you must fi rst use the signaling forward command in conf-voi-serv mode, followed by either the none or unconditional keyword. The signaling forward command tells the voice gateway to forward signaling information to the terminating voice gateway. The none keyword blocks the gateway from forwarding the information, while the unconditional keyword forwards the information. You want to forward the information on to the terminating gateway as shown in Figure 7.11, so you will configure the following: Chicago#configure terminal Chicago(config)#voice service voip Chicago(conf-voi-serv)#signaling forward unconditional Chicago(conf-voi-serv)#end Chicago#
Step 2 requires that you navigate to the ISDN interface on our voice gateway and issue the isdn supp-service name calling command. This specifies that you wish to forward the calling name information sent out of the ISDN circuit. Here is an example of how to configure this on ISDN PRI serial 1/0: Chicago#configure terminal Chicago(config)#interface s1/0:23 Chicago(config-if)#isdn supp-service name calling Chicago(config-if)#end Chicago#
Optionally, if the display name is not available, you can issue the clid substitute name command to show the number in its place. You configure this command in conf-voi-serv mode, as shown here: Chicago#configure terminal Chicago(config)#voice service voip Chicago(conf-voi-serv)#clid substitute name Chicago(conf-voi-serv)#end Chicago#
All of the caller-ID configurations can also be configured at the dial-peer level instead of globally. The command syntax is identical.
c07.indd 248
21/09/11 11:23 AM
Configuring SIP
249
ISDN and SIP Caller-ID Blocking ISDN supports caller-ID blocking at the network level. While the number will be blocked at the destination phone by SIP, the message could potentially still be read elsewhere on the network in SIP message requests. If you want to completely block incoming caller ID from ISDN calls on your network, you can issue the clid strip pi-restrict command. This will permanently remove caller-ID information from SIP messages that come in as private, instead of simply hiding it from the destination endpoint. Caller-ID blocking is configured on each dial peer. Here is an example of how to configure CLID blocking on VoIP dial peer 101: Chicago#configure terminal Chicago(config)#dial peer voice 101 voip Chicago(config-dial-peer)#clid strip pi-restrict Chicago(config-dial-peer)#end Chicago#
SIP show Commands There are several useful show commands to determine if SIP is operational as well as for troubleshooting purposes. The following is a list of commonly used SIP show commands with examples of their output so you can see what information can be gleaned.
show sip-ua statistics This command is great for troubleshooting because it displays counters for various SIP successes and failures, as shown in this example output: Router# show sip-ua statistics SIP Response Statistics (Inbound/Outbound) Informational: Trying 0/5, Ringing 0/4, Forwarded 0/0, Queued 0/0, SessionProgress 0/0 Success: OkInvite 0/4, OkBye 0/0, OkCancel 0/0, OkOptions 0/0, OkPrack 0/0, OkPreconditionMet 0/0, OkSubscribe 0/0, OkNotify 0/0, OkInfo 0/0, 202Accepted 0/0 Redirection (Inbound only): MultipleChoice 0, MovedPermanently 0, MovedTemporarily 0, UseProxy 0,
c07.indd 249
21/09/11 11:23 AM
250
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
AlternateService 0 Client Error: BadRequest 0/0, Unauthorized 0/0, PaymentRequired 0/0, Forbidden 0/0, NotFound 0/0, MethodNotAllowed 0/0, NotAcceptable 0/0, ProxyAuthReqd 0/0, ReqTimeout 0/0, Conflict 0/0, Gone 0/0, ReqEntityTooLarge 0/0, ReqURITooLarge 0/0, UnsupportedMediaType 0/0, BadExtension 0/0, TempNotAvailable 0/0, CallLegNonExistent 0/0, LoopDetected 0/0, TooManyHops 0/0, AddrIncomplete 0/0, Ambiguous 0/0, BusyHere 0/0, RequestCancel 0/0, NotAcceptableMedia 0/0, BadEvent 0/0, SETooSmall 0/0 Server Error: InternalError 0/0, NotImplemented 0/0, BadGateway 0/0, ServiceUnavail 0/4, GatewayTimeout 0/0, BadSipVer 0/0, PreCondFailure 0/0 Global Failure: BusyEverywhere 0/0, Decline 0/0, NotExistAnywhere 0/0, NotAcceptable 0/0 SIP Total Traffic Statistics (Inbound/Outbound) Invite 5/0, Ack 4/0, Bye 0/4, Cancel 0/0, Options 0/0, Prack 0/0, Comet 0/0, Subscribe 0/0, Notify 0/0, Refer 0/0, Info 0/0 Retry Statistics Invite 0, Bye 2, Cancel 0, Response 4, Prack 0, Comet 0, Reliable1xx 0, Notify 0 SDP application statistics: Parses:5, Builds 4 Invalid token order:0, Invalid param:0 Not SDP desc:0, No resource:0 Last time SIP Statistics were cleared: Router#
c07.indd 250
21/09/11 11:23 AM
Configuring SIP
251
Note the last line of the output, which indicates when the SIP statistics were last cleared. If you are troubleshooting with this command, you can clear out the statistics using the clear sip-ua statistics command.
show sip-ua status This command gives you a quick view of the SIP configuration settings so you can easily see if there have been any modifications. The following output tells you what SIP options are enabled/disabled and shows you settings such as your max-forwards for SIP proxy and redirect servers. Additionally, you can see what SDP information is supported and required: Router#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 SIP User Agent bind status(signaling): DISABLED SIP User Agent bind status(media): DISABLED SIP early-media for 180 responses with SDP: ENABLED SIP max-forwards: 70 SIP DNS SRV version: 2 (rfc 2782) NAT Settings for the SIP-UA Role in SDP: NONE Check media source packets: DISABLED Maximum duration for a telephone-event in NOTIFYs: 2000 ms SIP support for ISDN SUSPEND/RESUME: ENABLED Redirection (3xx) message handling: ENABLED Reason Header will override Response/Request Codes: DISABLED Out-of-dialog Refer: DISABLED Presence support is DISABLED SDP application configuration: Version line (v=) required Owner line (o=) required Timespec line (t=) required Media supported: audio image Network types supported: IN Address types supported: IP4 Transport types supported: RTP/AVP udptl Router#
c07.indd 251
21/09/11 11:23 AM
252
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
show sip-ua timers If you made changes to the SIP timers, you can verify them using this command. Here is an example of its output, displaying all of the default SIP timer settings: Router#show sip-ua timers SIP UA Timer Values (millisecs unless noted) trying 500, expires 180000, connect 500, disconnect 500 prack 500, rel1xx 500, notify 500, update 500 refer 500, register 500, info 500, options 500, hold 2880 minutes tcp/udp aging 5 minutes Router#
show sip-ua retry SIP retry values can also be scanned and verified using this command. Here is an example of its output, showing the default SIP retry settings: Router#show sip-ua retry SIP UA Retry Values invite retry count = 6 bye retry count = 10 prack retry count = 10 reliable 1xx count = 6 refer retry count = 10 info retry count = 6 options retry count = 6
response retry count cancel retry count update retry count notify retry count register retry count subscribe retry count
= = = = = =
6 10 6 10 6 6
Router#
show sip-ua calls This command is useful for seeing calls being made in real time. Helpful information includes source and destination E.164 numbers, source and destination IP addresses, and codecs being used, as shown in this example output: Router# show sip-ua calls SIP UAC CALL INFO Call 1 SIP Call ID: A0626031–8EC511DF-A260B9C0–[email protected] State of the call: STATE_ACTIVE (6)
c07.indd 252
21/09/11 11:23 AM
Configuring MGCP
253
Substate of the call: SUBSTATE_NONE (0) Calling Number: 4010 Called Number: 5510 Bit Flags: 0x12120030 0x220000 Source IP Address (Sig ): 192.168.1.77 Destn SIP Req Addr:Port: 192.168.10.66:5063 Destn SIP Resp Addr:Port: 192.168.10.66:5063 Destination Name: 192.168.10.66 Number of Media Streams: 1 Number of Active Streams: 1 RTP Fork Object: 0x0 Media Stream 1 State of the stream: STREAM_ACTIVE Stream Call ID: 27 Stream Type: voice-only (0) Negotiated Codec: g711ulaw (160 bytes) Codec Payload Type: 0 Negotiated Dtmf-relay: inband-voice Dtmf-relay Payload Type: 0 Media Source IP Addr:Port: 192.168.1.77:19465 Media Dest IP Addr:Port: 192.168.10.66:16890 SIP UAS CALL INFO Number of UAS calls: 0 Router#
Configuring MGCP Compared to H.323 and SIP, configuring MGCP is a breeze. This is primarily thanks to the fact that MGCP is a client-server architecture with centralized call control. The call control agent in the Cisco world is a CUCM, which manages all dial plans and the setup and teardown of connections between the IP network and the PSTN. When connecting to the PSTN via ISDN, MGCP is different from H.323 and SIP in that all Layer 3 signaling is controlled by the call agent. Therefore, both MGCP and Q.931 signaling is backhauled between the PSTN and the CUCM, while Q.921 signaling is used between the voice gateway and the PSTN. MGCP creates a separate channel that is used to backhaul the
c07.indd 253
21/09/11 11:23 AM
254
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Q.931 information between the call agent and voice gateway. MGCP communication boundaries are shown in Figure 7.12.
F I G U R E 7.1 2
MGCP and ISDN signaling Internal IP network
M CUCM
PSTN
V Voice gateway
MGCP
Q.921 Q.931
Like SIP, MGCP uses SDP for session initiation between endpoints. The MGCP gateway is responsible for converting voice signals between traditional PSTN connections and the IP network. MGCP signaling is used to report events such as off-hook status or DTMF occurrences. These events are sent up to the call agent as notification event messages. And because the call agent handles all call-routing decisions, no dial peers are configured on the voice gateway (unless you have analog phones directly attached). This is what is meant by centralized call control.
Because MGCP relies so heavily on the call agent, if connectivity is lost, MGCP does not have the capability on its own to independently route calls between the IP and PSTN. Fortunately, you can configure H.323 fallback and Survivable Remote Site Telephony (SRST) on the voice gateway to handle these situations. Both of these techniques are defined and described in Chapter 9, “Advanced Voice Gateway Features,” of this study guide.
MGCP uses cleartext communication between the voice gateway and call agent. The commands are sent from the call agent to the voice gateway using UDP port 2427 by default. The actual MGCP configuration on voice gateways primarily defi nes where the call agent is located on the network so a communications channel can be started. MGCP defi nes two distinctly different voice gateway types.
Residential Gateways MGCP residential gateways are responsible for providing signaling between the IP network and analog voice ports including FXS, FXO, and E&M. Figure 7.13 shows an example of what a residential gateway network might look like.
c07.indd 254
21/09/11 11:23 AM
Configuring MGCP
F I G U R E 7.1 3
255
An MGCP residential gateway
Voice gateway V
Switch
Analog ports
g
lin
na
ig Ps
C
MG
M CUCM
While this example shows the MGCP voice gateway supporting analog telephone endpoints, keep in mind that the analog endpoint could be a key system or analog PBX.
Trunking Gateways As the name suggests, MGCP trunking gateways differ from residential gateways because they connect an IP network to the PSTN using trunk ports such as T1s and E1s. Figure 7.14 shows an example of what a trunking gateway network might look like.
F I G U R E 7.1 4
An MGCP trunking gateway
Voice gateway Trunk V
PSTN
Switch
M CUCM
Regardless of the gateway type, an MGCP gateway exchanges control commands between itself and the call agent. These messages are simplistic in nature and are used to either notify the call agent of things occurring on the PSTN or to take orders from the call
c07.indd 255
21/09/11 11:23 AM
256
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
agent. Each of these messages is sent with a four-letter acronym to define the command. Responses to the commands begin with a three-number response code. The nine MGCP communications messages and their functions are listed in Table 7.4. TA B L E 7. 4
MGCP command acronyms
MGCP Command Acronym
Acronym Meaning
Command Function
AUEP
Audit endpoint
Used to audit the status of endpoints.
AUCX
Audit connection
Used to audit the status of endpoint connections.
CRCX
Create connection
Used to create RTP connection that terminates on the voice gateway.
DLCX
Delete connection
Used to delete RTP connection that is terminated on the voice gateway.
MDCX
Modify connection
Used to modify existing RTP connection that is terminated on the voice gateway.
RQNT
Request for notification
Used by the call agent to request the voice gateway to begin monitoring for signaling events.
EPCF
Endpoint configuration
Used by the call agent to remotely send a configuration command to the voice gateway.
NTFY
Notify
Used by the voice gateway to notify the call agent of an event the call agent has requested (in an RQNT command message) it monitors for.
RSIP
Restart in progress
Used by the voice gateway to inform the call agent that it is in the process of restarting.
The MGCP’s events and signaling messages are bundled into various MGCP configuration packages to provide simplicity when setting up your MGCP gateway. Each package serves a specific MGCP function. You enable the packages you wish to utilize and leave the other packages disabled. Packages are categorized into groups; for example, the line-package group contains all of the signaling and event packets when operating a residential gateway. The trunk-package provides all the default events and signals for PSTN trunking gateways. Other packages provide more specific events and signaling such
c07.indd 256
21/09/11 11:23 AM
Configuring MGCP
257
as a secure RTP (srtp-package) package and a fax transmission (fxr-package) package. Package types are configured on voice gateways using the mgcp package-capability command while in global configuration mode. Following is a listing within the Cisco IOS showing possible MGCP package types and their descriptions: Router(config)#mgcp package-capability ? as-package Select the Announcement Server Package dtmf-package Select the DTMF Package fm-package Select the FM Package fxr-package Select the FXR Package gm-package Select the Generic Media Package hs-package Select the Handset Package it-package Select the IT Package lcs-package Select the Line Control Signaling Package line-package Select the Line Package mdr-package Select the MDR Package mf-package Select the MF Package pre-package Select the PRE Package res-package Select the RES Package rtp-package Select the RTP Package script-package Select the Script Package srtp-package Select the SRTP Package sst-package Select the SST Package trunk-package Select the Trunk Package Router(config)#mgcp package-capability
Configure an MGCP Residential Gateway As stated previously, MGCP residential gateways connect analog ports to an IP network. The fi rst IOS configuration step that must be performed is simply to enable MGCP on your voice gateway. To do that, just type in mgcp while in global configuration mode. Additionally, if your call agent is a CUCM, you need to add the ccm-manager mgcp command. If your call agent is from a different vendor, this command is not needed. Next, you need to inform your local voice gateway where your call agent (or call agents if there are more than one) is located on the IP network. To accomplish this, you use the mgcp call-agent command in global configuration mode and specify either the IP address or the hostname (using DNS) of your CUCM. To fi nish the command, you use the service-type mgcp keyword to indicate you are using MGCP signaling. This command can be used multiple times in the configuration to add additional call agents. The voice gateway will send requests out to all configured call agents and will use the fi rst one that responds to a MGCP message request.
c07.indd 257
21/09/11 11:23 AM
258
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Finally, you will select the MGCP event and signaling packages you will utilize on your network using the mgcp package-capability command. Note that the line-package is enabled by default for residential gateway configurations. In our example we will use the line-package, dtmf-package, gm-package, and rtp-package. Using Figure 7.15 as our example network, we enable MGCP on our voice gateway, configure the two CUCM call agents, and enable the following MGCP packages for our residential gateway:
line-package—The default package used with MGCP residential gateways for message information such as caller ID, hook flash, and reorder tones.
dtmf-package—Used to generate DTMF tones.
gm-package—Used to generate media events and signals for a wide range of “generic” events including the congestion tone, fax tones, and ringback.
rtp-package—Used to generate RTP event messages such as continuity tones and tests,
jitter buffer modification messages, and RTP/RTCP timeouts. The following commands show how to configure an MGCP residential gateway: Router#configure terminal Router(config)#mgcp Router(config)#ccm-manager mgcp Router(config)#mgcp call-agent 192.168.10.100 service-type mgcp Router(config)#mgcp call-agent 192.168.20.100 service-type mgcp Router(config)# mgcp package-capability line-package Router(config)# mgcp package-capability dtmf-package Router(config)# mgcp package-capability gm-package Router(config)# mgcp package-capability rtp-package Router(config)#end Router#
F I G U R E 7.1 5
An MGCP residential gateway network
M Primary CUCM 192.168.10.100
FXS 0/0/1 Switch
V Voice gateway
M Secondary CUCM 192.168.20.100
c07.indd 258
21/09/11 11:23 AM
Configuring MGCP
259
If your CUCM is listening for MGCP signaling on a UDP port other than the default 2427, you can change the port when defining call agents. For example, if you want to change the port to 3000 to a call agent at 192.168.1.10, you would configure: mgcp call-agent 192.168.1.10 3000 service-type mgcp Alternatively, if the MGCP wishes to communicate to the voice gateway on a different port, this can be changed using the mgcp command used to enable MGCP on the voice gateway. To change the voice gateway listening port to 3000, you would issue mgcp 3000 on the voice gateway in global configuration mode.
The remainder of an MGCP residential gateway configuration is performed within individual POTS dial peers. In our example, we will configure a POTS dial peer (300) for FXO port 0/0/1 and issue the application mgcpapp command to associate the dial peer and port with MGCP: Router#configure terminal Router(config)#dial-peer voice 300 pots Router(config-dial-peer)#port 0/0/1 Router(config-dial-peer)#application mgcpapp Router(config-dial-peer)#end Router#
Notice that we do not include any destination-pattern commands in our POTS dial peer; that’s because the call agent controls this information.
Configure an MGCP Trunking Gateway The primary steps for enabling, specifying call agents, and choosing MGCP package groups you’ve seen for the configuration of residential gateways are identical for trunking gateways, although the specific MGCP packages you select will be different. Also note that the trunkpackage MGCP configuration group will be enabled by default when configuring a trunking gateway. In our example we will use trunk-package, dtmf-package, gm-package, and rtp-package. The remainder of the MGCP trunking configuration is very different from the MGCP residential configuration, however. When configuring trunking gateways, you must specify the controller of the T1/E1 you wish to enable MGCP on. Then you must use the PRI ds0group command, specify the timeslots, specify a type of none, and then issue the service mgcp key phrase. Using Figure 7.16 as our example network, we enable MGCP on our voice gateway, configure a CUCM call agent, and enable our required MGCP group packages. Also note in the configuration example how the MGCP line package that was used in our residential
c07.indd 259
21/09/11 11:23 AM
260
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
gateway is replaced with the trunk package for our trunking gateway. The trunk package includes trunk-specific events and tones.
F I G U R E 7.1 6
An MGCP trunking gateway network
T1 2/0 M CUCM 10.165.1.100
Switch
V Voice gateway
PSTN
Router#configure terminal Router(config)#mgcp Router(config)#ccm-manager mgcp Router(config)#mgcp call-agent 10.165.1.100 service-type mgcp Router(config)# mgcp package-capability trunk-package Router(config)# mgcp package-capability dtmf-package Router(config)# mgcp package-capability gm-package Router(config)# mgcp package-capability rtp-package Router(config)#end Router#
Next, we will configure T1 PRI port 2/0 to enable MGCP on all 24 timeslots of DS0 group 0, which is already configured: Router#configure terminal Router(config)#controller t1 2/0 Router(config-controller)#ds0-group 0 timeslots 1–24 type none service mgcp Router(config-controller)#end Router#
MGCP show Commands Now that you know how to configure both residential and trunking MGCP gateways, let’s look at some of the IOS show commands used to verify our configuration and to be used for troubleshooting MGCP signaling problems. The next section covers show commands commonly used for gathering MGCP information.
show mgcp profile This command is great when verifying configuration settings and when comparing timeout values, as shown this example output:
c07.indd 260
21/09/11 11:23 AM
Configuring MGCP
261
Router#show mgcp profile MGCP Profile default Description: None Call-agent: 10.165.1.100 Initial protocol service is MGCP 0.1 Tsmax timeout is 20 sec, Tdinit timeout is 15 sec Tdmin timeout is 15 sec, Tdmax timeout is 600 sec Tcrit timeout is 4 sec, Tpar timeout is 16 sec Thist timeout is 30 sec, MWI timeout is 16 sec Ringback tone timeout is 180 sec, Ringback tone on connection timeout is 180 sec Network congestion tone timeout is 180 sec, Busy tone timeout is 30 sec Network busy tone timeout is 0 sec Dial tone timeout is 16 sec, Stutter dial tone timeout is 16 sec Ringing tone timeout is 180 sec, Distinctive ringing tone timeout is 180 sec Continuity1 tone timeout is 3 sec, Continuity2 tone timeout is 3 sec Reorder tone timeout is 30 sec, Persistent package is ms-package Max1 DNS lookup: ENABLED, Max1 retries is 5 Max2 DNS lookup: ENABLED, Max2 retries is 7 Source Interface: NONE T3 endpoint naming convention is T1 prefer active call-agent is DISABLED CAS Notification Digit order is Default Router#
show mgcp This command can tell you the current operational status of the voice gateway. In the following output, you can see that MGCP is both administratively and operationally active. This means that the voice gateway is ready to communicate with the call agent located at IP 10.165.1.100. Additionally, you can see information such as codec type and supported MGCP packages: Router#show mgcp MGCP Admin State ACTIVE, Oper State ACTIVE—Cause Code NONE MGCP call-agent: 10.165.1.100 Initial protocol service is MGCP 0.1 MGCP validate call-agent source-ipaddr DISABLED MGCP validate domain name DISABLED MGCP block-newcalls DISABLED MGCP send SGCP RSIP: forced/restart/graceful/disconnected DISABLED MGCP quarantine mode discard/step
c07.indd 261
21/09/11 11:23 AM
262
MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP MGCP
MGCP SGCP MGCP MGCP MGCP MGCP MGCP
c07.indd 262
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
quarantine of persistent events is ENABLED dtmf-relay for VoIP is SDP controlled dtmf-relay for voAAL2 is SDP controlled voip modem passthrough disabled voaal2 modem passthrough disabled voip modem relay: Disabled T.38 Named Signalling Event (NSE) response timer: 200 Network (IP/AAL2) Continuity Test timer: 200 ‘RTP stream loss’ timer: 5 request timeout 500 maximum exponential request timeout 4000 gateway port: 2427, MGCP maximum waiting delay 3000 restart delay 0, MGCP vad DISABLED rtrcac DISABLED system resource check DISABLED xpc-codec: DISABLED, MGCP persistent hookflash: DISABLED persistent offhook: ENABLED, MGCP persistent onhook: DISABLED piggyback msg ENABLED, MGCP endpoint offset DISABLED simple-sdp DISABLED undotted-notation DISABLED codec type g711ulaw, MGCP packetization period 20 JB threshold lwm 30, MGCP JB threshold hwm 150 LAT threshold lwm 150, MGCP LAT threshold hwm 300 PL threshold lwm 1000, MGCP PL threshold hwm 10000 CL threshold lwm 1000, MGCP CL threshold hwm 10000 playout mode is adaptive 60, 40, 1000 in msec Fax Playout Buffer is 300 in msec media (RTP) dscp: ef, MGCP signaling dscp: af31 default package: trunk-package supported packages: gm-package dtmf-package trunk-package line-package hs-package ms-package dt-package mo-package mt-package fxr-package md-package Digit Map matching order: shortest match Digit Map matching order: always left-to-right VoAAL2 ignore-lco-codec DISABLED T.38 Max Fax Rate is DEFAULT T.38 Fax is ENABLED T.38 Fax ECM is ENABLED T.38 Fax NSF Override is DISABLED
21/09/11 11:23 AM
Configuring MGCP
263
MGCP T.38 Fax Low Speed Redundancy: 0 MGCP T.38 Fax High Speed Redundancy: 0 MGCP Fax relay SG3-to-G3: ENABLED MGCP control bind:DISABLED MGCP media bind:DISABLED MGCP Upspeed payload type for G711ulaw: 0, G711alaw: 8 MGCP Dynamic payload type for G.726–16K codec MGCP Dynamic payload type for G.726–24K codec MGCP Dynamic payload type for G.726–32K codec MGCP Dynamic payload type for G.Clear codec MGCP Dynamic payload type for NSE is 100 MGCP Dynamic payload type for NTE is 99 MGCP rsip-range is enabled for TGCP only. MGCP Comedia role is NONE MGCP Comedia check media source is DISABLED MGCP Comedia SDP force is DISABLED MGCP Guaranteed scheduler time is DISABLED MGCP DNS stale threshold is 30 seconds Router#
show mgcp statistics This command is useful for troubleshooting purposes because it displays incrementing counts of sent and received MGCP messages between the voice gateway and call agent. Counters increment for successful and failed message packets, so you can quickly see if your MGCP messages are being properly transmitted across your network. You can verify information including unrecognized, duplicate, or failed packets. Here is an example of the output of this show command: Router#show mgcp statistics UDP pkts rx 20, tx 21 Unrecognized rx pkts 0, MGCP message parsing errors 0 Duplicate MGCP ack tx 0, Invalid versions count 0 CreateConn rx 10, successful 10, failed 0 DeleteConn rx 4, successful 4, failed 0 ModifyConn rx 10, successful 10, failed 0 DeleteConn tx 0, successful 0, failed 0 NotifyRequest rx 10, successful 10, failed 0 AuditConnection rx 0, successful 0, failed 0 AuditEndpoint rx 0, successful 0, failed 0
c07.indd 263
21/09/11 11:23 AM
264
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
RestartInProgress tx 1, successful 1, failed 0 Notify tx 0, successful 0, failed 0 ACK tx 20, NACK tx 0 ACK rx 0, NACK rx 0 IP address based Call Agents statistics: IP address 10.165.1.100, Total msg rx 20, successful 20, failed 0 DS0 Resource Statistics ———————————Utilization: 0.00 percent Total channels: 0 Addressable channels: 0 Inuse channels: 0 Disabled channels: 0 Free channels: 0 Router#
You can see in this example that we’ve successfully communicated with our call agent at 10.165.1.100, because it is listed in the statistics command output and MGCP packets are being transmitted and received. The statistics counters can be reset by issuing the clear mgcp statistics command, so you can easily see if any changes to the configuration had an impact on success transmits and receipts of MGCP messages.
show ccm-manager You can easily verify that you are properly registered to a CUCM using this command. Information at the beginning of the output lists primary and backup CUCM call agents, their current status, and the host/IP address of the call agent, as shown in this example where we have our primary call agent (10.165.1.100) registered but have no backups configured: Router#show ccm-manager MGCP Domain Name: CCVP Priority Status Host ============================================================ Primary Registered 10.165.1.100 First Backup None Second Backup None Current active Call Manager: Backhaul/Redundant link port: Failover Interval:
c07.indd 264
None 2428 30 seconds
21/09/11 11:23 AM
Summary
Keepalive Interval: Last keepalive sent: (elapsed time: 02:17:46) Last MGCP traffic time: (elapsed time: 00:00:00) Last failover time: Last switchback time: Switchback mode: MGCP Fallback mode: Last MGCP Fallback start time: Last MGCP Fallback end time: MGCP Download Tones: TFTP retry count to shut Ports:
265
15 seconds 09:33:22 CST Jan 22 2011 10:51:08 CST Jan 22 2011 None None Graceful Not Selected None None Disabled 2
Backhaul Link info: Link Protocol: TCP Remote Port Number: 2428 Remote IP Address: 10.165.1.100 Current Link State: OPEN Statistics: Packets recvd: 0 Recv failures: 0 Packets xmitted: 0 Xmit failures: 0 PRI Ports being backhauled: Slot 0, VIC 0, port 0 FAX mode: cisco Router#
Summary In Chapter 7 you learned about the three primary voice gateway signaling protocols: H.323, SIP, and MGCP. Each of these protocols operates slightly differently on IP and PSTN networks, and we explored their differences and how to configure and tweak their settings. Additionally, it is important to know several show commands used to verify proper configuration of your voice gateway and to use them in cases where troubleshooting is needed. We will continue to explore voice gateway configurations in various situations that utilize these signaling protocols in Chapter 9 of this study guide.
c07.indd 265
21/09/11 11:23 AM
266
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
Exam Essentials Understand H.323 voice gateway signaling boundaries between the CUCM and ISDN. H.323 signaling operates between the CUCM and the H.323 voice gateway. ISDN Q.921 and Q.931 signaling operates between the H.323 gateway and the PSTN. Know the difference between H.323 slow and fast start initiation methods. With slow start, the H.245 channel is created after the call setup, call proceeding, alerting, and connect phases complete, while fast start sets up the H.245 channel during the call setup stage. Know how to configure basic H.323 between two voice gateways. H.323 is the default signaling protocol for Cisco voice gateways. Configuring signaling between two voice gateways is just a matter of configuring the proper dial peers that point to the remote gateway. Understand the primary H.323 settings that can be modified. Sometimes it is necessary to modify H.323 from its default settings. Options such as configuring slow start initiation, codec preference, and transport mode and adjusting H.323 timers are often changed to meet the needs of the network. Understand H.323 interface binding. If you want to eliminate a physical single point of failure on your H.323 network, configure interface binding to bind multiple physical interfaces together to create a single logical interface. Know how to verify H.323 configurations. There are several show commands that are useful for verification and troubleshooting H.323, including show gateway and show h323 gateway. Understand SIP voice gateway signaling boundaries between the CUCM and ISDN. SIP signaling operates between the CUCM and SIP voice gateway. ISDN Q.921 and Q.931 signaling operates between the SIP gateway and the PSTN. Understand the responsibilities of SIP. SIP is an end-to-end protocol that can be responsible for knowing the location of endpoints and their capabilities, determining if endpoints are available, and the establishment and teardown of a SIP call. Know how to configure basic SIP between two voice gateways. Configuring SIP between voice gateways on a network is a matter of enabling SIP version 2 on the router, configuring UA settings, and creating the proper VoIP dial peers to point to the remote SIP gateway. Know how to configure secure SIP communications. You can configure SIP itself by enabling SIPS. Additionally, you can secure the voice channel by enabling SRTP and SRTP fallback. Understand the primary SIP settings that can be modified. Sometimes it is necessary to modify SIP from its default settings. Options such as transport protocol method, signaling timers, retry limits, and proxy and redirect server settings are often changed to meet the needs of the network.
c07.indd 266
21/09/11 11:23 AM
Written Lab 7.1
267
Know how to configure SIP to interoperate with ISDN. There are a few steps that should be taken so that SIP properly interoperates with ISDN. Commands such as signaling forward unconditional, isdn supp-service name, clid strip-pi-restrict, and clid substitute name all deal with how SIP can properly handle caller-ID functions that are transported across ISDN networks. Know how to verify SIP configurations. There are several show commands that are useful for verifying and troubleshooting SIP, including show sip-ua statistics, show sip-ua status, show sip-ua timers, show sip-ua retry, and show sip-ua calls. Understand MGCP voice gateway signaling boundaries between the CUCM and ISDN. MGCP signaling operates between the CUCM and MGCP voice gateway. ISDN signaling Q.921 operates between the MGCP gateway and the PSTN, while ISDN Q.931 operates between the PSTN and CUCM. Understand the difference between MGCP residential and trunking gateways. MGCP residential gateways use analog ports such as FXS, FXO, and E&M, while trunking gateways use PSTN connections that can be trunked such as an ISDN T1/E1 PRI. Know how to configure basic MGCP between two voice gateways. Configuring MGCP between voice gateways on a network is a matter of enabling MGCP on the router, notifying the MGCP gateway where the call agent resides, and choosing the MGCP signaling packages your gateway requires. If your gateway has analog ports directly configured, you must add the application mgcpapp command to the dial peer. If your gateway has trunking ports, you must enable the MGCP service on the physical controller interface. Know how to verify MGCP configurations. There are several show commands that are useful for verification and troubleshooting MGCP including show mgcp profile, show mgcp, show mgcp statistics, and show ccm-manager.
Written Lab 7.1
c07.indd 267
1.
What is the default H.323 initiation method?
2.
You wish to configure a voice gateway but fi nd that the VoIP service has been manually shut down. While in global configuration mode, you enter voice service voip, which brings you to the conf-voi-serv configuration mode. What must you enter to start the VoIP service?
3.
By default, how many concurrent calls are supported using the H.323 protocol on Cisco IOS gateways?
4.
You are configuring a VoIP dial peer and are in config-dial-peer mode. What command do you use to enable this dial peer to utilize the SIP signaling protocol?
5.
In a SIP environment, what is a SIP voice gateway known as?
21/09/11 11:23 AM
268
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
6.
Once a SIP call is connected and RTP connections are established independently between two endpoints, SIP continues to monitor the call to provide what two services?
7.
What SIP show command lets you see if SIP is enabled to operate on both UDP and TCP?
8.
When connected to the PSTN through an ISDN BRI, MGCP backhauls what type of signaling between the PSTN and local CUCM?
9.
You want to enable fax transmission services on your MGCP router for outbound fax service to the PSTN. What MGCP configuration package must you enable?
10. What protocol and port does MGCP operate on by default?
(The answers to Written Lab 7.1 can be found following the answers to the review questions for this chapter.)
Hands-On Labs To complete the labs in this section, you need a Cisco router with a voice-capable IOS and two FastEthernet ports to use as our simulated WAN connection and a second connection to our internal network. Each lab in this section builds on the last and will follow the logical voice gateway design shown in Figure 7.17.
F I G U R E 7.17
Voice gateway lab diagram
172.16.3.10
Extensions: 3XX
IP
Internal network
Fa1/0
Fa2/0 V Local SIP gateway
V ITSP gateway
PSTN
M 10.154.79.101
c07.indd 268
21/09/11 11:23 AM
Hands-On Labs
269
This lab assumes that basic IP networking and the local voice network are operational. Additionally, we assume the ITSP voice gateway is already properly configured. We are only concerned with configuring the local SIP gateway. Here is a list of the labs in this chapter: Lab 7.1: Configuring Basic SIP Lab 7.2: Modifying SIP Timers and Retries
Hands-On Lab 7.1: Configuring Basic SIP In this lab, we’re going to configure a voice gateway that has a connection to our ITSP for outbound calling over Fa1/0. Our phones receive E.164 information from the remote SIP server located at the ITSP. The task here is to enable SIP and point it to the SIP registrar using the information found in Table 7.5. TA B L E 7. 5
c07.indd 269
Sample configuration values for basic SIP
SIP Network Information
PSTN Requirements
SIP registrar address
10.154.79.101
Username
cucmsipregistrar
Password
password101
Bind interface
Fa2/0
Remote SIP address
172.16.3.10
Outbound dial peer
Dial 9 for off-net calls and allow all E.164 numbers
1.
Log into the local voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Enter into conf-voi-serv mode by typing voice service voip.
3.
Enter into config-serv-sip mode by typing sip.
4.
Configure SIP source binding by typing bind all source-interface fa2/0.
5.
Return to global configuration mode by typing exit and exit.
6.
Enter into config-sip-ua mode by typing sip-ua.
7.
Configure the SIP registrar server by typing registrar 10.154.79.101.
8.
Configure SIP authentication to the local SIP registrar server by typing authentication username cucmsipregistrar password 0 password 101.
9.
Return to global configuration mode by typing exit.
21/09/11 11:23 AM
Chapter 7
270
■
Configuring Voice Gateway Signaling Protocols
10. Enter into config-dial-peer mode and create VoIP dial peer 300 by typing dial-peer voice 300 voip.
11. Enable SIP on this dial peer by typing session protocol sipv2. 12. Configure a destination pattern to match the internal IP phones by typing destination-pattern 3...
13. Point the dial peer to our internal SIP proxy (the CUCM) by typing session target 10.154.79.101.
14. Return to global configuration mode by typing exit. 15. Enter into config-dial-peer mode and create VoIP dial peer 9 by typing dial-peer voice 9 voip.
16. Enable SIP on this dial peer by typing session protocol sipv2. 17. Configure a destination pattern to match all external phones by typing destinationpattern 9T.
18. Point the dial peer to our internal SIP proxy (the CUCM) by typing session target 10.154.79.101.
19. Exit config-dial-peer mode by typing end.
Hands-On Lab 7.2: Modifying SIP Timers and Retries In Lab 7.1 we configured basic SIP. But now we’re beginning to experience some problems because of congestion on the network. It has been suggested that we modify the following timers and retries on our voice gateway according to Table 7.6. TA B L E 7. 6
c07.indd 270
Sample configuration values for modifying SIP timers and retries
SIP Timers/Retries
PSTN Requirements
trying timer
1000 ms
connect timer
1000 ms
disconnect timer
200000 ms
expires timer
1000 ms
invite retries
10
response retries
10
bye retries
15
cancel retries
15
21/09/11 11:23 AM
Hands-On Labs
271
1.
Log into the local voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Enter into conf-sip-ua mode by typing sip-ua.
3.
Modify the SIP trying timer by typing timers trying 1000.
4.
Modify the SIP connect timer by typing timers connect 1000.
5.
Modify the SIP disconnect timer by typing timers disconnect 200000.
6.
Modify the SIP max invite retries by typing retry invite 10.
7
Modify the SIP max response retries by typing retry response 10.
8.
Modify the SIP max bye retries by typing retry bye 15.
9.
Modify the SIP max cancel retries by typing retry cancel 15.
10. Exit config-sip-ua mode by typing end. 11. Verify your SIP timers by typing show sip-ua timers. 12. Verify your SIP retries by typing show sip-ua retry.
c07.indd 271
21/09/11 11:23 AM
Chapter 7
272
■
Configuring Voice Gateway Signaling Protocols
Review Questions 1.
A what stage of the H.323 slow start initiation process does the voice gateway perform H.245 negotiation? A. After the call setup stage
2.
B.
During the call proceeding stage
C.
After the connect stage
D.
After the alerting stage
Which signaling protocol does not need dial peers configured on the voice gateway in order to operate? A. SIP
3.
B.
SIP v2
C.
H.323
D.
MGCP
What two functions are the responsibility of H.245 when using H.323 signaling? A. Exchange capabilities information between endpoints.
4.
B.
Transport SDP information between endpoints.
C.
Transport voice or video streams within an H.245 channel.
D.
Open and close media channels.
Which of the following is the correct IOS command mode and command used to enable H.323 slow start signaling globally on a voice gateway? A. Router(conf-voi-serv)#call start slow
5.
B.
Router(conf-serv-h323)#h323 call start slow
C.
Router(conf-voi-serv)#h323 call start slow
D.
Router(conf-serv-h323)#call start slow
Which of the following might be a valid reason to modify the H.323 initiation procedure from the default fast start to slow start? A. If the network is prone to dropped packets and/or congestion
c07.indd 272
B.
If you have an H.323 endpoint that does not support fast start
C.
If you plan to use media features such as MOH
D.
If you wish to utilize the H.323 early media feature
21/09/11 11:23 AM
Review Questions
6.
273
You have finished configuring codec preference 10 on your voice gateway and want to apply it to dial peer 101. Which of the following commands correctly shows this? A. Router(config)#dial-peer voice 101 pots Router(config-dial-peer)#voice-class codec 10 B.
Router(config)#dial-peer voice 101 pots Router(config-dial-peer)#voice-class preference 10
C.
Router(config)#dial-peer voice 101 voip Router(config-dial-peer)#voice-class codec 10
D.
Router(config)#dial-peer voice 101 voip Router(config-dial-peer)#voice-class preference 10
7.
You have been asked to eliminate a physical single point of failure on your H.323 network by configuring interface binding. Which of the following properly configures a virtual address with the IP address of 172.16.3.1/24 and binds the interface to be used as the H.323 source address? A. Router(config)#interface loopback0 Router(config-if)#ip address 172.16.3.1 255.255.255.0 Router(config-if)#h323-gateway voip bind srcaddr loopback 0 B.
Router(config)#interface loopback0 Router(config-if)#ip address 172.16.3.1 255.255.255.0 Router(config-if)#h323-gateway voip bind srcaddr 172.16.3.1
C.
Router(config)#interface loopback0 Router(config-if)#ip address 172.16.3.1 255.255.255.0 Router(config-if)#gateway voip bind srcaddr 172.16.3.1
D.
Router(config)#interface loopback0 Router(config-if)#ip address 172.16.3.1 255.255.255.0 Router(config-if)#h323-gateway voip interface-bind 172.16.3.1
8.
Which H.323 show command would be most useful when troubleshooting H.323 call-signaling problems? A. show gateway
c07.indd 273
B.
show h323 gateway h225
C.
show h323 gateway
D.
show h323 gateway statistics
21/09/11 11:23 AM
Chapter 7
274
9.
■
Configuring Voice Gateway Signaling Protocols
In what format are SDP messages sent? A. Hexadecimal B.
ASCII
C.
Binary
D.
Cisco proprietary format
10. What type of SIP message contains SDP data when using the SIP early-offer method? A. Ack B.
Response
C.
Invite
D.
OK
11. Which of the following is not a task that is handled by SIP? A. Knowing the capabilities of target endpoints B.
Providing the setup and teardown of voice calls
C.
Knowing the location of target endpoints
D.
Opening a backhaul channel for the transport of Q.931 signaling between the PSTN and CUCM when the SIP gateway is connected to an ISDN circuit from the PSTN
E.
Determining if the destination endpoint is available for a call
12. SIP must signal back to the calling party when the calling phone is all of the following except what? A. Busy B.
Incompatible firmware
C.
Offline
D.
Ring-no-answer
13. Which of the following commands is used to enable SIP on a VoIP dial peer? A. Router(config-dial-peer)#session protocol sipv2
c07.indd 274
B.
Router(config-dial-peer)#gateway protocol sipv2
C.
Router(config-dial-peer)#session protocol sip
D.
Router(config-dial-peer)#gateway protocol sip
21/09/11 11:23 AM
Review Questions
275
14. Which of the following commands configures SIP secure globally on a voice gateway? A. Router(config)#voice service voip Router(config-voi-serv)#sip Router(config-serv-sip)#udp sips B.
Router(config)#voice service voip Router(config-voi-serv)#sip Router(config-serv-sip)#sip secure
C.
Router(config)#voice service voip Router(config-voi-serv)#sip Router(config-serv-sip)#url sips
D.
Router(config)#voice service voip Router(config-voi-serv)#sip Router(config-serv-sip)#tcp sips
15. When configuring SRTP, what optional configuration step is not required but recommended to ensure interoperation with multiple SIP endpoints? A. Router(config-voi-serv)#session transport tcp B.
Router(config-voi-serv)#url sips
C.
Router(config-voi-serv)#timers expires 1000
D.
Router(config-voi-serv)#srtp fallback
16. Which of the following show commands is used to view SIP calls that are being made through the voice gateway in real time? A. show sip-ua connections B.
show sip connections
C.
show sip calls
D.
show sip-ua calls
17. Which three functions does MGCP handle? A. Send messages between the MGCP voice gateway and CUCM using SDP messages.
c07.indd 275
B.
Provide a separate channel for backhauling Q.931 traffic from the PSTN to the CUCM.
C.
Use communications messages between the MGCP and CUCM.
D.
Provide in-band signaling to backhaul Q.921 signaling between the PSTN and CUCM.
E.
Learn the location of target endpoints.
21/09/11 11:23 AM
Chapter 7
276
■
Configuring Voice Gateway Signaling Protocols
18. What MGCP configuration is operational by default when configuring an MGCP residential gateway? A. rtp-package B.
pre-package
C.
dtmf-package
D.
fxr-package
E.
line-package
19. You are reviewing a Cisco voice gateway configured with MGCP. You perform a show run and see the following two configuration commands: mgcp call agent 10.10.100.100 service-type mgcp ccm-manager mgcp Based on this, which of the following is true? A. This is an MGCP residential gateway. B.
The voice gateway connects to a CUCM.
C.
The voice gateway connects to a call agent that may or may not be a CUCM.
D.
This is an MGCP trunking gateway.
20. Which MGCP show command shows if MGCP is enabled and operationally active? A. show mgcp statistics
c07.indd 276
B.
show ccm-manager
C.
show mgcp profile
D.
show mgcp
21/09/11 11:23 AM
Answers to Review Questions
277
Answers to Review Questions 1.
C. When using H.323 slow start, H.323 must wait for the call setup, call proceeding, alerting, and connect stages to fi nish.
2.
D. MGCP lets the call agent (CUCM) handle dial-peer functions.
3.
A, D. H.245 exchanges information about capabilities such as encryption, flow control, and jitter data between H.323 endpoints. Additionally, the protocol is responsible for opening and closing media streams but is not responsible for the actual transport.
4.
D. The correct command to modify H.323 initiation is call start slow within conf-serv-h323 mode.
5.
B. H.323 fast start operates on devices that support H.323 version 2 or higher. If you have legacy equipment that does not support at least H.323 version 2, you must configure slow start initialization.
6.
C. The correct config-dial-peer command is voice-class codec 10. Also remember that codec preference commands can be used only on VoIP dial peers.
7.
B. While in config-if mode for the loopback interface, you must fi rst configure the correct IP address and then bind it to H.323 by issuing the h323-gateway voip bind srcaddr 172.16.3.1 command.
8.
B. The show h323 gateway h225 command displays H.323 call-control messages that are the responsibility of H.225. The details such as number of sent, received, and failed messages increment for H.225 requests such as setup, alert, and call proceeding.
9.
B. SDP messages are sent and received in ASCII format.
10. C. When SIP is configured for early offer, SDP messages are transported in invite messages from the initiating device to the target device. 11. D. SIP voice gateways terminate both ISDN Q.921 and Q.931 at the voice gateway interface so that signaling is transferred between the voice gateway and the PSTN. Q.931 signaling never reaches the CUCM when SIP is used for signaling. 12. B. SIP signals a calling phone when the called phone is busy or offl ine or the calling party does not answer (ring-no-answer). 13. A. By default, dial peers use H.323 signaling. This must be modified. The correct configdial-peer command to enable SIP on a dial peer is session protocol sipv2. 14. C. SIP secure (SIPS) encrypts SIP message transmissions. This feature can be enabled while in config-serv-sip mode by issuing the url sips command. 15. D. It is recommended that when you enable secure RTP, you also use the srtp fallback command so that the voice gateway falls back to using unencrypted RTP if an end device does not support it.
c07.indd 277
21/09/11 11:23 AM
278
Chapter 7
■
Configuring Voice Gateway Signaling Protocols
16. D. The show sip-ua calls command displays calls that are being made through the local voice gateway in real time. Information includes source and destination IP address, E.164 numbers, and codec(s) used. 17. A, B, C. MGCP is a client-server protocol. It uses special communications messages with the CUCM using SDP on UDP port 2427. 18. E. By default, line-package is operational on MGCP residential gateways. This package contains the signaling necessary to operate analog voice ports. 19. B. The fi rst command is used by both residential and trunking gateways, so you cannot determine if the router is a MGCP residential or trunking gateway. The ccm-manager mgcp command is only needed when the call agent is a Cisco UCM. 20. D. The show mgcp command shows the MGCP administrative and operational status on the fi rst line of the output.
c07.indd 278
21/09/11 11:23 AM
Answers to Written Lab 7.1
279
Answers to Written Lab 7.1 1.
Fast start
2.
no shutdown
3.
15
4.
session protocol sipv2
5.
User Agent (UA)
6.
Call transfers and disconnects
7.
show sip-ua status
8.
Q.931
9.
fxr-package
10. UDP 2427
c07.indd 279
21/09/11 11:23 AM
c07.indd 280
21/09/11 11:23 AM
Chapter
8
Configuring and Managing CUCM Express THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Implement Cisco Unified Communications Manager Express to support endpoints using CLI. ■
Describe the appropriate software components needed to support endpoints.
■
Configure DHCP, NTP, and TFTP.
■
Describe the differences between the different types of ephones and ephone-dns.
■
Configure Cisco Unified Communications Manager Express endpoints.
c08.indd 281
9/21/11 11:24:35 AM
The new CVOICE 8.0 exam requires that test candidates understand how to configure a basic voice network using a Cisco Unified Communications Manager Express router. In addition, the candidate must understand the infrastructure required to support IP endpoints. This chapter covers the current options for powering IP phones on a network, and it shows how to configure VLAN trunks and VLAN voice access ports and network infrastructure services that support voice, including DHCP, NTP, and TFTP. The remainder of the chapter covers using the CUCM Express IOS command-line software to configure and verify voice settings and operational status for both the SCCP and SIP protocols.
Voice Network Infrastructure Considerations There are several network infrastructure factors that you must consider when implementing a CUCM Express or any voice system over an IP network. In this section we will cover IP phone power options, voice VLAN configurations, and network services such as DHCP and NTP that support the use of voice on a network.
Power Options for IP Phones Cisco IP phones, being much more than simple analog telephones of old, require a power source to operate. Currently there are three ways of providing power to Cisco IP phones:
Power brick
Powered patch panel/power injector
Power over Ethernet (PoE) switch Let’s briefly review each of these IP phone power methods.
Power Brick The power brick is the simplest to understand. It connects to a power port on the back of the phone and plugs into a standard 110v AC wall outlet. You then connect a Category 5 or higher Ethernet cable into a switch to provide network connectivity.
c08.indd 282
9/21/11 11:24:37 AM
Voice Network Infrastructure Considerations
283
The power brick option may be useful in situations where you will use only a handful of phones. Otherwise, you may want to investigate a PoE option, because it can be more cost effective and, quite simply, it’s nicer to combine power and Ethernet in one cable to eliminate the need for a second connection to the phone.
Powered Patch Panel/Power Injector A second power option is to have a device that sits between your IP phone and switch (which is not PoE capable). This is known as a midspan method, because the power sits in the middle of the connection. A powered patch panel can terminate nonpowered Ethernet on one end and a powered Ethernet termination point on the other. These patch panels allow the power to be connected back at the wiring closet, so no power brick is required and the phone receives both power and Ethernet over a single Category 5 or 6 Ethernet cable. You can also purchase a Cisco power injector. These devices provide the same midspan “sit-in-the-middle” power function as the powered patch panel but only for a single phone per injector.
Power over Ethernet Switch The most streamlined and efficient method of providing power to phones (and other PoE-capable devices) is the Power over Ethernet (PoE) switch. The switch is responsible for detecting and outputting the required power on each switchport. By adding PoE functionality to the switch, you have fewer devices that need UPS protection in the event of a power outage. There are a couple of “gotchas” that you need to be aware of when powering Cisco phones with any PoE option. The fi rst is to be sure of the type of inline power and quantity that the phone supports. The second thing to watch out for is ensuring that your switch can properly handle the power load. Let’s look fi rst at the two inline power methods for Cisco switches and then at switch power capacities.
Inline Power Method 1: Cisco Inline Power In its typical fashion, Cisco began offering a proprietary inline-power option to customers before an open standard was available. In early 2000, Cisco began selling Catalyst switches with the proprietary inline power (ILP) functionality. ILP uses RJ-45 pins 1, 2, 3, and 6 to provide power to the phones. Using the same wiring that Ethernet uses to transmit and receive is called phantom power. Cisco’s proprietary inline power provides a fi xed 6.3W of power to any device that requires it. ILP detects a capable device by sending a very-low-voltage AC signal across the transmit pairs and expects to receive the same signal back on the receive pairs. This is because the ILP-capable phones have a low-pass fi lter that bridges the specific voltage signal from TX to RX. Once the switch receives the voltage back on the receive pair, it knows that the device requires power and sends the 6.3W on that specific switchport.
c08.indd 283
9/21/11 11:24:38 AM
284
Chapter 8
■
Configuring and Managing CUCM Express
Inline Power Method 2: Cisco IEEE 802.3af In mid-2003 the IETF released the 802.3af PoE standard. This became the de facto standard for powering Ethernet over 10/100 and 1000Base-T. The standard states that power can be sent across the Category 5/6 cabling either on an active transmit/receive pair or over the inactive pairs for 10/100Base-T. 1000Base-T has the requirement of using either pins 1, 2, 3, and 6; or 4, 5, 7, and 8 for power. Cisco uses pins 1, 2, 3, and 6 on its 802.3af-supported PoE switches. The 802.3af standard handles endpoint detection using a different method than ILP. It uses a low-power DC signal sent across a copper pair. Just as in ILP, the voltage is looped back to the switch by a slightly more advanced fi lter to signal that the end device is capable of receiving power. Unlike ILP, 802.3af has five different classes of power that it can transmit. It knows the power level the end device requires by the voltage strength that it receives back during the detection phase. Table 8.1 lists the 802.3af power classifications. TA B L E 8 .1
IEEE 802.3af classifications
Class
Usage
Min Power Level at the Switch (in Watts)
Max Power Levels at the Device (in Watts)
0
Default
15.4
0.44–12.95
1
Optional
4.0
0.44–3.84
2
Optional
7.0
3.84–6.49
3
Optional
15.4
6.49–12.95
4
Reserved for future use
N/A
N/A
Class 0 is the default class and allocates a full 15.4W of power to any device that falls into the category. This class is for devices whose vendor did not choose to implement a power classification. You’ll commonly fi nd this in inexpensive PoE products. Moving up, a device that declares itself as class 1 will have a max power requirement level between 0.44W and 3.84W. The switch allocates 4.0W of power for these devices. Class 2 allocates 7.0W for devices requiring a maximum power level of 3.84W to 6.49W. Class 3 is for any device that requires 6.49W to 12.95W, and the switch allocates 15.4W of power. Class 4 is not currently in use but was set aside so an additional power level can be added in the future.
Cisco Inline Power Switch Backward Compatibility Because Cisco jumped the gun a few years early with its pre-standard ILP, it now faces the need to support the newer 802.3af as well as its own proprietary ILP standard on its
c08.indd 284
9/21/11 11:24:38 AM
Voice Network Infrastructure Considerations
285
Catalyst line of PoE switches. The methods of power detection are fairly different between ILP and 802.3af, and Cisco has come up with a method that allows its switches to detect the power requirements of Cisco phones. Here are the steps the PoE switch goes through for powering Cisco IP phones: 1.
The switch detects that the IP phone is PoE capable and sends the ILP power amount of 6.3W.
2.
If the phone is only capable of using the ILP proprietary inline-power method, the phone boots normally and the process ends. If the phone uses the 802.3af power method, the phone will boot into “low-power mode” using the 6.3W of power provided to it on the port.
3.
Once the phone boots into low-power mode, it exchanges Cisco Discovery Protocol (CDP) messages with the switch and negotiates which 802.3af class the phone should reside in. CDP is a Cisco proprietary Layer 2 messaging protocol that is commonly used between Cisco devices to determine who their neighbor is and what their capabilities are.
4.
When the negotiation process is complete, the switch provides the necessary power to fully boot the IP phone.
CDP must be enabled on both the switch and switchport for it to negotiate power with Cisco PoE endpoints. If CDP is disabled, the switch will have no choice but to allocate the maximum amount of power for the 802.3af class the device belongs to.
Cisco PoE Intelligent Power Management Depending on the types of endpoints you deploy and the type of switch and power supply used, you need to be aware that you can eventually exhaust the amount of power available to the switch. If you add too many PoE phones to a switchport, the switch may have allocated all the available power, so that your device will not receive the necessary electricity to power the phone. There is also the fact that the 802.3af classification system can often set aside more power than is necessary, which can unnecessarily limit the number of PoE devices that can be powered. That is why Cisco offers multiple configurable modes on its PoE-capable switches. This is known as Intelligent Power Management (IPM). This section shows how to configure IPM modes. The power inline IOS commands allow you to change PoE settings on a port-by-port basis. Let’s look at the PoE interface commands available to us: 4506-switch(config-if)#power inline ? auto Automatically detect and power inline devices never Never apply inline power static High priority inline power interface
c08.indd 285
9/21/11 11:24:39 AM
286
Chapter 8
■
Configuring and Managing CUCM Express
The auto setting is the default. If the endpoint is a Cisco device such as a Cisco 7965 IP phone, the power settings will be negotiated automatically. To prove this, let’s look at a show power inline command output on the 4500 switch: 4506-switch#show power inline gigabitEthernet 3/2 Interface Admin Oper Power(Watts) Device Class From PS To Device --------- ------ ---------- ---------- ---------- ------------------- ----Gi3/2
auto
on
13.5
12.0
Cisco IP Phone 7965 3
Interface
AdminPowerMax (Watts) ---------- --------------Gi3/2
15.4
You can see that the Admin setting is set to auto. Using CDP, the switch detected the Cisco 7965 phone. The switch placed it into 802.3af power settings as a class 3 device and thus allocated 15.4W of power to it. However, the switch went one step further and dropped the power output to the device to 12.0W. You can use the never option if you choose to not provide any power on that specific port. Finally, the static option can be useful if you have non-Cisco phones that you know use only a specific amount of power. This helps with power budgeting and reduction of surprises.
Configuring VLANs and Voice VLANs CVOICE candidates should have a thorough understanding of VLANs and the benefits they provide for devices on a network. Those benefits include limiting broadcast messages, improved security, and logical segmentation based on business processes. These benefits can be extended into the VoIP realm as well. Because CVOICE candidates must know how to install and configure CUCM Express endpoints on an IP network, we will review VLAN trunking and how to assign both voice and data VLANs to access-layer ports.
Configuring VLAN Trunks Let’s take a very simple network example that has two VLANs. VLAN 10 is the Sales VLAN and VLAN 20 is the Marketing VLAN. Our network consists of two Cisco switches that are connected through a single Fast Ethernet port. What if you have Sales and Marketing employees connected to multiple switches, but you would like them to reside in the same logical VLAN? The solution to this problem is to use the link connecting the two switches as a VLAN trunk port. Figure 8.1 shows our new network topology with two switches that have VLANs 10 and 20 trunked between them.
c08.indd 286
9/21/11 11:24:39 AM
Voice Network Infrastructure Considerations
F I G U R E 8 .1
287
A VLAN trunk
Fa0/1 Switch A
Trunk VLAN 10 and 20
Fa0/1
Switch B
VLAN 10
VLAN 20
A trunk port is a link between two Layer 2 switches that can transport traffic from multiple VLANs. It keeps the traffic between the VLANs separate by tagging each frame. VLAN tagging essentially places a VLAN identifier on each frame. In our example, frames on VLAN 10 that need to go from one switch to the other are tagged as belonging to VLAN 10. By far the most common trunk method is 802.1Q, which is what we will implement in detail here. Using Figure 8.1 as our example, let’s configure a trunk link between switches A and B using the 802.1Q trunking protocol on port Fa0/1. For simplicity’s sake, we will assume that both switch A and switch B have been identically configured to switches VLAN 10 and 20. Configuring an 802.1Q trunk between the switches requires the following steps.
c08.indd 287
9/21/11 11:24:40 AM
288
Chapter 8
■
Configuring and Managing CUCM Express
Step 1: Configure the Trunk Encapsulation Type The fi rst step is to set the encapsulation type for the trunk interface. The command for configuring trunk encapsulation is: switchport trunk encapsulation [dot1q|isl]
Step 2: Configure the Trunk Mode There are several options for the trunk’s operational mode, including dynamic desirable and dynamic auto. But since we know we want to configure the port as a trunk, we can simply hard-code the port using the switchport mode trunk command. Let’s configure Switch-A and Switch-B for trunking on port Fa0/1. Here is the configuration for Switch-A: Switch-A#configure terminal Switch-A(config)#interface fa0/1 Switch-A(config-if)#switchport trunk encapsulation dot1q Switch-A(config-if)#switchport mode trunk Switch-A(config-if)#end
Here is the configuration for Switch-B: Switch-B#configure terminal Switch-B(config)#interface fa0/1 Switch-B(config-if)#switchport trunk encapsulation dot1q Switch-B(config-if)#switchport mode trunk Switch-B(config-if)#end
So now we have a two-switch network with two VLANs that are properly trunked together. A Sales department user on a PC on Switch-A, VLAN 10, can communicate with another Sales department user attached to Switch-B on VLAN 10. The same is true for the Marketing department users on VLAN 20. While it is true that users on VLAN 10 of Switch-A can communicate with users on VLAN 10 of Switch-B, users on VLAN 10 cannot communicate with any users on VLAN 20 or vice versa. Layer 3 routing is required to perform this functionality. This topic is outside the scope of the CVOICE exam and has not been included in this study guide.
Configuring and Verifying Voice VLANs Many Cisco mid- and high-range phones such as the 7945G give users the ability to plug a PC into an Ethernet port on the phone to provide network connectivity. The phone essentially becomes a three-port switch at that point. One port (port 0) connects the phone to the accesslayer switch, the second virtual port (port 1) is for voice traffic to the phone, and the third port (port 2) is to connect to a PC for standard data transport. Figure 8.2 shows how a PC is plugged directly into the phone, which is essentially trunked with both a voice and a data VLAN.
c08.indd 288
9/21/11 11:24:40 AM
Voice Network Infrastructure Considerations
FIGURE 8.2
289
A Cisco IP phone switch PC Cisco phone
Switch Fa0/5
Trunk link
Voice VLAN Data VLAN
As you can see, the connection between the switch and the Cisco phone is an 802.1Q trunk link. It is necessary to have a trunk because we have our voice and data separated on two different VLANs. When configuring the trunk on the switchport that connects to the phone, we use a slightly different method. The Cisco IOS has a unique method to identify a VLAN specifically as a voice VLAN. In all actuality, this trunk link between our switch and the Cisco phone is not a full-fledged 802.1Q trunk like those we have practiced configuring between two switches and a switch and router. Instead, the Cisco switch and Cisco IP phone use CDP to implement this quasi-trunk. The VLAN that is configured as the voice VLAN is marked with an 802.1Q tag, while the data VLAN is considered to be the native VLAN and is left unmarked. This trunk is capable of handling only two VLANs—one tagged VLAN for voice and one untagged VLAN for data. It used to be that the trunk link between the access switch and Cisco IP phone was indeed a full-blown 802.1Q trunk. Unfortunately, it was easy to fool this setup, and PCs could easily join the voice VLAN and use sniffers to collect and re-create voice calls. Because the new quasi-trunk setup uses CDP to identify which devices can join the voice VLAN, the new method is much more secure. But the 802.1Q trunks to phones are still used when third-party phones make use of built-in switch functionality but cannot use Cisco’s CDP messaging protocol. You also may run into installations with older Cisco equipment (such as the NM-16ESW) that cannot use voice VLANs and instead must rely on 802.1Q trunks.
With that understanding of the voice VLAN, let’s go back to our two-switch network with data VLANs 10 and 20 and say we have configured a new VLAN (VLAN 100) for voice. We attach an IP phone to port fa0/5. We then need to configure the port to access our new voice VLAN (using the switchport voice vlan command) and the Sales VLAN to the Cisco phone according to Figure 8.2. With this information, we can configure the switchport to quasi-trunk our voice and data VLANs to our Cisco IP phone: Switch#configure terminal Switch(config)#interface fa0/5 Switch(config-if)#switchport voice vlan 100 Switch(config-if)#switchport access vlan 10 Switch(config-if)#end
c08.indd 289
9/21/11 11:24:41 AM
290
Chapter 8
■
Configuring and Managing CUCM Express
To verify, we can run the show vlan brief command to ensure that our port fa0/5 is in both VLAN 10 and VLAN 100: Switch#sh vlan brief VLAN ---1 10
Name -------------------------------default Sales
Status --------active active
20
Marketing
active
30 Management 100 Voice 1002 fddi-default 1003 trcrf-default 1004 fddinet-default 1005 trbrf-default Switch#
Ports ------------------------------Gi0/1, Gi0/2 Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/13, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/20 Fa0/21, Fa0/22, Fa0/23, Fa0/24 Fa0/25, Fa0/26, Fa0/27, Fa0/28 Fa0/29, Fa0/30, Fa0/31, Fa0/32 Fa0/33, Fa0/34, Fa0/35, Fa0/36 Fa0/37, Fa0/38, Fa0/39, Fa0/40 Fa0/41, Fa0/42, Fa0/43, Fa0/44 Fa0/45, Fa0/46, Fa0/47, Fa0/48
active active Fa0/5 act/unsup act/unsup act/unsup act/unsup
Sure enough, port Fa0/5 belongs to both the Sales (VLAN 10) and Voice (VLAN 100) VLANs.
Network Infrastructure Services for VoIP Support A CUCM Express or other Cisco Layer 3 device such as a router or multilayer switch can be configured to provide Dynamic Host Control Protocol (DHCP) services to your phones to assign IP addresses and other network information to the phones dynamically. One of these devices can also serve as a centralized point for synchronizing your UC equipment clocks by being the Network Time Protocol (NTP) point of reference. Let’s look at how we configure both of these network services for our voice network.
Configuring DHCP for Voice Functionality DHCP allows an endpoint device (such as a Cisco IP phone) to boot up on the network and request network information, which it dynamically receives from a DHCP server. This section will show you how to configure DHCP on your CME router for your end devices.
c08.indd 290
9/21/11 11:24:42 AM
Voice Network Infrastructure Considerations
291
DHCP server functionality is considered to be a service on your IOS router and is enabled by default on IOS versions 12.0(1)T and later. The fi rst step in your DHCP server configuration process is to ensure that specific IP addresses on your network are never handed out to endpoints. IPs such as default gateways and other static interfaces that are already in use must be specifically excluded. To do this, you use the ip dhcp excluded address command followed by the beginning and ending IP addresses you wish to exclude. In our example, we will exclude the fi rst 20 addresses of the pool. The next step is to actually create our DHCP pool and give it a name using the ip dhcp pool command. The following shows how we defi ne a pool and exclude specific addresses: Router# configure terminal Router(config)# ip dhcp excluded-address 192.168.100.1 192.168.100.20 Router(config)# ip dhcp pool voip-pool Router(dhcp-config)#
As soon as you give a name to your DHCP pool, you are placed into dhcp-config configuration mode. This is where you actually create your IP scope with the network command and any additional DHCP information you want to give to the endpoints. Following are the common parameters for endpoints.
Default-router This parameter is mandatory for all endpoints. It tells the endpoint what IP address it should use for its default-gateway.
Domain-name Specifies the domain name you want your endpoints to use.
DNS-server Informs the endpoints about the IP addresses of their DNS servers for name resolution. You can specify up to eight DNS servers with a single command.
Lease This command allows you to specify how long an endpoint is to maintain the dynamically assigned IP address. You can specify the number of days, hours, minutes, or even if it can maintain the address infi nitely.
Option Another critical parameter that you will want to configure when setting up DHCP for your Cisco IP phones is the IP address of the TFTP server where the Cisco phone configuration files are located. All Cisco phones (SIP and SCCP) must download a configuration file when they first boot. This file contains important information required for the phone to function properly with the CUCM Express. The IP phones must know the location of the TFTP server so they can request the configuration file. The DHCP option command is followed by a specific numeric parameter for the additional DHCP information you wish to send to endpoints. In the case of TFTP, that parameter number is 150. You can then specify the IP address or domain name of the TFTP server.
c08.indd 291
9/21/11 11:24:42 AM
292
Chapter 8
■
Configuring and Managing CUCM Express
Here is an example of DHCP configuration parameters, using the following information:
Network: 192.168.100.0/24
Default router: 192.168.100.1
Domain name: ccnavoice1.com
DNS server: 192.168.10.5
TFTP server: 192.168.100.10
Lease time: 6 hours
Router(dhcp-config)#network 192.168.100.0 255.255.255.0 Router(dhcp-config)#default-router 192.168.100.1 Router(dhcp-config)#domain-name ccnavoice1.com Router(dhcp-config)#dns-server 192.168.10.5 Router(dhcp-config)#option 150 ip 192.168.100.10 Router(dhcp-config)#lease 0 6 0 Router(dhcp-config)#end
Once those configuration steps are complete, when an IP phone configured on the correct voice VLAN boots, it will request an IP address from the DHCP server. Our DHCP server will return an IP address, default gateway, DNS server, and TFTP server along with a lease time of 6 hours for the information to be valid for the phone. On large networks with multiple VLANs, there typically is a server (or cluster of servers for redundancy) that is responsible for all DHCP requests on a network. Because DHCP clients use broadcasts to attempt to find the DHCP server, it would be necessary to configure a DHCP server on each and every VLAN that required DHCP services. Obviously, this does not scale well. Instead, we can use the ip-helper address command followed by the IP address of the remote DHCP server. The command is configured on Layer 3 interfaces such as a router interface or switched virtual interface on a multilayer switch. This is known as DHCP relay. This command enables the Layer 3 interface to listen for DHCP broadcast requests and send a separate broadcast message to the DHCP server identified. When the DHCP server replies to the Layer 3 interface, the router/multilayer switch then relays that information onto the original requestor.
Monitoring and Troubleshooting the DHCP Service You can monitor your DHCP service with the following useful show commands:
show ip dhcp binding Use this command to display the dynamic IP-to-MAC address mappings. It also lets you know when a specific lease will expire. The following example shows the binding for the DHCP leased IP address 192.168.100.101:
c08.indd 292
9/21/11 11:24:42 AM
An Overview of CUCM Express
293
Router# show ip dhcp binding 192.168.100.101 IP address Hardware address 192.168.100.101 00a0.9802.32de
Lease expiration Mar 01 2009 12:00 AM
Type Automatic
show ip dhcp conflict This command lists any IP address confl icts and the time the detection occurred. It also indicates the method of conflict detection. The next example shows a confl ict for the IP 192.168.100.101: Router# show ip dhcp conflict IP address 192.168.100.101
Detection Method Ping
Detection time Mar 01 2009 12:28 PM
Configuring the Network Time Protocol NTP should be configured on every single piece of network equipment in a production network. It is very important to have synchronized times for all of your logging information. It is good practice to specify two devices on a network that have access to a public time source from the National Institute of Standards and Technology (NIST). Keep in mind that NTP runs over UDP port 123, so make sure you have this port opened on your fi rewall rule-set to allow access. The configuration of a time source on a Cisco IOS device is quite simple. This configuration is used to point your CUCM Express at a designated NTP server that resides on your network. First, you should specify the time zone that your local equipment resides in, using the clock timezone command. Next, you issue the command ntp server and specify an IP address of one of the public time servers. Then all of your other network devices can be configured to peer with the device receiving an external clock. For example, here’s the configuration of a router for an external NTP server that uses the external time source IP of 192.5.41.41: Router#configure terminal Router(config)#clock timezone CHICAGO -6 Router(config)#ntp server 192.5.41.41 Router(config)#end
An Overview of CUCM Express CUCM Express is a unique offering from Cisco. Instead of the server- and Linux-based solutions of the CUCM and CUCM Business Edition platforms, CUCM Express runs on a specialized version of IOS software and Cisco ISR hardware. The ability to have a fully functioning router, voice system, and optional voicemail messaging system in a
c08.indd 293
9/21/11 11:24:43 AM
Chapter 8
294
■
Configuring and Managing CUCM Express
single device greatly appeals to small businesses and branch offices that wish to limit the amount of hardware and administration duties. This section will cover the primary voice capabilities found in CUCM Express along with its supported hardware and maximum number of IP phones. Lastly, we will look at the software licenses required to legally operate CUCM Express.
Understanding CUCM Express Capabilities Cisco Unified Communications Manager Express is geared toward small and medium-size environments. CUCM Express combines all of the following IOS software capabilities into a signally managed device:
Call processing agent
Call setup and routing
Dial plan administration
Phone feature administration
Telephone directory services
Services such as music on hold (MOH), paging, intercom, hunt groups, interactive voice response (IVR), and call detail records (CDR)
Voice gateway
Translation between PSTN and IP networks, transcoding, and compression
Ability to provide SRST
Direct termination of PSTN ports
DSP service capabilities
Optional voicemail
A Unity Express voicemail module can be installed directly into the router, providing voicemail services
CUCM Express can be managed either by using the command-line interface (CLI) or through an optional web-based GUI.
For internal IP-to-IP voice calls, CUCM Express uses the concept of virtual dial peers instead of the static dial peers that we are accustomed to configuring on voice gateways. These virtual dial peers are created automatically as we defi ne telephones and directory numbers. You will learn how to configure IP phones in a CUCM Express environment later in this chapter. CUCM Express can support a wide range of Cisco and third-party vendor phones and common voice codecs as IP voice endpoints, including G.711, G.729, and iLBC. CUCM Express supports SCCP and SIP signaling protocols to end devices. In addition, if you are operating Cisco IP phones in SIP mode, CUCM Express can offer additional voice features
c08.indd 294
9/21/11 11:24:43 AM
An Overview of CUCM Express
295
that are not typically found in generic SIP environments. The features available depend on the Cisco phone model being used.
Understanding CUCM Express Hardware Requirements From a hardware perspective, CUCM Express has the capability to support up to 450 IP phones on a single-system deployment. A multisite deployment design can also be implemented by interconnecting multiple CUCM Express systems using a signaling protocol such as H.323. The maximum number of supported IP phones depends on the CUCM Express ISR hardware model, as shown in Table 8.2.
TA B L E 8 . 2
c08.indd 295
IP phones supported by ISR and ISR G2 CUCM Express
Router Model
Maximum Supported IP Phones
1861 ISR
15
2801 ISR
25
2811 ISR
35
2901 ISR G2
35
2821 ISR
50
2911 ISR G2
50
2851 ISR
100
2921 ISR G2
100
2951 ISR G2
150
3825 ISR
175
3845 ISR
250
3925 ISR G2
250
3945 ISR G2
350
3925E ISR G2
400
3945E ISR G2
450
9/21/11 11:24:44 AM
Chapter 8
296
■
Configuring and Managing CUCM Express
Understanding CUCM Express Software Licensing One of the more complex tasks required when ordering Cisco voice equipment is the way Cisco handles licensing structures. There are three Cisco licenses needed to run your CUCM Express system and Cisco phones on your network:
Cisco IOS license for voice capabilities
CUCM Express feature license
Individual user licenses for the total number of Cisco phones
In this section we’ll review each of these so you can properly license and run a CUCM Express system and Cisco IP phones.
IOS Licenses for Voice The fi rst license allows you to download and operate a version of Cisco IOS that has CUCM Express functionality. When you purchase a router, it comes with an IOS feature set with which it can run the router. It also allows you to download and install new versions of this IOS feature set when they become available.
CUCM Express Feature Licenses Just because you own the license to run the voice-capable IOS image doesn’t mean you can start adding Cisco IP phones! The second license you need is the CUCM Express feature license. This license determines how many phones you can run on the CUCM Express. It is sold in bundles; the smallest bundle is for 25 Cisco IP phones. Table 8.3 shows the current CUCM Express feature license bundles available.
TA B L E 8 . 3
c08.indd 296
CUCM Express 7965 feature license bundles
License
Description
FL-CCME-250
CUCM Express support for up to 250 IP phones
FL-CCME-175
CUCM Express support for up to 175 IP phones
FL-CCME-100
CUCM Express support for up to 100 IP phones
FL-CCME-50
CUCM Express support for up to 50 IP phones
FL-CCME-35
CUCM Express support for up to 35 IP phones
FL-CCME-25
CUCM Express support for up to 25 IP phones
9/21/11 11:24:44 AM
Initial CUCM Express Configuration
297
Cisco Phone User Licenses Finally, you need the Cisco phone user license. When you place an order for Cisco phones, you are given license options for each Cisco phone. For example, Table 8.4 lists the part numbers and descriptions for the 7965G phone. TA B L E 8 . 4
Cisco IP phone part numbers
Part Number
Description
CP-7965G=
Spare phone w/o license
CP-7965G-CH1
Phone w/ CUCM user license
CP-7965G-CCME
Phone w/ CUCM Express user license
As you can see, you are given several ordering choices for a single phone! The CP7965G= is simply a spare phone. It does not come with a license. These are most commonly purchased to serve as “cold spares” at businesses. If a licensed phone on the network were to break, it could be replaced with the unlicensed spare as a one-to-one trade. These unlicensed phones are less expensive but can be used only as replacements. The other two license options are for either the CUCM/CUCMBE or the CUCM Express call-processing systems. The pricing is slightly different for these two parts. The CH1 licenses are more expensive than the CCME licenses, but the CH1 licenses can legitimately be used by the larger CUCM system. By contrast, the CCME licenses cannot be used for the CUCM/CUCMBE systems. So if you think you may upgrade from a CUCM Express system to one of the bigger CUCM systems, you may want to go ahead and purchase the CH1 licenses so you won’t have to purchase phone user licenses twice.
New Software-Activated Voice Licensing With the Cisco Generation 2 ISR platforms, there will soon be a new licensing approach that uses a software activation process to license voice package options. The various voice licenses can be purchased in bundles for different voice network sizes. The licenses are activated and enforced within the IOS software. Additional licenses can easily be purchased and added to the currently activated licenses. Also, if you currently have the older “right-to-use” licenses, don’t despair because they will be fully transferrable to the new licensing structure. At the time of this writing, the new software activation method is not yet operational, but be on the lookout for it soon!
Initial CUCM Express Configuration Cisco IP phones rely on external sources to receive information such as the fi rmware and configuration fi les. This section details the fi les that the phones require and how to
c08.indd 297
9/21/11 11:24:45 AM
298
Chapter 8
■
Configuring and Managing CUCM Express
configure them on the CUCM Express router. First, you will see how to turn CUCM Express into a TFTP server to offer up specific Cisco phone fi rmware fi les. Then we’ll move on to the four mandatory CUCM Express system configurations needed to support IP phones. Finally, you will see how to configure and generate individual phone configuration fi les to allow each Cisco phone to have unique functionality within the voice system. After all these steps are completed, your Cisco phone can successfully connect to its host CUCM Express and use the information gathered to function as a VoIP phone.
Configuring CUCM Express as a TFTP Server When a Cisco IP phone initially powers up, it will use CDP to determine the voice VLAN it should belong to and then request and receive, at a minimum, an IP address/subnet mask and gateway IP address via DHCP. It also must have the all-important option 150 IP address, which is the location of the TFTP server. As you’ve already learned, for voice the TFTP server is responsible for delivering Cisco phone fi rmware and configuration fi les to the phones when requested. The TFTP server can be located anywhere on your network, but in smaller environments, the CUCM Express router is configured for TFTP. This is the fi rst server the IP phone gets its information from. One group of fi les that our Cisco IP phone will request is its fi rmware, which is specifically tailored to the type of Cisco phone hardware. If you are using your CUCM Express router to handle TFTP server functionality, you must configure the IOS to serve up the fi rmware that your phones will request. All you need to do is figure out what Cisco phones you will want to allow on your network and then configure the router to serve the appropriate files. You can see all of the fi rmware fi le directories by issuing the dir flash:/phone command: Directory of flash:/phone/ 47 drw56 drw58 drw60 drw69 drw71 drw79 drw88 drw96 drw101 drw110 drw118 drw511664128 bytes total
0 Apr 7 2009 18:18:28 0 Apr 7 2009 18:18:56 0 Apr 7 2009 18:19:24 0 Apr 7 2009 18:19:26 0 Apr 7 2009 18:19:52 0 Apr 7 2009 18:19:58 0 Apr 7 2009 18:20:24 0 Apr 7 2009 18:28:46 0 Apr 7 2009 18:29:30 0 Apr 7 2009 18:29:38 0 Apr 7 2009 18:30:06 0 Apr 7 2009 18:30:34 (395001856 bytes free)
+00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00
7945-7965 7937 7914 7906-7911 7920 7931 7942-7962 7921 7940-7960 7970-7971 7975 7941-7961
Let’s assume that we are going to be configuring Cisco 7945 and 7965 phones in our environment. Therefore, we need to configure our TFTP server to offer all of the fi les
c08.indd 298
9/21/11 11:24:46 AM
Initial CUCM Express Configuration
299
within the flash:/phone/7945-7965 directory. Notice that some of the fi rmware fi les work for multiple phones, including the fi rmware for the 7945 and 7965. Configuring the CUCM Express router to serve as a TFTP server for the fi rmware fi les is quite simple. Each fi le needs to have its own tftp-server flash:/phone/ command. Also note that because our CUCM Express fi les are organized with a directory structure, we must provide a directory alias for the Cisco phones. Cisco phones are unintelligent devices for the most part. They know only the name of the firmware fi les but not where they are located. Because our CUCM Express phone fi rmware software is organized into directories, we must create aliases so that when the Cisco phone asks for a fi le, it knows in which subdirectory the fi le is located. We can look at all of the 7945-7965 phone fi rmware fi les inside the directory by issuing the dir flash:/phone/7945-7965 command: Router#dir flash:/phone/7945-7965 Directory of flash:/phone/7945-7965/ 48 49 50 51 52 53 54 55
-rw-rw-rw-rw-rw-rw-rw-rw-
2496963 585536 2453202 326315 555406 638 642 642
Apr Apr Apr Apr Apr Apr Apr Apr
7 7 7 7 7 7 7 7
2009 2009 2009 2009 2009 2009 2009 2009
18:26:30 18:26:34 18:26:44 18:26:46 18:26:48 18:26:50 18:26:50 18:26:52
+00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00 +00:00
apps45.8-5-3S.sbn cnu45.8-5-3S.sbn cvm45sccp.8-5-3S.sbn dsp45.8-5-3S.sbn jar45sccp.8-5-3S.sbn SCCP45.8-5-3S.loads term45.default.loads term65.default.loads
These phones will need all eight fi les to function properly using SCCP. If you are going to run the phones in SIP mode, you need to install the necessary SIP fi rmware fi les. To offer these fi les up for downloading to the phones, you need to configure the following: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#tftp-server flash:/phone/7945-7965/apps45.8-5-3S.sbn alias apps45.8-5-3S.sbn Router(config)#tftp-server flash:/phone/7945-7965/cnu45.8-5-3S.sbn alias cnu45.8-5-3S.sbn Router(config)#tftp-server flash:/phone/7945-7965/cvm45sccp.8-5-3S.sbn alias cvm45sccp.8-5-3S.sbn Router(config)#tftp-server flash:/phone/7945-7965/dsp45.8-5-3S.sbn alias dsp45.8-5-3S.sbn Router(config)#tftp-server flash:/phone/7945-7965/jar45sccp.8-5-3S.sbn alias jar45sccp.8-5-3S.sbn Router(config)#tftp-server flash:/phone/7945-7965/SCCP45.8-5-3S.loads alias SCCP45.8-5-3S.loads
c08.indd 299
9/21/11 11:24:46 AM
300
Chapter 8
■
Configuring and Managing CUCM Express
Router(config)#tftp-server flash:/phone/7945-7965/term45.default.loads alias term45.default.loads Router(config)#tftp-server flash:/phone/7945-7965/term65.default.loads alias term65.default.loads Router(config)#
At this point, if you were to add one of these phones to your network, it would receive all the necessary IP information and download the phone fi rmware fi les from the TFTP server. The phone will not register to CUCM Express, however. It is still missing vital configurations that must be set up on CUCM Express for the registration process to occur. The next few sections of this chapter show how to configure CUCM Express to allow Cisco phones to work with the call processor, and how to identify and serve up default configuration fi les to your Cisco IP phones. First you’ll see how to configure SCCP signaling, and then you’ll explore the differences when configuring SIP signaling between the CUCM Express and IP phones.
Configuring the Mandatory CUCM Express System Settings Using SCCP Signaling The majority of CUCM Express configuration tuning happens while in config-telephony configuration mode. There are four configuration steps that must be accomplished to get the system to properly register phones for call processing using SCCP signaling: 1.
Configure the source IP address for CUCM Express.
2.
Configure the maximum number of ephones and ephone-DNs (directory numbers) allowed on the CUCM Express.
3.
Identify and set the fi rmware load fi les that Cisco IP phones should request based on the Cisco phone model.
4.
Generate and serve up default phone configuration fi les via TFTP to the Cisco IP phones. Here’s a detailed look at each of these steps:
Step 1: Configure the Source CUCM Express IP Address The source IP address defi nes the location of the CUCM Express call-processing agent. All of the Cisco IP phones on the network will use this address for all communications with the CUCM Express hardware. After a Cisco phone downloads the correct fi rmware used via TFTP, it requests and receives generic information about CUCM Express. One item is the source IP address where CUCM Express can be found. In the example shown in Figure 8.3, we’ll assume that all of our IP phones reside on the voice VLAN of 192.168.10.0/24.
c08.indd 300
9/21/11 11:24:46 AM
Initial CUCM Express Configuration
FIGURE 8.3
301
A sample CUCM Express network
Telephony source IP: 192.168.10.1
CUCM Express
Trunk VLAN 1 and 10
Switch
Cisco phone Voice VLAN 10 192.168.10.0/24 Cisco phone Cisco phone
Data VLAN 1 192.168.1.0/24
We’re going to use the 192.168.10.1 IP address as our source IP for the CUCM Express. The configuration of the CUCM Express source IP address is as follows: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#ip source-address 192.168.10.1 Router(config-telephony)#end Router#
You’ll see later how this information is eventually packaged within a default configuration fi le and sent to all Cisco IP phones on the network.
Step 2: Configure Max Ephones and DNs Step 2 of our CUCM Express system configuration involves setting the maximum number of ephones and ephone-DNs. Ephones represent physical phones. They are the way you identify a particular device within the IOS. Ephone-DNs, by contrast, are the telephone
c08.indd 301
9/21/11 11:24:47 AM
302
Chapter 8
■
Configuring and Managing CUCM Express
number extensions configured on each phone. Figure 8.4 shows a Cisco phone with buttons for multiple ephone-DNs. This particular Cisco phone has buttons to handle up to eight ephone-DNs. FIGURE 8.4
Cisco IP phone extension buttons
By default, the maximum number of both ephones and ephone-DNs is 0. You might wonder why Cisco sets the defaults to 0 if you still have to set them to 1 or more to get a single phone to work. The answer has to do with memory allocation. When a maximum number of ephones and ephone DNs is set, the router sets aside memory for each one. For example, if you set max-ephones to 10 and max-dn to 50, the router allocates memory for each of the 10 ephones and all 50 ephone-DNs regardless of whether you actually use them or not. Keep this in mind, because you don’t want to set the maximums too high, which could overtax your router. In our example, we’re going to set our max-ephones to 8 and our max-dn to 20: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#max-ephones 8 Router(config-telephony)#max-dn 20 Router(config-telephony)#end Router#
The maximum number of ephones and ephone-DNs that can be configured depends on hardware, because different devices have different amounts of memory installed in them. To show you what happens when you try to go over the maximum setting, let’s say that your max-ephones is 8 and you attempt to add a ninth phone to CUCM Express. When this occurs, the phone will not be allowed to register and will display a “Registration Rejected” message, as shown in Figure 8.5.
c08.indd 302
9/21/11 11:24:47 AM
Initial CUCM Express Configuration
FIGURE 8.5
303
“Registration Rejected” message
Also, if you exceed the max-dn number, you will receive an error when attempting to configure the maximum +1 ephone-DN. The following example has a max-dn set to 20, so on the 21st ephone-DN configuration you’ll see this log message on the CUCM Express console: Router(config)#ephone-dn 21 dn 21 exceeds max-dn 20 Router(config)#
Step 3: Identify and Set Firmware Load Files Step 3 of the CUCM Express system configuration process deals with how you handle the distribution of fi rmware for your Cisco phones. In the previous steps, we identified the fi les that our Cisco phones need and have configured our router to serve them using TFTP. The CUCM Express telephony processes must also be configured to set the fi rmware fi les you choose to defi ne for each phone hardware type. As mentioned earlier, when the phones fi rst communicate, they have very little information to begin with and must be told virtually everything. One piece of information a phone does possess is the hardware type of Cisco phone it is. This information is then used by CUCM Express to determine which fi rmware load file it should request. The fi rmware load fi le basically tells CUCM Express what fi rmware to tell the Cisco phones to download. It can be a bit difficult to figure out which fi rmware load fi le you need to configure for each phone. The best way to fi nd out which load fi les you need is to search on the cisco.com website for “CME X.X fi rmware,” where X.X is the version of the CUCM Express software you are running.
c08.indd 303
9/21/11 11:24:48 AM
304
Chapter 8
■
Configuring and Managing CUCM Express
Once you locate the firmware, you can click the link to display a table listing the correct load fi le for each phone that needs to be configured within config-telephony configuration mode. In Figure 8.6, you can see that you need to configure SCCP45.9-11SR1S.loads as our load fi le. FIGURE 8.6
Cisco phone load file table
You know that you need to use SCCP45.9-1-1SR1S.loads as your key load fi le because: 1.
You are using SCCP as your signaling protocol.
2.
The fi le marked with an asterisk (*) is the load fi le.
In this example, we are configuring CUCM Express to tell our Cisco 7945 and 7965 phones which fi rmware load fi les they should request: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#load 7945 SCCP45.9-1-1SR1S.loads Updating CNF files CNF files update complete for phonetype(7945) Router(config-telephony)#load 7965 SCCP45.9-1-1SR1S.loads Updating CNF files CNF files update complete for phonetype(7965)
Step 4: Generate and Serve Default Phone Configuration Files The default phone configuration file is the XML configuration fi le that informs a Cisco IP phone of all the general information it needs to communicate with the CUCM Express system. Included in this default phone configuration are the source IP address and the port through which the phones can communicate with the call-processing agent. It also includes the load configuration fi lenames we just fi nished setting up. At this point, I’m referring to the phone configuration fi les as “default” because there is nothing unique about the configurations right now. Once we begin configuring phone
c08.indd 304
9/21/11 11:24:48 AM
Initial CUCM Express Configuration
305
extensions and other settings unique to the phones, this information will be compiled and stored as a single phone configuration fi le. But since none of that information is configured at this time, the configuration fi les have only the default information that all the Cisco phones share. The phone configuration fi le is automatically updated every time a change is made that affects the configuration. For example, if you need to add additional load fi les for a Cisco phone, as soon as an addition, subtraction, or change occurs in the telephony-service configuration prompt, the configuration fi le updates itself. You can also manually update the phone configuration fi le by issuing the create cnf-files command within the config-telephony command structure. Here is an example of this command: Router(config-telephony)#create ? cnf-files create XML cnf for ethernet phone Router(config-telephony)#create cnf-files Creating CNF files
Once these four steps have been completed, you can back out of config-telephony configuration mode and fi nish your basic SCCP configuration by configuring ephones and ephone-DNs. Before you do that, however, we will go over the slightly different procedure for configuring CUCM Express for SIP signaling.
Configuring the Mandatory CUCM Express System Settings Using SIP Signaling If you want to use SIP signaling instead of SCCP, then a few of the mandatory CUCM Express system settings are slightly different. This section goes through the configuration procedure, noting the differences between commands.
IP Telephony Digit-Collection Methods While we are discussing SCCP and SIP endpoint protocols, it’s a good time to talk about the different digit-collection methods supported by the two. Digit collection refers to the method that the signaling protocol uses to collect telephone numbers that are entered using an endpoint such as a Cisco IP phone. There are two primary methods of digit collection. In the digit-by-digit method, the user picks up the phone and immediately receives a dial tone. Each digit the user presses into the telephone endpoint is immediately transferred using the signaling protocol in use. This is how analog telephones operate. It is also how SCCP and Enhanced SIP phones operate. The other digit-collection method is called en-bloc. The user enters all the required telephone digits before receiving a dial tone. Once all digits are entered, the user presses
c08.indd 305
9/21/11 11:24:49 AM
306
Chapter 8
■
Configuring and Managing CUCM Express
the call button, and at that point, a dial tone is received and all digits are sent in one large block using the signaling protocol. This is how current mobile phone digit collection works, and it is also how Simple SIP phones operate. It is important to know what digit-collection type your voice network is using, because it can affect when dial-peer patterns are matched. For example, say you have two dial peers. Dial peer 1 has a destination pattern of 123, and dial peer 2 has a destination pattern of 12345. When digit-by-digit collection is used, dial peer 2 could never be matched because it will always match after the third digit is sent. However, if en-bloc digit collection is used, if the user enters the exact extension of 12345, it will indeed trigger on dial peer 2.
1.
The fi rst thing that you need to do is to enable the SIP process to allow SIP calls to be made between separate networks on CUCM Express. This is a matter of enabling SIP while in conf-voi-serv configuration mode and issuing the allow-connections sip to sip command as shown here: Router#configure trminal Router(config)#voice service voip Router(conf-voi-serv)#allow-connections sip to sip
2.
Next, you need to specify that your local CUCM Express system is the SIP registrar server for SIP phones that attempt to register with it. To do so, you must enter into conf-serv-sip configuration mode and issue the registrar server command. Then the bind control source-interface command includes the interface that your source-address is configured on so that CUCM Express will not use the IP layer to determine the source address for SIP signaling. In the following example, we will bind our CUCM Express source address to loopback 0 for all SIP control signaling: Router(conf-voi-serv)#sip Router(conf-serv-sip)#registrar server Router(conf-serv-sip)#bind control source-interface loopback0 Router(conf-serv-sip)#end Router#
3.
Now you need to enter into config-register-global structure by issuing voice register global and then enter the mode cme command. These two commands are the SCCP command equivalent of the voice service voip command, and this is where the majority of the CUCM Express phone settings are configured: Router#configure trminal Router(config)#voice register global Router(config-register-global)#mode cme
c08.indd 306
9/21/11 11:24:50 AM
Configuring SCCP and SIP Phones and Directory Numbers
4.
307
Just as with the SCCP phones, you need to configure your source CUCM Express IP address, phone fi rmware load fi les, your maximum number of hardware phones, and your maximum number of directory numbers. Following is an example showing how to configure these settings using the same parameters as our SCCP CUCM Express configuration so you can see the differences: Router(config-register-global)#source-address 192.168.10.1 Router(config-register-global)#max-pool 8 Router(config-register-global)#max-dn 20 Router(config-register-global)#load 7945 SIP45.8-5-3S.loads Router(config-register-global)#create profile
As you can see when comparing the SIP and SCCP configurations, there are some noticeable differences in syntax. The SIP source-address command is slightly different from the SCCP ip source-address command but serves the same purpose as when configuring SCCP. The max-pool command is identical to the max-ephones command, and the max-dn command remains the same when setting the maximum number of directory numbers CUCM Express can be configured with. When working with SIP in a CUCM Express environment, there are some differences in what physical phones and directory numbers are called compared to an SCCP setup. When configuring IP phones for SCCP, you call the physical IP phone an ephone, and when using SIP, it is called a voice register pool. Also, SCCP ephone-DNs are known as voice register DNs. You will see examples of how to configure voice register pool phones and voice register DNs later in this chapter.
Next, the firmware load command is identical to the one for SCCP, but keep in mind that you need to offer your phones SIP fi rmware as opposed to SCCP fi rmware. Additionally, your TFTP server will need to be configured to offer up the required SIP fi rmware fi les. Finally, you need to generate your default configuration profi les that are similar to the SCCP cnf-fi les. This is accomplished using the create profile command, which generates configuration fi les that are used for provisioning SIP phones.
Configuring SCCP and SIP Phones and Directory Numbers Now that you know how to configure a CUCM Express router for basic operation for both SCCP and SIP, you need to configure the phones and directory numbers that will connect to your CUCM Express system and use it as a call-processing agent.
c08.indd 307
9/21/11 11:24:50 AM
308
Chapter 8
■
Configuring and Managing CUCM Express
Configuring Basic SCCP Ephone and Ephone-DNs Up until now, all of the configuration information that the Cisco IP phones receive from the CUCM Express has been generic information that all of the phones share. Ephone and ephone-DN configurations are the way the administrator can control the unique features that belong to each phone. We’ll fi rst look at what an ephone-DN is and how to configure the most basic type. Then you’ll learn about ephones and how to apply an ephone-DN to an ephone.
Configuring an SCCP Ephone Directory Number An ephone-DN is what we usually think of as a telephone number. This is the extension that a user dials when they wish to call your phone. On CUCM Express, there are many different ephone-DN configuration settings that can be used to add functionality, but for now, all you want to do is add a single ephone-DN to a phone. You’ll see different ways to configure ephone-DN line options later in this chapter. From a directory number (DN) standpoint, you need to fi rst create an ephone-DN logical tag. Then, once you are in the config-ephone-dn configuration mode, you give the ephone-DN an extension number. Let’s configure your fi rst ephone-DN with an extension of 4001 and a second ephone-DN with an extension of 4002: Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 4001 Router(config-ephone-dn)#exit Router(config)#ephone-dn 2 Router(config-ephone-dn)#number 4002 Router(config-ephone-dn)#end Router#
Now that you have two directory numbers configured, let’s apply them to two Cisco phones using the ephone configuration command.
Configuring an SCCP Ephone An ephone configuration is the logical representation of a physical IP phone. This is where you apply all the unique ephone-DNs and other settings that are ultimately pushed down to the phone hardware. Every phone on CUCM Express has a unique ephone tag in which all of the phone configurations are applied. CUCM Express maps the ephone configuration to the unique MAC address of the phone. By using the MAC address, the phone can physically move around the network and continue to maintain the same configuration settings wherever it goes. Since you’re creating the most basic phone configuration, the only information you’ll need to configure ephones is the MAC address of each phone and the ephone-DN tag you
c08.indd 308
9/21/11 11:24:51 AM
Configuring SCCP and SIP Phones and Directory Numbers
309
wish to apply. You will also configure two optional but important settings—the physical phone type and the preferred codec. You will also specify the telephone model using the type command followed by the model number. This lets CUCM Express explicitly know what phone fi rmware to offer this particular ephone. By default, CUCM Express is preconfigured with templates for most of the popular Cisco IP phones. If the phone you wish to use is not included, you can create your own ephone-type template using the ephone-type global configuration command followed by a name to identify your new phone type template. An optional addon keyword indicates that the phone type includes the specified add-on module, such as a Cisco 7916 button expansion “side-car” module. You will then be placed into config-ephonetype mode, where you can enter a unique device-id. Additionally, you can specify the device-type, num-buttons, and max-presentation settings, which specifically state what your phone is capable of supporting.
You can also set the codec command followed by a codec supported by the phone. This command sets your preferred codec when calling between two phones that utilize CUCM Express as their call-processing agent. The default codec is G.711 and will be used if a codec is not defi ned here. For phones that connect to other IP phones through VoIP dial peers, you can use the dspfarm-assist keyword so CUCM Express can negotiate codec preference for VoIP dial peer calls. Using this optional keyword, CUCM will direct calls to a DSP farm that will transcode between the specified codec and G.711. Keep in mind that you will need to make sure you have adequate DSP resources, based on the number of simultaneous calls that will be transcoded. Let’s configure two Cisco phones with your ephone-DN extension numbers. Ephone 1 will be configured to use extension 4001 and ephone 2 will be configured with extension 4002. Both phones are 7965Gs and prefer to use the G.729r8 codec for local calls only: Router#configure terminal Router(config)#ephone 1 Router(config-ephone)#mac-address 0014.1c4d.2589 Router(config-ephone)#type 7965 Router(config-ephone)#codec g729r8 Router(config-ephone)#button 1:1 Router(config-ephone)#exit Router(config)#ephone 2 Router(config-ephone)#mac-address 0014.4c7f.a49b Router(config-ephone)#type 7965 Router(config-ephone)#codec g729r8 Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
c08.indd 309
9/21/11 11:24:51 AM
310
Chapter 8
■
Configuring and Managing CUCM Express
CUCM Express can automatically assign extensions to brand-new phones that do not have a specific ephone-to-MAC-address mapping configured. Using the auto assign command in the config-telephony command structure, you can specify the hardware types eligible for auto-assign as well as specify which ephone-DNs should be assigned. As soon as you power up an eligible phone and it registers to CUCM Express, auto-assign starts up and builds an ephone configuration. To do this it pulls in the MAC address of the phone and configures the lowest unused tagged ephonedn from the range specified. This option is perfect for new environments where it doesn’t matter who receives a particular extension number or for fast deployments where editing can come later.
The mac-address configuration is self-explanatory, but the button configuration needs some explanation. The fi rst number of the button command indicates the Cisco IP phone button that is being configured. For example, on a Cisco 7965G IP phone, there are six extension buttons available, so this number could be 1–6. On the other hand, a 7945G phone has only two buttons, so this number could only be 1 or 2. The colon (:) indicates that you want a standard ring for this extension. There are many different types of audible and silent rings that we’ll sort out later on, but for now, you just want a standard ring for your phone. The last number in the configuration specifies the ephone-DN to apply to the physical phone. Since we specified that ephone 1 uses ephone-DN 1, the extension on button 1 of ephone 1 will be 4001. Therefore ephone 2 will be configured to use ephone-DN 2 or extension 4002.
Configuring Basic SIP Voice Register Pools and Voice Register DNs Similar to SCCP, SIP setup in a CUCM Express environment requires that you configure physical phones and logical directory numbers. The processes are similar to the configuration of SCCP. In fact, some configuration commands are identical. With other commands, the command syntax is slightly changed, as you will see in the next two sections.
Configuring SIP Voice Register DNs The directory numbers are configured using the voice register dn command followed by a unique DN tag, which is used to differentiate multiple directory numbers configured on the CUCM Express system. After that, you use the number command followed by the telephone number you wish to associate with a DN. Let’s configure two voice register DNs that are similar to the ephone DNs configured in the previous example: Router#configure terminal Router(config)#voice register dn 1 Router(config-register-dn)#number 4001
c08.indd 310
9/21/11 11:24:52 AM
SCCP Ephone-DN Line Configuration Options
311
Router(config-register-dn)#exit Router(config)#voice register dn 2 Router(config-register-dn)#number 4002 Router(config-register-dn)#end Router#
Configuring SIP Voice Register Pools Again, an easy way to understand the configuration of voice register pools is to compare them to SCCP ephone-DNs. With voice register pools, you specify the MAC address of your physical phone, the physical-phone type, and your preferred codec for local calls, as shown in this example: Router#configure terminal Router(config)#voice register pool 1 Router(config-register-pool)#id mac 0014.1c4d.2589 Router(config-register-pool)#type 7965 Router(config-register-pool)#codec g729r8 Router(config-register-pool)#number 1 dn 1 Router(config-register-pool)#exit Router(config)#voice register pool 2 Router(config-register-pool)#id mac 0014.4c7f.a49b Router(config-register-pool)#type 7965 Router(config-register-pool)#codec g729r8 Router(config-register-pool)#number 1 dn 2 Router(config-register-pool)#end Router#
You assign extensions to telephone buttons using the number command followed by the button number. Then you use the dn keyword to indicate that you wish to set a voice register DN to the button.
SCCP Ephone-DN Line Configuration Options The CVOICE exam requires that you understand different SCCP ephone-DN line options that are commonly used in both small and large environments. A key-system environment is commonly used in small businesses where the vast majority of calls are coming from the PSTN. The key-system model uses a single-line-extension-to-many-phones shared-line design. Alternatively, a PBX modeled system uses an individual line approach with one
c08.indd 311
9/21/11 11:24:52 AM
312
Chapter 8
■
Configuring and Managing CUCM Express
extension to one phone model. There are several more directory number line options that are configurable for SCCP or SIP and SCCP, as shown in Table 8.5.
TA B L E 8 . 5
SIP and SCCP ephone-DN line option compatibility
DN Option
SCCP Compatible?
SIP Compatible?
Single-line
Yes
Yes
Dual-line
Yes
No
Octo-line
Yes
No
Shared-line
Yes
Yes
Two DNs with one telephone
Yes
Yes
Dual-number line
Yes
Yes
Overlay line
Yes
No
This section will first show a typical ephone-DN shared-line configuration, and one that has two DNs on a single telephone; both are common in key-system environments. You can then combine these options to configure dual-line and octo-line ephone-DNs, which are also common in small-business environments. Finally, we will look at typical PBX line configurations that commonly use single-, dual-, or octo-lines with individual extensions for each phone.
Configuring Ephone-DN Shared Lines In a key-system environment, you commonly see the entire PSTN extension configured on the line instead of a truncated 4- or 5-digit extension. Furthermore, all phones must be capable of answering any call. That means that all the ephone-DNs will be configured as buttons on every phone. This is known as a shared line. One way of configuring this shared line is to configure a single ephone-DN and apply it to multiple ephones. The following keysystem example configuration shows two ephone-DNs that represent two separate external PSTN phone numbers. The DNs are assigned to both phones, and both will ring when the number is dialed. The fi rst phone to answer gets the call: Router#configure terminal Router(config)#ephone-dn 1 Router(config-dn)#number 5555552121
c08.indd 312
9/21/11 11:24:53 AM
SCCP Ephone-DN Line Configuration Options
313
Router(config-dn)#ephone-dn 2 Router(config-dn)#number 5555559191 Router(config-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 2:2 Router(config)#ephone 2 Router(config-ephone)#button 1:1 2:2 Router(config-ephone)#end Router#
Figure 8.7 shows what ephone-DN 1 looks like after these configurations are made and the phone is reset.
F I G U R E 8 .7
A shared line
Let’s say that a phone call is placed to 555-555-2121. Both ephone-DN 1 and ephoneDN 2 will ring. If ephone-DN 2 answers the call fi rst, line 1 of ephone-DN 1 shows this line as in use by lighting the extension button red and using the double-handset icon next to the line number. Figure 8.8 shows line 1 of ephone 1 in use. Because line 1 is in use, if the person using ephone-DN 1 needs to make a call, they must choose to use line 2, which is currently not in use.
c08.indd 313
9/21/11 11:24:53 AM
314
Chapter 8
FIGURE 8.8
■
Configuring and Managing CUCM Express
DN in use
Line in use
Configuring Two Ephone-DNs with One Number An alternative shared-line method is to configure two ephone-DNs with the same number. You then can configure the ephones to use the separate ephone-DN configurations. You set a preference on the ephone-DN configuration so that one particular phone will always ring fi rst. If the preferred ephone is busy, then the next ephone with the lowest preference will ring instead. This preference is set on the CUCM Express, and its value can be between 0 and 9. You can accomplish this multiple ephone-DN configuration with a shared line using the preference configuration command. This next configuration example shows how to configure two ephone-DNs with a single phone number. You can see that ephone-DN 1 has a preference of 0, which means that when a call is made to this extension, it will ring the phone that is configured to use ephone-DN 1 fi rst. Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#ephone-dn 2 Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1
c08.indd 314
9/21/11 11:24:54 AM
SCCP Ephone-DN Line Configuration Options
315
Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
If you did not configure a preference on the ephone-DNs, or you set them to be the same, the CUCM Express would round-robin the calls between the two ephones. The preference command gives you control of where CUCM Express routes calls.
If ephone-DN 1 is in use, any new call will also be sent to ephone-DN 1 because it is the lowest preferred DN regardless of whether the phone is busy. So a second call placed to our extension would receive a busy signal, and ephone-DN 2 would never receive any calls. To get around this problem, you configure ephone-DN 1 with the no huntstop command. The huntstop command tells the CUCM Express that it should look for the next preferred ephone-DN if the most preferred phone is busy. Now when ephone-DN 1 is busy, a second call placed on the shared extension will roll over and ring ephone-DN 2: Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#no huntstop Router(config-ephone-dn)#ephone-dn 2 Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
Configuring Ephone-DN Dual- and Octo-lines Another shared-line key-system configuration we need to look at is when the phone extensions are configured as dual-line and octo-line DNs. So far, we’ve configured only single-line phones. A single-line phone can only make and receive one call at a time. So if the line is already in use, you cannot place the call on hold to make a second call. Likewise, if line 1 is in use, a second phone call to the extension will receive a busy signal.
c08.indd 315
9/21/11 11:24:54 AM
316
Chapter 8
■
Configuring and Managing CUCM Express
Dual-line phones, on the other hand, allow the phone to place calls on hold or receive a second call when in use. And octo-line phones are capable of handling up to eight simultaneous calls on a single phone button extension. Dual- and octo-lines are configured within the ephone-DN as shown here: Router(config)#ephone-dn 1 ? dual-line dual-line DN (2 calls per line/button) octo-line octo-line DN (8 calls per line/button)
Configuring ephone-DNs with dual lines is extremely beneficial because it allows for additional functionality when your phone is in use. For now, let’s assume that your small business has a single PSTN line that is to be shared between two phones configured with dualline ephone-DNs. Just as in the previous configuration example, we want to ensure that the first call made to the extension is received on ephone-DN 1 and that a second call rolls over to ephone-DN 2 if ephone-DN 1 is already in a call. Let’s say you configure the following: Router#configure terminal Router(config)#ephone-dn 1 dual-line Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#no huntstop Router(config-ephone-dn)#ephone-dn 2 dual-line Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
In this situation, the first call will always go to ephone-DN 1. But because the ephoneDN is configured as a dual-line, a second call will also go to ephone-DN 1. Only a third simultaneous call will make it to ephone-DN 2. To get around this dual-line problem, you can use the huntstop channel command on ephone-DN 1. The huntstop command prevents calls from hunting to the second channel of the ephone-DN. So if you combine the no huntstop command with the huntstop channel command, you get the result that the fi rst call always goes to ephone-DN 1, and if channel 1 of ephone-DN 1 is busy, the second call will be sent to ephone-DN 2. Here is the full configuration example to accomplish your goal: Router#configure terminal Router(config)#ephone-dn 1 dual-line Router(config-ephone-dn)#number 5555557777
c08.indd 316
9/21/11 11:24:55 AM
SCCP Ephone-DN Line Configuration Options
317
Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#no huntstop Router(config-ephone-dn)#huntstop channel Router(config-ephone-dn)#ephone-dn 2 dual-line Router(config-ephone-dn)#number 5555557777 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
There are additional phone button options that also expand the shared-line experience for SCCP phones. The concept of overlay buttons will be explained in the “Configuring Ephone Button Options” section of this chapter.
Configuring SCCP Individual Lines PBX systems, which are more commonly found in larger office environments, assign a unique phone extension to every phone. This allows the caller to reach a specific person within an organization. Also, because of the size of the environment, a large percentage of phone calls are on-network calls. To help make life easier for the phone users, phone extensions are used instead of the full phone number. Typical extensions are four or five digits in length. These digits often correspond to the last digits of the full PSTN DID if there is one. Also, you will fi nd that the phones almost always are configured as dual-line ephone-DNs. This is because you need a second line to enable the additional functionality that the PBX system offers. In the previous section, you learned how to configure the most common key-system methods of sharing a single phone number with multiple phones. Here is a very basic and common method of configuring two PBX system phones with separate extension numbers: Router#configure terminal Router(config)#ephone-dn 1 dual-line Router(config-ephone-dn)#number 8001 Router(config-ephone-dn)#ephone-dn 2 dual-line Router(config-ephone-dn)#number 8002 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2
c08.indd 317
9/21/11 11:24:55 AM
318
Chapter 8
■
Configuring and Managing CUCM Express
Router(config-ephone)#button 1:2 Router(config-ephone)#end Router#
Now you have two phones with separate extensions. The CUCM Express system can then be configured for additional features to tailor your system to your environment. Next we’ll look at how to configure ephone button options to enhance your SCCP phone configurations.
Configuring Ephone Button Options As you saw earlier, when it’s time to assign ephone-DNs to specific ephones, you use the button command in ephone-config configuration mode: button 1:1
The separator between the line button you wish to configure and the ephone-DN identifier is an ephone button separator. There are many different button separator options available for use. Let’s look at all the options available. Table 8.6 details what each of these button separator functions does: TA B L E 8 . 6
c08.indd 318
Button separator options
Separator
Option Name
Function
:
Normal ring
Phone rings normally with default ring tone. Also uses flashing lights on line button and headset lamp to indicate ring.
s
Silent ring
No audible ring when calls come into the phone. Uses flashing lights on line button and headset lamp to indicate ring. No audible call-waiting beep.
b
Silent with beep
No audible ring when calls come into the phone. Uses flashing lights on line button and headset lamp to indicate ring. Call-waiting beep is audible.
f
Feature ring
Phone rings using an alternate ring tone from the default.
m
Monitor line
Used to monitor status (on- or off-hook) of a line. Commonly used on receptionist phones to verify if an employee is currently using the phone. No audible ring when calls come into the phone, and the line cannot be used to make or take calls.
w
Watch phone
Similar to the monitor mode except it allows the user to monitor all ephone-DNs on a phone instead of a single ephone-DN. This mode presents a more accurate picture of user availability compared to using the m option separator.
9/21/11 11:24:56 AM
SCCP Ephone-DN Line Configuration Options
319
Separator
Option Name
Function
o
Overlay line
Associates multiple ephone-DNs with a single line button. No call-waiting functionality.
c
Overlay with call waiting
Same as the overlay line but with call-waiting functionality added.
x
Expansion line
Another overlay line option. The difference is that if the line button extension is in use, new calls are allowed to overflow to additional line buttons to help prevent a busy signal.
The ring phone button options (:, s, b, and f) are fairly straightforward and need no more explanation. We’ll focus on when you would want to use the monitor and overlay button options.
Monitor Line (m) Let’s say you have an administrative assistant who is tasked with taking your calls and transferring them to your phone when you are not busy with other calls. The monitor line button option allows your assistant’s phone to monitor your ephone-DN. That way, your assistant can see if you are currently on a call using that ephone-DN. If you are already busy on the line, the assistant knows you are busy and can hold all other incoming calls for you. The line configured in monitor mode cannot make or receive any calls. Instead, it is simply used as a visual aid to see if another line is being used. In this example, my phone is assigned the number 4040. My administrative assistant has his own number of 4041 assigned to button 1. Also configured is button 2 to monitor my ephone-DN: Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 4040 Router(config-ephone-dn)#ephone-dn 2 Router(config-ephone-dn)#number 4041 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 2m1 Router(config-ephone)#end Router#
Now when I pick up my phone to make a call, my administrative assistant can see that I’m busy on that ephone-DN. Figure 8.9 shows the administrative assistant’s phone when the 4040 line is in use.
c08.indd 319
9/21/11 11:24:56 AM
320
Chapter 8
FIGURE 8.9
■
Configuring and Managing CUCM Express
The phone configured to monitor ext. 4040
Line in use
One of the drawbacks to this setup is what would happen if my phone were to be configured with multiple ephone-DNs. Multiple monitor button operators would then need to be created for each extension. A way around the monitor line limitation is to use the watch phone (w) button separator.
Watch Phone (w) The watch phone button option does exactly the same thing as the monitor line option, except that it monitors all of the ephone-DNs of an entire ephone instead of just one ephone-DN. You configure the button to watch the primary line of a phone, and it monitors all lines on the phone. This is far more useful than the monitor line option, because you can see if any of the lines on a phone are in use. Also just like the monitor line option, a line configured with the watch phone option cannot make or receive any calls. The status on the watching display button shows the phone in use when the following conditions occur on the watched phone:
Off-hook and/or in use
The phone is not registered (unregistered or deceased)
In DnD (do not disturb) mode
Overlay Line (o) Overlay lines allow you to configure multiple ephone-DNs to a single phone button on a Cisco phone. Cisco phones have a fi nite number of phone buttons to use. You can use the
c08.indd 320
9/21/11 11:24:57 AM
SCCP Ephone-DN Line Configuration Options
321
overlay button option to assign multiple ephone-DNs to a single physical phone button. Ephone-DNs that are configured on a particular ephone with the overlay option must all be single-line or dual-/octo-line phones. There cannot be a mix of single- and multi-line phones. A common example of using an overlay line is when you have a main line that is answered by anyone in a specific department. This overlay shared-line configuration is best paired with the preference and no huntstop commands shown earlier in this chapter. In our example, we have a department that has two employees. Each employee has a unique extension for their phone. There is also a shared line number (5454) that is configured as an overlay line on button 1. When we configure the ephone-DN, we make sure to configure the unique extension fi rst. The fi rst ephone configured is the number that is displayed on the phone display LCD panel. The overlay line is configured, but that number is never seen on the phone button display. The shared line is configured on ephone-DN 3 and ephone-DN 4. Ephone-DN 3 has the lower preference and will handle the fi rst call. It is also configured to look for the next preferred ephone-DN with the same extension if the most preferred phone is busy by using the no huntstop command. The complete configuration looks like this: Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 6001 Router(config-ephone-dn)#ephone-dn 2 Router(config-ephone-dn)#number 6002 Router(config-ephone-dn)#ephone-dn 3 Router(config-ephone-dn)#number 5454 Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#no huntstop Router(config-ephone-dn)#ephone-dn 4 Router(config-ephone-dn)#number 5454 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1o1,3,4 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1o2,3,4 Router(config-ephone)#end Router#
Phone button 1 of both the phones is configured with its unique number as well as the shared-line number for the department. Calls placed to 6001 go only to ephone-DN 1. Calls placed to 6002 go only to ephone-DN 2. But calls placed to 5454 are sent to both phones. The configuration consumes only one phone button on each phone. Now other buttons are open to be configured for additional lines or speed-dial capabilities if desired. Here is a show ephone for our two configured ephone-DNs. As you can see, the fi rst number assigned in the overlay configuration is bound to the phone and idle. The shared number is visible but not the primary number.
c08.indd 321
9/21/11 11:24:57 AM
322
Chapter 8
■
Configuring and Managing CUCM Express
Router#show ephone ephone-1 Mac:0021.A084.4F0C TCP socket:[3] activeLine:0 REGISTERED in SCCP ver 12/8 mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.2 49242 7965 keepalive 11 max_line 6 button 1: dn 1 number 6001 CH1 IDLE overlay overlay 1: 1(6001) 3(5454) 4(5454)
ephone-2 Mac:0021.A02E.7D9A TCP socket:[4] activeLine:0 REGISTERED in SCCP ver 12/8 mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.3 49219 7965 keepalive 11 max_line 6 button 1: dn 2 number 6002 CH1 IDLE overlay overlay 1: 2(6002) 3(5454) 4(5454)
Let’s say a call is placed to extension 5454, and ephone-DN 2 answers the call. Now a show ephone looks like this: Router#show ephone ephone-1 Mac:0021.A084.4F0C TCP socket:[3] activeLine:0 REGISTERED in SCCP ver 12/8 mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.2 49242 7965 keepalive 14 max_line 6 button 1: dn 1 number 6001 CH1 IDLE overlay overlay 1: 1(6001) 3(5454) 4(5454) ephone-2 Mac:0021.A02E.7D9A TCP socket:[4] activeLine:1 REGISTERED in SCCP ver 12/8 mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.3 49219 7965 keepalive 14 max_line 6 button 1: dn 3 number 5454 CH1 CONNECTED overlay shared overlay 1: 2(6002) 3(5454) 4(5454) Active Call on DN 3 chan 1 :5454 192.168.10.3 27418 to 192.168.1.100 24646 via 192.168.10.3 G711Ulaw64k 160 bytes no vad Tx Pkts 196 bytes 33712 Rx Pkts 192 bytes 33024 Lost 0 Jitter 7 Latency 0 callingDn 5 calledDn -1
At this point, ephone-DN 3, which is number 5454, is owned and controlled by ephoneDN 2. A second call is made to 5454; this time, ephone-DN 3 is in use, so it rolls over to the next ephone-DN, which is 4. Because ephone-DN 2 is configured with an overlay with both ephone-DN 3 and 4, the phone rings on ephone-DN 2. A show ephone with both ephone-DN 3 and 4 in use looks like this:
c08.indd 322
9/21/11 11:24:58 AM
SCCP Ephone-DN Line Configuration Options
323
Router#show ephone ephone-1 Mac:0021.A084.4F0C TCP socket:[3] activeLine:1 REGISTERED in SCCP ver 12/8 mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.2 49242 7965 keepalive 19 max_line 6 button 1: dn 4 number 5454 CH1 CONNECTED overlay shared overlay 1: 1(6001) 3(5454) 4(5454) Active Call on DN 4 chan 1 :5454 192.168.10.2 27274 to 192.168.1.101 24648 via 192.168.10.2 G711Ulaw64k 160 bytes no vad Tx Pkts 0 bytes 0 Rx Pkts 0 bytes 0 Lost 0 Jitter 0 Latency 0 callingDn 5 calledDn -1 ephone-2 Mac:0021.A02E.7D9A TCP socket:[4] activeLine:1 REGISTERED in SCCP ver 12/8 mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.3 49219 7965 keepalive 19 max_line 6 button 1: dn 3 number 5454 CH1 CONNECTED overlay shared overlay 1: 2(6002) 3(5454) 4(5454) Active Call on DN 3 chan 1 :5454 192.168.10.3 26148 to 192.168.1.100 24640 via 192.168.10.3 G711Ulaw64k 160 bytes no vad Tx Pkts 738 bytes 126936 Rx Pkts 736 bytes 126592 Lost 0 Jitter 2 Latency 0 callingDn 6 calledDn -1
As you can see, this shared-line overlay configuration is a very good option in many office environments. It also highlights a combination of PBX and key-system capabilities on CUCM Express. Situations that combine both PBX and key-system functionality are commonly called hybrid systems.
Overlay with Call Waiting (c) This button separator option is the same as the overlay except that it adds call-waiting functionality. Call waiting is the ability for a phone to receive two or more simultaneous calls. The user answering the call can place a currently engaged call on hold to answer the second call. To see this difference, we will configure our CUCM Express router with the same configuration as the overlay example except we will use the call-waiting button separator option. We’ll also have to configure ephone-DN 3 as a dual-line phone so it can utilize call waiting: Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 6001 Router(config-ephone-dn)#ephone-dn 2 Router(config-ephone-dn)#number 6002 Router(config-ephone-dn)#ephone-dn 3
c08.indd 323
9/21/11 11:24:58 AM
324
Chapter 8
■
Configuring and Managing CUCM Express
Router(config-ephone-dn)#number 5454 Router(config-ephone-dn)#preference 0 Router(config-ephone-dn)#no huntstop Router(config-ephone-dn)#ephone-dn 4 Router(config-ephone-dn)#number 5454 Router(config-ephone-dn)#preference 1 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1c1,3 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1c2,3 Router(config-ephone)#end Router#
So what are the results of this configuration? The fi rst call to extension 5454 is handled by ephone-DN 3 because of its lower preference. A second call rolls over to ephone-DN 4, because the no huntstop option has been set. Ephone-DN 4 rings ephone-DN 1, but it also sends the call-waiting beep to ephone-DN 2, which is currently in a call. This way, the user on ephone-DN 2 is notified of a second call and can, if he/she wants to, place the fi rst call on hold and answer the second.
Expansion Line (x) The expansion button separator is used to expand line coverage for an overlay button (o). It does not work when the overlay separator button is configured for call waiting (c). When the extensions configured as overlay lines are in use, the expansion lines begin taking calls. In this example, we have ephone-DN 1 configured to overlay ephone-DNs 1 and 2, which are both 7001. Ephone-DN 1 is also a dual-line phone. We also have button 2 configured as an overlay for line 1 on the phone: Router#configure terminal Router(config)#ephone-dn 1 dual-line Router(config-ephone-dn)#number 7001 Router(config)#ephone-dn 2 Router(config-ephone-dn)#number 7001 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#button 1o1,2 2x1 Router(config-ephone)#end Router#
So in this example, what happens? The fi rst call to 7001 goes to button 1. The second call also goes to button 1, because it is a dual-line phone and channel 2 is free. The third call will overflow to button 2 because both lines are busy on button 1. Always remember that overflow lines will be used only when all other lines are occupied.
c08.indd 324
9/21/11 11:24:58 AM
Configuring CUCM Express Telephony Service Features
325
Configuring CUCM Express Telephony Service Features The configuration steps for most telephony service features are performed while in config-telephony configuration mode. These features provide multiple ways to tailor your voice environment to better fit the needs of your end users. This section will show you how to configure several of the most important telephony service features. We will look at how to change the language and ring tone settings to match the location where your endpoints will reside. You will also see how to modify the date and time formats and modify the phone handset system message to personalize your voice system. Keep in mind that these features can be configured in either SCCP or SIP mode. The commands are identical for both protocols except where explicitly indicated.
Configuring User Locale and Network Locale By default, CUCM Express is set for the English (US) language for its location. What happens if you need to deploy this system in Colombia, where Spanish is the native language? To modify the language used on the Cisco phone handsets, including soft keys, help, and other buttons, we can use the user-locale command. Let’s see what language options are currently available: Router(config-telephony)#user-locale ? <0-4> user locale index 0 to 4 (0 is default) DE Germany DK Denmark ES Spain FR France IT Italy JP Japan NL Netherlands NO Norway PT Portugal RU Russian Federation SE Sweden US United States
Using our Colombian deployment example, we’ll choose ES for our locale, so Spanish will be displayed on our handsets: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#user-locale ES Updating CNF files
c08.indd 325
9/21/11 11:24:59 AM
326
Chapter 8
■
Configuring and Managing CUCM Express
CNF files update complete Please issue ‘create cnf’ command after the locale change Router(config-telephony)#create cnf-files CNF file creation is already On Updating CNF files CNF files update complete
Whenever we make changes to the configuration of a telephone, we will need to reset the phone in order to obtain all of the updated configuration and settings as manipulated. The network-locale command modifies tones and cadence differences between geographic regions. Unlike user-locale, which changes language functions of the phones, the network-locale settings are based on regional standards for telephone signaling. Using our Colombia deployment example, we can use ES for the user-locale because Colombians speak the same language as Spaniards. The network-locale settings differ, however, because each region has different tones within its geographic regions: Router(config-telephony)#network-locale ? <0-4> network locale index 0 to 4 (0 is default) AT Austria CA Canada CH Switzerland CO Colombia DE Germany DK Denmark ES Spain FR France GB United Kingdom IT Italy JP Japan NL Netherlands NO Norway PT Portugal RU Russian Federation SE Sweden US United States Router(config-telephony)#network-locale CO Updating CNF files CNF files update complete Please issue ‘create cnf’ command after the locale change Router(config-telephony)#create cnf-files CNF file creation is already On Updating CNF files CNF files update complete
c08.indd 326
9/21/11 11:24:59 AM
Configuring CUCM Express Telephony Service Features
327
Can You Translate This for Me? Jeff was an IT consultant who recently began installing CUCM Express solutions in businesses. All of his implementations up to this point had been for local businesses in the United States, where English is the dominant language. A recent client, however, called for a Canadian deployment. Some employees had English as their primary language and others had French. In addition, the company regularly had visits from consultants from Spain, which required a third language. Since Jeff was new to the language-localization features of the CUCM Express, he had to do a bit of research to figure out the best configuration method to provide the three different language options to users. He learned that if the CUCM Express is going to be in a mixed-language environment, his best option was to configure user-locale and network-locale ephone templates. This is an example of how the ephone templates were used to remedy this situation: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#user-locale 1 ES Router(config-telephony)#user-locale 2 FR Router(config-telephony)#network-locale 1 ES Router(config-telephony)#network-locale 2 FR Router(config-telephony)#ephone-template 1 Router(config-ephone-template)#user-locale 1 Router(config-ephone-template)#network-locale 1 Router(config-ephone-template)#ephone-template 2 Router(config-ephone-template)#user-locale 2 Router(config-ephone-template)#network-locale 2 Router(config-ephone-template)#ephone 1 Router(config-ephone)#button 1:1 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1:2 Router(config-ephone)#ephone-template 1 Router(config-ephone)#ephone 3 Router(config-ephone)#button 1:3 Router(config-ephone)#ephone-template 2 Router(config-ephone)#exit Router(config)#telephony-service Router(config-telephony)#create cnf-files CNF file creation is already On Updating CNF files CNF files update complete Router(config-telephony)#restart all
c08.indd 327
9/21/11 11:25:00 AM
328
Chapter 8
■
Configuring and Managing CUCM Express
This method sets up a very simple and streamlined way to configure ephones that fits the needs of the local user. Note that by default, the English (US) locale is configured if you do not specify a template. So, for example, ephone 1 is for English-speaking users because there is no ephone template 1 or 2 specified. Ephone 2 is configured for user-locale 1, which is Spanish, and ephone 3 uses the French language as specified in template 2.
Configuring the Date and Time Format Similar to user-locale is the date and time format. Different countries display the date and time differently. In the United States, the date is displayed as mm/dd/yy. In other regions, such as Europe, the date is displayed as dd/mm/yy. The default format is mm/dd/ yy. If you wish to change the format on your Cisco IP phones, you use the date-format command. You can specify the following formats: Router(config-telephony)#date-format ? dd-mm-yy Set date to dd-mm-yy format mm-dd-yy Set date to mm-dd-yy format yy-dd-mm Set date to yy-dd-mm format yy-mm-dd Set date to yy-mm-dd format
Let’s change the date format to the European dd/mm/yy: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#date-format dd-mm-yy Router(config-telephony)#end Router#
Now when we reset our phones, we get the date to display with the day fi rst. When configuring date format settings for SIP, the commands are identical but the date must use a slash (/) as opposed to a hyphen (-) to separate the month, day, and year such as in the SIP configuration command:
date-format mm/dd/yy
We can configure the time format to use either a 12- or 24-hour clock, with the time-format command followed by 12 or 24. In this example we set a 24-hour clock for
our phones: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#time-format 24 Router(config-telephony)#end Router#
c08.indd 328
9/21/11 11:25:00 AM
Configuring CUCM Express Telephony Service Features
329
Modifying the Cisco IP Phone Keepalive Timer Cisco IP phones are constantly informing the call-processing agent (in our case, CUCM Express) that they are still active on the network. The phone uses keepalive messages for notification, with an interval of 30 seconds by default. If CUCM Express misses three keepalives in a row, it assumes the Cisco phone is no longer active. In situations where your IP phones reside on a congested network, it might be advisable to increase the keepalive timer to help reduce network load. To do this, you enter into config-telephony configuration mode and use the keepalive command followed by the number of seconds in between each sent notification, as shown here: Router#configure terminal Router(config)#telephony-service Router(config-telephony)#keepalive 60 Router(config-telephony)#end Router#
Now your IP phones will send keepalive messages every 60 seconds, and CUCM Express will declare the Cisco phone as deceased after 180 seconds or three missed keepalive messages in a row.
Cisco IP Phone Restart versus Reset When you make modifications to a previously configured CUCM Express, there will be some settings that need to be pushed to your connected Cisco IP phones using either a restart or a full reset of the phone. If this is not done, the phones will not grab the new configuration fi le. The next section covers the difference between a phone restart and reset and when each should be used.
Restart A restart is a partial reset of the Cisco IP phone. The phones connect to the TFTP server and update any changes to the configuration file. This command will update the following information:
Directory numbers (DNs)
Phone buttons
Speed-dial
You have the ability to restart either all of the connected phones or one at a time. If you wish to restart all of the phones, you must be in config-telephony configuration mode and issue a restart all command. Here is an example of the output of this command: Router(config)#telephony-service Router(config-telephony)#restart all Reset 2 phones: at 5 second interval per phone Starting with 7960 phones
c08.indd 329
- This could take several minutes
9/21/11 11:25:01 AM
Chapter 8
330
■
Configuring and Managing CUCM Express
Router(config-telephony)# Reset/Restart-all looking for phones registered as type 30008 7902 Reset/Restart-all looking for phones registered as type 20000 7905 [output omitted] Reset/Restart-all looking for phones registered as type 436 7965 Reset-All: Requesting Restart for phone SEP0021A086D04D at 192.168.10.12 deviceType 436 Idle [count=1] May 2 07:28:51.878: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP0021A086D04D IP:192.168.10.12 Socket:1 DeviceType:Phone has unregistered normally. Reset/Restart-all looking for phones registered as type 30006 7970 [output omitted] Reset/Restart-all looking for phones registered as type 30016 CIPC Reset-All: Requesting Restart for phone SEP001E68E1AFE9 at 192.168.1.15 deviceType 30016 Idle [count=2] May 2 07:29:04.858: %IPPHONE-6-UNREGISTER_NORMAL: ephone-2:SEP001E68E1AFE9 IP:192.168.1.15 Socket:3 DeviceType:Phone has unregistered normally. May 2 07:29:05.250: %IPPHONE-6-REG_ALARM: 23: Name=SEP001E68E1AFE9 Load= 7.0.1.0 Last=Reset-Restart May 2 07:29:06.122: %IPPHONE-6-REGISTER: ephone-2:SEP001E68E1AFE9 IP:192.168.1.15 Socket:3 DeviceType:Phone has registered. Reset/Restart-all looking for phones registered as type 39999 none [output omitted] Reset/Restart-all looking for phones registered as type -1 Unknown Ephone type Restart-All issued for 2 phones
To restart a single phone, you navigate into config-ephone configuration mode and issue the restart command.
Reset The reset command performs a full reboot of the Cisco IP phone. This process requires the phone to go through both the TFTP download and DHCP renewal processes, so it takes more time for the phone to become fully operational within the CUCM Express system. In addition to handling the same three configuration updates that the restart command can perform, the reset command updates the phone if any of the following were added/deleted or modified:
Date/time
Phone fi rmware
CUCM Express source IP address
TFTP download path
Voicemail access number
Just like the restart command, reset can be performed on all phones or a single phone. To reset all phones, you must be in config-telephony configuration mode and issue a reset all command. And for a single ephone, navigate to the ephone you desire and enter a reset command. Here is the command-line output when we reset all the phones on the system:
c08.indd 330
9/21/11 11:25:01 AM
Configuring CUCM Express Telephony Service Features
331
Router(config)#telephony-service Router(config-telephony)#reset all ITS configuration has been changed, selecting sequence-all reset Reset 2 phones: sequentially with 240 second per-phone timeout to guarantee TFTP access - this could take several minutes per phone you may abort this process using ‘reset cancel’ Starting reset sequence with 7960 phones Router(config-telephony)# Reset/Restart-all looking for phones registered as type 30008 7902 Reset/Restart-all looking for phones registered as type 20000 7905 [output omitted] Reset/Restart-all looking for phones registered as type 436 7965 Reset-All: Requesting Reset for phone SEP0021A086D04D at 192.168.10.12 deviceType 436 7965 Idle [count=1] Reset-All received Unregister from ephone-1 SEP0021A086D04D May 2 07:56:31.941: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP0021A086D04D IP:192.168.10.12 Socket:6 DeviceType:Phone has unregistered normally. May 2 07:57:08.905: %MGCP-3-INTERNAL_ERROR: mgcp_cfg_commands: nvgen lawfulintercept: should not happen May 2 07:57:33.149: %IPPHONE-6-REG_ALARM: 25: Name=SEP0021A086D04D Load= SCCP45.8-5-3S Last=Initialized May 2 07:57:33.165: %IPPHONE-6-REGISTER: ephone-1:SEP0021A086D04D IP:192.168.10.12 Socket:1 DeviceType:Phone has registered. Reset sequence-all, Ready to reset next phone (last 61 sec) Reset sequence-all, Ready to reset next phone (last 61 sec) Reset/Restart-all looking for phones registered as type 30006 7970 [output omitted] Reset/Restart-all looking for phones registered as type 30016 CIPC Reset-All: Requesting Reset for phone SEP001E68E1AFE9 at 192.168.1.15 deviceType 30016 CIPC Idle [count=2] Reset-All received Unregister from ephone-2 SEP001E68E1AFE9 May 2 07:57:41.885: %IPPHONE-6-UNREGISTER_NORMAL: ephone-2:SEP001E68E1AFE9 IP:192.168.1.15 Socket:3 DeviceType:Phone has unregistered normally. May 2 07:57:48.545: %IPPHONE-6-REG_ALARM: 22: Name=SEP001E68E1AFE9 Load= 7.0.1.0 Last=Reset-Reset May 2 07:57:50.269: %IPPHONE-6-REGISTER: ephone-2:SEP001E68E1AFE9 IP:192.168.1.15 Socket:3 DeviceType:Phone has registered. Reset sequence-all, Ready to reset next phone (last 8 sec) [output omitted] Reset/Restart-all looking for phones registered as type -1 Unknown Ephone type Reset-All issued for 2 phones
c08.indd 331
9/21/11 11:25:01 AM
332
Chapter 8
■
Configuring and Managing CUCM Express
You can also reset a single phone by navigating into config-ephone configuration mode and issue the reset command. You can also reset a Cisco phone using the handset unit by pressing the Settings button followed by **#** on the keypad.
Using CUCM Express Verification and Troubleshooting Commands When setting up CUCM Express for the first time, you may need some basic troubleshooting skills. This section goes through some of the more common troubleshooting steps, including how to figure out why a Cisco phone won’t register and how to determine the state of an ephone on your network.
Troubleshooting Cisco Phone Registrations There will come a time when you add a new Cisco phone to your CUCM Express environment and it simply will not register. Because you understand the boot process, there is a methodical way of troubleshooting the problem. Here is the order in which troubleshooting should be performed: 1.
Troubleshoot DHCP issues.
2.
Troubleshoot TFTP issues.
3.
Troubleshoot ephone registration issues.
Troubleshooting these three items in order will help you to fi nd and fi x the vast majority of phone registration problems you’ll encounter.
Troubleshooting DHCP Issues When the phone boots up, one of the fi rst things it displays is a “Configuring IP” message. This tells you that the phone is attempting to fi nd the DHCP servers so it can receive the IP address and TFTP information needed to download the fi rmware and configuration fi les. If the IOS device you are on is the DHCP server, you can verify that your phone is receiving DHCP information by using the debug ip dhcp server events command. Here’s an example of the output you will receive when a device successfully receives an IP address from the DHCP server that is configured on your CUCM Express router: Router#debug ip dhcp server events DHCP server event debugging is on. May 17 18:18:54.303: DHCPD: Sending notification of ASSIGNMENT:
c08.indd 332
9/21/11 11:25:02 AM
Using CUCM Express Verification and Troubleshooting Commands
May 17 18:18:54.303: May 17 18:18:54.303: May 17 18:18:54.303:
333
DHCPD: address 192.168.10.2 mask 255.255.255.0 DHCPD: htype 1 chaddr 0021.a086.d04d DHCPD: lease time remaining (secs) = 86400
On a Cisco IP phone, you can verify that your phone received DHCP information by pressing the Settings button and navigating to the Network Configuration area. If your phone is not receiving an IP address, you should start by looking at a possible misconfiguration of DHCP and not of the VoIP fi rmware or CUCM Express.
Troubleshooting TFTP Issues If your phone is receiving DHCP information, the next thing it attempts to do is to download the fi rmware and configuration fi les required to operate. If your phone is stuck with the “Registering” notification on the screen, you can try to run the debug tftp events command to see if your phone is requesting fi les that are not on your TFTP server. Keep in mind that this command is useful only if your router is acting as the TFTP server. Here is an example of the output of this command for a phone that successfully receives some but not all of the requested fi rmware and configuration fi les: Router#debug tftp events TFTP Event debugging is on Router# May 17 18:51:36.855: TFTP: Looking for CTLSEP001E68E1AFE9.tlv May 17 18:51:37.887: TFTP: Looking for SEP001E68E1AFE9.cnf.xml May 17 18:51:37.887: TFTP: Opened system:/its/XMLDefaultCIPC.cnf.xml, fd 9, size 1056 for process 248 May 17 18:51:37.891: TFTP: Finished system:/its/XMLDefaultCIPC.cnf.xml, time 00:00:00 for process 248 May 17 18:51:42.315: TFTP: Looking for Communicator/LdapDirectories.xml May 17 18:51:43.423: TFTP: Looking for Communicator/LdapDialingRules.xml May 17 18:51:49.823: TFTP: Looking for SEP001E68E1AFE9.cnf.xml May 17 18:51:49.823: TFTP: Opened system:/its/XMLDefaultCIPC.cnf.xml, fd 9, size 1056 for process 248 May 17 18:51:49.827: TFTP: Finished system:/its/XMLDefaultCIPC.cnf.xml, time 00:00:00 for process 248 May 17 18:51:50.035: TFTP: Looking for CTLSEP001E68E1AFE9.tlv May 17 18:51:50.043: TFTP: Looking for English_United_States/ipc-sccp.jar May 17 18:51:50.059: TFTP: Looking for CTLSEP001E68E1AFE9.tlv May 17 18:51:50.063: TFTP: Looking for United_States/g3-tones.xml May 17 18:51:50.315: %IPPHONE-6-REG_ALARM: 25: Name=SEP001E68E1AFE9 Load= 7.0.1.0 Last=Initialized May 17 18:51:51.791: %IPPHONE-6-REGISTER: ephone-1:SEP001E68E1AFE9 IP:192.168.10.4 Socket:1 DeviceType:Phone has registered. Router#
c08.indd 333
9/21/11 11:25:02 AM
334
Chapter 8
■
Configuring and Managing CUCM Express
Any line that begins with “Looking” means that the Cisco phone is requesting the file. If the TFTP server knows where a file is located, it will process the file, giving you the “Opened” statement. Finally, once the file is transferred, you will receive a “Finished” message. As you can see in the sample output, this phone registered to the CUCM Express even though it did not receive all of the files it requested. Some of the files, such as LdapDirectories.xml, are supplementary services that do not affect phone registration. The TFTP server did manage to serve up the required files for the phone to register on the system.
If your phones are not receiving the necessary fi rmware or configuration fi les, you should make sure that your TFTP server is configured to serve up the fi les your phone is requesting. To do so, you can issue a show telephony-service tftp-bindings command. Here’s a sample of typical output from this command: Router#show telephony-service tftp-bindings tftp-server system:/its/united_states/7960-tones.xml alias United_States/7960tones.xml tftp-server system:/its/united_states/7960-font.xml alias English_United_ States/7960-font.xml tftp-server system:/its/united_states/7960-font.xml alias English_United_ States/7920-font.xml tftp-server system:/its/united_states/7960-dictionary.xml alias English_United_ States/7960-dictionary.xml tftp-server system:/its/united_states/7960-kate.xml alias English_United_ States/7960-kate.xml tftp-server system:/its/united_states/7960-kate.xml alias English_United_ States/7920-kate.xml tftp-server system:/its/united_states/SCCP-dictionary.xml alias English_United_ States/SCCP-dictionary.xml tftp-server system:/its/SEPDEFAULT.cnf alias SEPDefault.cnf tftp-server system:/its/XMLDefault.cnf.xml alias XMLDefault.cnf.xml tftp-server system:/its/ATADefault.cnf.xml alias ATADefault.cnf.xml tftp-server system:/its/XMLDefaultCIPC.cnf.xml alias SEP001E68E1AFE9.cnf.xml tftp-server system:/its/XMLDefault7965.cnf.xml alias SEP0021A086D04D.cnf.xml
If there are any fi les that are being requested and not listed by this command, you should locate them on your flash storage and serve them up using the tftp-server configuration command.
Determining the State of an Ephone Once your phones are configured and registered on your CUCM Express system, you’ll want to familiarize yourself with the show ephone command, because it provides a wealth
c08.indd 334
9/21/11 11:25:03 AM
Using CUCM Express Verification and Troubleshooting Commands
335
of information that can prove very useful when troubleshooting. First, we’ll look at the different registration states you will see.
Ephone Registration States There are three different states that an ephone can be in. Table 8.7 lists the states and what each state means. TA B L E 8 . 7
Ephone registration states
State
Meaning
REGISTERED
Indicates the phone is registered to CUCM Express and is active.
UNREGISTERED
Indicates the phone unregistered normally from CUCM Express and is not active.
DECEASED
Indicates the phone is unregistered abnormally because of a keepalive timeout.
Let’s look at all three of these states by issuing the show ephone command: Router#show ephone ephone-1[0] Mac:0021.A086.D04D TCP socket:[-1] activeLine:0 DECEASED mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 51055 7965 keepalive 8 max_line 6 button 1: dn 1 number 4001 CH1 DOWN Preferred Codec: g711ulaw
ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:0 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 6 max_line 6 button 1: dn 2 number 4002 CH1 IDLE Preferred Codec: g711ulaw ephone-3[2] Mac:001E.68E1.AFE9 TCP socket:[1] activeLine:0 UNREGISTERED mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:1 caps:8 IP:192.168.10.14 1556 CIPC keepalive 127 max_line 8 button 1: dn 1 number 4003 CH1 DOWN Preferred Codec: g711ulaw
c08.indd 335
9/21/11 11:25:03 AM
336
Chapter 8
■
Configuring and Managing CUCM Express
There are three ephones configured on this CUCM Express system. Ephone-1 is in a DECEASED state, which means that CUCM Express has lost contact with the switch. CUCM Express uses keepalives to monitor the state of the phones. After six missed keepalive messages, the phone is placed into a DECEASED state. This typically happens when a phone loses power. Ephone-2 is in a REGISTERED state. This means that this phone is operational on the network and is ready to make and receive calls. Lastly, ephone3 is in an UNREGISTERED state. This state means that the phone gracefully unregistered from the CUCM Express. You can see the type of phone this is on the third line from the bottom, where it says the phone hardware is CIPC. Given that ephone-2 is a Cisco IP Communicator, the phone probably unregistered when the user exited the application.
Ephone Extension States A second piece of information that can be gained from the show ephone command is the state of a phone extension. There are six ephone extension states that an ephone extension can have. Table 8.8 provides a description of each of these states. TA B L E 8 . 8
Ephone extension states Ephone Registration State
Description
N/A
Unregistered/ Deceased
Ephone is not registered to CUCM Express.
IDLE
On-hook
Registered
Ephone is ready to make and receive calls.
SEIZE
Off-hook
Registered
Ephone handset has been picked up but no call has been made.
RINGING
Off-hook
Registered
Ephone is calling another extension.
ALERTING
On-hook
Registered
Ephone is receiving a call from another extension.
CONNECTED
Off-hook
Registered
An active call is in progress between two or more extensions.
State
On- or Off-hook
DOWN
Let’s look at the show ephone command to see what each of the ephone extension states looks like while we go through the process of ephone registration and call processing.
c08.indd 336
9/21/11 11:25:03 AM
Using CUCM Express Verification and Troubleshooting Commands
337
Ephone Extension DOWN State The two following examples of ephone extensions show that the ephone registration process is in either a DECEASED or an UNREGISTERED state for the extensions to be in a DOWN state: ephone-1[0] Mac:0021.A086.D04D TCP socket:[-1] activeLine:0 DECEASED mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 51055 7965 keepalive 8 max_line 6 DOWN button 1: dn 1 number 4001 CH1 Preferred Codec: g711ulaw ephone-3[2] Mac:001E.68E1.AFE9 TCP socket:[1] activeLine:0 UNREGISTERED mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:1 caps:8 IP:192.168.10.14 1556 CIPC keepalive 127 max_line 8 DOWN button 1: dn 1 number 4003 CH1 Preferred Codec: g711ulaw
Ephone Extension IDLE State A phone is ready to either make or receive calls when the extension is in an IDLE state. In order for this to happen, the ephone must be properly REGISTERED to CUCM Express, as shown here: ephone-1[0] Mac:0021.A086.D04D TCP socket:[1] activeLine:0 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 52084 7965 keepalive 0 max_line 6 IDLE button 1: dn 1 number 4001 CH1 Preferred Codec: g711ulaw
Ephone Extension SEIZE State When an end user on ephone-2 wishes to make a call, they pick up the handset of the phone. As you know, this action changes the phone from an on-hook state to an off-hook state. This is called a line seizure. When this happens, the show ephone command has the ephone extension in a SEIZE state, as shown here: ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 16 max_line 6 SEIZE button 1: dn 2 number 4002 CH1
c08.indd 337
9/21/11 11:25:04 AM
338
Chapter 8
■
Configuring and Managing CUCM Express
Preferred Codec: g711ulaw Active Call on DN 2 chan 1 :4002 0.0.0.0 0 to 0.0.0.0 0 via 0.0.0.0 G711Ulaw64k 160 bytes no vad Tx Pkts 0 bytes 0 Rx Pkts 0 bytes 0 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn -1
Ephone Extension RINGING and ALERTING States Let’s say that a user picks up a phone and dials an extension. Once that process reaches the CUCM Express, the phone where the user called from is put into a RINGING state. At this point the CUCM Express sends back the audible ringing tone through the phone handset to indicate that the call is being processed, and the user is just waiting for the called party to pick up their handset to complete the call. At the same time, the called phone goes into an ALERTING state. In this state the called phone is on-hook but ringing to alert the end user that someone is attempting to speak with them. The show ephone output looks like this: ephone-1[0] Mac:0021.A086.D04D TCP socket:[1] activeLine:0 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:0 ringing:1 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 52084 7965 keepalive 1 max_line 6 RINGING button 1: dn 1 number 4001 CH1 Preferred Codec: g711ulaw call ringing on line 1
ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 17 max_line 6 ALERTING button 1: dn 2 number 4002 CH1 Preferred Codec: g711ulaw Active Call on DN 2 chan 1 :4002 0.0.0.0 0 to 0.0.0.0 0 via 0.0.0.0 G711Ulaw64k 160 bytes no vad Tx Pkts 0 bytes 0 Rx Pkts 0 bytes 0 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn 1
Ephone Extension CONNECTED State The remote phone rings, and the end user picks up the phone to answer it. At this point, the CUCM Express places both calls into a CONNECTED state. You can also see in the show ephone command that it lists the source and destination IP addresses:
c08.indd 338
9/21/11 11:25:04 AM
Summary
339
ephone-1[0] Mac:0021.A086.D04D TCP socket:[1] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:1 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 52084 7965 keepalive 2 max_line 6 CONNECTED button 1: dn 1 number 4001 CH1 Preferred Codec: g711ulaw Active Call on DN 1 chan 1 :4001 192.168.10.12 25848 to 192.168.10.13 23436 via 192.168.10.12
G711Ulaw64k 160 bytes no vad Tx Pkts 219 bytes 37668 Rx Pkts 219 bytes 37668 Lost 0 Jitter 0 Latency 0 callingDn 2 calledDn -1
ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:1 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 18 max_line 6 CONNECTED button 1: dn 2 number 4002 CH1 Preferred Codec: g711ulaw Active Call on DN 2 chan 1 :4002 192.168.10.13 23436 to 192.168.10.12 25848 via 192.168.10.13
G711Ulaw64k 160 bytes no vad Tx Pkts 470 bytes 80840 Rx Pkts 468 bytes 80496 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn 1
Summary At its core, the CUCM Express system is a voice gateway with the capability of providing call-processing services for up to 450 phones. It is a unique system that can handle most unified communications voice functionalities in a single IOS system. CUCM Express is often found in small and medium-size businesses but also can be found in large-network remote sites that use a distributed call-processing model. This chapter covered many of the steps that must be accomplished before implementing a voice system, including everything from power options to voice VLANs and even services used by IP phones, including DHCP, NTP, and TFTP. The chapter continued to describe CUCM Express’s hardware and software licensing requirements as well as how to configure SCCP and SIP endpoints.
c08.indd 339
9/21/11 11:25:05 AM
340
Chapter 8
■
Configuring and Managing CUCM Express
Exam Essentials Know the three different power options for IP phones. The power brick is attached to the phone and plugs directly into the wall outlet. A power patch panel or power injector sits between an IP phone and a standard non-PoE switch. Power is sent to the phone over the same cable that voice traffic resides on. Finally, the PoE switch offers power directly from the switch to the phone over an Ethernet cable. Understand the different PoE proprietary and IETF standards for IP phones and PoE switches. The Cisco proprietary method is ILP and the IETF standard is 802.3af. Know how to manipulate power requirements for your IP phone deployment for PoE switches. Using Cisco’s intelligent power management, you can set switchports to disable power, assign a static amount, or have the switch intelligently determine the power requirements of the PoE endpoint. Understand the difference between data and voice VLANs. Cisco switches use CDP to identify Cisco IP phones on the network. Voice VLANs are configured differently at the switchport level. Finally, voice VLANs are tagged on the switchport, while any PC that is connected to a switch or Cisco IP phone is untagged. Know how to configure DHCP for VoIP support. Cisco IP phones rely heavily on DHCP servers for information such as IP address, default-router, DNS, and the location of IP phone configuration fi les by defi ning the option 150 parameter for a TFTP server. Understand the purpose of NTP and how to configure it. NTP is used to synchronize time for all of your phone equipment on the network. Synchronization of time helps to ensure proper operation and support of your VoIP network. Understand CUCM Express hardware and software capabilities. The maximum number of IP phones that can be supported depends on the ISR model you are working with. Once you have an ISR router set up with CUCM Express IOS software, it can be configured to be used as a call-processing agent, voice gateway, voicemail server, and IP router in a single system. Understand the three CUCM Express licenses and the new software activation method. Cisco has three different licenses for CUCM environments. One license is for the voice-capable IOS. The second is the CUCM Express feature license. The third is the individual user license. Currently, software is licensed as a right-to-use license. The new model will be one that is activated automatically in software. Know how to configure the mandatory CUCM Express system configuration settings using the command line. The mandatory configuration settings to get a CUCM Express router ready for operation to run SCCP are to specify a source IP address of the call-processing agent, set the max ephones and ephone-DNs, and set the fi rmware load fi les and default configuration fi les. For SIP phones, you must first enable SIP and SIP-to-SIP calls, then
c08.indd 340
9/21/11 11:25:05 AM
Written Lab 8.1
341
specify a source IP address of the call-processing agent, set the max pool and max DNs, and set the fi rmware load fi les and default configuration fi les. Understand what the auto-assign configuration command does. Auto-assign allows you to set up a pool of ephone-DNs. When Cisco IP phones connect to CUCM Express for the fi rst time, the auto-assign function registers the ephone. It maps an ephone-DN taken from the pool to the MAC address of the phone. This functionality is a great way to partially automate a phone rollout. Understand the difference between the telephony-service restart and reset commands. Restart is a quick reset of the phone. It is good to use when you make changes to the configuration fi le, including changes to DNs, phone buttons, and speed dial. Reset is a full boot of the phone. This command causes the phone to go through a DHCP renewal process. It is also required when you change global parameters such as date/time, CUCME source IP, and TFTP download path. Know how to configure different DN line options. Key system phones are typically configured identically and share DNs. PBX systems are configured with unique DNs on each phone and are individually tailored to meet the needs of the user. Understand the different types of ephone button options. Using the button separator when configuring extensions lets you set various ring options, phone monitoring, and overlay features. Know how to configure your CUCM Express system to meet the needs of your users. Depending on where you set up your CUCM Express, you may need to modify user options to match the native language. In addition, you can modify the network options to match the PSTN tone and cadence that are familiar to the area, and you can modify CUCM Express to display the date and time in a familiar format. Know how to troubleshoot CUCM Express registration and extension states. Understand how to best troubleshoot registration and extension problems using command-line debug and show commands.
Written Lab 8.1 1.
What interface command assigns a switchport to voice VLAN 55?
2.
What DHCP server command removes the fi rst 20 IP addresses from being included in the DHCP pool on the 192.168.10.0/24 network?
3.
What configuration command tells CUCM Express to serve up the flash:/ phone/7945-7965/SCCP45.8-5-2-27.sbn fi le via TFTP?
c08.indd 341
4.
What config-telephony command sets the SCCP source IP address for the CUCM Express system to 172.16.55.100?
5.
What config-telephony command sets the maximum number of ephones to 30?
6.
What config-telephony command sets the maximum number of ephone-DNs to 50?
9/21/11 11:25:06 AM
342
Chapter 8
■
Configuring and Managing CUCM Express
7.
What is the config-register-pool command to configure SIP voice register DN 5 on button 2?
8.
What is the config-ephone command to configure ephone-DN 1 on button 2 and DN 2 on button 1?
9.
What is the config-ephone command to assign button 2 to ephone-DN 8 and have it use an alternate ring?
10. What is the config-ephone-dn command to set a DN to be more preferred than a DN
that has its preference set to 2? (The answers to Written Lab 8.1 can be found following the answers to the review questions for this chapter.)
Hands-On Labs To complete the labs in this section, you need a CUCM Express router and two Cisco IP phones. The phones used in this example are 7940s, but you can use any phone or the IP Communicator softphone if you wish. The labs will follow the logical network design shown in Figure 8.10. F I G U R E 8 .1 0
CUCM Express lab diagram
Telephony source IP: 192.168.10.1 Ext. 444 CUCM Express
Ext. 555
These labs build on each other, so it is best to perform them in the order listed: Lab 8.1: Configuring CUCM Express as a TFTP Server Lab 8.2: Configuring CUCM Express for Basic SCCP Phone Operation Lab 8.3: Verifying the Configuration and Status of your Ephones
Hands-On Lab 8.1: Configuring CUCM Express as a TFTP Server In this lab, we are going to add 7940 phones to our voice network. In order for them to work properly, we need to configure the CUCM Express router as a TFTP server to serve up the fi rmware fi les that the 7940 phones require.
c08.indd 342
9/21/11 11:25:06 AM
Hands-On Labs
1.
Log into your CUCM Express router and go into privileged execution configuration mode by typing enable.
2.
Check to see which fi rmware fi les the 7940 phones need by viewing the fi les on the flash drive. To do this, type dir flash:/phone/7940-7960. You should see something similar to the following output:
343
Directory of flash:/phone/7940-7960/ 97 98 99 100
-rw-rw-rw-rw-
129824 458 705536 130228
Mar Mar Mar Mar
7 7 7 7
2011 2011 2011 2011
18:14:31 18:14:31 18:14:34 18:14:34
+00:00 +00:00 +00:00 +00:00
P00308000500.bin P00308000500.loads P00308000500.sb2 P00308000500.sbn
3.
Enter into configuration mode by typing configure terminal.
4.
Configure the CUCM Express router to serve up the 7940 fi rmware fi les. Note that because the fi les are organized in a directory structure, you need to include the alias command: tftp-server tftp-server tftp-server tftp-server
5.
flash:/phone/7940-7960/P00308000500.bin alias P00308000500.bin flash:/phone/7940-7960/P00308000500.loads alias P00308000500.bin flash:/phone/7940-7960/P00308000500.sb2 alias P00308000500.bin flash:/phone/7940-7960/P00308000500.sbn alias P00308000500.bin
Exit configuration mode by typing end.
Hands-On Lab 8.2: Configuring CUCM Express for Basic SCCP Phone Operation In our second lab, we will go through the basic configuration necessary to get our two Cisco 7940 phones up and running on the voice network. We will set our max-ephones to 5 and max-dn to 10. Additionally, we will set the preferred codec to g729r8. 1.
Log into your CUCM Express router and go into privileged execution configuration mode by typing enable.
2.
Enter into config-telephony configuration mode by typing configure terminal and then telephony-service.
3.
Configure the IP source address to the address given in the diagram by typing ip source-address 192.168.10.1.
c08.indd 343
4.
Configure the maximum ephones to 5 and maximum ephone-DNs to 10 by typing max-ephones 5, pressing Enter, and then typing max-dn 10.
5.
Set the fi rmware load fi les for the 7940 phones by typing load 7940-7960 PPPPPPPP. loads, where PPPPPPPP is the load fi lename for your particular Cisco phone.
9/21/11 11:25:07 AM
344
Chapter 8
■
Configuring and Managing CUCM Express
6.
Exit config-telephony configuration mode by typing exit.
7.
Configure ephone-DN 1 to have the number 444 by typing ephone-dn 1 and then number 444.
8.
Configure ephone-DN 2 to have the number 555 by typing ephone-dn 2 and then number 555.
9.
Configure the MAC address of ephone 1 by typing ephone 1, pressing Enter, and then typing mac-address XXXX.XXXX.XXXX. Your MAC address will be unique.
10. Configure the MAC address of ephone 2 by typing ephone 2, pressing Enter, and then
typing mac-address XXXX.XXXX.XXXX. Your MAC address will be unique. 11. Configure button 1 of ephone 1 to use ephone-DN 1 by typing ephone 1, pressing
Enter, and then typing button 1:1. 12. Configure the phone type and codec preference by typing type 7940, pressing Enter,
and then typing codec g729r8. 13. Configure button 1 of ephone 2 to use ephone-DN 2 by typing ephone 2, pressing
Enter, and then typing button 1:2. 14. Configure the phone type and codec preference by typing type 7940, pressing Enter,
and then typing codec g729r8. 15. Exit config-ephone configuration mode by typing end.
Hands-On Lab 8.3: Verifying the Configuration and Status of Your Ephones Now that we have our phones properly configured, we can verify our configuration settings and check to see if the phones are connected. 1.
Log into your CUCM Express router and go into privileged exec configuration mode by typing enable.
2.
Verify the configuration and status of your ephones by typing show ephone and reviewing the output of this command. An example of the output you should see is listed here:
Router#show ephone ephone-1[0] Mac: 0021.A086.D04D TCP socket:[5] activeLine:0 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.12 50271 7940 keepalive 6 max_line 2 button 1: dn 1 number 444 CH1 IDLE
c08.indd 344
9/21/11 11:25:07 AM
Hands-On Labs
345
Preferred Codec: g729r8 ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:0 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:0 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7940 keepalive 6 max_line 2 button 1: dn 2 number 555 CH1 IDLE Preferred Codec: g729r8
3.
4.
c08.indd 345
From a configuration standpoint, you should verify that the CUCM Express properly sees the following information:
Telephone model type (in this example, Cisco 7940)
Button and DN numbers (button 1: dn1 for ephone 1 and button 1: dn2 for ephone 2)
Extension numbers (number 444 for ephone 1 and number 555 for ephone 2)
Preferred codec (g729r8)
From an operational standpoint, you should verify that the phones are in a REGISTERED and IDLE state (assuming the phones are not in use).
9/21/11 11:25:08 AM
Chapter 8
346
■
Configuring and Managing CUCM Express
Review Questions 1.
An ILP PoE switch can power devices of up to how many watts? A. 6.0W
2.
B.
15.4W
C.
6.3W
D.
7.0W
What protocol does a Cisco IP phone use to tell the PoE switch how much power it requires for the phone? A. PoE protocol
3.
B.
iLBC
C.
VTP
D.
STP
E.
CDP
What Cisco power-saving method helps to negotiate the exact power requirements of a Cisco IP phone? A. IPM B.
4.
802.3af
C.
ILP
D.
CDP
Why is it important to configure DHCP option 150 for Cisco voice networks? A. It defines the default gateway for the phone.
5.
B.
It defines the IP address of the TFTP server.
C.
It defines the IP address of the communications manager.
D.
It defines the IP address for CDP.
Which of the following is not a CUCM Express license? A. Cisco SCCP license
6.
B.
Cisco IOS license for voice capabilities
C.
CUCM Express feature licenses
D.
Individual user license
What is the tftp-server IOS command used for? A. To identify the IP address of the TFTP server
c08.indd 346
B.
To set option 150 for DHCP clients
C.
To identify files the router serves via TFTP
D.
To enable Secure FTP
9/21/11 11:25:08 AM
Review Questions
7.
347
What command is used to manually update the phone configuration load files on a CUCM Express system configured for SCCP endpoints? A. create firmware
8.
B.
create cnf-files
C.
load cnf-files
D.
load firmware
Which of the following required commands is missing from the CUCM Express initial configuration for SCCP endpoints? A. ip source-address 192.168.1.1
9.
B.
create profile
C.
source-address 192.168.1.1
D.
auto assign
When configuring SIP to control signaling to IP phone endpoints, which of the following commands is used to set 120 as the maximum number of telephone extensions that can be configured on the system? A. Router(config-register-global)#max-pool 120 B.
Router(config-telephony)#max-ephones 120
C.
Router(config-telephony)#max-dn 120
D.
Router(config-register-global)#max-dn 120
10. Which of the following CUCM Express dial number line options are not compatible when the end device is running SIP? (Choose all that apply.) A. Single-line B.
Dual-line
C.
Octo-line
D.
Shared-line
E.
Two DNs with one telephone
11. What line type and button type does this configuration represent? Router(config)#ephone 1 Router(config-ephone)#button 1o1,5,6 Router(config-ephone)#ephone 2 Router(config-ephone)#button 1o2,5,6 Router(config-ephone)#end
A. Shared-line, octo-line
c08.indd 347
B.
Huntgroup
C.
Two DNs with one telephone
D.
Shared-line, overlay
E.
Shared-line, extension-line
9/21/11 11:25:09 AM
Chapter 8
348
■
Configuring and Managing CUCM Express
12. When configuring SIP to control signaling to IP phone endpoints, which of the following commands is used to create the default configuration load file? A. Router(config-register-global)#create cnf-files B.
Router(config-telephony)#create cnf-files
C.
Router(config-register-global)#create profile
D.
Router(config-telephony)#create profile
13. Which command-line operation does a quick reset of all phones currently registered on a CUCM Express system using a single command? A. Router(config-telephony)#restart reset B.
Router(config-ephone)#restart all
C.
Router(config-telephony)#restart all
D.
Router(config-ephone)#restart reset
E.
Router(config-ephone)#reset all
F.
Router(config-telephony)#reset
14. When troubleshooting a Cisco phone that powers up and connects to the network but will not register, what is the first logical thing to check? A. Ensure that the proper firmware and configuration files are accessible to the phone. B.
Ensure that the ephone is properly configured in the CUCM Express configuration.
C.
Make sure that the phone is receiving the correct IP address and other network parameters through DHCP.
D.
Check to see if the clock is properly synchronized with NTP.
15. When viewing show ephone output like the following, what does ALERTING mean on the extension? ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:1 REGISTERED in SCCP ver 12/9 mediaActive:0 offhook:1 ringing:0 ringRate: 0 reset:0 reset_sent:0 paging 0 debug:0 caps:9 IP:192.168.10.13 50271 7965 keepalive 17 max_line 6 button 1: dn 2 number 4002 CH1 ALERTING Preferred Codec: g711ulaw Active Call on DN 2 chan 1 :4002 0.0.0.0 0 to 0.0.0.0 0 via 0.0.0.0 G711Ulaw64k 160 bytes no vad Tx Pkts 0 bytes 0 Rx Pkts 0 bytes 0 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn 1
A. The phone is currently in a call. B.
c08.indd 348
The phone is on-hook.
C.
The phone is calling another extension.
D.
The phone is receiving a call.
9/21/11 11:25:09 AM
Review Questions
349
16. With multiple ephone-DNs sharing a single number, what command can you use to prioritize which ephone-DN will always receive the incoming call if it is not in use? A. priority B.
preference
C.
state
D.
no huntstop
17. With multiple ephone-DNs sharing a single number when the phone preference for each ephone-DN is the same, how is call routing handled for incoming calls? A. Calls will be received on the ephone-DN with the lowest tag. B.
This configuration will not work. The ephone-DNs must be configured with different priorities.
C.
Calls will be received on the ephone with the lowest tag.
D.
Calls will be handled round-robin style.
18. What ephone overlay button separator would you use if you want calls to come in on this extension only when all other lines are busy? A. o B.
c
C.
w
D.
x
E.
m
19. What is the term used to describe the configuration of multiple ephone-DNs on a single physical phone button? A. Ephone B.
Ephone-DN
C.
Dual-line
D.
Call waiting
E.
Overlay
20. What configuration option can you change so that Cisco phones will display information on the screen in a different language? A. network-locale
c08.indd 349
B.
language-locale
C.
user-locale
D.
telephony-service-locale
9/21/11 11:25:09 AM
350
Chapter 8
■
Configuring and Managing CUCM Express
Answers to Review Questions 1.
C. An ILP PoE switch provides a fi xed 6.3W of power to capable devices.
2.
E. The Cisco Discovery Protocol (CDP) is used to discover IP phones and negotiate power options.
3.
A. Cisco Intelligent Power Management works between Cisco PoE switches and Cisco IP phones to negotiate and allocate the exact amount of power needed by the phone.
4.
B. Option 150 defi nes the IP address of the TFTP server, where the phone can download configuration fi les.
5.
A. You need a license for the voice IOS, the CUCME software for a specific number of endpoints, and the individual user licenses for endpoints.
6.
C. The tftp-server command is used to specify fi les that the router can serve to clients using TFTP.
7.
B. You manually update configuration SCCP load fi les using the create cnf-files command.
8.
A. The initial configuration must include the ip source-address 192.168.1.1 command to identify the IP address of the call-processing agent to the Cisco IP phones.
9.
D. The max-dn command specifies the number of telephone extensions that can be operated on CUCM Express. This command is entered while in config-register-global configuration mode.
10. B, C. The dual- and octo-lines are possible only when SCCP is used between the CUCM Express and IP phone. 11. D. The configuration shows two ephones with a shared-line and overlay button. 12. C. The create profile command is used to build the default configuration load fi le for SIP endpoints. This command is entered while in config-register-global configuration mode. 13. C. The restart all command within config-telephony configuration mode performs a quick reset of all registered phones. 14. C. When a phone powers up and connects to the network, its first task is to receive network parameters such as an IP address, gateway, subnet mask, and the option 150 parameter. If your phone is not receiving one or more of these, it will fail to register properly. 15. D. Alerting means that someone is trying to call that ephone-DN, but the user has not yet picked up the handset. 16. B. The preference command allows you to set which ephone-DN will receive all calls when not in use. The lower number is the more preferred ephone-DN.
c08.indd 350
9/21/11 11:25:10 AM
Answers to Review Questions
351
17. D. If preferences are the same, then calls will be handled in a round-robin manner. 18. D. The expansion (x) line button separator helps prevent a caller from receiving a busy signal. The calls will go to this line only when all other lines are busy. 19. E. An overlay line is a phone button separator configuration option that allows you to configure multiple ephone-DNs on a single phone button. 20. C. The user-locale option allows you to change the language displayed on the LCD screens of Cisco IP phones.
c08.indd 351
9/21/11 11:25:10 AM
352
Chapter 8
■
Configuring and Managing CUCM Express
Answers to Written Lab 8.1 1.
switchport voice vlan 55
2.
ip dhcp excluded address 192.168.10.1 192.168.10.20
3.
tftp-server flash:/phone/7945-7965/SCCP45.8-3-2-27.sbn alias SCCP45.8-3-2-27.sbn
4.
ip source-ip 172.16.55.100
5.
max-ephones 30
6.
max-dn 50
7.
number 2 dn 5
8.
button 1:2 2:1
9.
button 2f8
10. preference 1 (or preference 0, which is the default)
c08.indd 352
9/21/11 11:25:10 AM
Chapter
9
Advanced Voice Gateway Features THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe a dial plan. ■
Describe path selection.
■
Describe calling privileges.
Describe the basic operation and components involved in a VoIP call. ■
Describe VoIP call flows.
Describe the components of a gateway. ■
Describe dial peers and the gateway call routing process.
Implement a gateway.
c09.indd 353
■
Configure digit manipulation.
■
Implement fax support on a gateway.
9/21/11 11:25:35 AM
We’re at the point in this study guide where we begin to expand the capabilities of the IOS voice gateway and CUCM Express to see what value-added features can be implemented. In Chapter 9, we will investigate several scenarios that require you to go beyond basic IP and voice configuration to further enhance the voice experience. We will begin by configuring DTMF relay support to improve the reliability of DTMF tones on an IP network. We will then cover the still-important topic of fax machines and modems. These devices still need to be supported, and you’ll see how to implement that on a voice gateway. Finally, you’ll learn how to implement failover, toll bypass, and call-restriction techniques.
Configuring DTMF Relay Support By default, H.323, SIP, and MGCP transport DTMF tones in band. This means the tones are sent in standard RTP voice packets just as if they were part of a regular voice stream. This method may work fi ne for you, but if you are using highly compressed codecs, the tones may not be reconstructed accurately enough and you’ll run into connection problems. For example, when using interactive voice response (IVR) services, it is critical that when the calling party presses a number to direct them through the IVR menu system, the number is correctly interpreted by the system so the call can be properly routed. To make sure that DTMF tones are correctly interpreted, you can configure DTMF tones to be sent out of band using specially crafted RTP packets, while using a codec with lower compression to ensure that the digit tones are better replicated at the opposite end. This section will show how to configure DTMF relay support for H.323, SIP, and MGCP.
Configuring H.323 DTMF Relay H.323 DTMF relay is configured while in config-dial-peer configuration mode. To enable sending of DTMF tones out of band, you simply use the dtmf-relay command followed by the DTMF method you wish to use. For H.323 the possible relay options are these: This method uses a Cisco proprietary method of transporting DTMF tones in special RTP packets.
cisco-rtp
c09.indd 354
9/21/11 11:25:36 AM
Configuring DTMF Relay Support
355
h245-alphanumeric This method uses the H.245 alphanumeric user input method for specifying only dial-pad tones, namely, 0–9, *, #, and the A–D buttons that are represented as ASCII characters.
This uses the H.245 tone signal method that sends the same dial-pad tones in ASCII format as the h245-alphanumeric method does. The h245-signal method also sends along the length of time that the button was pressed, which is sometimes necessary.
h245-signal
rtp-nte This method uses the named telephone event defi ned in RFC 2883, which specifies a standard method for transporting DTMF tones in RTP packets. One optional keyword that is compatible with H.323 is digit-drop, which will explicitly drop the inband tones from being sent. Without this command, the DTMF tones will be sent both in and out of band.
The remote end gateway that you are communicating with must also be configured to use one of these out-of-band signaling methods. When you configure DTMF relay on a dial peer, you can specify one or more DTMF relay methods. The order of priority is determined by the router, and the order in which you configure them has no effect. Cisco rates the order of priority as follows: 1.
cisco-rtp
2.
rtp-nte
3.
h245-signal
4.
h245-alphanumeric
As an example of how this works, we will configure VoIP dial peer 100 to use both H245 alphanumeric and H245 signal methods: Router#configure terminal Router(config)#dial-peer voice 100 voip Router(config-dial-peer)#dtmf-relay h245-alphanumeric h245-signal Router(config-dial-peer)#end Router#
So now our voice gateway is configured to use either H.323 alphanumeric or H.245 signal methods. But even though H.245 alphanumeric was entered in the command fi rst, the gateway will still prefer to use H.245 signal.
Configuring SIP DTMF Relay Configuration of DTMF relay using SIP is similar to the H.323 configuration, except that your dial peer must specifically have the session protocol sipv2 command to enable SIP; by contrast, H.323 is enabled by default. One DTMF relay method is compatible with both
c09.indd 355
9/21/11 11:25:37 AM
356
Chapter 9
■
Advanced Voice Gateway Features
SIP and H.323. The dtmf-relay rtp-nte command is the relay method the two signaling protocols use. The optional digit-drop keyword is also a valid SIP command to drop the in-band tones. The second DTMF relay method is unique to SIP: sip-notify This SIP-only DTMF relay method specifies that out-of-band DTMF tones
are sent in SIP-notify messages between remote voice gateways. Both DTMF relay methods can be configured, with the priority method being rtp-nte. Here’s an example of how to configure SIP signaling on VoIP dial peer 200 to use only the rtp-nte method that will also drop in-band DTMF tone digits: Router#configure terminal Router(config)#dial-peer voice 200 voip Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#dtmf-relay rtp-nte digit-drop Router(config-dial-peer)#end Router#
Configuring MGCP DTMF Relay DTMF relay support for the MGCP voice gateway signaling protocol can be configured in one of two ways. Remember that MGCP relies heavily on the call-processing agent and in many cases simply does what the call-processing agent asks of it. Along the same lines, DTMF relay and relay negotiation can be completely handled by the call agent (CA), so the voice gateway is oblivious to the process. It simply passes messages between the DTMF relay endpoints. If you want, however, you can configure the voice gateway (GW) to have control of the DTMF relay configuration and negotiation process with the remote end gateway. This is useful when you don’t want to completely rely on the call-processing agent for signaling. To configure DTMF relay for MGCP, you must globally enter the mgcp dtmf-relay voip codec command followed by either the low-bit-rate or all keyword to specify what codecs can be used. You then issue the mode keyword, followed by either nte-gw or nte-ca to specify whether the gateway or call agent handles DTMF relay functions. Finally, you must enable the dtmf-package if you are using the voice gateway for DTMF negotiations. The following example shows how to configure the RFC 2833 standard DTMF relay method, letting the voice gateway negotiate the relay method using any voice codec: Router#configure terminal Router(config)#mgcp dtmf-relay voip codec all mode nte-gw Router(config)#mgcp package-capability dtmf-package Router(config)#end Router#
c09.indd 356
9/21/11 11:25:37 AM
Configuring Fax Support
357
Configuring Fax Support Voice on an IP network oftentimes uses codecs that provide voice payload compression. The greater the compression, the less bandwidth is consumed on a network. While many compression methods work fine for the human voice, the same cannot be said for fax transmissions. Fax transmissions are far more sensitive to the loss of fidelity that compression cannot replicate on the other end. Additionally, VAD and echo cancellation, which save bandwidth and improve the quality of voice calls, have a negative impact on fax transmissions. The result of using a fax machine over a compressed voice circuit with VAD and echo cancellation is that faxes come out garbled and incomplete. Fortunately, we can choose from three options that can utilize an IP network while providing consistent and reliable transmissions from one fax machine to another. There are three different fax service over IP methods that we can implement:
Fax relay
Fax pass-through
T.37 store-and-forward fax
In the following sections, we will cover the differences between the three fax service methods and show how to configure them.
Understanding Fax Relay Fax relay is the VoIP fax transmission technique that has been around the longest of the three possible methods. The analog fax transmissions are terminated at the voice gateway, which then demodulates, packetizes, and retransmits the packets to the remote voice gateway. This process is accomplished using either the Cisco fax relay or T.38 fax relay method, explained next.
Cisco Fax Relay Cisco’s proprietary fax relay method uses special RTP packets to transport the communication stream between voice gateways. Cisco fax relay is the default relay method and works only when both voice gateways are Cisco hardware and utilize T.30-compatible fax machines. T.30 fax machines are defined by the ITU-T and are also defined as group 3 fax machines. They use digital formats and compression methods for compiling the fax transmission but transmit the signal in an analog stream. Using Cisco fax relay, the transmitting voice gateway creates a virtual T.30 fax machine interface, which is responsible for demodulating the analog T.30 fax transmission (using DSPs) coming inbound on the analog port that the real fax is attached to. It then packetizes the demodulated fax transmission for transport on an IP network using the special RTP packets. Once the packets reach the destination voice gateway, the voice gateway remodulates the signal and sends the reconstructed analog transmission to the destination fax machine. Figure 9.1 shows how Cisco fax relay transport functions.
c09.indd 357
9/21/11 11:25:38 AM
358
Chapter 9
F I G U R E 9 .1
■
Advanced Voice Gateway Features
The Cisco fax relay process VoIP
Fax Ext: 3000 Fax to 4000
V
V
Voice gateway
Voice gateway
T.30
Cisco proprietary RTP Demodulation and packetization
Fax Ext: 4000 T.30
Depacketization and remodulation
Keep in mind that the fax machines are not aware of the demodulation and remodulation process because they transmit and receive only analog signals. The conversion that occurs at the voice gateway is completely transparent, and to them, it looks as if they are still using a completely analog system from end to end. Cisco fax relay works with either the H.323 or SIP signaling protocol.
ITU-T T.38 Fax Relay The alternate to Cisco fax relay is to use the ITU-T T.38 fax relay standard method, which is useful in situations where one voice gateway is a non-Cisco device. This method is compatible with H.323, SIP, and MGCP voice gateway signaling protocols. One main configuration difference between the Cisco and T.38 relay methods is that the T.38 method requires you to create independent dial peers for the transmission of T.38 Internet fax packets (IFP). Also, just as with the Cisco method, T.38 relay requires that your transmitting and receiving fax machines conform to the ITU-T T.30 standard for transmitting digital streams and can handle digital compression natively. The process of demodulating and remodulating a fax transmission between voice gateways is similar to the Cisco fax relay method with the exception that the T.38 method uses its own method to packetize and transport fax streams on an IP network, and it doesn’t use the concept of virtual fax interfaces. Figure 9.2 shows how the T.38 fax transmission transport functions. FIGURE 9.2
T.38 fax relay VoIP
Fax Ext: 3000 Fax to 4000
V
V
Voice gateway
Voice gateway
T.30
ITU-T T.38 Demodulation and packetization
c09.indd 358
Fax Ext: 4000 T.30
Depacketization and remodulation
9/21/11 11:25:38 AM
Configuring Fax Support
359
Again, as in the Cisco fax relay method, the process is transparent, and the fax machines never realize that they are using an IP network for transport.
Configuring Cisco Fax Relay Fax relay can be enabled either on a global basis while in config-voi-serv configuration mode or on an individual dial-peer level while in conf-dial-peer configuration mode. If both methods are used on a voice gateway, the dial-peer setting takes precedence over the global setting. Here is an example of configuring Cisco fax relay globally: Router#configure terminal Router(config)#voice service voip Router(config-voi-serv)#fax protocol Router(config-voi-serv)#end Router#
The same command in config-dial-peer mode will enable Cisco fax relay on an individual dial peer.
Configuring T.38 Fax Relay Because the Cisco fax relay method is the default on Cisco routers, it takes a few additional configuration commands to enable T.38 fax relay.
Configuring T.38 Fax Relay with H.323 and SIP Enabling T.38 fax relay either locally or globally with the H.323 or SIP protocol is a matter of fi rst configuring all of the necessary and compatible signaling and DTMF tones for your respective protocol. Then it’s a matter of issuing the fax protocol t38 command. There are several optional keywords that you can enter at the end to modify how T.38 fax relay operates; here is a summary of them: nse Uses Cisco proprietary named serviceg events (NSE) for fax signaling. An additional force keyword requires the use of NSEs; it is used for interoperability between H.323/SIP
T.38 configurations and MGCP T.38 configurations. ls-redundancy Stands for low-speed redundancy and specifies the number of redundant T.38 packets to be sent using the low-speed V.21-based T.30 protocol. The range is either 0 to 5 or 0 to 7 depending on the hardware platform you are using. The default number of redundant packets is 0. hs-redundancy Stands for high-speed redundancy and specifies the number of redundant T.38 packets to be sent using the high-speed V.17, V.27, V.29, T.4, or T.6 protocol. Range can be set between 0 and 3, and the default number of redundant packets is 0.
c09.indd 359
9/21/11 11:25:39 AM
360
Chapter 9
■
Advanced Voice Gateway Features
In addition to the T.38 configuration options, there is an alternate way to send fax transmissions in the event that T.38 fax relay fails. There are two different options, and they are enabled using the fallback keyword followed by one of the following: cisco Attempts to use the Cisco proprietary fax relay method. pass-through Attempts to use the fax pass-through method of transmitting fax messages. The codecs that can be used are either G.711mu-law or G.711a-law. The fax pass-through is explained in the next section.
The following example shows how to configure T.38 fax relay on VoIP dial peer 80 using SIP. We will also set the ls-redundancy and hs-redundancy to 3 and specify that the dial peer attempt to use Cisco fax relay in the event the T.38 method fails. Router#configure terminal Router(config)#dial-peer voice 80 voip Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#fax protocol t38 ls-redundancy 3 hs-redundancy 3 fallback cisco Router(config-dial-peer)#end Router#
Always remember that fax relay can also be configured globally while in conf-voi-serv configuration mode. The specific dial-peer configurations take precedence over the global configurations if both are used.
Understanding and Configuring Optional Fax SIP and H.323 Settings CVOICE candidates should be familiar with a few optional configuration commands. The fi rst command is fax rate, which is used to statically assign the transmission rate for outbound T.38 transmissions. The second command is fax-relay, which is used either to disable error checking or to suppress tones so the sending and receiving Super Group 3 (SG3) fax machine can negotiate a lower group 3 (G3) speed. fax rate voice This command statically sets the fax transmission rate. The default rate depends on the codec method in use and is always set to the maximum possible. The value can be lowered, which alters the maximum possible rate to one of the following:
2400 bps
4800 bps
7200 bps
9600 bps
12000 bps
14400 bps
The command is configured while in config-dial-peer mode. Here is an example of how to configure a static transmission rate of 7200 bps on VoIP dial peer 10:
c09.indd 360
9/21/11 11:25:39 AM
Configuring Fax Support
361
Router#configure terminal Router(config)#dial-peer voice 10 voip Router(config-dial-peer)#fax rate 7200 voice Router(config-dial-peer)#end Router#
fax-relay The fax-relay command is used to enable/disable two distinct fax features. The command can be configured globally or on an individual dial peer.
One task for the fax-relay command is to disable error correction mode (ECM) using the ecm disable keywords. This is commonly done on congested WAN links. By default, ECM is enabled. The following example shows how to disable fax-relay ECM globally: Router#configure terminal Router(config)#voice service voip Router(config-voi-serv)#fax-relay ecm disable Router(config-voi-serv)#end Router#
When Error Correction Goes Wrong Tiffany was in the process of converting multiple remote sites, that used analog lines for fax connections to the corporate office, to use the IP WAN connections instead. The first three site conversions went smoothly, but she began struggling with fax transmission failures at the fourth remote site. After some investigation, it turned out that while the IP WAN connection was in no way overutilized, it had a history of dropped packets. In fact, her tests showed almost a 3 percent packet loss from the remote site to the corporate office. The fax machines being used utilized fax-relay “packet loss concealment” features. These are fax machines that scan the entire image and store it in local memory. Once a page has been scanned, the sending fax transmits the data in a series of frames. The receiving fax machine then receives the frames and checks for any errors using ECM. Tiffany found that ECM is enabled by default on her T.38 fax-relay voice gateway configuration. In addition, Cisco recommends that ECM be disabled on networks with a packet loss of 2 percent or more, because ECM requires a 100 percent error-free fax transmission. If it’s not completely error free, the transmission fails. After disabling ECM on her voice gateways, Tiffany was able to successfully send and receive faxes between the remote and corporate offices. This bought her enough time to investigate the root cause of why her IP WAN was experiencing a high rate of dropped packets.
c09.indd 361
9/21/11 11:25:40 AM
362
Chapter 9
■
Advanced Voice Gateway Features
A second task is to configure tone suppression. Tone suppression is a way to block fax tone transmissions so that they can be transported at a lower rate. You might want to do this if you have an overutilized link and want to lower the amount of bandwidth a fax transmission requires. There are two tone-suppression methods. The fax-relay ans-disable command is used to suppress answer (ANS) tones from the sending SG3compatible fax machine. This allows SG3 fax machine negotiation of lower, group 3 (G3) connection speeds. Super Group 3 (SG3) is a standard fax transmission method that supports speeds up to 33.6 Kbps. Sometimes this speed is not reliable, or too much bandwidth is consumed. That is why it is sometimes necessary to force the downgrade to lower G3 speeds, which can be more reliable and consume less bandwidth. The fax-relay sg3-to-g3 command essentially does the same thing as the ans-disable keyword, except that the two voice gateways simply negotiate slower G3 speeds as opposed to suppressing ANS tones.
Configuring T.38 Fax Relay with MGCP Similar to configuring DTMF relay on MGCP gateways, negotiation of T.38 fax relay can be controlled by either a call-processing agent or the voice gateway itself. The call agent (CA) method is enabled by default, and therefore the actual configuration is performed on the CUCM and is outside the scope of this study guide. Therefore, we will fi rst look at how to configure gateway (GW)-controlled MGCP T.38 fax relay. Additionally, we will configure MGCP T.38 fax relay to interoperate with SIP- and H.323-configured T.38 gateways. The commands needed to configure T.38 fax relay using MGCP are performed in global configuration mode. Two commands are required to enable this properly on a voice gateway. The fi rst command is mgcp fax t38. There are several optional but useful keywords that can follow the mgcp fax t38 command, described here: ecm Enables error correction mode (ECM) for the gateway, which better ensures the proper receipt of all packets. Keep in mind, however, that network congestion caused by ECM can also cause more failures on slow or unreliable networks. gateway force Forces the gateway-controlled fax relay service to use Cisco’s proprietary NSEs. ls_redundancy Stands for low-speed redundancy and specifies the number of redundant T.38 packets to be sent using the low-speed V.21-based T.30 protocol. Its range can be set between 0 and 5; the default number of redundant packets is 0. hs_redundancy Stands for high-speed redundancy and specifies the number of redundant T.38 packets to be sent using the high-speed V.17, V.27, V.29, T.4, or T.6 protocol. Its range can be set between 0 and 2; the default number of redundant packets is 0. nsf Overrides non-standard facilities (NSF) code with unique code that depends on
the two-digit hexadecimal code entered to specify the fax-machine vendor. NSFs are proprietary capability codes that fax-machine makers may build into their equipment. By default, the NSF code is not overridden. You need to look up the code for the specific vendor that you are using in order for this to work. inhibit This command disables T.38 fax relay on MGCP. By default, T.38 fax relay is enabled.
c09.indd 362
9/21/11 11:25:40 AM
Configuring Fax Support
363
The second required command is mgcp tse payload, followed by a unique number to specify the telephony service event (TSE) payload size. TSEs are special messages that can provide a way to communicate telephony events between MGCP gateways. The valid TSE range is 98 to 119. The default is 100; but this command is disabled by default, so it must be enabled in order for the voice gateway to enable in-band signaling events. Also keep in mind that the TSE payload sizes must be the same on both the source and destination voice gateways. The following shows an example of how to configure MGCP T.38 signaling to use Cisco NSEs and to enable error checking. The TSE payload size is enabled and set to 105: Router#configure terminal Router(config)#mgcp fax t38 gateway force Router(config)#mgcp tse payload 105 Router(config)#end Router#
Understanding and Configuring Optional Fax MGCP Settings You should be familiar with two optional MGCP fax configuration commands. The fi rst adjusts the transmission rate at which a fax is sent. The other sets the amount of time that a voice gateway waits to receive an NSC response packet from a peer. Let’s briefly look at how to configure both. mgcp fax rate This command statically sets the fax transmission rate. The default rate depends on the codec method in use and is always set to the maximum. The value can be lowered so that less bandwidth is used, but the transmission will take longer. The voice keyword will reset any statically-assigned rate and revert to using the highest possible rate for the codec being used. The command is configured while in global configuration mode. Here is an example of how to configure a static transmission rate of 9600 bps: Router#configure terminal Router(config)#mgcp fax rate 9600 Router(config)#end Router#
mgcp timer nse-response t38 This command is used to change the default time that the local voice gateway waits to receive a T.38 NSE response message from the remote voice gateway. The possible range is 100 to 3000 ms, with the default being 200. It is sometimes necessary to increase the wait time on low-bandwidth links. The following example configures the T.38 NSE response wait time to 1000 ms: Router#configure terminal Router(config)#mgcp timer nse-response t38 1000 Router(config)#end Router#
c09.indd 363
9/21/11 11:25:41 AM
364
Chapter 9
■
Advanced Voice Gateway Features
Understanding Fax Pass-through Fax pass-through is the simplest yet least-reliable fax transport method. It can come in handy, however, whenever you run across equipment that doesn’t support any of the other compatible fax methods. The pass-through method transports fax transmissions the same way that voice calls are transmitted. The only difference is that when fax pass-through is enabled, it ensures that fax transmissions are encoded using either G.711mu-law or G.711a-law, which provides a high-quality digital representation of the original analog source. Figure 9.3 shows how fax transmissions flow through the IP network.
FIGURE 9.3
Fax pass-through VoIP
Fax Ext: 3000
V
V
Voice gateway
Voice gateway
Fax to 4000
Fax Ext: 4000
T.30 G.711a-law or mu-law enforced
Using fax pass-through, even if voice calls are negotiated to a higher-compression codec such as G.729a, the voice gateway detects fax transmissions locally by listening for a 2100 Hz tone. As soon as this tone is detected, the local voice gateway sends an NSE message in the RTP stream to inform the remote gateway that this stream is a fax transmission and that the negotiated codec should be G.711. Fax pass-through can operate with H.323, SIP, and MGCP protocols and is a fairly simple process to configure on a voice gateway. The voice gateway can be configured either globally while in conf-voi-serv configuration mode or on a single dial peer while in config-dial-peer mode. Keep in mind that individual dial-peer configurations take precedence over global configurations.
Configuring Fax Pass-through Global configuration of fax pass-through is identical for H.323 and SIP. Here is an example of how to configure fax pass-through globally: Router#configure terminal Router(config)#voice service voip Router(conf-voi-serv)#fax protocol pass-through g711ulaw
c09.indd 364
9/21/11 11:25:41 AM
Configuring Fax Support
365
Configuration of fax pass-through for MGCP is slightly different. There are three required commands, which must be configured while in global configuration mode: mgcp fax t38 inhibit This command is necessary to disable T.38 fax relay, which is enabled by default on MGCP. If this command is not run, the voice gateway will attempt to use T.38 fax relay with the peer voice gateway. mgcp modem passthrough voip mode nse This command enables fax and modem passthrough using NSE messages in a peer-to-peer fashion between two voice gateways. mgcp package-capability rtp-package This command enables the RTP package for MGCP so the two voice gateways can communicate with each other.
By default, the G.711 codec used is mu-law. This can easily be changed by issuing the mgcp modem passthrough voip codec g711alaw command. The following example shows how to configure fax pass-through on an MGCP voice gateway that uses G.711a-law: Router#configure terminal Router(config)#mgcp modem passthrough voip mode nse Router(config)#mgcp modem passthrough voip codec g711alaw Router(config)#mgcp package-capability rtp-package Router(config)#mgcp fax t38 inhibit Router(config)#end Router#
Understanding T.37 Store-and-Forward Fax T.37 store-and-forward fax is also commonly referred to as T.37 fax, because this is the ITU-T standard that defi nes the fax-over-email method. Some fax machines natively support T.37 and have the capability to send the contents of the fax transmission to an email address instead of a telephone number. Alternatively, legacy fax machines that do not support T.37 store-and-forward fax can be configured to send T.30 fax transmissions to the destination fax as usual. The fax transmission passes through a voice gateway configured for store-and-forward fax service. The voice gateway detects the fax transmission and demodulates it. The demodulated transmission is then converted to an image in a multipage tagged image fi le format (TIFF). The new fi le is then attached to an email that is sent to a remote voice gateway, a T.37-compatible fax machine, or any device that can receive email messages. If it is sent to the voice gateway, the gateway receives the email and attached fi le. The TIFF image is converted back into a T.30 signal and sent to the analog fax machine. Figure 9.4 shows an example of the store-and-forward method between two phones that support only legacy T.30 transmissions.
c09.indd 365
9/21/11 11:25:42 AM
366
Chapter 9
FIGURE 9.4
■
Advanced Voice Gateway Features
T.37 store-and-forward fax SMTP server
V
Fax Ext: 3000 Fax to 4000
IP Network
On-ramp voice gateway T.30
V
Email Conversion of T.30 fax to TIFF and sent as email attachment
Fax Ext: 4000
Off-ramp voice gateway T.30 Conversion TIFF to T.30 fax and sent to Ext: 4000
PC- or T.37 capable fax
As you can see, the voice gateway that is responsible for taking the T.30 fax transmission and converting it to a TIFF-attached email is known as the on-ramp gateway, and the voice gateway that takes the TIFF-attached email and remodulates it back to a T.30 transmission is called the off-ramp gateway. Obviously, a single gateway can be considered either the on-ramp gateway or the off-ramp gateway depending on the direction in which the fax is being sent on the network.
Because T.37 store-and-forward fax messages are sent in an email format, they can easily be sent to multiple recipients in a single transfer.
The store-and-forward fax service is configured identically on voice gateways running H.323 or SIP. MGCP does not support store-and-forward. The configuration of T.37 fax is a fairly lengthy process. A separate interactive voice response (IVR) process is needed for on-ramp and off-ramp gateway functionality. These processes are implemented on Cisco voice gateways using Tool Command Language (TCL) scripts.
TCL scripts for on-ramp and off-ramp functionality can be found online at Cisco’s Software Support Center. The scripts are proprietary, and valid CCO credentials are required in order to download them.
c09.indd 366
9/21/11 11:25:42 AM
Configuring Modem Support
367
In addition, because the process is email based, it requires an SMTP server to work. SMTP is used to transport the message over the IP network between on- and off-ramp gateways, and to send a confirmation of receipt back to the originating gateway. Because the configuration process is complex, involving many components, and the configuration varies greatly from one network to another, the CVOICE exam does not require you to know how to configure store-and-forward fax, only that you understand how it works from a design and signaling perspective.
Configuring Modem Support Modem support on IP networks is similar to that for fax machines. The primary difference between fax and modem transmissions is that data sent across a modem begins its life in a digital format, while fax data is converted from paper to digital data using a scanning device. A second difference is that with fax, the data transmission speeds are set prior to sending of data, and these data rates are fi xed. Modem data rates, on the other hand, can fluctuate throughout a single connection. Modem traffic can be configured using either modem passthrough or modem relay methods, which are discussed in the following sections.
Configuring Modem Pass-Through Modem pass-through works similarly to fax pass-through, because modem signaling is detected and then transported on a no-compression G.711 codec. This method can be configured either globally, while in config-voi-serv configuration mode or on individual dial peers. To enable modem pass-through, you use the modem passthrough command followed by either the nse or system keyword. When configuring modem pass-through globally, you have only the nse option, which stands for named service events. The system option is available only when configuring pass-through on dial peers. This command basically tells the voice gateway to use the options on the global configuration. There also are other optional keywords that can be used to defi ne additional settings. All the modem pass-through keyword options are listed here: nse This keyword specifies that you use named service event packets for switching the codec from a nonsupported codec to G.711. There also is an optional payload-type keyword followed by a number specifying the payload for NSE packets. The default payload type is 100, and the range is between 96 and 119 on most hardware platforms.
This keyword is available only on dial-peer configurations and is used to tell the voice gateway to use the globally configured modem pass-though configuration.
system
codec This keyword specifies which G.711 codec should be used. Your options are g711ulaw and g711alaw. An optional redundancy keyword enables a single reception of
RFC 2198 packets to help ensure the receipt of the packets to improve reliability. This keyword sets a maximum number of simultaneous modem passthrough sessions. The range of maximum-sessions varies by hardware platform.
maximum-sessions
c09.indd 367
9/21/11 11:25:43 AM
368
Chapter 9
■
Advanced Voice Gateway Features
The following example shows how to configure modem pass-through on dial peer 20 that specifies use of the G.711-ulaw codec and the use of RFC 2198 redundancy packets: Router#configure terminal Router(config)#dial-peer voice 20 voip Router(config-dial-peer)#modem passthrough nse codec g711ulaw redundancy Router(config-dial-peer)#end Router#
Configuring Modem Relay Configuring modem relay is nearly identical to configuring modem pass-through, with just a few exceptions. Modem relay can be configured either globally or at a dial-peer level. To enable modem relay for H.323 or SIP, you use the modem relay command followed by one or more options that are identical to the modem pass-through commands listed in the previous section. There is one new keyword that can be used, however: gw-controlled Specifies whether the voice gateway controls modem pass-through
transport parameters. Here is an example of how to configure modem relay on a voice gateway using NSE and gateway control functionality for SIP and H.323: Router#configure terminal Router(config)#voice service voip Router(config-voi-serv)#modem relay nse gw-controlled Router(config-voi-serv)#end Router#
For MGCP, you use the mgcp modem relay voip mode command with all of the optional keywords available for H.323 and SIP. MGCP can only be configured globally, but otherwise the commands are the same. Also remember that you need to enable the necessary MGCP packages required for modem transport. The following example enables modem relay on MGCP-operated voice gateways: Router#configure terminal Router(config)#mgcp modem relay voip mode nse gw-controlled Router(config)#mgcp package-capability dtmf-package Router(config)#end Router#
Configuring Voice Backup Paths Part of a good voice network design is to provide backup mechanisms to help eliminate single points of failure. The three different backup path designs we will focus on here are
c09.indd 368
9/21/11 11:25:44 AM
Configuring Voice Backup Paths
369
a WAN-to-PSTN fallback trigger using the preference command, an MGCP-to-H.323 fallback, and a COR and SRST configuration using CUCM Express.
Configuring a WAN-to-PSTN Fallback Many IP voice networks that have multiple sites interconnected by way of a WAN connection often use the WAN to transport voice as well. This will help to save money on long-distance charges. But in case of a WAN failure, it is often necessary to configure a backup path through the PSTN. While the PSTN will likely cost more, in most instances the added cost is preferable to a lack of communication. To demonstrate how to configure WAN-to-PSTN fallback, we will use Figure 9.5 as our example network. FIGURE 9.5
WAN-to-PSTN fallback Extensions: 4XXX
Extensions: 5XXX
Preferred path
IP WAN
V
Switch
S0/0/0:23
Seattle
172.16.1.1
V
Las Vegas
Switch
up
ck
Ba th
pa PSTN
As you can see, we have two sites connected by an IP WAN connection. A secondary path will go through the PSTN. We want our voice gateways to use the WAN connection as the primary path and only use the backup PSTN path in case of a WAN failure. To accomplish this goal, we will configure two different dial peers to the same remote destination. To force the voice gateway to choose the WAN path, we will use the preference command in each dial peer and give the WAN path dial peer a lower preference number. The lower the preference number, the more preferred it is. We will configure the Seattle router with two dial peers (101 and 102). The VoIP dial peer that uses the WAN path will have a preference of 1, while the POTS dial peer will have a preference of 2 and therefore will be used only when the WAN is unavailable. The commands to implement this are as follows: Seattle#configure terminal Seattle(config)#dial-peer voice 101 voip Seattle(config-dial-peer)#destination-pattern 4....
c09.indd 369
9/21/11 11:25:44 AM
370
Chapter 9
■
Advanced Voice Gateway Features
Seattle(config-dial-peer)#no digit-strip Seattle(config-dial-peer)#preference 1 Seattle(config-dial-peer)#session-target ipv4:172.16.1.1 Seattle(config-dial-peer)#exit Seattle(config)#dial-peer voice 102 pots Seattle(config-dial-peer)#destination-pattern 4... Seattle(config-dial-peer)#prefix 13125554 Seattle(config-dial-peer)#preference 2 Seattle(config-dial-peer)#port 0/0/0:23 Seattle(config-dial-peer)#end Seattle#
Don’t forget that you will need to manipulate the calling digits as necessary. For example, on VoIP dial peer 101, we trigger on four-digit extensions beginning with the number 4. When an extension to our Chicago site is triggered and the WAN connection is available, we will simply forward the four digits to the remote voice gateway. The forwarding of all digits is accomplished using the no digit-strip command. But if the WAN connection is not available, the voice gateway will use the next preferred path, which is POTS dial peer 102. In this situation, we need to prepend the country code, area code, and central office code. Additionally, we simply prepend the digit 4 and will pass the other three wildcard digits along, effectively forwarding an 11-digit number to the PSTN.
Configuring MGCP-to-H.323 Fallback Our second example is a voice backup path that can be used when MGCP is the voice gateway signaling protocol. As you’ve seen, MGCP is different from SIP and H.323 in that all the call-routing intelligence (dial-peer rules) is controlled at the call control agent layer and not directly on the voice gateway. In the event of a loss of communication between our MGCP voice gateway and the call control agent, it would be nice to provide at least basic calling service to calls going through our voice gateway. This would eliminate a single point of failure in the event that the connection between the MGCP voice gateway and CUCM (or CUCM cluster) is lost. MGCP does not use dial peers but instead relies on the call-processing agent to tell the voice gateway where to route calls. That means that if the gateway cannot communicate with the CUCM, it doesn’t have the intelligence to route calls on its own. To overcome the lack of dial peers on a MGCP gateway, you can configure H.323 fallback on the router. With H.323 fallback configured, the router will begin using H.323 signaling (and corresponding dial peers that are configured locally) to route calls going into the private network and out to the PSTN. The best way to show you how to configure H.323 fallback on MGCP voice gateways is to walk through an example where the solution can be used. Our example will use the network setup shown in Figure 9.6.
c09.indd 370
9/21/11 11:25:45 AM
Configuring Voice Backup Paths
FIGURE 9.6
371
H.323 fallback CUCM 192.168.1.2
MG
CP
M
V
Connection failure IP WAN
V
Switch
PSTN
Voice gateway H.323 fallback using dial peer to PSTN
Configuring MGCP to H.323 fallback would require the following three configuration steps: 1.
The fi rst command we enter tells our voice gateway that we are enabling MGCP fallback in the case that communications to the CUCM are lost: Router#configure terminal Router(config)#ccm-manager fallback-mgcp Router(config)#end Router#
2.
Next we enable MGCP fallback to the default signaling protocol H.323. This is simply a matter of configuring the following: Router#configure terminal Router(config)#application Router(config-app)#global Router(config-app-global)#service alternate default Router(config-app-global)#end Router#
c09.indd 371
9/21/11 11:25:46 AM
372
3.
Chapter 9
■
Advanced Voice Gateway Features
Then we configure any necessary POTS dial peers that will be controlled by H.323 in the event the voice gateway needs to fall back. For example, we configure POTS dial peer 909 to accept any incoming calls and route NANP long-distance calls out the T1 CAS: Router#configure terminal Router(config)#dial-peer voice 909 pots Router(config-dial-peer)#application mgcpapp Router(config-dial-peer)#incoming called-number . Router(config-dial-peer)#destination-pattern 91[2-8]......... Router(config-dial-peer)#forward-digits 10 Router(config-dial-peer)#port 2/0:15 Router(config-dial-peer)#end Router#
Once completed, our voice gateway will use MGCP and the call-routing decisions coming from the CUCM. But in the event of a loss of connectivity to the CUCM, H.323 will take over and our dial peer will allow inbound and outbound NANP calls to the PSTN. A good command to check the status of your voice gateway is the show ccm-manager fallback-mgcp command. Here is an example of our router when it has connectivity to the CUCM: Router#show ccm-manager fallback-mgcp Current active Call Manager: 192.168.1.2 MGCP Fallback mode: Enabled/OFF Last MGCP Fallback start time: None Last MGCP Fallback end time: None
And when our voice gateway loses connectivity, the MGCP fallback becomes enabled, as shown here: Router#show ccm-manager fallback-mgcp Current active Call Manager: None MGCP Fallback mode: Enabled/ON Last MGCP Fallback start time: 11:25:42 UTC Apr 16 2011 Last MGCP Fallback end time: 11:25:18 UTC Apr 16 2011
Understanding and Configuring COR and SRST In our previous example of MGCP-to-H.323 fallback, we enabled the voice gateway to fall back to H.323, which can then utilize dial peers that are configured on the voice gateway. The problem with this setup, however, is that all the phones are treated identically, meaning they all can dial NANP numbers and nothing else. In many situations, we want to allow some phones to call NANP, allow others to call NANP and international numbers, and allow still other phones only local calling on the PSTN. In order to be able to do this,
c09.indd 372
9/21/11 11:25:46 AM
Configuring Voice Backup Paths
373
we need to configure Class of Restriction (COR) lists and place telephone extensions within them. COR is commonly used to enforce dialing privileges in large voice networks, and typically the restrictions are handled by the CUCM. But in the case that the voice gateway loses connectivity with the CUCM, we can configure survivable remote site telephony (SRST) in conjunction with local COR profiles to get the job done. We will use Figure 9.7 as our example of COR and SRST configuration to implement. F I G U R E 9 .7
COR and SRST CUCM 192.168.1.2
M
V
3000
3001
Connection failure
3006 IP WAN
192.168.1.1
0/0/0:23 V
Switch
PSTN
SRST voice gateway
Let’s fi rst look at understanding COR on IOS gateways and then how to apply COR lists to dial peers when SRST kicks in.
Configuring Class of Restriction Class of Restriction is a method used to defi ne calling search spaces, which can be applied to a group of IP phones based on their extension number. COR lists can be defi ned as inbound or outbound. Inbound COR lists are applied to calls. When a call is made that passes through the router, it is matched with dial peers, which dictate the next hop to the destination phone. If COR lists have been applied to the matched dial peers, the following must be determined:
c09.indd 373
If the COR configured on the inbound dial peer has access rules equal to or greater than the outbound COR list, the call can proceed. If the inbound COR list is not equal to the outbound COR list, the call cannot proceed.
Additionally, if an inbound or outbound COR list is not defined on a dial peer, then the voice gateway will use the default inbound or outbound COR list configured. The default COR lists use the lowest priority setting and therefore will allow the call to proceed.
9/21/11 11:25:47 AM
374
Chapter 9
■
Advanced Voice Gateway Features
The configuration of this on IOS routers begins with defi ning the COR members. These are simply labels that will defi ne specific telephone access areas. Then actual COR lists are defi ned within the COR members. The lists defi ne what numbers can be dialed when the COR list is applied to a dial peer. For example, let’s fi rst configure four commonly configured COR members. To do this we must fi rst enter into config-dp-cor configuration mode by using the dial-peer cor custom command. Once we enter this mode, we can create our COR containers: Router#configure terminal Router(config)#dial-peer cor custom Router(config-dp-cor)#name 911 Router(config-dp-cor)#name local Router(config-dp-cor)#name ld Router(config-dp-cor)#name int Router(config-dp-cor)#end Router#
Now that we have our COR members defined, we can create our COR lists for both inbound and outbound calls. First, we’ll create our outbound COR lists that apply to calls going out of the voice gateway (typically to the PSTN). In our example, we will configure four COR lists that each contain their respective single COR membership that we configured earlier: Router#configure terminal Router(config)#dial-peer cor list 911out Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#exit Router(config)#dial-peer cor list localout Router(config-dp-corlist)#member local Router(config-dp-corlist)#exit Router(config)#dial-peer cor list ldout Router(config-dp-corlist)#member ld Router(config-dp-corlist)#exit Router(config)#dial-peer cor list intout Router(config-dp-corlist)#member int Router(config-dp-corlist)#end Router#
Next, we’ll create our inbound COR lists. These lists are used to defi ne the calling privileges of the internal phones. Depending on the COR list, one or more COR members are applied, as shown here: Router#configure terminal Router(config)#dial-peer cor list 911 Router(config-dp-corlist)#member 911
c09.indd 374
9/21/11 11:25:47 AM
Configuring Voice Backup Paths
375
Router(config-dp-corlist)#exit Router(config)#dial-peer cor list local Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member local Router(config-dp-corlist)#exit Router(config)#dial-peer cor list ld Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member local Router(config-dp-corlist)#member ld Router(config-dp-corlist)#exit Router(config)#dial-peer cor list int Router(config-dp-corlist)#member 911 Router(config-dp-corlist)#member local Router(config-dp-corlist)#member ld Router(config-dp-corlist)#member int Router(config-dp-corlist)#end Router#
So now we can see that phones defi ned to be within the 911 COR list are only allowed to make calls within the 911 COR membership. Alternatively, the COR list named int allows the phones to call numbers defi ned within all four COR memberships. Then we need to apply our newly created COR lists to outbound dial peers that they are associated with. For example, we will configure POTS dial peer 9 and defi ne it for local destination patterns, as shown here: Router#configure terminal Router(config)#dial-peer voice 9 pots Router(config-dial-peer)#destination-pattern 9[2-9]...... Router(config-dial-peer)#corlist outgoing localout Router(config-dial-peer)#port 0/0/0:23
All the other required dial peers for our example are shown here: Router(config)#dial-peer voice 911 pots Router(config-dial-peer)#destination-pattern 911 Router(config-dial-peer)#forward-digits 3 Router(config-dial-peer)#corlist outgoing 911out Router(config-dial-peer)#port 0/0/0:23 Router(config-dial-peer)#exit Router(config)#dial-peer voice 9911 pots Router(config-dial-peer)#destination-pattern 9911 Router(config-dial-peer)#forward-digits 3 Router(config-dial-peer)#corlist outgoing 911out
c09.indd 375
9/21/11 11:25:48 AM
376
Chapter 9
■
Advanced Voice Gateway Features
Router(config-dial-peer)#port 0/0/0:23 Router(config-dial-peer)#exit Router(config)#dial-peer voice 91 pots Router(config-dial-peer)#destination-pattern 91[2-9]..[2-9]...... Router(config-dial-peer)#prefix 1 Router(config-dial-peer)#corlist outgoing ldout Router(config-dial-peer)#port 0/0/0:23 Router(config-dial-peer)#exit Router(config)#dial-peer voice 9011 pots Router(config-dial-peer)#destination-pattern 9011T Router(config-dial-peer)#prefix 011 Router(config-dial-peer)#corlist outgoing intout Router(config-dial-peer)#port 0/0/0:23 Router(config-dial-peer)#end Router#
Now we have our outbound dial peers defi ned on our voice gateway. The fi nal step is to enable SRST and defi ne which phones are allowed which dialing privileges in the event of a WAN failure.
Configuring Survivable Remote Site Telephony The configuration of SRST on a compatible IOS gateway version is very similar to configuring CUCM Express. The voice gateway can connect to IP phones that use either SCCP or SIP signaling. This study guide will show you the basic steps to configure SRST for SCCP. First, we need to enter into config-cm-fallback configuration mode and defi ne our source IP address and max ephones and ephone-DNs as shown here: Router#configure terminal Router(config)#call-manager-fallback Router(config-cm-fallback)#ip source-address 192.168.1.1 Router(config-cm-fallback)#max-ephones 10 Router(config-cm-fallback)#max-dn 20 Router(config-cm-fallback)#end Router#
Next, we need to defi ne our ephone-DNs and ephone settings. In this example, we will configure an ephone and apply the ephone-DN of 3000 to button 1: Router#configure terminal Router(config)#ephone-dn 1 Router(config-ephone-dn)#number 3000 Router(config-ephone-dn)#exit Router(config)#ephone 1 Router(config-ephone)#mac-address 0014.1c4d.2589
c09.indd 376
9/21/11 11:25:48 AM
Toll Bypass and TEHO
377
Router(config-ephone)#type 7965 Router(config-ephone)#codec g729r8 Router(config-ephone)#button 1:1 Router(config-ephone)#end Router#
Now that we have an SRST phone configured, we can go ahead and apply a COR list to it through SRST, which is explained next.
Configuring SRST to Define COR Dialing Access When our remote voice gateway fails to communicate with the CUCM, SRST will be used to route calls. We also would like to enforce COR while in SRST mode. To do that, we must fi rst enter into config-cm-fallback configuration mode and then defi ne the telephone extensions or range of extensions that are applied a COR list. You can apply up to 20 COR lists in SRST mode, and you need to number each rule individually using 1–20. For example, we will assign extensions 3000 to 3005 on list 1 to use the local COR list and extension 3006 on list 2 to dial any PSTN number: Router#configure terminal Router(config)#call-manager-fallback Router(config-cm-fallback)#cor incoming local 1 3000 3005 Router(config-cm-fallback)#cor incoming int 2 3006 Router(config-cm-fallback)#end Router#
So the ephone that we configured with an extension of 3000 will be able to call outbound on the PSTN to local numbers as well as to emergency services using 911 or 9911.
Toll Bypass and TEHO One of the primary attractions of implementing a VoIP network is the inherent cost savings that can be achieved. Cost savings are found in several areas. By combining voice and data into a single network, you eliminate the need to support separate voice and data networks. Additionally, a substantial saving in long-distance charges can be found when transporting traffic over IP WAN connections, effectively eliminating long-distance charges. The key point is that as long as you have enough bandwidth on your WAN connections, you pay for that bandwidth whether you use it or not. So you may as well transport voice using available IP bandwidth and avoid long-distances charges in the process.
Understanding Tail End Hop Off The process of configuring your IP network to utilize WAN connections for voice transport is known as toll bypass, and you already know how to configure this as well as how to configure the PSTN as a backup in case of a WAN failure. You can extend the functionality
c09.indd 377
9/21/11 11:25:48 AM
378
Chapter 9
■
Advanced Voice Gateway Features
of toll bypass, however, when you configure what is known as tail end hop off (TEHO). Toll bypass works great when you are calling from site to site where you have a high-speed WAN connection to utilize. No matter what business you are in, eventually you are going to have to use the PSTN to make calls to people outside of your VoIP network. But if you have a vast IP network that covers a wide range of geographical locations, it is possible to utilize the IP WAN to get remote calls as close to the PSTN destination as possible. The calls can then be dumped off onto the PSTN locally, and the call will look as if it a local call as opposed to a long-distance one.
In some countries, toll bypass and TEHO are not legal, and the PSTN must provide transport for the entire call. If you are planning to implement either of these features, you need to understand the laws in the regions you will be covering.
To give you a better idea, let’s look at Figure 9.8 as an example. FIGURE 9.8
A TEHO network Ext 4000 call to 305-558-8442
Extensions: 5XXX
To area code 305
Local h
op-off to
PSTN
192.168.10.1 V
IP WAN
192.168.10.2
SanFran
V
PSTN
PSTN
Miami
Area code 415
Area code 305
PSTN
Here you can see that we have our SanFran site interconnected with our Miami site through an IP WAN. An employee at the SanFran site needs to call someone located in Miami, but the user is not part of the IP network. We can configure our network, however, to use the IP WAN to transport the call from SanFran to Miami, and then the voice gateway in Miami will route the call out their PSTN connection. The call therefore looks to the PSTN as if it is a local call, and no long-distance charges will be incurred. Let’s walk through the process of configuring TEHO on our SanFran and Miami voice gateways.
Configuring Tail End Hop Off The secret to configuring TEHO lies in dial-peer configurations and digit translations. It’s really just a matter of determining the following:
c09.indd 378
What area codes are considered local in Miami?
What area codes are considered local in SanFran?
9/21/11 11:25:49 AM
Toll Bypass and TEHO
379
Then you need to do the following:
Configure digit manipulation for Miami to SanFran local PSTN calls so that the remote ANI is displayed.
Configure digit manipulation for SanFran to Miami local PSTN calls so that the remote ANI is displayed.
Configure an outbound VoIP dial peer on the SanFran voice gateway to transport Miami PSTN calls across the IP WAN.
Configure an outbound VoIP dial peer on the Miami voice gateway to transport SanFran PSTN calls across the IP WAN.
Once these steps are completed, long-distance PSTN calls will be transported over the IP WAN. Once they reach the remote voice gateway, the standard PSTN dial peers already configured will properly route the call to the PSTN and complete the local PSTN call. To make our example a little easier to understand, we are going to assume that there is only one area code in Miami and one area code in SanFran that are considered local. The Miami area code is 305 and the SanFran area code is 415. Therefore, if someone in SanFran calls someone in the Miami area code, we will use TEHO to make the call and save on long-distance charges. The same will be true for Miami employees calling the SanFran 415 area code. The next step is to create translation rules and profi les so the correct ANI will be registered at the opposite end. We will start with our SanFran router to create a translation rule and profi le to add the SanFran area code of 415 and CO code of 555: SanFran#configure terminal SanFran(config)#voice translation-rule 1 SanFran(cfg-translation-rule)#rule 1 /^4/ /1415555/ SanFran(cfg-translation-rule)#exit SanFran(config)#voice translation-profile miami-teho-loc-code SanFran(cfg-translation-profile)#translate calling 1 SanFran(cfg-translation-profile)#end SanFran#
Next, we need to create our VoIP dial peer that routes calls to the Miami 305 area code out the IP WAN. We will also apply our translation profile outbound so the proper ANI number will be sent to the Miami voice gateway: SanFran#configure terminal SanFran(config)#dial-peer voice 305 voip SanFran(config-dial-peer)#destination-pattern 91305....... SanFran(config-dial-peer)#session-target ipv4:192.168.10.2 SanFran(config-dial-peer)#translation-profile outgoing miami-teho-loc-code SanFran(config-dial-peer)#end SanFran#
c09.indd 379
9/21/11 11:25:49 AM
380
Chapter 9
■
Advanced Voice Gateway Features
At this point, calls originating from the VoIP network in SanFran destined to Miami phones with area code 305 will be sent across the IP WAN to the Miami voice gateway. The Miami voice gateway should then be set up with typical dial peers for local, longdistance, and international calling. When the call comes in from the WAN, the Miami voice gateway will match it with a dial peer out to the PSTN, and the local call will be made. The Miami voice gateway will also forward the ANI information it received from the SanFran voice gateway. To complete our configuration, we will now configure the Miami voice gateway for local calling to the 415 area code: Miami#configure terminal Miami(config)#voice translation-rule 1 Miami(cfg-translation-rule)#rule 1 /^2/ /1305555/ Miami(cfg-translation-rule)#exit Miami(config)#voice translation-profile sanfran-teho-loc-code Miami(cfg-translation-profile)#translate calling 1 Miami(cfg-translation-profile)#exit Miami(config)#dial-peer voice 305 voip Miami(config-dial-peer)#destination-pattern 91305....... Miami(config-dial-peer)#session-target ipv4:192.168.10.1 Miami(config-dial-peer)#translation-profile outgoing sanfran-teho-loc-code Miami(config-dial-peer)#end Miami#
Always be aware of the increased bandwidth this can require on your IP WAN link. If you are planning to implement toll bypass and TEHO, you should closely monitor WAN utilization. You should also seriously consider implementing QoS techniques on your IP WAN. QoS is detailed in Chapters 11, “Introduction to Quality of Service (QoS),” and 12, “Configuring Quality of Service,” of this study guide.
Configuring Call Blocking In many business voice networks, there are telephone numbers that you simply don’t want anyone to call or, conversely, numbers that cannot call you. This usually includes premiumrate numbers that are typically in the 900 and 976 area code ranges in North America. Call blocking is typically performed at the call-processing agent level, either on CUCM, CUCMBE, or CUCM Express. Inbound call blocking can also be performed on SIP and H.323 gateways by using translation-reject rules and applying the translation profile to an incoming dial peer.
From a voice gateway’s perspective, incoming dial peers are either coming from telephony equipment that is connected to a telephony interface (such as a T1 from the PSTN) or coming from a VoIP peer device.
c09.indd 380
9/21/11 11:25:50 AM
Configuring Call Blocking
381
To demonstrate how call blocking works on voice gateways, we will use an example where we want to block all incoming calls from our T1 PRI that begin with the number 123555. The fi rst step to take is to create our voice translation rule (rule 123) that will be triggered by that number and prevent the call from completing. Here is how we can configure our specific rule: Router#configure terminal Router(config)#voice translation-rule 123 Router(cfg-translation-rule)#rule 1 reject /^123555/ Router(cfg-translation-rule)#end Router#
Now that we have our voice translation rule defi ned, we can make our voice translation profi le and apply our rule. To do this, we will configure a new voice translation profi le and name it block_900. Once we are in cfg-translation-profile mode, we apply translation rule 123, as shown here: Router#configure terminal Router(config)#voice translation-profile block_900 Router(cfg-translation-profile)#translate calling 123 Router(cfg-translation-profile)#end Router#
Our fi nal step will be to apply the voice translation profi le to our inbound POTS dial peer from the PSTN. In our case, let’s say we already have POTS dial peer 100 configured as our inbound dial peer for our PSTN connection. Therefore, we simply apply the following configuration: Router#configure terminal Router (config)#dial-peer voice 100 pots Router(config-dial-peer)#call-block translation-profile incoming block_900 Router(config-dial-peer)#end Router#
Now, our voice gateway will block any number with a calling number of 123555. It will return a “no service” disconnect message to the calling party.
If you want to change the disconnect message from the default, you can do so by using the call-block disconnect-cause incoming command followed by one of four different disconnect causes that are configured in the dial peer. These causes are shown in the following output:
Router(config-dial-peer)#call-block disconnect-cause incoming ? call-reject Call Reject invalid-number Invalid Number
c09.indd 381
9/21/11 11:25:50 AM
382
Chapter 9
■
unassigned-number
Advanced Voice Gateway Features
Unassigned Number
user-busy
User Busy Router(config-dial-peer)#call-block disconnect-cause incoming
We can test our call-blocking configuration by using the test voice translation-rule command and specifying translation rule 123 along with a number beginning with 123555, as shown here: Router#test voice translation-rule 123 1235556542 1235556542 blocked on rule 1 Router#
Summary Voice gateways are a bit of a Swiss army knife in terms of what they can be configured to do for voice services, reliability, and customization. In Chapter 9, we moved beyond basic voice gateway configuration to configure various scenarios that you will likely face in the real world. We explored ways to more effectively transport DTMF, fax, and modem transmissions when using H.323, SIP, and MGCP signaling. In addition, we looked at several voice backup design methods that help to provide the mission-critical reliability that is required in most voice networks. Lastly, we looked at various ways we can restrict, bypass, and block calls that should turn into PSTN cost savings if implemented properly.
Exam Essentials Know the four methods for configuring H.323 DTMF relay. H.323 DTMF relay can be configured using Cisco’s proprietary method, the H.245 alphanumeric method, the H.245 signal method, and the RFC 2883 RTP-NTE method. Know the two methods for configuring SIP DTMF relay. SIP DTMF can be configured using the RFC 2883 RTP-NTE method or the SIP notify method. Know the two methods for configuring MGCP DTMF relay. SIP DTMF relay can be configured using the CUCM call agent (CA) or locally using the voice gateway (GW) method. Know the three fax-relay methods. and T.37 store-and-forward fax.
c09.indd 382
The three methods are fax relay, fax pass-through,
9/21/11 11:25:51 AM
Exam Essentials
383
Understand the two types of fax relay. The Cisco fax relay method is proprietary and uses Cisco voice gateways to demodulate and remodulate analog transmissions across an IP network. The T.38 method is essentially the same, but it uses ITU-T open standards. Understand how fax pass-through functions. Fax pass-through simply creates a voice channel using a low-compression codec for the transport of voice. It is the simplest yet least reliable method. Understand the benefits of T.37 store-and-forward fax. The advantages are in its reliability and ease in sending a single message to multiple recipients because of its use of SMTP for transport. Know the two types of modem support on Cisco voice gateways. pass-through and modem relay.
Cisco supports modem
Understand the primary differences between sending fax transmissions and sending modem transmissions. With modem transmissions, the data starts out in a digital format. Additionally, modem speeds can vary throughout a transmission, but a fax rate is statically set. Know the key command used to create WAN-to-PSTN fallback configurations. The preference command is used to create multiple dial peers to the same destination but assign a priority to them. That way, the voice gateway will always choose the most preferred route that is currently available. Understand the importance of configuring MGCP fallback. MGCP fallback is important in cases where your MGCP gateway cannot communicate with the call-processing agent. Understand the purpose of COR. Class of Restriction is used to create a structured set of dialing rules that can be applied to a phone or a group of phones. It is often used in situations where some phones should only be allowed internal, local, long-distance, or international dialing access. Know how to configure basic SCCP SRST. SRST is configured similarly to the way CUCM Express is configured. You create an IP source address for the phones so they know where the call-processing agent (the SRST router) resides. Then it’s a matter of configuring ephone-DNs and associating them to buttons on ephones. Understand the purpose of toll bypass and TEHO. Toll bypass and TEHO are configured on networks that span a large geographical region in order to save on PSTN long-distance charges. TEHO takes toll bypass one step further by dropping off connections at the PSTN of a remote site so the call is technically local, as opposed to long distance. Know how to configure call blocking on a voice gateway. Call blocking can be configured for inbound calls into a voice gateway. To do this, you can create a translation rule and profi le that reject a number or range of numbers that you choose to block. Once the rule is created, you then apply it as an inbound rule on your dial peer.
c09.indd 383
9/21/11 11:25:51 AM
384
Chapter 9
■
Advanced Voice Gateway Features
Written Lab 9.1 1.
What is the command that configures H.323 DTMF relay for the method that uses RFC 2883 and explicitly drops in-band tones from being sent?
2.
What fax transport method uses the concept of virtual fax machines?
3.
What config-dial-peer command is used to statically set the fax transmission speed to 9600 bps?
4.
What SIP fax-relay command can be used to help ensure transmissions succeed on a link with more than 2 percent packet loss?
5.
What are the names of the two MGCP fax-relay configuration methods?
6.
What tone frequency does a voice gateway, configured for fax pass-through, listen for to detect the transmission of a line?
7.
You are configuring a voice gateway for redundant paths. What config-dial-peer command will ensure that the dial peer will be used unless unavailable because of a failure?
8.
What command can be used to verify the status of MGCP-to-H.323 fallback?
9.
What config-dial-peer command can be used to set an outbound COR list named int-out?
10. When configuring, you should use voice translation rules and profiles to send the
correct
to the PSTN.
(The answers to Written Lab 9.1 can be found following the answers to the review questions for this chapter.)
Hands-On Labs To complete the labs in this section, you need two Cisco routers with a voice-capable IOS. Each lab in this section builds upon the last and will follow the logical voice gateway design shown in Figure 9.9. FIGURE 9.9
Toll bypass and TEHO labs Area code 123
Area code 555 IP WAN
V
Ext: 456-7890
SiteA
S1/0:23
10.1.1.1 V
PSTN
SiteB
Ext: 888-3434 PSTN
c09.indd 384
9/21/11 11:25:52 AM
Hands-On Labs
385
This lab assumes that basic IP networking and the local voice network is operational. We are only concerned with configuring SiteA’s voice gateway. Here is a list of the labs in this chapter: Lab 9.1: Configuring Toll Bypass and PSTN Redundancy Lab 9.2: Configuring TEHO
Hands-On Lab 9.1: Configuring Toll Bypass and PSTN Redundancy In this lab, we’re going to configure the SiteA voice gateway for toll bypass to SiteB. The SiteB extensions all begin with a site code of 888 followed by a four-digit extension. The preferred path to SiteB should be across the IP WAN with a backup path across the PSTN. Additionally, make sure to configure an off-network dial peer using 9 as the off-network trigger digit. SiteA phones should be able to access local, long-distance, and international phones. 1.
Log into the local voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
We will fi rst create dial peer 888 to send calls to SiteB phones across the IP WAN. To do this, enter conf-dial-peer mode by typing dial-peer voice 888 voip.
3.
Configure a destination-pattern to match on site-code 888 followed by four wildcard digits, by typing destination-pattern 888....
4.
Configure the dial peer to forward all seven digits, by typing no digit-strip.
5.
Configure the next-hop destination to send calls over the IP WAN to SiteB, by typing session-target ipv4:10.1.1.1.
6.
Configure the dial peer to be the preferred path, by typing preference 1.
7.
Return to global configuration mode by typing exit.
8.
Create dial peer 889 to send calls to SiteB phones across the PSTN if the IP WAN is unavailable. To do this, enter into conf-dial-peer mode by typing dial-peer voice 889 pots.
9.
Configure a destination-pattern to match on site-code 888 followed by four wildcard digits by typing destination-pattern 888....
10. Configure the dial peer to add the USA nation code and area code for SiteB so the
correct 11-digit number is sent to the PSTN, by typing prefix 1555. 11. Configure the dial peer to forward all seven of the entered digits, by typing no digit-strip.
12. Configure the next-hop destination to send calls out the T1 and over to the PSTN, by
typing port 1/0:23. 13. Configure the dial peer to be the backup path, by typing preference 2. 14. Return to global configuration mode by typing exit.
c09.indd 385
9/21/11 11:25:52 AM
386
Chapter 9
■
Advanced Voice Gateway Features
15. Create dial peer 9 to send all off-network calls (except for SiteB phones) out the PSTN. To do this, enter into conf-dial-peer mode by typing dial-peer voice 9 pots. 16. Configure a destination pattern to match on all numbers starting with 9, by typing destination-pattern 9T.
17. Configure the next-hop destination to send calls out the T1 and over to the PSTN, by
typing port 1/0:23. 18. Exit config-dial-peer mode by typing end.
Hands-On Lab 9.2: Configuring TEHO In Lab 9.2 we will configure TEHO on the SiteA voice gateway for all calls destined for the 555 area code. We also want to make sure the correct ANI is displayed when phones at SiteA use TEHO to call off-network phones in the 555 area code. 1.
Log into the local voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Create a voice translation rule by typing voice translation-rule 1. You will be placed into cfg-translation-rule mode.
3.
Create a rule that appends 1–123 to the beginning of the seven-digit ANI that is configured on phones at SiteA by typing rule 1 /^2/ /1123/.
4.
Exit cfg-translation-rule mode by typing exit.
5.
Configure a voice translation profi le (named siteb-teho-loc-code) by typing voice translation-profile siteb-teho-loc-code. You will be placed into cfg-translationprofile mode.
6.
Add translation rule 1 that we just created as a calling match rule by typing translate calling 1.
7.
Exit cfg-translation-profile mode by typing exit.
8.
Configure a new VoIP dial peer that matches destination telephone numbers that start with 91555 followed by seven wildcard digits by typing destination-pattern 91555.......
9.
Configure the next-hop destination to send calls over the IP WAN to SiteB by typing session-target ipv4:10.1.1.1.
10. Apply our translation profi le to append a country code and area code to the ANI of the
calling number by typing translation-profile outgoing siteb-teho-loc-code. 11. Exit config-dial-peer mode by typing end.
c09.indd 386
9/21/11 11:25:53 AM
Review Questions
387
Review Questions 1.
You configure the following config-dial-peer DTMF relay command: Router(config-dial-peer)#dtmf-relay h245-alphanumeric h245-signal rtp-nte
What order of preference will the voice gateway use for the signaling method? A. 1. h245-alphanumeric 2. cisco-rtp 3. h245-signal 4. rtp-nte B.
1. cisco-rtp 2. rtp-nte 3. h245-signal 4. h245-alphanumeric
C.
1. cisco-rtp 2. h245-signal 3. h245-alphanumeric 4. rtp-nte
D.
1. h245-alphanumeric 2. rtp-nte 3. cisco-rtp 4. h245-signal
2.
If DTMF relay support is not configured, how are DTMF tones transported across IP networks? A. In band
3.
B.
In the data channel
C.
As a pulse
D.
In the bearer channel
What voice gateway fax transport method transmits fax messages over an IP network the same way that voice messages are transported? A. T.30
4.
B.
T.37
C.
Fax relay
D.
Fax pass-through
What fax relay method uses the concept of virtual fax interfaces? A. T.37
c09.indd 387
B.
Cisco fax relay
C.
Fax pass-through
D.
Store-and-forward fax
E.
T.38
9/21/11 11:25:53 AM
Chapter 9
388
5.
■
Advanced Voice Gateway Features
You are reviewing a SIP voice gateway configured with T.38 fax relay and see the following configuration entry: dial-peer voice 101 voip session protocol sipv2 fax protocol t38 ls-redundancy 3
What does ls-redundancy 3 mean? A. Will attempt to use the Cisco proprietary fax-relay method as a backup in case T.38 fails B.
6.
Specifies the number of times a T.38 fax can fail before giving up on low-speed connections
C.
Uses the group 3 fax transmission method
D.
Specifies sending three T.38 packets using the low-speed V.21-based T.30 protocol
What is the maximum fax transmission rate for SG3 fax machines? A. 14,400 bps B.
7.
28,800 bps
C.
33,600 bps
D.
56,000 bps
What are the two fax tone transmissions that can be used on T.38 fax relay? A. fax protocol t38 nse
8.
B.
fax protocol t38 tse
C.
fax-relay sg3-to-g3
D.
fax-relay ans-disable
You are reviewing an MGCP voice gateway T.38 fax-relay configuration and run across the following command entry: mgcp fax t38 ecm gateway force
What is the purpose of the gateway force keyword? A. It overrides nonstandard facilities (NSF) code with a unique code that is dependent on the two-digit hexadecimal code entered to specify the fax-machine vendor.
9.
B.
It disables T.38 fax relay on MGCP. By default, T.38 fax relay is enabled.
C.
It requires the use of Cisco proprietary named service events (NSEs).
D.
It enables error correction mode (ECM) for the gateway, which better ensures the proper receipt of all packets.
How are faxes transmitted across the IP network using the T.37 store-and-forward method? A. TIFF images attached in emails
c09.indd 388
B.
TCL scripts attached in emails
C.
In special RFC 2883 RTP packets
D.
In special Cisco proprietary packets
9/21/11 11:25:54 AM
Review Questions
389
10. Which of the following external components is required to operate T.37 store-and-forward fax? A. CUCM, CUCM BE, or CUCM Express B.
Unity or Unity Express
C.
SMTP server
D.
DHCP server
11. Which of the following is not a primary difference between analog fax and modem transmissions? A. Fax transmission is not supported on MGCP gateways. B.
Modem transmission is only supported using pass-through techniques.
C.
Modem transmission is only supported on H.323 and SIP networks.
D.
Modem transmission rates can vary.
12. Which of the following commands and command modes is used to configure locally controlled modem relay using MGCP NSE? A. Router(config)#mgcp modem relay voip mode nse gw-controlled B.
Router(config-dial-peer)#mgcp modem relay voip mode nse gw-controlled
C.
Router(config)#mgcp modem relay voip mode nse ca-controlled
D.
Router(config-dial-peer)#mgcp modem relay voip mode nse ca-controlled
13. What command is needed within the dial-peer configuration when configuring MGCP to H.323 fallback? A. ccm-manager fallback-mgcp B.
service alternate default
C.
application mgcpapp
D.
mgcp-to-h323
14. What show command can be used to see if MGCP to H.323 fallback has taken place? A. show ccm-manager fallback-mgcp B.
show ccm-manager fallback-h323
C.
show voice fallback mgcp
D.
show voice fallback h323
15. When is it common to configure COR on a voice gateway? A. On large networks
c09.indd 389
B.
On networks that utilize MGCP
C.
On networks that utilize H.323 or SIP
D.
When voice gateways are configured for SRST
9/21/11 11:25:54 AM
Chapter 9
390
■
Advanced Voice Gateway Features
16. Which of the following commands and configuration modes are used to begin the process of creating COR members? A. Router(config)#dial-peer cor custom B.
Router(config-voi-serv)#dial-peer cor custom
C.
Router(config-voi-serv)#dial-peer cor list
D.
Router(config)#dial-peer cor list
17. Which of the following will assign extensions 4000–4010 to COR list 3 using a privilege of emergency? A. cor incoming emergency 3 4000-4010 B.
cor assign emergency 3 4000-4010
C.
cor incoming emergency 3 4000 4010
D.
cor assign emergency 3 4000 4010
18. You are reviewing a voice gateway configured for TEHO and come across the following configuration commands in the running configuration: dial-peer voice 555 voip destination-pattern 91555....... session-target ipv4:192.168.1.10 translation-profile outgoing remote-teho-loc-code
What is likely to be the purpose of the translation-profile outgoing remote-teho-loc-code configuration entry? A. To hide the calling number from the remote voice gateway B.
To block the calling number from the remote voice gateway
C.
So that the full and proper CLID number will be sent to the remote voice gateway
D.
So that the full and proper ANI number will be sent to the remote voice gateway
19. Which of the following answers correctly identifies the configuration commands shown here? Router(config)#voice translation-rule 1 Router(cfg-translation-rule)#rule 1 reject /^773555/
A. A class-of-restriction rule to block numbers that are greater than 7735555 B.
A class-of-restriction rule to block numbers that begin with 773555
C.
A call-blocking rule to block numbers that begin with 773555
D.
A class-of-restriction rule to block a specific area code and central office code
E.
A call-blocking rule to block numbers greater than 7735555
20. Which of the following is not a call-block disconnect cause message? A. Reorder-reject
c09.indd 390
B.
Call-reject
C.
Invalid-number
D.
User-busy
E.
Unassigned-number
9/21/11 11:25:55 AM
Answers to Review Questions
391
Answers to Review Questions 1.
B. The order that the voice gateway will prefer, regardless of order entered into the IOS, is as follows: 1. cisco-rtp 2. rtp-nte 3. h245-signal 4. h245-alphanumeric
2.
A. DTMF relay transports signals out of band. If this is not configured, the tones are sent in band along with the standard voice signals.
3.
D. Fax pass-through transmits fax messages over IP networks using the same RTP packets. The only difference is that it will negotiate so that the G.711 low-compression codec is used to increase the chances that the fax is transmitted accurately.
4.
B. The Cisco fax relay method uses the concept of virtual fax interfaces that terminate at the voice gateway.
5.
D. ls-redundancy will send multiple, redundant packets to the remote end to help to ensure the receipt of those packets. In this case, three redundant packets will be sent.
6.
C. The maximum fax transmission rate for Super Group 3 (SG3) class fax machines is 33,600 bps.
7.
C, D. Both the fax-relay sg3-to-g3 and fax-relay ans-disable commands are used to suppress answer (ANS) tones. This is done if you want to transport faxes at a lower rate.
8.
C. The gateway force keyword forces the gateway-controlled fax relay service to use Cisco’s proprietary NSEs.
9.
A. T.37 faxes use emails for transport and attach fax transmissions as TIFF image fi les.
10. C. An SMTP server is required for T.37 store-and-forward fax because the method uses emails to send faxes in attached TIFF images. 11. D. One primary difference between how fax and modem transmissions are handled is that analog fax transmission rates are static, while modem transmissions can vary throughout the connection. 12. A. The correct command is mgcp modem relay voip mode nse gw-controlled, and this command can only be entered while in global configuration mode. 13. C. When configuring MGCP to H.323 fallback, you must configure dial peers. Within those dial peers, you must add the application mgcpapp command to designate these dial peers as backups in case the voice gateway loses connectivity to the call-processing agent. 14. A. The show ccm-manager fallback-mgcp command will display if the voice gateway can communicate to the CUCM or if it has fallen back to H.323.
c09.indd 391
9/21/11 11:25:55 AM
392
Chapter 9
■
Advanced Voice Gateway Features
15. D. Typically, COR is configured on the CUCM. One exception is when a voice gateway is also configured for SRST. When in SRST mode, the voice gateway can also enforce COR rules. 16. A. The correct command is dial-peer cor custom, and it is set while in global configuration mode. 17. C. The correct syntax is cor incoming emergency 3 4000 4010. This is configured while in config-cm-fallback configuration mode. 18. D. When you configure TEHO, you should also configure a translation rule and profi le so that the ANI number of the local calling phone is correct before sending it to the remote voice gateway. 19. C. This is a call-blocking rule that will fi nd and reject numbers beginning with 773555. 20. A. All of the messages are possible disconnect cause messages when configuring call-block except reorder-reject.
c09.indd 392
9/21/11 11:25:56 AM
Answers to Written Lab 9.1
393
Answers to Written Lab 9.1 1.
dtmf-relay rtp-nte digit-drop
2.
Cisco fax relay
3.
fax rate 9600 voice
4.
fax-relay ecm disable
5.
Call agent (CA) and gateway (GW)
6.
2100 Hz
7.
preference 1
8.
show ccm-manager fallback-mgcp
9.
corlist outgoing int-out
10. Automatic Number Identification (ANI)
c09.indd 393
9/21/11 11:25:56 AM
c09.indd 394
9/21/11 11:25:56 AM
Chapter
10
Configuring and Managing CUBE and H.323 Gateways THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Implement Cisco Unified Border Element. ■
Describe the Cisco Unified Border Element features and functionality.
■
Configure Cisco Unified Border Element to provide address hiding.
■
Configure Cisco Unified Border Element to provide protocol and media internetworking.
■
Configure Cisco Unified Border Element to provide call admission control.
■
Verify Cisco Unified Border Element configuration and operation.
c10.indd 395
9/21/11 11:26:22 AM
In this chapter we’ll look at equipment that is used to help manage large voice networks. First, we’ll examine the H.323 gatekeeper to see how it can be used to break networks into zones and how to interact with multiple gatekeepers that control different zones within a network. You might notice that gatekeepers aren’t part of the official exam objectives, but understand that they are a critical part of the 642-437 exam. Once we fi nish our coverage of gatekeepers, we’ll move on to look at the Cisco Unified Border Element (CUBE) to see how it is different from a standard voice gateway and how it can connect two voice networks using a pure IP-to-IP solution when the networks are running either SIP or H.323.
What Is an H.323 Gatekeeper? H.323 can function fairly well on its own just being configured on voice gateways, as you learned in Chapter 7, “Configuring Voice Gateway Signaling Protocols.” When you begin dealing with larger networks, H.323 simply doesn’t scale well without the help of an H.323 gatekeeper to manage your voice network, by breaking it up into multiple zones. Your H.323 gateways will quickly become cluttered with multiple dial peers that often cause confusion, and are a pain to maintain when you are dealing with multiple voice gateways. A better solution is to install one or more gatekeepers into an H.323 network to perform the following mandatory and optional functions, shown in Table 10.1. TA B L E 1 0 .1
Mandatory and optional H.323 gatekeeper functions
Mandatory
Optional
Zone management
Call authorization
Address translation
Call management
Call admission control (CAC)
Bandwidth management
Bandwidth control
Let’s break down each of these mandatory and optional H.323 functions to better understand what the H.323 gatekeeper can provide.
c10.indd 396
9/21/11 11:26:24 AM
What Is an H.323 Gatekeeper?
397
H.323 Gatekeeper Mandatory Features The primary responsibilities of an H.323 gatekeeper are to control call routing, call permission, and call settings on the network. The H.323 mandatory features control each of these functions.
Zone Management Gatekeepers use the concept of logical zones to segment large networks into small and more manageable chunks. A single zone may contain one or more voice gateways, multipoint control units (MCUs), or H.323 endpoints. The H.323 gatekeeper’s responsibility is to manage all registered devices within the zone and to provide information about how to route calls between zones. Figure 10.1 shows an example of a gatekeeper managing two different zones in a network. F I G U R E 1 0 .1
A network controlled by a single H.323 gatekeeper
V
Gatekeeper
Zone1
V
V
Voice Gateway1
Voice Gateway2
Zone2
In our example, you see that we have two zones connected to our gatekeeper. The gatekeeper that directly controls a zone considers them to be local zones, yet our gatekeeper does not specifically belong to a zone itself. There can also be multiple gatekeepers configured that manage different zones, as shown in Figure 10.2. F I G U R E 10. 2
A network controlled by multiple H.323 gatekeepers Gatekeeper1
Zone1
c10.indd 397
V
V
Gatekeeper2
V
V
Voice Gateway1
Voice Gateway2
Zone2
9/21/11 11:26:24 AM
398
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Now you see that Gatekeeper1 controls Zone1 and Gatekeeper2 controls Zone2. When a device in Zone1 needs to contact a phone in Zone2, the H.323 endpoint or gateway contacts its local gateway. The local gateway does not know about the zone, because it does not directly control it. The two zones in the example therefore are considered to be remote zones to each other, since they are not controlled by the same gatekeeper. In order for remote gateway calls to work, the two gatekeepers communicate with each other and Gatekeeper1 forwards the request to the unknown zone to Gatekeeper2. Gatekeeper2 knows about Zone2 because it is local to it, and the call can be completed.
Address Translation The H.323 gatekeeper maintains a telephone-number-to-IP-address table. When an H.323 endpoint or gateway sends call information to the gatekeeper, it provides the destination telephone address but does not know how to reach the remote endpoint. The gatekeeper’s table maps telephone numbers to next-hop IP addresses. The IP address information is passed back to the original requester so it can attempt to establish a call with the intended remote device. The IP address that is given is where the H.225 setup packet should be sent from the H.323 calling endpoint.
Call Admission Control So now you know that H.323 gatekeepers control H.323 zones for management purposes and possess routing information about where endpoints reside in the network. Given this information, we can make calls across the entire network. But what if we want to prevent some calls from being made between zones? Since the H.323 gatekeeper is at the center of all the action, there is no better place to implement admission control. To accomplish admission control between H.323 devices, gatekeepers use H.225 Registration Admission and Status (RAS) messages. RAS messages are used for multiple H.323 services and are explained in detail in the “Understanding Gatekeeper Signaling” section of this chapter.
Bandwidth Control Because the gatekeeper is for providing call admission services using an H.323 gatekeeper, the centralized location of a gatekeeper is ideal for controlling bandwidth usage between endpoints. Bandwidth control uses RAS messages to negotiate codec rates and bandwidth limits with endpoints.
H.323 Gatekeeper Optional Features The optional H.323 gatekeeper functions revolve around the optimal management of the network for operation of voice over an IP network. This includes functions such as call authorization, call management, and bandwidth control; we will talk about each of these next.
Call Authorization Situations arise where you want to restrict the access to endpoints or entire zones based on various policies. These policies can be configured as either permit or deny rules, depending
c10.indd 398
9/21/11 11:26:25 AM
Understanding Gatekeeper Signaling
399
on the structure of the rule set. A common example of a call authorization would be to deny calls to call-center endpoints based on the time of day.
Call Management Call management deals with using in-progress call status information to better manage call routing based on the information. For example, if the gatekeeper knows that a particular H.323 endpoint is already in a connected call, and a second call comes into the gatekeeper, it can respond to the calling party with a busy signal on behalf of the called party. Call management can further be used for call-redirection purposes as well.
Bandwidth Management When you think of bandwidth management, you should think of call admission control (CAC), the technique by which bandwidth usage is tracked across the network by the gatekeeper. When new calls come into the gatekeeper, it can make the decision to allow the call to proceed because sufficient bandwidth is available. If, however, the gatekeeper finds that there is not enough bandwidth available at the current time, it can reject new calls from being made until sufficient bandwidth has been reclaimed. CAC is one of the most common reasons for implementing a gatekeeper.
Understanding Gatekeeper Signaling Gatekeepers communicate with other H.323-speaking devices, such as endpoints or H.323 voice gateways, by using signaling. RAS falls under the H.225 protocol within the overall H.323 umbrella. Signaling messages are sent between devices using the User Datagram Protocol (UDP). When a gatekeeper is involved in the call-setup process on an H.323 network, RAS messages are sent between the party requesting the call and the gatekeeper. If no gatekeeper is used, these messages are sent directly between the registered endpoints involved in the call. There are a number of RAS messages used within the H.323 protocol suite for various communication messages between gatekeepers and endpoints/voice gateways. This section will detail the most commonly used messages in a Cisco environment.
RAS Gatekeeper Discovery Messages H.323 voice gateways and endpoints need to be able to fi nd the gatekeeper. Following are the three gatekeeper discovery message types:
Gatekeeper Request (GRQ)
Gatekeeper Confi rm (GCF)
Gatekeeper Reject (GRJ)
On voice gateways, there are two slightly different methods of discovering a gatekeeper. The fi rst method is to preconfigure your H.323 voice gateways with the IP address of your
c10.indd 399
9/21/11 11:26:25 AM
400
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
gatekeeper. Because the gateway is preconfigured with an IP address, it can send a unicast GRQ message and wait to receive either a GCF, which means the gatekeeper is available, or a GRJ if for some reason the gatekeeper cannot allow endpoints to register. If the voice gateway (or any other H.323 endpoint) is not preconfigured with the gatekeeper’s IP address, it will send the same GRQ message but this time as a multicast message instead of a unicast message. This is known as dynamic gatekeeper discovery, and the message is sent to the multicast address of 224.0.1.41.
RAS Gateway Registration Messages If the discovery process resulted in a gatekeeper confi rm (GCF) message, the next step is registration. The following messages are used in the registration process:
Registration Request (RRQ)
Registration Confi rm (RCF)
Registration Reject (RRJ)
The endpoint or voice gateway initiates this process by sending an RRQ message to the gatekeeper that was previously discovered. This is essentially a permission message, and the gatekeeper can either accept the registration using the RCF message or reject the registration using an RRJ response message. If an RCF message is sent back, that endpoint or voice gateway is now considered to be registered to the gatekeeper. That’s not the end of the registration messages, however. H.323 also uses these messages as keepalives to ensure connectivity. H.323 version 1 devices will send all of the original message information contained in a standard RRQ message. These messages are sent every 30 seconds. This information obviously isn’t required if the registration process has been completed, and it leads to wasted bandwidth. Fortunately, version 2 of the H.323 protocol suite sends what is known as lightweight registration messages. If this version is used, it means that RRQ messages contain only basic information and consume far less bandwidth. The lightweight registration messages specify a time to live (TTL) either in the endpoint/voice gateway RRQ or the gatekeeper response RCF. Each time registration messages are sent, the TTL is decreased and the keepalive field is set to true until the TTL expires. When the TTL expires, the full RRQ message is sent to verify that no changes have been made.
RAS Call Admission Messages After the H.323 endpoints or voice gateways have received a registration confi rm (RCF) message from the gatekeeper, calls can be attempted through the gatekeeper. Notice that the word attempted is used here. What happens is that when an endpoint wants to make a call, it sends admission messages between itself and the gatekeeper. Here are all of the admission message types:
c10.indd 400
Admission Request (ARQ)
Admission Confi rmation (ACF)
Admission Reject (ARJ)
9/21/11 11:26:26 AM
The H.323 Gatekeeper Discovery, Registration, and Admission Process
401
When the H.323 gatekeeper receives an ARQ message from a registered device, it makes the following two decisions: 1.
Is the call permitted to go through? Or more specifically, is there enough bandwidth available over the link to support the call at the current time? If the call is denied, an ARJ message is sent back to the requesting device.
2.
If the call is permitted, how should it be routed? This is where the gatekeeper does a table lookup to determine where the next-hop IP address is for this particular E.164 telephone number. Once the routing information is known, the gatekeeper sends back an ACF message that both permits the call to be made and provides the IP location where the calling device can fi nd the called device.
The H.323 Gatekeeper Discovery, Registration, and Admission Process Let’s visualize the three H.323 gatekeeper RAS processes you’ve learned up to this point. We’ll use Figure 10.3 as our example network. F I G U R E 10. 3
Gatekeeper RAS discovery, registration, and admission
S RA
V
Gatekeeper
RA S
Zone1
Zone2 V
Voice_GW_1 4444
V
H.225 H.245
Voice_GW_2 5555
RTP RTP
In our example network, we have two H.323 voice gateways that require the services of an H.323 gatekeeper. All of our RAS communication will take place between the voice gateways and the gatekeeper, while the H.225, H.245, and RTP streams occur directly between the two voice gateways. Let’s step through an example of all the messaging that occurs to complete a call, using Figure 10.3. Voice_GW_1 has the IP address manually configured and therefore sends a unicast GRQ to the gatekeeper. Voice_GW_2, on the other hand, does not have the IP of the gatekeeper and must therefore send a unicast message across the WAN. The gatekeeper receives both messages and is available for registration, so a GCF is sent back to the voice gateways.
c10.indd 401
9/21/11 11:26:26 AM
402
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Receiving the GCF, the voice gateways attempt to register to the gatekeeper by sending an RRQ. The messages are received and the gatekeeper permits both devices to register. A RCF message is sent back to both voice gateways to confi rm this. At this point, our two voice gateways are registered and ready to field calls to the gatekeeper. Now let’s say that our phone at extension 4444 attempts to call extension 5555. The call is handled by Voice_GW_1, which in turn sends an ARQ to its registered gatekeeper. The ARQ contains E.164 numbers of the calling and called parties. The gatekeeper ensures that the call has enough bandwidth to be made and finds the next-hop IP address where the called party phone is located. This information is packaged and sent back to Voice_GW_1 in the form of an ACF message. Now that Voice_GW_1 knows the location of the remote phone, it sends an H.225 call-setup message to the remote voice gateway, which happens to be Voice_GW_2 in this example. Now that our remote voice gateway is involved in a new call, it too must send an ARQ message and wait for an ACF message response before the call can be permitted. Once the ACF message is received by both voice gateways, the H.225 message-exchange process can be completed as usual. As soon as this process is completed, the two voice gateways handle the H.245 exchange messages, and two RTP sessions are set up between the endpoints when the call is established.
RAS Location Messages If your H.323 network uses multiple gatekeepers, the gatekeepers will use interzone messages among one another to exchange information regarding zones that each of them are responsible for. The following location request messages are used:
Location Request (LRQ)
Location Confi rm (LCF)
Location Reject (LRJ) Using Figure 10.4 as our example, let’s go through the location request message process.
F I G U R E 10. 4
RAS location messages RAS location messages
Gatekeeper1
V
V
Gatekeeper2
Zone1
Zone2 V
Voice_GW_1 7777
c10.indd 402
V
Voice_GW_2 8888
9/21/11 11:26:27 AM
The H.323 Gatekeeper Discovery, Registration, and Admission Process
403
Let’s say that our voice gateways are properly registered to their respective gatekeepers. A call is made from extension 7777 to extension 8888. The Voice_GW_1 sends an ARQ to Gatekeeper_1. This gatekeeper does not have any information about extension 8888, because it is in a zone managed by Gatekeeper_2. Gatekeeper_1 sends an LRQ to its neighbor, Gatekeeper_2, which is responsible for the zone that extension 8888 resides in. Gatekeeper_2 verifies permissions and looks up the necessary next-hop IP address information and sends it back to Gatekeeper_1 in the form of an LCF message. Gatekeeper_1 then takes the newly acquired information, places it into an ACF message, and sends it back to Voice_GW_1, and the connection can be established. If you have more than two gatekeepers, location messages can be sent either sequentially to individual gatekeepers or in a “blast,” where all gatekeepers are sent LRQ messages at one time. If you have gatekeepers configured with identical zones, you will want to use sequential forwarding, which happens to be the default setting. With sequential forwarding, you can specify which gatekeepers should be sent LRQ messages over others. If you don’t have any overlapping zones, however, you may want to consider the blast method, because it provides faster response times. Figure 10.5 shows the sequential method of location message forwarding.
F I G U R E 10. 5
Sequential location message forwarding
V
LRQ #1 LRJ LRQ #2
ARQ
Zone_A
Zone_B
Gatekeeper2
V
Gatekeeper1
LRJ LRQ #3
V
Zone_C
Gatekeeper3 LCF
V
Zone_D
Gatekeeper4
As you can see, Gatekeeper1 receives an ARQ from Zone_A for a phone in Zone_C. Gatekeeper1 is set up to sequentially send LRQ messages to remote gatekeepers, so it fi rst sends a request to Gatekeeper2. Gatekeeper1 receives an LRJ message from Gatekeeper2 that indicates this gatekeeper has no knowledge of Zone_C. Gatekeeper1 sends a second LRQ message to Gatekeeper3 and again receives a reject message. Finally, Gatekeeper1 sends a third LRQ message to Gatekeeper4, which has knowledge of Zone_C and therefore sends an LCF message to Gatekeeper1. Finally, the blast method of location message forwarding is shown in Figure 10.6.
c10.indd 403
9/21/11 11:26:27 AM
404
Chapter 10
F I G U R E 10.6
■
Configuring and Managing CUBE and H.323 Gateways
Blast location message forwarding
V
Zone_B
Gatekeeper2 LRQ Blast ARQ
Zone_A
V
V
Gatekeeper1
Zone_C
Gatekeeper3 LCF
V
Zone_D
Gatekeeper4
Here you see that LRQs are sent to all gatekeepers at once. The fi rst gatekeeper to respond with an LCF is the one that will be used.
RAS Resource Availability Messages Special resource availability messages sent from voice gateways to gatekeepers can be used to update information about current call capacity and resource availability. This information is then used to permit calls and set bandwidth limitations on H.323 calls. The following messages are used:
Resource Availability Indicator (RAI)
Resource Availability Confi rmation (RAC)
Resource in Progress (RIP)
The H.323 voice gateway sends RAI messages that contain resource availabilities such as available bandwidth. If the gatekeeper successfully receives the RAI, it will process the information and return an RAC to the voice gateway. If there is a problem with resource availability, such as an RAS message timing out, the gatekeeper will send out a RIP message to the voice gateway to wait additional time for the gatekeeper confi rmation message before the call can be attempted.
RAS Bandwidth Messages After H.323 calls are established, it is possible that an endpoint can request that the bandwidth for a particular call be adjusted. The following bandwidth request messages are used between endpoints/voice gateways and gatekeepers:
c10.indd 404
Bandwidth Request (BRQ)
Bandwidth Confi rm (BCF)
Bandwidth Reject (BRJ)
9/21/11 11:26:28 AM
Configuring an H.323 Gatekeeper
405
The endpoint sends a BRQ message to the gatekeeper that can accept the request and make bandwidth adjustments to the stream. An acceptance of the BRQ requires that the gatekeeper send a BCF back to the requestor. If, however, the bandwidth request is denied, the BRJ message is sent back and bandwidth settings remain the same.
Configuring an H.323 Gatekeeper Now that you have a solid understanding of what H.323 gatekeepers offer and how they communicate, we will explore how to configure the following gatekeeper functions:
Local zones
Remote zones
Zone prefi xes
Technology prefi xes
We’ll go over each of these configuration steps in the following few sections. Figure 10.7 shows the network with dual gatekeepers that will be used to show how to configure H.323 gatekeeper and gateway interoperation. F I G U R E 10 .7
H.323 multi-gatekeeper network Domain: example.com Gatekeeper1 Tech prefix: 1# 99#
Gatekeeper2
V
10.99.99.1
V
10.5.5.1 5XXX
3XXX V
S0/0
S0/0
Boston
V
LA
Zone: Boston
Zone: LA
IP WAN 4XXX V
S0/0
Miami Zone: Miami
c10.indd 405
9/21/11 11:26:28 AM
406
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Configuring Local Zones Local zones are those zones that are managed by the local gatekeeper. For example, Gatekeeper1 has two local zones, Boston and Miami. H.323-speaking endpoints and voice gateways register directly to this gatekeeper. To configure our local zones, we must fi rst enter into config-gk mode by issuing the gatekeeper command. Next, we enter the zone local command, followed by the zone name, the domain name, and the RAS IP address. The zone name is the name of a local zone. The domain name is the fully qualified domain name (FQDN) of the gatekeeper and is used when DNS names are entered instead of IP addresses. Note that the domain-name information is required even if DNS services are not used. Finally, the RAS IP address is the IP address of the local gatekeeper that will be the source IP used for sending and receiving RAS messages. Because there can be only one IP address used for RAS communication on a gatekeeper, this command can be specified only once in a local zone configuration. Once the IP address is configured for one local zone, this address is used for all other configured local zones. Here is an example of how to configure Gatekeeper1 with local zones: Gatekeeper1#configure terminal Gatekeeper1(config)#gatekeeper Gatekeeper1(config-gk)#zone local Boston example.com 10.99.99.1 Gatekeeper1(config-gk)#zone local Miami example.com Gatekeeper1(config-gk)#no shutdown Gatekeeper1(config-gk)#end Gatekeeper1#
Don’t forget to issue the no shutdown command, which enables the gatekeeper service on your router.
The RAS IP address is often a loopback interface in situations where redundant connections exist. Since a virtual interface generally does not go down like a physical interface, it is considered to be more reliable.
Configuring Remote Zones Remote zones are the zones that are not configured locally and are handled by an external gatekeeper. As discussed previously, gatekeepers that are responsible for different zones communicate with each other using location RAS messages. In order for the RAS messages to be sent between gatekeepers, you must configure a remote zone and specify the FQDN and IP address of the remote gateway. In our example, we will configure a remote zone for our LA zone and specify that calls that are not configured locally should send an LRQ message to Gatekeeper2 to see if it has routing information for the unknown E.164 address. Here is an example of the remote zone configuration: Gatekeeper1#configure terminal Gatekeeper1(config)#gatekeeper
c10.indd 406
9/21/11 11:26:29 AM
Configuring an H.323 Gatekeeper
407
Gatekeeper1(config-gk)#zone remote LA la.example.com 10.5.5.1 Gatekeeper1(config-gk)#end Gatekeeper1#
Configuring Zone Prefixes Gatekeepers keep track of zones by using a unique zone prefix. A zone prefix uses E.164 numbers to define each zone. If a call made by an H.323 device reaches the gatekeeper, it checks the dialed number to see if it matches a specific prefix for a known local zone. If a match is made, the gatekeeper routes that call to the zone that is mapped to the zone prefix. To configure zone prefixes, we use the zone prefix command followed by the local zone name and a range of E.164 numbers that represent numbers within that zone. In our example, we will configure Gatekeeper_1 with two zone prefix commands for the Boston and Miami local zones: Gatekeeper1#configure terminal Gatekeeper1(config)#gatekeeper Gatekeeper1(config-gk)#zone prefix Boston 3... Gatekeeper1(config-gk)#zone prefix Miami 4... Gatekeeper1(config-gk)#end Gatekeeper1#
Now we’ve successfully mapped all 3XXX calls to the Boston zone and all 4XXX calls to Miami. Since we’ve already configured the next-hop IP address in our local zone configuration commands, the gatekeeper will perform an E.164-number-to-IP-address lookup and return the IP address of the correct gateway to the sending voice gateway.
Gateway Redundancy Anthony was developing a highly redundant H.323 gatekeeper and needed to configure gateway redundancy, in which multiple voice gateways are responsible for the same zone and thus the same phone groupings. In Anthony’s case, he was creating zone redundancy within the Atlanta_gw1 and Atlanta_gw2 gateways that covered phones in the 5XXX extension range. Anthony has already registered both voice gateways with the gatekeeper, but now he needs to configure the gatekeeper to send all calls to Atlanta_ gw1—unless it is unreachable, at which point the gatekeeper would use the Atlanta_gw2 route. To do this, Anthony discovered the gw-priority keyword within the zone prefix command. Anthony simply creates two zone prefix commands for extensions 5XXX in the Atlanta zone for both Atlanta_gw1 and Atlanta_gw2 voice gateways. But at the end of each of these commands, Anthony added gw-priority followed by a priority
c10.indd 407
9/21/11 11:26:30 AM
408
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
number and the gateway alias name. The higher the priority number, the more preferred the destination is. The range is 0 to 10. A priority of 0 means that the gatekeeper will never use the route. An example of using 0 as a priority would be when you want to specifically exclude a gateway from a gateway pool, because that pool would require that the gateway incur an expensive long-distance charge if it was allowed through. The default priority is 5. Therefore, Anthony chose to use a priority of 10 for Atlanta_gw1 and a priority of 5 for Atlanta_gw2, as shown here:
Gatekeeper#configure terminal Gatekeeper(config)#gatekeeper Gatekeeper(config-gk)#zone prefix Atlanta 5... gw-priority 1 Atlanta_gw1 Gatekeeper(config-gk)#zone prefix Atlanta 5... gw-priority 2 Atlanta_gw2 Gatekeeper(config-gk)#end Gatekeeper# Once this is configured, the gatekeeper will tell other gateways to use the Atlanta_gw1 path to the Atlanta zone. If it ever goes down, the gatekeeper will use the second most preferred route, which is the Atlanta_gw2 voice gateway.
Configuring Technology Prefixes On large networks, you might have voice gatekeepers that handle additional H.323 tasks. If this is true, you will need to configure technology prefixes, which are special numbers that when dialed connect to the appropriate voice gateway for the service that is needed. Your users will need to know the prefix numbers in order to include them as a prefix when the destination number is dialed. In addition, note that the technology prefix takes precedence over any zone prefixes. So even though the number dialed matches a zone prefix, the technology prefix number will be matched first and sent to the proper voice gateway. Also note that the technology prefix will be stripped off prior to forwarding the call to the destination voice gateway. By default, no technology prefixes are defined, so therefore LRQ messages will be sent to all gatekeepers either sequentially or simultaneously if the blast method is used. In our example, we will configure two technology prefi x commands on Gatekeeper1. To configure a technology prefi x, we use the gw-type-prefix command, followed by the prefi x extension and additional configuration keywords, as shown in our configuration: Gatekeeper1#configure terminal Gatekeeper1(config)#gatekeeper Gatekeeper1(config-gk)#gw-type-prefix 99# gw ipaddr 10.99.99.1 Gatekeeper1(config-gk)#gw-type-prefix 1# default-technology Gatekeeper1(config-gk)#end Gatekeeper1#
c10.indd 408
9/21/11 11:26:30 AM
Voice Gateway Interoperation with Gatekeepers
409
You will notice that our examples use the # sign as part of our technology prefix. This convention is commonly used in the real world to easily differentiate technology prefixes from other extensions. A technology prefix does not need to have any special characters, however, and can range from 1 to 11 digits in length.
In this scenario, we’ve just mapped the prefi x number 99# to our Boston remote voice gateway. In addition, the second technology prefi x that uses the default-technology keyword specifies that 1# be used as the default technology prefi x for this gatekeeper. Thus, all gateways that register with Gatekeeper_1 and use the 1# prefi x option are used as the default for routing any addresses that cannot be resolved. Keep in mind that your second gatekeeper should have technology prefi x configurations identical to the fi rst, to ensure proper interoperation of H.323 services.
Voice Gateway Interoperation with Gatekeepers Now that you’ve learned how to configure H.323 gatekeepers on an IP network, we need to shift our focus and explore how to configure H.323 voice gateways to interoperate with them. The following configuration steps are required to register a voice gateway to a gatekeeper: 1.
Configure the necessary H.323 commands on your designated H.323 signaling interface.
2.
Configure one or more dial peers that point to the local gatekeeper.
3.
Enable the H.323 process on your voice gateway.
Let’s go through how to configure each of these required steps on the Boston router using the multi-gatekeeper diagram from Figure 10.7.
Configuring H.323 Interface Commands As we configured for the H.323 gatekeeper, the voice gateway needs a designated interface that will always be used when communicating with the gatekeeper using RAS messages. First, we will enter into interface configuration mode for an interface that has an IP address configured. Next, we will use the h323-gateway voip command followed by various keywords to set up our interface for gatekeeper interoperation. The primary h323-gateway voip keywords are described next. interface
This keyword marks the interface as being a voice gateway interface.
bind srcaddr The bind srcaddr command is followed by the IP address of the interface you are using for H.323 functions.
c10.indd 409
9/21/11 11:26:31 AM
410
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
This keyword is used to specify the local zone the voice gateway operates in and the IP address of the local gatekeeper. This command is optional and allows the voice gateway to contact the gatekeeper using a unicast GRQ RAS message. If this command is not configured, the voice gateway will send the GRQ RAS message using multicast.
id
The h323-id keyword followed by the local zone name is another optional command that is used to specify what zone the voice gateway should register under.
h323-id
This keyword is followed by a prefi x number and is used to specify that our voice gateway wants to register with technology prefi x services.
tech-prefix
Using our network diagram in Figure 10.7, we will configure our Boston voice gateway to interoperate with Gatekeeper_1 on our serial 1/0 interface using the following commands: Boston#configure terminal Boston(config)#interface serial 0/0 Boston(config-if)#h323-gateway voip Boston(config-if)#h323-gateway voip Boston(config-if)#h323-gateway voip Boston(config-if)#h323-gateway voip Boston(config-if)#h323-gateway voip Boston(config)#end Boston#
interface id Boston ipaddr 10.99.99.1 h323-id Boston tech-prefix 1# tech-prefix 99#
Configuring Dial Peers for Gatekeeper Interoperation When using an H.323 gatekeeper for routing information, you need to enter the VoIP dial peer session target ras command. This tells the router to request routing information from its locally configured H.323 gatekeeper using RAS messaging. The gatekeeper will determine where the call should be routed (if possible) and send that information back to our Boston voice gateway. You should also specify the tech-prefix digits that you plan to use on your dial peers. The remainder of the dial-peer configuration statements should look familiar to you by now. Here is an example of how to configure a dial peer on our Boston voice gateway for the Miami and LA extensions: Boston#configure terminal Boston(config)#dial-peer voice 1000 voip Boston(config-dial-peer)#destination-pattern .... Boston(config-dial-peer)#tech-prefix 1# Boston(config-dial-peer)#tech-prefix 99# Boston(config-dial-peer)#session target ras Boston(config-dial-peer)#end Boston#
c10.indd 410
9/21/11 11:26:31 AM
Configuring Call Admission Control on H.323 Gatekeepers
411
Notice that our VoIP dial peer 1000 has a four-digit wildcard. This is a catch-all for our voice network that will forward any four-digit extensions to the gatekeeper. Our local gatekeeper will know about the locally configured 3XXX and 4XXX extensions but nothing else. If another extension is dialed (such as the LA 5XXX extensions), the caller will be forwarded to Gatekeeper_2 to see if it has any knowledge of the location of the extensions.
Enabling the H.323 Service on a Voice Gateway Once we have all of our configurations set on the voice gateway, we must enable the H.323 gateway-to-gatekeeper service, by issuing the gateway global configuration command. Note that we also include a no shutdown command while in config-gk configuration mode to bring up the service, as shown here: Boston#configure terminal Boston(config)#gateway Boston(config-gk)#no shutdown
Configuring Call Admission Control on H.323 Gatekeepers One of the true strengths of implementing an H.323 gatekeeper is the ability to manage your H.323 devices and voice gateways by zones. When you have the ability to segment a network into distinct zones, you can easily configure and control the amount of bandwidth used when calls are placed between those zones. Bandwidth control is an important part of a voice network, especially when low-speed WAN connections are being used with a remote site. By limiting the number of calls that can be made at one time, this technique ensures that the calls in progress have sufficient bandwidth. This section shows how to configure call-admission control to limit bandwidth used. But before we configure bandwidth control, we must fi rst discuss how the gatekeeper keeps track of the bandwidth being used for voice calls at any given time.
Understanding the CAC Bandwidth Control on H.323 Gatekeepers An H.323 gatekeeper can control CAC between itself and the following voice components:
c10.indd 411
H.323-enabled voice gateways
CUCM
CUCM Business Edition
CUCM Express
9/21/11 11:26:32 AM
Chapter 10
412
■
Configuring and Managing CUBE and H.323 Gateways
The policies that are configured on the gatekeeper are static, so it is important to understand how voice call bandwidth is calculated so that the bandwidth settings you implement are ideal for your network. The formula for determining the current amount of voice bandwidth being utilized between H.323 zones couldn’t be simpler. Here is the equation: Zone_Bandwidth = Number_of _Current_Calls × Codec_Payload_Bandwidth × 2 Notice that we multiply the calls and bandwidth by 2. We do so because that part of the equation calculates only the codec bandwidth and nothing else. Because the gatekeeper has no knowledge of the network topology, it simply doubles the codec bandwidth to define a static number that should take care of any overhead. For example, let’s say that we have five concurrent calls in place between zone_A and zone_B. Three of the calls are using the G.711 codec and the other two are using the G.729 codec. You should know that the payload bandwidth for G.711 is 64 Kbps and the payload bandwidth for G.729 is 8 Kbps. Therefore, our H.323 gatekeeper with CAC enabled will calculate the current bandwidth as the following: Zone_Bandwidth = 3 × 64 × 2 = 384 Kbps Zone_Bandwidth = 2 × 8 × 2 = 32 Kbps The gatekeeper will add 384 to 32 to get a total of 416 Kbps current bandwidth between zone_A and zone_B. Note again that the simplicity of this calculation at no time takes into account compression techniques (such as cRTP) or LAN/WAN header size differences. Now that you understand CAC interoperation and zone bandwidth calculations, let’s see how to configure bandwidth limitations between H.323 zones on a gatekeeper.
Configuring CAC Bandwidth Control on H.323 Gatekeepers To configure bandwidth control on an H.323 gatekeeper, you must fi rst enter into config-gk mode and use the bandwidth command followed by one of these keywords: This keyword defi nes the maximum amount of bandwidth permitted for a single H.323 stream on a zone.
session
This keyword defi nes the maximum amount of bandwidth allowed between different zones.
interzone
total This keyword defi nes the total amount of voice bandwidth permitted (both interzone and intrazone) on a zone.
This keyword defi nes the total amount of voice bandwidth permitted between gatekeepers in a multi-gatekeeper environment.
remote
Once you decide whether you want to control bandwidth at the session, interzone, or total level, you can further refi ne bandwidth control based on the following: default bandwidth-amount This keyword sets the default maximum bandwidth for all zones. The default is overridden with more specific bandwidth configurations that use the zone keyword, described next. If no specific bandwidth configurations exist, this default value is used.
c10.indd 412
9/21/11 11:26:32 AM
Configuring Call Admission Control on H.323 Gatekeepers
413
The zone keyword, followed by a previously configured zone name and then a bandwidth amount in Kbps, sets the maximum amount of voice bandwidth for a specific zone.
zone zone-name bandwidth-amount
If you are configuring either the interzone, total, or remote bandwidth control amounts, you can specify a bandwidth (in Kbps) between 1 and 10,000,000. If you are configuring bandwidth control at the session level, the range is 1 to 5,000.
To demonstrate how to configure zone bandwidth control using the bandwidth command, we will use the gatekeeper-controlled network with three zones depicted in Figure 10.8.
F I G U R E 10. 8
An H.323 gatekeeper bandwidth-controlled network
zone_A
zone_B
V
V
IP WAN
V
zone_C
V
Gatekeeper
On our gatekeeper, we want to set the following bandwidth limitations:
Interzone default: four G.711 calls
Interzone for zone_A: six G.711 calls
Total bandwidth for each zone: eight G.711 calls
Gatekeeper#configure terminal Gatekeeper(config)#gatekeeper Gatekeeper(config-gk)#bandwidth interzone zone default 512 Gatekeeper(config-gk)#bandwidth interzone zone zone_A 768 Gatekeeper(config-gk)#bandwidth total default 1024 Gatekeeper(config-gk)#end Gatekeeper#
c10.indd 413
9/21/11 11:26:33 AM
414
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
That should give you a solid understanding of H.323 gatekeepers and how to configure them. Next, we’ll look at how to verify and troubleshoot H.323 gatekeepers in a network.
Gatekeeper Verification and Troubleshooting Commands There are several show and debug commands that will be useful when verifying gatekeeper configuration and for troubleshooting purposes. These commands are to be used on the gatekeeper itself to verify current calls, endpoints, zones, and RAS communications. show gatekeeper status The output of this command shows the status of the gatekeeper service. It is a great way to verify that the gatekeeper is up and operational and which local zones are configured, as shown in this example output: Gatekeeper#show gatekeeper status Gatekeeper State: UP Load Balancing: DISABLED Flow Control: DISABLED Zone Name: Zone1 Zone Name: Zone2 Accounting: DISABLED Endpoint Throttling: DISABLED Security: DISABLED Maximum Remote Bandwidth: unlimited Current Remote Bandwidth: 0 kbps Current Remote Bandwidth (w/ Alt GKs): 0 kbps
From the output you can see that the gatekeeper’s state is UP and we have two zones (Zone1 and Zone2) that are configured locally. This command shows a real-time snapshot of all the current calls on the voice network that utilize the local gatekeeper. Here’s an example of its output:
show gatekeeper calls
Gatekeeper#show gatekeeper calls Total number of active calls = 1. GATEKEEPER CALL INFO ==================== LocalCallID Age(secs) BW 9-34668 124 16(Kbps) Endpt(s): Alias E.164Addr src EP: [email protected] 3001
c10.indd 414
9/21/11 11:26:33 AM
Gatekeeper Verification and Troubleshooting Commands
CallSignalAddr 10.1.1.100 Endpt(s): Alias dst EP: voice2 CallSignalAddr 10.2.1.101
Port RASSignalAddr 1720 10.1.1.100 E.164Addr 4001 Port RASSignalAddr 1720 10.2.1.101
415
Port 55136
Port 51329
In this example, you can see that there is one active call that the gatekeeper is aware of. You can see the source and destination IP addresses, port numbers, and aliases for the endpoints currently communicating. Also, you see that this call is using a bandwidth of 16 Kbps, which means that the codec being used is probably G.729. This is because G.729 uses 8 Kbps of bandwidth, and we need two RTP streams for our outgoing and incoming voice for a single call. show gatekeeper endpoints This command displays all of the currently known H.323 end devices and voice gateways from the local gateway’s perspective. Here is an example of the output from this command: Gatekeeper#show gatekeeper endpoints GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port -------------- ----- -------------- ---10.1.1.2 1720 10.1.1.2 1719 H323-ID: gway1 (static) 10.2.2.2 1720 10.2.2.2 1719 H323-ID: gway2 (static) Total number of active registrations = 2
Zone Name Type Flags -------- -------Zone1 VOIP-GW S Zone2
VOIP-GW
S
You can see that our gatekeeper currently has two endpoints associated with the gatekeeper, and they both are voice gateways (Type: VOIP-GW). You can also verify the IP address of the endpoints and the ports they used to communicate signaling with. debug ras The debug ras command is great for troubleshooting RAS communication problems in real time or simply to understand how the different RAS message types operate for various gatekeeper functions. In the example output, we have enabled RAS debugging on our gatekeeper. A voice gateway is registering with the gatekeeper, and we are watching the RAS messages in the process: Gatekeeper#debug ras RASLib::RASRecvData: successfully rcvd message of length 34 from 10.1.1.2:24999 RASLib::RASRecvData: GRQ rcvd from [10.1.1.2:24999] on sock[5C8D28] RASlib::ras_sendto: msg length 45 sent to 192.168.1.100
c10.indd 415
9/21/11 11:26:33 AM
416
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
RASLib::RASSendGCF: GCF sent to 192.168.1.100 RASLib::RASRecvData: successfully rcvd message of length 76 from 10.1.1.2:24999 RASLib::RASRecvData: RRQ rcvd from [10.1.1.2:24999] on sock [0x5C8D28] RASlib::ras_sendto: msg length 81 sent to 192.168.1.100 RASLib::RASSendRCF: RCF sent to 192.168.1.100
The output shows a Gatekeeper Request (GRQ) by our voice gateway. The gatekeeper accepts the request and sends back a Gatekeeper Confi rm (GCF). Next, the voice gateway sends a Registration Request (RRQ), and the gatekeeper registers the voice gateway and sends back an acknowledgement in the form of a Registration Confi rm (RCF).
Introducing the Cisco Unified Border Element Don’t be concerned about the name Cisco Unified Border Element (CUBE), because it is simply a Cisco marketing term for a voice gateway that uses only IP-based connections instead of traditional PSTN analog and digital lines. It used to be that the CUBE was called an IPto-IP gateway, and that is still a good way to describe the duties of a CUBE. But you should know that a CUBE is commonly deployed at the border or edge of the network and is used to connect either to other networks managed by the organization or to an Internet Telephony Service Provider (ITSP). There are some instances, however, where a CUBE is deployed within a large enterprise voice environment that finds a need to translate between legacy H.323 equipment and newer hardware that may only operate with SIP signaling. A CUBE is also deployed internally to provide CAC support between CUCMs in a clustered environment. The CUBE is responsible for terminating and establishing call legs to external VoIP networks. The voice signaling protocols must be terminated and reestablished at the CUBE. Media sessions, however, can be configured to terminate at the CUBE or to flow around the CUBE. As we know, voice networks can run on various voice signaling protocols. Fortunately, the CUBE can interconnect VoIP networks using the following voice signaling protocol scenarios:
SIP-to-SIP
H.323-to-H.323
SIP-to-H.323
H.323-to-SIP
This is different from traditional voice gateways, which typically take an IP call on the internal network and translate it for transport on a PSTN circuit such as a T1 PRI. VoIP dial peers would be used for internal call routing and POTS dial peers used for external call routing. But with the CUBE, both internal and external call routing is performed using physical VoIP dial peers and logical call legs, as shown in Figure 10.9.
c10.indd 416
9/21/11 11:26:34 AM
Introducing the Cisco Unified Border Element
F I G U R E 10. 9
417
CUBE VoIP-to-VoIP dial peers VoIP call leg/ dial peer
VoIP call leg/ dial peer
IP voice network 1
IP voice network 2 CUBE
CUBE Features As noted earlier, a CUBE and a voice gateway are very similar. They operate on the same Cisco router hardware, and many functions are the same. The primary difference is that a CUBE runs a specialized version of IOS software to achieve the protocol internetworking function as well as some of the other more commonly implemented features. Here’s a summary of the primary CUBE gateway services: Protocol Internetworking This is the ability to terminate and reinitiate IP voice sessions between devices that run H.323, SIP, or H.323-to-SIP. Call Admission Control A CUBE provides dynamic CAC either statically or dynamically in the form of the Resource Reservation Protocol (RSVP). Secure Deployment A CUBE can be deployed on the DMZ arm of a fi rewall to provide voice/video services to external (and therefore untrusted) networks. IP Address Hiding Because the CUBE can terminate and reinitiate VoIP sessions, it can be used to either replace or hide the true IP address of endpoint devices. This can add an additional layer of security if needed. Codec Negotiation Because a CUBE sits on the border of a network, it is an ideal device to provide codec negotiation between signaling protocols. You can configure a CUBE to take an interest in codec negotiation, meaning that the two endpoint devices and the CUBE must all agree on the codec, or the CUBE can be set to transparent mode where the codec negotiation between endpoints is ignored. Next, we’ll go through the CUBE essentials and configure a CUBE device to bridge two voice networks together.
CUBE Media Flow Options When calls that are destined for external voice networks pass through a CUBE, the internal voice signaling protocol is terminated and reestablished. This type of behavior is known as a proxy. While the voice signaling protocol must be terminated, the voice/video media streams may or may not be proxied as well. These two approaches, known as media flow-through and media flow-around, are detailed next.
c10.indd 417
9/21/11 11:26:34 AM
418
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Media Flow-Through In media flow-through, voice/video streams come into and are proxied by the CUBE. Because the connection is proxied, the CUBE will replace the source IP address of the actual device with its own IP address. While this is done primarily for routing purposes, it also provides the following two benefits:
IP address hiding for added security
Prevention of duplicate network address spaces between separate networks
Media flow-through is the default transport method on the CUBE and is the only option when terminating two different signaling protocols such as SIP-to-H.323. Figure 10.10 shows an example of using media flow-through between two different VoIP protocols. F I G U R E 1 0 .1 0
Media flow-through CUBE
H. 2 H. 25/ 24 5
5/ 22 H. 245 H.
RT P
P RT
V
IP WAN
V
While the added benefits of IP address hiding and duplicate address protection are useful, the flow-through method also has drawbacks:
Increased CPU and bandwidth load on the CUBE and its connected network
The possibility of suboptimal paths that can introduce unnecessary latency for calls.
Because these two drawbacks might become an issue on some networks, Cisco has a second option, called media flow-around, that fi xes these problems.
Media Flow-Around Media flow-around does not act as a proxy for voice/video transmissions such as RTP. Instead, the media streams flow freely between the two networks and fi nd their own path to the destination. This solves the CUBE load and suboptimal-path problems inherent in the media flow-through method but at the cost of giving up IP address hiding and duplicate IP network protection. Figure 10.11 shows an example of using media flow-around between two different VoIP networks.
c10.indd 418
9/21/11 11:26:35 AM
Introducing the Cisco Unified Border Element
F I G U R E 1 0 .11
419
Media flow-around CUBE
H. 2 H. 25/ 24 5
5/ 22 H. 245 H.
IP WAN
V
V
RTP
It is important to keep in mind that you must verify that the two networks you are connecting with your CUBE using the media flow-around method do not have overlapping IP address space. If that is the case, you’ll need to revert to the default media flow-through method.
CUBE Signaling Protocol Interoperation Now that we’ve determined how we can manipulate the flow of media streams, we must next look at the voice signaling protocols that can be implemented on a CUBE to provide interoperating functions. Specifically, the CUBE provides interoperation using either SIP or H.323. In Chapter 7 you learned that H.323 can be configured with either fast- or slowstart initiation and SIP can be configured with early or delayed offer. With a CUBE, these initiation methods may or may not be available, depending on the signaling types being used. The following methods are supported according to Table 10.2. TA B L E 1 0 . 2
CUBE signaling interoperation
SIP-to-SIP
SIP early
SIP delayed
H.323 fast
H.323 slow
SIP early
SIP delayed
SIP early SIP delayed H.323-to-H.323 H.323 fast H.323 slow H.323-to-SIP H.323 fast H.323 slow
c10.indd 419
9/21/11 11:26:35 AM
420
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
CUBE RSVP-CAC Earlier in this chapter, you learned how to configure CAC on H.323 gatekeepers. While this static method of bandwidth control does work, it’s not very flexible. Resource Reservation Protocol (RSVP)–based CAC, on the other hand, can be configured between two CUBE routers to provide a much more intelligent method of bandwidth control between two Cisco Unified Communications (CUCM) systems or voice gateways. RSVP is a transport-layer protocol that is designed to reserve bandwidth resources dynamically across an IP network. RSVP-CAC is initiated by the calling-side network. As soon as the call-setup message is received by the local CUBE, the path and reservation messages are sent to the remote CUBE. It determines whether there is enough bandwidth and either accepts or denies the RSVP request. As soon as an RSVP confi rm message is returned to the local CUBE, the call is considered to be admitted, and the H.225 call-setup process continues.
When running RSVP-CAC on your network, you must make sure that your CUBE routers are configured for media flow-through, because media flowaround is not supported.
Figure 10.12 shows the signaling steps and responsibilities with two H.323 voice gateways and two RSVP-CAC CUBE routers sitting in between.
F I G U R E 1 0 .1 2
RSVP-CAC signaling
Called party phone
Called party phone 1. H.225 call setup V
Gateway1
V
CUBE 1
CUBE 2
Gateway2
2. RSVP request 3. RSVP confirm 4. H.225 call setup
c10.indd 420
5. H.225 call setup
9/21/11 11:26:36 AM
Introducing the Cisco Unified Border Element
421
CUBE Call Flow Differences Call signaling with a CUBE depends on not only the voice-signaling type used but also the type of hardware that is connected. In the following sections we will focus on two CUBE network scenarios.
Communication with a SIP ITSP Our fi rst example is interconnecting our CUCM Express, running the default H.323 protocol, to a SIP ITSP voice gateway through a CUBE. Figure 10.13 shows the call signaling flow from end to end.
F I G U R E 1 0 .1 3
CUBE network call flow to a SIP ITSP
ITSP
M
Internet
CUCM Express SCCP
V
CUBE
SIP
H.225/H.245
PSTN
Don’t forget that if the SIP ITSP uses only the early-offer method, your H.323 session must be configured for fast start. And if SIP late-offer is configured between the SIP ITSP and CUBE, then H.323 slow-start initiation must be used. Also remember that media flow-through must be used because we are connecting calls that use different signaling protocols.
Communication through a Gatekeeper to a SIP ITSP In our next example, you see CUCM Express and an H.323 gatekeeper on one managed IP network. Then, on the opposite network, we have a remote gatekeeper and a CUBE, as depicted in Figure 10.14.
c10.indd 421
9/21/11 11:26:37 AM
422
Chapter 10
F I G U R E 1 0 .1 4
■
Configuring and Managing CUBE and H.323 Gateways
CUBE network call flow through a gatekeeper
Remote-GK
Local-GK Remote zone RAS V
ITSP V
Admission RAS
M
Internet
CUCM Express SCCP
V
CUBE
SIP
H.225/H.245
PSTN
You can see that CUCM Express and the remote SIP ITSP network both utilize an H.323 gatekeeper to provide telephone-number-to-IP-address lookups. Remote zone RAS signaling can be configured between the gatekeepers to exchange call-routing information. Once RAS is completed and the call is permitted, the CUCME works directly with the CUBE, as does the CUBE with the SIP voice gateway. Next you will learn how to configure a CUBE in various network topologies.
Configuring the CUBE In this section, you’ll see how to configure a CUBE to operate in VoIP networks that run SIP, H.323, or both.
Configuring Protocol Interoperation To enable VoIP-to-VoIP interoperation, you need to first get into conf-voi-serv configuration mode by issuing the voice service voip command. Once there, you use the allowconnections command, followed by the protocol interoperation you want to use on your CUBE. This is accomplished by first choosing the “from” protocol, which is the protocol used by the originating endpoint. Then you issue the to command followed by the protocol used by the terminating endpoint. Here are the possible protocol interoperation options: allow-connections sip to sip allow-connections h323 to h323 allow-connections sip to h323 allow-connections h323 to sip
c10.indd 422
9/21/11 11:26:37 AM
Configuring the CUBE
423
Always remember when working to interconnect SIP and H.323 networks that the allow-connections command is unidirectional. If you want your CUBE to work bidirectionally (that is, able to make outbound calls and receive inbound calls), you must configure two commands to allow SIP-to-H.323 and H.323-to-SIP. Figure 10.15 shows CUBE interoperation between H.323 and SIP networks. F I G U R E 1 0 .1 5
An H.323-to-SIP network
H.323 network
SIP ntetwork CUBE Bidirectional communication
We want either network to be able to initiate calls that terminate on the other side, so we must configure two allow-connections statements as shown here: CUBE#configure terminal CUBE(config)#voice service voip CUBE(conf-voi-serv)#allow-connections h323 to sip CUBE(conf-voi-serv)#allow-connections sip to h323 CUBE(conf-voi-serv)#end CUBE#
Configuring Media Flow-Around You can modify the default media flow-through behavior, which forces all media flows to be proxied at the CUBE. As long as you are running the same gateway protocol (either SIP-to-SIP or H.323-to-H.323) and are not using RSVP-CAC, you can modify the media flow behavior to flow-around. Let’s say you have a SIP-to-SIP network interconnected with a CUBE. You want to modify the media flow to use the flow-around method. There are three ways of configuring this:
At a global level
At a voice-class level
At a dial peer level In this example, we will configure media flow-around on VoIP dial peer 111:
CUBE#configure terminal CUBE(config)#dial-peer voice 111 voip CUBE(config-dial-peer)#media flow-around CUBE(config-dial-peer)#end CUBE#
c10.indd 423
9/21/11 11:26:38 AM
Chapter 10
424
■
Configuring and Managing CUBE and H.323 Gateways
Configuring Codec Transparency Earlier in the chapter, we discussed how the CUBE can take an interest and help negotiate which codec is used between endpoints. This is the default behavior. If you don’t want the CUBE to interfere with codec negotiation, the default behavior can be changed using the codec transparent command; you don’t need to specify particular codecs that can be used between connected endpoints. Here is an example of how to configure codec transparency on VoIP dial peer 111: CUBE#configure terminal CUBE(config)#dial-peer voice 111 voip CUBE(config-dial-peer)#codec transparent CUBE(config-dial-peer)#end CUBE#
Now the CUBE will stay out of the codec negotiation process. However, it should be mentioned that even though codec transparency is enabled, the CUBE still looks to see what codec is being attempted by the endpoints. If the codec is not known to the CUBE, the call cannot be completed.
Configuring H.323 Fast-to-Slow-Start Signaling When configuring an H.323-to-H.323 network, you need to decide how to handle the H.323 initiation process. This behavior can be modified while in conf-serv-h323 configuration mode by using the call start command, followed by one of these keywords: This command forces all H.323 dial peers to use H.323v2 fast-start initiation. This is the default CUBE setting for H.323.
fast slow
This command forces all H.323 dial peers to use H.323v1 slow-start initiation.
This command is used where there is either a fast-start-to-slow-start or slow-start-to-fast-start interoperation. Note that this option disables slow-to-slow or fast-to-fast call-matching setups. As an example of how to configure this, Figure 10.16 illustrates a network that requires an H.323 fast-to-slow-start setup.
interwork
F I G U R E 1 0 .1 6
H.323 fast-to-slow start Fast-start
Slow-start
H.323 network
H.323 network CUBE
Focusing on CUBE1, we’ll fi rst configure H.323-to-H.323 protocol interoperation and then enable fast-to-slow-start signaling, as shown here:
c10.indd 424
9/21/11 11:26:38 AM
CUBE Verification and Troubleshooting Commands
425
CUBE1#configure terminal CUBE1(config)#voice service voip CUBE1(config-voi-serv)#allow-connections h323 to h323 CUBE1(config-voi-serv)#exit CUBE1(config)#h323 CUBE1(conf-serv-h323)#call start interwork CUBE1(conf-serv-h323)#end CUBE1#
Once this is completed, you simply need to configure the proper VoIP dial peers for routing calls and you’re all set.
Configuring SIP Delayed-to-Early-Offer Signaling Like H.323, SIP can be modified to use either early- or delayed-offer signaling when operating a SIP-to-SIP network. You can configure a delayed-to-early-offer SIP network either globally for all SIP dial peers while in config-voi-serv mode or individually while in config-dial-peer mode. In our example, we will fi rst allow SIP-to-SIP interoperation and then enable SIP delayed-offer-to-early-offer by using the command early-offer forced, as shown in this example: CUBE1#configure terminal CUBE1(config)#voice service voip CUBE1(config-voi-serv)#allow-connections sip to sip CUBE1(config-voi-serv)#early-offer forced CUBE1(config-voi-serv)#exit
Now all SIP dial peers that are configured on this CUBE will participate in early- to late-offer early-media negotiations.
CUBE Verification and Troubleshooting Commands To end this chapter we’ll cover some of the show and debug commands that are especially useful when verifying and troubleshooting a CUBE-supported voice network. To display the number of currently active call legs and signaling type that are traversing a CUBE, you can use the show call active voice brief command. A portion of the output of this command is shown here:
show call active voice brief
CUBE#show call active voice brief -output cut Telephony call-legs: 0
c10.indd 425
9/21/11 11:26:39 AM
426
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
SIP call-legs: 1 H323 call-legs: 1 Call agent controlled call-legs: 0 SCCP call-legs: 0 Multicast call-legs: 0 Total call-legs: 2 -output cut CUBE#
In the output of this example, we have one call with two total call legs, and the CUCM is providing voice network interoperation between a SIP and an H.323 network. show call history voice brief You can also take a look at the past history of call leg connections using the show call history voice command. The output is nearly identical to that of the show active call brief command, but this command takes the accumulated calls in the CUBE router’s memory. The history can be cleared out by issuing the clear call history voice command. show voip rtp connections If you are running your CUBE as a media flow-through device, RTP sessions will be terminated and proxied. You can view the RTP sessions by issuing the show voip rtp connections command, as shown here: CUBE#show voip rtp connections Load for five secs: 1%/0%; one minute: 1%; five minutes: 1% Time source is NTP, 19:18:43.542 CST Mon May 19 2011 VoIP RTP active connections : No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP 1 3001 4001 18546 17402 10.10.10.100 10.10.3.50 2 4001 3001 17778 19596 10.10.10.100 10.10.4.50 Found 2 active RTP connections CUBE#
The output shows a single voice call with a transmitting and receiving RTP stream. Notice how the LocalIP address for both RTP sessions is the same. The 10.10.10.100 IP address is the address of the CUBE because it is acting as a proxy for the RTP stream. This allows the CUBE to hide the actual endpoint IP addresses. debug voip ipipgw The debug voip ipipgw command is useful to see the CUBE pro-
cesses it is responsible for when connecting separate voice networks together. You’ll fi nd information such as H.323 or SIP initiation processes, RTP and RTCP port information, and media flow settings. In this example, you see output showing that the H.323 incoming call leg is set to use the flow-through media stream method:
c10.indd 426
9/21/11 11:26:39 AM
Exam Essentials
427
CUBE#debug voip ipipgw -output cut May 19 20:27:53.430 CST: cch323_media_flow_mode: IPIPGW(3001):Flow Mode=1 May 19 20:27:53.430 CST: cch323_set_h245_state_mc_mode_outgoing:call_spi_ mode = 1
You can see that the call originated from extension 3001. If the CUBE device is set for the flow-through method, the debug output will show Flow Mode=1.
Summary This chapter introduced the H.323 gatekeeper and CUBE devices. You learned how these two devices interact with voice end devices and voice gateways and how to configure each of these devices and verify their operational status. In the next two chapters, we’ll take what you’ve learned from the entire book and add one fi nal layer of serviceability to IP voice networks in the form of Quality of Service (QoS). It is the last step that smoothens out the rough spots in terms of the quality of voice calls on a packet-switched network.
Exam Essentials Know the mandatory and optional H.323 gatekeeper features. Mandatory features include zone management, address translation, CAC, and bandwidth control. Optional features include call authorization, call management, and bandwidth management. Understand the purpose of RAS messages. RAS messages are used between H.323 endpoints and the gatekeeper to register to the gateway, perform call lookups and admissions, and provide information about where calls to remote zones should be routed. Understand how endpoints discover the H.323 gatekeeper. Endpoints can either be statically configured and sent as a unicast GRQ RAS message, or if not statically configured, that same GRQ is sent as a multicast message. Understand the purpose of RAS location messages. These messages are used to request information from one gatekeeper to another in a multi-gatekeeper environment. Know where local zones reside in an H.323 environment. Local zones are the zones configured between a voice gateway and their local gatekeeper. Know where remote zones reside in an H.323 environment. configured on a gatekeeper other than the local gatekeeper.
Remote zones are the zones
Know the difference between zone prefixes and technology prefixes. Zone prefi xes are E.164 numbers used to represent an H.323 zone that includes endpoints and voice
c10.indd 427
9/21/11 11:26:39 AM
428
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
gateways. Technology prefi xes are special E.164 numbers that, if dialed, direct the calling device to a location where special H.323 functions reside. Know how to configure a voice gateway dial peer to use a gatekeeper. To direct a VoIP dial peer to use a gatekeeper, you use the session target ras command while in configdial-peer mode. Understand how an H.323 gatekeeper calculates zone bandwidth for CAC services. The equation is Zone_Bandwidth = Number_of _Current_Calls × Codec_Payload_Bandwidth × 2. Understand the primary purpose of a CUBE. gateway connections.
The CUBE is primarily used for IP-to-IP
Know the four possible CUBE voice gateway signaling scenarios. H.323-to-H.323, SIP-to-H.323, and H.323-to-SIP.
They are: SIP-to-SIP,
Understand how a CUBE can provide address hiding. The CUBE offers address hiding by acting as a proxy and terminating and reinitiating signaling and media flows. Know the pros and cons of media flow-through. Media flow-through offers IP address hiding and prevention of duplicate network address schemes. The downside is that all media flows must terminate at the CUBE and therefore increase CPU and bandwidth load. Know the pros and cons of media flow-around. Media flow-around allows the media flow to move around the network as opposed to forcing it through the CUBE. The downside is that it does not provide IP address hiding or prevention of duplicate IP network schemes. Understand the concept of RSVP. RSVP is a transport-layer protocol that is designed to dynamically reserve bandwidth resources across an IP network. Know which command is useful when you want to see CUBE setup messages in real time. The debug voip ipipgw command is ideal when troubleshooting CUBE connection problems.
Written Lab 10.1
c10.indd 428
1.
What config-gk configuration mode command assigns zoneA in domain example.com as a local zone?
2.
What config-gk configuration mode command assigns zoneEXT in domain example. com as a remote zone controlled by a gatekeeper with the IP address of 192.168.9.101?
3.
What config-gk mode command maps zoneA with E.164 numbers that range between 5500000 and 5599999?
4.
What config-if command is used on a voice gateway to identify it as the interface used for interoperation with the H.323 gatekeeper?
5.
When configuring dial peers for voice gateways in a gatekeeper-controlled network, how do you configure the dial peer to fi nd the next-hop IP address from the gatekeeper when in config-dial-peer configuration mode?
6.
What gatekeeper verification command lets an administrator view communication messages between itself and other H.323 components in real time?
9/21/11 11:26:40 AM
Hands-On Labs
429
7.
You are configuring a CUBE for bidirectional communication between SIP and H.323 networks. You have already configured H.323-to-SIP communications. What confvoi-serv command is used to allow SIP-to-H.323 communications?
8.
You are configuring a CUBE VoIP dial peer and don’t want the media flow to be proxied. What config-dial-peer command is used to do this?
9.
You have a CUBE configured for H.323 to SIP functionality. What command is used verify that you have an H.323 and a SIP call leg for a call that is currently going on?
10. You are running your CUBE as a media flow-through proxy. What command can be
used to view active RTP sessions? (The answers to Written Lab 10.1 can be found following the answers to the review questions for this chapter.)
Hands-On Labs To complete the labs in this section, you need two routers to act as voice gateways and one router as a gatekeeper. There is a second gatekeeper (Dub_Gatekeeper_1) and third voice gateway (Dublin_gw1), which act as our remote gatekeeper zone, but we will only configure our local GB_Gatekeeper_1 and two local zone voice gateways in the labs. The labs will follow the logical network design shown in Figure 10.17. F I G U R E 1 0 .17
H.323 Gatekeeper lab diagram Domain: example.com 5555XXX GB_Gatekeeper_1 Default tech prefix: V 1# 10.88.88.1
V
Dub_Gatekeeper_1
10.77.77.1
5553XXX V
S0/0
V
Dublin_gw1
London_gw1 Zone: London
Zone: Dublin
IP WAN 5554XXX V
S0/0
Glasgow_gw1 Zone: Glasgow
c10.indd 429
9/21/11 11:26:40 AM
430
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
These labs build on each other, so it is best to perform them in the order listed: Lab 10.1: Configuring GB_Gatekeeper_1 Lab 10.2: Configuring London_gw1 and Glasgow_gw1
Hands-On Lab 10.1: Configuring GB_Gatekeeper_1 In this lab, we assume that GB_Gatekeeper_1 is preconfigured on the WAN except for the gatekeeper-specific settings. It is our responsibility to configure local zones, remote zones, and zone prefi xes according to Figure 10.17. In addition, the gatekeeper will be used as a default technology prefi x for extension 1#. 1.
Log into GB_Gatekeeper_1 and go into privileged exec mode by typing enable.
2.
Enter into configuration mode by typing configure terminal.
3.
Enter into config-gk configuration mode by typing gatekeeper.
4.
Configure the London zone as a local zone and specify the local IP address as the source IP for RAS messages by typing zone local London example.com 10.88.88.1.
5.
Configure the Glasgow zone as a local zone by typing zone local Glasgow example.com.
6.
Configure the Dublin zone as a remote zone by typing zone remote Dublin example.com 10.77.77.1.
7.
Configure the local zone prefi x for the London zone to be 5553… by typing zone prefix London 5553...
8.
Configure the local zone prefi x for the Glasgow zone to be 5554… by typing zone
9.
Configure the gatekeeper to be the default technology prefi x when users key in extension 1# by typing gw-type-prefix 1# default-technology.
prefix London 5554...
10. Enable gatekeeper services by typing no shutdown. 11. Exit config-gk configuration mode by typing end.
Hands-On Lab 10.2: Configuring London_gw1 and Glasgow_gw1 In this lab, we assume that both the London_gw1 and Glasgow_gw1 gateways are preconfigured on the WAN except for the gatekeeper-specific settings and dial peers. We must configure the voice gateway to communicate with a gatekeeper, configure the VoIP dial peer pointing to the gatekeeper, and set the default technology prefi x we have set up on our gatekeeper.
c10.indd 430
1.
Log into London_gw1 and go into privileged exec mode by typing enable.
2.
Enter into configuration mode by typing configure terminal.
9/21/11 11:26:41 AM
Hands-On Labs
431
3.
Enter into interface serial 0/0 mode by typing interface serial 0/0.
4.
Enable gateway-to-gatekeeper operation on this interface by typing h323-gateway voip interface.
5.
Set the zone name to London by typing h323-gateway voip h323-id London.
6.
Set the gateway to use the 1# default technology prefi x by typing h323-gateway voip tech prefix 1#.
7.
Exit config-if mode by typing exit.
8.
Enable this router as an H.323 gateway by typing gateway.
9.
Configure a VoIP dial peer (dial peer 555) by typing dial-peer voice 555 voip.
10. Configure a destination pattern to match all seven-digit numbers beginning with 555
by typing destination pattern 555... 11. Configure the dial peer to use the default technology prefi x that our gatekeeper is con-
figured for by typing tech-prefix 1#. 12. Configure the dial peer to look to the gatekeeper for next-hop call-routing information
by typing session target ras. 13. Exit config-dial-peer configuration mode by typing end. 14. Repeat steps 1 to 13 on the Glasgow_gw1 voice gateway to complete the end-to-end
setup between the two networks.
c10.indd 431
9/21/11 11:26:41 AM
Chapter 10
432
■
Configuring and Managing CUBE and H.323 Gateways
Review Questions 1.
Which of the following is not a mandatory H.323 gatekeeper feature? A. Zone management
2.
B.
Address translation
C.
Call authorization
D.
Admission control
What does H.323 address translation accomplish? A. Translates IP addresses into physical interface ports
3.
B.
Translates IP addresses into physical MAC addresses
C.
Translates E.164 numbers into interface ports
D.
Translates E.164 numbers into MAC addresses
E.
Translates E.164 numbers into IP addresses
If a voice gateway sends a RAS gatekeeper discovery message and the gatekeeper determines that the gateway can register, what RAS message type is returned to the voice gateway? A. GRJ B.
4.
GCF
C.
RCF
D.
RRJ
What are the two options that can be used with voice gateways to discover a local H.323 gatekeeper? A. Using a broadcast message
5.
B.
Using a static IP address
C.
Using a multicast message
D.
Using a MAC address message
RAS location messages are sent and received between what two devices? A. A gatekeeper and an MCU
c10.indd 432
B.
A gateway and a gatekeeper
C.
A gatekeeper and any H.323 compatible endpoint
D.
Between two gatekeepers
E.
Between two MCU’s
9/21/11 11:26:42 AM
Review Questions
6.
433
When a gatekeeper determines that there is a resource problem on the H.323 network, what type of message does it send to the calling endpoint to inform it that it must wait before the call setup process can begin? A. RIP
7.
B.
RRJ
C.
BCF
D.
RAI
What IOS command mode must an administrator be in to configure H.323 zones on a gatekeeper? A. config-if
8.
B.
config-voi-serv
C.
config-gk
D.
config-h323-gk
You are reviewing an H.323 gatekeeper configuration and see the following command: zone local zoneA example.com 10.101.13.99
What does the 10.101.13.99 represent? A. The IP address of an endpoint in zoneA that is used as the source IP for RAS messages
9.
B.
The IP address of the local gatekeeper that is used as the source IP for RAS messages
C.
The IP address of a voice gateway in zoneA that is used as the source IP for RAS messages
D.
The IP address of a remote gatekeeper that is used as the source IP for RAS messages
Which of the following is the correct IOS configuration mode and syntax used to configure a remote zone? A. Gatekeeper(config-gk)#remote zone zoneA example.com 192.168.1.1 B.
Gatekeeper(conf-voi-serv)#remote zone zoneA example.com 192.168.1.1
C.
Gatekeeper(config-gk)#zone remote zoneA example.com 192.168.1.1
D.
Gatekeeper(conf-voi-serv)#zone remote zoneA example.com 192.168.1.1
10. You are reviewing an H.323 gatekeeper configuration and see the following commands: zone prefix Denver 50... zone prefix Seattle 51...
Based on this information, which of the following statements is true? A. Denver and Seattle are remote zones.
c10.indd 433
B.
Denver and Seattle are local zones.
C.
The Denver and Seattle zones have their own H.323 gatekeeper.
D.
Voice gateways within the Denver and Seattle zones do not use VoIP dial peers.
9/21/11 11:26:42 AM
Chapter 10
434
■
Configuring and Managing CUBE and H.323 Gateways
11. You are configuring an H.323 gatekeeper that has two paths to the Dallas zone. Which of the following is the correct command syntax used to ensure there is a backup path to the secondary voice gateway in the event that the primary path fails? A. zone prefix Dallas 4.. gw-priority 4 Dallas_gw1 zone prefix Dallas 5.. gw-priority 5 Dallas_gw2 B.
zone prefix Dallas 4.. gw-priority 4 Dallas_gw1 zone prefix Dallas 4.. gw-priority 4 Dallas_gw2
C.
zone prefix Dallas 4.. gw-priority 4 Dallas_gw1 zone prefix Dallas2 4.. gw-priority 5 Dallas_gw2
D.
zone prefix Dallas 4.. gw-priority 4 Dallas_gw1 zone prefix Dallas 4.. gw-priority 5 Dallas_gw2
12. A user dials a unique E.164 prefix extension to connect to a gatekeeper-controlled device that provides unique services. What is this called? A. Technology gateway B.
Prefix service
C.
Call admission control (CAC)
D.
Technology prefix
13. Which of the following commands and configuration modes will enable the H.323 gateway-to-gatekeeper service on a voice gateway? A. Gateway(config-gw)#gatekeeper B.
Gateway(config)#gatekeeper
C.
Gateway(config-gw)#gateway
D.
Gateway(config)#gateway
14. Your network has 5 G.711 and 3 G.729 calls operating on a gatekeeper controlled network between two zones. According to the gatekeeper, how much bandwidth is being utilized? A. 688 Kbps B.
640 Kbps
C.
384 Kbps
D.
344 Kbps
15. You are reviewing an H.323 gatekeeper configuration and come across the following command: bandwidth interzone zone default 1024
Which of the following statements is correct? A. This command is used to create static CAC.
c10.indd 434
B.
This command is used to create static RSVP-CAC.
C.
This command is used to create dynamic CAC.
D.
This command is used to create dynamic RSVP-CAC.
9/21/11 11:26:43 AM
Review Questions
435
16. What is the primary difference between a CUBE configured for media flow-through as opposed to media flow-around? A. Media flow-through does not proxy media streams on the CUBE. B.
Media flow-through proxies media streams on the CUBE.
C.
Media flow-through allows the RTP sessions to find the optimal path from end-to-end on an IP network.
D.
Media flow-through does not prevent overlapping IP address space.
17. A CUBE is configured for RSVP-CAC. When are path reservation messages exchanged? A. Before the call setup message is received B.
After the call setup message is received
C.
Before the H.323 endpoint capabilities message is received
D.
After the H.323 endpoint capabilities message is received
18. A CUBE is providing interoperation between a SIP and an H.323 network. Which of the following call-initiation types can a CUBE be configured for? (Choose all that apply.) A. Early offer to fast start B.
Early offer to slow start
C.
Delayed offer to fast start
D.
Delayed offer to slow start
19. Which of the following configuration examples correctly configures a CUBE for bidirectional SIP-to-H.323 interoperation? A. CUBE(config)#voice service voip CUBE(config-voice-serv)#allow-connections h323 to sip B.
CUBE(config)#voice service cube CUBE(conf-voi-serv)#allow-connections h323 to sip CUBE(conf-voi-serv)#allow-connections sip to h323
C.
CUBE(config)#voice service voip CUBE(conf-voi-serv)#allow-connections h323 to sip CUBE(conf-voi-serv)#allow-connections sip to h323
D.
CUBE(config)#voice service cube CUBE(conf-voi-serv)#allow-connections sip to h323
20. You enable CUBE debugging by issuing the debug voip ipipgw command and see the following: May 19 20:27:53.430 CST: cch323_media_flow_mode: IPIPGW(3001):Flow Mode=1 May 19 20:27:53.430 CST: cch323_set_h245_state_mc_mode_outgoing: call_spi_mode = 1
What does Flow Mode=1 mean? A. The CUBE currently has one H.323 call leg.
c10.indd 435
B.
The CUBE is configured for media flow-through.
C.
The CUBE is configured for media flow-around.
D.
The CUBE currently has one SIP call leg.
9/21/11 11:26:43 AM
436
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Answers to Review Questions 1.
C. Call authorization is an H.323 feature that can be optionally configured, while the other three features are mandatory when configuring H.323 gatekeepers.
2.
E. An H.323 gatekeeper maintains a table of E.164 numbers to next-hop IP addresses of the local zones it controls.
3.
C. A gatekeeper RAS registration RCF message is returned to the voice gateway when the gatekeeper decides it can register to it.
4.
B, C. H.323 voice gateways can discover their local gatekeeper by either statically configuring the IP address of the gatekeeper and sending a unicast RAS or by sending a multicast message.
5.
D. RAS location messages are exchanged between two gatekeepers to send query messages about remote zones.
6.
A. The Resource in Progress (RIP) RAS message is used by the gatekeeper to inform the H.323 endpoint that a resource constraint has been discovered and to allow for more time to begin the call setup process.
7.
C. H.323 zones are configured while in config-gk mode on a gatekeeper.
8.
B. 10.101.13.99 is the IP address of the gatekeeper you are currently configuring. It signifies that this is the IP that will be used to source RAS messages. This command can only be entered on a single zone-configuration command, but it is then used for all configured zones.
9.
C. Remote zones are configured while in config-gk configuration mode, and the proper syntax is zone remote zoneA example.com 192.168.1.1.
10. B. Given the configuration information in the question, the gatekeeper manages the Denver and Seattle zones locally. 11. D. When you are configuring zone redundancy using priority commands, the E.164 numbers and zone names must match. The priority numbers are used to determine the primary path and therefore one should be more preferred (a higher number). 12. D. Technology prefi x numbers are special E.164 prefi xes that users can dial to access special gatekeeper-controlled resources. 13. D. The gateway-to-gatekeeper interoperation must be enabled on a voice gateway by issuing the gateway command while in global configuration mode. 14. A. The equation the gatekeeper uses is Zone_Bandwidth = Number_of _Current_Calls × Codec_Payload_Bandwidth × 2. 15. A. CAC on gatekeepers is static in nature. This command is used to limit the maximum bandwidth for H.323 traffic to 1024 Kbps. 16. B. Media flow-through acts as a proxy for media streams such as RTP for voice transport. 17. B. RSVP-CAC messages are sent as soon as the call setup message is received by the local CUBE.
c10.indd 436
9/21/11 11:26:44 AM
Answers to Review Questions
437
18. A, D. A CUBE can be configured to interoperate between a SIP early offer to H.323 faststart initiation process or a SIP delayed offer to H.323 slow-start process only. 19. C. To access conf-voi-serv configuration mode, you must use the voice service voip command. Then two allow-connections commands must be entered for bidirectional communication between the SIP and H.323 networks. 20. B. The Flow Mode=1 output from the debug voip ipipgw command means that the voice gateway is processing H.323 media that are configured for the flow-through method.
c10.indd 437
9/21/11 11:26:44 AM
438
Chapter 10
■
Configuring and Managing CUBE and H.323 Gateways
Answers to Written Lab 10.1 1.
zone local zoneA example.com
2.
zone remote zoneEXT example.com 192.168.9.101
3.
zone prefix zone1 55.....
4.
h323-gateway voip interface
5.
session target ras
6.
debug ras
7.
allow-connections sip to h323
8.
media flow-around
9.
show call active voice brief
10. show voip rtp connections
c10.indd 438
9/21/11 11:26:44 AM
Chapter
11
Introduction to Quality of Service THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe the need to implement QoS for voice and video. ■
Describe the causes of voice and video quality issues.
■
Describe how to resolve voice and video quality issues.
■
Describe QoS requirements for voice and video traffic.
Describe and configure the DiffServ QoS model. ■
Describe the DiffServ QoS model.
■
Describe marking based on CoS, DSCP, and IP Precedence.
■
Describe trust boundaries.
■
Describe the operations of the QoS classifications and marking mechanisms.
■
■
Describe Low Latency Queuing. Describe the operations of the QoS WAN link efficiency mechanisms.
c11.indd 439
9/21/11 11:27:09 AM
As soon as IP networks were designed and implemented with sufficient redundancy mechanisms in place to rival traditional voice systems in stability, it was only a matter of time before voice made the transition to IP. During this early transition period, early adopters began noticing that for voice traffic to function as well on a packet network as it did on traditional circuit-switched networks, the transport method used by IP networks needed some additional policies and compression techniques in place. Thus began the rise of Quality of Service (QoS), the collective term for queuing techniques devised to help eliminate bottlenecked areas on a network. This chapter covers the “who, what, when, where, and why” of QoS on IP networks. Newly added voice traffic began creating bottlenecks, and these bottlenecks led to the need to create a way to prioritize and queue these packets that are highly sensitive to drops and latency. Specifically, you will learn what it is that causes IP networks to falter when running real-time streaming voice and video and how QoS and compression techniques can be used to eliminate each of those problems. In Chapter 12, “Configuring Quality of Service,” we’ll move on to the “how” of QoS on IP networks as we explore configuring various QoS scenarios.
Problems with Voice/Video on IP Networks To understand what QoS does, you need to understand the problems it was introduced to solve. Before the convergence of time-sensitive transport such as voice and video, IP networks dealt with applications and data that had the following characteristics:
Large packet payloads
Bursty transport flow
Time-flexible transmissions
No one application or data flow with higher priority than another on shared links
The ability to recover in the event of packet drops
As you can see, most data traffic before voice and video were added was inherently robust. It didn’t really matter how long it took for data to get from point A to point B, as long as it was transported without errors. Thus you see that most data applications
c11.indd 440
9/21/11 11:27:10 AM
Mitigating IP Network Voice Issues
441
were built using TCP, which has built-in CRC checks and retransmission of lost or damaged packets. Today’s modern IP networks that carry voice and video have very different transport needs outside of the standard data flows just described. Now a network must also provide mechanisms to carry traffic with these characteristics:
Small packet payloads
Continuous transport flow
Time-sensitive payloads
A way to defi ne some data flows as higher priority than others on shared links
High sensitivity to packet drops
Because of these new requirements, network administrators must focus on four primary modifications to ensure that voice/video traffic does not suffer on an IP network. We’ll look at those factors in the next section.
Mitigating IP Network Voice Issues Now that converged voice/video and data networks are here to stay, network designers and administrators must educate themselves about addressing IP network issues so that timesensitive data can properly be transported in a reliable and efficient manner. There are four primary issues to address:
Providing sufficient bandwidth for a converged network
Reducing end-to-end delay
Reducing jitter
Eliminating packet loss
Let’s break down each of these issues to see how they can be resolved on a network. You will then learn how to implement QoS configurations to mitigate the issues in Chapter 12.
Providing Sufficient Bandwidth for a Newly Converged Network When planning for a converged voice/video and data network over IP, you must carefully consider how to allow for the increase in bandwidth usage. There are several considerations when determining how much bandwidth will increase when adding IP voice to the mix. These include things such as:
c11.indd 441
Number of users
Internal versus external calling
Remote site bottlenecks
9/21/11 11:27:10 AM
Chapter 11
442
■
Introduction to Quality of Service
Codec choice
Required voice features and services
Future growth estimates
Keep in mind that there are other reasons for determining how much bandwidth is required, but these are the primary ones to focus on. See Chapter 5, “VoIP Design Options,” if you need to revisit bandwidth calculations.
Reduce End-to-End Delay Chapter 5 discussed fi xed and variable delay as aspects of the quality of voice calls on IP networks. It should be stated again, however, that while a certain amount of delay is necessary and acceptable, it is the responsibility of the network administrator to limit variable delay whenever possible. You can use three basic techniques to reduce variable delay: eliminate bottlenecks, add compression, and prioritize time-sensitive traffic. Table 11.1 describes the advantages of each. Again, you’ll learn how to implement these techniques in Chapter 12. TA B L E 11 .1
Variable-delay reduction techniques
Technique
Description
Eliminate bottlenecks
Bottlenecks not only drop packets, but they can also force packets into queues until the network router/switch can process them. These queuing delays can substantially add to the delay of a packet.
Add compression
Compression reduces the packet size and therefore reduces the amount of overall bandwidth consumed on a link.
Prioritize timesensitive traffic
Not all IP packets require low delay times. You can pinpoint voice/ video traffic to give it priority when it enters a queue. By moving time-sensitive traffic to the front of the queue, you can reduce variable delay for the data streams that absolutely require it.
Reduce Jitter Network jitter and variable delay often go hand in hand. While delay attempts to reduce the time it takes for packets to be transported from one end to the other, jitter attempts to stabilize the time in between the receipt of packets at the destination. If you don’t keep jitter within a specified range (30 ms for voice), the audio stream at the destination will end up sounding distorted and garbled. The same techniques used to eliminate variable delay can also be used to reduce jitter.
c11.indd 442
9/21/11 11:27:11 AM
Mitigating IP Network Voice Issues
443
Eliminate Packet Loss When I think about network bandwidth and packet loss, I’m often reminded of a quote by Abraham Lincoln: “You cannot escape the responsibility of tomorrow by evading it today.” I am reminded of that quote because most networks today have more applications utilizing more and more bandwidth. It is a major responsibility of the network administrator to constantly monitor end-to-end link utilization on a network. Even though your network utilization may be fi ne today, you need to have plans in place for the time when you are approaching the point where your network becomes overutilized. When a link becomes overutilized, packet loss often occurs in the form of interface output queue drops (sometimes called tail drops). When an interface becomes overwhelmed with traffic, it begins placing packets into an output queue buffer in the hope that traffic will eventually die down and the network device can catch back up. If the traffic does not die down, however, the queue fi lls up. Those packets that cannot be placed into the already full output queue are dropped. Additional but less-frequent reasons for packet loss due to bottlenecks include these:
Input queue drops
Overruns
Ignored packets
Frame errors including CRC, runts, and giants
The primary areas of concern are at the network bottlenecks, as Chapter 5 briefly described. Network bottlenecks can cause a network interface to become overwhelmed. And when the interface cannot handle any more data, some of it is dropped. Because voice and video streams are highly sensitive to dropped packets, it is important to be able to identify various bottlenecks on a network. Figure 11.1 shows the network location where a bottleneck is most likely to occur between two IP phones. F I G U R E 11 .1
Network bottleneck Possible bottleneck
1000 Mbps
1000 Mbps
IP WAN V
1000 Mbps
c11.indd 443
V
45 Mbps
1000 Mbps
9/21/11 11:27:11 AM
444
Chapter 11
■
Introduction to Quality of Service
By identifying possible bottleneck interfaces before problems occur, administrators can closely monitor the increase in utilization that will occur as network usage grows. When utilization begins reaching capacity, it’s time to consider either implementing compression techniques or increasing bandwidth. Ideally, increasing bandwidth is the way to go in most situations, but compression can be used when upgrades are not possible. Compression techniques include compressing the IP header information and compressing the IP payload. Both of these techniques are described in more detail later in this chapter.
Putting the Pieces Together Now that we’ve identified problems with voice on IP networks and looked at some of the solutions, there are three primary steps that we can take so that voice/video can operate well on a converged network. The first step is to add bandwidth wherever it is needed. This is a simple yet highly effective solution. Unfortunately, it can also be expensive. The other two steps involve careful planning and configuration to accomplish, and these are what the remainder of the book will cover. First, we have Quality of Service, which is used to give time-sensitive traffic priority on the network to limit delay, jitter, and packet loss. Next, we can configure link efficiency and compression techniques to lower our bandwidth utilization footprint. While link efficiency and compression isn’t technically QoS, it is good to combine the two methods because they can help significantly reduce bandwidth utilization and ultimately move traffic across a network with less latency and packet drops. We’ll begin by covering QoS.
The Three-Step QoS Process So the goal for us is to implement QoS in order to provide a much more consistent and steady transport mechanism for voice, video, and other time-sensitive data flows. While our best-effort design may work well for data, voice traffic requires a bit more care to function optimally. Now that you know what we’re trying to accomplish with QoS, let’s turn our attention to how it works. The QoS function has three stages, which we’ll look at each in turn: 1.
Traffic classification
2.
Traffic marking
3.
Traffic queuing
Traffic Classification Traffic classification is the process of identifying traffic based on different characteristics in order to group the same traffic types together for QoS. The identification process must be performed fi rst because the equipment must be able to clearly identify certain traffic.
c11.indd 444
9/21/11 11:27:12 AM
QoS Policy Considerations
445
Creating voice VLANs makes it easy to identify voice traffic, because we can assume that any packets on the voice VLAN should be classified as such.
Traffic Marking Traffic marking is the process of flagging critical packets so that the rest of the network can properly identify them and give them priority over all other traffic. Cisco phones have the ability to mark voice packets with a Class of Service (CoS) and Differentiated Services Code Point (DSCP) value. The CoS is a field within the Layer 2 Ethernet frame header that marks traffic as being one of eight (0 to 7) classes. The higher the CoS value, the more priority is given. By default, voice traffic is marked with a classification of 5. If data is not marked with a CoS, it is given a value of 0. The CoS is used by Layer 2 switches for proper queuing. The Cisco phone also marks the IP packet with a DSCP value at Layer 3. By marking the ToS/DS field, DSCP essentially does the same thing as CoS but is intended to be used by Layer 3 devices such as routers and switches. Also keep in mind that the Layer 2 headers change at each hop, while Layer 3 header information always remains until it reaches its destination.
Traffic Queuing Traffic queuing is the process of ordering certain types of traffic for transport over LAN/WAN interfaces. Queues are logical storage devices that can be used for egress interface traffic. Egress basically means that the traffic is exiting the interface as opposed to coming into it. Queuing for ingress traffic is not possible, because no queues are available. There are several queuing techniques, discussed under “Congestion Management,” later in this chapter.
QoS Policy Considerations With every managed network, there are network providers and network customers or users. When configuring QoS on an IP network, it is important to create a written policy that details what kind of service end users should expect depending on the traffic type or application used.
The Three-Step QoS Policy Development Process The construction of a QoS policy consists of the following three steps: 1.
c11.indd 445
Consider the traffic types on your network and determine their network delay, jitter, and packet loss requirements. The ITU-T G.114 recommendation states that a one-way delay should not exceed 150 ms for voice. Additionally, Cisco recommends that jitter stay under a 30 ms average and that packet loss should be held under 1 percent.
9/21/11 11:27:12 AM
446
Chapter 11
■
Introduction to Quality of Service
2.
Put your various traffic types into categories based on network requirements. The more sensitive the traffic is to latency, jitter, and packet loss, the higher the priority. For example, voice and video would be placed into the high-priority category, while FTP would be considered low priority. Other applications that are not necessarily time sensitive but are important to the business may also be higher on the priority list. While you might think it to be a good idea to have dozens of different QoS priorities so that your policy is highly granular, having categories over the Cisco recommended maximum of 11 adds very little additional value.
3.
Document your QoS policy to show users where their application traffic fits into the QoS policy structure. Additionally, explain why some traffic is given priority over others. In this way, your network becomes highly transparent to end users, so they understand why some traffic is given a higher priority on the IP network.
Methods of Configuring QoS Policies As QoS has evolved over the years, so too have the methods for configuring QoS policies on Cisco hardware. Following are the three primary methods of configuring QoS policies on QoS-aware Cisco equipment such as routers and switches.
Command Line Interface The command line was at one time the only way to configure QoS on Cisco equipment. As it is with all Cisco command-line interface (CLI) methods, it’s highly robust in the fact that everything that you can do and modify for QoS, you can do with the CLI. Unfortunately, the major drawbacks are the fact that configuring QoS using the command line requires many steps on multiple interfaces of your hardware. This often led to misconfiguration errors on the equipment, which in turn often led network administrators to scrap QoS configurations altogether. But if you know what you are doing and you like the flexibility, the CLI is certainly an option for QoS.
AutoQoS To help simplify the QoS configuration process as well as help eliminate misconfigurations, Cisco developed AutoQoS, which is essentially a CLI script that can be run on QoS-capable Cisco interfaces. This script has only a couple of configuration options to choose from, depending on your network type and the device(s) connected to the interface being configured. The standard Cisco AutoQoS for VoIP is used to configure Cisco routers and switches within a LAN. The AutoQoS for the Enterprise feature, on the other hand, is used at the WAN edge for remote-site QoS configuration across common WAN interfaces such as serial, Frame Relay, and ATM circuits. We will use AutoQoS for basic QoS configuration in Chapter 12.
c11.indd 446
9/21/11 11:27:13 AM
QoS Classification Models
447
Modular QoS CLI The modular QoS CLI (MQC) method strikes a happy medium between the CLI and AutoQoS methods. Using MQC-specific CLI commands, a network administrator can construct a single QoS module on the IOS router or switch. Once that module has been configured, it can then be applied to any interface on that hardware. This gives us a highly flexible and robust QoS configuration system that eases configuration and management issues. MQC has a modular three-step hierarchical structure when configuring a module: 1.
Configure a traffic class that is used to identify a priority of network traffic such as voice.
2.
Create a traffic policy that defi nes the amount of network resources that should be reserved. The traffic class is assigned to a traffic policy.
3.
Assign the traffic policy to the appropriate network interface. Chapter 12 also demonstrates using MQC for class-based QoS configuration.
QoS Classification Models We can categorize all QoS functionality within three distinct QoS feature models:
Best-effort
IntServ
DiffServ
The next three sections will cover what each of these models provides in regard to service of traffic on an IP network.
The Best-Effort Model The Best-effort QoS model is really no model at all. When IP networks run without QoS, all traffic is considered to be best-effort, meaning that there is no guarantee that the packets will be delivered. Additionally, all traffic is treated identically. Thus an email message would be treated by the network the same way that an IP voice call would be. This is how the Internet currently works, as well as any private network that does not have QoS implemented.
The IntServ Model Integrated services, or IntServ, is the only model that guarantees the quality of service for specific types of traffic from end to end. IntServ provides these guarantees by reserving a dedicated amount of bandwidth to specific traffic. Once that traffic has been reserved, it is set aside to be used only by the intended traffic regardless of all other traffic. This bandwidth guarantee is why the IntServ model is often referred to as hard QoS. In a way,
c11.indd 447
9/21/11 11:27:13 AM
448
Chapter 11
■
Introduction to Quality of Service
IntServ carves out its own connection for specified traffic, similar to a PSTN circuit. When a PSTN circuit is not in use, it sits idle. In the same sense, bandwidth that has been reserved by IntServ might sit idle as well while the rest of the bandwidth becomes overutilized. So what type of IP traffic might be configured with IntServ? The classic example would be a dedicated video-streaming application that uses a well-defi ned amount of continuous bandwidth. It is important to point out that IntServ is inherently granular, because one specific flow type must have its own bandwidth reservation. That is why only the most critical applications are configured with IntServ. Considering that you may have hundreds or even thousands of different data flows, it would be impossible to configure IntServ for each of them. IntServ is built upon the Resource Reservation Protocol. RSVP is used for admission control and instructs the QoS device as to what classification the packets should be given along the path. This classification is then used along the entire path of the traffic stream to reserve a set amount of bandwidth. While it is true that IntServ provides an absolute guarantee of bandwidth for specific applications, there are some major drawbacks. For one, IntServ must be configured at every Layer 3 device along the path of the traffic flow. Because of this requirement, IntServ does not scale well. Second, when bandwidth is reserved and not in use, no other traffic can use that bandwidth even when it might be needed. The hard reservation of bandwidth is often wasteful and can lead to utilization problems for other types of traffic. Think of IntServ as an overprotective mother. She won’t let her children play football because of the off chance that they might get hurt. But since this scenario rarely happens, the child never gets to play the game. Similarly, RSVP reserves bandwidth because of the fear the link will be over utilized. But if a network is properly designed, overutilization is probably rare and thus reserve bandwidth is wasted. Because of these drawbacks, IntServ is rarely used and the DiffServ model is used instead.
The DiffServ Model The differentiated services or DiffServ model is sometimes referred to as soft QoS. DiffServ classifies (differentiates) IP traffic flows and marks them for use on other QoS-aware devices along the traffic flow path. This is similar to the IntServ model in terms of classification. DiffServ can group together multiple data-flow types into a single group, however. This helps tremendously with configuration scalability. Another difference from IntServ is that DiffServ does not make an explicit reservation along the path for classified traffic. Instead, the DiffServ marking is used along each hop of the path that traffic takes. Each hop could potentially give the traffic a different level of service, and therefore the quality can’t be considered guaranteed. But if a network is managed by one administrative source, DiffServ could be configured so that service is nearly guaranteed. Additionally, bandwidth is never set aside for one specific type of bandwidth, so a network can be more cost-effective.
c11.indd 448
9/21/11 11:27:14 AM
QoS Classification Models
449
Comparing the QoS Models Before we look in more detail at the widely used DiffServ model, it will be useful to summarize and compare the three QoS models: Best-effort, IntServ, and DiffServ. Each has its benefits and drawbacks. It is important that CVOICE candidates understand when one model is better than another in any given situation. Therefore, Table 11.2 lists the pros and cons for each model. TA B L E 11 . 2
The three QoS models compared
Model
Pros
Cons
Best-effort
Highly scalable
No traffic differentiation
No configuration required
No service guarantee
Absolute service guarantee
Not scalable because of configuration complexities
Complete bandwidth control
Wasted bandwidth when services not in use
Highly granular
Continuous signaling, which wastes a small amount of bandwidth
Highly scalable
Attempted service guarantee but not absolute
Highly granular
Mildly complex to configure
IntServ
DiffServ
Understanding the DiffServ ToS/DS Byte DiffServ uses a traffic-marking mechanism based on either the Type of Service (ToS) byte or the Differentiated Services (DS) byte contained in every IP header. In reality, the ToS and DS byte are one and the same. ToS (originally defi ned in IETF RFC 791) was used to assign packet priorities using IP Precedence. The ToS byte was later renamed the DS byte when it became obvious that IP Precedence was not granular enough for many networks. Instead of IP Precedence, the DSCP marking method was used to create a more granular marking structure as well as provide congesting markings. Let’s take a look at both IP Precedence and DSCP to compare the two marking mechanisms.
IP Precedence This marking method uses 3 of the 8 bits of the ToS byte. The remaining 5 bits are unused. Specifically, IP Precedence uses the 3 leftmost bits of the ToS, as shown in Figure 11.2.
c11.indd 449
9/21/11 11:27:14 AM
450
Chapter 11
F I G U R E 11 . 2
■
Introduction to Quality of Service
IP Precedence and the ToS byte ToS byte 0
1
2
3
4
IP precedence bits
5
6
7
Unused
Since IP Precedence uses 3 binary bits, that means that there are eight possible IP Precedence–marking values, which are numbered 0 to 7. However, the two highest numbers (6 and 7) are reserved for network control traffic such as routing protocols. That means there are six categories that a network administrator can prioritize traffic into. The higher the IP Precedence, the more preferred the traffic is. That is why it is most common to mark voice and video with an IP precedence of 5. Table 11.3 lists the eight possible IP Precedence values and their descriptions according to the RFC. TA B L E 11 . 3
IP Precedence priorities
3-Bit Binary
Decimal
Description
000
0
Routine
001
1
Priority
010
2
Immediate
011
3
Flash
100
4
Flash override
101
5
CRITICAL/ECP
110
6
Internetwork control
111
7
Network control
While the IP Precedence method of marking packets is simple to understand, the limitation that packets could only be assigned six different priorities clearly was a drawback, because it did not provide enough markings to classify the dozens or hundreds of different traffic flows and applications used on today’s networks. Add to that the fact that IP Precedence did not utilize all of the bits within the ToS byte, leaving room to expand the number of priorities, and that is precisely why DSCP was created. You will learn about it next.
c11.indd 450
9/21/11 11:27:15 AM
QoS Classification Models
451
DSCP The Differentiated Services Code Point (DSCP) method effectively replaces IP Precedence and is defined in RFC 2474. It uses a 6-bit field in the newly renamed Differentiated Services (DS) byte (previously known as the ToS byte). DSCP is far more granular, because 6 bits are used to prioritize packets instead of only 3 as with IP Precedence. A network administrator can configure similar behavior flows to operate inside various classes. These similar flows that are traveling in the same direction on a network device are called a behavior aggregate (BA). You are probably curious what the other 2 bits of the DS byte are used for. When DSCP was fi rst developed, the last 2 bits were unused and served no purpose. In 2001, RFC 3168 was introduced and there was fi nally a role for the last 2 bits. According to RFC 3168, the 2 rightmost bits are for explicit congestion notification (ECN). Layer 3 devices can be used to monitor congestion and mark the ECN bits when congestion is detected on an interface. The ECN can then be read by other ECN-aware network devices to reduce their transmission rates. ECN is often used on network equipment that uses Weighted Random Early Detection (WRED) congestion management, which is a more robust congestion tool for voice/video than packet drops. ECM and queuing mechanisms will be discussed later in this chapter. Figure 11.3 shows the DS byte, with its 6 leftmost bits used for DSCP markings and its 2 rightmost bits used for ECN. F I G U R E 11 . 3
DSCP and the DS byte DS byte 0
1
2
3
DSCP bits
4
5
6
7
ECN bits
Now network administrators could theoretically have up to 64 different priority markings if they choose. This made DSCP almost too flexible, so some guidelines were needed so that DSCP values can be uniform when crossing into a network managed by a different administration group. The IETF has created four structured DSCP per-hop behaviors (PHB):
Default PHB
Expedited Forwarding (EF) PHB
Assured Forwarding (AF) PHB
Class Selector (CS) PHB These DSCP subsets of the 64 possible DSCP markings are defi ned next.
Default PHB The default PHB is for all IP data that requires only a best-effort level of service. This would likely be used on the majority of your network data including FTP,
c11.indd 451
9/21/11 11:27:15 AM
452
Chapter 11
■
Introduction to Quality of Service
HTTP, and other noncritical and non-delay-sensitive data flows. The default PHB is defi ned in DSCP as all 0s. Because DSCP uses 6 bits, a default PHB is 000000. Expedited Forwarding PHB The Expedited Forwarding (EF) PHB is defi ned in RFC 3246 and is used for IP data flows that require low latency, packet loss, and jitter. These characteristics are ideal for real-time traffic such as voice and video, and therefore most voice traffic is tagged with EF PHB. Using the 6 bits of the DSCP field, EF is 46 in decimal or 101110 in binary format. Assured Forwarding PHB The Assured Forwarding (AF) PHB is defi ned in RFC 2597 and 3260 and has 12 different priority classes within the group. The priorities are broken up into four classes each containing three drop probabilities. The priorities within each class are divided into low, medium, and high drop probabilities, as shown in Table 11.4. TA B L E 11 . 4
AF PHB classes and drop priorities
Drop Probability
Class 1
Class 2
Class 3
Class 4
Low drop
AF11 (DCSP 10)
AF21 (DCSP 18)
AF31 (DCSP 26)
AF41 (DCSP 34)
Med drop
AF12 (DCSP 12)
AF22 (DCSP 20)
AF32 (DCSP 28)
AF42 (DCSP 36)
High drop
AF13 (DCSP 14)
AF23 (DCSP 22)
AF33 (DCSP 30)
AF43 (DCSP 38)
The higher the AF class number, the more preferred the packet will be on a network. But instead of using strict priority queuing between classes, a fair queuing algorithm is commonly used so that lower-class packets are not choked off completely. Additionally, packets within a class have a drop precedence applied to them. If congestion occurs within a single class, the packets marked with a higher drop precedence are dropped before ones marked with medium and low precedence. Drop precedence is handled using traffic-policing mechanisms, which are used to drop excess packets that venture above a defined rate limit. If you look at the binary conversion of the 12 AF PHB classes, you can better see the structure and backward compatibility inherent in AF PHBs, as shown in Table 11.5. TA B L E 11 . 5
AF PHB binary values
Class 1
c11.indd 452
Class 2
Class 3
Class 4
Low drop
001
010
010
010
011
010
100
010
Med drop
001
100
010
100
011
100
100
100
High drop
001
110
010
110
011
110
100
110
9/21/11 11:27:16 AM
QoS Classification Models
453
Recall that IP Precedence uses only the 3 leftmost bits in the field (highlighted in gray in Table 11.5). Therefore all AF class 1 values would be treated as having an IP Precedence of 1. Class 2 AFs would have an IP Precedence of 2, and so on. Alternatively, you will notice that all of the drop precedence bit values (in white) are identical for the low (binary 010 or decimal 2), medium (binary 100 or decimal 4), and high (binary 110 or 6) drops. One final thing to keep in mind is that the highest number here does not represent the highest priority packet. The leftmost 3 bits that represent the AF classes are based on the strategy that a higher number is better, but the drop preference bits use a lower-number strategy. Therefore, a class 2, low-drop packet (binary 010010 or decimal 18) is less likely to be dropped than a class 2, high-drop packet (binary 010110 or decimal 22). Class Selector PHB The Class Selector (CS) PHB is defi ned in RFC 2474 and is the DSCP subset that most closely follows IP Precedence values. This is because CS PHBs technically use only the 3 leftmost bits, and the 3 rightmost bits are all 0s. So when a CS value is 110000 (or a decimal value of 40), devices that are compatible only with IP Precedence would read 110, or a decimal IP Precedence of 5, which means this packet would be treated as a voice/video real-time priority packet.
DiffServ Service Quality Features Once IP packets are placed in classes and properly marked, a number of quality tools can be implemented on a network to make the network play nice for time- and drop-sensitive packets. This includes features such as the following:
Congestion management
Congestion avoidance
Traffic policing and shaping
Link efficiency
In the next few sections, we will detail what each of these features can do for priority traffic flows.
Congestion Management Congestion management uses logical queues within network hardware interfaces to store packets that are waiting to be transmitted on a congested link. Different queuing mechanisms can be used to determine which packets leave the queue first and which ones have to stay a longer period of time. This is where classification and marking of packets comes into play. Once you can classify traffic flows and mark them so that network equipment can differentiate between packets of different classes, queue emptying strategies can be implemented. Cisco currently supports these queuing mechanisms: First-In First-Out The fi rst-in fi rst-out (FIFO) queuing mechanism does not place any emphasis on packet priorities. Instead, the fi rst packet to be placed in the queue is the fi rst one to come out. This is the default queuing method on Cisco hardware for any interface above an E1 speed.
c11.indd 453
9/21/11 11:27:17 AM
454
Chapter 11
■
Introduction to Quality of Service
Priority Queuing Priority queuing (PQ) is a strict queuing mechanism that is used to give explicit priority to certain traffic types. These traffic types can be divided into categories such as protocol type, source/destination IP, packet size, and incoming interface. PQ can place traffic into one of four different queues—labeled high, medium, normal, and low—based on the priority assignment by the network administrator. Packets that are not prioritized are placed into the normal queue. Packets in the higher queues are given absolute preferential treatment and allowed out of the queue. Therefore, PQ suffers from queue starvation for traffic at lower preferred levels. Priority queuing is also known as strict priority queuing because of its strict nature. Custom Queuing The custom queuing (CQ) mechanism divides the total number of queue slots into different classes. Each class gets a certain number of queue spaces; this value can be configured by the network administrator. The more preferred a class is, the more queue slots it is given. The queued traffic is then performed in a round-robin fashion, where the classes with more queue allocation will have the opportunity to transmit packets out of the queue more frequently. CQ was designed to let administrators allocate more resources for traffic with minimum bandwidth and low-latency requirements such as voice. There are 17 total queues, but queue 0 is designated for network signaling messages. Queues 1 through 16 are handled in the round-robin fashion, so the complete queue starvation that was found in PQ is eliminated. One drawback is that applications with larger packet sizes inadvertently receive more bandwidth than others because the roundrobin mechanism sends the complete packet. Therefore, smaller voice packets can suffer under this method. Weighted Fair Queuing As you’ve learned, custom queuing (CQ) has a downside when it comes to the fairness of handling large versus small packets. The larger packets get preferential treatment because CQ transmits the entire packet from a queue regardless of size. Weighted fair queuing (WFQ), on the other hand, is much fairer to small-packet transmissions because it transmits data from queues at the byte level as opposed to the packet level. Therefore, if queue 1 has 10 packets that are 200 bytes each and queue 2 has 20 packets that are 100 bytes each, WFQ will transmit 1 packet in queue 1 and 2 packets in queue 2. Weighted fair queuing also has the ability to prioritize traffic based on data flows. It does this by matching frame header information such as source/destination IP or MAC address, protocol and port numbers, and IP Precedence in the ToS field. WFQ then places the categorized traffic into either high- or low-bandwidth traffic. Low-bandwidth traffic flows are given higher priority and receive preferential queuing treatment. The WFQ mechanism provides a much more consistent one-way delay and reduces jitter. That is why WFQ is great on low-speed WAN links and is the default queuing method for interfaces at E1 speeds or below. Class-Based Weighted Fair Queuing An extension of standard WFQ, class-based weighted fair queuing (CBWFQ), lets an administrator create classes and places categorized traffic into multiple classes. Each class can then be given a minimum bandwidth requirement level, which CBWFQ will attempt to meet for the entire class. Note that the minimum bandwidth level is not at a flow level but based on all the flows within a
c11.indd 454
9/21/11 11:27:17 AM
QoS Classification Models
455
class. CBWFQ is very fair, but this fairness can sometimes prevent sensitive voice or video traffic from getting out of queues because of the inability to use strict queuing methods. Low Latency Queuing Low Latency Queuing (LLQ) is a priority queue (PQ) mechanism with CBWFQ classes built in. Essentially, LLQ is two different queuing methods in one. This mechanism provides a very fair level of service and is commonly used on high-speed LAN interfaces that transport voice and video. LLQ allows for priority queuing based on administrator-defi ned class flows instead of specific traffic types. LLQ is perfect for voice and video because it allows an administrator to configure voice and video flows in a high-priority class. This class can then be configured for a strict queuing priority to ensure preferential treatment. Other traffic that does not need strict priority queuing can use WFQ or CBWFQ queuing instead. As you can see, there are many queuing mechanisms to choose from. When QoS was new, there were only a few queuing strategies, such as PQ and CQ, and they solved very specific problems while introducing others. Later on, more general-purpose queuing methods such as WFQ and CBWFQ came around and were very popular. Finally, LLQ was developed, which is a combination of simple PQ and CBWFQ and is the preferred queuing mechanism that Cisco recommends for voice and video networks because it was built specifically to service real-time traffic.
Congestion Avoidance Sometimes an interface’s queue gets filled up to the maximum. When this happens without intervention, new packets that have no place to go are dropped. For applications that are not time sensitive and are running TCP, tail-dropped packets are not a big deal because the packets can simply be retransmitted. But time-sensitive traffic that uses UDP suffers greatly from dropped packets. Therefore, it is often wise to implement congestion-avoidance features such as Weighted Random Early Detection (WRED). WRED is a congestionavoidance tool that uses the original Random Early Detection (RED) tool and combines it with IP Precedence intelligence to drop packets based on priority levels. RED uses TCP’s built-in capability to retransmit packets that are dropped. If the sending device begins to see that it has to continuously retransmit dropped packets, it will automatically reduce its transmission speed to help ease any possible congestion. WRED adds an extra layer of intelligence that will discard packets on a congested interface that have a lower IP Precedence first. This works out well because voice and video (which often operate on UDP and thus cannot retransmit packets) will be at a higher precedence, while more robust data transactions using TCP will have lower IP Precedence and their packets will be dropped first, triggering the host to temporarily slow down its transmissions. WRED is ideal in bottleneck situations and is commonly configured on WAN interfaces, which are likely to be slower than LAN interfaces.
Traffic Policing and Shaping Traffic policing and shaping is all about setting maximum limits for classes of traffic. This approach is in contrast to setting a minimum value. Traffic shaping and policing is
c11.indd 455
9/21/11 11:27:18 AM
Chapter 11
456
■
Introduction to Quality of Service
also known as traffic conditioning, because you condition your traffic not to overreach its bandwidth boundaries. Traffic Policing Traffic policing is the more hard core of the two traffic-conditioning methods. The technique does not rely on interface queues and can therefore be applied either inbound or outbound on an interface. When data attempts to come into or out of an interface and it exceeds a configured policing maximum level, the packets are dropped or marked, based on configuration details. Policing does not buffer packets. Because no buffering occurs, you can see that bursty data is simply cut off at the tips when graphed, as shown in Figure 11.4. F I G U R E 11 . 4
Traffic policing Dropped traffic
Traffic
Maximum rate
Time
Notice that when traffic bursts above the maximum rate, traffic policing allows only the maximum traffic rate to be sent. This is how policing works; the interface is configured to send only a specific amount of traffic over a set period of time. Because of this characteristic, you commonly see a sawtooth diagram of peaks and valleys. Traffic policing is also commonly implemented in network bottleneck situations and usually found configured on WAN interfaces. The two possible traffic-policing methods that can be configured on Cisco hardware are these:
Committed Access Rate (CAR): A legacy traffic-policing method that limits traffic rates based on criteria such as IP Precedence, MAC address, or IP address.
Class-based policing: A newer policing method that uses a more advanced algorithm and can match traffic on information such as DSCP values, class maps, and Layer 2 CoS as well as the same criteria that CAR matches on.
Traffic Shaping Traffic shaping buffers data into queues. Because queuing techniques are only used outbound on interfaces, traffic shaping can only be applied outbound. Also, because queues are used with traffic shaping, those packets that are queued should eventually be transmitted. Therefore, if we graph the same interface data as we did with the traffic policing, instead of the sawtooth graph, we should see a much smoother traffic rate, as shown in Figure 11.5.
c11.indd 456
9/21/11 11:27:18 AM
QoS Classification Models
Traffic shaping
Maximum rate
Traffic
F I G U R E 11 . 5
457
Time
Policing vs. Shaping on Low-Speed WAN Connections Richard was responsible for configuring IP voice services at a remote site that utilized a shared voice/data WAN connection. At times the WAN became overutilized. Richard decided to implement traffic policing in an attempt to proactively avoid congestion. After traffic policing was implemented, Richard noticed that it had little effect on the quality and reliability of calls during periods of high bandwidth utilization on the WAN. So he scrapped the traffic-policing configuration and instead configured traffic shaping on his outbound interfaces across the WAN. This time, there was a noticeable difference in the quality and reliability of calls. Richard discovered that since voice packets are transported using UDP, when traffic policing happened to drop those packets, UDP could not retransmit them. This caused calls to stutter or fail altogether if congestion was high. Alternatively, with traffic shaping, the voice UDP packets were queued rather than completely dropped. In this situation, the voice packets might have been delayed, but they eventually made it out of the queue, and call clarity improved and there were fewer dropped calls.
The primary differences between policing and shaping are that policing will cause more drops and therefore more TCP retransmissions, while shaping will add additional variable delay because packets have to be placed into queues and wait to be transmitted on the wire.
Link Efficiency In addition to configuring QoS on your network for voice support, you can use two other link-efficiency techniques to help with the consistent transport of VoIP. These techniques are compression and link fragmentation and interleaving (LFI). Again, keep in mind that linkefficiency techniques should only be applied to low-speed WAN interfaces below 768 Kbps.
Compression Techniques There are two primary types of frame-compression techniques. The first is payload compression, in which compression techniques are used to reduce the data payload size. Obviously, the smaller the frame size, the more frames can be transmitted over a
c11.indd 457
9/21/11 11:27:19 AM
458
Chapter 11
■
Introduction to Quality of Service
fixed-bandwidth link. Cisco router hardware commonly uses two forms of payload compression. The first method is called stacker compression and uses a special encoded dictionary that both routers possess. The router replaces streaming data with much smaller codes found in the dictionary. The data is then sent to the receiving router interface, where the symbols are looked up and converted back into the original data stream. The predictor compression method, on the other hand, attempts to predict the next sequence of characters in a data stream by using an index in the compression dictionary. Predictor looks at a portion of the data stream and looks it up in the compression dictionary. If a sequence match is found, that data is replaced with the sequence that was previously looked up. The other type of frame compression is header compression, such as cRTP, which compresses the standard 40-byte headers into either 2- or 4-byte sizes depending on CRC settings. Keep in mind that cRTP can only be configured on serial interfaces, as shown in Figure 11.6. F I G U R E 11 . 6
An example of compression T1 PPP S1/0
S1/0
Router-A
Router-B cRTP compression
In general, compression should be used only on low-speed WAN links where potential bottlenecks exist. Otherwise, the benefit of compression simply isn’t worth the increased memory and CPU utilization that compression processes consume. Also remember that these techniques affect only a single hop along the entire path. When a voice packet must traverse multiple low-speed WAN links, each of them needs to be configured separately.
Link Fragmentation Interleaving A second link-efficiency technique that is commonly used on low-speed PPP multilink circuits is called link fragmentation interleaving (LFI). This process takes large data frames and fragments them into smaller, more manageable sizes. If we don’t break down large frames into smaller ones, our smaller voice packets that are waiting behind the large data packets can experience serialization delay, which can seriously hurt voice quality. Serialization delay is the amount of time it takes the router to place a packet onto the outbound interface. The amount of time depends on the packet size and interface link speed. The formula for calculating serialization delay is: Serialization_delay (packet_byte_size 8) / link_bps_speed For example, let’s say we have a 512 Kbps WAN link and a packet that is 1024 bytes. Therefore we calculate serialization delay as: Serialization_delay (1024 8) / 512000 Serialization_delay 8192 / 512000
c11.indd 458
9/21/11 11:27:19 AM
Layer 2 Class of Service and QoS Trust Boundaries
459
Serialization_delay 0.016 seconds Serialization_delay 16 milliseconds If you play around with larger packet sizes across WAN links with low bandwidths, you’ll begin to see the serious impact that serialization delay can have on time-sensitive traffic. This is why LFI is so important on low-speed links. LFI breaks up large, Layer 2 frames into much smaller sizes. It then is able to interleave voice frames between the newly fragmented data frames. This process ensures that voice packets have a more consistent variable delay and significantly cuts down on voice jitter. In Chapter 12 we will configure the two most commonly implemented LFI mechanisms, MLP LFI and FRF.12, for Frame Relay connections.
Layer 2 Class of Service and QoS Trust Boundaries This section explains how we can design our IP network to best handle QoS for voice and video. First, we will look at a way to enable Layer 2 devices to prioritize frames using a field in an 802.1Q frame. This allows us to mark data either at Layer 2 or Layer 3 in the network. Next, we will look at the different locations in a network where classification and marking can and ideally should occur.
Layer 2 Classification and Marking with CoS So far we’ve discussed in detail how to mark packets with either IP Precedence or DSCP. Unfortunately, these two marking methods are Layer 3 mechanisms, and therefore Layer 2 devices (such as Layer 2 switches) cannot perform any QoS marking. Fortunately, Class of Service (CoS) allows us to configure Layer 2 switches to classify and mark Ethernet frames that pass through a CoS-capable Layer 2 switch. The CoS consists of 3 bits that are found inside a field within the 2-byte 802.1Q header Tag Control Information (TCI). The 3-bit CoS markings follow the exact same structure as IP Precedence, where there are eight possible values (0–7), and priorities 6 and 7 are recommended for network information usage only. The CoS bits within an 802.1Q frame are shown in Figure 11.7.
F I G U R E 11 . 7
CoS bits in an 802.1Q frame header
Preamble
Start frame delimiter
DA
SA
TCI
PT
Data
FCS
3 Bits of the TCI are for CoS
c11.indd 459
9/21/11 11:27:20 AM
460
Chapter 11
■
Introduction to Quality of Service
If you are using CoS at the Access layer, voice frames from Cisco IP phones will already be marked with both CoS (in the 802.1Q frame header) and DSCP (in the IP DS field) priorities. Remember that Cisco IP phones transport data in 802.1Q frames, so they can place voice traffic in one VLAN and (if a computer is connected to the phone’s Ethernet port) data in a separate VLAN, as shown in Figure 11.8. The switch can either trust the CoS markings contained within the 802.1Q header or rewrite them. Native VLAN frames that come into the switch untagged are assigned an administrator-defi nable CoS, which is 0 by default.
F I G U R E 11 . 8
IP phone 802.1Q tags
PC Cisco phone
Switch Fa0/5
Trunk link
Voice VLAN Data VLAN
Once the switch either trusts or re-marks frames, they are sent out the egress port to the next hop along the network path to their destination. By default, the egress port will send all traffic to a single queue. Alternatively, an egress port can be configured to place traffic into one of four queues where frames are placed into a queue. The de-queuing mechanism can be configured to use either strict priority scheduling or weighted round-robin (WRR) scheduling.
Identifying QoS Trust Boundaries You can classify, mark, and begin enforcing queuing strategies for IP traffic at several points along a network. But where should this process begin? The simplest answer is to push your trust boundary out as far to the endpoint as possible. But, depending on the type of network, you may have to pull the boundary in a bit based on how much you trust markings from end devices (that’s why it’s called a “trust” boundary!). If you have full control of endpoints, then you control the CoS and ToS/DS markings that are generated, and you can push the trust boundary out to the phone and even PC levels. If you do not have as much control over your network, it might be better to begin marking (and possibly overwriting) CoS/ToS values as soon as the traffic hits your switch. Also, you may run into a situation where your access switches are not capable of QoS. Because of this, you have no choice but to configure the trust boundary at the Distribution layer. Figure 11.9 illustrates where trust boundaries can be implemented within a typical network.
c11.indd 460
9/21/11 11:27:21 AM
QoS Baseline Models
F I G U R E 11 . 9
461
Trust boundaries Trust at Distribution layer Trust at Access layer
Trust any endpoint
Trust cisco phones
Si
Most organizations will trust CoS/ToS/DS markings from Cisco IP phones but will not trust the markings from devices attached to the phone, such as a PC. When network data from the PC reaches the Cisco phone, the switch will ignore the CoS/ToS/DS markings and consider all data packets to have a value of 0 by default.
QoS Baseline Models When you begin designing QoS policies for your network, it can be a little overwhelming. Every network is different and runs very different applications. Additionally, data that may be a priority for some networks may be farther down the list for others. While prioritizing your network data is completely up to your discretion, there are several available QoS baseline models that give you a classification framework to organize your data more easily and with a sense of consistency.
Comparing the Cisco QoS Baseline Model While there are multiple QoS baseline models, the Cisco QoS baseline model is the one that we will focus on. The Cisco QoS baseline model consists of 11 different classes that you can place your applications/data into. Figure 11.10 shows the Cisco QoS baseline model beside common 8-class and 5-class models so you can compare and contrast how each class is broken down.
c11.indd 461
9/21/11 11:27:22 AM
462
Chapter 11
F I G U R E 11 .1 0
■
Introduction to Quality of Service
The Cisco QoS baseline model compared with 5- and 8-class models Cisco QoS baseline
8-Class model
Voice
Voice
Video conf
Network control
Real-Time
Video stream Call signaling
Call signaling
Call signaling
Routing
Network control
Network mgmt
5-Class model
Critical
Critical data Critical data
Transactional Bulk data
Bulk data
Best-effort
Best-effort
Best-effort
Scavenger
Scavenger
Scavenger
Recommended Cisco Baseline Classification Markings Since we have 11 different classes within our Cisco QoS baseline model, we should mark our packets with DSCP, PHB, or CoS markings according to the Cisco recommended method, as shown in Table 11.6. TA B L E 11 . 6
c11.indd 462
Cisco QoS baseline recommended markings
Cisco QoS Baseline
PHB
DSCP
CoS
Routing
CS6
46
6
Voice
EF
46
5
Video conf
AF41
34
4
Video stream
CS4
32
4
Critical
AF31
26
3
Call signaling
CS3
24
3
Transactional
AF21
18
2
Network mgmt
CS2
16
2
Bulk data
AF11
10
1
Scavenger
CS1
8
1
Best-effort
0
0
0
9/21/11 11:27:22 AM
QoS Baseline Models
463
The beauty of using a QoS model such as the Cisco baseline is the fact that you can more easily provide an end-to-end classification and marking model. Once you have a consistent model in place, it is much easier to treat your marked data with the same level of service throughout the entire network.
Recommended Cisco Baseline Congestion-Management and -Avoidance Tools So far, the Cisco QoS baseline model has given us a structured model for classification and marking. The fi nal piece of the puzzle is to implement consistent congestion management in the form of queuing and congestion avoidance using RED and WRED. Table 11.7 lists each of the 11 Cisco baseline classes, in order from highest to lowest priority, and their Cisco recommended congestion-management and -avoidance configurations. TA B L E 11 . 7 Cisco QoS baseline recommendations for congestion management and avoidance, from highest to lowest priority Cisco QoS Base
Recommended QoS
Routing
CBWFQ + RED
Voice
RSVP + LLQ
Video conf
RSVP + CBWFQ + DSCP-WRED
Video stream
RSVP + CBWFQ + RED
Critical
CBWFQ + DSCP-WRED
Call signaling
CBWFQ + RED
Transactional
CBWFQ + DSCP-WRED
Network mgmt
CBWFQ + RED
Bulk data
CBWFQ + DSCP-WRED
Best-effort
BW Guarantee CBWFQ + RED
Scavenger
No BW Guarantee + RED
Notice that some of these recommended configurations, such as voice, include call admission control. CAC is used to ensure that only a specified number of simultaneous calls can be made. This is typically done on WAN interfaces that may be a possible bottleneck.
c11.indd 463
9/21/11 11:27:23 AM
464
Chapter 11
■
Introduction to Quality of Service
Summary This chapter covered the terminology, methods, and models used to implement QoS on a network for voice and video. This included the three-step QoS process of traffic classification, marking, and queuing. You also learned two different congestion-avoidance techniques in the form of compression and LFI. In Chapter 12, we will put all this knowledge to use when we set about actually configuring QoS on Cisco routers and switches.
Exam Essentials Understand how to resolve potential problems with voice/video on IP networks. Timesensitive traffic such as voice and video can suffer from delay, jitter, and packet loss. To resolve these problems, network administrators should provide sufficient bandwidth, eliminate bottlenecks, use QoS to prioritize traffic, and use link-efficiency techniques to reduce bandwidth requirements. Understand the three-step QoS process. QoS can be broken down into three steps. First is the classification of data. Next is the marking of classified traffic. And the third is using interface queuing techniques on marked traffic. Understand the purpose of a QoS policy. A QoS policy should be created so network users understand what levels of service to expect for various networked applications. Know the three QoS IOS configuration methods. The three methods that can be used to configure QoS on Cisco routers are command-line interface (CLI), AutoQoS, and Modular QoS CLI (MQC). Know the three QoS classification models. There are three different QoS classification models with which to categorize traffic. The models are Best-effort, IntServ, and DiffServ. Understand the DiffServ ToS/DS byte. The ToS or DS is a byte within every IP header. This byte is used for the marking of packets so they can be placed into different classes. It is called the ToS byte when IP Precedence is being used and called the DS byte when DSCP is being used. Know the IP Precedence values. IP Precedence is a marking system that uses 3 bits. There are eight possible values. The higher the value, the more preferred the packet is. Know the DSCP values. IP Precedence is a marking system that uses 6 bits. There are 64 possible values. DSCP can be used on its own, or per-hop behavior models can be used to classify traffic. Know the four IETF PHB systems. The four structured per-hop behaviors (PHB) are Default PHB, Expedited Forwarding (EF), Assured Forwarding (AF), and Class Selector (CS).
c11.indd 464
9/21/11 11:27:23 AM
Written Lab 11.1
465
Know the four DiffServ quality features. DiffServ can be configured for the following quality features: congestion management, congestion avoidance, traffic policing/shaping, and link efficiency techniques. Understand CoS markings. Class of Service markings are 3 bits contained with Layer 2 Ethernet frames that can be used for marking traffic that can be understood by Layer 2–switch hardware. Know the possible trust boundary locations. Trust boundaries can be located at endpoints, IP phones, access switch ports, and the Distribution layer. Understand the Cisco QoS baseline model. Cisco recommends that traffic be classified into 11 specific groups based on traffic type and sensitivity to delay.
Written Lab 11.1 1.
Of all the possible methods used to prevent delay problems on time-sensitive IP traffic, which method is preferred if possible?
2.
What are the three steps of the QoS process?
3.
What QoS method uses a three-stage hierarchical configuration structure?
4.
Which QoS classification model is also called soft QoS?
5.
When using IP Precedence, what is voice traffic commonly marked as?
6.
When using DSCP, what is voice traffic commonly marked as using both the DSCP decimal and PHB formats?
7.
How are the 12 PHB AF classes categorized?
8.
LLQ is a combination of what two queuing mechanisms?
9.
The primary difference between traffic policing and traffic shaping is that traffic policing drops packets outright instead of using what?
10. A Cisco Catalyst switch operating at Layer 2 can understand which type of QoS
markings? (The answers to Written Lab 11.1 can be found following the answers to the review questions for this chapter.)
c11.indd 465
9/21/11 11:27:24 AM
Chapter 11
466
■
Introduction to Quality of Service
Review Questions 1.
Which of the following is not a characteristic of voice traffic on an IP network? A. Small packet payloads
2.
B.
Time sensitive
C.
Sensitive to compression
D.
Sensitive to packet loss
What type of delay should a network administrator focus most on reducing using QoS mechanisms? A. Fixed delay
3.
B.
Variable delay
C.
Compression delay
D.
Signaling delay
What is another name for an occurrence when an output interface queue fills up and begins discarding packets? A. Delay
4.
B.
Jitter
C.
Frame overflow
D.
Tail drop
Which of the following is not a reason for packet loss on a router interface that has limited bandwidth? A. Input queue drops
5.
B.
Tail drops
C.
DSCP marking of 0
D.
CRC errors
Which QoS classification model uses either the ToS or DS byte to mark packets? A. DiffServ
6.
B.
IntServ
C.
Best-effort
D.
Both IntServ and DiffServ
IP Precedence marking uses which bits of the ToS IP header field? A. The 6 leftmost bits
c11.indd 466
B.
The 4 leftmost bits
C.
The 3 leftmost bits
D.
The 4 rightmost bits
9/21/11 11:27:24 AM
Review Questions
7.
467
According to best-practice strategies, network administrators can use IP Precedence to classify traffic into how many different groups? A. 6
8.
B.
7
C.
8
D.
46
What is the decimal equivalent to the AF binary value11? A. 8
9.
B.
10
C.
36
D.
46
Voice traffic is commonly marked with what DSCP value? (Choose two.) A. 64 B.
AF42
C.
EF
D.
46
E.
CS4
10. You are installing a T1 circuit for an IP WAN to a remote site. What queuing mechanism will be enabled by default? A. CQ B.
FIFO
C.
None
D.
WFQ
11. What QoS queuing mechanism can use strict priority queuing for voice traffic and WFQ or CBWFQ for other types of traffic? A. CQ B.
PQ
C.
LLQ
D.
Traffic policing
E.
Traffic shaping
12. Which congestion-avoidance technique drops packets based on IP Precedence values before buffers begin to get congested? A. WRED
c11.indd 467
B.
Traffic shaping
C.
RED
D.
Traffic policing
9/21/11 11:27:24 AM
Chapter 11
468
■
Introduction to Quality of Service
13. What are the two traffic-policing methods on Cisco equipment? A. WFQ B.
Class-based
C.
RED
D.
CAR
E.
WRED
14. Why is traffic shaping more suited for voice and video traffic than policing? A. Traffic shaping prioritizes voice and video traffic more aggressively. B.
Traffic policing will not queue any packets, including voice and video.
C.
Traffic policing will put voice/video packets into queues, which causes delay and jitter.
D.
Neither traffic policing nor traffic shaping is recommended when operating voice/video over IP.
15. We will configure LFI on a 256 Kbps WAN interface but first need to know what serialization delay to expect if we break up packets into 128-byte sizes. Based on this information, what is the approximate serialization delay for this interface? A. 8 ms B.
16 ms
C.
4 ms
D.
24 ms
16. Which of the following is not a negative aspect of IntServ? A. No service guarantee B.
Potential for wasted bandwidth
C.
Large amount of signaling traffic
D.
Not scalable
17. Cisco best-practice methodologies recommend that network administrators separate traffic into or fewer classes for QoS purposes. A. 64 B.
32
C.
11
D.
12
18. Using the Cisco QoS baseline model, voice traffic will be marked with which values for PHB, DSCP, and CoS? A. EF, 42, and 1
c11.indd 468
B.
AF41, 46, and 7
C.
EF, 46, and 5
D.
AF41, 42, and 5
E.
AF41, 46, and 1
9/21/11 11:27:25 AM
Review Questions
469
19. The Cisco recommended congestion-management tools for voice include which two of the following? A. CBWFQ B.
LLQ
C.
RSVP
D.
DSCP-WRED
E.
RED
20. Which classification of traffic is given QoS tools that technically give it a lower priority than a best-effort level of traffic? A. Bulk data
c11.indd 469
B.
Transactional
C.
Scavenger
D.
Call signaling
9/21/11 11:27:25 AM
Chapter 11
470
■
Introduction to Quality of Service
Answers to Review Questions 1.
C. Voice traffic is not sensitive to compression, which in many instances is implemented to provide better voice services.
2.
B. Using QoS mechanisms, a network administrator should focus on reducing variable delay on IP networks for time-sensitive traffic.
3.
D. Interface output drops are also known as tail drops.
4.
C. Having a DSCP marking of 0 will not cause the packet to be dropped on a bottlenecked interface unless it is explicitly configured.
5.
A. Of the three QoS classification models, only DiffServ uses the ToS or DS byte to mark packets for prioritization purposes.
6.
C. IP Precedence uses the 3 leftmost bits of the ToS byte for marking purposes.
7.
A. IP Precedence has eight total markings but best-practice documentation states that classes 6 and 7 should be reserved for network control traffic and therefore should not be used. Therefore, there are six available classes to group traffic under.
8.
B. AF11 is equivalent to 10 in decimal.
9.
C, D. Voice traffic is commonly classified with a DSCP PHB of hexadecimal EF, which is 46 in decimal format.
10. D. WFQ is enabled on interfaces that are E1 speeds or lower. 11. C. LLQ uses a strict priority-queuing technique, which is ideal for voice and/or video traffic. All other traffic is queued using either WFQ or CBWFQ. 12. A. Weighted Random Early Detection (WRED) is a mechanism that randomly drops packets before buffer queues get completely full. WRED uses IP Precedence and drops packets with lower values more often. 13. B, D. There are two methods of implementing traffic policing. CAR is the older method, used for legacy traffic, and class-based is the newer method that is commonly implemented in new installations. 14. B. Traffic policing will drop packets outright, whereas traffic shaping places them into queues. While voice or video packets may be delayed, it’s better than not getting the packet at all. Traffic shapers have a queue associated in order to get the best probability of packet transmission. 15. C. Serialization_delay (128 8) / 256000 Serialization_delay 1024 / 256000 Serialization_delay 0.004 4 ms
c11.indd 470
9/21/11 11:27:25 AM
Answers to Review Questions
471
16. A. One positive aspect of IntServ is its ability to offer absolute service guarantees. 17. C. Cisco’s QoS baseline model recommends you segment traffic into one of the 11 different class categories. Depending on your network size and traffic types, not all classes need to be used. 18. C. According to the Cisco QoS baseline model, voice traffic should be marked with an EF PHB, DSCP 46, or CoS value of 5. 19. B, C. The QoS tools recommended for voice are RSVP and LLQ. 20. C. Scavenger traffic is recommended to have no bandwidth guarantee at all.
c11.indd 471
9/21/11 11:27:26 AM
Chapter 11
472
■
Introduction to Quality of Service
Answers to Written Lab 11.1 1.
Increasing bandwidth
2.
Traffic classification, traffic marking, and traffic queuing
3.
Modular QoS CLI (MQC)
4.
DiffServ
5.
5
6.
46 or PHB EF
7.
Four classes with three drop priorities
8.
PQ and CBWFQ
9.
Queue buffers
10. CoS
c11.indd 472
9/21/11 11:27:26 AM
Chapter
12
Configuring Quality of Service THE FOLLOWING CVOICE EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Describe and configure the DiffServ QoS model. ■
Configure Layer 2 to Layer 3 QoS mapping.
■
Configure trust boundary on Cisco switches.
■
Describe the operations of the QoS classifications and marking mechanisms.
■
Describe Low Latency Queuing.
■
Describe the operations of the QoS WAN link efficiency mechanisms.
c12.indd 473
■
Enable QoS mechanisms on switches using AutoQoS.
■
Configure Low Latency Queuing.
9/21/11 11:27:51 AM
Chapter 12 is where the QoS rubber meets the network road. Chapter 11, “Introduction to Quality of Service,” covered the basics of QoS, and now it is time to apply what you learned to the routers and switches. You will learn how to implement QoS policies using the AutoQoS methods at Layer 2 and Layer 3, as well as the three-tiered MQC mechanism, where we mark traffic flow, set policies, and apply them to interfaces. In addition, we will look at how to configure class-based link efficiency techniques, traffic policing and shaping, trust boundaries, and Layer 2 to Layer 3 mapping modifications. At the end of this chapter, you should have a solid understanding of how to configure key QoS components as well as how to verify their operation.
Configuring QoS Policies Using AutoQoS If you quickly want to get a uniform QoS implementation up and operational on a network, AutoQoS is the way to go. Essentially, AutoQoS is a built-in script where the router automatically evaluates a network and then applies QoS settings based on the script’s best guess at a policy that will work in a particular infrastructure environment. The evaluation includes verification of interface types and link speeds. The AutoQoS configuration method is by far the easiest method to implement because little knowledge is required of you in order to implement it. QoS deployment times are greatly reduced, and the best-practice configurations are uniform on all network equipment. AutoQoS can be configured on both routers and switches, although their configurations and operations vary. Only certain routers are capable of using AutoQoS. The current generation of ISR and ISR G2 routers supports AutoQoS. From a router perspective, AutoQoS is commonly configured on WAN interfaces that may be bottlenecks at some point along a path. AutoQoS may configure the following features on WAN interfaces:
c12.indd 474
Automatic classification of RTP, cRTP, and voice gateway signaling protocols (SCCP, H.323, SIP, MGCP)
Automatic building of service policies for priority traffic
LLQ implementation for high-priority traffic
Traffic shaping where appropriate
Link fragmentation where appropriate
cRTP compression where appropriate
9/21/11 11:27:53 AM
Configuring QoS Policies Using AutoQoS
475
The automatic classification function within AutoQoS uses the NetworkBased Application Recognition (NBAR) feature to identify and classify different application and data types based on Layer 4 UDP and TCP port numbers. In order for NBAR to work on a router interface, Cisco Express Forwarding (CEF) must be enabled first. CEF has been enabled by default, beginning at IOS 12.2, so if you are running an earlier version, you must make sure to manually enable it.
On the LAN side of the network, any Cisco Catalyst switch can have AutoQoS for VoIP configured on its access ports and trunk ports. The following QoS features can be enabled on switchports using AutoQoS for VoIP:
Set the trust boundary at the Cisco IP phone
Set the trust boundary at the access port or trunk-port level
Automatically enable PQ and WRR queuing when appropriate
Automatically add or modify CoS markings where appropriate
Automatically adjust queue sizes and weights where appropriate
Perform CoS-to-DSCP or IP precedence–to-DSCP mappings
You must choose from two AutoQoS implementation methods when configuring AutoQoS on a router:
AutoQoS for VoIP
AutoQoS for the Enterprise
The AutoQoS for VoIP is the least complex AutoQoS method, and it primarily focuses on prioritizing traffic for voice. It can be configured on either routers or switches. Larger networks with a substantial number of remote site WAN connections may benefit from additional prioritization for traffic types other than voice (such as video and other streaming applications), and the more complex AutoQoS for the Enterprise is likely to be a better fit. Note that QoS for the Enterprise can be configured only on routers and not switches. We’ll start by going through the AutoQoS for VoIP configuration for both routers and switches followed by configuring AutoQoS for the Enterprise, while pointing out differences between the two implementation methods along the way.
Configuring AutoQoS for VoIP on a Router Configuring AutoQoS on routers is truly a magical thing to see. It seems magical because AutoQoS intelligently recognizes a network setup and appropriately configures multiple QoS settings. And when I say multiple, I mean it. The AutoQoS for VoIP command is entered while in config-if mode on any router interface you choose. The command to kick off the AutoQoS for VoIP process is auto qos voip. There is one optional keyword that can follow this command, trust. This keyword tells the router to trust the DSCP values that have been already marked on incoming packets. If the trust keyword is not used, the router uses NBAR and marks (or re-marks) packets. If you trust your endpoints and their
c12.indd 475
9/21/11 11:27:53 AM
Chapter 12
476
■
Configuring Quality of Service
QoS markings, then you should use trust. If not, then don’t include it and instead rely on NBAR. To show you how to configure AutoQoS for VoIP on a router, we will use Figure 12.1 as our example network. F I G U R E 1 2 .1
AutoQoS for VoIP on a router
CUCM Express
S0/0 Switch
Router-A
S0/0 256 Kbps
Router-B
Switch
We will configure the interface serial 0/0 of Router-A shown in the diagram. To show you what AutoQoS for VoIP will configure for our particular router, here is the current configuration on interface s0/0: Router-A#show run int s0/0 ! interface Serial0/0 bandwidth 256 ip address 192.168.1.1 255.255.255.0 encapsulation ppp clock rate 2000000
You can see that we have an enabled serial interface that has a set bandwidth of 256 Kbps. Additionally, the interface has an IP address and is set to use PPP as the transport mechanism. Now we can configure AutoQoS for VoIP. In our example, we will let the router use NBAR to mark packets with a DSCP value; we do that by not using the trust keyword in the auto qos voip command, as shown here: Router-A#configure terminal Router-A(config)#interface serial 0/0 Router-A(config-if)#auto qos voip Router-A(config-if)#end Router-A#
As soon as this command is entered on the serial 0/0 interface, the router kicks off a script to determine the best possible QoS configuration for this interface. The number of actual configurations made is fairly staggering. But don’t take my word for it: you can use
c12.indd 476
9/21/11 11:27:54 AM
Configuring QoS Policies Using AutoQoS
477
the show auto qos command on Router-A to see exactly what the router chose to configure as our QoS policy, as shown here: Router-A#show auto qos ! policy-map AutoQoS-Policy-UnTrust class AutoQoS-VoIP-RTP-UnTrust priority percent 70 set dscp ef class AutoQoS-VoIP-Control-UnTrust bandwidth percent 5 set dscp af31 class AutoQoS-VoIP-Remark set dscp default class class-default fair-queue ! class-map match-any AutoQoS-VoIP-Remark match ip dscp ef match ip dscp cs3 match ip dscp af31 ! class-map match-any AutoQoS-VoIP-Control-UnTrust match access-group name AutoQoS-VoIP-Control ! class-map match-any AutoQoS-VoIP-RTP-UnTrust match protocol rtp audio match access-group name AutoQoS-VoIP-RTCP ! ip access-list extended AutoQoS-VoIP-RTCP permit udp any any range 16384 32767 ! ip access-list extended AutoQoS-VoIP-Control permit tcp any any eq 1720 permit tcp any any range 11000 11999 permit udp any any eq 2427 permit tcp any any eq 2428 permit tcp any any range 2000 2002 permit udp any any eq 1719 permit udp any any eq 5060 !
c12.indd 477
9/21/11 11:27:54 AM
478
Chapter 12
■
Configuring Quality of Service
rmon event 33333 log trap AutoQoS description “AutoQoS SNMP traps for Voice Drops” owner AutoQoS rmon alarm 33333 cbQosCMDropBitRate.146.12938593 30 absolute rising-threshold 1 33333 falling-threshold 0 owner AutoQoS Serial0/0 ! interface Serial0/0 no ip address encapsulation ppp no fair-queue ppp multilink ppp multilink group 2001100115 ! interface Multilink2001100115 bandwidth 256 ip address 192.168.1.1 255.255.255.0 ppp multilink ppp multilink interleave ppp multilink group 2001100115 ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-UnTrust ip rtp header-compression iphc-format Router-A#
Our QoS configuration on Router-A now consists of the following:
Policy maps and class maps to classify and mark our voice and voice-related traffic
Access lists for VoIP RTCP and control packets
RMON settings to trigger alerts via SNMP based on thresholds
A PPP multilink configuration on the serial 0/0 interface along with LFI configurations
Compressed RTP configuration on the serial 0/0 interface
The PPP multilink LFI configuration in the previous example was configured because the router discovered that serial 0/0 had a bandwidth below 768 Kbps. As mentioned in Chapter 11, any WAN interface that is below 768 Kbps should be configured with link-efficiency techniques such as LFI and cRTP. We will discuss PPP multilink in more detail later in this chapter.
You can see that AutoQoS for VoIP configured four different classes with which to mark packets and enforce policy. Specifically, our voice (RTP) traffic will be tagged as DSCP EF and will have a strict priority queue of 70 percent of the total bandwidth of our 256 Kbps serial interface.
c12.indd 478
9/21/11 11:27:55 AM
Configuring QoS Policies Using AutoQoS
479
If we went ahead and performed AutoQoS on Router-B, the same QoS settings would be implemented there as well, and we would have a completely uniform QoS structure on either side of our WAN connection. Now that you’ve seen how AutoQoS for VoIP works on routers, let’s take a look at how to configure switches.
Configuring AutoQoS for VoIP on a Switch There are only three options for configuring AutoQoS on a switch interface using the auto qos voip command. Once you understand these three options, configuring QoS on your Cisco Catalyst will be a snap! Here is the output of the switch when configuring AutoQoS: Switch(config-if)#auto qos voip ? cisco-phone Trust the QoS marking of Cisco IP Phone cisco-softphone Trust the QoS marking of Cisco IP SoftPhone trust Trust the DSCP/CoS marking
Let’s look at the options to understand when each one should be used: You should use this option when you want to trust the QoS markings from your Cisco phone. Note that I said “Cisco” phone and not “IP” phone. Cisco uses CDP between the switch and phone to ensure that the device is indeed a phone and not some other device attempting to get a better classification for its traffic. Because CDP is Cisco proprietary, it works only when Cisco IP phones are connected or when other companies license CDP technology (such as Mitel IP Phones). You must also make sure that CDP is enabled both globally and on the access port your Cisco phone is connected to.
cisco-phone
This option is very similar to the cisco-phone option, except that it trusts the CoS/ToS markings on PCs that are running the Cisco IP Communicator software. The IP Communicator software runs CDP once again to ensure that the device is properly identified as a Cisco phone.
cisco-softphone
trust The trust option basically means that the switch will trust any CoS/ToS value received and treat the traffic accordingly. Be cautious when configuring this on access ports, because people “in the know” can manipulate the classification markings of data traffic on their PCs and have their data sent as priority traffic when it should be treated as normal traffic. But where the trust option should absolutely be used is between all of the switch and router interfaces that interconnect your network equipment. As soon as you set a location for your trust boundary, all other devices within that boundary can safely trust the CoS/ToS markings they receive.
That’s all there is to AutoQoS for VoIP on a switchport. Let’s use Figure 12.2 as our network example for configuring QoS on a production network. Assume that the Sales, Marketing, Management, and Voice VLANs are preconfigured on the network. Switchport Fa0/5 is configured to use VLAN 10 for data and VLAN 100 for voice traffic. Also assume that 802.1Q trunking is configured between the switch and the CUCM Express router.
c12.indd 479
9/21/11 11:27:55 AM
480
Chapter 12
F I G U R E 12 . 2
■
Configuring Quality of Service
AutoQoS for VoIP on a switch CUCM Express
Fa0/5
Fa0/1 Fa0/1 802.1Q Trunk Switch-B
Switch-A
Fa0/5
Trust boundary
We need to set our trust boundary. Let’s assume that we’ll trust the Cisco phones but not trust ordinary PCs. Therefore, our trust boundary is set at the phone, using the auto qos voip cicso-phone command. But fi rst, let’s view the current configuration of our interface using the show run interface fastEthernet 0/5 command, as shown here: Switch-A#sh run int fa0/5 Building configuration... Current configuration : 487 bytes ! interface FastEthernet0/5 switchport access vlan 10 switchport mode dynamic desirable switchport voice vlan 100
Now we will go into interface-configuration mode and configure AutoQoS to trust Cisco phones attached to Fa0/5. Switch-A#configure terminal Switch-A(config)#interface fastEthernet 0/5 Switch-A(config-if)#auto qos voip cisco-phone Switch-A(config-if)#end
Let’s see exactly what AutoQoS has configured on our port, using the show run interface fastEthernet 0/5 command a second time: Switch-A#sh run int fa0/5 Building configuration... Current configuration : 487 bytes ! interface FastEthernet0/5 switchport access vlan 10
c12.indd 480
9/21/11 11:27:56 AM
Configuring QoS Policies Using AutoQoS
481
switchport mode dynamic desirable switchport voice vlan 100 mls qos trust device cisco-phone mls qos trust cos auto qos voip cisco-phone wrr-queue bandwidth 10 20 70 1 wrr-queue min-reserve 1 5 wrr-queue min-reserve 2 6 wrr-queue min-reserve 3 7 wrr-queue min-reserve 4 8 wrr-queue cos-map 1 0 1 wrr-queue cos-map 2 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 priority-queue out spanning-tree portfast
You can see that the auto qos voip command actually configured all kinds of things on the interface, including trust settings, weighted round-robin (WRR) queuing policies, and priority queuing specifically for VoIP traffic. The important thing you need to identify is that we are trusting the Cisco phone with the auto qos voip cisco-phone entry. Once the trust boundary is set, we know that the interfaces connecting our Layer 2 switch to the CME router should be configured using the auto qos voip trust command. To show you what is actually configured using the AutoQoS command, we will do a show run interface fa0/1 command to view the initial configuration settings: Switch-A#show run interface fa0/1 Building configuration... Current configuration : 436 bytes ! interface FastEthernet0/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 10,20,100 switchport mode trunk
Now we will configure AutoQoS to trust markings passing through Fa0/1: Switch-A#configure terminal Switch-A(config)#interface fastEthernet 0/1 Switch-A(config-if)#auto qos voip trust Switch-A(config-if)#end
c12.indd 481
9/21/11 11:27:56 AM
482
Chapter 12
■
Configuring Quality of Service
You can now view our new running configuration for our switch uplink to see the differences between the auto qos voip trust configurations and the auto qos voip cisco-phone output: Switch-A#show run interface fa0/1 Building configuration... Current configuration : 436 bytes ! interface FastEthernet0/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 10,20,100 switchport mode trunk mls qos trust cos auto qos voip trust wrr-queue bandwidth 10 20 70 1 wrr-queue min-reserve 1 5 wrr-queue min-reserve 2 6 wrr-queue min-reserve 3 7 wrr-queue min-reserve 4 8 wrr-queue cos-map 1 0 1 wrr-queue cos-map 2 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 priority-queue out
Notice that from a QoS configuration standpoint, the only difference between the trust and cisco-phone configuration is the auto qos voip trust command. After configuring AutoQoS for VoIP on the switch, you will also fi nd a couple of global configurations in the running configuration shown here: Switch-A#show run | include mls qos Building configuration... mls qos map cos-dscp 0 8 16 26 32 46 48 56 mls qos
The mls qos command is what enables QoS on our switch. The mls qos map cos-dscp command followed by DSCP numbers instructs the switch to map Layer 2 CoS values that are read by the switch coming from the Cisco phone. The switch will adjust DSCP markings according to the CoS values. Remember that CoS uses eight different markings. A CoS of 0 will be mapped to a DSCP value of 0, while a CoS of 5 (which is what voice frames are tagged with) will use a DSCP value of 46, which corresponds to an AF PHB class of EF. We will discuss CoS-to-DSCP mappings and how to modify them later in this chapter.
c12.indd 482
9/21/11 11:27:56 AM
Configuring QoS Policies Using AutoQoS
483
The configuration of the opposite-end switch in our example diagram should be identical. Once you’ve completed configuring all the interfaces, congratulations; you’ve successfully implemented QoS for voice on your switch-based LAN.
Configuring AutoQoS for the Enterprise on a Router If your network requires a more generalized QoS approach that classifies and marks traffic other than simply voice, the AutoQoS for the Enterprise method might be the right choice for you. In addition to identifying, classifying, and queuing voice traffic with LLQ, AutoQoS for the Enterprise classifies other forms of application traffic into possibly 10 different queues. You might remember from Chapter 11 that the Cisco QoS baseline model has 11 different classes. So why does AutoQoS for the Enterprise have only up to 10 queues? The “critical” classification is the missing class that AutoQoS for the Enterprise does not attempt to use. This is because the tool has no way of knowing what your particular business or organization deems as critical application flows. If you wish to use the critical classification and markings, you’ll have to go back and configure it manually by specifying what traffic you deem to be critical. Keep in mind that AutoQoS for the Enterprise will not use this class by default. The other 10 classes are available and may or may not be used depending on what type of traffic the router sees and classifies according to Cisco best-practice policies. AutoQoS for the Enterprise will also identify low-speed WAN links and configure compression and link-efficiency techniques on interfaces that are less than 768 Kbps (just like AutoQoS for VoIP). Unlike the AutoQoS for VoIP method, AutoQoS for the Enterprise is a two-phased approach: 1.
The AutoQoS autodiscovery phase is started when a router monitors traffic passing through a specific interface. The router monitors its local interfaces and collects baseline information about the data flows it sees, and attempts to classify them into one of 10 possible classes. Either discovery can either be made using NBAR, or the router can be set to trust the DSCP markings of packets and classify them based on the markings that packets currently have.
2.
Once the AutoQoS autodiscovery phase has had sufficient time to collect data and classify it, AutoQoS for the Enterprise automatically creates QoS templates for classification, marking, queuing, and link efficiency. A network administrator should review the templates, and enable them during the AutoQos installation phase.
Let’s fi rst go through the AutoQoS autodiscovery phase and then see how we can verify and implement the recommended settings in the AutoQoS installation phase. We will use the network shown in Figure 12.3 as our example network and configure Router-A with AutoQoS for the Enterprise.
c12.indd 483
9/21/11 11:27:57 AM
484
Chapter 12
F I G U R E 12 . 3
■
Configuring Quality of Service
AutoQoS for the Enterprise
Desktop computers
IP phones IP phones
S0/0
Application servers
Switch
Router-A
1540 Kbps
Desktop computers
S0/0 Router-B
Switch
CUCM
Configuring the AutoQoS Discovery Phase As you can see from Figure 12.3, we have a fairly large network with multiple application servers that we would like to be able to categorize, mark, and queue accordingly. We will focus on the Router-A configuration, but keep in mind that Router-B must go through the same process. In the AutoQoS discovery phase we will enable the discovery of traffic on our serial 0/0 interface by using the auto discovery qos command. This command will use NBAR to discover and classify traffic. Any traffic that NBAR does not have in its database will be placed into the best-effort queue. If we wanted to use and trust DSCP markings that packets may already be configured with, we would use the auto discovery qos trust command. This would disable NBAR discovery and solely rely on DSCP marking for classification. In our example, we will use NBAR for classification, as shown here: Router-A#configure terminal Router-A(config)#interface serial 0/0 Router-A(config-if)#auto discovery qos Router-A(config-if)#end Router-A#
When you turn on autodiscovery, it runs in the background while the interface operates normally, so you should not be concerned about it interfering with traffic flows. You’ll notice in the interface configuration that there is an entry that has auto discovery qos enabled, as shown here: Router-A#show run interface s0/0 interface Serial0/0 bandwidth 1540 ip address 192.168.1.1 255.255.255.0 encapsulation ppp auto discovery qos clock rate 2000000
c12.indd 484
9/21/11 11:27:57 AM
Configuring QoS Policies Using AutoQoS
485
The duration of the AutoQoS autodiscovery phase is completely up to your discretion, although it is highly recommended that you run it for several days. In many situations, a complete week’s worth of data discovery is highly recommended in case you have some applications that only run during specific times of the day or days of the week. While the autodiscovery phase is going on, you can use the show auto discovery qos command while in privileged EXEC mode to see what traffic the router has identified and the suggested configuration policy commands according to Cisco best practices, as shown in this example: Router-A#show auto discovery qos Serial0/0 AutoQoS Discovery enabled for applications Discovery up time: 1 hours, 12 minutes AutoQoS Class information: Class Voice: Recommended Minimum Bandwidth: 519 Kbps/52% (PeakRate). Detected applications and data: Application/ AverageRate PeakRate Protocol (kbps/%) (kbps/%) ---------------------------rtp audio 3/<1 517/52 Class Interactive Video: No data found. Class Control: Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate). Detected applications and data: Application/ AverageRate PeakRate Protocol (kbps/%) (kbps/%) ---------------------------h323 0/0 75/7 rtcp 0/0 7/<1 Class Streaming Video: No data found. Class Transactional: No data found. Class Bulk: Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate). Detected applications and data: Application/ AverageRate PeakRate Protocol (kbps/%) (kbps/%) ----------------------------
c12.indd 485
Total (bytes) -----------703323
Total (bytes) -----------30212 1540
Total (bytes) ------------
9/21/11 11:27:58 AM
486
Chapter 12
■
Configuring Quality of Service
ftp 0/0 330/31 74480 Class Scavenger: No data found. Class Management: Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate). Detected applications and data: Application/ AverageRate PeakRate Total Protocol (kbps/%) (kbps/%) (bytes) --------------------------------------dhcp 0/0 84/8 115543 ldap 0/0 169/16 55434 Class Routing: Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate). Detected applications and data: Application/ AverageRate PeakRate Total Protocol (kbps/%) (kbps/%) (bytes) --------------------------------------icmp 0/0 2/<1 300 Class Best Effort: Current Bandwidth Estimation: 355 Kbps/34% (AverageRate). Detected applications and data: Application/ AverageRate PeakRate Total Protocol (kbps/%) (kbps/%) (bytes) --------------------------------------unknowns 336/32 99650/97 949276 http 14/1 15557/15 41545 Suggested AutoQoS Policy based on a discovery uptime of 1 hours, 12 minutes: ! class-map match-any AutoQoS-Voice match protocol rtp audio ! class-map match-any AutoQoS-Signaling match protocol sip match protocol rtcp ! class-map match-any AutoQoS-Bulk match protocol exchange policy-map AutoQoS-Policy class AutoQoS-Voice priority percent 1 set dscp ef
c12.indd 486
9/21/11 11:27:58 AM
Configuring QoS Policies Using AutoQoS
487
class AutoQoS-Signaling bandwidth remaining percent 1 set dscp cs3 class AutoQoS-Bulk bandwidth remaining percent 1 random-detect dscp-based set dscp af11 class class-default fair-queue Router-A#
From this output, you can see that the discovery process has identified several different data flows using NBAR and classified them into one of the 10 possible classes according to Cisco best practices. Notice that not all 10 classes are used in the example. Your specific network may use all or only a few of the possible classes. Additionally, at the end of the command, you can see the recommended configuration settings the router will implement during phase 2 of the AutoQoS for the Enterprise process. This gives you an opportunity to review the settings to make sure they perform the QoS functions you desire.
Don’t Forget to Rediscover Your Network Jeremy is a network consultant working on a WAN project to upgrade a company’s fractional 512 Kbps PRI data connections to full 1.536 Kbps PRI speeds. The process would help alleviate some of the congestion that the 512 Kbps circuits were previously experiencing. The upgrade to the full PRI speeds went smoothly, but Jeremy noticed that the AutoQoS policies did not automatically update. All of the cRTP compression and LFI configurations remained on the configuration. This was an important lesson for Jeremy to learn. Now he knows that when bandwidth upgrades occur, the AutoQoS for the Enterprise discovery process must be completely redone so the process can suggest the optimal QoS configuration policies for the newly upgraded network. After running the AutoQoS process for a week as recommended, Jeremy found that the AutoQoS process correctly saw the WAN interface as a full PRI and removed the cRTP and LFI settings, which are recommended only for slower links.
c12.indd 487
9/21/11 11:27:58 AM
488
Chapter 12
■
Configuring Quality of Service
Configuring AutoQoS Implementation Phase After you have completed the discovery phase and reviewed the configuration that AutoQoS for the Enterprise has recommended specifically for our network, it’s time to apply those changes. In our example, it is simply a matter of going back into the serial 0/0 interface and issuing the auto qos command, as shown here: Router-A#configure terminal Router-A(config)#interface serial 0/0 Router-A(config-if)#auto qos Router-A(config-if)#end Router-A#
This command applies all of the QoS classification, marking, and queuing configurations. In addition, it will configure any link-efficiency techniques for low-speed WAN interfaces when necessary.
After you complete the implementation phase, you should go ahead and disable the AutoQoS discovery process on any interfaces it is currently enabled on. To do this, simply go into config-if configuration mode and issue the no auto discovery qos command. This will end the data-collection process and delete all data-collection information on the router for that interface.
To review the complete list of QoS settings implemented on a router, you can issue the same show auto qos command as we did with AutoQoS for VoIP. This command again shows all of the class maps, policy maps, service policies, and link-efficiency settings on the local router. If you want to go in and manually modify or add any QoS policies, you can do so using the standard CLI method. In the next section, we will step away from the fully automated QoS policy-creation method and look at a more robust, yet fully structured configuration tool called Modular QoS CLI (MQC).
Configuring QoS Policies Using MQC You’ve seen the power of AutoQoS and how it can provide sound QoS policies for most networks. But sometimes network administrators want to control the configuration process completely. If this is the case, they typically will choose to use the Modular QoS CLI (MQC) method. This is also known as class-based (CB) QoS. Although there are more configuration steps involved, MQC lets administrators decide for themselves how data flows should be classified and marked, and what queuing policies to use. MQC uses a structured three-step command process, as shown here:
c12.indd 488
9/21/11 11:27:59 AM
Configuring QoS Policies Using MQC
489
Class maps are used to configure different traffic class types. This is your matching function. Keep in mind that a packet will be matched by only one class. The matching order is set by the appearance of classes in the policy map. Therefore, it is important to configure your most specific matching statements fi rst.
class-map
policy-map Policy maps are used to associate a traffic class type with one or more QoS operations. This is your set or do function.
A service policy is used to apply a policy to router interfaces, including subinterfaces and virtual circuits. The service policies can be applied inbound or outbound depending on the need.
service-policy
The beauty of MQC lies in its highly scalable and modular nature. Classifications can be used within multiple policies and applied to multiple interfaces. Figure 12.4 shows how one or more class maps can be placed in a policy map. Then that policy map is applied to an inbound or outbound (or both) interface using the service-policy command. F I G U R E 12 . 4
MQC structure
class-map
service-policy
policy-map
Class 1
Policy
Class 2
Interface Class 3
Class-map match statements can also match against other class-maps. That is, you can have nested class maps. Nested class maps and policy maps are fairly common and are configured similarly. An example of a nested policy map can be found later in this chapter.
Now that you have a solid foundation in the structure of MQC, we will try out the three-step configuration process, using Figure 12.5 as our example network. F I G U R E 12 . 5
MQC network example
S0/0 IP WAN Router-A
c12.indd 489
9/21/11 11:27:59 AM
490
Chapter 12
■
Configuring Quality of Service
Configuring Class Maps The fi rst step of any QoS policy is to segment various types of traffic into classes. Using MQC, this process is kicked off by using the class-map command while in global configuration mode. You are also required to assign the new class a unique name to identify it. Additionally, two optional keywords can be entered when creating a new class map: match-any (default) This command states that any single match statement contained within the class map can be used to match a packet to that class. If you have multiple match statements configured within the class, your packet needs to meet only one of the requirements.
This command states that a packet must adhere to all match statements contained within the class map. Therefore if you have three match statements in a match-all class, your packet must meet all three distinctions to be part of that class. match-all
Again, note that the match-any and match-all keywords are optional. If the class-map command simply has a unique identifier in the statement and no keyword, that class map is a match-any class map. In our fi rst example, we will configure a class map named class-1, where we want to trigger on any one match statement: Router#configure terminal Router(config)#class-map class-1 Router(config-cmap)#
Notice that we did not include a match-any or match-all keyword. This means that this class map is a match-any map. Also note that we are placed into config-cmap mode. This is where we can configure our match statements. The process of configuring match statements is straightforward. You use the match command followed by any of the following match options listed in Table 12.1. Keep in mind that the available options vary depending on the hardware type and version of IOS you are running: TA B L E 1 2 .1
c12.indd 490
Class-map match statement options
Option
Description
access-group
Match against an access control list (ACL) configured on the local router.
any
Match any packet.
class-map
Match against another class map.
9/21/11 11:28:00 AM
Configuring QoS Policies Using MQC
491
Option
Description
cos
Match against the packet’s COS value.
destination-address mac
Match against the packet’s destination MAC address.
discard-class
Match against the packet’s discard class (within DSCP).
dscp
Match against the packet’s DSCP value for both IPv4 and IPv6 packets using either DSCP values (1-63) or PHB values.
flow
Match against the packet’s flow QoS parameters.
fr-de
Match against the Frame Relay discard eligibility (DE) bit.
fr-dlci
Match against the Frame Relay DLCI identifier.
input-interface
Match against the input interface the packet came into the router on.
ip
Match against specific IP values such as RTP, IPv4 DSCP, and IPv4 precedence.
mpls
Match against specific multi-protocol label-switching values within the packet.
not
Negate a match statement.
packet
Match against packet size (for v4 or v6).
precedence
Match against the packet’s IP Precedence value for both IPv4 and IPv6 packets.
protocol
Match against the packet’s protocol with NBAR.
qos-group
Match against a preconfigured QoS group.
source-address mac
Match against the packet’s source MAC address.
vlan
Match against the VLAN assignment.
In our fi rst example, we will create a class map named voice and use it to classify any traffic marked with either an IP Precedence of 5 or a DSCP of 46: Router#configure terminal Router(config)#class-map voice
c12.indd 491
9/21/11 11:28:01 AM
492
Chapter 12
■
Configuring Quality of Service
Router(config-cmap)#match precedence 5 Router(config-cmap)#match dscp 46 Router(config-cmap)#end Router#
As a result, any packet that crosses an interface where this class map is applied will be put into the voice class. Let’s configure a second class map that uses an access-list as well as DSCP PHB values CS6 and CS2 for our network control flows. First we’ll configure an ACL to defi ne what IP addresses to match against. Then we will create our new match-all class map named network and use the appropriate match statements to classify our traffic: Router#configure terminal Router(config)#access-list 10 permit 10.0.1.0 Router(config)#access-list 10 permit 10.0.2.0 Router(config)#access-list 10 permit 10.0.3.0 Router(config)#access-list 10 permit 10.0.4.0 Router(config)#class-map match-all network Router(config-cmap)#match access-group 10 Router(config-cmap)#match dscp cs2 cs6 Router(config-cmap)#end Router#
0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255
Notice that you can match multiple values for DSCP (up to eight) on a single line. Similarly, you can use the precedence command to match one of eight IP precedence values on a single match statement.
Lastly, you will see how to use class maps to classify traffic using NBAR. In this example, we will create a new match-any class map named web and use NBAR to identify HTTP and HTTPS traffic: Router#configure terminal Router(config)#class-map web Router(config-cmap)#match protocol http Router(config-cmap)#match protocol secure-http Router(config-cmap)#end Router#
So as you can see, there are multiple ways to classify traffic, using all sorts of differentiation techniques, including ACLs, IP precedence/DSCP values, and NBAR. Now that we have classified some traffic, let’s see how we can apply QoS policies using the policy-map command.
c12.indd 492
9/21/11 11:28:01 AM
Configuring QoS Policies Using MQC
493
Configuring Policy Maps To apply various QoS policies to classes we have created, we use the policy-map global configuration command followed by a unique name for the policy. We will then be placed into config-pmap configuration mode. Here, we can identify a class map by its unique name. We will then be put into config-pmap-c configuration mode. It is within this configuration mode that QoS policies are applied. Table 12.2 lists all of the QoS policy options available, with their descriptions. Again, the options will vary based on the hardware and IOS version you are running. TA B L E 1 2 . 2
c12.indd 493
QoS policy-map options
Option
Description
bandwidth
Sets the CBWFQ bandwidth by Kbps, percent of link, or percent of remaining bandwidth on the link.
compression
Enables compression on all packets.
drop
Drops all packets.
log
Logs IPv4 and ARP packets.
netflow-sampler
Performs NetFlow actions.
no
Negates an option.
police
Enables traffic-policing policies.
priority
Sets strict priority queuing either by Kbps or bandwidth percent of the link.
queue-limit
Set the maximum tail-drop threshold.
random-detect
Enables Random Early Detection (RED) or Weighted Random Early Detection (WRED) as the drop policy.
service-policy
Used to configure nested policy maps.
set
Sets QoS values such as IP Precedence, COS and DSCP values, DE bits, and discard class values.
shape
Enables traffic-shaping policies.
9/21/11 11:28:02 AM
494
Chapter 12
■
Configuring Quality of Service
We will use our three previously configured class maps and apply them to a single policy map in our example. We will call the policy policyWAN and apply specific traffic condition settings for each class, as shown here: Router#configure terminal Router(config)#policy-map policyWAN Router(config-pmap)#class voice Router(config-pmap-c)#priority percent 70 Router(config-pmap-c)#exit Router(config-pmap)#class network Router(config-pmap-c)#bandwidth percent 5 Router(config-pmap-c)#random-detect dscp-based Router(config-pmap-c)#exit Router(config-pmap)#class web Router(config-pmap-c)#set dscp 0 Router(config-pmap-c)#end Router#
In this example you can see that we gave our voice traffic a strict-priority queue of 70 percent of the total link bandwidth. Next, we chose to use CBWFQ (5 percent of the total bandwidth), and we also turned on WRED. Finally, our web traffic is simply handed a DSCP value of 0. Next, you will learn how to apply our policies to interfaces using the service-policy interface configuration command.
The Parent and Child Relationship Nathan was working on configuring classes and policies using MQC. He wanted an elegant way to apply CBWFQ on a wide range of traffic (a class named big) and enable traffic policing on a subset of that class (a class named small). After looking over the MQC policy-map options, Nathan found the service-policy command option with the policy-map that allows for nested classes. Therefore, Nathan could create two policy maps: one “parent” map that could set the priority for all traffic and a “child” map that would use the parent priority settings but also enable traffic policing, as shown in this example:
Router#configure terminal Router(config)#policy-map child Router(config-pmap)#class big Router(config-pmap-c)#priority 30 Router(config-pmap-c)#exit
c12.indd 494
9/21/11 11:28:02 AM
Configuring QoS Policies Using MQC
495
Router(config-pmap)#exit Router(config)#policy-map parent Router(config-pmap)#class small Router(config-pmap-c)#police 256000 conform-action transmit exceed-action drop Router(config-pmap-c-police)#exit Router(config-pmap-c)#service-policy child Router(config-pmap-c)#end Router# Now Nathan has a single policy map named parent that polices all traffic and at the same time applies PQ to a subset policy map named child.
Applying Policy Maps to Interfaces with a Service Policy The fi nal step in the MQC process, after we have defined traffic in classes and configured QoS policies, is to apply those policies to an interface. To do this, we navigate to config-if configuration mode of the interface we choose to apply our policy on, and then issue the service-policy command. We must then choose to specify whether we want the policy to apply for traffic coming into or out of the interface, using the input or output keywords. Keep in mind that an interface can have policies applied both inbound and outbound if you choose, but anything that involves the use of queues can only be applied outbound. In our example network we apply our service policy outbound on interface s0/0: Router#configure terminal Router(config)#interface s0/0 Router(config-if)#service-policy output policyWAN Router(config-if)#end Router#
That’s all there is to MQC! To recap, you must perform the following MQC steps: 1.
Configure a class map.
2.
Configure a policy map.
3.
Apply a policy map to an interface (input or output) using a service policy.
Next you’ll learn how to verify our QoS configurations and policy mechanisms using various show commands.
MQC QoS Configuration Show Commands In this section, we’ll cover three useful show commands to verify a class-based QoS policy that was configured using MQC. The last of these commands, show policy-map interface, can be used to verify packet matching and queue usage on interfaces configured with QoS policies.
c12.indd 495
9/21/11 11:28:03 AM
496
Chapter 12
■
Configuring Quality of Service
show class-map Use this command to quickly view all of the class maps configured on your local router. Notice that the DSP entries list both the PHB values and DSCP values together, as shown in this example: Router#show class-map Class Map match-any class-default (id 0) Match any Class Map match-all web (id 3) Match protocol http Match protocol secure-http Class Map match-all voice (id 1) Match precedence 5 Match dscp ef (46) Class Map match-all network (id 2) Match access-group 10 Match dscp cs2 (16) cs6 (48)
show policy-map This command is useful when you want to review all policy-map configurations on a router, as shown here: Router#show policy-map Policy Map policyWAN Class voice Strict Priority Bandwidth 70 (%) Class network Bandwidth 5 (%) Max Threshold 64 (packets) Class web Set dscp default
show policy-map interface Lastly, the show policy-map interface command, followed
by an interface that has a service policy applied to it, will show which policy and class maps are in force, along with packet-matching statistics for traffic that has passed through the interface. This is a very useful command to verify that your policies are operating correctly, as demonstrated in the following example output: Router#show policy-map interface s0/0 Serial0/0 Service-policy output: policyWAN Class-map: voice (match-all) 0 packets, 0 bytes
c12.indd 496
9/21/11 11:28:03 AM
Configuring QoS Policies Using MQC
497
5 minute offered rate 0 bps, drop rate 0 bps Match: precedence 5 Match: dscp ef (46) Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 70 (%) Bandwidth 31500 (kbps) Burst 787500 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: network (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 10 Match: dscp cs2 (16) cs6 (48) Queueing Output Queue: Conversation 265 Bandwidth 5 (%) Bandwidth 2250 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: web (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps Match: protocol http Match: protocol secure-http QoS Set dscp default Packets marked 0 Class-map: class-default (match-any) 25 packets, 600 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Router#
Notice that at the end of this command is a map identified as class-default. While we did not configure this class map, it is always included anytime you apply a policy to an interface. This class map is used for all other traffic that does not match a configured class map.
c12.indd 497
9/21/11 11:28:03 AM
498
Chapter 12
■
Configuring Quality of Service
Now that you understand how to configure QoS using MQC, we will take a look at how to configure RED and WRED, which as you learned in Chapter 11 are congestion-avoidance techniques for bottlenecked links.
Configuring Congestion-Avoidance Techniques Random Early Detect (RED) is a congestion-avoidance technique that is set into motion when queues begin to fill up, and packets need to be discarded on bottleneck interfaces. Before the queue buffer completely fills and sensitive traffic begins to suffer from TCP synchronization, you can use RED to drop random packets in an attempt to have TCP applications back off their current TCP window rates and send packets to their destination more slowly. TCP synchronization often occurs when queue buffers fill up and begin dropping packets, because the multiple TCP sessions will all back off their TCP window size at the same time. When this happens, you’ll see a seesaw effect in the interface traffic. All of the TCP transmissions slow down simultaneously and then begin speeding up simultaneously, and ultimately buffers overflow over and over again. To avoid this, RED will randomly drop packets in an attempt to have only some TCP sessions adjust their windowing downward. When it does this, you’ll see a much more even transport flow across an interface. Weighted RED, or simply WRED, is Cisco’s proprietary advancement of RED to make the dropping of packets a little less random by selecting packets that are marked lower than others. WRED can be configured directly on the interface, but we will use class-based WRED (CB-WRED) for our examples. Also keep in mind that CBWFQ must be configured in conjunction with WRED within a policy map. We can configure WRED to look for either IP Precedence or DSCP markings, and we can determine the probability of dropped packets based on these values that we can classify. To do this, we must have our class maps defined and create a policy map. Within the policy map we reference the class map of traffic we wish to apply WRED on. We can then issue the random-detect command. From here we have some decisions to make. First, do we want WRED to used IP Precedence or DSCP markings? If we want to use IP Precedence, we enter the prec-based keyword. If we wish to use DSCP values, we use the dscp-based keyword. For example, let’s assume we’ve created a class map named tcp-traffic that classifies a group of TCP data packets flowing through an interface. We will create a policy map for this class and give it a CBWFQ percent of 10. Additionally, we will configure WRED to use DSCP markings, as shown here: Router(config-pmap)#class tcp-traffic Router(config-pmap-c)#bandwidth percent 10 Router(config-pmap-c)#random-detect dscp-based Router(config-pmap-c)#
At this point, we are ready to tell WRED manually how we want our packets to be dropped. To do this, we again use the random-detect command followed by dscp
c12.indd 498
9/21/11 11:28:04 AM
Configuring Congestion-Avoidance Techniques
499
(or precedence if using IP Precedence). We then need to configure the following four WRED settings: DSCP or IP Precedence Value
This is the marking that you want to specify for WRED.
Minimum Threshold (Number Of Packets) This sets the number of packets that must be in the queue before the router starts to discard packets with a specific DSCP or IP Precedence marking. Maximum Threshold (Number Of Packets) This sets the maximum number of packets that can be in the queue before all other packets are dropped. Mark Probability Denominator This is a proportion of the number of packets that are dropped when the queue maximum threshold is reached (but not yet surpassed). This can be really confusing, so we will use a visual diagram depicting the different WRED thresholds, shown in Figure 12.6. F I G U R E 12 .6
WRED packet drop procedure
Packet drop probability
100% packet drop Packets go from a portion being dropped to 100% dropped after the maximum threshold is reached. Mark probability denominator
0% packet drop Minimum threshold
Maximum threshold
Queue size
As you can see from the diagram, all packets are sent to a queue until the minimum threshold is reached. When the number of packets in a queue is between the minimum and maximum, some packets are queued and others are dropped. The number of dropped versus queued packets increases until it reaches the maximum threshold. Once the number of packets exceeds the maximum threshold, you see that the portion of dropped packets becomes 100 percent, and no packets are queued until the number of queued packets drops below the maximum threshold. So to show you an example of this, we will complete our configuration process by defining minimum, maximum, and mark-probability numbers for the three DSCP values shown here: Router(config-pmap-c)#random-detect dscp af13 25 100 4 Router(config-pmap-c)#random-detect dscp af12 30 100 4 Router(config-pmap-c)#random-detect dscp af11 35 100 4
c12.indd 499
9/21/11 11:28:04 AM
500
Chapter 12
■
Configuring Quality of Service
Looking at DSCP value AF11, you see that we have a minimum threshold of 35 packets. Once a queue reaches 25 packets, WRED will begin dropping packets marked with a value of AF13. WRED will continue dropping packets more proportionally up until the queue reaches 100 packets. Right at this point, when there are 100 packets waiting in the queue, the probability of an AF13 packet being dropped is 1 in 4, because the mark probability indicator is set to 4. That means that 25 percent of AF11 packets will be dropped when there are 100 packets waiting in the queue. If the queue were to exceed 100 packets, WRED would begin dropping all packets. The same is true for the configurations for AF12 and AF11 as well, although their minimum thresholds are different. Next, let’s look at how we can configure class-based traffic policing and shaping to help condition and control traffic rates.
Configuring Class-Based Traffic Policing and Shaping QoS techniques such as priority queuing (PQ) and class-based weighted fair queuing (CBWFQ) focus on setting minimum-bandwidth requirements for certain types of traffic. While this is important, sometimes it is just as important to set maximum-bandwidth levels for traffic flows as well. This is especially critical when dealing with traffic that can handle dropped packets and still function. On Cisco routers, there are two methods for configuring maximum levels of traffic, known as traffic policing and traffic shaping. We covered the basics of these two methods and their differences in Chapter 11. In this section we will fi rst examine the token bucket mechanism that both traffic policing and shaping use. Next we’ll show how to configure traffic policing, which is the stricter of the two options. Last, we will go on to configure traffic shaping, which utilizes queues to slow down TCP flows.
Understanding Token Buckets Traffic policing and shaping use the concept of token buckets to manage traffic. The token bucket is used to regulate data in a flow to manage overall bandwidth of an interface. The token bucket mean rate equation defi nes the average (mean) rate of transfer for traffic on a specific interface. The three components for determining token bucket rates are as follows: Committed Information Rate (CIR) This is the average amount (in bps) of data that can be forwarded out of an interface. The mean rate for policing and shaping is commonly represented in bps. Burst Conforming Size (Bc) This is a number in bits that tells us how much traffic can be sent on a token within a specific time interval without disrupting other traffic. Time Interval (Tc)
c12.indd 500
This number tells us the time in seconds allowed for a burst of traffic.
9/21/11 11:28:05 AM
Configuring Class-Based Traffic Policing and Shaping
501
The equation to determine the mean rate is: CIR ⫽ Bc / Tc
Alternatively, this equation could be reworked to find either Tc or Bc if the CIR is known. For example, to find the time interval, we would use the following equation: Tc ⫽ Bc / CIR
For example, let’s say we have 16000 bits worth of tokens of burst traffic (Bc) moving in and out of the token bucket every 250 ms. We would see a CIR of the following: CIR ⫽ 16000 / 0.25 CIR ⫽ 64000 bps or 64 Kbps Using a traffic-policing example, the maximum traffic rate for this interface cannot go over 64 Kbps or it will either be dropped or discarded. Policed traffic that is at or below this rate is our burst-conforming (Bc) traffic. Any data flows that go above the CIR are called burst-exceeding (Be) traffic. Let’s take a closer look at the token bucket itself. The bucket always has a fi xed capacity size. If the bucket completely fills up, all new tokens are dropped. Tokens are metaphors used to describe a router’s permission for a source device to send a specified number of bits out to the network. There must be enough tokens to send a complete IP packet. These tokens move in and out of the token bucket at a rate specified by the router. If the bucket does not contain enough tokens to send a packet, one of two things happens, depending on whether you are using traffic policing or traffic shaping: Not Enough Tokens: Traffic Policing When there are not enough tokens to send a packet with traffic policing, the packet is either dropped or marked with a new DSCP or IP Precedence value and then forwarded on. Not Enough Tokens: Traffic Shaping When there are not enough tokens to send a packet with traffic shaping, the packet is placed into a queue and waits until enough free tokens are available. Let’s next examine the different traffic-policing bucket types and how to configure them.
Understanding Traffic-Policing Token Buckets Traffic policing can use a single bucket, dual bucket with a single rate, or dual bucket with dual rates. The single bucket has only the Bc bucket to work with. Figure 12.7 shows the singlebucket method.
c12.indd 501
9/21/11 11:28:05 AM
502
Chapter 12
F I G U R E 12 .7
■
Configuring Quality of Service
A single token bucket Token flow (CIR) Exceed-action performed on these tokens
Exceeding the CIR Bc
Conform-action performed on these tokens
As you can see from Figure 12.7, there are two possible outcomes for single-bucket traffic: Conform-action If the number of bytes in the packet is equal to or less than the number of token bytes available in the bucket, the traffic conforms to the rules. The bucket tokens are used to remove the conforming data from the bucket, and specific actions are performed on that data that meet the conform rules. One of these actions is commonly a forward action, so traffic can move to the next hop to their destination. Exceed-action If the number of bytes in the packet is greater than the number of token bytes available in the bucket, the traffic exceeds the rule limits. The exceeding data remains in the token bucket, and specific actions are performed on the data that exceed conform rules. In a dual-bucket, single-rate model, there is a burst conform (Bc) bucket and a burst exceed (Be) bucket, as shown in Figure 12.8. The Bc bucket is used fi rst, and any exceeding traffic that fits into the Be bucket will be categorized and handled differently. If the exceeding traffic does not fit into the Be bucket, it is considered to be in violation. F I G U R E 12 . 8
Dual-bucket, single-rate model
Token flow (CIR)
Violate-action performed on these tokens
Exceeding the CIR Bc Be
Conform-action performed on these tokens
c12.indd 502
Exceed-action performed on these tokens
9/21/11 11:28:06 AM
Configuring Class-Based Traffic Policing and Shaping
503
Here are the three specific outcomes of traffic using the dual-bucket, single-rate method: Conform-action Just as in the single-bucket method, if the number of bytes in the packet is equal to or less than the number of token bytes available in the Bc bucket, the traffic conforms to the rules and the conformed traffic is handled accordingly. Exceed-action If the packet is higher than the CIR and cannot fit into the fi rst Bc bucket, it exceeds the limit. However, there is a second bucket that it can possibly fit into. This is the Be bucket. If the CIR overflow packet data can fit inside this bucket, it is classified as an exceed-action traffic type and specific actions can be performed on this data. Violate-action If the number of overflow bytes in the packet is greater than the number of token bytes available in the Be bucket, the traffic is considered to be in violation of the policing rules. The data remains in the bucket and specific actions can be performed on this data. The default action here is to drop, and please note that not all hardware can modify the violate-action. Finally, we have a dual-bucket, dual-rate method, as shown in Figure 12.9. F I G U R E 12 . 9
Dual-bucket, dual-rate method
Token flow (PIR) Exceeding the PIR
Violate-action performed on these tokens
Token flow (CIR) Exceed-action performed on these tokens
Exceeding the CIR
Conform-action performed on these tokens
c12.indd 503
9/21/11 11:28:06 AM
504
Chapter 12
■
Configuring Quality of Service
You’ll notice that in this situation, there are two different traffic rates. We have our standard CIR and a second rate called the peak information rate (PIR). When a packet arrives at an interface, the PIR bucket is checked first to see if there are enough tokens available for the packet. If there are not enough tokens, the packets fall into the violate-action category. If there are enough PIR tokens available, that is good, but it does not mean the traffic conforms to the rules yet. The packet is then checked against the CIR bucket to see if there are enough tokens in this bucket to transmit the traffic. If so, the traffic does indeed meet the conform-action rules; if not, the traffic is considered to exceed the CIR limits and must abide by the exceed-action rules. Here are the possible token outcomes for the dual-bucket, dual-rate method: Conform-action If the number of bytes in the packet is equal to or less than the number of token bytes available in the Bc bucket, the traffic conforms to the rules and the conformed traffic is handled accordingly. Exceed-action If the packet is higher than the CIR and cannot fit into the fi rst Bc bucket, it exceeds the limit. However, if there are enough tokens in the PIR bucket, that packet is considered to have exceeded the conform limit and abides by the exceed-action rules. Violate-action If there are not enough tokens to handle the packet in the conform or exceed buckets, that traffic is considered to be in violation and abides by the violate-action rules. Having two different traffic rates allows for the following benefits:
Improved bandwidth manageability
Sustained (non-bursty) excess traffic rates
Preferred rate limiting on network edges for packet conforming and marking
Configuring Class-Based Traffic Policing With class-based traffic policing, we can manipulate packets and data flows in one of the two following ways:
Setting a rate that limits (or drops completely) the data flow transmission rate on packets coming into or out of an interface.
Marking packets using CoS, IP Precedence, and/or DSCP.
Class-based traffic policing configuration occurs during the policy-map stage, after we have defi ned a class of traffic we wish to police. We will use the police command followed by one or several keywords. The best way to understand how to configure traffic policing is to use an example and then break down each command to see exactly what’s going on. In our fi rst example, we want to use the following rates and burst sizes:
c12.indd 504
CIR = 8000
Bc = 2000
Be = 4000
9/21/11 11:28:07 AM
Configuring Class-Based Traffic Policing and Shaping
505
For any traffic that conforms to the CIR, we will transmit the data. For traffic that falls into the exceed-action category, we will re-mark it with a DSCP value of 0. Finally, any traffic that falls into the violate-action category is immediately dropped. Because we are using the violate-action keyword, we know we are configuring a dual-bucket policing strategy. For our policing and shaping configuration examples, we will use Figure 12.10 as our sample network. F I G U R E 1 2 .1 0
A traffic-policing network example
LAN
LAN
S0/0
Router-A
256 Kbps
Router-B
We have already defi ned a class map named police-me on Router-A. Let’s create our policy map named policyPOLICE and police our class map as shown here: Router-A#configure terminal Router-A(config)#policy-map policyPOLICE Router-A(config-pmap-c)#class police-me Router-A(config-pmap-c)#police 8000 2000 4000 conform-action transmit exceedaction set-dscp-transmit 0 violate-action drop Router-A(config-pmap-c-police)#end Router-A#
To make this a single-bucket structure, we would simply remove the violate-action command.
Now that we have our policy map created, we need to apply it to interface s0/0 according to figure 12.10. With traffic policing, we have the ability to apply the policy for either inbound or outbound traffic. In our particular case, we will choose to apply the policy to outbound traffic, as shown here: Router-A#configure terminal Router-A(config)#interface s0/0 Router-A(config-if)#service-policy output policyPOLICE Router-A(config-if)#end Router-A#
c12.indd 505
9/21/11 11:28:08 AM
506
Chapter 12
■
Configuring Quality of Service
Next, you’ll learn how to configure the other rate-limiting technique using traffic-shaping methods.
Configuring Class-Based Traffic Shaping Configuring class-based traffic shaping is done in a similar manner as traffic policing on policy-map configurations of a specific class of traffic. The command used to configure traffic shaping is shape, followed by one of these keywords: Router(config-pmap-c)#shape ? adaptive Enable Traffic Shaping adaptation to BECN average configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc only per interval fecn-adapt Enable Traffic Shaping reflection of FECN as BECN fr-voice-adapt Enable rate adjustment depending on voice presence max-buffers Set Maximum Buffer Limit peak configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc+Be per interval
While there are several keywords available to choose from, we want to configure generic traffic shaping (GTS). For GTS, the two commands we are interested in are average and peak. Notice that the keyword descriptions are using token bucket terms you are already familiar with, including CIR, Bc, and Be. If we configure the average rate, this limits traffic to the committed burst (Bc). The tokens are emptied, and a period of inactivity occurs. Right after that point, Bc + Be can be sent. Peak rate shaping, on the other hand, allows the router to send traffic up to the committed burst (Bc) as well as up to the excess burst (Be) rate at every time interval and not only after periods of inactivity. The trade-off between average and peak is that peak will squeeze a bit more bandwidth out of the link but at the cost of the possibility of more dropped packets. The equation to calculate the peak rate in bps is: Peak_rate ⫽ CIR ⫻ [1 ⫹ (Be / Bc)] Because of the possibility of dropped packets, configuring traffic shaping using an average rate is preferred and implemented in most situations. When configuring using the shape command followed either by average or peak, we will configure only the average/peak bps for the classified traffic. Optionally, we can manually set the Bc and Be rates. If we do not manually configure these, the router will set the values automatically. The router will always choose to set the Bc and Be rates to be the same rate. For example, if our CIR is 16 Kbps, the router will set Bc and Be to 8 Kbps. Using our equation we will get: Peak_rate ⫽ 16000 ⫻ [1 ⫹ (8000 / 8000)] Peak_rate ⫽ 16000 ⫻ [1 ⫹ 1]
c12.indd 506
9/21/11 11:28:08 AM
Configuring Class-Based Traffic Policing and Shaping
507
Peak_rate ⫽ 16000 ⫻ 2 Peak_rate ⫽ 32000 or 32 Kbps Let’s look at a traffic-shaping configuration example again using Figure 12.10 as our network. We have two classes already configured on Router-A. One class is named sensitive and the other class is named tolerant. The sensitive class will use an average shape of 128 Kbps, while the tolerant class will use a peak shape of 64 Kbps, as shown here: Router-A#configure terminal Router-A(config)#policy-map policySandT Router-A(config-pmap)#class sensitive Router-A(config-pmap-c)#shape average 128000 Router-A(config-pmap-c)#exit Router-A(config-pmap)#class tolerant Router-A(config-pmap-c)#shape peak 64000 Router-A(config-pmap-c)#exit Router-A(config-pmap)#exit Router-A(config)#interface s0/0 Router-A(config-if)#service-policy output policySandT Router-A(config-if)#end Router-A#
From this configuration, traffic defined in the sensitive class will transmit to the CIR at a rate of 128 Kbps, and the tolerant class will peak to a rate of 128 Kbps. How did we come up with the peak rate number? We let the router determine the Bc and Be rates. We can use the show policy-map interface interface-name interface-number output command to see what the router set the Bc and Be rates to: Router#show policy-map interface serial 0/0 output Serial0/0 Service-policy output: policySandT Class-map: sensitive (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate Match: dscp ef (46) Traffic Shaping Target/Average Byte Sustain Rate Limit bits/int 128000/128000 1984 7936
c12.indd 507
0 bps
Excess bits/int 7936
Interval (ms) 62
Increment (bytes) 992
9/21/11 11:28:09 AM
508
Chapter 12
Adapt Queue Active Depth 0
■
Configuring Quality of Service
Packets
Bytes
0
0
Class-map: tolerant (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate Match: dscp default (0) Traffic Shaping Target/Average Byte Sustain Rate Limit bits/int 128000/64000 2000 8000 Adapt Queue Active Depth 0
Packets
Bytes
0
0
Packets Delayed 0
Bytes Delayed 0
Shaping Active no
Excess bits/int 8000
Interval (ms) 125
Increment (bytes) 2000
Packets Delayed 0
Bytes Delayed 0
Shaping Active no
0 bps
Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Router#
You can see here that the average shaping policy has a target and average rate of 128000. And our peak shaping policy has a target of 128000 and an average of 64000. How did the router arrive at the 128000 peak rate number? We can use our equation again to calculate the peak rate. In the output the Sustain bits/int of 8000 is the Bc and the Excess bits/int is the Be. Therefore we can calculate the following: Peak_rate ⫽ 64000 ⫻ [1 ⫹ (8000 / 8000)] Peak_rate ⫽ 64000 ⫻ [1 ⫹ 1] Peak_rate ⫽ 64000 ⫻ 2 Peak_rate ⫽ 128000 or 128 Kbps
Configuring Link Efficiency Techniques Sometimes QoS just isn’t enough to provide efficient transport for sensitive traffic. This is especially true with low-speed WAN connections. Fortunately, there are several different techniques to manipulate frames and packets so that the transport of sensitive data is
c12.indd 508
9/21/11 11:28:09 AM
Configuring Link Efficiency Techniques
509
more efficient. In this section I’ll show how to use LFI on both MLP and Frame Relay connections as well as how to configure class-based header compression.
Configuring Link Fragmentation and Interleaving for MLP and Frame Relay In Chapter 11, you learned that link fragmentation is a technique used to accomplish two goals:
Break up large frames into smaller frame chunks
Intermix the smaller frames with frames from other traffic flows
LFI allows us to have a more steady serialization delay on an interface, which helps control jitter that can cripple time-sensitive voice and video traffic. LFI is recommended on links at or below 768 Kbps and is an optional configuration on WAN links with bandwidth speeds between 768 Kbps and 2048 Kbps. Any circuit that is higher than an E1 (2048 Kbps) is not recommended because the trade-off between fragmenting frames and higher CPU and memory utilization is not favorable. LFI is commonly implemented on multilink PPP (MLP) and Frame Relay circuits, and this guide will focus on how to configure these two scenarios.
Configuring LFI for Multilink PPP Multilink PPP is a Layer 2 transport mechanism defi ned in RFC 1990 that encapsulates Layer 3 traffic over point-to-point links including ISDN. While the protocol does have built-in abilities to load-balance traffic from multiple links into a single connection, keep in mind that MLP can be used for a single P2P connection as well. Cisco’s LFI feature uses the MLP protocol for transport because the protocol natively allows frames to be fragmented and passed across a WAN connection, where the frame is then put back together. Cisco then adds the interleaving feature, which is used to provide a special transmit queue for time-sensitive frames such as voice and video. This special queue is given priority over other traffic so it can avoid serialization delays. The queuing mechanism used to differentiate between time-sensitive and regular traffic is WFQ, which can differentiate traffic flows at Layers 3 and 4. To configure MLP, you must fi rst create an MLP virtual interface by using the interface multilink command followed by a unique virtual interface identifier. The virtual interface identifier will later be used to map the physical interface to the multilink interface. In our example, we will use the number 1 as our MLP virtual interface identifier: Router#configure terminal Router(config)#interface multilink 1 Router(config-if)#
At this point, we are in config-if configuration mode, and we should first configure an IP address on it. Note that the virtual interface contains the IP address and not the
c12.indd 509
9/21/11 11:28:09 AM
510
Chapter 12
■
Configuring Quality of Service
physical interface that we will apply the virtual interface to. If you have an IP address already applied to the physical interface, it needs to be removed for the multilink connection to work. Next, we will use the ppp multilink command to enable MLP on our interface. Then we need to turn on the LFI feature by issuing the ppp multilink interleave command. As an optional configuration we will use the ppp multilink fragment-delay command, followed by a delay time in milliseconds. This command will alter the LFI fragmentation techniques to abide by a specific delay timer. This is very useful for voice traffic, which is delay sensitive. So, for example, if we were to set the fragment delay to 20 ms, MLP would fragment frames in a way that the delay would be 20 ms or less on the interface. Here is the complete virtual interface configuration: Router(config-if)#ip address 192.168.10.1 255.255.255.0 Router(config-if)#ppp multilink Router(config-if)#ppp multilink interleave Router(config-if)#ppp fragment-delay 20 Router(config-if)#exit Router(config)#
Lastly, we can apply our multilink virtual interface to a physical interface. In our example, we will configure LFI on interface serial 0/1. We must first change the default encapsulation method of HDLC to PPP, by issuing the encapsulation ppp command. Then we must enable multilink by issuing the ppp multilink command. Last, we can reference our virtualmultilink interface by issuing the ppp multilink-group 1 command, as shown here: Router(config)#int s0/1 Router(config-if)#encapsulation ppp Router(config-if)#ppp multilink Router(config-if)#ppp multilink-group 1 Router(config-if)#no shutdown Router(config-if)#end Router#
At this point, MLP is up and running on your interface. Make sure that you also configure the opposite-end router with a multilink interface and LFI that is identical to this one.
Configuring LFI for Frame Relay Frame Relay is one of those legacy technologies that seem to stick around year after year. Many remote sites are still connected to their primary site through the use of Frame Relay circuits. But because the technology is dated, the bandwidth speeds are less than ideal. When you attempt to run time-sensitive traffic such as voice over these circuits, you can experience congestion problems quickly. In this section, you will learn how to configure FRF.12, which is a specification for fragmenting large Frame Relay frames into smaller chunks. FRF.12 does not have Layer 3 or 4 intelligence and therefore cannot distinguish between a voice packet and an HTTP packet, for example, as MLP can. Instead, FRF.12 simply
c12.indd 510
9/21/11 11:28:10 AM
Configuring Link Efficiency Techniques
511
fragments any frame larger than the configured fragment size. Because of this, you must be cautious in setting your fragmentation size so you don’t accidentally fragment timesensitive voice frames, which can cause added delay. Make sure you properly calculate your voice frame size and set the fragmentation size to something higher. Frame Relay traffic shaping must also be configured on the Frame Relay map and physical interface in order for fragmentation to work. The map-class frame-relay command followed by a unique name identifier is used to configure FRF.12 fragmentation. Once we have created a Frame Relay map class, we must use the frame-relay fragment command, followed by the maximum fragment size in bytes. We can use the following equation to figure out the optimal maximum fragment size for our circuit: Max_fragment_size ⫽ (bandwidth / 8) ⫻ target_delay In order to use this calculation, you must know the bandwidth of the Frame Relay connection (in bps) and your target serialization delay time. For this example, we will assume a bandwidth of 256 Kbps and a target serialization delay of 10 ms (0.01 seconds). The equation is: Max_fragment_size ⫽ (256000 / 8) ⫻ 0.01 Max_fragment_size ⫽ 32000 ⫻ 0.01 Max_fragment_size ⫽ 320 bytes We can then configure our Frame Relay traffic-shaping configuration as shown in this example, where we configure a Frame Relay class named Frag-Me: Router#configure terminal Router(config)#map-class frame-relay Router(config-map-class)#frame-relay Router(config-map-class)#frame-relay Router(config-map-class)#frame-relay Router(config-map-class)#exit Router(config)#
Frag-Me fragment 320 cir 128000 fair-queue
Now it’s time to apply our Frame Relay fragment and shaping class to the Frame Relay interface with a configured DLCI. Similar to MLP, we must modify our Layer 2 protocol from HDLC to Frame Relay. Also remember that we must enable Frame Relay traffic shaping on the physical interface. We can then configure DLCI 100 on the subinterface s0/0.1 point-to-point circuit. This is where we need to apply our Frame Relay class map and set the bandwidth for the circuit, as shown here: Router#configure terminal Router(config)#interface s0/0 Router(config-if)#frame-relay traffic-shaping
c12.indd 511
9/21/11 11:28:10 AM
512
Chapter 12
■
Configuring Quality of Service
Router(config-if)#exit Router(config)#int s0/0.1 point-to-point Router(config-subif)#frame-relay interface-dlci 100 Router(config-fr-dlci)#class Frag-Me Router(config-fr-dlci)#end Router#
To verify the result, we can use the show frame-relay fragment command to display the maximum fragment size as well as the total number of fragmented frames, as shown in this example: Router#show frame-relay fragment interface dlci frag-type size in-frag out-frag Serial0/0.1 100 end-to-end 320 643 790 0 Router#
dropped-frag
Now that you understand how to configure LFI for MLP and Frame Relay connections, let’s move on to learn how to configure class-based header compression.
Configuring Class-Based Header Compression Class-based (CB) header compression can perform either RTP, TCP, or both TCP and RTP compression on packets that are defi ned within a policy map. Using the layered MQC configuration method, we can configure traffic for compression as well as multiple other QoS policies such as PQ and CBWFQ. The command used to configure CB header compression while within config-pmap-c configuration mode is compression header ip. If you simply enter this command, it will enable both cRTP and TCP compression. If you want to enable only one or the other, you can use the optional rtp and tcp keywords. In our example configuration, we want to create a class map named voice. This class will group voice packets by matching on the DSCP EF markings. We will then create a new policy map named policyRTPcompress. This policy will give a strict policy of 50 percent of the link bandwidth to voice traffic and will enable cRTP compression: Router#configure terminal Router(config)#class-map voice Router(config-cmap)#match dscp ef Router(config-cmap)#exit Router(config)#policy-map policyRTPcompress Router(config-pmap)#class voice Router(config-pmap-c)#priority percent 50 Router(config-pmap-c)#compression header ip rtp Router(config-pmap-c)#end Router#
c12.indd 512
9/21/11 11:28:11 AM
Configuring Trust Boundaries
513
Now it’s all a matter of applying our policy map to an interface using the service-policy command, and we’re now using a strict priority queue and cRTP on voice packets with the DSCP EF markings configured on them. Here is an example of how to apply our policy map to interface serial 0/0: Router#configure terminal Router(config)#interface s0/0 Router(config-if)#service-policy output policyRTPcompress Router(config-if)#end Router#
Configuring Trust Boundaries Chapter 11 discussed Layer 2/Layer 3 markings and trust boundary locations on Catalyst switches. Recall that the best-practice decision about where to set a trust boundary depends on the level of trust from endpoint devices and the capabilities of Access layer switches. If your access switches are QoS capable, you can trust markings from all endpoints or only the Cisco IP phones. Most organizations choose to trust the Cisco phones, and any other markings from PCs are rewritten regardless of what they come in as. In fact, by default, if a PC is connected to a Cisco phone, the phone will rewrite any frame coming from the PC with a CoS value of 0. Keep in mind, however, that the DSCP markings will not be rewritten. To configure trust boundaries on an Access layer switch, we must be in config-if configuration mode of the switchport that connects to the device we want to create a boundary for. In Figure 12.11 we will use interface gi0/5 as our example interface to apply a trust boundary on. F I G U R E 1 2 .11
Access switch trust boundary configuration VLAN 99 VLAN 10
Switch Gi0/5
Trusted markings Untrusted markings
The mls qos trust command is used to set what type of traffic is to be trusted that comes inbound on the interface. We can then set the boundary to trust one of the two markings:
c12.indd 513
9/21/11 11:28:11 AM
Chapter 12
514
■
Configuring Quality of Service
cos Trusts all Layer 2 CoS markings and rewrites the DSCP markings using the default CoS-to-DSCP map.
Trusts the DSCP markings and rewrites the CoS markings using the default DSCP-to-CoS map.
dscp
The default CoS-to-DSCP and DSCP-to-CoS mappings are listed here: CoS-to-DSCP mappings CoS markings
0
1
2
3
4
5
6
7
DSCP markings
0
8
16
24
32
40
48
56
DSCP-to-CoS mappings DSCP markings
0
8, 10
16, 18
24, 26
32, 24
40, 46
48
56
CoS markings
0
1
2
3
4
5
6
7
The default CoS-to-DSCP and DSCP-to-CoS mappings can be modified, and you will learn how this is done in the next section.
The preferred method for a Cisco IP phone network is to use the Layer 2 CoS values on lower-end Catalyst switches. One optional command that can be added when configuring trust boundaries to use CoS is mls qos trust cos pass-through dscp. The pass-through dscp keywords state that the DSCP markings are not to be overwritten with the CoS-toDSCP map. Another popular configuration command that can be used when a network has Cisco IP phones is mls qos trust device cisco-phone. This command works with the Cisco Discovery Protocol (CDP), which both the Cisco phone and switchport (if enabled) understand. This effectively pushes our trust boundary out past the access switch to Cisco IP phones. But keep in mind that only Cisco IP phones are trusted and no other end-device markings. The following example shows how to configure an Access layer switchport with both a voice (10) and data (99) VLAN. In addition, the switchport will be configured to trust CoS markings from Cisco IP phones: Switch#configure terminal Switch(config)#interface gi0/5 Switch(config-if)#switchport mode access Switch(config-if)#switchport voice vlan 10 Switch(config-if)#switchport access vlan 99 Switch(config-if)#mls qos trust cos Switch(config-if)#mls qos trust device cisco-phone Switch(config-if)#end Switch#
c12.indd 514
9/21/11 11:28:12 AM
Configuring CoS-to-DSCP Mappings
515
One fi nal switch interface configuration command that you should be familiar with is mls qos cos, followed by a CoS value. This command statically assigns a CoS value to
traffic that comes into the switchport untagged and thus does not have a CoS value assigned. The optional override keyword can be used so the static CoS value used in this command will rewrite the CoS value of frames that already have CoS markings. In the following example, we will configure our switch interface gi0/5 to assign frames with a CoS of 1 if they come in untagged: Switch#configure terminal Switch(config)#interface gi0/5 Switch(config-if)#mls qos cos 1 Switch(config-if)#end Switch#
Next we’ll discuss the need for CoS-to-DSCP mappings (and vice versa) and how to modify the default settings for better end-to-end QoS.
Configuring CoS-to-DSCP Mappings As you know, trust boundaries are configured to trust (or not to trust) QoS markings that come into a port. When a switch is configured to trust the CoS values of a frame, the switch will rewrite the DSCP value based on the default CoS-to-DSCP values. This remapping of DSCP numbers is a critical step and allows us to have a truly end-to-end QoS policy. Unfortunately, the default CoS-to-DSCP mappings (Figure 12.12) built into the Catalyst switch IOS are not ideal for all situations. For example, a Cisco IP phone marks traffic coming from it with a CoS of 5 and a DSCP of 46. But if you look at Figure 12.12, we have a switch configured to trust the CoS values and rewrite the DSCP value using the default CoS-to-DSCP mappings. F I G U R E 1 2 .1 2
CoS-to-DSCP default mapping
Router trust DSCP
Switch trust CoS
CoS = 5 DSCP = 40
CoS = 5 DSCP = 46
CoS-to-DSCP lookup and remapping
c12.indd 515
Cos markings
0
1
2
3
4
5
6
7
DSCP markings
0
8
16
24
32
40
48
56
9/21/11 11:28:12 AM
516
Chapter 12
■
Configuring Quality of Service
You’ll notice that when the switch remaps the DSCP value, it changes from 46 to 40. Best-practice documentation states that RTP traffic should be classified as DSCP 46 (PHB EF), and therefore we have our voice operating with suboptimal QoS levels, which can degrade the Quality of Service applied to it. To fi x this problem, we can adjust the default CoS-to-DSCP mappings to make them conform to best-practice policy. To modify the default mapping settings, we can issue the mls qos map cos-dscp command, followed by eight DSCP values that we want to map to CoS values 0 to 7. The remapping is configured globally on the switch. This example shows a commonly remapped CoS-to-DSCP mapping: Switch#configure terminal Switch(config)#mls qos map cos-dscp 0 10 18 26 34 46 48 56 Switch(config)#end Switch#
When our Catalyst switch makes queuing decisions that come from the DSCP-operated network, it performs a DSCP-to-CoS remapping, again in an attempt to use a single QoS mark from end to end. If the default DSCP-to-CoS mappings are not optimal for your network, they too can be modified. We use the same mls qos map command, but this time we specify dscp-cos. But because there are multiple DSCP markings and only eight possible CoS values, we have the ability to configure up to 13 DSCP markings to a single CoS number. Each CoS value is configured using a single CLI command. For example, we will configure DSCP markings 0, 8, and 10 to a CoS of 0. Then, on the next line, we will map DSCP 16, 18, 24, and 26 to a CoS value of 1: Switch#configure terminal Switch(config)#mls qos map dscp-cos 0 8 10 to 0 Switch(config)#mls qos map dscp-cos 16 18 24 26 to 1 Switch(config)#end Switch#
To review the current mappings of a switch we can use the show mls qos maps command followed by the type of map we want to see. Here we will use the show command to view our CoS-to-DSCP mappings: Switch#show mls qos maps cos-dscp cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------dscp: 0 10 18 26 34 46 48 56
c12.indd 516
9/21/11 11:28:13 AM
Exam Essentials
517
Summary Quality of Service is no longer a “nice to have” feature on networks. When networks begin intermixing standard TCP data transmissions along with time-sensitive UDP voice and video transmissions, you must be able to properly mark sensitive traffic so it gets the interface priority that it requires. The CVOICE version 8.0 exam now requires that certification candidates know the two primary QoS configuration methods, AutoQoS and MQC. Without this knowledge, you’ll quickly fi nd that many IP networks will not meet the strict bandwidth, latency, and jitter requirements, and voice quality will suffer.
Exam Essentials Know the two different AutoQoS types. the Enterprise.
They are AutoQoS for VoIP and AutoQoS for
Understand when AutoQoS for the Enterprise is recommended. AutoQoS for the Enterprise is used on larger networks with a significant number of remote sites interconnected with WAN connections. Know what type of AutoQoS can be configured on Cisco Catalyst switches. Catalyst switches can only be configured for AutoQoS for VoIP.
Cisco
Know the two phases of AutoQoS for the Enterprise. The first phase is called the AutoQoS autodiscovery phase and is used to discover interfaces and data flows on a network. The second phase creates QoS templates based on the findings from the autodiscovery phase. Know the three primary commands used to configure QoS using MQC. The three commands are class-map, policy-map, and service-policy. Understand the difference between class-map match-any and match-all statements. The match-any statement triggers when any single match statement is met. The match-all statement is triggered only when all match statements are met. Understand the difference between RED and WRED. RED is used to drop packets randomly before queue buffers fill up. WRED uses classification markings to drop lessimportant packets fi rst. Understand the concept of a token bucket. A token bucket is used to regulate data in a flow to manage the overall bandwidth of an interface. Understand the three different types of class-based header compression. CB header compression can perform either RTP, TCP, or RTP and TCP compression on packets matched in a policy map. Understand the most common need to modify CoS-to-DSCP mappings on a VoIP network. The default CoS-to-DSCP mappings will mark voice traffic with a lower DSCP value that is recommended by Cisco.
c12.indd 517
9/21/11 11:28:13 AM
518
Chapter 12
■
Configuring Quality of Service
Written Lab 12.1 1.
What Cisco equipment can Auto-QoS for VoIP be configured on?
2.
AutoQoS for the Enterprise is recommended on large networks with multiple connections.
3.
What Cisco switch AutoQoS command is used to configure an interface to trust DSCP and/or CoS markings?
4.
What router interface command is used to configure AutoQoS for the Enterprise to monitor and classify traffic using NBAR?
5.
What class-map command will configure a class named voice and set it to classify traffic when all match statements are met?
6.
What class-map match statement will match packets that have DSCP values of 48 or 56?
7.
What policy-map statement will configure WRED?
8.
What is the switch-interface command used to rewrite the CoS to be a value of 2?
9.
What is the switch-interface command used to map the DSCP values of 0 and 8 to a CoS value of 2?
10. What switch command can be used to verify CoS to DSCP mappings?
(The answers to Written Lab 12.1 can be found following the answers to the review questions for this chapter.)
Hands-On Labs To complete the labs in this section, you need a Cisco Catalyst switch for Layer 2 QoS configurations. In addition, you will need a router with a voice-capable IOS, one serial interface, and one Ethernet interface. Each lab in this section builds upon the last and will follow the logical network design as shown in Figure 12.13.
F I G U R E 1 2 .1 3
QoS lab diagram Phone (VLAN 5)
PC (VLAN 101)
Fa0/5
S0/0
Fa0/0 Fa0/0 Switch
c12.indd 518
Remote site
Router
9/21/11 11:28:14 AM
Hands-On Labs
519
Here is a list of the labs in this chapter: Lab 12.1: Configuring a Switchport to Trust Cisco IP Phone QoS Markings Lab 12.2: Modifying CoS-to-DSCP Mappings Lab 12.3: Configuring a Router for QoS Using MQC
Hands-On Lab 12.1: Configuring a Switchport to Trust Cisco IP Phone QoS Markings In this lab, we’re going to configure our access port on fa0/5 to place traffic coming from the phone on VLAN 5 and from the PC on VLAN 101. Additionally, we will configure the interface to trust QoS markings that come from the Cisco IP phone but not the connected PC. 1.
Log into the switch and go into configuration mode by typing enable and then configure terminal.
2.
We can then begin to configure the Cisco IP phone that is attached to fa0/5 by fi rst entering into interface configuration mode by typing interface fa 0/5.
3.
We will configure this port as an Access layer port by typing switchport mode access.
4.
Now we will configure the switchport to place voice traffic on VLAN 5 by typing switchport voice vlan 5.
5.
Next, we will configure all other traffic coming from the PC to use VLAN 101 for transport by typing switchport access vlan 101.
6.
Our fi rst QoS command is to configure the port to trust CoS markings by typing mls qos trust cos.
7.
Lastly, we will configure the port to trust CoS markings only from the Cisco phone by typing mls qos trust device cisco-phone.
8.
Exit config-interface mode by typing end.
Hands-On Lab 12.2: Modifying CoS-to-DSCP Mappings From our configuration in lab 12.1, we are now trusting CoS markings that come from the Cisco IP phone connected to fa0/5. However, we must now modify the default CoS-to-DSCP mappings so our voice traffic will be marked with a DSCP value of 46 (EF). Remember that if we use AutoQoS for VoIP on our switchport, the AutoQoS script will modify the CoS-to-DSCP mappings for us. But since we are manually configuring QoS on our switch, we need to configure mapping rules so that our voice traffic will receive the proper QoS on the network. We will use the following CoS-to-DSCP mappings according to Table 12.3.
c12.indd 519
9/21/11 11:28:14 AM
520
Chapter 12
TA B L E 1 2 . 3
■
Configuring Quality of Service
CoS-to-DSCP mappings
CoS Markings
DSCP Markings
0
0
1
10
2
18
3
26
4
34
5
46
6
48
7
56
1.
Log into your voice gateway and go into configuration mode by typing enable and then configure terminal.
2.
Configure the CoS-to-DSCP mappings by typing mls qos map cos-dscp 0 10 18 26 34 46 48 56.
3.
Exit global configuration mode by typing exit.
Hands-On Lab 12.3: Configuring a Router for QoS Using MQC We will now shift our attention from the Cisco switch QoS configuration to the router QoS configuration. In this lab we will use MQC to configure QoS to match our voice traffic coming from our switch. We will then apply QoS policies and apply them to the outbound serial 0/0 interface. We will first configure a class map named voice-traffic. Within this class map, we will match packets that have a DSCP value of 46. Remember that in our previous two labs, we configured our switch to trust markings from the Cisco IP phone and modified the CoS to DSCP mappings so voice traffic will be marked with a DSCP value of 46.
c12.indd 520
1.
Log into the switch and go into configuration mode by typing enable and then configure terminal.
2.
Configure and name our class map by typing class-map voice-traffic.
3.
Differentiate between voice and non-voice packets by typing match dscp 46.
4.
Exit out of class-map configuration mode by typing exit.
9/21/11 11:28:15 AM
Hands-On Labs
521
Now we will create our policy map named voice-policy, which will tell our router how voice traffic that is matched against the class map rules should be handled. In our example, we will give our voice traffic a strict priority queuing capability up to 60 percent of the total link bandwidth. 5.
Configure and name our policy map by typing policy-map voice-policy.
6.
Specify the voice-traffic class map by typing class voice-policy.
7.
Apply the QoS strict-priority queuing mechanism for this traffic by typing priority percent 60.
8.
Exit out of policy-map configuration mode by typing exit.
Finally, we will apply the policy to our serial interface 0/0 so the voice traffic can have plenty of bandwidth across the WAN to the remote network. 9.
Enter into interface configuration mode for our serial interface by typing interface serial 0/0.
10. Apply the policy map outbound by typing service-policy output voice-policy. 11. Exit interface configuration mode by typing end.
c12.indd 521
9/21/11 11:28:15 AM
Chapter 12
522
■
Configuring Quality of Service
Review Questions 1.
AutoQoS works in conjunction with which two features? A. CDP
2.
B.
SIP
C.
CEF
D.
NBAR
E.
H.323
Which of the following are not AutoQoS features that can be enabled on Cisco Catalyst switches? A. Setting the trust boundary at the Cisco IP phone
3.
B.
Setting the trust boundary at the access or trunk port
C.
Automatic classification of RTP, cRTP, and voice gateway signaling protocols
D.
Automatic enabling of PQ and WRR when appropriate
When configuring AutoQoS for VoIP on a Cisco router, what optional keyword(s) instructs the router to believe DSCP markings from incoming packets? A. trust interface
4.
B.
trust cisco-phone
C.
trust dscp
D.
trust
You are configuring a Cisco switch interface and issue the following command: auto qos voip Which of the following is not a keyword that can be used to complete this command? A. cisco-phone
5.
B.
dscp
C.
trust
D.
cisco-softphone
What two global configuration commands will be found after enabling AutoQoS on one or more interfaces on a Cisco switch? A. mls qos
c12.indd 522
B.
mls qos trust cos
C.
mls qos trust dscp
D.
mls qos map cos-dscp 0 8 16 26 32 46 48 56
9/21/11 11:28:16 AM
Review Questions
6.
523
What command can be used to verify that the AutoQoS for the Enterprise autodiscovery phase is identifying and classifying traffic? A. show qos auto discovery
7.
B.
show auto discovery qos
C.
show mls qos auto discovery
D.
show auto discovery mls qos
Which of the following switch-interface commands will trust DSCP markings coming from an upstream router? A. auto qos voip trust
8.
B.
qos voip trust
C.
qos voip trust dscp
D.
mls qos trust dscp
A QoS class map is always configured by default when a class map is configured on Cisco hardware. What is the name of this class map? A. class-voip
9.
B.
class-best-effort
C.
class-default
D.
class-network
How can the MQC service policy be applied on a Cisco router? A. Inbound on an interface B.
Outbound on an interface
C.
Inbound and/or outbound on an interface
D.
Inbound or outbound on an interface but not both inbound and outbound
10. You are configuring an MQC policy for voice traffic and enter the following commands: Router(config)#class-map voice Router(config-cmap)#match precedence 5 Router(config-cmap)#match dscp 46 In order for a packet to trigger on this class map, what must be true? A. The packet must have an IP Precedence value of 5 or a DSCP value of 46.
c12.indd 523
B.
The packet must have an IP Precedence value of 5 and a DSCP value of 46 or higher.
C.
The packet must have an IP Precedence value of 5 and a DSCP value of 46.
D.
The packet must have an IP Precedence value of 5 or higher or a DSCP value of 46 or higher.
9/21/11 11:28:16 AM
Chapter 12
524
■
Configuring Quality of Service
11. You have created the following access list: access-list 5 permit 192.168.1.0 0.0.0.255 access-list 5 permit 192.168.2.0 0.0.0.255 You want to use this access list in a class map. Which of the following commands properly does this? A. Router(config)#class-map match-all access-group 5 B.
Router(config-cmap)#match access-list 5
C.
Router(config-cmap)#match access-group 5
D.
Router(config)#class-map match-any access-group 5
12. Which of the following is the proper way to create a policy-map named mypolicy for a class map named ipt? You want to apply a strict PQ of 60 percent of the overall link bandwidth. A. Router(config)#policy-map mypolicy Router(config-pmap)#class ipt Router(config-pmap-c)#bandwidth percent 60 B. Router(config)#policy-map mypolicy Router(config-pmap)#class ipt Router(config-pmap-c)#priority percent 60 C. Router(config)#policy-map mypolicy Router(config-pmap)#class ipt bandwidth percent 60 D. Router(config)#policy-map mypolicy Router(config-pmap)#class ipt priority percent 60 13. Which of the following policy-map keywords sets a CBWFQ value? A. priority B.
police
C.
shape
D.
bandwidth
14. Which of the following show commands can be issued on a router to view the policy map(s) that has been applied on interface serial 0/1? A. show policy-map interface serial 0/1 B.
show service policy serial 0/1
C.
show policy-map serial 0/1
D.
show service-policy interface serial 0/1
15. What is a Cisco proprietary congestion-avoidance technique that intelligently drops packets based on QoS markings? A. RED B.
c12.indd 524
WRED
C.
CQ
D.
CBWFQ
9/21/11 11:28:17 AM
Review Questions
525
16. If there are 56,000 bits worth of tokens of burst traffic (Bc) and these bits are moved in and out of the token bucket every 250 ms, what is our token bucket CIR? A. 14,000 bps B.
140,000
C.
24,400 bps
D.
224,000 bps
17. When traffic in a token bucket goes above the CIR, what is the traffic called? A. Burst conforming (Bc) B.
Burst violated (Bv)
C.
Burst overflow (Bo)
D.
Burst exceeded (Be)
18. In a dual-bucket, dual-rate token model, which of the following is not a possible token outcome? A. Overflow-action B.
Conform-action
C.
Violate-action
D.
Exceed-action
19. Tokens within a traffic-policing mechanism using a single token bucket can have which two possible outcomes? A. Conform-action B.
Violate-action
C.
Exceed-action
D.
Shaping-action
E.
Policing-action
20. You are reviewing a router policy map configuration as shown here: policy-map policyONE police 8000 2000 4000 conform-action transmit exceed-action set-dscptransmit 0
What token bucket structure is used? A. Single-bucket
c12.indd 525
B.
Single-bucket with dual-rates
C.
Dual-bucket with single-rates
D.
Dual-bucket with dual-rates
9/21/11 11:28:17 AM
526
Chapter 12
■
Configuring Quality of Service
Answers to Review Questions 1.
C, D. The automatic classification function of AutoQoS uses NBAR to identify and classify traffic at Layer 4. NBAR requires that CEF be enabled.
2.
C. The automatic classification of RTP, cRTP, and voice-signaling protocols cannot be performed on Catalyst switches.
3.
C. The optional trust keyword indicates that inbound packets that are already marked with DSCP values should be trusted.
4.
B. The three possible keyword options are cisco-phone, trust, and cisco-softphone.
5.
A, D. The mls qos command enables QoS on the switch, and the mls qos map cos-dscp 0 8 16 26 32 46 48 56 command sets the new set of CoS-to-DSCP mappings.
6.
B. The show auto discovery qos command displays information about how long the discovery process has been running, and the types of traffic found and classified while monitoring. Additionally, the command output shows suggested QoS configuration commands based on the traffic-discovery process.
7.
D. The mls qos trust dscp interface command will trust DSCP markings coming inbound on the interface.
8.
C. The class-default class is included when a new policy is created and applied to an interface.
9.
C. A service policy can be applied to traffic coming into or out of an interface.
10. A. The command class-map voice does not include the keywords match-any or match-all. Because of this, the router will use the default match-any statement. Therefore, a packet that has an IP Precedence of 5 or a DSCP of 46 will be classified into this class. 11. C. The match access-group class-map command followed by the access-list number should be configured while in config-cmap mode. 12. B. You must fi rst specify the class map while in config-pmap mode. Then you use the priority percent command followed by a percentage value to set the strict priority queue for this traffic. 13. D. The bandwidth command sets the CBWFQ bandwidth. 14. A. The show policy-map interface command followed by the interface type and number is used to view the input and/or output policy maps applied to that specific interface. 15. B. WRED is a Cisco proprietary mechanism that uses the same dropping techniques of RED but drops packets with lower IP Precedence or DSCP markings before those of a higher priority.
c12.indd 526
9/21/11 11:28:17 AM
Answers to Review Questions
527
16. D. CIR = Bc / Tc CIR = 56,000 / 0.25 CIR = 224,000 bps or 224 Kbps 17. D. Traffic that exceeds the CIR is considered to be Be traffic and is placed into the Be token bucket. 18. A. All of these token outcomes for tokens are possible except for the overflow-action. 19. A, C. The two possible outcomes of a single token bucket-policing mechanism are conform-action or exceed-action. 20. A. Because the police command only has conform-action and exceed-action settings, this is a single-bucket structure.
c12.indd 527
9/21/11 11:28:18 AM
528
Chapter 12
■
Configuring Quality of Service
Answers to Written Lab 12.1 1.
Routers and Catalyst switches
2.
WAN (or remote site)
3.
auto qos voip trust
4.
auto discovery qos
5.
class-map match-all voice
6.
match dscp 48 56
7.
random-detect dscp-based
8.
mls qos cos 2
9.
mls qos map dscp-cos 0 8 to 2
10. show mls qos maps cos-dscp
c12.indd 528
9/21/11 11:28:18 AM
Appendix
About the Companion CD IN THIS APPENDIX:
bapp.indd 529
What you’ll find on the CD.
System requirements.
Using the CD.
Troubleshooting.
9/20/11 1:34:45 PM
What You’ll Find on the CD The following sections are arranged by category and summarize the software and other goodies you’ll fi nd on the CD. If you need help with installing the items provided on the CD, refer to the installation instructions in the “Using the CD” section of this appendix.
Sybex Test Engine The CD contains the Sybex test engine, which includes two bonus practice exams for Exam 642-437.
Electronic Flashcards These handy electronic flashcards are just what they sound like. One side contains a question and the other side shows the answer.
PDF of the Glossary We have included an electronic version of the Glossary in PDF format. You can view the electronic version of the book with Adobe Reader.
Adobe Reader We’ve also included a copy of Adobe Reader so you can view PDF fi les that accompany the book’s content. For more information on Adobe Reader or to check for a newer version, visit Adobe’s website at www.adobe.com/products/reader/.
bapp.indd 530
9/20/11 1:34:46 PM
Troubleshooting
531
System Requirements Make sure your computer meets the minimum system requirements shown in the following list. If your computer doesn’t match up to most of these requirements, you may have problems using the software and files on the companion CD. For the latest and greatest information, please refer to the ReadMe fi le located at the root of the CD-ROM.
A PC running Microsoft Windows 98, Windows 2000, Windows NT4 (with SP4 or later), Windows Me, Windows XP, Windows Vista, or Windows 7
An Internet connection
A CD-ROM drive
Using the CD To install the items from the CD to your hard drive, follow these steps: 1.
Insert the CD into your computer’s CD-ROM drive. The license agreement appears.
Windows users: The interface won’t launch if you have autorun disabled. In that case, click Start Run (for Windows Vista or Windows 7, Start All Programs Accessories Run). In the dialog box that appears, type D:\Start.exe. (Replace D with the proper letter if your CD drive uses a different letter. If you don’t know the letter, see how your CD drive is listed under My Computer.) Click OK.
2.
Read the license agreement, and then click the Accept button if you want to use the CD.
The CD interface appears. The interface allows you to access the content with just one or two clicks.
Troubleshooting Wiley has attempted to provide programs that work on most computers with the minimum system requirements. Alas, your computer may differ, and some programs may not work properly for some reason. The two likeliest problems are that you don’t have enough memory (RAM) for the programs you want to use or you have other programs running that are affecting installation or running of a program. If you get an error message such as “Not enough
bapp.indd 531
9/20/11 1:34:46 PM
532
Appendix About the Companion CD
memory” or “Setup cannot continue,” try one or more of the following suggestions and then try using the software again: Turn off any antivirus software running on your computer. Installation programs sometimes mimic virus activity and may make your computer incorrectly believe that it’s being infected by a virus. Close all running programs. The more programs you have running, the less memory is available to other programs. Installation programs typically update fi les and programs; so if you keep other programs running, installation may not work properly. Have your local computer store add more RAM to your computer. This is, admittedly, a drastic and somewhat expensive step. However, adding more memory can really help the speed of your computer and allow more programs to run at the same time.
Customer Care If you have trouble with the book’s companion CD-ROM, please call the Wiley Product Technical Support phone number at (800) 762-2974.
bapp.indd 532
9/20/11 1:34:46 PM
Index Note to the Reader: Throughout this index boldfaced page numbers indicate primary discussions of a topic. Italicized page numbers indicate illustrations.
A A-law algorithm, 55 access codes for private plans, 117 access-group option, 490, 492 access-list option, 492 ACF (Admission Confirmation) message, 400–401 Adaptive Differential Pulse Code Modulation (ADPCM), 155 Adaptive MultiRate Wideband (AMR-WB), 155 address signaling, 35–37, 36–37 address translation, 398 Admission Confirmation (ACF) message, 400–401 Admission Reject (ARJ) message, 400–401 Admission Request (ARQ) message, 400–401 ADPCM (Adaptive Differential Pulse Code Modulation), 155 AF (Assured Forwarding) PHB, 452–453 agents call processing, 15–17, 17 fax relay, 362 SIP, 86, 240 AIM (AOL Instant Messenger), 156 ALERTING ephone extension state, 336, 338 aliases, directory, 299 allow-connections command, 422–423 allow-connections sip to sip
command, 306 alternate mark inversion (AMI), 59, 59 AMI option, 63, 192 ampersands (&) in regular expressions, 128 AMR-WB (Adaptive MultiRate Wideband), 155 analog telephones, 3 analog telephony adapters (ATAs), 15 analog-to-digital conversion compression process, 54–55 encoding process, 53–54, 54 overview, 51–52
bindex.indd 533
quantization, 53, 53 signal sampling, 52–53, 52 analog-to-IP adapters, 15 analog voice, 34 conversion to digital. See analog-to-digital conversion exam essentials, 66–67 ports, 34–35 FXO outbound, 184–187, 185 FXS and FXO PLAR OPX, 180–184, 180 FXS basic, 47–50 FXS/DID inbound, 184–187, 185 review questions, 69–74 signaling, 35 address, 35–37, 36–37 E&M, 41–46, 44– 46 ground-start, 40–41, 41 informational, 37–38 supervisory, 38–41, 39, 41 summary, 66 T1 CAS to analog cross-connect, 191–195, 191 written lab, 67–68, 75 ANI (Automatic Number Identification), 112, 188–189 ani mapping command, 213 answer-address command, 112 answer (ANS) tones, 362 AOL Instant Messenger (AIM), 156 application mgcpapp command, 259 application-specific packets, 82 application-specific routing (ASR), 91 applications, 15 area codes, 8, 115, 190 ARJ (Admission Reject) message, 400–401 ARQ (Admission Request) message, 400–401 ASR (application-specific routing), 91 associate application SCCP command, 199 associate ccm command, 201 associate profile command, 201 Assured Forwarding (AF) PHB, 452–453 asterisks (*) in regular expressions, 128
9/20/11 1:38:36 PM
534
ATA 180 series phones – boundaries, trust
ATA 180 series phones, 15 ATAs (analog telephony adapters), 15 AUCX (audit connection) command, 256 audible rings, 310 audio fidelity, 148, 148 AUEP (audit endpoint) command, 256 Authentication and Message Integrity packets, 83 authentication username command, 269 authentication username password command, 240 authorization, call, 398–399 auto command, 285 auto assign command, 310 auto discovery qos command, 484, 488 auto discovery qos trust command, 484 auto qos command, 488 auto qos cisco-phone command, 480–481 auto qos voip command, 475–476, 481 auto qos voip cisco-phone command, 482 auto qos voip trust command, 481–482 autodiscovery phase in AutoQoS, 483–487 Automatic Number Identification (ANI), 112, 188–189 AutoQoS, 446, 474–475 autodiscovery phase, 483–487 enterprises, 475, 483, 484 implementation phase, 488 installation phase, 483 VoIP, 475 on routers, 475–479, 476 on switches, 479–483, 480 average keyword, 506
backward compatibility of inline power switches, 284–285 bandwidth H.323 gatekeepers, 398–399 CAC control, 411–414, 413 RAS messages, 404–405 IP voice, 164 calculations, 165, 167–169, 169 codec bit rate, 166–167 packet and frame size information, 165–166, 166 providing, 441–442 bandwidth command H.323 gatekeepers, 412–413 QoS policy maps, 493 Bandwidth Confirm (BCF) message, 404–405 Bandwidth Reject (BRJ) message, 404–405 Bandwidth Request (BRQ) message, 404–405 baseline models in QoS, 461–463, 462 Basic Rate Interface (BRI), 56, 61 Bc (Burst Conforming) size for token buckets, 500–501, 506 BCF (Bandwidth Confirm) message, 404–405 Be (burst-exceeding) traffic for token buckets, 501–502, 506 bearer (B) channels, 61 behavior aggregate (BA) in DSCP, 451 Bell, Alexander Graham, 2 Best-effort QoS model, 447, 449 bind command, 247 bind all source-interface command, 269 bind control source-interface
command, 306
B B (bearer) channels, 61 b (silent with beep) ephone button separator, 318 B8ZS (Bipolar 8-bit Zero Substitution), 59, 60, 192 B8ZS option, 63 BA (behavior aggregate) in DSCP, 451 Baby Bell companies, 8 background noise, 149–151, 150 backhauled connections, 7 backslashes (\) in regular expressions, 128–130 backup paths, voice, 368–369 COR, 372–377, 373 MGCP-to-H.323 fallback, 370–372, 371 SRST, 376–377 WAN-to-PSTN fallback, 369–370, 369
bindex.indd 534
bind interface command, 201 bind srcaddr command, 409
binding SIP sources to IP addresses, 247 virtual H.323 gateway addresses, 233–234, 233 Bipolar 8-bit Zero Substitution (B8ZS), 59, 60, 192 bipolar variations, 59 bit rate for codecs, 166–167 blast method for location message forwarding, 403 bottlenecks end-to-end delays, 442 packet loss from, 443–444, 443 as quality issue, 151–152 boundaries, trust configuring, 513–515, 513 identifying, 460–461, 461
9/20/11 1:38:37 PM
BRI (Basic Rate Interface) – cisco-softphone option
BRI (Basic Rate Interface), 56, 61 BRJ (Bandwidth Reject) message, 404–405 BRQ (Bandwidth Request) message, 404–405 buffer packets in traffic policing, 456 buffering delay, 152 Burst Conforming (Bc) size for token buckets, 500–501, 506 burst-exceeding (Be) traffic for token buckets, 501–502, 506 Busy informational signals, 38 button command ephone, 318 SCCP, 344 button separator options for ephone, 318–319 expansion line, 324 monitor line, 319–320, 320 overlay line, 320–323 overlay with call waiting, 323–324 watch phone, 320 Bye retry type, 246 bytes setting, 230
C c (overlay with call waiting) ephone button separator, 319, 323–324 C549 DSP chipset (PVDM), 157–158 C5510 DSP chips (PVDM2), 157, 159–160 CA (call agent) fax relay method, 362 call-admission control (CAC), 90–91, 93, 398, 411–414, 413, 417 call admission messages, 400–401 call agent (CA) fax relay method, 362 call authorization, 398–399 call-block disconnect-cause incoming
command, 381 call blocking, 380–382 call clarity, codecs for, 164 call control devices, 87 call flow differences, 421–422, 421– 422 call management in H.323, 399 call processing agents, 15–17, 17 call-processing clusters, 90, 90 call progress (CP) tones, 38 call routing, 108 call legs, 110–111, 111 POTS dial peers, 108–109 VoIP dial peers, 109–110, 110 call signaling, 17, 17 call start config-serv-h232
command, 228
bindex.indd 535
535
call waiting, 323–324 Call waiting informational signals, 38 called type in translation profiles, 131 caller-ID blocking, 249 calling privileges, 90, 104 calling type in translation profiles, 131 CAMA (Centralized Automatic Messaging Accounting) trunks, 188–191, 189, 213 Cancel retry type, 246 CAR (Committed Access Rate), 456 carets (^) in regular expressions, 128–130 CAS (Channel Associated Signaling), 56, 60–61 categories of traffic, 446 CB (class-based) header compression, 512–513 CB (class-based) QoS, 488–489 CB-WRED (class-based WRED), 498 CBWFQ (class-based weighted fair queuing), 454–455 CC (Country Code) in E.164, 113–114 ccm-manager mgcp command, 257 CCME licenses, 297 CCS (Common Channel Signaling), 56, 61–62 CDP (Cisco Discovery Protocol), 285, 514 CEF (Cisco Express Forwarding), 475 central office (CO) overview, 4–5, 4 trunks, 7, 7 central office code in NANP, 115 Centralized Automatic Messaging Accounting (CAMA) trunks, 188–191, 189, 213 centralized call-control systems, 93 centralized services deployment model, 20, 21 cfg-translation-profile mode, 131, 381 CH1 licenses, 297 Channel Associated Signaling (CAS), 56, 60–61 child maps, 494 CIR (Committed Information Rate), 500–501 Cisco Cius Tablet, 14, 14 Cisco Discovery Protocol (CDP), 285, 514 Cisco Express Forwarding (CEF), 475 Cisco fax relay, 357–359, 358 Cisco IP Communicator, 13–14 cisco option, 360 cisco-phone option, 479 Cisco products overview. See Unified Communications Model overview cisco-rtp option, 354–355 cisco-softphone option, 479
9/20/11 1:38:38 PM
536
Cisco Unified Border Element (CUBE) – committed burst (Bc)
Cisco Unified Border Element (CUBE), 396, 421–422, 421– 422 codec transparency, 424 debug voip ipipgw command, 426–427 exam essentials, 427–428 features, 417 H.323 fast-to-slow signaling, 424–425 hands-on labs, 429–431, 429 media flow-around, 418–419, 419, 423 media flow-through, 418, 418 overview, 416, 417 protocol interoperation, 422–423, 423 review questions, 432–437 RSVP-CAC, 420, 420 show call active voice brief command, 425–426 show call history voice brief command, 426 show voip rtp connections
command, 426 signaling protocol interoperation, 419, 419 SIP delayed-to-early-offer signaling, 425 summary, 427 written lab, 428–429, 438 Cisco Unified Communications Manager (CUCM), 16, 420 configuring, 201–202, 202 gatekeepers, 89–90 IP soft phones, 13–14 RTP, 79 Cisco Unified Communications Manager Business Edition (CUCMBE), 16 Cisco Unified Communications Manager Express (CUCME), 16, 294–295 Cisco Unified Mobile Communicator, 13–14 Cisco Unified Personal Communicator, 13 Cisco Video Advantage product, 14 Cius tablet, 14, 14 clarity, voice codecs for, 160–163 class-based (CB) header compression, 512–513 class-based (CB) QoS, 488–489 class-based traffic policing configuring, 504–505, 505 description, 456 token buckets, 500–504, 502–503 class-based traffic shaping, 500 configuring, 506–508 token buckets, 500–501 class-based weighted fair queuing (CBWFQ), 454–455
bindex.indd 536
class-based WRED (CB-WRED), 498 class-default command, 497 class-map command, 489–490 class-map voice-traffic command, 520
class maps, 489–492 Class of Restriction (COR), 372–377, 373 Class of Service (CoS), 445, 459–460, 459– 460 Class Selector (CS) PHB, 453 class voice-policy command, 521 classification, traffic, 444–445 classification markings, baseline, 462–463 classification models in QoS Best-effort, 447, 449 DiffServ. See DiffServ QoS model IntServ, 447–449 clear call history voice command, 426 clear h323 gateway h225 command, 235 clear mgcp statistics command, 264 CLI (command line interface) in QoS, 446 clid command, 127 clid strip pi-restrict command, 249 clid substitute name command, 248 clock source command, 63–64 clock source line command, 213 clock timezone command, 293 clocking, 63–65, 192 CO (central office) overview, 4–5, 4 trunks, 7, 7 codec command ephones, 309 modem pass-through, 367 SCCP, 344 codec complexity command, 158–159 codec preference command, 229–230 codec transparent command, 424 codecs bit rate, 166–167 choosing, 163–164 complexity, 156–160 CUBE negotiation, 417 H.323 preference, 229–231 transparency, 424 types, 153–156 cold spares, 297 colons (:) ephone button separator, 318 comfort-noise command, 151 comfort noise synthesis, 151 command line interface (CLI) in QoS, 446 commas (,) for prefix adding, 125 Committed Access Rate (CAR), 456 committed burst (Bc), 506
9/20/11 1:38:38 PM
Committed Information Rate (CIR) – cRTP (compressed RTP)
Committed Information Rate (CIR), 500–501 Common Channel Signaling (CCS), 56, 61–62 companding, 55 compatibility codecs, 158–159 ephone-DN line, 163 inline power switches, 284–285 complexity of codecs, 156–160, 164 compressed RTP (cRTP) header compression, 166 overhead, 82–83 compression analog-to-digital conversion, 54–55 CB header, 512–513 end-to-end delays, 442 link efficiency, 457–458, 458 packets, 493 compression command, 493 compression header ip command, 512 conf-dial-peer mode, 359–360 conf-serv-sip mode, 306 conf-voi-serv mode CUBE, 422 fax pass-through, 364 fax relay, 360 H.323, 227, 229 modem pass-through, 367 SIP, 248 conference calling, 147, 147 config-class mode, 232 config-cm-fallback mode, 376–377 config-cmap mode, 490 config-controller mode T1 CAS, 192 T1 PRI, 196 config-dial-peer mode, 354 fax pass-through, 364 H.323, 354 outbound dial peers, 214 SIP, 242–243, 425 config-dp-cor mode, 374 config-dsp-farm-profile mode, 199 config-ephone mode, 330, 332 config-ephone-dn mode, 308 config-ephone-type mode, 309 config-gk mode, 406, 411–412 config-if mode AutoQoS, 475, 488 MLP, 509 QoS, 495 trust boundaries, 513
bindex.indd 537
537
config-pmap mode, 493 config-pmap-c mode, 493, 512 config-register-global structure, 306 config-sccp-ccm mode, 201 config-serv-h323 mode, 231 config-serv-sip mode, 242, 247 config-sip-ua mode, 240–241, 243–247 config-telephony mode, 300, 304–305, 310,
325, 329 config-voi-serv mode, 242, 359, 425 config-voicecard mode, 158 config-voiceport mode, 180–181, 207 configure terminal command, 47–50
conflicts, IP address, 293 conform-actions with token buckets, 502–504, 502–503 Confucius, 170 Congestion informational signals, 38 congestion management avoidance techniques, 498–500, 499 baseline congestion, 463 DiffServ, 453–455 connect timer, 245 connect voice-port command, 194 CONNECTED ephone extension state, 336, 338–339 connection plar command, 183 Contributing Source (CSRC) field in RTP headers, 81 controller command, 63 conversion, analog-to-digital. See analog-todigital conversion COR (Class of Restriction), 372–377, 373 CoS (Class of Service), 445, 459–460, 459– 460 cos option class maps, 491 trust boundaries, 514 CoS-to-DSCP mappings, 514–516, 515, 519–520 country codes E.164 telephone numbers, 113–114 FXS ports, 47–48 progress tones, 181–182 CP (call progress) tones, 38 cp-tone command, 47 CPE (customer premise equipment), 35 cptone command, 181–182 CQ (custom queuing) mechanism, 454 CRC (cyclic redundancy check) feature, 58 CRCX (create connection) command, 256 create cnf-files command, 305 create profile command, 307 cRTP (compressed RTP)
9/20/11 1:38:38 PM
538
cRTP (compressed RTP) – deployment models
cRTP (compressed RTP) (continued) header compression, 166 overhead, 82–83 CS (Class Selector) PHB, 453 csim start command, 209 CSRC (Contributing Source) field in RTP headers, 81 CSRC counter field in RTP headers, 80 CUBE. See Cisco Unified Border Element (CUBE) CUCM (Cisco Unified Communications Manager), 16, 420 configuring, 201–202, 202 gatekeepers, 89–90 IP soft phones, 13–14 RTP, 79 CUCM Express, 281–282 capabilities, 294–295 date and time format, 328 default phone configuration file, 304–305 ephones button options. See button separator options for ephone extension states, 336–339 registration states, 335–336 state, 334–335 exam essentials, 340–341 firmware load files, 303–304, 304 hands-on labs, 342–345, 342 hardware requirements, 295 initial configuration, 297–298 IP phone keepalive timer, 329 restart vs. reset, 329–332 overview, 293–294 review questions, 346–351 SCCP ephone configuration, 308–310, 314–317 ephone directory number, 308 ephone-DN line configuration, 311–313, 313–314 individual lines, 317–318 phone operation, 343–344 signaling, 300–305, 301–304 SIP signaling, 305–307 voice register DNs, 310–311 software licensing, 296–297 summary, 339 as TFTP server, 298–300, 342–343 troubleshooting DHCP, 332–333 phone registrations, 332 TFTP, 333–334
bindex.indd 538
user locale and network locale, 325–328 voice network infrastructure power options for IP phones, 282–286 VLANs, 286–290, 287, 289 VoIP support, 290–293 written lab, 341–342, 352 CUCMBE (Cisco Unified Communications Manager Business Edition), 16 CUCME (Cisco Unified Communications Manager Express), 16, 294–295 custom queuing (CQ) mechanism, 454 customer premise equipment (CPE), 35 cyclic redundancy check (CRC) feature, 58
D D (delta) channel, 61 date-format command, 328 date format in CUCM Express, 328 de-jitter buffer delay, 152 debug dialpeer command, 209–210 debug ip dhcp server events command, 332 debug ras command, 415–416 debug tftp events command, 333 debug voice translation command, 134 debug voip dialpeer command, 134 debug voip ipipgw command, 426–427 DECEASED ephone registration state, 335–337 default command, 412 default-technology keyword, 409 defaults DHCP routers, 291–292 dial peer 0, 112 PHB, 451 phone configuration files, 304–305 SIP retry settings, 246 zone bandwidth, 412 delay, network, 151–152 delay-dial command, 50 delay-dial E&M signaling, 46, 46 delayed offer in SIP, 238, 238 delayed-to-early-offer signaling, 425 delta (D) channel, 61 demarcation point (demarc) points, 5, 5 deployment models, 20 centralized services, 20, 21 distributed services, 21, 21 geographical diversity, 22–23, 23 inter-networking of services, 22, 22
9/20/11 1:38:39 PM
deregulation – digital voice
deregulation, 8 destination-address mac option, 491 destination-pattern command
dial-plan digit manipulation, 123 DNIS, 112 FSX ports, 184 outbound dial peers, 112–113, 214 POTS dial peer, 109 SIP, 270 tool bypass, 385–386 VoIP dial peers, 109 wildcards, 117–120, 119, 121 detector state in voice port tests, 207 dhcp-config mode, 291 DHCP relay command, 292 DHCP (Dynamic Host Control Protocol) services monitoring and troubleshooting, 292–293, 332–333 for voice, 290–292 dial peer 0, 112 dial-peer command FSX ports, 184 H.323, 228 dial-peer cor custom command, 374 dial-peer voice command, 214 H.323, 227 POTS, 109 SIP, 270 tool bypass, 385–386 VoIP, 109 dial-peer voice 911 pots command, 214 dial peers gatekeeper interoperations, 410–411 inbound rules, 111–112 outbound rules, 112–113 POTS, 372, 381 T1 CAS, 194 wildcards, 117–121, 119, 121 dial-plan digit manipulation, 104, 123 digit stripping, 123–124 forwarding last X digits, 124–125 number substitution, 126–127 prefixes, 125 translation rules and profiles, 127–132 verifying, 132–134 dial plan path-selection process, 104 call routing, 108–111, 110–111 International Numbering Plan, 113–114, 114 NANP, 114–116, 115 private plans, 116–117 PSTN, 113
bindex.indd 539
539
site-code dialing, 122–123, 122 strategies, 111–113 voice call types, 104–108, 105–108 wildcards, 117–121, 119, 121 Dial tone informational signals, 38 dial-type command, 49, 183 Dialed Number Identification Service (DNIS) interfaces, 111–112 DID (direct inward dial) inbound ports, 184–187, 185 PSTN, 116 ranges and extensions, 122 Differentiated Services (DS) byte, 449–450, 450 Differentiated Services Code Point (DSCP), 445, 451–453, 451, 514 DiffServ QoS model, 448–449, 453 congestion avoidance, 455 congestion management, 453–455 link-efficiency techniques, 457–459, 458 traffic policing and shaping, 455–457, 456– 457 DiffServ ToS/DS byte, 449–450, 450 digit-collection methods, IP phones, 305–306 digit-drop keyword, 355–356 digit manipulation. See dial-plan digit manipulation digit stripping, 123–124 digital ports, 56 configuring, 63–65 CUCM, 201–202, 202 DSP profiles, 199–200 SCCP, 200–201 T1 CAS to analog cross-connect, 191–195, 191 T1 PRI, 195–198, 195 digital signal processors (DSPs), 18, 146, 156–159 chipsets, 157–160 CUCM configuration, 201–202, 202 delay from, 152 exam essentials, 210–211 farms, 198–199, 198 profiles, 199–200 SCCP communications, 200–201 status, 205–206 summary, 210 voice gateway functions, 146–147, 147 written lab, 211 digital telephones, 3 digital trunks, 54 digital voice, 51
9/20/11 1:38:39 PM
540
digital voice – ECN (explicit congestion notification)
digital voice (continued) analog-to-digital conversion, 51–55, 52–54 exam essentials, 66–67 framing, 57–58, 58 multiplexing, 56–57, 57 physical transport, 59, 59–60 port configuration, 63–65 port types, 56 review questions, 69–74 signaling, 60–63 summary, 66 written lab, 67–68, 75 dir flash command, 298–299, 343 direct inward dial (DID) inbound ports, 184–187, 185 PSTN, 116 ranges and extensions, 122 direct-inward-dial command, 185–186 directory aliases, 299 discard-class command, 491 disconnect timer, 245 discovery messages in H.323, 399–400 discrete signals, 52 distributed call-control systems, 93 distributed services deployment model, 21, 21 DLCX (delete connection) command, 256 DNIS (Dialed Number Identification Service) interfaces, 111–112 DNs configuring, 301–302 SCCP, 308 SIP voice register, 307, 310–311 DNS servers, 291–292 dollar signs ($) in regular expressions, 128–129 domain names, 87, 291–292 DOWN ephone extension state, 336–337 drop option, 493 drop precedence, 452 dropped calls, 159 ds0-group command MGCP, 259 T1 CAS circuits, 64, 193–194 DSCP (Differentiated Services Code Point), 445, 451–453, 451, 514 dscp command class maps, 491 trust boundaries, 514 dscp-based command, 498 DSCP or IP Precedence Value setting, 499 DSCP-to-CoS mappings, 514 dspfarm_assist keyword, 309
bindex.indd 540
DSPs. See digital signal processors (DSPs) DTMF (dual-tone multi-frequency), 36, 37 dtmf command, 49 dtmf-package packages, 258–259, 356 dtmf-relay command, 354, 356 DTMF relay support, 354 H.323, 354–355 MGCP, 356 SIP, 355–356 dual-bucket traffic, 502–504, 502–503 dual-line phones, 315–317 dual-tone multi-frequency (DTMF), 36, 37 dynamic auto trunk mode, 288 dynamic desirable trunk mode, 288 dynamic gatekeeper discovery, 400 Dynamic Host Control Protocol (DHCP) services monitoring and troubleshooting, 292–293, 332–333 for voice, 290–292
E E.164 standard, 113–114, 114 E wire in E&M signaling, 42 E1 ports, 56 E&M ports and signaling, 35, 41–42 configuring, 50 line-seizure, 43–46, 44– 46 physical wiring types, 42–43 trunks, 187–188, 187 E911 calling outbound dial peers, 214 ports, 213 trunks, 188–189, 189 X11 services, 116 Early Media in H.323, 226, 226 early-offer forced command, 425 early offer in SIP, 237, 237 earth wire in E&M signaling, 42–43 echo and echo cancellation, 148–149 echo-cancel command, 149 echo return loss (ERL) levels, 207, 209 ECM (error correction mode), 361–362 ecm command, 362 ecm disable command, 361 ECN (explicit congestion notification), 451
9/20/11 1:38:40 PM
edge devices – filters, low-pass
edge devices, 3 EF (Expedited Forwarding) PHB, 452 egress interface traffic, 445 802.1Q trunk links, 289 802.3af standard, 284–285 email, TIFF-attached, 366 emergency calls outbound dial peers, 214 ports, 213 trunks, 188–189, 189 X11 services, 116 en-bloc digit collection, 305–306 encapsulation, trunk, 288 encapsulation ppp command, 510 encoding process in analog-to-digital conversion, 53–54, 54 encryption payloads, 83 SIP passwords, 240 end command, 213 end-to-end delays, 442 endpoints, 11 analog-to-IP adapters, 15 codec issues, 164 gatekeepers for, 90 IP soft phones, 13–14 private plans, 117 SIP availability, 239 capabilities, 237–239, 237–238 locations, 237 video phones and tablets, 14, 14 wired IP phones, 12–13 enterprises AutoQoS for, 483, 484 wired IP phones, 12–13 EPCF (endpoint configuration) command, 256 ephone-config mode, 318 ephone-dn command, 344 ephone-DNs configuring, 301–303, 302–303 dual- and octo-lines, 315–317 SCCP line configuration, 311–313, 313–314 two with one number, 314–315 ephone-type command, 309 ephones, 307 button options. See button separator options for ephone configuring, 301–303, 302–303 directory number, 308 extension states, 336–339
bindex.indd 541
541
registration states, 335–336 SCCP configuration, 308–310 state, 334–335, 344–345 ERL (echo return loss) levels, 207, 209 error correction mode (ECM), 361–362 ESF (Extended Super Frame), 58, 58 exceed-action for token buckets, 502–505, 502–503 excess burst (Be) rate, 506 exit command, 213 expansion line (x) ephone button separator, 319, 324 Expedited Forwarding (EF) PHB, 452 expires timer, 245 explicit congestion notification (ECN), 451 Extended Super Frame (ESF), 58, 58 extension field in RTP headers, 80 extension states for ephones, 336–339 extensions in PBX systems, 10, 317
F f (feature ring) ephone button separator, 318 f8 cipher mode, 83 fallback, 87 MGCP-to-H.323, 370–372, 371 WAN-to-PSTN, 369–370, 369 fallback keyword, 360 farms, DSP, 198–199, 198 fast command, 424 fast start in H.323, 226, 228–229 fast-to-slow signaling, 424–425 fax protocol t38 command, 359 fax rate command, 360 fax-relay command, 361 fax-relay ans-disable command, 362 fax-relay sg3-to-g3 command, 362 fax transmission package, 257 faxes fax relay, 357–359, 358 MGCP settings, 364, 364 pass-through, 364–365 SIP and H.323 settings, 360 T.37 store-and-forward, 365–367, 366 T.38, 362–363 feature licenses for CUCM Express, 296 feature ring (f) ephone button separator, 318 FIFO (first-in first-out) queuing mechanism, 453 filters, low-pass, 52
9/20/11 1:38:41 PM
542
firewalls in VoIP – H.323 gatekeepers
firewalls in VoIP, 80 firmware load command, 307 firmware load files, 303–304, 304 first-in first-out (FIFO) queuing mechanism, 453 fixed-bytes setting, 230 fixed delay, 151–152 flex option, 160 flow option, 491 Foreign Exchange Office (FXO) ports, 35, 40 configuring, 49–50, 180–184, 180 outbound, 184–187, 185 Foreign Exchange Station (FXS) ports, 34 configuring, 47–49, 180–184, 180 inbound, 184–187, 185 forward-digits command, 124–125, 214 forward-digits all command, 214 forward-digits shutdown command, 191 FQDNs (fully qualified domain names), 406 fr-de option, 491 fr-dlci option, 491 Frame Relay, 510–512 frame-relay fragment command, 511 frames calculations, 165, 167–169, 169 compression techniques, 457–458, 458 digital voice, 57–58, 58 frame errors and packet loss, 443 size information, 165–166, 166 framing command, 63, 192 framing esf command, 213 FRF.12, 510–511 fully qualified domain names (FQDNs), 406 FXO (Foreign Exchange Office) ports, 35, 40 configuring, 49–50, 180–184, 180 outbound, 184–187, 185 fxr-package package, 257 FXS (Foreign Exchange Station) ports, 34 configuring, 47–49, 180–184, 180 inbound, 184–187, 185
G G.711 codec, 54–55, 154 G.711mu-law and G.711a-law, 364 G.722 codec, 155 G.723.1 codec, 154–155 G.726 codec, 155 G.728 codec, 155
bindex.indd 542
G.729 codec, 155–156 gatekeeper command, 406 Gatekeeper Confirm (GCF) message, 399–400 Gatekeeper Reject (GRJ) message, 399–400 Gatekeeper Request (GRQ) message, 399–400 gatekeepers. See H.323 gatekeepers gateway command, 411 gateway force option, 362 gateways. See voice gateways GCF (Gatekeeper Confirm) message, 399–400 generic traffic shaping (GTS), 506 geographical diversity deployment model, 22–23, 23 glare, 40 gm-package packages, 258–259 Goodbye RTCP packets, 82 GRJ (Gatekeeper Reject) message, 399–400 ground-start signaling, 40–41, 41 ground wire in supervisory signaling, 38–39 groundstart signaling, 181 group 3 fax machines, 357 growth, dialing plans for, 113 GRQ (Gatekeeper Request) message, 399–400 GSM Full Rate (GSMFR) codec, 156 GTS (generic traffic shaping), 506 gw-controlled command, 368 gw-priority command, 407 gw-type-prefix command, 408, 430
H H.225 protocol description, 85 settings, 231–232 timers, 232–233 H.235 protocol, 85 H.245 protocol, 85 H.323 gatekeepers, 89–91, 89–90, 396 address translation, 398 bandwidth control, 398 bandwidth management, 399 call admission control, 398, 411–414, 413 call authorization, 398–399 call management, 399 configuration overview, 405, 405 debug ras command, 415–416 dial peers, 410–411
9/20/11 1:38:42 PM
H.323 protocol – input-interface option
enabling, 411 exam essentials, 427–428 hands-on labs, 429–431, 429 interface commands, 409–410 overview, 396 RAS messages, 399–400 bandwidth, 404–405 call admission, 400–401 location, 402–404, 402– 404 registration, 400 resource availability, 404 review questions, 432–437 sample network, 401–402, 401 show gatekeeper calls command, 414–415 show gatekeeper endpoints
command, 415 show gatekeeper status command, 414
signaling, 399–401 summary, 427 technology prefixes, 408–409 written lab, 428–429, 438 zones local, 406 managing, 397–398, 397 prefixes, 407 remote, 406–407 H.323 protocol codec preference, 229–231 DTMF relay, 354–355 fast and slow start connections, 228–229 fast-to-slow signaling, 424–425 fax settings, 360 gatekeepers. See H.323 gatekeepers gateway configuration, 227–228, 228 H.225 settings, 231–233 MCU, 91–92 MGCP-to-H.323 fallback, 370–372, 371 overview, 84–85, 224–226, 224–226 proxy servers, 91 sample network, 92–93, 92 session transport mode, 231 show gateway command, 234 show h323 gateway h225 command, 234–236 T.38 fax relay with, 359–360 virtual gateway addresses, 233–234, 233 H.450 protocol, 85 h225 timeout setup command, 233 h225 timeout tcp call-idle command, 232 h225 timeout tcp establish command, 232 h245-alphanumeric method, 355 h245-signal method, 355
bindex.indd 543
543
h323-gateway voip command, 409 h323-gateway voip interface
command, 431 h323-id command, 410
hardware codec compatibility, 163 CUCM Express, 295 voice gateways, 18–19, 19 header compression, 458 header fields in RTP, 80–81 high-complexity codec calls, 157–160 high-speed fax relay redundancy, 359 house wiring, 5 hs-redundancy option, 359–360 hs_redundancy option, 362 huntstop command, 315–316 huntstop channel command, 316 hybrid systems, 323 hyphens (-) in dates, 328
I id keyword, 410 identifier setting, 200 IDLE ephone extension state, 336–337
IEEE 802.3af standard, 284–285 IETF (Internet Engineering Task Force) protocols, 85 IFP (Internet fax packets), 358 ignored packets, 443 iLBC (Internet Low Bit Rate Codec), 156 ILP (inline power) functionality, 283–286 immediate signaling type, 50 immediate-start E&M signaling, 44, 44 impedance FXS ports, 48 mismatches, 149 impedance command, 207 implementation phase in AutoQoS, 488 inbound calls, translation profiles for, 132 inbound dial-peer rules, 111–112 inbound SIP transport protocols, 243–244 incoming called-number command, 111–112, 185 informational signaling, 35, 37–38 inhibit command, 362 inject-tone state, 207 inline power (ILP) functionality, 283–286 input-interface option, 491
9/20/11 1:38:42 PM
544
input queue drops – IVR (interactive voice response)services
input queue drops, 443 installation phase in AutoQoS, 483 Integrated Services Digital Network (ISDN) BRI, 56, 61 with H.323, 224, 224 with MGCP, 253–254, 254 PRI, 62, 64–65, 195–198, 195 with SIP, 236, 236, 247–249, 247 Intelligent Power Management (IPM), 285–286 inter-networking of services deployment model, 22, 22 interactive voice response (IVR) services, 354 intercluster trunk calls, 108, 108 interdigit timeout, 118 interexchange networks, 9 interface binding, 233–234, 233 interface command for voice gateways, 409 interface commands for H.323 gatekeepers, 409–410 interface multilink command, 509 interface serial command, 213, 521 internal T1 CAS option, 63 international calling, 8, 9 international networks, 9 International Numbering Plan, 113–114, 114 Internet Engineering Task Force (IETF) protocols, 85 Internet fax packets (IFP), 358 Internet Low Bit Rate Codec (iLBC), 156 Internet Protocol Telephony (IPT), 11 Internet Speech Audio Codec (iSAC), 156 Internet Telephony Service Providers (ITSPs), 12, 154, 416, 421–422, 421– 422 interoffice trunks, 7–8, 8 interwork command, 424 interzone keyword command, 412 IntServ QoS model, 447–449 Invite SIP retry type, 246 IOS licenses, 296 IP addresses binding SIP sources to, 247 conflicts, 293 CUBE, 417 CUCM Express, 300–301, 301 DHCP monitoring and troubleshooting, 292–293, 332–333 for voice, 290–292 ip command for class maps, 491
bindex.indd 544
ip dhcp excluded address command, 291 ip dhcp pool command, 291 ip-helper address command, 292
IP networks bandwidth, 441–442 end-to-end delays, 442 jitter, 442 packet loss, 443–444, 443 SIP configuration, 239–241, 240 voice issues, 441–444, 443 voice/video on, 440–441 IP phones digit-collection methods, 305–306 keepalive timers, 329 power options, 282–286 restart vs. reset, 329–332 soft phones, 13–14 VLAN configuration, 288–290, 289 wired, 12–13 wireless, 13 IP Precedence in ToS byte, 449–450, 450 ip source-address command, 307, 343 IP-to-IP gateways, 416 IP to PSTN translations, 87 IP/UDP header size, 165 IP voice bandwidth consumption, 164 calculations, 165, 167–169, 169 codec bit rate, 166–167 packet and frame size information, 165–166, 166 providing, 441–442 IPM (Intelligent Power Management), 285–286 IPSec, 166, 166 IPT (Internet Protocol Telephony), 11 iSAC (Internet Speech Audio Codec), 156 ISDN. See Integrated Services Digital Network (ISDN) isdn incoming-voice command, 197 isdn incoming-voice voice command, 213 isdn supp-service name calling
command, 248 isdn switch-type command, 64, 196 isdn switch-type primary-ni
command, 212 ISR router series, 19 ITSPs (Internet Telephony Service Providers), 12, 154, 416, 421–422, 421– 422 ITU-T T.38 fax relay, 358–359, 358 IVR (interactive voice response) services, 354
9/20/11 1:38:43 PM
jitter, network – MDCX (modify connection) command
J jitter, network, 152–153, 152, 442
K keepalive command, 329 keepalive timers, phone, 329 key systems, 10–11, 311–312
L languages in CUCM Express, 325–328 LATAs (Local Access and Transport Areas), 8 Layer 2 CoS, 459–460, 459– 460 Layer 2 header size, 165 LCF (Location Confirm) message, 402–404, 403 LdapDirectories.xml files, 334 leases, DHCP, 291–292 legacy PBX, 187–188, 187 LFI (link fragmentation and interleaving), 457–459, 509–512 licensing CUCM Express, 296–297 lightweight registration messages, 400 Lincoln, Abraham, 443 line command, 63 line-package packages, 256, 258 line seizure, 40 E&M signaling, 43–46, 44– 46 ephone extension state, 336–338 linecode command, 63, 192 linecode b8zs command, 213 link efficiency, 457, 508–509 compression, 457–458, 458, 512–513 LFI, 509–512 link fragmentation and interleaving (LFI), 457–459, 509–512 listener echo, 149 lists in regular expressions, 128 LLQ (Low Latency Queuing), 455 load files in CUCM Express, 303–304, 304 Local Access and Transport Areas (LATAs), 8 local calls, 105, 105 local loop, 5, 5 local name segment in MGCP, 87 local zones, 406 locales in CUCM Express, 325–328 Location Confirm (LCF) message, 402–404, 403
bindex.indd 545
545
location messages in RAS, 402–404, 402–404 Location Reject (LRJ) message, 402–403, 403 Location Request (LRQ) message, 402–404, 403 log option, 493 loop-start signaling, 39–40, 39, 181 loopback interface, 233–234, 233 loopback state in voice port tests, 207 loopstart signaling, 181 low-bit-rate keyword, 356 low-complexity codec calls, 157–160 Low Latency Queuing (LLQ), 455 low-pass filters, 52 low-speed fax relay redundancy, 359 low-speed WAN connections, 457 LRJ (Location Reject) message, 402–403, 403 LRQ (Location Request) message, 402–404, 403 ls-redundancy option, 359–360 ls_redundancy option, 362
M m (monitor line) ephone button separator, 318–320, 320 M wire in E&M signaling, 42 mac-address command, 310, 344 MAC addresses for ephones, 310 magnet wire in E&M signaling, 42–43 management, dialing plans for, 113 map-class frame-relay command, 511 maps class, 490–492 CoS-to-DSCP, 514–516, 515, 519–520 policy, 493–495 Mark Probability Denominator setting, 499 marker field in RTP headers, 81 marking traffic, 445 match-all command, 490, 492 match-any command, 490, 492 max-dn command, 302–303, 343 max-ephones command, 302, 343 max-forwards command, SIP, 246 max-pool command, 307 maximum sessions command, 199–200, 367 maximum sessions hardware command, 200 Maximum Threshold (Number Of Packets) setting, 499 MC (Multipoint Controller), 92 MCU (Multipoint Control Unit), 91–92 MDCX (modify connection) command, 256
9/20/11 1:38:44 PM
546
Mean Opinion Score (MOS) test – NIST
Mean Opinion Score (MOS) test, 161–162 media flow-around, 418–419, 419, 423 media flow-around command, 423 media flow-through, 418, 418 Media Gateway Control Protocol (MGCP), 87–88 DTMF relay, 356 fallback, 87, 370–372, 371 fax relay with, 362–363 fax settings, 364, 364 overview, 253–254, 254 residential gateways, 254–255, 255, 257–259, 258 show ccm-manager command, 264–265 show mgcp command, 261–263 show mgcp profile command, 260–261 show mgcp statistics command, 263–264 trunking gateways, 255–257, 255, 259–260, 260 media termination point (MTP), 146–147 medium-complexity codec calls, 157–160 mgcp call-agent command, 257, 259
show class-map command, 496 show policy-map command, 496 show policy-map interface command,
496–497 MOH (music on hold), 150 monitor line (m) ephone button separator, 318–320, 320 monitoring DHCP service, 292–293 MOS (Mean Opinion Score) test, 161–162 MP (Multipoint Processor), 92 mpls option, class maps, 491 MQC. See modular QoS CLI (MQC) method MTP (media termination point), 146–147 mu-law codecs, 365 multilink PPP (MLP), 509–510 multiplexing, 54, 56–57, 57 Multipoint Control Unit (MCU), 91–92 Multipoint Controller (MC), 92 Multipoint Processor (MP), 92 music on hold (MOH), 150
mgcp dtmf-relay voip codec mgcp mgcp mgcp mgcp
command, 356 fax rate command, 363 fax t38 command, 362 fax t38 inhibit command, 365 modem passthrough voip mode nse
command, 365 mgcp modem relay voip mode command, 368 mgcp package-capability command, 257–258 mgcp package-capability rtp-package
command, 365 mgcp timer nse-response t38
command, 363 MGCP-to-H.323 fallback, 370–372, 371 mgcp tse payload command, 363 Minimum Threshold (Number Of Packets) setting, 499 minus signs (-) in regular expressions, 128 MLP (multilink PPP), 509–510 mls qos command, 482 mls qos map command, 516 mls qos trust command, 513–514 mls qos trust cos command, 519 mode cme command, 306 modem relay command, 368 modems, 367 pass-through, 367–368 relay, 368 modular QoS CLI (MQC) method, 447 policies using, 488–498, 489, 520–521
bindex.indd 546
N named service events (NSE), 359 NANP (North American Numbering Plan), 114–116, 115, 190 narrowband communication, codecs for, 154 narrowband sampling, 148, 148 national calling PSTN, 8, 9 National Destination Code (NDC), 113–114 National Institute of Standards and Technology (NIST), 293 NBAR (Network-Based Application Recognition) feature, 475 NDC (National Destination Code), 113–114 netflow-sampler option, 493 Network-Based Application Recognition (NBAR) feature, 475 network capacity in codec selection, 164 network delay, 151–152 network infrastructure, 20 network jitter, 152–153, 152 network-locale command, 326–327 network locales in CUCM Express, 325–328 network-number command, 127 Network Time Protocol (NTP), 290, 293 never command in PoE, 285 9951 IP video phone, 14 NIST (National Institute of Standards and Technology), 293
9/20/11 1:38:45 PM
no command in QoS policy maps – pass-through keyword
no command in QoS policy maps, 493 no digit-strip command
CAMA, 191 forwarding digits, 124–125 tool bypass, 385 WAN-to-PSTN fallback, 369 no huntstop command, 315, 321 no maximum sessions command, 200 no shutdown command CAMA, 190–191, 213 DSP profiles, 199 FSX ports, 182 H.323 service, 411 local zones, 406 voice port tests, 207 VoIP service, 227 noise, background, 149–151, 150 non-standard facilities (NSF) code, 362 none keyword in SIP, 248 normal ring (:) ephone button separator, 318 North American Numbering Plan (NANP), 114–116, 115, 190 not option for class maps, 491 NPD (Numbering Dialing Plan) in emergency calls, 190 NSE (named service events), 359 nse keyword modem pass-through, 367 T.38 fax relay, 359 NSF (non-standard facilities) code, 362 nsf option, 362 NTFY (notify) command, 256 NTP (Network Time Protocol), 290, 293 ntp server command, 293 NULL ciphers, 83 NULL rules, 129 num-exp command, 126 number command, 310–311 Number not in service informational signals, 38 number substitution, 126–127 Numbering Dialing Plan (NPD) in emergency calls, 190 Nyquist, Harry, 52 Nyquist Sampling Theorem, 52, 52
O o (overlay line) ephone button separator, 319–323 octo-line phones, 315–317
bindex.indd 547
547
off-hook state pulse dialing, 36 supervisory signaling, 38–39, 39 off-net calls, 106, 106 off-premises extension (OPX), 180 off-ramp gateways, 366–367, 366 on-hook state pulse dialing, 36 supervisory signaling, 38–39, 39 on-net calls, 105, 105 on-net-to-off-net calls, 106, 107 on-ramp gateways, 366–367, 366 one-stage dialing, 186 operation command, 50 option command in DHCP, 291 OPX (off-premises extension), 180 out-of-band signaling, 61 outbound calls, translation profiles for, 132 outbound dial peers to PSAP, 214 to PSTN, 214 rules, 112–113 outbound SIP transport protocols, 243–244 overlay line (o) ephone button separator, 319–323 overlay with call waiting (c) ephone button separator, 319, 323–324 override keyword in trust boundaries, 515 overruns, packet loss from, 443
P packages, 256–259 packet loss concealment (PLC) methods, 153 packet option for class maps, 491 packetization delay, 152 packets information for, 165–166, 166 loss of, 153, 443–444, 443 packets per second (PPS), 165, 167–168 padding field in RTP headers, 80 PAM (pulse-amplitude modulation), 51 parent maps, 494 parentheses () destination pattern wildcards, 120 in regular expressions, 128–130 pass-through fax, 364–365 modems, 367–368 pass-through keyword, 360
9/20/11 1:38:45 PM
548
pass-through dscp keywords – primary-5ess command
pass-through dscp keywords, 514
passwords in SIP, 240 Payload Encryption packets, 83 payload type field in RTP headers, 81 PBX (private branch exchange) systems, 10 E&M trunks with, 187–188, 187 extensions, 317 PBX-to-PBX calls, 107, 107 PBX-to-PBX switch connections, 40 PBX-to-PSTN switch connections, 40 PCM (pulse-code modulation), 53, 53, 55, 154 peak information rate (PIR), 504 peak keyword, 506 peer-to-peer architecture, 84–85 peer-to-peer protocols H.323, 224 SIP, 236 UDP, 86 per-hop behaviors (PHB), 451–453 percent signs (%) in destination pattern wildcards, 120 Perceptual Evaluation of Speech Quality (PESQ) measure, 163 Perceptual Objective Listening Quality Analysis (POLQA), 163 Perceptual Speech Quality Measure (PSQM), 162–163 periods (.) destination pattern wildcards, 118–119, 119 in regular expressions, 128–130 PESQ (Perceptual Evaluation of Speech Quality) measure, 163 phantom power, 283 PHB (per-hop behaviors), 451–453 phone configuration files, 304–305 phone registrations, 332 phone switches, 3–4 phones, IP. See IP phones physical transport in digital voice, 59, 59–60 physical wiring in E&M signaling, 42–43 PIR (peak information rate), 504 PLAR (Private Line Automatic Ringdown), 180–184 PLC (packet loss concealment) methods, 153 plus signs (+) destination pattern wildcards, 120 in regular expressions, 128 PoE (Power over Ethernet) switches, 283–285 police command, 493, 504 policy-map command, 489, 492–493 policy-map voice-policy command, 521
bindex.indd 548
policy maps, 493–495 QoS, 489 service policies, 495 POLQA (Perceptual Objective Listening Quality Analysis), 163 pools DHCP, 291 voice register, 311 port command outbound dial peers, 214 POTS dial peer, 109 ports analog voice configuring, 47–50 types, 34–35 digital. See digital voice inbound dial-peer rules, 112 POTS dial peers, 108–109, 372, 381 power IP phones, 282–286 supervisory signaling, 38, 40 power bricks, 282–283 power injectors, 283 power inline command, 285 Power over Ethernet (PoE) switches, 283–285 powered patch panels, 283 ppp multilink command, 510 ppp multilink fragment-delay
command, 510 ppp multilink-group command, 510 ppp multilink interleave command, 510
PPP multilink LFI configuration, 478 PPS (packets per second), 165, 167–168 PQ (priority queuing), 454–455 prec-based keyword, 498 precedence option, 491 predictor compression method, 458 preference command ephone DNs, 314–315 overlay lines, 321 tool bypass, 385 WAN-to-PSTN fallback, 369 prefix adding, 125 prefix command, 125 CAMA, 191 tool bypass, 385 prefixes technology, 408–409 zone, 407 PRI (Primary Rate Interface), 62, 64–65, 195–198, 195 pri-group timeslots command, 65, 213 primary-5ess command, 65
9/20/11 1:38:46 PM
primary-qsig command – Quality of Service (QoS)
primary-qsig command, 65 Primary Rate Interface (PRI), 62, 64–65, 195–198, 195 priorities call-processing units, 201 end-to-end delays, 442 gateways, 408 IP Precedence, 450 QoS policy maps, 493 traffic marking, 445 priority percent command, 521 priority queuing (PQ), 454–455 priority setting QoS policy maps, 493 SCCP, 200 private branch exchange (PBX) systems, 10 E&M trunks with, 187–188, 187 extensions, 317 Private Line Automatic Ringdown (PLAR), 180–184 private numbering plans, 116–117 private switches, 4 private telephone systems, 2, 9–10 profiles dial-plan digit manipulation, 127–132 DSP, 199–200 translation, 131–132 propagation delay, 151–152 protocol internetworking, 417 protocol interoperation, 422–423, 423 protocol option for class maps, 491 proxies, CUBE, 417 proxy servers H.323, 91 SIP, 86–87, 246–247 PSAPs (Public Safety Answering Points) CAMA trunks, 189 outbound dial peers to, 214 PSQM (Perceptual Speech Quality Measure), 162–163 public switched telephone network (PSTN), 3, 8–9, 9 central office, 4–5, 4 local loop, 5, 5 with MGCP, 253–254, 254 number substitution, 126 numbering plan, 113 outbound dial peers to, 214 redundancy, 385–386 with SIP, 247–248, 247 termination, 146 WAN-to-PSTN fallback, 369–370, 369
bindex.indd 549
549
public telephone systems, 2 pulse-amplitude modulation (PAM), 51 pulse-code modulation (PCM), 53, 53, 55, 154 pulse command, 49 pulse dialing, 36, 36 pulse interval command, 182 PVDM (C549 DSP chipset), 157–158 PVDM2 (C5510 DSP chips), 157, 159–160 PVDM3 (C5510 DSP chips), 157, 159
Q Q.921 signaling, 253 Q.931 signaling, 62, 253 Q signaling (QSIG), 62–63 QoS. See Quality of Service (QoS) qos-group option, 491 QSIG (Q signaling), 62–63 quality considerations, 147–148 audio fidelity, 148, 148 background noise, 149–151, 150 echo and echo cancellation, 148–149 network delay, 151–152 network jitter, 152–153, 152 packet loss, 153 Quality of Service (QoS), 439–440 AutoQoS. See AutoQoS baseline models, 461–463, 462 Best-effort model, 447, 449 class-based, 488–489 class maps, 490–492 command line interface, 446 congestion management, 453–455, 463, 498–500, 499 CoS-to-DSCP mappings, 514–516, 515 DiffServ model, 448, 453–459 DiffServ ToS/DS byte, 449–450, 450 DSCP method, 451–453, 451 exam essentials, 464–465, 517 hands-on labs, 518–521, 518 IntServ model, 447–448 Layer 2 classification, 459–460, 459– 460 link efficiency techniques, 457–458, 458, 508–513 mitigating IP network voice issues, 441–444, 443 models comparison, 448 policies
9/20/11 1:38:47 PM
550
Quality of Service (QoS) – Resource Reservation Protocol (RSVP)
Quality of Service (QoS) (continued) considerations, 445–447 using MQC, 488–498, 489 policy maps, 493–495 review questions, 466–471, 522–527 settings, 153 show class-map command, 496 show policy-map command, 496 show policy-map interface command, 496–497 summary, 464, 517 three-step process, 444–445 traffic policing and shaping, 455–457, 456– 457, 500–508, 502–503, 505 trust boundaries configuring, 513–515, 513 identifying, 460–461, 461 voice/video on IP networks, 440–441 written lab, 465, 472, 518, 528 quantization in analog-to-digital conversion, 53, 53 question marks (?) destination pattern wildcards, 120 in regular expressions, 128 queue-limit option, 493 queuing delay, 152 traffic, 445, 456
R R wire in E&M signaling, 42 R1 wire in E&M signaling, 42 RAC (Resource Availability Confirmation), 404 RAI (Resource Availability Indicator), 404 random-detect command, 493, 498 Random Early Detection (RED) tool, 455, 498 RAS. See Registration Admission and Status (RAS) messages RBS (robbed-bit signaling), 60 RCF (Registration Confirm) message, 400 Real-time Transport Control Protocol (RTCP), 81–82 Real-time Transport Protocol (RTP), 17, 78–81 header fields, 80–81 header size, 165 Receiver off-hook informational signals, 38 Receiver Report packets, 81
bindex.indd 550
RED (Random Early Detection) tool, 455, 498 redirect-called type, 131 redirect servers maximum, 246–247 SIP with ISDN, 247–249, 247 redundancy gateways, 407–408 modem pass-through, 367 PSTN, 385–386 redundancy keyword, 367 register device-name command, 201 register servers, 87 REGISTERED ephone registration state, 335–339 registrar server command, 306 Registration Admission and Status (RAS) messages, 398 bandwidth, 404–405 call admission, 400–401 location, 402–404, 402– 404 registration, 400 resource availability, 404 Registration Confirm (RCF) message, 400 registration messages, 400 Registration Reject (RRJ) message, 400 “Registration Rejected” message, 302, 303 Registration Request (RRQ) message, 400 registration states for ephones, 335–336 registrations, phone, 332 regular expressions, 128 relay fax, 357–359, 358, 362–363 modem, 368 relay state in voice port tests, 207 remote keyword, 412 remote zones in H.323, 406–407 Reorder informational signals, 38 repeaters for analog signal, 51 Replay Protection packets, 83 reset, IP phone, 330–332 reset command, 330 reset all command, 330 residential gateways, 254–255, 255, 257–259, 258 Resource Availability Confirmation (RAC), 404 Resource Availability Indicator (RAI), 404 resource availability messages, 404 Resource in Progress (RIP), 404 Resource Reservation Protocol (RSVP) CAC, 420, 420 QoS, 448
9/20/11 1:38:48 PM
Response retry type – Session Initiation Protocol (SIP)
Response retry type, 246
sccp local command, 200
restart, IP phone, 329–330 restart command, 330 restart all command, 329 retries, SIP, 245–246, 270–271 retry invite command, 271 retry response command, 271 right-to-use licenses, 297 Ring-back informational signals, 38 ring cadence command, 182 ring frequency command, 182 ring number command, 183 RINGING ephone extension state, 336, 338 ringing time, 149 RIP (Resource in Progress), 404 robbed-bit signaling (RBS), 60 rotary dialing, 36, 36 routers DHCP, 291–292 Enterprise, 483, 484 VoIP on, 475–479, 476 RQNT (request for notification) command, 256 RRJ (Registration Reject) message, 400 RRQ (Registration Request) message, 400 RSIP (restart in progress) command, 256 RSVP (Resource Reservation Protocol) CAC, 420, 420 QoS, 448 RTCP (Real-time Transport Control Protocol), 81–82 RTP (Real-time Transport Protocol), 17, 78–81 header fields, 80–81 header size, 165 rtp-nte method, 355–356 rtp-package packages, 258–259
SDP (Session Description Protocol) with MGCP, 254 with SIP, 237–238, 238 second-number strip command, 127 secure codec option, 160 secure RTP (sRTP), 83, 242–243 secure RTP packages, 257 security CUBE deployment, 417 SIP, 241–243 voice packets, 166, 166 Segmented Integer Counter Mode cipher mode, 83 SEIZE ephone extension state, 336–338 seizure, line, 40 E&M signaling, 43–46, 44– 46 ephone extension state, 336–338 Sender Report packets, 81 separators, button. See button separator options for ephone sequence field in RTP headers, 81 serialization delay, 152, 458 service policies policy maps, 495 QoS, 489 service-policy command, 489, 493–495, 513 service-policy output voice-policy command, 521 service-type mgcp command, 257 Session Description Protocol (SDP) with MGCP, 254 with SIP, 237–238, 238 Session Initiation Protocol (SIP), 17, 85–87 basic configuration, 269–270 call signaling, 12 CUCM signaling, 305–307 delayed-to-early-offer signaling, 425 DTMF relay, 355–356 endpoints availability, 239 capabilities, 237–239, 237–238 locations, 237 ephone-DN line compatibility, 312 fax relay with, 359–360 fax settings, 360 IP voice gateways, 239–241, 240 overview, 236–237 register servers, 87 secure communications, 241–243 sessions, 239 show sip-ua calls command, 252–253 show sip-ua retry command, 252
S s (silent ring) ephone button separator, 318 sampling analog-to-digital conversion, 52–53, 52 audio fidelity, 148, 148 SB (signal battery) wire, 42–43 SB-ADPCM (Sub-Band Adaptive Differential Pulse Code Modulation), 155 SBCS (Smart Business Communications System) suite, 12 SC (Subscriber Code), 113–115 SCCP. See Skinny Client Control Protocol (SCCP) sccp cucm group command, 201
bindex.indd 551
551
9/20/11 1:38:48 PM
552
Session Initiation Protocol (SIP) – signal ground (SG) wire
Session Initiation Protocol (SIP) (continued) show sip-ua statistics command, 249–251 show sip-ua status command, 251 show sip-ua timers command, 252 timers and retries, 270–271 voice gateway settings, 243 binding sources to IP addresses, 247 inbound and outbound transport protocols, 243–244 ISDN call-ID blocking, 249 ISDN interoperation settings, 247–248, 247 proxy and redirect servers, 246–247 signaling retries, 245–246 signaling timers, 244–245 voice register DNs, 310–311 voice register pools, 311 session keyword, gatekeepers, 412 session protocol sipv2 command, 241, 270, 355 session target command SIP, 270 tool bypass, 385 VoIP dial peer, 109 session target ipv4 command, 227, 241 session target ras command, 410 session target sip-server command, 241 session transport mode in H.323, 231
show dial-peer command, 132–133 show dialplan number command, 133–134 show ephone command, 321–323, 335–336,
session transport tcp calls-per-connection
show sip-ua retry command, 252, 271 show sip-ua statistics command,
command, 231 session transport udp command, 231
sessions, SIP, 239 set option in QoS policy maps, 493 7921G wireless IP phone, 13 7925G and 7925G-EX wireless IP phones, 13 7985G IP video phone, 14 SF (Super Frame), 57–58, 58 SG (signal ground) wire, 42–43 SG3 (Super Group 3) fax transmissions, 362 shape command, 493, 506 shared lines with ephone-DN, 312–313, 313–314 show auto discovery qos command, 485–487 show auto qos command, 477–478 show call active voice brief command, 425–426 show call history voice brief command, 426 show ccm-manager command, 264–265 show ccm-manager fallback-mgcp command, 372 show class-map command, 496 show connection all command, 195 show controller command, 205
bindex.indd 552
338, 344 show frame-relay fragment command, 512 show gatekeeper calls command,
414–415 show show show show
gatekeeper endpoints command, 415 gatekeeper status command, 414 gateway command, 227, 234 h323 gateway h225 command,
234–236 show show show show show show show show
ip dhcp binding command, 292–293 ip dhcp conflict command, 293 mgcp command, 261–263 mgcp profile command, 260–261 mgcp statistics command, 263–264 mls qos maps command, 516 policy-map command, 496 policy-map interface command,
495–497, 507–508 show power inline command, 286 show run interface fa0/1
command, 481 show run interface fastEthernet 0/5
command, 480 show sip-ua calls command,
252–253
249–251 show sip-ua status command, 251 show sip-ua timers command,
252, 271 show telephony-service tftp-bindings
command, 334 show vlan brief command, 290 show voice dsp command, 160,
205–206 show voice port command, 203–205 show voice port summary command,
196–197 show voip rtp connections command, 426 shutdown command
CAMA, 190–191, 213 voice port tests, 207 shutdown forced command, 227 side-car modules, 309 signal battery (SB) wire, 42–43 signal command for FSX ports, 181 signal cama command, 213 signal ground (SG) wire, 42–43
9/20/11 1:38:49 PM
signal groundstart command – Survivable Remote Site Telephony (SRST)
signal groundstart command, 49 signal loopstart command, 47
signaling analog voice, 35 address, 35–37, 36–37 E&M, 41–46, 44– 46 ground-start, 40–41, 41 informational, 37–38 supervisory, 38–41, 39, 41 call, 17, 17 digital voice, 60–63 gatekeeper, 399–401 retries, 245–246 timers, 244–245 signaling forward command, 248 signaling protocols with CUBE, 419, 419 voice gateway. See voice gateway signaling protocols silent ring (s) ephone button separator, 318 silent rings, 310 silent with beep (b) ephone button separator, 318 simplicity, dialing plans for, 113 single-bucket traffic, 502–503, 502–503 SIP. See Session Initiation Protocol (SIP) SIP ITSP, 421–422, 421– 422 sip-notify method, 356 SIP secure (SIPS) mechanism, 241 sip-server command, 241 sip-ua command, SIP, 271 SIPS (SIP secure) mechanism, 241 site-code dialing, 122–123, 122 sites in private plans, 117 size of frames, 165–166, 166 Skinny Client Control Protocol (SCCP), 17, 88 configuring, 200–201 CUCM Express, 300–305, 301–304 with DSP farms, 198, 198 ephone configuration, 308–310 ephone directory number, 308 ephone-DN line configuration, 311–313, 313–314 individual lines, 317–318 phone operation, 343–344 slashes (/) in dates, 328 in regular expressions, 128–130 slow command, 424 slow start connections in H.323, 228–229
bindex.indd 553
553
slow start initiation mode in H.323, 225, 225 small businesses, wired IP phones for, 12 Smart Business Communications System (SBCS) suite, 12 Smart Phone Control Protocol (SPCP), 12 soft phones, 13–14 software-activated voice licensing, 297 software licensing for CUCM Express, 296–297 source-address command, 307 source-address mac command, 491 source-bind feature, 247 Source Description packets, 82 source IP addresses in CUCM Express, 300–301, 301 SPA 300 and 500 series IP phones, 12 spare phones, 297 SPCP (Smart Phone Control Protocol), 12 square brackets ([]) destination pattern wildcards, 118–120, 120 in regular expressions, 128 SRST (Survivable Remote Site Telephony), 21 configuring, 376–377 with COR, 373, 373 with MGCP, 254 sRTP (secure RTP), 83, 242–243 srtp command, 242–243 srtp fallback command, 242–243 srtp-package package, 257 SSDC5, 43 SSRC (Synchronization Source Identifier) field in RTP headers, 81 stacker compression method, 458 standards for dialing plans, 113 states, ephones, 344–345 extensions, 336–339 registration, 335–336 static command, 285 station-id command, 182 store-and-forward fax, 365–367, 366 stripping, digit, 123–124 Sub-Band Adaptive Differential Pulse Code Modulation (SB-ADPCM), 155 Subscriber Code (SC), 113–115 substitution, number, 126–127 Super Frame (SF), 57–58, 58 Super Group 3 (SG3) fax transmissions, 362 supervisory signaling, 35, 38–41, 39, 41 Survivable Remote Site Telephony (SRST), 21 configuring, 376–377 with COR, 373, 373 with MGCP, 254
9/20/11 1:38:50 PM
554
switches and switchports – total keyword
switches and switchports, 3–4, 519 inline power, 283–286 QoS markings, 519 in voice port tests, 207 VoIP on, 479–483, 480 switchport access vlan command, 519 switchport mode access command, 519 switchport mode trunk command, 288 switchport trunk encapsulation
command, 288 switchport voice vlan command, 289, 519
synchronization CAS, 60 CCS, 61 ISDN, 62 TCP, 498 time, 290, 293 Synchronization Source Identifier (SSRC) field in RTP headers, 81 system keyword, 367
T T.30 fax machines, 357–358 T.37 fax, 365–367, 366 T.38 fax relay with H.323 and SIP, 359–360 with MGCP, 362–363 T wildcard, 118, 121, 121 T wire in E&M signaling, 42 T1 circuits CAS configuration, 63–64, 191–195, 191 ports, 56–57, 57 PRI configurations, 64–65, 195–198, 195, 212–213 T1 wire in E&M signaling, 42 tablets, 14, 14 Tag Control Information (TCI), 459 tagged image file format (TIFF), 365–366 tail end hop off (TEHO), 377–380, 378, 386 talker echo, 149 Tc (Time Interval) in token buckets, 500 TCI (Tag Control Information), 459 TCL (Tool Command Language) scripts, 366 TCP (Transmission Control Protocol) RTP with, 79 with SIP, 86 synchronization, 498
bindex.indd 554
tcp-traffic keyword, 498
TDM (time-division multiplexing), 56–57, 57 tech-prefix keyword, 410 technology prefixes, 408–409 TEHO (tail end hop off), 377–380, 378, 386 telephony. See traditional telephony telephony-service command, 343 telephony service event (TSE) payload size, 363 termination, PSTN, 146 test voice port command, 206–209 test voice translation-rule command, 130, 382 tftp-server flash command, 299–300 TFTP servers CUCM Express as, 298–300, 342–343 DHCP, 291–292 troubleshooting, 333–334 tie trunks, 6–7, 6 TIFF (tagged image file format), 365–366 time CUCM Express format, 328 synchronizing, 290, 293 time-division multiplexing (TDM), 56–57, 57 Time Interval (Tc) in token buckets, 500 time-sensitive traffic in end-to-end delays, 442 time to live (TTL) in registration messages, 400 time zones, 293 timeouts, interdigit, 118 timers H.225, 232–233 keepalive, 329 SIP, 244–245, 270–271 timers command, 245 timers connect command, 271 timers disconnect command, 271 timers trying command, 271 timeslots command, 259 timestamp field in RTP headers, 81 tip wire in supervisory signaling, 38–39 TLS (Transport Layer Security), 86, 241 token buckets, 500–504, 502–503 toll bypass, 377–380, 378, 385–386 tone suppression for faxes, 362 Tool Command Language (TCL) scripts, 366 ToS (Type of Service) byte, 449–450, 450 total keyword, 412
9/20/11 1:38:51 PM
touch-tone pads – User Datagram Protocol (UDP)
touch-tone pads, 36, 37 traditional telephony, 2–3 central office, 4–5, 4 edge devices, 3 exam essentials, 24 local loop, 5, 5 phone switches, 3–4 private systems, 9–10 PSTN, 8–9, 9 review questions, 26–31 summary, 23–24 trunks, 6–8, 6–8 written lab, 25, 32 traffic classification in QoS, 444–445 traffic marking in QoS, 445 traffic policing and shaping class-based, 504–508 DiffServ features, 455–457, 456– 457 token buckets, 500–504, 502–503 traffic queuing in QoS, 445 transcoding, 146 translate command, 131 translation-profile command, 132, 386 translation profiles, 131–132 translation rules in dial-plan digit manipulation, 127–132 Transmission Control Protocol (TCP) RTP with, 79 with SIP, 86 synchronization, 498 transmission rate for faxes, 360 transparent setting for H.323 codecs, 230 transport digital voice, 59, 59–60 SIP protocols, 243–244 Transport Layer Security (TLS) protocol, 86, 241 transport tcp command, 243 triggers for FSX ports, 184 troubleshooting Cisco phone registrations, 332 DHCP, 292–293, 332–333 TFTP, 333–334 trunk encapsulation command, 288 trunk-package packages, 256, 258–259 trunking gateways configuring, 259–260, 260 overview, 255–257, 255 trunks, 6 CAMA, 188–191, 189, 213 central office, 7, 7 digital, 54
bindex.indd 555
555
E&M, 187–188, 187 intercluster, 108, 108 interoffice, 7–8, 8 tie, 6–7, 6 VLANs, 286–288, 287 trust boundaries configuring, 513–515, 513 identifying, 460–461, 461 trust keyword in AutoQoS, 475–476, 479 trying timer, 245 TSE (telephony service event) payload size, 363 TTL (time to live) in registration messages, 400 tunnels for voice packets, 166, 166 2900 and 3900 series ISR routers, 19 two-stage dialing, 186 type command for ephones, 309 Type of Service (ToS) byte, 449–450, 450
U u-law algorithm, 55 UAC (user agent clients), 86 UAS (user agent servers), 86 UAs (user agents) in SIP, 86, 240 UC500 series products, 12 UDP (User Datagram Protocol), 79–80, 86 unconditional keyword, 248 Unified Communications Model overview, 11 applications, 15 call processing agents, 15–17, 17 endpoints, 11–15, 14 exam essentials, 24 network infrastructure, 20–23, 21–23 review questions, 26–31 summary, 23–24 voice gateways, 18–19, 19 written lab, 25, 32 Uniform Resource Locators (URLs), 86 Unity Express voicemail module, 294 UNREGISTERED ephone registration state, 335–337 upgrades of key systems, 10 url sips command, 242 URLs (Uniform Resource Locators), 86 User agent clients (UAC), 86 User agent servers (UAS), 86 user agents (UAs) in SIP, 86, 240 User Datagram Protocol (UDP), 79–80, 86
9/20/11 1:38:51 PM
556
user licenses for Cisco phone – voice gateways
user licenses for Cisco phone, 297 user-locale command, 325–326 user locales in CUCM Express, 325–328 usernames in SIP, 240
V VAD (Voice Activity Detection), 150–151, 150, 156 variable delay, 152 version field in RTP headers, 80 version setting in SCCP, 200 VG200 series appliances, 15 video phones, 14, 14 violate-action command, 505 violate-actions for token buckets, 503–505 virtual dial peers in CUCM, 294 virtual gateway addresses, 233–234, 233 vlan option for class maps, 491 VLANs configuring and verifying, 288–290, 289 trunks, 286–288, 287 voice analog. See analog voice clipping, 150 digital. See digital voice IOS licenses, 296 IP network issues, 441–444, 443 Voice Activity Detection (VAD), 150–151, 150, 156 voice backup paths, 368–369 COR, 372–377, 373 MGCP-to-H.323 fallback, 370–372, 371 SRST, 376–377 WAN-to-PSTN fallback, 369–370, 369 voice call types intercluster trunk, 108, 108 local, 105, 105 off-net, 106, 106 on-net, 105, 105 on-net-to-off-net, 106, 107 PBX-to-PBX, 107, 107 voice class codec command, 230 voice class h323 command, 232–233 voice-class sip url sips command, 242 Voice Codec Bandwidth Calculator, 169, 169 voice codecs, 153 clarity, 160–163 complexity, 156–160 types, 153–156
bindex.indd 556
voice gateway ports, 179–180 CAMA trunks, 188–191, 189 csim start command, 209 CUCM, 201–202, 202 debug dialpeer command, 209–210 DSP profiles, 199–200 E&M trunks, 187–188, 187 exam essentials, 210–211 FXS and FXO PLAR OPX, 180–184, 180 FXS/DID inbound and FXO outbound, 184–187, 185 hands-on labs, 212–214, 212 review questions, 215–221 SCCP, 200–201 show controller command, 205 show voice dsp command, 205–206 show voice port command, 203–205 summary, 210 T1 CAS to analog cross-connect, 191–195, 191 T1 PRI, 195–198, 195 test voice port command, 206–209 written lab, 211, 222 voice gateway signaling protocols, 83–84, 84, 223–224 comparisons, 88 exam essentials, 266–267 H.323. See H.323 protocol hands-on labs, 268–271, 268 MGCP. See Media Gateway Control Protocol (MGCP) review questions, 272–278 SCCP, 88 selecting, 93 SIP. See Session Initiation Protocol (SIP) summary, 265 written lab, 267–268, 279 voice gateways, 18–19, 19, 353–354 call blocking, 380–382 dial peers, 410–411 DSP farms on, 198–199, 198 DSP functions, 146–147, 147 DTMF relay support, 354–356 exam essentials, 382–383 fax. See faxes H.323 interface commands, 409–410 H.323 service on, 411 hands-on labs, 384–386, 384 modems, 367–368 redundancy, 407–408 review questions, 387–392
9/20/11 1:38:52 PM
voice media transmission protocols – wink-start E&M signaling
SIP settings, 243–249, 247 summary, 382 toll bypass and TEHO, 377–380, 378 voice backup paths. See voice backup paths written lab, 384, 393 voice media transmission protocols, 78 cRTP, 82–83 RTCP, 81–82 RTP, 78–81 sRTP, 83 voice network infrastructure considerations power options for IP phones, 282–286 VLANs, 286–290, 287, 289 VoIP support, 290–293 voice payload size, 165 voice-port command, 47–50, 63 voice register dn command, 310 voice register DNs, 310–311 voice register global command, 306 voice register pools, 307, 311 voice service voip command, 227, 229, 269, 422 voice translation-profile command, 131, 386 voice translation-rule command, 129, 386 voice transport, 17, 17 voice/video hardware protocols, 93 voice/video on IP networks, 440–441 voice VLANs configuring and verifying, 288–290, 289 trunks, 286–288, 287 VoIP AutoQoS policies on routers, 475–479, 476 on switches, 479–483, 480 VoIP design, 145–146 codecs clarity concerns, 160–163 selecting, 163–164 types, 153–160 exam essentials, 170–171 IP voice bandwidth consumption, 164–169, 166, 169 quality considerations, 147–153, 148, 150, 152 review questions, 172–177 summary, 170 voice gateway DSP functions, 146–147, 147 written lab, 171, 178
bindex.indd 557
557
VoIP network infrastructure support, 290–293 VoIP operation, 77 exam essentials, 94–95 firewalls, 80 gatekeepers, 89–91, 89–90 H.323 MCU, 91–92 proxy servers, 91 sample network, 92–93, 92 review questions, 96–101 summary, 94 voice gateway signaling protocols, 83–88, 84, 93 voice media transmission protocols, 78–83, 79 written lab, 95, 102 VoIP path-selection process, 103 dial peers, 109–110, 110 dial-plan digit manipulation. See dial-plan digit manipulation dial plans. See dial plan path-selection process exam essentials, 135–136 review questions, 137–142 summary, 135 written lab, 136, 143
W w (watch phone) ephone button separator, 318, 320 WAN connections, 457 WAN-to-PSTN fallback, 369–370, 369 watch phone (w) ephone button separator, 318, 320 weighted fair queuing (WFQ), 454 Weighted Random Early Detection (WRED), 451, 455, 498–500, 499 white noise, 151 wideband communication, codecs for, 154–155 wideband sampling frequencies, 148, 148 wildcards dial-peer configurations, 117–121, 119, 121 in digit stripping, 124 in prefix adding, 125 in regular expressions, 128–129 wink-start command, 50 wink-start dialing, 185 wink-start E&M signaling, 44–45, 45
9/20/11 1:38:53 PM
558
wired IP phones – zones
wired IP phones, 12–13 wireless IP phones, 13 WRED (Weighted Random Early Detection), 451, 455, 498–500, 499
X x (expansion line) ephone button separator, 319, 324 X11 services, 116
bindex.indd 558
Z zone keyword, 413 zone local command, 406, 430 zone prefix command, 407, 430
zones H.323 gatekeepers, 397–398, 397 local, 406 prefixes, 407 remote, 406–407
9/20/11 1:38:54 PM
Glossary
bgloss.indd 1
8/19/11 12:40:26 PM
2
802.3af
Glossary
An IETF standard PoE method for powering networked devices.
A The transmission of telephone digits from the calling-party phone to the called-party phone. A unique sequence of digits identifies each individual phone on the network so the call reaches the correct destination.
address signaling
alternate mark inversion (AMI)
An older digital circuit method for dictating how binary
is sent and interpreted on the wire. analog telephone An edge device that sends and receives voice using two wires. The voice signal is sent and received in analog waveforms. application-specific routing (ASR)
An H.323 feature that allows streams to be routed
based on the application being used. assured forwarding (AF) PHB A PHB classification system that has 12 priority classes, which are segmented into four classes, each with three drop priorities: low, medium, and high. Automatic Number Identification (ANI)
The source telephone number of the calling
party. Also known as caller ID. AutoQoS A Cisco QoS configuration method that automatically determines the bestpractice configurations for an interface and applies them for you.
The first step on the two-step AutoQoS for the Enterprise configuration process. The router monitors interfaces and collects information about the data flows it sees and attempts to classify them into one of 10 possible classes.
AutoQoS autodiscovery phase
AutoQoS for the Enterprise An automated QoS feature that configures large-scale networks for voice transport based on Cisco best-practice methodologies. AutoQoS for VoIP An automated QoS feature that configures small to medium-size networks for voice transport based on Cisco best-practice methodologies. AutoQoS installation phase The second step on the two-step AutoQoS for the Enterprise configuration process. The router uses the information collected during the AutoQoS autodiscovery phase to configure classes and policies, and then applies them to the appropriate interfaces.
B backhaul Trunks used to transport multiple voice calls between the private site and the service provider core network. Basic Rate Interface (BRI)
bgloss.indd 2
See ISDN Basic Rate Interface (BRI).
8/19/11 12:40:28 PM
Glossary
3
behavior aggregate (BA) A QoS term used to describe similar traffic flows that are traveling in the same direction on a network device. Typically you want to classify traffic into groups that have a similar BA. best-effort QoS model The model in which a network device treats all traffic the same and does not guarantee the delivery of traffic. Bipolar 8-bit Zero Substitution (B8ZS) A newer digital circuit method for dictating how binary is sent and interpreted over the wire. It solves the AMI 8-zeroes-in-a-row problem by sending a distinct pattern that can be interpreted as such.
The part of a network between two points where bandwidth is at its lowest. This is the area where congestion is most likely.
bottleneck
C A voice protection feature that monitors the amount of bandwidth on a path, and either permits or denies a call from being established based on the amount of bandwidth available.
call admission control (CAC)
call leg
A one-way logical connection of a call setup between two voice gateways.
call-processing agent Hardware and software responsible for call-processing and callcontrol functions on an IPT network. From a Cisco perspective, call-processing agents are any of the three Cisco Unified Communications Managers. call waiting caller ID
The ability of a phone to receive two or more simultaneous calls.
See: Automatic Number Identification (ANI).
A PSTN switch equipment office that is geographically dispersed to handle the need of users based on population density and telephone usage.
central office (CO)
central office (CO) trunk
Circuits that connect a private business PBX to the PSTN.
A specialized trunk configuration often used in North America for connecting to emergency services (E911).
Centralized Automatic Messaging Accounting (CAMA)
Channel Associated Signaling (CAS) A digital signaling method that allows for up to 24 simultaneous calls at one time. In order to be able to squeeze 24 calls into an SF or ESF frame, CAS uses robbed-bit signaling.
A Cisco proprietary Layer 2 messaging protocol that is commonly used between Cisco devices to determine neighboring devices and their capabilities.
Cisco Discovery Protocol
Cisco’s proprietary fax relay method, which uses special RTP packets to transport the communication stream.
Cisco fax relay
bgloss.indd 3
8/19/11 12:40:28 PM
4
Glossary
Cisco phone user license Cisco power injector
A license for each individual phone endpoint.
A midspan device that provides power to a single phone endpoint.
Cisco Unified Border Element (CUBE)
A specialized voice gateway IOS that can perform
IP-to-IP gateway functionality. Cisco Unified Communications Manager (CUCM) A hardware appliance that runs on a hardened Linux operating system. Each server appliance is capable of handling up to 7,500 endpoints and can be clustered to support up to 30,000 endpoints.
A hardware appliance that runs on a hardened Linux operating system. The appliance is used in medium-size businesses and can handle up to 500 endpoints.
Cisco Unified Communications Manager Business Edition (CUCMBE)
Specialized IOS software that runs on Cisco routers. The voice hardware and software are commonly used in small business environments and supports up to 250 endpoints.
Cisco Unified Communications Manager Express (CUCME)
class maps
The first tier of a class-based QoS policy that defines a specific subset of traffic.
Class of Restriction (COR) Within the voice gateway, a method that allows you to configure calling privileges and assign them to dial peers and telephone extensions configured on the voice gateway or CUCM Express. Class of Service (CoS) A field within the Layer 2 Ethernet frame header that marks traffic as being one of eight (0 to 7) classes for QoS prioritization purposes.
A PHB classification system that uses only the three leftmost bits. The other three bits are always 0s. The CS was created for backward compatibility with IP Precedence values.
Class Selector (CS) PHB
class-based (CB) QoS A term used to describe the three-tiered MQC configuration process for QoS. The three tiers include class maps, policy maps, and applying the policy maps using a service policy. class-based weighted fair queuing (CBWFQ) A queuing mechanism that is an extension of WFQ and also can be used to classify and prioritize traffic based on flow types. codec An algorithm that converts analog waves into a digital format that may or may not include compression. There are multiple codecs that use different fidelities, sampling rates, and packet payload sizes. The word codec is short for coder/decoder. comfort noise Artificial white noise created locally and played to let the user receive audio feedback that a call is still in progress and has not been terminated.
A digital signaling method that uses in-band signaling by taking an entire channel out of the TDM structure to use exclusively for signaling.
Common Channel Signaling (CCS)
bgloss.indd 4
8/19/11 12:40:28 PM
Glossary
5
A bandwidth-saving technique used to reduce the total number of bits that are required for the digital circuit to be encoded and transported.
companding
A technique used to shrink the size of the IP/UDP/RTP header from 40 bytes to 2–5 bytes by not passing static information in every packet of an RTP stream. compressed RTP (cRTP)
A method of reducing bandwidth by eliminating redundant 8-bit binary samples on the receiving end. This is done by using a known sample or group of samples and sending a signal to represent the known samples.
compression
congestion avoidance
A QoS method used to drop packets when congestion is detected
on an interface. congestion management The use of logical queues within network hardware interfaces to store packets that are waiting to be transmitted on a congested link. CUCM Express feature license
A license that determines how many phones you can run
on the CUCM. A queuing mechanism that divides the total number of queue slots into different classes. Each class gets a certain amount of queue spaces that is configurable by the network administrator. The more preferred a class is, the more queue slots it is given.
custom queuing (CQ)
customer premise equipment (CPE)
Telephone equipment owned by a private party that
connects to the PSTN network.
D default PHB A PHB classification describing traffic that requires only best-effort QoS. The default PHB has a binary value of 000000.
An XML configuration file that provides a Cisco IP phone with all the general information it needs to communicate with the CUCM Express system.
default phone configuration file
demarc The termination point that separates cabling responsibility between the customer’s house wiring and the PSTN local-loop wiring.
A configuration setting that relays DHCP messages between requesting endpoints and a DHCP server that resides on a different IP subnet.
DHCP relay
If no inbound dial-peer matches are made using configured dial-peer rules, the voice gateway will use this built-in “catch-all” rule.
Dial Peer 0
dial plan A telephone number methodology that uses dial peers to interpret dial strings and determine how calls are directed through IP and/or PSTN networks.
bgloss.indd 5
8/19/11 12:40:29 PM
6
Glossary
Dialed Number Identification Service (DNIS)
The destination telephone number a caller
dials and wishes to reach. Differentiated Services (DS) byte
A field within the IP header that is used to mark
packets with a DSCP value. A ToS/DS field within the Layer 3 packet header that marks traffic as being one of 64 (0 to 63) classes for QoS prioritization purposes.
Differentiated Services Code Point (DSCP)
A QoS model that classifies different IP traffic flows and marks them for use on other QoS-aware devices along the traffic flow path. Classified traffic can then be given different priorities although it is not considered to be guaranteed.
DiffServ
A digit-manipulation technique that removes digits that are explicitly defined in dial-peer rules.
digit stripping
Digital Signal Processor (DSP) A hardware chip installed in a voice gateway that serves to assist in voice connectivity, conferencing, and transcoding functionality in a voice network. digital telephone An edge device that converts the analog signal into a digital format. This is done to overcome distance and scalability issues inherent with analog phones.
A PSTN connection capable of transporting multiple digitized voice streams across a single cable.
digital trunk
direct inward dial (DID) A PSTN option where the carrier strips off and sends only a portion of the dialed digits to the customer. directory alias A command used when identifying files to be serviced by the TFTP server when the files are organized in a directory structure. The alias helps the phones locate the directory where the files can be stored on the flash. discrete signal
The resulting data after digital sampling has been performed on an
analog signal. drop precedence A portion of the DSCP AF marking classification system where traffic can be marked with a drop precedence of low, medium, or high probability. DSP farm A voice gateway configured to use DSP resources to offload transcoding, conferencing, and MTP from a CUCM. DSP profile
A grouping of DSP resources to serve a specific DSP-farm offloading service.
DTMF relay A method of transporting DTMF tones to better ensure that they are accurately reconstructed at the opposite end of a VoIP network.
The combining of two separate phone lines in one telephone button. This lets users of the phone place calls on hold or receive a second call when one line is in use.
dual line
bgloss.indd 6
8/19/11 12:40:29 PM
Glossary
7
A method of inputting telephone digits using buttons that sends two distinct tones to the phone switch to indicate a specific dialed digit.
dual-tone multi-frequency (DTMF)
The method in which an H.323 device sends gatekeeper request (GRQ) RAS messages in a multicast to discover its local gatekeeper.
dynamic gatekeeper discovery
Dynamic Host Control Protocol (DHCP) A service that dynamically assigns IP addresses and other network information to endpoint devices such as PCs and IP phones.
E E&M port
An analog port commonly used to connect two PBX systems together.
An analog signaling protocol used to communicate between PBX systems or PSTN network switches.
E&M signaling
E.164
See International Numbering Plan.
A digital trunk that carries 32 TDM channels. Two channels are used for framing and signaling so the E1 can carry up to 30 simultaneous calls. E1s are used almost everywhere outside of North America and Japan.
E1
echo The reflection of sound that arrives to the listener a period of time after the original sound is heard. encoding
The process of taking the quantized samples and translating them into binary.
ephone button separator A CUCM Express command character that is used to set different ring, call waiting, overlay, and monitor options on an ephone. ephone extension states
The six different operational states that an IP phone can be in.
A CUCM Express configuration statement that represents physical phones on the CUCM Express system running SCCP. It includes a number used to identify a particular device within the IOS.
ephone
A CUCM Express configuration statement that represents the telephone extension configured on each phone that is running SCCP.
ephone-dn
error correction mode (ECM) A fax feature that can be enabled to better ensure the proper receipt of all fax-transmission packets.
An ephone button separator option used to expand line coverage for an overlay button.
expansion
A PHB classification system used for IP data flows that require low-latency packet loss and jitter.
expedited forwarding (EF) PHB
bgloss.indd 7
8/19/11 12:40:29 PM
8
Glossary
explicit congestion notification (ECN) The two rightmost bits of the DS field that can be marked by Layer 3 devices to indicate link congestion. Extended Superframe (ESF) The newer digital framing method, which bundles 24 TDM channel cycles together in a single frame. It also performs cyclic redundancy checks (CRC) for better reliability compared to SF.
F A queuing algorithm that schedules packets for transport across the same interface. It is used in conjunction with priority marking of packets so that lower-class packets are not choked off completely.
fair queuing
A fax transmission method that transports fax messages the same way that voice calls are transmitted. The only difference is that when fax pass-through is enabled, it ensures that fax transmissions are encoded using either G.711 mu-law or G.711 a-law to provide a high-quality digital representation of the original analog source.
fax pass-through
A fax transmission method where analog fax transmissions are terminated at the voice gateway, which then demodulates, packetizes, and transmits the packets to the remote voice gateway. This process is accomplished using either the Cisco fax relay or T.38 fax relay method.
fax relay
A static transmit rate (measured in bps) at which the fax is transmitted over an IP network.
fax transmission rate
fidelity
The accuracy of a copied signal (such as voice) compared to the original.
A file on the CUCM Express system used to tell the registering Cisco phones which firmware they are to download.
firmware load file
A queuing mechanism that does not place any emphasis on packet priorities. Instead, the first packet to be placed in the queue is the first one to come out.
First-In, First-Out (FIFO)
fixed delay The amount of time it takes in an ideal situation where the only slowdown is in how fast it takes electrical and optical signals to transport IP packets. Foreign Exchange Office (FXO)
An analog port commonly used to connect a voice
gateway to the PSTN. An analog port commonly used to connect analog end devices such as a telephone or fax machine.
Foreign Exchange Station (FXS)
FRF.12
bgloss.indd 8
An LFI mechanism that can be configured on Frame Relay circuits.
8/19/11 12:40:30 PM
Glossary
9
G A device whose primary function is to maintain a database mapping telephone extensions to IP addresses. It is primarily found in environments running the H.323 protocol.
gatekeeper
Protocols used to communicate signaling between voice gateways or between a voice gateway and a call agent.
gateway signaling protocols
An occurrence when loop-start signaling is used whereby a user picks up a phone and unexpectedly finds they are already connected to a call that came inbound.
glare
A supervisory signaling type that uses grounding wires for the signaling of the line to be seized.
ground-start signaling
group 3
A fax standard transmission method that supports speeds up to 14.4 Kbps.
H A suite of protocols for the signaling of voice, video, and data using a peer-to-peer architecture. H.323
An H.323 feature used in concert with H.323 fast start to provide early communication channels for media such as broadcast announcements and music on hold (MOH).
H.323 Early Media
An H.323 call-initiation process that sets up an H.245 channel during the call setup stage and does not wait for the call proceeding, alerting, and connect stages to complete.
H.323 fast start
H.323 gatekeeper An H.323 component that breaks up an H.323 network into multiple zones. It can also be configured for other services, including RSVP-based CAC. H.323 proxy server A server that works as a head end for call setup and teardown of one or more H.323 endpoints.
An H.323 call-initiation process that sets up an H.245 channel after the call setup, call proceeding, alerting, and connect stages have completed.
H.323 slow start
high-complexity codec A codec that requires a large amount of DSP processing power typically because of higher compression rates while maintaining call clarity. house wiring
The customer’s internal telephone wiring that it is responsible for
maintaining. huntstop A command that tells CUCM Express to look for the next preferred ephone-DN if the most preferred phone is busy. hybrid system
bgloss.indd 9
The combination of PBX and key-system functionalities.
8/19/11 12:40:30 PM
10
Glossary
I impedance
The ratio between voltage and electrical current.
inbound dial peer
A dial peer that matches number strings coming into the voice gateway.
informational signaling Feedback generated from the telephone switch to the user in the form of tones or voice messages to inform the phone user what state a call is in. inject-tone A voice port-testing method used to send a tone across the port at a specific frequency that is used to determine proper settings as optimal impedance settings. inline power (ILP)
A Cisco proprietary PoE option integrated into switches.
A standard suite of protocols that operates on Layers 1–3 of the OSI model. It utilizes PSTN circuits running CCS for the transport of voice, data, and video. Integrated Services Digital Network (ISDN)
Intelligent Power Management (IPM)
A Cisco method using CDP to negotiate power
allocation of 802.3af PoE devices. intercluster trunk A VoIP call type where call setup signaling is transferred between the CUCMs at each site in order to establish the call. interexchange network
The level within the PSTN hierarchy where national long-distance
charges are incurred. interface binding A configuration method used to associate a virtual interface with multiple physical interfaces. This is commonly implemented on voice networks to eliminate a single physical point of failure.
The level within the PSTN hierarchy where international longdistance charges are incurred.
international network
International Numbering Plan A telephone numbering plan used by all countries around the world. The plan breaks numbers into three categories: country code, national destination code, and subscriber code.
A public telephone service provider that uses the IP network to connect customers to the PSTN. It offers telephony services similar to the PSTN; the primary difference is that connection between the private organization and the service provider uses VoIP as opposed to legacy analog or digital circuits.
Internet Telephony Service Provider (ITSP)
Backhaul connections that interconnect central offices. Calls made between interconnected COs are considered to be local.
interoffice trunk
IntServ A QoS model that guarantees the quality of service for specific traffic types. It can provide a guarantee by reserving a specific amount of bandwidth for a flow from end to end.
bgloss.indd 10
8/19/11 12:40:30 PM
Glossary
11
IOS feature set A license that determines the different features that can be run on an IOS-capable device. IP Precedence A technique that uses the three leftmost bits of the ToS byte to mark packets with a value of 0–7 for QoS classification purposes.
Digital circuit that has three channels of 64 Kbps each. The two channels used for transport are called B channels, and the one channel that out-of-band signaling uses is called the D channel.
ISDN Basic Rate Interface (BRI)
J The variation in the time between the receipt of each voice packet. For voice, it is recommended that jitter be reduced to 30 ms or less, on average.
jitter
K key system A telephone system used in small businesses for the sharing of external PSTN lines on multiple phones.
L lightweight registration A feature in H.323v2 that uses modified RRQ messages that are smaller and consume less bandwidth when notifying the gatekeeper that the end device is still alive.
A telephone line state when a phone transitions from an on-hook to an off-hook state.
line seizure
A QoS method used to make the transport of data flows more efficient, including techniques such as compression and LFI techniques.
link efficiency
link fragmentation interleaving (LFI) A link-efficiency compression technique that takes large data frames and fragments them into smaller, more manageable sizes. It then interleaves these smaller fragmented frames with other small frames such as voice. listener echo The reflection of sound that is an echo of an echo; the listening party hears the talker two times during different time intervals.
A VoIP call type where source and destination phones are connected to the same call-processing agent or voice gateway.
local call
The physical wiring between a customer’s private phone equipment and the PSTN central office (CO).
local loop
bgloss.indd 11
8/19/11 12:40:31 PM
12
Glossary
local zones
H.323 zones that are managed by the local gatekeeper.
loop-start signaling
A supervisory signaling type that uses a two-wire method for line
seizure. A queuing mechanism that can be configured to offer priority queuing (PQ) for traffic such as voice and CBWFQ queuing for other types of traffic.
Low Latency Queuing (LLQ)
low-complexity codec
A codec that requires a low amount of DSP processing power.
M Mean Opinion Score (MOS) A subjective ITU-T method of ranking call clarity for various audio codecs. Each codec is judged for various quality aspects and is given an averaged score between 1 and 5, where 5 is considered excellent quality. media flow-around Media streams flow freely between the two networks and find their own path to the destination instead of being forced through a CUBE. media flow-through
Voice/video streams come into and are proxied by the CUBE.
Media Gateway Control Protocol (MGCP) A newer voice gateway protocol that uses a client-server architecture. It is very easy to set up but limited in its features.
A method used to set up logical terminations to offload voice duties such as call hold, transfer, park, conference calling, and DTMF generation.
Media Termination Point (MTP)
medium-complexity codec
A codec that requires a moderate amount of DSP processing
power. MGCP fallback A MGCP failover feature that lets gateways fall back to the H.323 protocol when communications are lost, which renders MGCP useless.
A type of MGCP gateway where the protocol is responsible for providing signaling between the IP network and analog voice ports including FXS, FXO, and E&M.
MGCP residential gateway
A type of MGCP gateway where the protocol is responsible for providing signaling between the IP network and PSTN trunked ports such as ISDN BRI and PRI circuits.
MGCP trunking gateway
A Cisco QoS configuration method that uses a modular three-step hierarchical approach to configuring classes and policies and applying the policies to interfaces.
Modular QoS CLI (MQC)
monitor line An ephone button separator option used to monitor the status (on- or offhook) of a single ephone-DN.
bgloss.indd 12
8/19/11 12:40:31 PM
Glossary
13
A Layer 2 transport mechanism defined in RFC 1990 that encapsulates Layer 3 traffic over point-to-point links including ISDN.
Multilink PPP (MLP)
multiplexing
Combining multiple analog or digital signals over a shared physical
medium. Devices used to control and facilitate H.323 multimedia content such as audio and video for a point-to-multipoint communication.
multipoint control units (MCU)
N A message used to communicate resources such as codec choice when transporting fax transmissions. In this book, NSE messages can be either Cisco proprietary or ITU-T standard messages.
named signaling events (NSE)
Describes an audio sample taken using a smaller frequency range than wideband but that collects the vast majority of audio. Narrowband commonly collects signals between 300 and 3400 Hz.
narrowband
Network Time Protocol (NTP)
A service that synchronizes the internal clocks on
networked equipment. Proprietary (non-T.30) capability codes that are exchanged between two fax machines to determine possible fax transmission methods.
non-standard facilities (NSF)
North American Numbering Plan (NANP) The numbering plan used in the United States, Canada, and parts of the Caribbean. The plan uses a fixed format of 10 digits divided into three categories: area code, central office code, and subscriber code.
A digit-manipulation technique that matches one string of digits and then substitutes different digits before forwarding them to the next destination.
number expansion
Nyquist sampling theorem A mathematical equation used to find the optimal method for sampling the human voice for transport on a telephone network.
O octo-line The combining of eight separate phone lines in one telephone button. This lets users of the phone place calls on hold or receive a second call when the first line is in use. off-hook When the analog circuit between the ring and tip is connected and the ring powers the tip. off-net A VoIP call type where source and destination phones are on different networks where the PSTN must be utilized to complete the call.
bgloss.indd 13
8/19/11 12:40:31 PM
14
Glossary
one-stage dialing When a voice network is configured so that a call is not terminated until the endpoint phone is reached.
When the analog circuit between the ring and tip is severed and the battery (ring) cannot power the tip lead.
on-hook
on-net A VoIP call type where source and destination phones are on the same network but traverse more than one voice gateway. outbound dial-peer rule
A dial peer that matches number strings before exiting the voice
gateway. The process of using a separate voice channel that is reserved for signaling. That way, signaling is kept completely separate from any voice or data transmissions.
out-of-band signaling
overlay An ephone button separator option used to associate multiple ephone-DNs with a single-line button.
P An occurrence when network hardware queues fill up and packets are dropped. For voice, it is recommended that packet loss not exceed 1 percent.
packet loss
Software used to intelligently guess what the payload should be for lost packets. The software then generates a substitute packet to fill in for the one that was lost on the network.
packet loss concealment
peak information rate (PIR)
A byte setting that sets an absolute maximum rate above and
beyond the CIR. peer-to-peer architecture A model in which both voice peers have intelligence to route calls from one point to another. Perceptual Evaluation of Speech Quality (PESQ) An objective ITU-T method that produces a highly reproducible score of voice codec quality. It is similar to PSQM but takes network issues such as latency, jitter, and packet loss into the scoring equation. Scores are graded using a scoring method similar to MOS (1 to 5) so the two scores can be easily compared.
An objective ITU-T method that is used to score next-generation codecs in terms of voice quality. The standard will eventually be the replacement to PESQ because of its ability to offer more advanced benchmarking for sideband codecs as well as more advanced wireless networks.
Perceptual Objective Listening Quality Analysis (POLQA)
An objective ITU-T method that produces a highly reproducible score of voice-codec quality. It has since been replaced with the more accurate PESQ scoring system.
Perceptual Speech Quality Measure (PSQM)
bgloss.indd 14
8/19/11 12:40:32 PM
Glossary
15
per-hop behavior (PHB) A term used to describe DSCP subsets created by the IETF that define a structured methodology for marking packets with DSCP. phantom power
Using the same wiring to power devices as Ethernet uses to transmit and
receive data. phone branch exchange (PBX)
A telephone switch that lets a business run an internal
and private voice network. policy maps The second tier of a class-based QoS policy that associates traffic class types with one or more QoS operations. POTS dial peer Voice gateway configuration command that provides routing information for connecting to traditional telephony devices such as analog phones, fax machines, and any off-network calls that are routed out to the PSTN using either analog or digital interfaces connected to the voice gateway. power brick
Standard 110v AC unit that plugs directly into a single phone endpoint.
Power over Ethernet (PoE) A method of providing end devices with power using the same Ethernet cable used for the transport of data.
A device that sits in between an IP phone and a non-PoE-capable switch that provides power to multiple phone endpoints.
powered patch panel
A link-efficiency compression technique that attempts to predict the next sequence of characters in a data stream by using an index in the compression dictionary.
predictor compression
prefix adding A digit-manipulation technique that adds digits to the beginning of a number string before it is forwarded out of the voice gateway.
Digital circuit that uses either 23 or 32 channel T1/E1 ports. Out-of-band signaling is used.
Primary Rate Interface (PRI)
priority queuing (PQ)
A strict queuing mechanism that is used to give priority explicitly
to certain traffic types. Private Line Automatic Ringdown (PLAR)
An autodialing mechanism that is used to
associate a port with a single destination. Numbering plan for the configuration of private telephone networks within an organization.
private numbering plan
The amount of time it takes a packet to travel from source to destination on a network. For voice, it is recommended that delay not exceed 150 ms.
propagation delay
protocol internetworking The ability of a CUBE to terminate and reinitiate IP voice sessions between devices that run H.323, SIP, or H.323-to-SIP.
bgloss.indd 15
8/19/11 12:40:32 PM
16
proxy
Glossary
A device that acts as an intermediary for connected clients.
The name for the CO that is the first hop connecting a private voice network CAMA trunk to E911 services.
Public Safety Answering Point (PSAP)
public switched telephone network (PSTN) A network that interconnects private home and business phones. Customers pay a service fee to use the PSTN. pulse dialing A method of inputting telephone digits using a rotary disk with a mechanical motion to perform on- and off-hook transitions to specify a digit. pulse-amplitude modulation (PAM)
The process of sampling, quantizing, and encoding
an analog voice signal. The process of translating sampled analog signals into a numbering system. This is also referred to as quantization.
pulse-code modulation (PCM)
Q Q signaling (QSIG) A signaling protocol that uses Q.931 as its underlying signaling protocol but modifies the signals so proprietary ISDN signaling protocols can be used by nonproprietary equipment on the other end of the connection. Q.931 ITU-T standard sub-signaling protocol that is responsible for the setup and teardown of B channel connections whether they are voice or data connections.
A set of traffic-control mechanisms used to give time-sensitive traffic priority on the network to limit delay, jitter, and packet loss.
Quality of Service (QoS)
quantization The process of translating sampled analog signals into a numbering system. This is also referred to as pulse-code modulation.
R A congestion-avoidance technique that randomly drops packets when congestion is detected. It is set into motion when queues begin to fill up and packets need to be discarded on bottleneck interfaces. RED cannot differentiate between traffic types, so any packets could potentially be dropped.
Random Early Detection (RED)
Real-time Transport Control Protocol (RTCP) An out-of-band supporting protocol for RTP. Its primary purpose is to track statistics for QoS adjustments. Real-time Transport Protocol (RTP)
An IETF RFC 1889 and 3050 protocol designed to
transport real-time IP payloads. An H.225 message protocol that is used to communicate the registration process between H.323 gatekeepers and H.323 endpoints and voice gateways.
Registration Admission and Status (RAS)
bgloss.indd 16
8/19/11 12:40:33 PM
Glossary
remote zones
17
H.323 zones that are not configured locally and are handled by an external
gatekeeper. reset
A full reboot of a Cisco IP phone.
A Transport layer protocol that is designed to reserve bandwidth resources dynamically across an IP network.
Resource Reservation Protocol (RSVP)
restart
A partial reset of a Cisco IP phone.
ringing time The amount of time that an echo canceller waits to listen for echo on the receiving (Rx) line of the tail circuit.
The technique of taking bits from SF framing channels 6 and 12 and ESF framing channels 6, 12, 18, and 24 for sending signaling data from one end of the digital circuit to the other. This stealing of bits is done to maximize the number of calls a CAS T1 can handle.
robbed-bit signaling (RBS)
S Protocol that provides authentication, data encryption, and relay protection for RTP packets.
Secure RTP (sRTP)
seizure The process of taking a telephone connection off-hook, which reserves the line for a telephone call.
The third tier of a class-based QoS policy that is used to apply policy maps to router interfaces including subinterfaces and virtual circuits.
service policy
An RFC 2327 protocol that uses standard ASCII codes for describing and negotiating multimedia sessions.
Session Description Protocol (SDP)
A peer-to-peer transport protocol that uses a distributed call-processing architecture. The protocol messages are sent in ASCII format, and addressing looks similar to an email address.
Session Initiation Protocol (SIP)
shared line
The term used to describe an ephone-DN that is applied to two or more IP
phones. A method of exchanging SDP messages using SIP where the target device sends the initial request in a SIP OK message.
SIP delayed offer
SIP early offer A method of exchanging SDP messages using SIP where the initiating device sends the initial request in a SIP INVITE message. SIP proxy server
Device that takes the responsibility of forwarding INVITE messages for
the UACs. SIP register server Device that maintains a database mapping phone numbers to IP addresses on a SIP network.
bgloss.indd 17
8/19/11 12:40:33 PM
18
Glossary
SIP secure (SIPS)
A configuration feature to secure SIP communication.
SIP source-bind A SIP feature used to statically assign an IP address to a specific voice gateway interface to be used for the signaling and/or media source IP address.
SIP endpoint device that can be considered either a UAC or a UAS device.
SIP user agent (UA)
SIP user agent client (UAC)
Device that sends INVITE messages to a remote peer to
establish a SIP connection. SIP user agent server (UAS)
Device that responds to UAC INVITE messages.
site code dialing A dial plan method that uses a digit or multiple digits to specify a specific location on a voice network. Site codes are useful in situations where you have overlapping telephone extensions.
Cisco’s proprietary voice signaling protocol. It is primarily used as an endpoint-to-call-agent protocol for signaling but can be used on voice gateways for signaling. It uses a client-server architecture with centralized call control.
Skinny Client Control Protocol (SCCP)
source IP address
The IP address that defines the location of the CUCM Express
call-processing unit. A link-efficiency compression technique that uses a special encoded dictionary, which both routers possess. The router replaces streaming data with much smaller codes found in the dictionary.
stacker compression
Super Frame (SF) The former digital framing method, which bundles 12 TDM channel cycles together in a single frame. Super Group 3 (SG3)
A fax standard transmission method that supports speeds up to
33.6 Kbps. Signaling that detects changes in the status of the telephone physical loop or trunk and is then used to set up and tear down calls. Loop-start and ground-start analog signaling fall within this signaling category.
Supervisory Signaling
survivable remote site telephony (SRST) A voice backup method that allows the voice gateway to temporarily act as the call-processing agent in the event that a WAN connection is lost and there are phones that cannot communicate with the CUCM.
T T.30
An ITU-T standard for the transmission of fax messages over POTS lines.
T.37 store-and-forward fax A fax transmission method that uses SMTP email messages as transport for the fax transmission. The transmission is obtained and converted into a
bgloss.indd 18
8/19/11 12:40:33 PM
Glossary
19
TIFF file by the T.37-capable device. It is then attached to an email and sent to one or more recipients. T.38 fax relay
An ITU-T standard fax relay method for transmitting fax messages over IP
networks. T1 A digital trunk that carries 24 TDM channels. Depending on the signaling type used, a T1 can carry either 23 or 24 voice calls simultaneously. T1s are used primarily in North America. tail end hop off (TEHO) The voice design of configuring your IP network to transport calls as far as possible on the IP WAN before letting them hop off onto the PSTN. This is an extension of toll bypass that can work in geographically dispersed IP networks. talker echo The reflection of sound that arrives back at the originating talker where they hear themselves repeated. TCP synchronization A phenomenon that occurs when interface queues fill up. All TCP flows passing through the congested interface will back off and begin sending packets more slowly. They will eventually speed back up and cause the same congestion, causing a seesaw effect in traffic flow.
A special E.164 prefix number that can be dialed by endpoints to take advantage of special H.323 features.
technology prefix
telephony service event (TSE) Special messages that can provide a way to communicate telephony events between MGCP gateways. tie trunk (or tie line)
A dedicated voice circuit that directly connects two PBX switches.
time-division multiplexing (TDM)
A strict time-based method for sharing a single cable
to transport multiple voice signals. token A metaphor used to describe a router’s permission for a source device to send a specified amount of bits out to the network. token bucket
A metaphor used to describe interface queues.
The voice design of configuring your IP network to utilize WAN connections for voice transport and therefore avoiding long-distance charges.
toll bypass
A configuration method used to block fax tone transmissions so they can be transported at a lower rate.
tone suppression
Tool Command Language (TCL) A scripting language that can be used within the IOS to script events for processes such as the T.37 store-and-forward fax method.
The process of identifying traffic based on different characteristics in order to group same-traffic types together for QoS.
traffic classification
bgloss.indd 19
8/19/11 12:40:34 PM
20
Glossary
The process of flagging critical packets so that the rest of the network can properly identify them and give them priority over all other traffic.
traffic marking
traffic policing A QoS technique that sets a strict maximum transmission rate to a certain group of traffic. If traffic flows go above the configured rate, the traffic is dropped or retagged. traffic queuing
The process of ordering certain types of traffic for transport over LAN/
WAN interfaces. A QoS technique that sets a maximum transmission rate to a certain group of traffic. If traffic flows go above the configured rate, the traffic is put into queues when available. That means the data will still be sent, but it will be delayed.
traffic shaping
transcoding
The process of translating data between two different codecs.
A digit-manipulation technique that nests multiple rules in a translation rule set, which then can be called within dial peers or POTS ports to match and manipulate number strings.
translation rule
Defined characters used to provide an easy and structured method to match number strings used for matching and manipulating number strings within translation rules.
translation rule regular expressions
Transmission Control Protocol (TCP) An IP suite protocol often used in data applications that benefit from features such as reconstructing unordered packets at the destination, and the retransmission of missing packets. trust boundary A term used to describe the point within a network topology where you start trusting QoS markings contained within a packet or frame. two-stage dialing When a voice network is configured so that a caller dials digits, which are accepted by a voice gateway, and the call terminates at a second hop along the connection where a second dial tone is given. The caller must then enter a second series of digits to complete the intended call. Type of Service (ToS) byte
A field within the IP header that is used to mark packets with
an IP Precedence value.
U Unity Express A hardware device that provides voicemail services. It integrates directly into CUCM Express on an open network module. User Datagram Protocol (UDP) An IP suite protocol often used by voice because it provides no error-correction mechanisms, which real-time traffic cannot utilize.
bgloss.indd 20
8/19/11 12:40:34 PM
Glossary
21
V A link between two Layer 2 switches that can transport traffic from multiple VLANs. It keeps the traffic between the VLANs separate by tagging each frame.
VLAN trunk
Voice Activity Detection (VAD) Software used to detect silence on a phone call and prevent the sending of silent packets across the network to conserve bandwidth.
A side effect of VAD in which the first few milliseconds of a user’s voice are not transmitted to the remote party.
voice clipping
voice gateway A router that connects IP and PSTN voice networks. The gateway is responsible for translation, transcoding, and compression, when needed. voice register dn A CUCM Express configuration statement that represents the telephone extension configured on each phone that is running SIP.
A CUCM Express configuration statement that represents physical phones on the CUCM Express system running SIP. It includes a number used to identify a particular device within the IOS.
voice register pool
voice VLAN
A dedicated VLAN specifically used for voice communications on an IP
network. VoIP dial peer Voice gateway configuration command that provides routing information for devices connecting to each other through an IP network.
W An ephone button separator option used to monitor the status (on- or offhook) of all ephone-DNs assigned to a phone.
watch phone
weighted fair queuing (WFQ) A queuing mechanism that uses byte sizes to fairly distribute traffic out of queues. This lets smaller packets such as voice have preferential treatment over larger data packets.
A congestion-avoidance technique that uses RED but adds an extra layer of intelligence to better determine which packets should have a higher probability of being dropped based on QoS markings. It is a Cisco proprietary advancement of RED to make the dropping of packets less random by selecting packets that are marked lower than others.
Weighted Random Early Detection (WRED)
Describes an audio sample taken using a large frequency range that captures more of the audio signal than narrowband methods. Wideband commonly collects signals between 50 and 7000 Hz.
wideband
bgloss.indd 21
8/19/11 12:40:34 PM
22
Glossary
wildcard One or more characters used as a placeholder to describe a range of telephone digits. Wildcards are used in configurations (such as dial peers) to limit the number of rules that need to be created.
A term used to describe the on-off-on hook transition when using E&M wink-start supervisory signaling.
wink
WRED
See Weighted Random Early Detection (WRED).
Z zone In H.323, a gatekeeper is used to break up a large network into logical units known as zones for better management and policy enforcement. zone prefix
Configured on H.323 gateways, it is used to identify a zone by an E.164
number.
bgloss.indd 22
8/19/11 12:40:35 PM
John Wiley & Sons, Inc. End-User License Agreement READ THIS. You should carefully read these terms and conditions before opening the software packet(s) included with this book “Book”. This is a license agreement “Agreement” between you and John Wiley & Sons, Inc. “JWS”. By opening the accompanying software packet(s), you acknowledge that you have read and accept the following terms and conditions. If you do not agree and do not want to be bound by such terms and conditions, promptly return the Book and the unopened software packet(s) to the place you obtained them for a full refund. 1. License Grant. JWS grants to you (either an individual or entity) a nonexclusive license to use one copy of the enclosed software program(s) (collectively, the “Software”) solely for your own personal or business purposes on a single computer (whether a standard computer or a workstation component of a multi-user network). The Software is in use on a computer when it is loaded into temporary memory (RAM) or installed into permanent memory (hard disk, CD-ROM, or other storage device). JWS reserves all rights not expressly granted herein. 2. Ownership. JWS is the owner of all right, title, and interest, including copyright, in and to the compilation of the Software recorded on the physical packet included with this Book “Software Media”. Copyright to the individual programs recorded on the Software Media is owned by the author or other authorized copyright owner of each program. Ownership of the Software and all proprietary rights relating thereto remain with JWS and its licensers. 3. Restrictions on Use and Transfer. (a) You may only (i) make one copy of the Software for backup or archival purposes, or (ii) transfer the Software to a single hard disk, provided that you keep the original for backup or archival purposes. You may not (i) rent or lease the Software, (ii) copy or reproduce the Software through a LAN or other network system or through any computer subscriber system or bulletin-board system, or (iii) modify, adapt, or create derivative works based on the Software. (b) You may not reverse engineer, decompile, or disassemble the Software. You may transfer the Software and user documentation on a permanent basis, provided that the transferee agrees to accept the terms and conditions of this Agreement and you retain no copies. If the Software is an update or has been updated, any transfer must include the most recent update and all prior versions. 4. Restrictions on Use of Individual Programs. You must follow the individual requirements and restrictions detailed for each individual program in the “About the CD” appendix of this Book or on the Software Media. These limitations are also contained in the individual license agreements recorded on the Software Media. These limitations may include a requirement that after using the program for a specified period of time, the user must pay a registration fee or discontinue use. By opening the Software packet(s), you agree to abide by the licenses and restrictions for these individual programs that are detailed in the “About the CD” appendix and/or on the Software Media. None of the material on this Software Media or listed in this Book may ever be redistributed, in original or modified form, for commercial purposes. 5. Limited Warranty. (a) JWS warrants that the Software and Software Media are free from defects in materials and workmanship under normal use for a period of sixty (60) days from the date of purchase of this Book. If JWS receives notification within
bmeddis.indd 559
the warranty period of defects in materials or workmanship, JWS will replace the defective Software Media. (b) JWS AND THE AUTHOR(S) OF THE BOOK DISCLAIM ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE SOFTWARE, THE PROGRAMS, THE SOURCE CODE CONTAINED THEREIN, AND/OR THE TECHNIQUES DESCRIBED IN THIS BOOK. JWS DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE SOFTWARE WILL BE ERROR FREE. (c) This limited warranty gives you specific legal rights, and you may have other rights that vary from jurisdiction to jurisdiction. 6. Remedies. (a) JWS’s entire liability and your exclusive remedy for defects in materials and workmanship shall be limited to replacement of the Software Media, which may be returned to JWS with a copy of your receipt at the following address: Software Media Fulfillment Department, Attn.: CVOICE 8.0: Implementing Cisco Unified Communications Voice over IP and QoS v8.0 Study Guide, John Wiley & Sons, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, or call 1-800-762-2974. Please allow four to six weeks for delivery. This Limited Warranty is void if failure of the Software Media has resulted from accident, abuse, or misapplication. Any replacement Software Media will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer. (b) In no event shall JWS or the author be liable for any damages whatsoever (including without limitation damages for loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising from the use of or inability to use the Book or the Software, even if JWS has been advised of the possibility of such damages. (c) Because some jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation or exclusion may not apply to you. 7. U.S. Government Restricted Rights. Use, duplication, or disclosure of the Software for or on behalf of the United States of America, its agencies and/or instrumentalities “U.S. Government” is subject to restrictions as stated in paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of DFARS 252.227-7013, or subparagraphs (c) (1) and (2) of the Commercial Computer Software - Restricted Rights clause at FAR 52.227-19, and in similar clauses in the NASA FAR supplement, as applicable. 8. General. This Agreement constitutes the entire understanding of the parties and revokes and supersedes all prior agreements, oral or written, between them and may not be modified or amended except in a writing signed by both parties hereto that specifically refers to this Agreement. This Agreement shall take precedence over any other documents that may be in conflict herewith. If any one or more provisions contained in this Agreement are held by any court or tribunal to be invalid, illegal, or otherwise unenforceable, each and every other provision shall remain in full force and effect.
9/20/11 1:41:47 PM
T
he Best CVOICE v8.0 Book/CD Package on the Market!
Get ready for your Cisco CVOICE v8.0 (642-437) exam with the most comprehensive and challenging sample tests anywhere!
The Sybex Test Engine features: All the review questions, as covered in each chapter of the book Challenging questions representative of those you’ll find on the real exam A total of two full-length bonus Practice Exams available only on the CD. Use the Electronic Flashcards to jog your memory and prep last-minute for the exam!
Reinforce your understanding of key concepts with these hardcore flashcard-style questions. Now you can study for the CVOICE v8.0 exam anytime, anywhere.
An Assessment Test to narrow your focus to certain objective groups.
Use the Glossary for instant reference! Look up key terms any CCNP Voice candidate should be familiar with in this searchable database.
bmedinst.indd 560
9/21/11 2:59:32 PM
CVOICE 8.0: Implementing Cisco Unified Communications Voice over IP and QoS v8.0 Study Guide 642-437-AF-CVOICE Objectives OBJECTIVE
CHAPTER
Describe a Dial Plan Describe a numbering plan.
1, 4
Describe digit manipulation.
4
Describe path selection.
4, 9
Describe calling privileges.
4, 9
Describe the Basic Operation and Components Involved in a VoIP Call Describe VoIP call flows.
3, 9
Describe RTP, RTCP, cRTP, and sRTP.
3
Describe H.323.
3, 7
Describe MGCP.
3, 7
Describe Skinny Call Control Protocol.
3
Describe SIP.
3, 7
Identify the appropriate gateway signaling protocol for a given scenario.
3, 7
Choose the appropriate codec for a given scenario.
5
Describe and Configure VLANs.
5
Implement Cisco Unified Communications Manager Express to Support Endpoints Using CLI Describe the appropriate software components needed to support endpoints.
8
Configure DHCP, NTP, and TFTP.
8
Describe the differences between the different types of ephones and ephone-dns.
8
Configure Cisco Unified Communications Manager Express endpoints.
8
Describe the Components of a Gateway
Perf.indd 1
Describe the function of gateways.
1, 4, 5, 7
Describe DSP functionality.
5
Describe the different types of voice ports and their usage.
2, 5, 6
Describe dial peers and the gateway call routing process.
4, 9
Describe codecs and codec complexity.
5
8/29/11 2:33:16 PM
OBJECTIVE
CHAPTER
Implement a Gateway Configure analog voice ports.
2, 6
Configure digital voice ports.
2, 6
Configure dial peers.
4, 6
Configure digit manipulation.
4, 7, 9
Configure calling privileges.
7
Verify a dial-plan implementation.
4, 6, 7
Implement fax support on a gateway.
9
Implement Cisco Unified Border Element Describe the Cisco Unified Border Element features and functionality.
10
Configure Cisco Unified Border Element to provide address hiding.
10
Configure Cisco Unified Border Element to provide protocol and media internetworking. 10 Configure Cisco Unified Border Element to provide call admission control.
10
Verify Cisco Unified Border Element configuration and operation.
10
Describe the Need to Implement QoS for Voice and Video Describe the causes of voice and video quality issues.
5, 11
Describe how to resolve voice and video quality issues.
11
Describe QoS requirements for voice and video traffic.
5, 11
Describe and Configure the DiffServ QoS Model
Perf.indd 2
Describe the DiffServ QoS model.
11
Describe marking based on CoS, DSCP, and IP Precedence.
11
Configure Layer 2 to Layer 3 QoS mapping.
12
Describe trust boundaries.
11
Configure trust boundary on Cisco switches.
12
Describe the operations of the QoS classifications and marking mechanisms.
11, 12
Describe Low Latency Queuing.
11, 12
Describe the operations of the QoS WAN link efficiency mechanisms.
11, 12
Enable QoS mechanisms on switches using AutoQoS.
12
Configure Low Latency Queuing.
12
8/29/11 2:33:17 PM
