Sybex.cvoice.8.0.Implementing.cisco.unified.communications.voice.over.IP.and.QoS.v8.0.(Exam.642 437).2011.RETAiL.ebook DeBTB00k

ffirs.indd iiffirs.indd ii 9/21/11 11:51:43 AM9/21/11 11:51:43 AM

CVOICE 8.0Implementing Cisco

Unified Communications Voice over IP and QoS v8.0

Study Guide

ffirs.indd iffirs.indd i 9/21/11 11:51:42 AM9/21/11 11:51:42 AM

ffirs.indd iiffirs.indd ii 9/21/11 11:51:43 AM9/21/11 11:51:43 AM

John Wiley & Sons, Inc.

CVOICE 8.0Implementing Cisco

Unified Communications Voice over IP and QoS v8.0

Study Guide

Andrew Froehlich

ffirs.indd iiiffirs.indd iii 9/21/11 11:51:43 AM9/21/11 11:51:43 AM

Senior Acquisitions Editor: Jeff KellumDevelopment Editor: Jim ComptonTechnical Editors: Scott Morris and Tyler OwenProduction Editor: Dassi ZeidelCopy Editor: Linda RecktenwaldEditorial Manager: Pete GaughanProduction Manager: Tim TateVice President and Executive Group Publisher: Richard SwadleyVice President and Publisher: Neil EddeMedia Project Manager 1: Laura Moss-HollisterMedia Associate Producer: Doug KuhnMedia Quality Assurance: Shawn PatrickBook Designers: Judy Fung and Bill GibsonProofreaders: James Saturnio and Paul Sagan, Word One New YorkIndexer: Ted LauxProject Coordinator, Cover: Katherine CrockerCover Designer: Ryan Sneed

Copyright © 2012 by John Wiley & Sons, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-470-91623-0ISBN: 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 ivffirs.indd iv 9/21/11 11:51:53 AM9/21/11 11:51:53 AM

http://www.wiley.com/go/permissions

http://www.wiley.com

http://booksupport.wiley.com

Dear Reader,

Thank you for choosing CVOICE 8.0: Implementing Cisco Unifi ed 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 refl ected 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 EddeVice President and PublisherSybex, an Imprint of Wiley

ffirs.indd vffirs.indd v 9/21/11 11:51:53 AM9/21/11 11:51:53 AM

ffirs.indd viffirs.indd vi 9/21/11 11:51:54 AM9/21/11 11:51:54 AM

AcknowledgmentsI 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 confi dence 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. Specifi cally, 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 viiffirs.indd vii 9/21/11 11:51:54 AM9/21/11 11:51:54 AM

About the AuthorAndrew 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 Effi ciency. Andrew also authored Sybex’s CCNA Voice Study Guide.

ffirs.indd viiiffirs.indd viii 9/21/11 11:51:54 AM9/21/11 11:51:54 AM

Contents at a GlanceIntroduction 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 533

ffirs.indd ixffirs.indd ix 9/21/11 11:51:55 AM9/21/11 11:51:55 AM

ffirs.indd xffirs.indd x 9/21/11 11:51:55 AM9/21/11 11:51:55 AM

ContentsIntroduction xxi

Assessment Test xxx

Chapter 1 An Introduction to Traditional Telephony and Cisco Unified Communications 1

Understanding Traditional Telephony Components 2Telephony Edge Devices 3Phone Switches 3The Central Office 4The Local Loop 5Trunks 6National and International Calling PSTN 8

Understanding Private Telephony Phone Systems 9Key System 10PBX 10

Understanding the Unified Communications Model 11Endpoints 11Applications 15Call Processing Agents 15Network Infrastructure 20

Unified Communications Deployment Models 20The Centralized Services Deployment Model 20The Distributed Services Deployment Model 21The Inter-Networking of Services Deployment Model 22The Geographical Diversity Deployment Model 22

Summary 23Exam Essentials 24Written Lab 1.1 25Review Questions 26Answers to Review Questions 30Answers to Written Lab 1.1 32

Chapter 2 Understanding Analog and Digital Voice 33

Understanding Analog Voice Ports and Signaling 34Analog Voice Port Types 34Analog Voice Signaling 35Basic Configuration of Analog Voice Ports 47

Understanding Digital Voice Ports and Signaling 51An Overview of the Analog-to-Digital

Conversion Process 51

ftoc.indd xiftoc.indd xi 9/20/11 4:59:58 PM9/20/11 4:59:58 PM

xii Contents

Digital Voice Port Types 56Digital Voice Multiplexing, Framing, and

Physical Transport 56Digital Voice Signaling 60Basic Configuration of Digital Voice Ports 63


Chapter 3 VoIP Operation and Protocols 77

Voice Media Transmission Protocols 78Introduction to the Real-Time Transport Protocol 78Introduction to the Real-time Transport

Control Protocol 81Introduction to Compressed RTP 82Introduction to Secure RTP 83

Voice Gateway Signaling Protocols 83H.323 84Session Initiation Protocol 85Media Gateway Control Protocol 87Skinny Client Control Protocol 88Voice Gateway Signaling Protocol Comparison 88

An Introduction to Gatekeepers and Other H.323 Components 89

Gatekeeper 89H.323 Proxy Server 91H.323 Multipoint Control Unit 91A Typical H.323 Network 92

Choosing the Appropriate Voice Gateway Signaling Protocol 93


Chapter 4 The VoIP Path-Selection Process 103

Understanding the Dial Plan Path-Selection Process 104Understanding Voice Call Types 104Path Selection and Call Routing 108

ftoc.indd xiiftoc.indd xii 9/20/11 4:59:59 PM9/20/11 4:59:59 PM

Contents xiii

POTS and VoIP Dial Peers 108Call Legs 110Path-Selection Strategies 111Introduction to PSTN and Private Numbering Plans 113Using Wildcards to Simplify Dial-Peer Configurations 117Site-Code Dialing 122

Dial-Plan Digit Manipulation 123Digit Stripping 123Forwarding the Last X Digits 124Prefix Adding 125Number Substitution 126Translation Rules and Profiles 127Verifying Dial-Plan Configurations 132


Chapter 5 VoIP Design Options 145

Voice Gateway DSP Functions 146Understanding Voice and VoIP Quality Considerations 147

Audio Fidelity 148Echo and Echo Cancellation 148Background Noise 149Voice over IP Quality Considerations 151

Defining Voice Codecs 153Voice Codec Types 153Understanding Codec Complexity 156

Quantifying Voice Codec Clarity 160Mean Opinion Score 161Perceptual Speech Quality Measure 162Perceptual Evaluation of Speech Quality 163Perceptual Objective Listening Quality Analysis 163

Choosing the Right Codec 163Hardware Compatibility 163Network Capacity 164Codec Complexity 164Endpoint Uses 164Call Clarity 164

Calculating IP Voice Bandwidth Consumption 164Frame and Bandwidth Calculations 165Determining Packet and Frame Size Information 165

ftoc.indd xiiiftoc.indd xiii 9/20/11 4:59:59 PM9/20/11 4:59:59 PM

xiv Contents

Additional Voice Packet and Frame Size Factors 166Codec Bit Rate 166Frame and Bandwidth Calculation Example 167


Chapter 6 Configuring Voice Gateway Ports and DSPs 179

Analog Port Configurations 180Configuring an FXS and an FXO PLAR

OPX Port 180Configuring FXS/DID Inbound and FXO

Outbound 184Configuring E&M to Bridge Legacy PBX

with VoIP Networks 187Configuring CAMA 188

Digital Port Configurations 191Configuring a T1 CAS to Analog Cross-Connect 191Configuring a T1 PRI 195

Configuring DSP Resources 198Enabling a DSP Farm on a Voice Gateway 198Creating DSP Profiles 199Configuring SCCP Communications 200Configuring the CUCM 201

Voice Port and Dial-Peer Verification Commands 203show voice port 203show controller 205show voice dsp 205test voice port 206csim start 209debug dialpeer 209

Summary 210Exam Essentials 210Written Lab 6.1 211Hands-On Labs 212

Hands-On Lab 6.1: Configuring a T1 PRI 212Hands-On Lab 6.2: Configuring a CAMA

Port for E911 Services 213Hands-On Lab 6.3: Configuring an Outbound

Dial Peer to the PSTN 214Hands-On Lab 6.4: Configuring an Outbound

Dial Peer to the PSAP 214

ftoc.indd xivftoc.indd xiv 9/20/11 5:00:00 PM9/20/11 5:00:00 PM

Contents xv

Review Questions 215Answers to Review Questions 220Answers to Written Lab 6.1 222

Chapter 7 Configuring Voice Gateway Signaling Protocols 223

Configuring H.323 224Configuring an H.323 Gateway 227H.323 show Commands 234

Configuring SIP 236Determine the Endpoint Locations 237Determine the Endpoint Capabilities 237Determine Endpoint Availability 239Establish a Session 239Configure SIP between IP Voice Gateways 239Configure Secure SIP Communications 241Modify SIP Voice Gateway Settings 243SIP show Commands 249

Configuring MGCP 253Residential Gateways 254Trunking Gateways 255Configure an MGCP Residential Gateway 257Configure an MGCP Trunking Gateway 259MGCP show Commands 260


Hands-On Lab 7.1: Configuring Basic SIP 269Hands-On Lab 7.2: Modifying SIP Timers and Retries 270


Chapter 8 Configuring and Managing CUCM Express 281

Voice Network Infrastructure Considerations 282Power Options for IP Phones 282Configuring VLANs and Voice VLANs 286Network Infrastructure Services for VoIP Support 290

An Overview of CUCM Express 293Understanding CUCM Express Capabilities 294Understanding CUCM Express Hardware

Requirements 295Understanding CUCM Express Software Licensing 296New Software-Activated Voice Licensing 297

ftoc.indd xvftoc.indd xv 9/20/11 5:00:00 PM9/20/11 5:00:00 PM

xvi Contents

Initial CUCM Express Configuration 297Configuring CUCM Express as a TFTP Server 298Configuring the Mandatory CUCM Express

System Settings Using SCCP Signaling 300Configuring the Mandatory CUCM Express

System Settings Using SIP Signaling 305Configuring SCCP and SIP Phones and Directory Numbers 307

Configuring Basic SCCP Ephone and Ephone-DNs 308Configuring Basic SIP Voice Register Pools

and Voice Register DNs 310SCCP Ephone-DN Line Configuration Options 311

Configuring Ephone-DN Shared Lines 312Configuring Two Ephone-DNs with One Number 314Configuring Ephone-DN Dual- and Octo-lines 315Configuring SCCP Individual Lines 317Configuring Ephone Button Options 318

Configuring CUCM Express Telephony Service Features 325Configuring User Locale and Network Locale 325Configuring the Date and Time Format 328Modifying the Cisco IP Phone Keepalive Timer 329Cisco IP Phone Restart versus Reset 329

Using CUCM Express Verification and Troubleshooting Commands 332

Troubleshooting Cisco Phone Registrations 332Determining the State of an Ephone 334


Hands-On Lab 8.1: Configuring CUCM Express as a TFTP Server 342

Hands-On Lab 8.2: Configuring CUCM Express for Basic SCCP Phone Operation 343

Hands-On Lab 8.3: Verifying the Configuration and Status of Your Ephones 344


Chapter 9 Advanced Voice Gateway Features 353

Configuring DTMF Relay Support 354Configuring H.323 DTMF Relay 354Configuring SIP DTMF Relay 355Configuring MGCP DTMF Relay 356

ftoc.indd xviftoc.indd xvi 9/20/11 5:00:01 PM9/20/11 5:00:01 PM

Contents xvii

Configuring Fax Support 357Understanding Fax Relay 357Configuring Cisco Fax Relay 359Configuring T.38 Fax Relay 359Understanding Fax Pass-through 364Configuring Fax Pass-through 364Understanding T.37 Store-and-Forward Fax 365

Configuring Modem Support 367Configuring Modem Pass-Through 367Configuring Modem Relay 368

Configuring Voice Backup Paths 368Configuring a WAN-to-PSTN Fallback 369Configuring MGCP-to-H.323 Fallback 370Understanding and Configuring COR and SRST 372

Toll Bypass and TEHO 377Configuring Call Blocking 380Summary 382Exam Essentials 382Written Lab 9.1 384Hands-On Labs 384

Hands-On Lab 9.1: Configuring Toll Bypass and PSTN Redundancy 385

Hands-On Lab 9.2: Configuring TEHO 386Review Questions 387Answers to Review Questions 391Answers to Written Lab 9.1 393

Chapter 10 Configuring and Managing CUBE and H.323 Gateways 395

What Is an H.323 Gatekeeper? 396H.323 Gatekeeper Mandatory Features 397H.323 Gatekeeper Optional Features 398

Understanding Gatekeeper Signaling 399RAS Gatekeeper Discovery Messages 399RAS Gateway Registration Messages 400RAS Call Admission Messages 400

The H.323 Gatekeeper Discovery, Registration, and Admission Process 401

RAS Location Messages 402RAS Resource Availability Messages 404RAS Bandwidth Messages 404

Configuring an H.323 Gatekeeper 405Configuring Local Zones 406Configuring Remote Zones 406

ftoc.indd xviiftoc.indd xvii 9/20/11 5:00:01 PM9/20/11 5:00:01 PM

xviii Contents

Configuring Zone Prefixes 407Configuring Technology Prefixes 408

Voice Gateway Interoperation with Gatekeepers 409Configuring H.323 Interface Commands 409Configuring Dial Peers for Gatekeeper Interoperation 410Enabling the H.323 Service on a Voice Gateway 411

Configuring Call Admission Control on H.323 Gatekeepers 411

Understanding the CAC Bandwidth Control on H.323 Gatekeepers 411

Configuring CAC Bandwidth Control on H.323 Gatekeepers 412

Gatekeeper Verification and Troubleshooting Commands 414Introducing the Cisco Unified Border Element 416

CUBE Features 417CUBE Media Flow Options 417CUBE Signaling Protocol Interoperation 419CUBE RSVP-CAC 420CUBE Call Flow Differences 421

Configuring the CUBE 422Configuring Protocol Interoperation 422Configuring Media Flow-Around 423Configuring Codec Transparency 424Configuring H.323 Fast-to-Slow-Start Signaling 424Configuring SIP Delayed-to-Early-Offer Signaling 425

CUBE Verification and Troubleshooting Commands 425Summary 427Exam Essentials 427Written Lab 10.1 428Hands-On Labs 429

Hands-On Lab 10.1: Configuring GB_Gatekeeper_1 430

Hands-On Lab 10.2: Configuring London_gw1 and Glasgow_gw1 430


Chapter 11 Introduction to Quality of Service 439

Problems with Voice/Video on IP Networks 440Mitigating IP Network Voice Issues 441

Providing Sufficient Bandwidth for a Newly Converged Network 441

ftoc.indd xviiiftoc.indd xviii 9/20/11 5:00:02 PM9/20/11 5:00:02 PM

Contents xix

Reduce End-to-End Delay 442Reduce Jitter 442Eliminate Packet Loss 443Putting the Pieces Together 444

The Three-Step QoS Process 444Traffic Classification 444Traffic Marking 445Traffic Queuing 445

QoS Policy Considerations 445The Three-Step QoS Policy Development Process 445Methods of Configuring QoS Policies 446

QoS Classification Models 447The Best-Effort Model 447The IntServ Model 447The DiffServ Model 448Comparing the QoS Models 449Understanding the DiffServ ToS/DS Byte 449DiffServ Service Quality Features 453

Layer 2 Class of Service and QoS Trust Boundaries 459Layer 2 Classification and Marking with CoS 459Identifying QoS Trust Boundaries 460

QoS Baseline Models 461Comparing the Cisco QoS Baseline Model 461Recommended Cisco Baseline Classification

Markings 462Recommended Cisco Baseline Congestion-

Management and -Avoidance Tools 463Summary 464Exam Essentials 464Written Lab 11.1 465Review Questions 466Answers to Review Questions 470Answers to Written Lab 11.1 472

Chapter 12 Configuring Quality of Service 473

Configuring QoS Policies Using AutoQoS 474Configuring AutoQoS for VoIP on a Router 475Configuring AutoQoS for VoIP on a Switch 479Configuring AutoQoS for the Enterprise on

a Router 483Configuring QoS Policies Using MQC 488

Configuring Class Maps 490Configuring Policy Maps 493

ftoc.indd xixftoc.indd xix 9/20/11 5:00:02 PM9/20/11 5:00:02 PM

xx Contents

Applying Policy Maps to Interfaces with a Service Policy 495MQC QoS Configuration Show Commands 495

Configuring Congestion-Avoidance Techniques 498Configuring Class-Based Traffic Policing and Shaping 500

Understanding Token Buckets 500Understanding Traffic-Policing Token Buckets 501Configuring Class-Based Traffic Policing 504Configuring Class-Based Traffic Shaping 506

Configuring Link Efficiency Techniques 508Configuring Link Fragmentation and

Interleaving for MLP and Frame Relay 509Configuring Class-Based Header Compression 512

Configuring Trust Boundaries 513Configuring CoS-to-DSCP Mappings 515Summary 517Exam Essentials 517Written Lab 12.1 518Hands-On Labs 518

Hands-On Lab 12.1: Configuring a Switchport to Trust Cisco IP Phone QoS Markings 519

Hands-On Lab 12.2: Modifying CoS-to-DSCP Mappings 519

Hands-On Lab 12.3: Configuring a Router for QoS Using MQC 520


Appendix About the Companion CD 529

Index 533

ftoc.indd xxftoc.indd xx 9/20/11 5:00:03 PM9/20/11 5:00:03 PM

IntroductionWelcome 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 certifi cation goals. Cisco has multiple levels of certifi cations, 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 fi ve-exam CCNP Voice certifi cation or the two-exam Cisco Rich Media Communications Specialist certifi cation, both of which are highlighted. Currently, the fi ve exams to become CCNP Voice certifi ed 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 certifi cation track has the prerequisite that the test taker must currently be CCNA Voice (640-461 or 640-460) certifi ed.

Specialist certifi cations are for network professionals with a very focused certifi cation goal in mind. Specifi cally, the Cisco Rich Media Communications Specialist certifi cation is for IT professionals who must be profi cient 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 certifi cations is likely to change rapidly, and therefore most specialist certifi cations are valid for only two years. The two exams to become Cisco Rich Media Communications Specialist certifi ed are:

� 642-437 CVOICE v8.0

� 642-481 CRMC

The prerequisite for this Specialist certifi cation is that the certifi cation candidate must currently be either CCNA certifi ed or have any CCIE certifi cation.

flast.indd xxiflast.indd xxi 9/20/11 10:56:04 AM9/20/11 10:56:04 AM

xxii Introduction

The exams necessary to achieve either of these two Cisco certifi cations 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 certifi cation, because it is part of Cisco’s “core” structure for voice. Cisco offers three distinct levels of core voice certifi cations. The following diagram shows that the CCNA Voice certifi cation is a building block to the professional- and expert-level voice certifi cations:

CCIEVoice

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 specifi c 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 certifi cation. If you choose to achieve the CCNP Voice certifi cation, you may want to further your education and attempt to pass the CCIE Voice certifi cation. But even if you stop after achieving your CCNP Voice certifi cation, 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 profi cient in the following areas:

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

flast.indd xxiiflast.indd xxii 9/20/11 10:56:05 AM9/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 confi dence to complete the simulation questions found in the exam.

You will learn the following information in this book:

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

flast.indd xxiiiflast.indd xxiii 9/20/11 10:56:05 AM9/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.

� 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 value-added 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 best-practice 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

flast.indd xxivflast.indd xxiv 9/20/11 10:56:06 AM9/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 fi ve stages on the way to the professional-level certifi cation in Cisco voice technologies. To get the most out of this book, I recommend you use the following study method:

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.

flast.indd xxvflast.indd xxv 9/20/11 10:56:06 AM9/20/11 10:56:06 AM

xxvi Introduction

8. 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 confi gure QoS policies is highly recommended. If you are in a classroom environment, the training center should provide you with this equipment or a similar confi guration to get you hands-on experience. Otherwise, you will have to fi nd 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 certifi cation 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 Unifi ed 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 confi guring all of the example confi gurations 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 confi gurations. 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 confi guring Cisco hardware and using copy and paste functions, so you can save any confi gurations and command outputs that will help you with your studies.

flast.indd xxviflast.indd xxvi 9/20/11 10:56:07 AM9/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–certifi ed 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 fl ashcards with which to test yourself. These fl ashcards 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:

� 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

flast.indd xxviiflast.indd xxvii 9/20/11 10:56:07 AM9/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 BookThis 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 xxviiiflast.indd xxviii 9/20/11 10:56:08 AM9/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 fi t into the main fl ow 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 SybexSybex 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 xxixflast.indd xxix 9/20/11 10:56:08 AM9/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.

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.

2. Which of the following DTMF relay methods transmit tones in an ASCII format? (Choose all that apply.)

A. h245-signal

B. h245-alphanumeric

C. cisco-rtp

D. rtp-nte

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

B. Distributed services model

C. Inter-networking of services model

D. Geographical diversity model

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

B. Router(config-if)#auto qos voip cisco-phone

C. Router(config)#auto qos voip

D. Router(config)#auto qos voip cisco-phone

5. What is the correct command used to configure loop-start signaling on an FXS port?

A. Router(config-voiceport)#dial-type loopstart

B. Router(config-controller)#dial-type loopstart

C. Router(config-controller)#signal loopstart

D. Router(config-voiceport)#signal loopstart

flast.indd xxxflast.indd xxx 9/20/11 10:56:09 AM9/20/11 10:56:09 AM

6. Which of the following is not a feature of a Cisco Unified Border Element (CUBE)?

A. Call admission control (CAC)

B. Secure deployment

C. IP address hiding

D. Zone management

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

C. Five

D. Four

8. Which of the following is not a voice gateway signaling protocol?

A. MGCP

B. SCCP

C. Q.931

D. H.323

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

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.

Assessment Test xxxi

flast.indd xxxiflast.indd xxxi 9/20/11 10:56:10 AM9/20/11 10:56:10 AM

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

B. POLQA

C. PSQM

D. PESQ

xxxii Assessment Test

flast.indd xxxiiflast.indd xxxii 9/20/11 10:56:10 AM9/20/11 10:56:10 AM

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

C. H.323

D. MGCP

E. SIPv2

Assessment Test xxxiii

flast.indd xxxiiiflast.indd xxxiii 9/20/11 10:56:10 AM9/20/11 10:56:10 AM

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.

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.

xxxiv Assessment Test

flast.indd xxxivflast.indd xxxiv 9/20/11 10:56:11 AM9/20/11 10:56:11 AM

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

C. FIFO

D. Blast

Assessment Test xxxv

flast.indd xxxvflast.indd xxxv 9/20/11 10:56:11 AM9/20/11 10:56:11 AM

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

C. E.164

D. E.711

xxxvi Assessment Test

flast.indd xxxviflast.indd xxxvi 9/20/11 10:56:12 AM9/20/11 10:56:12 AM

Answers to Assessment Test xxxvii

Answers to Assessment Test1. 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 confi guration 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 traffi c 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 confi guration 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 offi ce. 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 confi gured 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 confi gured globally in confi g 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 xxxviiflast.indd xxxvii 9/20/11 10:56:12 AM9/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-fi delity 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 confi guration 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 specifi es the preferred codec for an ephone when this phone is calling another phone that is also confi gured on CUCM Express. The command can be used while confi guring 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 confi guration mode. See Chapter 9.

flast.indd xxxviiiflast.indd xxxviii 9/20/11 10:56:12 AM9/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. Traffi c prioritization techniques can use CBWFQ as a way to segment traffi c 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 traffi c 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 offl oad transcoding. See Chapter 5.

38. C. The ITU International numbering plan is formally known as E.164. See Chapter 4.

flast.indd xxxixflast.indd xxxix 9/20/11 10:56:13 AM9/20/11 10:56:13 AM

flast.indd xlflast.indd xl 9/20/11 10:56:13 AM9/20/11 10:56:13 AM

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.

■ Describe a numbering plan.

�

�

Chapter

1

c01.indd 1c01.indd 1 9/21/11 12:09:10 PM9/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 circuit-switched 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 ComponentsIn 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 2c01.indd 2 9/21/11 12:09:11 PM9/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 specifi cally 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 3c01.indd 3 9/21/11 12:09:12 PM9/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 offi ce is the fi rst major stop where a public telephone line terminates. Central offi ce (CO) is a term used to describe a geographically located offi ce that houses PSTN switch equipment. Home and business lines are run back to the central offi ce and connect to the PSTN switches. The CO has large trunk lines that further multiplex the phone lines and interconnect this central offi ce with the larger national and global telephone network.

In spite of the name, most modern central offi ces are not really offi ces 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 fi ts into the PSTN, imagine that you are at your offi ce 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 offi ce on the PSTN line and reach the central offi ce 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 GU R E 1.1 A PSTN call within the same central office

PSTN

central

office

555-1717

555-1717

Called party

Calling party

c01.indd 4c01.indd 4 9/21/11 12:09:12 PM9/21/11 12:09:12 PM


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 identifi es 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 effi cient. When calls enter a switch, the destination number is effi ciently 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 offi ce. 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 GU R E 1. 2 A local loop

PSTN

Central

office

Local loop

PBX PSTN

demarc

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 5c01.indd 5 9/21/11 12:09:13 PM9/21/11 12:09:13 PM


Trunks

Traditional telephony trunks are circuits that interconnect voice switches. There are three distinct types of trunk lines:

� Tie trunks

� Central offi ce trunks

� Interoffi ce 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.

Calling

party

Called

party

4104

PBX-A

3XXX

PBX-B

4XXX

Tie trunk

4104

4104

F I GU R E 1. 3 A tie trunk

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 reconfi gured so they use the same routing protocol or confi gured to redistribute into one another. At a very high level, the same challenges found in migrating two IP systems are

c01.indd 6c01.indd 6 9/21/11 12:09:14 PM9/21/11 12:09:14 PM


similar to merging two PBX systems. In both situations, similar planning methodologies are required to successfully merge the two systems.

Central Office Trunks

Central offi ce 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 effi cient 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.

PSTN

Central

office

Calling party

External calls

External calls

CO trunk

PBX

F I GU R E 1. 4 A CO trunk

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 offi ce trunk.

Interoffice Trunks

Interoffi ce trunks are the backhauled connections that interconnect central offi ces. Central offi ces that are connected with interoffi ce trunk lines are considered to be interexchange connections. It’s easiest to understand interoffi ce trunks in terms of local vs. long-distance charges; a call whose routing goes no higher than an interoffi ce trunk is considered local. For example, imagine you are in your offi ce 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 interoffi ce trunk connection. The phone switch seizes one of the lines on the interoffi ce 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 fl ow using an interoffi ce trunk between COs.

c01.indd 7c01.indd 7 9/21/11 12:09:14 PM9/21/11 12:09:14 PM


This type of interoffi ce trunk would likely be considered a local call instead of a long-distance call because the call uses the interoffi ce 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 offi ce 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.

Calling

party

Called

party

555-1717

PBX

4XXX

Interoffice

trunk

55

5

-1717

555-1717

PSTN

Central

office

PBX

4XXX

PSTN

Central

office

F I GU R E 1.5 An Interoffice trunk connection

c01.indd 8c01.indd 8 9/21/11 12:09:15 PM9/21/11 12:09:15 PM

Understanding Private Telephony Phone Systems 9

Telephone calls between COs that have interoffi ce trunks are considered to be local calling. If the telephones are on different networks that are not interconnected using interoffi ce 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 SystemsIn a business environment with multiple employees, you will quickly see that having individual telephone lines run in from the PSTN is not the most effi cient or economical method for providing voice services. It would be extremely rare to fi nd a time when every employee needed to access the PSTN at once. In fact, calculations show that the telephone-to-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 briefl y explain the differences between these two systems.

Central office (local

calling)

Interexchange network

(long distance calling)

International network

(international long

distance)

Lo

ca

l to

In

tern

ati

on

al ca

ll fl

ow

F I GU R E 1.6 The PSTN local-to-international hierarchy

c01.indd 9c01.indd 9 9/21/11 12:09:15 PM9/21/11 12:09:15 PM


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 offi ce can answer an incoming call to any line. The key system is often called a shared-line system, because of how lines are confi gured 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 fi ve 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 confi gured 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 offi ce for the proper person to pick up the line.

Over the years, Kevin’s business grew and with it the offi ce space and number of employees. The key system continued to be suffi cient until an interesting phenomenon

c01.indd 10c01.indd 10 9/21/11 12:09:16 PM9/21/11 12:09:16 PM

Understanding the Unified Communications Model 11

Understanding the Unified Communications ModelThe 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 Unifi ed Communications model, an endpoint can be any end device or software that interacts with Unifi ed 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

occurred. After a while, the inbound calls that were directed to a specifi c employee increased signifi cantly. This is because as the business grew, employees became specialists in a specifi c 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.

c01.indd 11c01.indd 11 9/21/11 12:09:16 PM9/21/11 12:09:16 PM


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 Unifi ed Communications devices available for implementation.

Wired IP Phones

When most people think of IPT, the fi rst 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 specifi cally 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 specifi c 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:

� 9900 series

� 8900 series

� 7900 series

c01.indd 12c01.indd 12 9/21/11 12:09:17 PM9/21/11 12:09:17 PM


� 6900 series

� 3900 series

Each of these phone series is designed to meet a specifi c 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 fl oors, and retail-outlet fl oors 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 rug-gedized 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 Unifi ed 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 hardware-based 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 Unifi ed 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 Unifi ed Communications

c01.indd 13c01.indd 13 9/21/11 12:09:17 PM9/21/11 12:09:17 PM


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 offi ce 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 Unifi ed 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 Unifi ed Communications voice and video functionality with additional PC functionality. The tablet can connect to a Cisco Unifi ed 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 offi ce. Figure 1.7 shows the Cisco Cius tablet.

F I GU R E 1.7 The Cisco Cius tablet device

Courtesy of Cisco Systems, Inc. Unauthorized use not permitted.

c01.indd 14c01.indd 14 9/21/11 12:09:18 PM9/21/11 12:09:18 PM


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 Unifi ed 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 Unifi ed Communications platform calling features, Cisco provides value-added Unifi ed 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 Unifi ed 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 Unifi ed 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:

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

c01.indd 15c01.indd 15 9/21/11 12:09:18 PM9/21/11 12:09:18 PM


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 confi gure basic settings on the Unifi ed Communications Manager Express. This material is covered in Chapter 8, “Confi guring 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 fl agship 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 benefi t 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 16c01.indd 16 9/21/11 12:09:19 PM9/21/11 12:09:19 PM


agent performs signaling between the source IP phone and the voice gateway, as shown in Figure 1.8.

M

Off-network

phoneIP phone

Call agent

PSTN

Signaling Signaling

V

F I GU R E 1. 8 Call setup signaling through the call agent

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 confi gured 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 effi cient path.

M

Off-network

phoneIP phone

Call agent

IP voice packet transport

Signaling Signaling

PSTNV

F I GU R E 1. 9 Voice transport

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 17c01.indd 17 9/21/11 12:09:19 PM9/21/11 12:09:19 PM


Cisco Voice Gateway Solutions

One major topic of the CVOICE exam is the functions of voice gateways on an IP network and how to confi gure 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 confi gured 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 Unifi ed Communications solutions described earlier in this chapter. These signaling protocols are as follows:

� H.323

� SIP

� MGCP

� SCCP

Each of these protocols has benefi ts and drawbacks. Careful consideration must be made during the voice network design phase to choose the signaling protocol that best fi ts 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 offl oading 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, “Confi guring 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. Specifi cally, 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:

� 1800 ISR series

� 2800 ISR series

� 3800 ISR series

c01.indd 18c01.indd 18 9/21/11 12:09:20 PM9/21/11 12:09:20 PM


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 Unifi ed Communications voice capabilities they offer.

TA B LE 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 19c01.indd 19 9/21/11 12:09:20 PM9/21/11 12:09:20 PM


The primary focus of the CVOICE exam is on the ISR series of router equip-ment. It is important to understand which equipment is considered to be part of the ISR lineup.

Network Infrastructure

The fi nal Unifi ed 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 Unifi ed Communications traffi c over the same physical network. The major point to note in a Unifi ed 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 traffi c such as voice and video.

Unified Communications Deployment ModelsCisco presents four different deployment models that it recommends for use within a production network for the entire Unifi ed Communications version 8.X suite. These models have remained fairly static over the years, but the terminology has changed to refl ect the fact that Unifi ed 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 benefi ts 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 benefi ts of this model derive from having a single administration point with which to manage the Unifi ed 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 20c01.indd 20 9/21/11 12:09:21 PM9/21/11 12:09:21 PM

Unified Communications Deployment Models 21

Campus

M PSTNV

F I GU R E 1.10 The centralized services deployment model

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.

Campus

M

VPSTN

Branch Branch

SRST

V

IP WAN

V

V

V

F I GU R E 1.11 The distributed services deployment model

c01.indd 21c01.indd 21 9/21/11 12:09:21 PM9/21/11 12:09:21 PM


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 traffi c in addition to data traffi c. 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 GU R E 1.12 The inter-networking of services model

Campus

M

V

IP WAN PSTN

M

V

Campus

M

V

Campus

V

V

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 22c01.indd 22 9/21/11 12:09:22 PM9/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 benefi t 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.

Campus

M

V

IP WAN PSTN

M

V

Campus

M

V

Campus

Cluster

V

V

V

F I GU R E 1.13 The geographical diversity model

SummaryYou 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 23c01.indd 23 9/21/11 12:09:22 PM9/21/11 12:09:22 PM


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 EssentialsKnow 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 offi ce 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 offi ce trunks connect a PBX to the CO. Interoffi ce trunks interconnect two COs.

Understand the three-tiered PSTN hierarchy. The PSTN routes calls based on central offi ce, interexchange, and international networks. The PSTN uses a hierarchical network structure where local calls are routed through the central offi ce, national calls through the central offi ce, and interexchange and international calls through all three tiers—the central offi ce, 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 24c01.indd 24 9/21/11 12:09:23 PM9/21/11 12:09:23 PM

Written Lab 1.1 25

Written Lab 1.1Write the answers to the following questions:

1. These PSTN sites house telephone switch equipment that directly connects to personal telephones and/or offi ce 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 Unifi ed 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 agent.

9. What hardware device allows a user to connect analog telephone devices to an IP network?

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 25c01.indd 25 9/21/11 12:09:23 PM9/21/11 12:09:23 PM


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

B. CO trunk

C. Local loop

D. Central office

2. 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. Inside wiring

C. Outside wiring

D. Local loop

E. House wiring

3. What type of voice trunk directly connects two PBX systems?

A. Demarc

B. Tie trunk

C. CO trunk

D. Interoffice trunk

4. What type of voice trunk directly connects two central offices?

A. CO trunk

B. Interoffice trunk

C. Tie line

D. Interexchange trunk

5. Central offices maintain pools of what numbers?

A. Subscriber code

B. E.164 code

C. Area code

D. Interexchange code

c01.indd 26c01.indd 26 9/21/11 12:09:24 PM9/21/11 12:09:24 PM

Review Questions 27

6. At what point of the PSTN hierarchy described in this Study Guide will a caller begin incurring long-distance charges?

A. Central office

B. Local loop

C. International network

D. Interexchange network

7. Which Cisco IP phone does not support Cisco’s proprietary SCCP signaling protocol?

A. 7925G series wireless phone

B. SPA 500 series phone

C. Cisco IP Communicator softphone

D. All Cisco phones support SCCP

8. The Cisco Emergency Responder belongs in what UC model category?

A. Network infrastructure

B. Applications

C. Call processing agents

D. Endpoints

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

B. H.323

C. SIP

D. SCCP

c01.indd 27c01.indd 27 9/21/11 12:09:24 PM9/21/11 12:09:24 PM


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

B. Distributed services model

C. Inter-networking of services model


c01.indd 28c01.indd 28 9/21/11 12:09:24 PM9/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


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.

B. If there are several large dispersed campus sites and WAN links are slow and/or unreli-able.

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.

c01.indd 29c01.indd 29 9/21/11 12:09:25 PM9/21/11 12:09:25 PM


Answers to Review Questions

1. D. The central offi ce is a geographically located offi ce 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 interoffi ce trunk is the name used to describe a circuit that connects two PSTN switches located in separate COs.

5. A. Central offi ces 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 interoffi ce 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 Unifi ed 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 modifi cation 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 confi gured 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 offl oad Cisco Emergency Responder duties.

15. A. QoS is confi gured 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 30c01.indd 30 9/21/11 12:09:25 PM9/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 traffi c 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 traffi c.

c01.indd 31c01.indd 31 9/21/11 12:09:25 PM9/21/11 12:09:25 PM


Answers to Written Lab 1.11. Central offi ce

2. Plant

3. Tie trunk, CO trunk, and interoffi ce 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 32c01.indd 32 9/21/11 12:09:26 PM9/21/11 12:09:26 PM

Understanding Analog and Digital Voice



■ Describe the different types of voice ports and their usage.

Implement a gateway.

■ Configure analog voice ports.

■ Configure digital voice ports.

�

�

Chapter

2

c02.indd 33c02.indd 33 9/21/11 11:47:48 AM9/21/11 11:47:48 AM

Unifi ed 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 confi gure the basic settings on various analog and digital ports that are available on Cisco voice gateway hardware.

Understanding Analog Voice Ports and SignalingAnalog 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 34c02.indd 34 9/21/11 11:47:49 AM9/21/11 11:47:49 AM

Foreign Exchange Office Ports

Foreign Exchange Offi ce (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. Briefl y, 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 identifi es 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 specifi cally for E&M ports.

Address Signaling

A telephone number consists of a string of digits that uniquely identifi es a specifi c 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:

� Pulse dialing

� DTMF dialing

Understanding Analog Voice Ports and Signaling 35

c02.indd 35c02.indd 35 9/21/11 11:47:49 AM9/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.

Dial

stopper

1

2ABC

3DEF

4GHI

5JKL

6MNO

7PRS

8TUV 9

XYZ

9OPER

Dial

F I GU R E 2 .1 A rotary dial pad

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 time-consuming 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 specifi c 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 36c02.indd 36 9/21/11 11:47:50 AM9/21/11 11:47:50 AM

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 differ-ence 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 net-work 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 effi cient 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

1

DTMF frequencies

1209 Hz 1336 Hz 1477Hz 1633 Hz

697 Hz

770 Hz

852 Hz

941 Hz

2ABC

3DEF A

4GHI

5JKL

6MNO B

7PQRS

8TUV

9WXYZ C

* 0 # D

F I GU R E 2 . 2 DTMF pad and corresponding frequencies


c02.indd 37c02.indd 37 9/21/11 11:47:51 AM9/21/11 11:47:51 AM


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.

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

TA B LE 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.

c02.indd 38c02.indd 38 9/21/11 11:47:51 AM9/21/11 11:47:51 AM

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.

The following sections cover each signaling technique to detail how on-hook and off-hook 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.

TA B LE 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

Analog

phone

Ring–48 volt

PSTN central

office switch

Tip

F I GU R E 2 . 3 The on-hook status in loop-start signaling

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.

Analog

phone

Ring–48 volt

PSTN central

office switch

Tip

F I GU R E 2 . 4 The off-hook status in loop-start signaling


c02.indd 39c02.indd 39 9/21/11 11:47:52 AM9/21/11 11:47:52 AM


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 clarifi cation, 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 on-hook 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 off-hook 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 40c02.indd 40 9/21/11 11:47:52 AM9/21/11 11:47:52 AM

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.

F I GU R E 2 .5 Ground-start signaling

Step 1: Idle state

PBX

Ring–48 volt

PSTN central

office switch

Tip Ring

ground

Step 2: The ring grounded

PBX

Ring–48 volt

PSTN central

office switch

Tip Ring

ground

Step 3: The loop closed

PBX

Ring–48 volt

PSTN central

office switch

Tip Ring

ground

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 41c02.indd 41 9/21/11 11:47:53 AM9/21/11 11:47:53 AM


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 specifi es eight different wires, listed in Table 2.3.

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

TA B LE 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

c02.indd 42c02.indd 42 9/21/11 11:47:54 AM9/21/11 11:47:54 AM

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 fi gures 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 43c02.indd 43 9/21/11 11:47:54 AM9/21/11 11:47:54 AM


(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 notifi cation 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 notifi ed 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 notifi es the sending-side PBX of the transition change and line seizure.

Sending

PBX

Receiving

PBX

On-hookOn-hook

Step 1: The idle state

Step 2: The sending side off-hook

Sending

PBX

Receiving

PBX

On-hookOff-hook

Going off-hook

Step 3: The pause before DTMF transmission

Sending

PBX

Receiving

PBX

On-hookOff-hook

DTMF digits

after 150 ms pause

Sending

PBX

Receiving

PBX

Off-hookOff-hook

Going off-hook

Step 4: The remote side off-hook

F I GU R E 2 .6 Immediate-start E&M signaling

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 44c02.indd 44 9/21/11 11:47:55 AM9/21/11 11:47:55 AM

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 notifi es 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 notifi cation 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 notifi cation 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 GU R E 2 .7 Wink-start E&M signaling


Sending

PBX

Receiving

PBX

On-hookOn-hook

Step 2: The serving side goes off-hook

Sending

PBX

Receiving

PBX

On-hookOff-hook

Going off-hook

Step 3: The remote side wink

Sending

PBX

Receiving

PBX

On-off-on hookOff-hook

Wink off/on

Step 4: DTMF transmission after receiving wink

Sending

PBX

Receiving

PBX

On-hookOff-hook

DTMF digits

after receiving wink

Step 5: The remote side goes off-hook

Sending

PBX

Receiving

PBX

Off-hookOff-hook

Going off-hook


c02.indd 45c02.indd 45 9/21/11 11:47:56 AM9/21/11 11:47:56 AM


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 off-hook after receiving DTMF addressing and seizing the line.


Sending

PBX

Receiving

PBX

On-hookOn-hook

Step 2: Sending side off-hook

Sending

PBX

Receiving

PBX

On-hookOff-hook

Going off-hook

Step 3: Sending side status check

Sending

PBX

Receiving

PBX

On- or off-hookOff-hook

Checks to see if

receiving PBX is on-

or off-hook

Step 4: DTMF transmission after receiving

side on-hook verification

Sending

PBX

Receiving

PBX

On-hookOff-hook

if Receiving PBX is

on-hook

DTMF digits

Step 5: The remote side goes off-hook

Sending

PBX

Receiving

PBX

Off-hookOff-hook

Going off-hook

F I GU R E 2 . 8 Delay-dial E&M signaling

c02.indd 46c02.indd 46 9/21/11 11:47:57 AM9/21/11 11:47:57 AM

Basic Configuration of Analog Voice Ports

There are literally dozens of options to choose from when confi guring 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 confi gurations. Chapter 6, “Confi guring Voice Gateway Ports and DSPs,” will cover voice-port confi guration options in greater detail.

Basic FXS Port Configuration

An FXS port most commonly connects to an analog telephone or fax machine. The primary confi guration option for this type of setup is whether the signaling type is loop-start 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 confi gure 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 confi gure settings that are specifi c 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(config-voiceport)#cptone ?

locale 2 letter ISO-3166 country code

AR Argentina IN India PE Peru

AU Australia ID Indonesia PH Philippines

AT Austria IE Ireland PL Poland

BE Belgium IL Israel PT Portugal

BR Brazil IT Italy RU Russian Federation

CA Canada JP Japan SA Saudi Arabia

CN China JO Jordan SG Singapore

CO Colombia KE Kenya SK Slovakia

C1 Custom1 KR Korea Republic SI Slovenia

C2 Custom2 KW Kuwait ZA South Africa


c02.indd 47c02.indd 47 9/21/11 11:47:59 AM9/21/11 11:47:59 AM


CY Cyprus LB Lebanon ES Spain

CZ Czech Republic LU Luxembourg SE Sweden

DK Denmark MY Malaysia CH Switzerland

EG Egypt MX Mexico TW Taiwan

FI Finland NP Nepal TH Thailand

FR France NL Netherlands TR Turkey

DE Germany NZ New Zealand AE United Arab Emirates

GH Ghana NG Nigeria GB United Kingdom

GR Greece NO Norway US United States

HK Hong Kong OM Oman VE Venezuela

HU Hungary PK Pakistan ZW Zimbabwe

IS Iceland PA Panama

Router(config-voiceport)#cptone

Another attribute international users may need to confi gure 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 confi guration options for setting impedance on an FXS port:



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)



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 confi gured to add 2 dB of input gain and –1 dB output attenuation:



c02.indd 48c02.indd 48 9/21/11 11:47:59 AM9/21/11 11:47:59 AM


Router(config-voiceport)#input gain 2

Router(config-voiceport)#output attenuation -1


Lastly, if you confi gure 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(config-voiceport)#echo-cancel coverage 32


Basic FXO Port Configuration

Because FXO ports commonly connect to the PSTN, they should be confi gured with ground-start signaling (although it is possible to have them confi gured with loop-start if the device you are connecting to requires it). Here is an example confi guring of ground-start signaling on an FXO at port 0/1/0 on a Cisco router:



Router(config-voiceport)#signal groundStart


There are two other FXO confi guration 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 confi gure them using the dial-type command, as shown here:



Router(config-voiceport)#dial-type ?

dtmf touch-tone dialer

pulse pulse dialer


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 49c02.indd 49 9/21/11 11:47:59 AM9/21/11 11:47:59 AM


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(config-voiceport)#ring number ?

<1-10> The number of rings detected before closing the loop


As you can see, the voice gateway can be confi gured 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 confi gure an E&M port. Fortunately, as long as you know the settings your Cisco voice gateway requires to connect two PBX systems, the basic confi guration 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 confi gure the E&M type on port 2/1/0 to use E&M type II:



Router(config-voiceport)#type 2

Next, you should confi gure which physical wiring setup needs to be used on the interface. Your choices are two-wire or four-wire. This is confi gured using the operation confi guration command as shown here:



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 confi gure immediate signaling, use the signal command and then choose an E&M signaling type, as shown here:



Router(config-voiceport)#signal immediate

c02.indd 50c02.indd 50 9/21/11 11:48:00 AM9/21/11 11:48:00 AM

Understanding Digital Voice Ports and SignalingPure 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 amplifi ed, so is the background noise that is inherently found on the line. Over time and multiple signal amplifi cations, 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 benefi t 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).

Understanding Digital Voice Ports and Signaling 51

c02.indd 51c02.indd 51 9/21/11 11:48:00 AM9/21/11 11:48:00 AM


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.

Fre

qu

en

cy

Time

Samples

F I GU R E 2 . 9 Discrete signal of an analog wave

c02.indd 52c02.indd 52 9/21/11 11:48:01 AM9/21/11 11:48:01 AM

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.

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.

43

32 32

Fre

qu

en

cy

Time

43

54 5459 59

62 62

F I GU R E 2 .10 Quantizing each sample


c02.indd 53c02.indd 53 9/21/11 11:48:01 AM9/21/11 11:48:01 AM


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

F I GU R E 2 .11 Encoding the quantized sample

0

0

1

0

0

0

0

0

0

0

1

0

1

0

1

1

43

Fre

qu

en

cy

Time

43

3232

54 5459 59

62 62

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

c02.indd 54c02.indd 54 9/21/11 11:48:02 AM9/21/11 11:48:02 AM

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 defi nite 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 diffi cult 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 benefi t 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 defi nition of companding in a digital sense consists of fi rst 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 defi ned in the G.711 (aka pulse-code modulation (PCM)) standard. Companding is the only compression-like technique used by PCM.


c02.indd 55c02.indd 55 9/21/11 11:48:03 AM9/21/11 11:48:03 AM


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 briefl y 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 benefi ts 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 time-based method for sharing a single cable to transport multiple voice signals. Let’s take a T1

c02.indd 56c02.indd 56 9/21/11 11:48:03 AM9/21/11 11:48:03 AM

circuit that uses 24 logical TDM channels, for example. Each channel is assigned a timeslot, which reoccurs in a specifi c 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 fi nished, 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.

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

C

h

a

n

n

e

I

1

C

h

a

n

n

e

I

2

C

h

a

n

n

e

I

3

C

h

a

n

n

e

I

4

C

h

a

n

n

e

I

5

C

h

a

n

n

e

I

21

C

h

a

n

n

e

I

22

C

h

a

n

n

e

I

23

C

h

a

n

n

e

I

24

24 timeslots – 8 bits

F I GU R E 2 .12 T1 TDM channels


c02.indd 57c02.indd 57 9/21/11 11:48:04 AM9/21/11 11:48:04 AM


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.

C

h

a

n

n

e

I

1

C

h

a

n

n

e

I

2

C

h

a

n

n

e

I

3

C

h

a

n

n

e

I

4

C

h

a

n

n

e

I

5

C

h

a

n

n

e

I

21

C

h

a

n

n

e

I

22

C

h

a

n

n

e

I

23

C

h

a

n

n

e

I

24

C

h

a

n

n

e

I

1

C

h

a

n

n

e

I

2

C

h

a

n

n

e

I

3

C

h

a

n

n

e

I

4

C

h

a

n

n

e

I

5

C

h

a

n

n

e

I

21

C

h

a

n

n

e

I

22

C

h

a

n

n

e

I

23

C

h

a

n

n

e

I

24

193 bits 193 bits

TDM cycle 1 + 1

signal bit

TDM cycle 2 + 1

signal bit

12 TDM cycle super frame

C

h

a

n

n

e

I

1

C

h

a

n

n

e

I

2

C

h

a

n

n

e

I

3

C

h

a

n

n

e

I

4

C

h

a

n

n

e

I

5

C

h

a

n

n

e

I

21

C

h

a

n

n

e

I

22

C

h

a

n

n

e

I

23

C

h

a

n

n

e

I

24

C

h

a

n

n

e

I

1

C

h

a

n

n

e

I

2

C

h

a

n

n

e

I

3

C

h

a

n

n

e

I

4

C

h

a

n

n

e

I

5

C

h

a

n

n

e

I

21

C

h

a

n

n

e

I

22

C

h

a

n

n

e

I

23

C

h

a

n

n

e

I

24

193 bits 193 bits

TDM cycle 11 + 1

signal bit

TDM cycle 12 + 1

signal bit

F I GU R E 2 .13 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 benefi t 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 specifi cally, 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 GU R E 2 .14 Extended Super Frame

ChanneI

1

ChanneI

2

ChanneI

3

ChanneI

4

ChanneI

5

ChanneI

21

ChanneI

22

ChanneI

23

ChanneI

24

ChanneI

1

ChanneI

2

ChanneI

3

ChanneI

4

ChanneI

5

ChanneI

21

ChanneI

22

ChanneI

23

ChanneI

24

193 bits 193 bits

TDM cycle 1 + 1signal bit


24 TDM cycle extended super frame

ChanneI

1

ChanneI

2

ChanneI

3

ChanneI

4

ChanneI

5

ChanneI

21

ChanneI

22

ChanneI

23

ChanneI

24

ChanneI

1

ChanneI

2

ChanneI

3

ChanneI

4

ChanneI

5

ChanneI

21

ChanneI

22

ChanneI

23

ChanneI

24

193 bits 193 bits



c02.indd 58c02.indd 58 9/21/11 11:48:04 AM9/21/11 11:48:04 AM

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 GU R E 2 .15 AMI Transport

V

o

l

t

a

g

e

0 1 0 0

Bits

+1

–1

0

1 1 1 0

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 suffi ciently 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 diffi culties 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 specifi c 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 59c02.indd 59 9/21/11 11:48:05 AM9/21/11 11:48:05 AM


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

0 0 0 1

Bits

+1

–1

0

V

o

l

t

a

g

e

1 0 1 1

V

o

l

t

a

g

e

0 0 0 1

Bits

+1

–1

0

1 0 1 1

F I GU R E 2 .16 B8ZS polarity patterns

c02.indd 60c02.indd 60 9/21/11 11:48:06 AM9/21/11 11:48:06 AM

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. There-fore, an ISDN BRI actually has a bandwidth of 144 Kbps.

bundles channels into groups of 16. In this way, channel 1 is used to designate the start of the fi rst 16-multiframe group, while channel 17 is used to designate the second grouping of 16.

Common Channel Signaling

Unlike CAS digital circuits that sacrifi ce 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 benefi ts 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 LE 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


c02.indd 61c02.indd 61 9/21/11 11:48:06 AM9/21/11 11:48:06 AM


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

� Caller ID

� Call transfer

c02.indd 62c02.indd 62 9/21/11 11:48:07 AM9/21/11 11:48:07 AM

� Call redirect

� Do not disturb

Basic Configuration of Digital Voice Ports

When working through the FXS, FXO, and E&M analog confi guration ports, you may have noticed that all of these ports were confi gured by issuing the voice-port command. Similarly, digital voice ports are confi gured using the controller command. The next section will go through how to confi gure basic settings for a T1 CAS and ISDN T1 PRI port.

Basic T1 CAS Configuration

T1 CAS circuits can be confi gured 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 confi gured 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 confi gure our T1 for B8ZS:

Router#config t


Router(config-controller)#linecode ?

ami AMI encoding

b8zs B8ZS encoding

Router(config-controller)#linecode b8zs


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 63c02.indd 63 9/21/11 11:48:07 AM9/21/11 11:48:07 AM


command to set one of these clocking options is clock source. We will confi gure internal clocking for our T1 here:

Router#config t


Router(config-controller)#clock source ?

internal Internal Clock

line Recovered Clock

Router(config-controller)#clock source internal


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 confi gure the signaling type that you wish these timeslots to utilize. The following confi guration shows a new DS0 group (group 0) using timeslots 1–12 and the different signaling types available:



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

<cr>


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 confi guring the switch type is a global confi guration command

c02.indd 64c02.indd 64 9/21/11 11:48:08 AM9/21/11 11:48:08 AM

and not a config-controller command. Listed in the following code snippet are the various switch-type options available. In our example, we will confi gure the switch to use primary-5ess.


Router(config)#isdn switch-type ?

primary-4ess Lucent 4ESS 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 confi gured on an ISDN PRI port. Here is an example of a T1 PRI confi gured for ESF framing, B8ZS as the linecode type, and receiving the clocking from the remote router:





Router(config-controller)#clock source line


Lastly, an ISDN T1 PRI port must be confi gured 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 confi gure a T1 PRI to use all 24 channels:



Router(config-controller)#pri-group timeslots 1-24



c02.indd 65c02.indd 65 9/21/11 11:48:08 AM9/21/11 11:48:08 AM


SummaryChapter 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 confi guration commands necessary to confi gure various analog and digital voice ports that are available on a Cisco voice gateway.

While future chapters in this book will expand on confi guration methods used in confi guring 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 confi guring specifi c settings and how the circuit will operate differently.

Exam EssentialsKnow the three different analog ports used on Cisco gateways. The three analog ports are FXS, FXO, and E&M 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 confi gured 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 66c02.indd 66 9/21/11 11:48:09 AM9/21/11 11:48:09 AM

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 fi rst 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. The three digital ports are T1, E1, and ISDN BRI.

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 confi gured 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.11. 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 notifi es 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.

Written Lab 2.1 67

c02.indd 67c02.indd 67 9/21/11 11:48:09 AM9/21/11 11:48:09 AM


8. Write the command used to confi gure a T1 controller to use the remote-side gateway for clocking while in config-controller mode.

9. Write the command used to confi gure 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 config-controller mode.


c02.indd 68c02.indd 68 9/21/11 11:48:09 AM9/21/11 11:48:09 AM

Review Questions1. Which supervisory signaling type is most recommended for connecting a business PBX to

the CO?

A. Loop-start

B. E&M

C. Ground-start

D. Local-loop

2. What process does DTMF use to specify dialed digits?

A. Combining two audio tones to specify a single digit

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

3. Which type of analog signaling is used to alert a phone user to the progress a telephone call is making?

A. Address

B. E&M

C. Informational

D. Relation

E. Supervisory

4. Ground-start signaling requires what before the ring and tip circuits are connected for line seizure?

A. The local side is grounded.

B. The remote side is grounded.

C. Both the local and remote sites are grounded.

D. The trunk line is grounded.

5. Which E&M signaling methods verify that the remote switch is ready to receive address signaling? (Choose all that apply.)

A. Wink-start

B. Immediate-start

C. Monitor-start

D. Delay-start

Review Questions 69

c02.indd 69c02.indd 69 9/21/11 11:48:10 AM9/21/11 11:48:10 AM


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

B. Immediate-start

C. Ground-start

D. Loop-start

E. Wink-start

7. What informational signaling type specifically indicates that the telephone network is unable to complete the call?

A. Dial tone

B. Reorder tone

C. Receiver off-hook

D. Congestion

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

C. Type V

D. SSDC5

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

B. input impedance

C. input attenuation

D. input cptone

c02.indd 70c02.indd 70 9/21/11 11:48:10 AM9/21/11 11:48:10 AM

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

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

Review Questions 71

c02.indd 71c02.indd 71 9/21/11 11:48:11 AM9/21/11 11:48:11 AM


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

B. Router(config-controller)#type 2

C. Router(config-controller)#signal 2

D. Router(config-voiceport)#type 2

c02.indd 72c02.indd 72 9/21/11 11:48:11 AM9/21/11 11:48:11 AM

Answers to Review Questions1. 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 notifi cation 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 confi gure 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 confi gured on FXS and FXO ports. E&M signaling can be confi gured 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 73c02.indd 73 9/21/11 11:48:11 AM9/21/11 11:48:11 AM


17. C. Q signaling (QSIG) uses Q.931 as its underlying signaling protocol but modifi es the signals so other proprietary ISDN signaling protocols can also be used and understood.

18. C. A T1 port is confi gured within config-controller mode. The correct command to confi gure Extended Super Frame is framing esf.

19. A. The ISDN switch type is a global confi guration 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 specifi es that the E&M interface type is II.

c02.indd 74c02.indd 74 9/21/11 11:48:12 AM9/21/11 11:48:12 AM

Answers to Written Lab 2.11. 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

Answers to Written Lab 2.1 75

c02.indd 75c02.indd 75 9/21/11 11:48:12 AM9/21/11 11:48:12 AM

c02.indd 76c02.indd 76 9/21/11 11:48:12 AM9/21/11 11:48:12 AM

VoIP Operation and Protocols


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.

�

Chapter

3

c03.indd 77c03.indd 77 9/21/11 11:16:21 AM9/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 fi rst 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 specifi cally 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 ProtocolsWhen 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 traffi c 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 effi ciently sent over low-speed serial connections. This is an extension of RTP called cRTP. Finally, we’ll discuss how to confi gure 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 specifi cally 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 78c03.indd 78 9/21/11 11:16:22 AM9/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 effi cient 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 fi nds 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 GU R E 3 .1 RTP end-to-end transport

M

CUCM

Switch

RTP packet flow

IP-phoneBIP-phoneA

SCCP signalingSCCP sig

naling

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 specifi es 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 79c03.indd 79 9/21/11 11:16:23 AM9/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 confi guration problems, he narrowed the root cause to a misconfi gured fi rewall that sits on the edge of the WAN connection. A fi rewall rule was confi gured 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 traffi c traverses a fi rewall. You must take proper care to ensure that your fi rewall is suffi ciently opened to allow RTP streams for a wide range of UDP ports. Otherwise, you will fi nd 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 fi elds. Within the RTP header are various fi elds that hold all kinds of information related to the proper transport of real-time, streaming data. These specifi c RTP header fi elds are listed here:

Version The version fi eld is two bits in size and specifi es 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 fi eld.

Padding The padding fi eld 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 fi eld 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 80c03.indd 80 9/21/11 11:16:23 AM9/21/11 11:16:23 AM

Voice Media Transmission Protocols 81

Marker The marker fi eld is one bit. If this bit is enabled (binary 1), it indicates a unique event that is identifi ed by the application using the RTP stream. Depending on the application, the marker fi eld can mean many different things.

Payload Type The payload fi eld is seven bits in size. This fi eld identifi es the type of RTP data that is inside the payload. This fi eld allows RTP to communicate the transport of voice, data, and other streaming protocols.

Sequence Number The sequence fi eld is 16 bits in size. This fi eld 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 fi eld is 32 bits in size. This fi eld 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 fi eld 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 fi eld is similar to SSRC in that it is used to identify the source of streaming data. The difference is that this fi eld specifi cally identifi es 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 specifi c 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 Provides reception quality feedback from the sending device of the RTP stream.

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 81c03.indd 81 9/21/11 11:16:24 AM9/21/11 11:16:24 AM


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 modifi cation 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 effi cient transport at any given time on a network.

Introduction to Compressed RTP

If you look at the size of an IP packet carrying voice traffi c, 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 fi elds, 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 specifi c stream. cRTP will stop sending this redundant information after the fi rst 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 confi gure 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 benefi ts. With the continuing

c03.indd 82c03.indd 82 9/21/11 11:16:24 AM9/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 confi gured 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 confi gured, 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 confi gured on a voice gateway, they replace the use of standard RTP and RTCP. However, sRTP and sRTCP can be confi gured to use cRTP if desired.

Voice Gateway Signaling ProtocolsVoice gateways are just one component in a Voice over IP solution. As you learned in Chapter 1, “An Introduction to Traditional Telephony and Cisco Unifi ed 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 Unifi ed 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 83c03.indd 83 9/21/11 11:16:25 AM9/21/11 11:16:25 AM


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.

IP phoneCall agent/voice

gateway

Analog phone

PSTN

F I GU R E 3 . 2 Integrated call-processing agent and voice gateway

IP phone Analog phone

PSTNVM

Call agent Voice

gateway

Signaling

protocol

F I GU R E 3 . 3 Separated call-processing agent and voice gateway

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 84c03.indd 84 9/21/11 11:16:25 AM9/21/11 11:16:25 AM


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 specifi cs 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 benefi t 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 specifi es 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-specifi cations.

TA B LE 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 85c03.indd 85 9/21/11 11:16:26 AM9/21/11 11:16:26 AM


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 next-hop location of where the endpoint can be located on a network. The user=phone portion specifi es 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 confi gurations 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 86c03.indd 86 9/21/11 11:16:26 AM9/21/11 11:16:26 AM


messages for the UACs. SIP register servers maintain a database of UA locations (number-to-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 confi gure 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 87c03.indd 87 9/21/11 11:16:27 AM9/21/11 11:16:27 AM


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 call-processing 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 confi guration of a DSP farm or communication with an analog-to-IP VG200, which only runs SCCP. In addition, FXS/FXO ports can be confi gured on a voice gateway to act like any other Cisco IP phone confi gured 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 LE 3 . 2 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

c03.indd 88c03.indd 88 9/21/11 11:16:28 AM9/21/11 11:16:28 AM


An Introduction to Gatekeepers and Other H.323 ComponentsBecause H.323 is a distributed architecture, many devices that utilize H.323 have their own intelligence. Much of this intelligence is offl oaded to specialized hardware that handles specifi c 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 call-processing 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 confi gure dial information for each of the clustered servers/gateways. Figure 3.4 shows a cluster of CUCMs that must be confi gured to know the telephone numbers and IP mappings of each clustered location.

F I GU R E 3 . 4 A call-processing cluster

M

CUCM

M

CUCM

M

CUCM

M

CUCM

Sharing of dial

information

c03.indd 89c03.indd 89 9/21/11 11:16:29 AM9/21/11 11:16:29 AM


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

F I GU R E 3 .5 Call-processing cluster with a gatekeeper

M

CUCM

M

CUCM

M

CUCM

M

CUCM

Zone 1

Sharing of dial

information

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 90c03.indd 90 9/21/11 11:16:29 AM9/21/11 11:16:29 AM


Cisco routers can be confi gured 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 LE 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-specifi c 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 briefl y 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 benefi ts:

� 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 confi gured to route based on the application being used, a capability known as application-specifi c 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 91c03.indd 91 9/21/11 11:16:30 AM9/21/11 11:16:30 AM


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.

H.323

proxy

IP phone

IP phone

PSTN

IP WAN

V

H.323

gatekeeper

H.323

voice

gateway

H.323

MCU

H.323 video

H.323 terminal

Headquarters

VH.323

voice

gateway

V

M

CUCM-1

M

CUCM-2

H.323

terminal

H.323 ISDN

terminal

H.323 ISDN

video

POTS

phone

H.323 video

F I GU R E 3 .6 Common H.323 network components

c03.indd 92c03.indd 92 9/21/11 11:16:30 AM9/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 ProtocolChoosing 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 call-control 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 fl exibility 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 confi gured to act as client-server architectures using proxy servers and gatekeepers.

c03.indd 93c03.indd 93 9/21/11 11:16:31 AM9/21/11 11:16:31 AM


SummaryVoIP 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 fi elds 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 effi cient 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 94c03.indd 94 9/21/11 11:16:31 AM9/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-to-point 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. An H.323 proxy server provides services for call setup and teardown.

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.11. 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 specifi es 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 confi gured 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?


c03.indd 95c03.indd 95 9/21/11 11:16:32 AM9/21/11 11:16:32 AM


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

B. Source and destination MAC

C. RTP header information

D. QoS information

2. RTP was designed and developed by the IETF to be used with which Layer 4 transport protocol?

A. Q.921

B. TCP

C. UDP

D. Q.931

3. How many RTP connections are required for a two-way voice call between IP phones?

A. One

B. Two

C. Four

D. Eight

4. Which of the following voice gateway signaling protocols uses a centralized call-control model? (Choose all that apply.)

A. MGCP

B. SIP

C. SCCP

D. H.323

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

C. 1954

D. 1956

c03.indd 96c03.indd 96 9/21/11 11:16:32 AM9/21/11 11:16:32 AM

Review Questions 97

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

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.

7. Which of the following RTCP packets contains information about the host device, including CNAME, username, email address, and other data?

A. Sender Report

B. Source Description

C. Application-Specific

D. Receiver Report

8. What size is an uncompressed RTP header?

A. 8 bytes

B. 8 bits

C. 12 bytes

D. 12 bits

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

B. On LAN interfaces 10 Mbps and lower

C. On WAN interfaces T1 speeds and higher

D. On WAN interfaces T1 speeds and lower

c03.indd 97c03.indd 97 9/21/11 11:16:33 AM9/21/11 11:16:33 AM


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

c03.indd 98c03.indd 98 9/21/11 11:16:33 AM9/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

B. QoS

C. MCU

D. RTCP

c03.indd 99c03.indd 99 9/21/11 11:16:33 AM9/21/11 11:16:33 AM


Answers to Review Questions1. 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 traffi c.

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 next-highest odd-numbered port that the RTP port has selected.

6. B. The most likely problem is that a fi rewall has been misconfi gured 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 fi elds.

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 confi gured to use a NULL cipher, which essentially disables encryption and sends payload traffi c 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 confi gured on a voice gateway simply performs call setup and signaling.

c03.indd 100c03.indd 100 9/21/11 11:16:34 AM9/21/11 11:16:34 AM


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 101c03.indd 101 9/21/11 11:16:34 AM9/21/11 11:16:34 AM


Answers to Written Lab 3.11. 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 102c03.indd 102 9/21/11 11:16:34 AM9/21/11 11:16:34 AM

The VoIP Path-Selection Process



■ Describe a numbering plan.

■ Describe digit manipulation.

■ Describe path selection.

■ Describe calling privileges.



■ Describe dial peers and the gateway call routing process.


■ Configure dial-peers.

■ Configure digit manipulation.

■ Verify dial-plan implementation.

�

�

�

Chapter

4

c04.indd 103c04.indd 103 9/21/11 11:17:03 AM9/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 modifi ed 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 confi gure 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 ProcessDial plans are confi gured 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 The modifi cation of dialed digits prior to routing a call out of the voice gateway

Calling Privileges 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 benefi ts.

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 confi gured 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 104c04.indd 104 9/21/11 11:17:05 AM9/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 GU R E 4 .1 A local call

IP phone Analog phone

VSwitch

Gi1/0 FXS0/0/0

Voice GW

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.

Switch

IP phone IP phone

Switch

VVS0/1S0/1 Gi1/0Gi1/0

Voice GWVoice GW

IP WAN

F I GU R E 4 . 2 An on-net call

c04.indd 105c04.indd 105 9/21/11 11:17:05 AM9/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.

F I GU R E 4 . 3 An off-net call

Switch

IP phone

Analog phone

VS0/1Gi1/0

Voice GW

PSTN

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 confi gure 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 confi gured 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 106c04.indd 106 9/21/11 11:17:06 AM9/21/11 11:17:06 AM


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.

Switch

IP phone

WANfailure

IP phone

Switch

VVS0/1

S0/2S0/2

S0/1 Gi1/0Gi1/0

Voice GWVoice GW

PSTN

F I GU R E 4 . 4 An on-net to off-net call

Analog phone Analog phonePBX PBX

Tie line

F I GU R E 4 .5 A PBX-to-PBX call

c04.indd 107c04.indd 107 9/21/11 11:17:06 AM9/21/11 11:17:06 AM


Intercluster Trunk Calls

Chapter 1, “An Introduction to Traditional Telephony and Cisco Unifi ed 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.

VV

ClusterM M

IP WAN

F I GU R E 4 .6 An intercluster trunk call

Path Selection and Call Routing

Now that you have an understanding of the different call classifi cations on a network, we can begin to explore how voice gateways can be confi gured 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 confi gures 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 confi gured with dial peers to instruct the router about where they need to send voice traffi c

c04.indd 108c04.indd 108 9/21/11 11:17:07 AM9/21/11 11:17:07 AM


based on the telephone number dialed. The two primary types of dial peers that can be confi gured 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 confi gured 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 confi gured 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 traffi c will exit. An example of POTS dial peers looks like the following:


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)#end

Router#

Here we have confi gured two different POTS dial peers. The fi rst dial peer is identifi ed 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 identifi er, 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 confi gurations:


Router(config)#dial-peer voice 5002 voip

c04.indd 109c04.indd 109 9/21/11 11:17:07 AM9/21/11 11:17:07 AM


Router(config-dial-peer)# destination-pattern 5002

Router(config-dial-peer)#session target ipv4:192.168.1.100






Router#

Here we have confi gured 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 confi guration 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 GU R E 4 .7 POTS and VoIP dial peer example

VV

Analog phone Analog phone

POTS dial peer POTS dial peerVoIPdial peer

VoIPdial peer

PSTN IP WAN PSTN

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 confi gured 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 110c04.indd 110 9/21/11 11:17:08 AM9/21/11 11:17:08 AM


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.

VV

Analog-Phone-A Analog-Phone-B

Inbound POTS call leg

Outbound POTScall leg

InboundVoIP

call leg

OutboundVoIP

call leg

PSTN IP WAN PSTN

F I GU R E 4 . 8 POTS and VoIP call legs

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 confi gured 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 confi gured 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 Identifi cation 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 confi gured 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 111c04.indd 111 9/21/11 11:17:09 AM9/21/11 11:17:09 AM


ANI Number Automatic Number Identifi cation (ANI) is the exact opposite of DNIS. The ANI fi eld is commonly used for billing purposes and cannot be modifi ed. 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 confi gure dial peers to match ANI information.

DNIS Number (again) This might sound confusing, but for inbound dial peers, DNIS information can either be confi gured 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 confi gure 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 confi gured 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 112c04.indd 112 9/21/11 11:17:09 AM9/21/11 11:17:09 AM


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 confi guring 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 specifi c 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-defi ned management boundaries. Control within those boundaries can be handled independently.

Clarity to End Users Your dial plan should make it easy for users to understand how to use the system.

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) Defi nes an optional country- or region-specifi c code

Subscriber Code (SC) Defi nes a central offi ce code

Because the E.164 standard is a hierarchical model, the three codes are built on each other from least specifi c to most specifi c in pinpointing the location of the originating phone that has the telephone number in question, as shown in Figure 4.9.

c04.indd 113c04.indd 113 9/21/11 11:17:10 AM9/21/11 11:17:10 AM


CC-NDC-SC

CC

Least specific

Most specific

NDC

SC

F I GU R E 4 . 9 The E.164 hierarchy

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 fi t. 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 LE 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 114c04.indd 114 9/21/11 11:17:10 AM9/21/11 11:17:10 AM


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 GU R E 4 .10 The NANP hierarchy

Area-CO-Subscriber

Area

Least specific

Most specific

CO

Subscriber

The NANP uses a fi xed 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 LE 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 115c04.indd 115 9/21/11 11:17:11 AM9/21/11 11:17:11 AM


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, “Confi guring 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 confi guration 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 fi ve 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.

TA B LE 4 . 3 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

c04.indd 116c04.indd 116 9/21/11 11:17:12 AM9/21/11 11:17:12 AM


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 offi ces. 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 confi gured to match exact telephone numbers or a range of numbers. Confi guring 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 benefi ts of dial-peer-matching multiple telephone extensions in a single rule.

Cisco has developed a series of wildcard characters that can be used when confi guring 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 dial-peer command.

c04.indd 117c04.indd 117 9/21/11 11:17:12 AM9/21/11 11:17:12 AM


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.

TA B LE 4 . 4 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.

c04.indd 118c04.indd 118 9/21/11 11:17:13 AM9/21/11 11:17:13 AM


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(config-dial-peer)# destination-pattern 4...



Router#

Example 2: Matching Digits Using [ ]

In our next example, you again are confi guring 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.

IP phone

IP phone

IP phone

IP phone

IP phone

IP phone

VVVG2VG1

Extensions:

5XXX

Extensions:

4XXX

IP WAN

F I GU R E 4 .11 Wildcard example 1


IP phone

IP phone

IP phone

IP phone

IP phone

IP phone

VVVG2VG1

Extensions:

4000-4299

Extensions:

4300-4999

IP WAN

c04.indd 119c04.indd 119 9/21/11 11:17:14 AM9/21/11 11:17:14 AM


In this case, you can use a combination of [ ] and . wildcards to designate the destination pattern, as shown here:



Router(config-dial-peer)# destination-pattern 4[3–9]..



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(config-dial-peer)# destination-pattern 54(11)?



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(config-dial-peer)# destination-pattern 54(11)%



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(config-dial-peer)# destination-pattern 54(11)+

c04.indd 120c04.indd 120 9/21/11 11:17:14 AM9/21/11 11:17:14 AM




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.

IP phone

IP phone

IP phone

VVoice

gateway

9T

PSTN


Here is the confi guration needed to forward all calls beginning with 9 out the T1 PRI circuit to the PSTN:



Router(config-dial-peer)# destination-pattern 9T

Router(config-dial-peer)# port 0/0/0:23


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 site-code dialing and is described in more detail in the next section. It is important to note that this specifi c 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 121c04.indd 121 9/21/11 11:17:15 AM9/21/11 11:17:15 AM


Site-Code Dialing

You may fi nd 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 GU R E 4 .14 Site-code configuration example. This approach won’t work with overlapping extensions

IP phone

IP phone

IP phone

IP phone

IP phone

IP phone

IP phone IP phone IP phone

V

V

VVG2VG1

Site 3VG3

Extensions:

3XXX

Extensions:

3XXX

Extensions:

3XXX

IP WAN

Site 2Site 1

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 LE 4 .5 DID ranges and extensions

Site Name DID Numbers Four-Digit Extensions

Site 1 222–555–3XXX 3XXX



c04.indd 122c04.indd 122 9/21/11 11:17:15 AM9/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 confi gure 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 ManipulationThere 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 fi rst was off-network dialing, when the user enters the number 9 to indicate an off-network 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 destination-pattern 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:





c04.indd 123c04.indd 123 9/21/11 11:17:16 AM9/21/11 11:17:16 AM



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(config-dial-peer)# no digit-strip



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 specifi es 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 forward-digits command to send all four digits including the three wildcard numbers:




Router(config-dial-peer)# forward-digits 4



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(config-dial-peer)# destination-pattern 835.......

c04.indd 124c04.indd 124 9/21/11 11:17:16 AM9/21/11 11:17:16 AM


Router(config-dial-peer)# forward-digits 7



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 fl exible 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(config-dial-peer)# destination-pattern 1..........

Router(config-dial-peer)#no digit-strip

Router(config-dial-peer)# prefix 9,



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 125c04.indd 125 9/21/11 11:17:17 AM9/21/11 11:17:17 AM


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 confi guration 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 LE 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 modifi ed to the full 10-digit number:


Router(config)# num-exp 2... 9000



Router(config-dial-peer)# port 0/0/2


Router#

c04.indd 126c04.indd 126 9/21/11 11:17:17 AM9/21/11 11:17:17 AM


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 identifi cation, 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 fi rst number is the unscreened number, which the calling party actually entered into their telephone. The second is the network-provided number. Several confi guration commands can be used, but the most common are shown in this example:



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 confi gure 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 127c04.indd 127 9/21/11 11:17:18 AM9/21/11 11:17:18 AM


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 LE 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 diffi cult 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 simplifi ed structure and true power that these rules offer. To help you better understand rule creation, we will examine some rule-creation examples.

c04.indd 128c04.indd 128 9/21/11 11:17:18 AM9/21/11 11:17:18 AM


Translation Rule Example 1

This fi rst example will be a simple extension-to-extension translation rule. The fi rst command will specify the rule set identifi cation 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 profi les. The second command is rule rule-number followed by the matched and translated numbers inside the / / matching and replacement regular expressions:


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.


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 confi guration to match any characters using the /^$/ regular expression that matches any digits. The rule then replaces it with extension 3000:



Router(cfg-translation-rule)#rule 1 /^$/ /3000/


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(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 129c04.indd 129 9/21/11 11:17:19 AM9/21/11 11:17:19 AM


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 signifi cance in the replacement string expression, however. This means that the fi rst set of numbers we have inside parentheses (XXX) are to be pulled into the fi nal 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 unmodifi ed and are to be processed in the fi nal 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 translation-rule 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: 7890

Original number type: none Translated number type: none

Original number plan: none Translated number plan: none

Router#

c04.indd 130c04.indd 130 9/21/11 11:17:19 AM9/21/11 11:17:19 AM


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 confi gure translation rule sets and rules, you need to learn how to confi gure 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 identifi es it with a name.

Once you name the translation profi le, 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 LE 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(config)#voice translation-profile PSTN-out

Router(cfg-translation-profile)#translate called 909

Router(cfg-translation-profile)#end

Router#

c04.indd 131c04.indd 131 9/21/11 11:17:20 AM9/21/11 11:17:20 AM


Here we create a translation profi le named PSTN-out. Within the translation profi le confi guration 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 confi gure translation profi les on dial peers, you must enter into dial-peer confi guration 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 confi gure 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)# translation-profile outgoing PSTN-out

Router(config-dial-peer)# end

Router#

Alternatively, a translation profi le can be confi gured directly on a POTS port that is installed on your voice gateway. The actual translation-profile command has the exact same confi guration 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(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 confi gurations 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 confi gured 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 132c04.indd 132 9/21/11 11:17:20 AM9/21/11 11:17:20 AM


Router# show dial-peer voice summary

dial-peer hunt 0

OPER DEST PASS TAG TYPE ADMIN PREFIX PATTERN PREF THRU SESS-TARGET PORT

10 voip up up 1.. 1 syst ipv4:192.168.10.1


100 pots up up 0 0 1/0/0

101 pots up up 0 0 1/0/1

Router#

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 specifi c telephone number. This will verify that the correct dial peer will be used if you have multiple dial peers confi gured 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 133c04.indd 133 9/21/11 11:17:21 AM9/21/11 11:17:21 AM


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.

Debug voice translation 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.

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 134c04.indd 134 9/21/11 11:17:21 AM9/21/11 11:17:21 AM

SummaryAs 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 confi guring 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 EssentialsUnderstand 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 traffi c outbound on POTS interfaces such as FXS, FXO, and T1 interfaces. VoIP dial peers send traffi c to IP network destinations.

Be able to describe and Identify call legs and dial peers on a diagram. Dial peers are the physical confi guration 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 confi gured 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.

Exam Essentials 135

c04.indd 135c04.indd 135 9/21/11 11:17:22 AM9/21/11 11:17:22 AM


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 confi gurations by using characters to signify various dialed-number ranges. By doing so, they allow you to manually confi gure 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.11. 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 confi gured 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 specifi c 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?


c04.indd 136c04.indd 136 9/21/11 11:17:22 AM9/21/11 11:17:22 AM

Review Questions 137

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

B. It can provide digit-manipulation techniques.

C. It determines how UDP is directed though IP networks.

D. It can provide calling privilege techniques.

2. Which voice call type best describes when a local user inside the organization calls their home telephone number?

A. Off-net

B. On-net-to-off-net

C. PBX-to-PBX

D. Intercluster

3. Which of the following does a POTS dial peer not provide routing information for?

A. Local IP phones

B. Local fax machines

C. Off-net PSTN calls

D. Local analog phones

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

B. The destination pattern

C. The DNIS

D. The ANI

5. Which of the following is the correct way to route outbound POTS dial peers?

A. Router(config-dial-peer)# destination-pattern 4040

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

c04.indd 137c04.indd 137 9/21/11 11:17:23 AM9/21/11 11:17:23 AM


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

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

7. A VoIP call traverses a WAN connection; how many dial peers are needed to traverse the IP WAN?

A. Zero

B. One

C. Two

D. Four

8. Which of the following is a one-way logical representation of a single hop along an end-to-end voice call?

A. Dial peer

B. Dial plan

C. Call leg

D. Digit manipulation

9. 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. National destination code

C. Country code

D. Area code

c04.indd 138c04.indd 138 9/21/11 11:17:23 AM9/21/11 11:17:23 AM


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


Router(config-dial-peer)# destination-pattern 33(22)+


A. 3322

B. 332222

C. 33

D. 33222


Router(config-dial-peer)# destination-pattern 413..[3–5].


A. 4132248

B. 4134551

C. 4135328

D. 4136678

c04.indd 139c04.indd 139 9/21/11 11:17:23 AM9/21/11 11:17:23 AM


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:

PASSTAG TYPE ADMIN OPER PREFIX DEST-PATTERN PREF THRU SESS-TARGET PORT

1 voip up up 4... 0 syst ipv4:192.168.10.1


10 pots up up 3... 0 1/0/0

20 pots up up 54.. 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. \

B. /

C. ^

D. [

c04.indd 140c04.indd 140 9/21/11 11:17:24 AM9/21/11 11:17:24 AM


1. C. UDP is a Layer 4 protocol used in the transport of IP traffi c 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 confi gure a dial peer, it must have a unique tag identifi er 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 specifi ed.

7. C. A dial peer is needed to send the traffi c out the IP WAN interface, and a second dial peer is needed to accept the traffi c 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 specifi es 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 confi gured 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 141c04.indd 141 9/21/11 11:17:24 AM9/21/11 11:17:24 AM


17. A, B, C. A translation rule set must fi rst be confi gured; it may contain up to 15 different matching/translation rules. A translation profi le is then confi gured, which references the translation rule set. Finally, the translation profi le can be applied to inbound and/or outbound calls.

18. A. The TAG specifi es 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 signifi es both the start and end of a match or translation string.

c04.indd 142c04.indd 142 9/21/11 11:17:25 AM9/21/11 11:17:25 AM

Answers to Written Lab 4.11. Local

2. SIP and H.323

3. voip

4. Inbound

5. Central offi ce code

6. ?

7. 5(54)+

8. 9T

9. prefix 9,

10. debug voice translation


c04.indd 143c04.indd 143 9/21/11 11:17:25 AM9/21/11 11:17:25 AM

c04.indd 144c04.indd 144 9/21/11 11:17:25 AM9/21/11 11:17:25 AM

VoIP Design Options



a VoIP call.

■ Choose the appropriated codec for a given scenario.

■ Describe and configure VLANs.



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

■ Describe the causes of voice and video quality issues.

■ Describe QoS requirements for voice and video traffic.

�

�

�

Chapter

5

C05.indd 145C05.indd 145 9/21/11 11:18:46 AM9/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 implementa-tion. First, you need to understand the full capabilities of voice

gateway DSPs and how they can be used to offl oad processor-intensive tasks from the call-processing 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 net-work as well as the fi delity 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 FunctionsVoice gateways do much more than simply route calls between networks. They can also be used to offl oad 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, traffi c 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 Unifi ed Communications Manager can perform transcoding locally, but these can be offl oaded to voice gateways with high-speed DSPs.

Media Termination Point A voice gateway can be confi gured 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:

� Call hold

� Call transfer

� Call park

� Conference calling

C05.indd 146C05.indd 146 9/21/11 11:18:47 AM9/21/11 11:18:47 AM

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 Unifi ed 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 offl oaded to the voice gateways where DSPs can be used to offl oad call-mixing duties, as shown in Figure 5.1.

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

IP Phone

Voice gateway offloading

conference calling

IP WAN VV

M

F I GU R E 5 .1 : Conference call offloading

Understanding Voice and VoIP Quality Considerations 147

C05.indd 147C05.indd 147 9/21/11 11:18:48 AM9/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 fi nished 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 fi delity. When audio is sampled using narrowband (300–3400 Hz) frequencies and is then highly compressed, the audio is considered to be low fi delity, while voice samples taken with a larger range of wideband frequencies (50–7000 Hz) and transported using lower compression ratios are called high fi delity. The difference between narrowband and wideband voice collection is displayed in Figure 5.2.

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 refl ection 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 amplifi ed 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

50 300 3400 7000

Frequency (Hz)

Ga

in

F I GU R E 5 . 2 Narrowband and wideband frequency collection

C05.indd 148C05.indd 148 9/21/11 11:18:48 AM9/21/11 11:18:48 AM

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 two-wire 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(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 149C05.indd 149 9/21/11 11:18:49 AM9/21/11 11:18:49 AM


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 fi rst 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 diffi culty 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(config-dial-peer)#no vad


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.

Ga

in

Time

VADVAD timer

Background noise

F I GU R E 5 . 3 An example of VAD

C05.indd 150C05.indd 150 9/21/11 11:18:50 AM9/21/11 11:18:50 AM

This number can be adjusted from 250 ms to 65536 ms. Here is an example of adjusting VAD detection to 750 ms:


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(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 151C05.indd 151 9/21/11 11:18:50 AM9/21/11 11:18:50 AM


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

1 2 3

130 ms

4 5

55 ms40 ms40 ms

F I GU R E 5 . 4 Jitter variation

C05.indd 152C05.indd 152 9/21/11 11:18:51 AM9/21/11 11:18:51 AM

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 confi guring Quality of Service (QoS) settings to ensure that real-time packet transmissions such as voice are prioritized ahead of data traffi c. The next section covers several voice codecs available on Cisco endpoints and voice gateways. Quality of Service considerations and confi gurations will be covered in Chapters 11, “Introduction to Quality of Service,” and 12, “Confi guring Quality of Service,” of this book.

Defining Voice CodecsWe’ve talked a little bit about codecs but have never offi cially 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 sacrifi ces 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

Defining Voice Codecs 153

C05.indd 153C05.indd 153 9/21/11 11:18:51 AM9/21/11 11:18:51 AM


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 suffi cient. 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 specifi cations 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 mu-law) 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 154C05.indd 154 9/21/11 11:18:52 AM9/21/11 11:18:52 AM

The non-Annex A variation does not have built-in VAD support. There are two additional options when confi guring 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 offi cially 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 benefi t of the G.726 protocol is that if the PSTN or PBX is confi gured 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 Sub-Band 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 less-compressed (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 Requires less DSP processing power but provides lower-quality audio.


C05.indd 155C05.indd 155 9/21/11 11:18:52 AM9/21/11 11:18:52 AM


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 medium-complexity 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 high-fidelity 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 benefi cial 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 offl oad 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 156C05.indd 156 9/21/11 11:18:53 AM9/21/11 11:18:53 AM

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 confi gurations shown in Table 5.1.

The more advanced and higher-density PVDM3 capabilities are listed in Table 5.2.

TA B LE 5 .1 PVDM2 DSP capabilities

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

TA B LE 5 . 2 PVDM3 DSP capabilities

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


C05.indd 157C05.indd 157 9/21/11 11:18:54 AM9/21/11 11:18:54 AM


Because DSPs handle a wide variety of voice duties, it can be diffi cult to understand how many DSPs you will need to install on your voice gate-ways. 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 medium-complexity 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 confi gured manually for DSP chipsets using the codec complexity type command within config-voicecard mode. On C549 DSP chips, you can confi gure each DSP as being either medium or high complexity, as shown here:


Router(config)#voice-card 1

Router(config-voicecard)#codec complexity ?

high Set codec complexity high. High complexity, lower call density.

medium Set codec complexity medium. Mid range complexity and call density.

<cr>

Router(config-voicecard)#codec complexity

C05.indd 158C05.indd 158 9/21/11 11:18:54 AM9/21/11 11:18:54 AM

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 confi gured 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 confi gure 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 busi-nesses 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 net-work 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 modifi cation 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 fi gure 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 confi gured 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 confi gured for high complexity or in variable fl ex mode.

The C5510 (PVDM2) and PVDM3 chipsets offer two additional confi guration options that can be set as shown here:



Router(config-voicecard)#codec complexity ?

flex Set codec complexity Flex. Flex complexity, higher call density.

high Set codec complexity high. High complexity, lower call density.

medium Set codec complexity medium. Mid range complexity and call density.

secure Set codec complexity secure.

<cr>

Router(config-voicecard)#codec complexity


C05.indd 159C05.indd 159 9/21/11 11:18:55 AM9/21/11 11:18:55 AM


The flex option is different from the high and medium complexity settings because fl ex mode allows for the oversubscription of calls and allows low-, medium-, and high-complexity calls to be processed on a DSP. While fl ex mode is benefi cial 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 confi gured as fl ex resources. The show voice dsp command can be used to verify how your DSPs are currently confi gured, as shown in the following example:

Router# show voice dsp

——————————————FLEX VOICE CARD 1———————————————

*DSP VOICE CHANNELS*

DSP DSP DSPWARE CURR BOOT PAK TX/RX

TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABRT PACK COUNT

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

C5510 001 01 modem-re 4.5.909 busy idle 0 0 1/1/0 05 0 298/353

*DSP SIGNALING CHANNELS*



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

C5510 001 05 {flex} 4.5.909 alloc idle 0 0 1/1/3 02 0 15/0

C5510 001 06 {flex} 4.5.909 alloc idle 0 0 1/1/2 02 0 17/0

C5510 001 07 {flex} 4.5.909 alloc idle 0 0 1/1/1 06 0 31/0

C5510 001 08 {flex} 4.5.909 alloc idle 0 0 1/1/0 06 0 321/0

————————————END OF FLEX VOICE CARD 1——————————————

As you can see from the output, these DSPs use the C5510 chipset and are set for fl ex mode.

Quantifying Voice Codec ClarityAs 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 160C05.indd 160 9/21/11 11:18:55 AM9/21/11 11:18:55 AM

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 offi cial ITU-T MOS scoring tests.

TA B LE 5 . 3 MOS listening quality scale

MOS Score MOS Subjective Rating

5 Excellent

4 Good

3 Fair

2 Poor

1 Bad

Quantifying Voice Codec Clarity 161

C05.indd 161C05.indd 161 9/21/11 11:18:56 AM9/21/11 11:18:56 AM


Table 5.4 shows the results of the MOS testing for several popular voice codecs.

While the ITU-T MOS scale was performed by the ITU-T using the most scientifi c 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 specifi cs 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

TA B LE 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

C05.indd 162C05.indd 162 9/21/11 11:18:56 AM9/21/11 11:18:56 AM

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-fi delity wideband codecs and voice codec operation over 3G and 4G networks.

Choosing the Right CodecWith 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.

Choosing the Right Codec 163

C05.indd 163C05.indd 163 9/21/11 11:18:57 AM9/21/11 11:18:57 AM


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 effi ciently on your network, you should use the codec with the higher voice clarity quantization (such as MOS).

Calculating IP Voice Bandwidth ConsumptionBefore 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 164C05.indd 164 9/21/11 11:18:57 AM9/21/11 11:18:57 AM

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 fi nding 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 confi gured 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.

Calculating IP Voice Bandwidth Consumption 165

C05.indd 165C05.indd 165 9/21/11 11:18:58 AM9/21/11 11:18:58 AM


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 traffi c 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 traffi c needs to be tunneled through other protocols for security and connectivity reasons. This tunneling adds signifi cantly 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.

Voice payload ESP tailESP

head

New

IPIP UDP RTP

RTPUDPIP Voice payload

F I GU R E 5 .5 An example of IPSec overhead

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 166C05.indd 166 9/21/11 11:18:58 AM9/21/11 11:18:58 AM

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.

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

TA B LE 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


C05.indd 167C05.indd 167 9/21/11 11:18:59 AM9/21/11 11:18:59 AM


Next, we can calculate the PPS rate for our call:


PPS = 8000 / 240

PPS = 33.33

Finally, we can determine the amount of bandwidth used per voice stream, as shown here:


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 = 16000 / 480

PPS = 30.33

Finally, we can determine the amount of bandwidth used per voice stream as shown here:


call_bandwidth = 1168 × 33.33

call_bandwidth = 38,929 bps

C05.indd 168C05.indd 168 9/21/11 11:18:59 AM9/21/11 11:18:59 AM

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.

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.

F I GU R E 5 .6 The Cisco Voice Codec Bandwidth Calculator


C05.indd 169C05.indd 169 9/21/11 11:19:00 AM9/21/11 11:19:00 AM


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 EssentialsUnderstand 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 fi delity, 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 fi delity 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 170C05.indd 170 9/21/11 11:19:00 AM9/21/11 11:19:00 AM

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.11. 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 per-son’s voice from being sent.

3. What IOS command can be used in global confi guration 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 compres-sion?

6. What voice card confi guration command is used to set codec complexity to high?

7. What show command can be used to see what complexity settings your DSPs are cur-rently confi gured 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?


Written Lab 5.1 171

C05.indd 171C05.indd 171 9/21/11 11:19:01 AM9/21/11 11:19:01 AM


Review Questions1. Why are DSP resources needed to process DTMF tones between SIP and SCCP devices?

A. SCCP does not use DTMF.

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.

2. On an IP network, what is the most common reason for echo?

A. VAD clipping

B. Glare

C. Network delay

D. Impedance

3. Under normal conditions, VAD can eliminate what percentage of bandwidth on a network?

A. 10 percent

B. 40 percent

C. 5 percent

D. 35 percent

4. When configuring a POTS port, how can you enable both VAD and comfort noise synthesis? (Choose two.)

A. vad

B. VAD is enabled by default on POTS interfaces.

C. comfort-noise

D. voice vad-time 750

5. What are the two different types of network delay? (Choose two.)

A. Fixed

B. Variable

C. Queuing

D. Static

6. What is the definition of network jitter?

A. The amount of time it takes a packet to travel from its source to the destination

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

C05.indd 172C05.indd 172 9/21/11 11:19:01 AM9/21/11 11:19:01 AM

7. All Cisco IP phones support what two voice codecs?

A. G.729

B. G.722

C. iLBC

D. iSAC

E. G.711

8. Which G.729 codec operates at medium complexity and has built-in VAD?

A. G.729a

B. G.729b

C. G.729i

D. G.729ab

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

B. PSQM

C. MOS

D. POLQA


C05.indd 173C05.indd 173 9/21/11 11:19:02 AM9/21/11 11:19:02 AM


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 frame-relay 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. 33.33

C. 50

D. 10

C05.indd 174C05.indd 174 9/21/11 11:19:02 AM9/21/11 11:19:02 AM

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

B. Jitter

C. Packet loss

D. VAD


C05.indd 175C05.indd 175 9/21/11 11:19:03 AM9/21/11 11:19:03 AM


Answers to Review Questions1. 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 176C05.indd 176 9/21/11 11:19:03 AM9/21/11 11:19:03 AM


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 177C05.indd 177 9/21/11 11:19:03 AM9/21/11 11:19:03 AM


Answers to Written Lab 5.11. 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 178C05.indd 178 9/21/11 11:19:04 AM9/21/11 11:19:04 AM

Configuring Voice Gateway Ports and DSPs



Configure analog voice ports.

Configure digital voice ports.

Configure dial peers.

Verify a dial plan implementation.


Describe different voice ports and their functionality.

�

■

■

■

■

�

■

Chapter

6

c06.indd 179c06.indd 179 9/21/11 11:19:30 AM9/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 confi gure our Cisco

voice gateways for operation on IP and PSTN networks. In this chapter, we’ll go through the full confi guration process to set up analog and digital interfaces in various scenarios. In addition, we will go through the process of confi guring a digital signal processor (DSP) farm that offl oads services from a CUCM. At the end of this chapter, we will examine several show, test, and debug commands used to verify confi gurations and troubleshoot voice gateways.

Analog Port ConfigurationsIn this section you’ll see how to confi gure 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 fi rst example will show how to confi gure 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 GU R E 6 .1 An Example of FXS and FXO PLAR OPX

Remote office

Ext: 2222

PLAR OPX

2222

555-321-1234

0/1/0

FXO

0/0/0

FXS VPSTN

FXS interfaces commonly connect analog telephones or fax machines to voice gateways. To confi gure an FXS port, you need to enter into config-voiceport mode by choosing the slot/port number you wish to confi gure. For example, if we wanted to confi gure FXS port 0/0/0 on our router, we would issue the following commands:

c06.indd 180c06.indd 180 9/21/11 11:19:31 AM9/21/11 11:19:31 AM

Analog Port Configurations 181




Once we are in config-voiceport mode, the FXS ports can be confi gured for various signaling. By default, FXS ports are confi gured to operate identically to a POTS line in the United States. Some of the default confi guration settings will need to be modifi ed 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 fl owing 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 confi guration, we will choose to confi gure loop-start signaling because it is more common.

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

Router(config-voiceport)#cptone ?

locale 2 letter ISO-3166 country code

AR Argentina IN India PE Peru

AU Australia ID Indonesia PH Philippines

AT Austria IE Ireland PL Poland

BE Belgium IL Israel PT Portugal

BR Brazil IT Italy RU Russian Federation

CA Canada JP Japan SA Saudi Arabia

CN China JO Jordan SG Singapore

CO Colombia KE Kenya SK Slovakia

C1 Custom1 KR Korea Republic SI Slovenia

C2 Custom2 KW Kuwait ZA South Africa

CY Cyprus LB Lebanon ES Spain

CZ Czech Republic LU Luxembourg SE Sweden

DK Denmark MY Malaysia CH Switzerland

EG Egypt MX Mexico TW Taiwan

FI Finland NP Nepal TH Thailand

FR France NL Netherlands TR Turkey

DE Germany NZ New Zealand AE United Arab Emirates

GH Ghana NG Nigeria GB United Kingdom

c06.indd 181c06.indd 181 9/21/11 11:19:31 AM9/21/11 11:19:31 AM

182 Chapter 6 ■ Configuring Voice Gateway Ports and DSPs

GR Greece NO Norway US United States

HK Hong Kong OM Oman VE Venezuela

HU Hungary PK Pakistan ZW Zimbabwe

IS Iceland PA Panama

Router(config-voiceport)#cptone

Since our example router is in Thailand, we will use TH as our country code.

ring cadence This command modifi es the pulse and interval times when your analog phone rings. This command fi rst looks to the cptone locale and uses the default specifi ed for that specifi c 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 preconfi gured patterns or defi ne your own pulse/interval settings. In our case, we will choose to modify our ring cadence to use pattern08.

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

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 confi gure the FXS port that is attached to our phone to the extension 2222 and a name of Remote-Offi ce.

no shutdown This command activates the FXS port we are confi guring 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 confi guration for a single FXS port in Thailand would look like this:




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 182c06.indd 182 9/21/11 11:19:32 AM9/21/11 11:19:32 AM


Now that we have our FXS port confi gured, we can confi gure 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.

Confi guring an FXO port is similar to confi guring an FXS port. The FXO port can be confi gured for either loop-start or ground-start signaling. The vast majority of the time, you will confi gure 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-specifi c commands when confi guring your voice port: dial-type and ring number.

You can choose to confi gure your FXO port to use DTMF or pulse dialing using the dial-type command. We will confi gure 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 confi gure 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 confi guration. 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 confi gured on FXS interfaces in locations such as public lobbies that will automatically match the extension number attached to the PLAR command with a preconfi gured dial peer that points to the location of the information operator. In this situation, as soon as the PLAR-confi gured phone goes off-hook, the remote extension is dialed. To confi gure 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 confi guration options are default settings, this example confi gures them for learning purposes. Therefore, the fi nal FXO port confi guration looks like this:




Router(config-voiceport)#dial-type dtmf

c06.indd 183c06.indd 183 9/21/11 11:19:32 AM9/21/11 11:19:32 AM


Router(config-voiceport)#ring number 1

Router(config-voiceport)#connection plar opx 2222



Router#

Now that we have our physical ports confi gured, we need to confi gure 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 confi gure 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 confi guration for our fi rst POTS dial peer looks like this:






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 confi guration 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(config-dial-peer)#destination-pattern 9T



Router#

The result of these confi gurations 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 184c06.indd 184 9/21/11 11:19:33 AM9/21/11 11:19:33 AM


offi ces 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 fi rst 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 confi gured to handle outbound calling. Figure 6.2 shows our example scenario, in which an FXS/DID interface will be used for inbound DID calling.

F I GU R E 6 . 2 FXS/DID inbound and FXO outbound

Ext: 30053005

Inbound calls

Outbound calls

PSTN

strips off

555-441

555-441-3005

1/0/0

FXO

0/0/0

FXS/DID

0/0/1

FXS VPSTN

Let’s say we have a small offi ce 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 confi gured on FXS interface 0/0/1.

First, we will confi gure our FXS/DID port that connects to the PSTN and the FXS port that connects to the analog phone:



Router(config-voiceport)#signal did wink-start


Router(config-voiceport)#voice-port 0/0/1




Router#

Next, we will confi gure 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 185c06.indd 185 9/21/11 11:19:33 AM9/21/11 11:19:33 AM


the incoming called-number .... command so we can match any four digits that come in from the PSTN:



Router(config-dial-peer)#direct-inward-dial

Router(config-dial-peer)#incoming called-number....



Router#

Now we can confi gure the dial peer for our analog phone at extension 3005:






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-inward-dial 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 confi gure off-network dialing on our FXO interface. To accomplish this goal, we will confi gure 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 digit-matching confi guration used to dial nationally within the NANP. Be sure to strip off only the 9 and send all other digits to the PSTN:



c06.indd 186c06.indd 186 9/21/11 11:19:34 AM9/21/11 11:19:34 AM




Router(config-voiceport)#exit


Router(config-dial-peer)#destination-pattern 9[2–8].........

Router(config-dial-peer)#forward-digits 10


Configuring E&M to Bridge Legacy PBX with VoIP

Networks

If you need to confi gure 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.

F I GU R E 6 . 3 E&M to bridge legacy and VoIP networks

Extensions

4xxx

Extensions

5xxx

2/1Fa 4/0

2/0

PBX

PBX E&M settings:

Type I

4-wire

Immediate-start

E & M

Trunks

VIP 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 confi gure and enable our two E&M ports:


Router(config)#voice-port 2/0

Router(config-voiceport)#signal immediate-start

■

■

■

c06.indd 187c06.indd 187 9/21/11 11:19:34 AM9/21/11 11:19:34 AM


Router(config-voiceport)#operation 4-wire



Router(config-voiceport)#voice-port 2/1

Router(config-voiceport)#signal immediate-start





Next, we will confi gure dial peers that match our four-digit PBX extension numbers and forward them to our two E&M ports:


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




Lastly, we can confi gure a dial peer for calls coming inbound from the E&M ports that are destined to our IP phones. Note that this confi guration assumes that our voice gateway is properly confi gured for IP routing between the two voice gateways shown in Figure 6.3.

Router(config-dial-peer)#dial-peer voice 5000 voip



Configuring CAMA

In North America, there are special port confi gurations 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 specifi c extension. Therefore, the Automatic Number Identifi cation (ANI) is used by emergency services to better pinpoint where a caller is within a business.

c06.indd 188c06.indd 188 9/21/11 11:19:35 AM9/21/11 11:19:35 AM


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 confi gure CAMA trunks such as the four-port VIC-4FXO. There are fi ve CAMA signaling options to choose from, as shown in this example:

Router(config-voiceport)#signal cama ?

KP-0-NPA-NXX-XXXX-ST Type 2 CAMA Signaling

KP-0-NXX-XXXX-ST Type 1 CAMA Signaling

KP-2-ST Type 3 CAMA Signaling

KP-II-NPA-NXX-XXXX-ST-KP-NPA-NXX-XXXX-ST Type 5 CAMA Signaling

KP-NPD-NXX-XXXX-ST Type 4 CAMA Signaling

<cr>

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 KP-0-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 confi gure your CAMA for the proper signaling it is expecting.

F I GU R E 6 . 4 CAMA trunk to E911 services

VPSTN

PSAPKP-0-NPA-

NXX-XXXX-ST

911 with ANI forreverse lolkup

CAMA0/1

Dial peermatched and

911 digitssent toPSAP.

911 OR 9911is dialed.

E911operators

Internal voicenetwork

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.

c06.indd 189c06.indd 189 9/21/11 11:19:35 AM9/21/11 11:19:35 AM


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 confi gure KP-0-NXX-XXXX-ST signaling. In addition to the port setup, we will confi gure 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 confi guration of the voice port looks like this:


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



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 confi gured, we can create the dial peers to send 911 and 9911 calls out the CAMA interface. Here’s how to accomplish this task:











Router#

c06.indd 190c06.indd 190 9/21/11 11:19:36 AM9/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 confi guration. 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 confi gurations, 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 ConfigurationsNow we will move on to discuss various digital port confi gurations. Digital PSTN connections are commonly used as multichannel trunks to the PSTN. In this section, we will confi gure 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 confi gure 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 confi gure it to operate in a channel bank mode, where the digital circuit cross-connects to analog lines.

PSTN

PSTN CAS settings:

ESF

B8ZS

Clock from PSTN

0/0/0

FXS

1/0 T1

CASFax

V

F I GU R E 6 .5 A CAS channel bank example

To confi gure 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 confi gured by entering config-controller mode. Compare this to how we

c06.indd 191c06.indd 191 9/21/11 11:19:36 AM9/21/11 11:19:36 AM


confi gure analog ports, by entering config-voiceport mode. In our example, we will fi rst confi gure 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 confi gured as FXO with ground-start signaling

The framing type sets the framing that your PSTN provider has confi gured on their end. You can see the options listed here while in config-controller mode:

Router#config t


Router(config-controller)#framing ?

esf Extended Superframe

sf Superframe

We will confi gure ESF framing for the T1 CAS:



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 confi gure it here:

Router(config-controller)#linecode ?

ami AMI encoding

b8zs B8ZS encoding



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



■

■

■

■

c06.indd 192c06.indd 192 9/21/11 11:19:37 AM9/21/11 11:19:37 AM


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 confi gure 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 confi gured 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

<cr>

Router(config-controller)#ds0-group 0 timeslots 1 type

Now we will confi gure ds0-group 0 to include the fi rst timeslot with loop-start signaling. Ds0-group 1 will then be confi gured for E&M immediate start. We then individually confi gure 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-voiceport)#signal loop-start




Router(config-voiceport)#signal wink-start




Router#

c06.indd 193c06.indd 193 9/21/11 11:19:37 AM9/21/11 11:19:37 AM


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 confi gure 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 confi guration command we need to use here to complete the channel bank cross-connect is connect name voice-port analog-port T1 digital-port ds0-group-number, which specifi es that we will be mapping our DS0 channels to our two FXS ports. The name specifi es a unique name identifi er, 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 confi guration, 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 confi guration we confi gure dial peers for our FXS and E&M analog ports. We will also confi gure 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)#destination-pattern 555200....



Router(config-dial-peer)#incoming called-number.

Router(config-dial-peer)#port 1/0:0


Router(config-dial-peer)#incoming called-number.



Router(config-dial-peer)#incoming called-number 555200....


Router(config-dial-peer)# dial-peer voice 9 pots




c06.indd 194c06.indd 194 9/21/11 11:19:38 AM9/21/11 11:19:38 AM


Router(config-dial-peer)# dial-peer voice 99 pots





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 confi guration 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 confi guration, we are asked to confi gure a fractional T1 circuit consisting of 12 channels. We are only asked to confi gure the T1 connection to the PSTN and the outbound dial peer for off-network calling, as shown in Figure 6.6.

F I GU R E 6 .6 An ISDN T1 PRI example

PSTN

ISDN switch: Primary-NI

PSTN PRI settings:

Channels: 1-12

ESF

B8ZS

Clock from PSTN

3/0 T1

PRIV

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 195c06.indd 195 9/21/11 11:19:38 AM9/21/11 11:19:38 AM


confi guring a voice gateway, you must know which type of ISDN switch your PSTN is using. You confi gure 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 confi gure the voice gateway to use primary-ni:


Router(config)#isdn switch-type ?



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 confi guring our T1 circuit. When confi guring a PRI, we use the pri-group 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 confi gure 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 confi gure framing, linecoding, and the clock source:



Router(config-controller)#pri-group timeslots 1-12,24




Router(config-controller)#end

Router#

We can verify that our channels were properly confi gured by issuing the show voice port summary command, as shown here:

c06.indd 196c06.indd 196 9/21/11 11:19:38 AM9/21/11 11:19:38 AM


Router1#show voice port summary

IN OUT

PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC

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

0/1/0:23 01 xcc-voice up dorm none none y












PWR FAILOVER PORT 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 confi gure 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 confi gured for voice, the voice gateway directs calls to be processed by the DSP. If they are confi gured for data, the voice gateway bypasses the DSPs:


Router(config)#interface serial 0/0:23

Router(config-if)#isdn incoming-voice voice

Router(config-if)#end

Router#

Our last step is to confi gure 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:




c06.indd 197c06.indd 197 9/21/11 11:19:39 AM9/21/11 11:19:39 AM


Router(config-dial-peer)#port 0/1/0:23


Router#

Configuring DSP ResourcesYou’ve already learned how to confi gure 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 confi gure the offl oading 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 suffi cient DSP resources installed for the job, your next task is to confi gure your router as a DSP farm. As the name implies, the router will work to offl oad, or farm out, tasks such as transcoding and conferencing from the CUCM. Thus the CUCM must be confi gured to allow DSP farming to proceed. The only way to do this with Cisco call-processing agents and voice gateways is to use either the Cisco proprietary SCCP protocol or MGCP. SCCP allows for more advanced confi guration, and we will use this in our confi guration example. Figure 6.7 shows the communication process between the call-processing agent and the voice gateway acting as a DSP farm.

DSP farm

SCCPcommunication

Switch

Fa 4/0

V

CUCM v8.0

F I GU R E 6 .7 SCCP communication between CUCM and 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 traffi c away from the CUCM and instead to the DSP farm.

c06.indd 198c06.indd 198 9/21/11 11:19:39 AM9/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(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 profi les, which are used to allocate DSP resources and set their terms of usage. DSP profi les are broken into the three services that DSP farms can handle. A profi le can be made for transcoding, conferencing, and MTP. Also, each profi le is given a unique identifi er, so it is possible to confi gure more than one transcoding profi le, for example, if you require different profi le settings to be used.

Once you have chosen the profi le type and given it a unique profi le identifi er number, you will be placed into config-dsp-farm-profile mode. Here you can confi gure 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 profi le, and the DSP resources required will be allocated. For example, the following is transcoding profi le 10, which specifi es 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 profi le 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 199c06.indd 199 9/21/11 11:19:40 AM9/21/11 11:19:40 AM


The confi guration of transcoding and conferencing resources is identical except for the profi le commands that identify the two. When confi guring MTP resources, the maximum sessions command requires an additional keyword to be set. The hardware setting specifi es that DSP resources are used, while the software setting actually uses the router processor and performs MTP in software. If you confi gure maximum sessions hardware, keep in mind that MTP will only work for G.711 a-law and mu-law. If you have already confi gured 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 confi gure a DSP profi le 15 for MTP to terminate two calls using hardware and two calls using software, we would confi gure 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 confi gure our DSP farm router to communicate with our CUCM, as was shown in Figure 6.7.

To accomplish the SCCP confi guration 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 confi guring the CUCM IP addresses, you can use either the IP address or the domain name. You can confi gure the router to do a domain lookup to retrieve the IP address using this method. Additionally, you should confi gure the following settings:

identifier A unique identifi er to specify that this confi guration is used between the router interface and a specifi c 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.

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

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 confi gure SCCP for our example:

c06.indd 200c06.indd 200 9/21/11 11:19:40 AM9/21/11 11:19:40 AM

Configuring DSP Resources 201


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 identifi ed our CUCM to the DSP farm gateway. The next confi guration step on the voice gateway is to create a DSP farm profi le that associates the farm with a CUCM call-processing agent group. The fi rst 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 config-sccp-ccm mode, where you can confi gure settings that must match your CUCM confi guration on the call-processing agent. The bind interface command specifi es the interface on which the group will be active. Next, you need to confi gure two associate commands to specify the CUCM the group pertains to and set the priority of the call-processing unit. The fi rst command will be associate ccm identifier-number priority priority-number. The identifier-number must match the identifi er that we confi gured 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 specifi es which CUCM is preferred if multiple units are confi gured for redundancy. Up to four CUCM servers can be confi gured, where 1 is the most preferred and 4 is the least. The associate profile command sets the group to use the profi le we previously confi gured, which is 15. The fi nal group command is the register device-name command. The device-name is a unique name that must be identical on both the voice gateway confi guration and the CUCM confi guration. In our example, we use TXDSPFARM1 as our device-name. All of the SCCP group confi guration 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 confi gured and points to one or more CUCM call-processing agents. Now we must confi gure the CUCM to offl oad the media resources we want the DSP farm to handle. While the confi guration of a CUCM is outside the scope of this book, you can fi nd where to confi gure the offl oading of media services when using the CUCM version 8.0 GUI by fi rst logging into the Cisco Unifi ed CM Administration portion of the server. Next, navigate to the Media Resources tab and select one of the three resources to offl oad:

Conference Bridge

Transcoder

Media Termination Point

■

■

■

c06.indd 201c06.indd 201 9/21/11 11:19:41 AM9/21/11 11:19:41 AM


Figure 6.8 shows the Media Resources tab’s drop-down list choices.

F I GU R E 6 . 8 The CUCM Media Resources tab

From here, you can confi gure 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 confi guring the CUCM and Mitch was responsible for confi guring the DSP farm router. When the two fi nished their respective confi gurations, they discovered that the CUCM and DSP farm would not cooperate when attempting to offl oad conference-calling duties.

Network connectivity was working properly, so the two administrators rechecked their respective confi gurations. As it turns out, the CUCM confi guration used the following as the conference bridge name:

ConfDSP1

And the DSP farm IOS listed the following when they issued a show running-configuration command:

register CnfDSP1

The conference bridge names must match exactly on the CUCM and DSP farm confi gurations. The confi guration was small, only one character off, but it was the difference between a working conference bridge farm and a nonworking one.

c06.indd 202c06.indd 202 9/21/11 11:19:41 AM9/21/11 11:19:41 AM

Voice Port and Dial-Peer Verification Commands 203

Voice Port and Dial-Peer Verification CommandsIn this section, you will get to know some useful show, test, and debug commands to verify analog and digital voice port confi gurations 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 confi gurations 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 specifi c 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 203c06.indd 203 9/21/11 11:19:42 AM9/21/11 11:19:42 AM


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

IN OUT

PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC

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

0/0/0 — fxs-ls up dorm on-hook idle y




0/1/0 — fxo-gs up dorm idle on-hook 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 confi gured with loop-start signaling, and the -gs tells us that the FXO ports are

c06.indd 204c06.indd 204 9/21/11 11:19:42 AM9/21/11 11:19:42 AM


confi gured 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 confi guration 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 confi gured 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 confi guration (medium, high, fl ex, 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


TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK COUNT

——————————————FLEX VOICE CARD 0———————————————

*DSP VOICE CHANNELS*

CURR STATE: (busy)inuse (b-out)busy out (bpend)busyout pending

LEGEND : (bad)bad (shut)shutdown (dpend)download pending



c06.indd 205c06.indd 205 9/21/11 11:19:42 AM9/21/11 11:19:42 AM


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

*DSP SIGNALING CHANNELS*



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

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 specifi c voice ports acting erratically, you can use the test voice port commands to run specifi c tests to verify proper operation of your confi gured voice interfaces. The commands entered don’t actually run tests, but instead they confi gure voice ports or DS0 groups into various testing states. The fi ve possible testing states that can be confi gured are shown in Table 6.1.

c06.indd 206c06.indd 206 9/21/11 11:19:43 AM9/21/11 11:19:43 AM


TA B LE 6 .1 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 inject-tone 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(config)#voice port 0/1/0

Router(config-voiceport)#no echo-cancel enable

Router(config-voiceport)#impedance 600r



c06.indd 207c06.indd 207 9/21/11 11:19:43 AM9/21/11 11:19:43 AM



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(config)#voice port 0/1/0

Router(config-voiceport)#impedance 900r




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 208c06.indd 208 9/21/11 11:19:44 AM9/21/11 11:19:44 AM


1704 20 -8 -28

1904 20 -8 -28

2104 20 -8 -28

2304 20 -8 -28

2504 20 -8 -28

2704 20 -8 -28

2904 20 -8 -28

3104 19 -8 -27

3304 19 -8 -27

3404 19 -8 -27

Router#

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 209c06.indd 209 9/21/11 11:19:44 AM9/21/11 11:19:44 AM


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.

SummaryIn this chapter we covered how to confi gure 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 offl oad 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 confi guring the various signaling protocols in Chapter 7, “Confi guring Voice Gateway Signaling Protocols.” By the end of that chapter, you will have all the tools necessary to confi gure, 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 EssentialsKnow 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 confi gured strictly for outbound calling for emergency services.

c06.indd 210c06.indd 210 9/21/11 11:19:44 AM9/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 confi gured 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 confi gured 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 confi gured on voice gateways to offl oad 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 confi guration verifi cation and testing purposes.

Written Lab 6.11. What is the config-voiceport command used to confi gure the extension 555-1234 for

caller ID services?

2. While in config-voiceport mode, you want to confi gure 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 confi guring 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 confi guring a dial peer for a CAMA port and have destination-pattern 9911 confi gured. What command is required to forward only 911 to the PSAP?

5. You are confi guring a T1 CAS and want to confi gure 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 confi guring 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 confi guring a DSP profi le for MTP services and are in config-dspfarm-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?


c06.indd 211c06.indd 211 9/21/11 11:19:45 AM9/21/11 11:19:45 AM


Hands-On LabsTo 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.

F I GU R E 6 . 9 Voice gateway lab diagram

VPSTN

PSAP

CAMA

0/0/1

S0/1/0

Outbound

NANP calls

911 and

9911

E911

operators

Internal voicenetwork

Here is a list of the labs in this chapter:

Lab 6.1: Confi guring a T1 PRI

Lab 6.2: Confi guring a CAMA Port for E911 Services

Lab 6.3: Confi guring Outbound Dial Peer to the PSTN

Lab 6.4: Confi guring Outbound Dial Peer to the PSAP

Hands-On Lab 6.1: Configuring a T1 PRI

In this lab, we’re going to confi gure a voice gateway that has a single ISDN PRI interface out to the PSTN. The voice gateway has been partially confi gured. The task here is to confi gure the T1 logical and physical port sections according to the PSTN requirements found in Table 6.2.

TA B LE 6 . 2 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 confi guration mode by typing enable and then configure terminal.

2. Confi gure the ISDN switch type by typing isdn switch-type primary-ni.

c06.indd 212c06.indd 212 9/21/11 11:19:45 AM9/21/11 11:19:45 AM

Hands-On Labs 213

3. Enter into config-controller mode by typing controller t1 0/1/0.

4. Confi gure a new PRI group specifying all T1 timeslots by typing pri-group timeslots 1–24.

5. Confi gure the T1 PRI to for ESF framing by typing framing esf.

6. Confi gure the T1 PRI to for B8ZS linecoding by typing linecode b8zs.

7. Confi gure 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. Confi gure 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 confi guring 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 LE 6 . 3 Area codes and numbering plan digits

Area Code Numbering Plan Digit

312 0

773 1

630 2

850 3


2. Enter into config-voiceport mode by typing port 0/0/1.

3. Confi gure 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. Confi gure NPD to area code mappings by typing

ani mapping 0 312

ani mapping 1 773

ani mapping 2 630

ani mapping 3 850

6. Exit config-voiceport mode by typing end.

c06.indd 213c06.indd 213 9/21/11 11:19:46 AM9/21/11 11:19:46 AM


Hands-On Lab 6.3: Configuring an Outbound

Dial Peer to the PSTN

An outbound dial peer needs to be confi gured 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.


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. Confi gure a dial-string mapping to match 9 plus a 10-digit number according to NANP guidelines by typing destination-pattern 9[2–8]. . . . . . . . .

4. Confi gure the dial peer to forward the last 10 digits to the PSTN by typing forward-digits 10.

5. Confi gure 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 confi gure outbound dial peers for E911 calling to the PSAP. Because we have internal callers dial 9 for an outbound call, we will confi gure 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 confi guration mode by typing enable and then

configure terminal.


3. Confi gure a dial-string mapping to match 911 by typing destination-pattern 911.

4. Confi gure the dial peer to forward all three digits to the PSAP by typing forward-digits all.

5. Confi gure the dial peer to send matched calls out our CAMA port by typing port 0/0/1.


7. Confi gure a dial-string mapping to match 9911 by typing destination-pattern 9911.

8. Confi gure 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. Confi gure the dial peer to send matched calls out our CAMA port by typing port 0/0/1.


c06.indd 214c06.indd 214 9/21/11 11:19:46 AM9/21/11 11:19:46 AM


Review Questions1. How can DNIS be used on FXO ports?

A. Inbound only.

B. DNIS cannot be used in either direction on FXO ports.

C. Outbound only.

D. Both inbound and outbound.

2. What is the name for an autodialing feature that is used to associate a port with a single destination?

A. PSAP

B. PLAR

C. CAMA

D. OPX

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

B. connection opx plar 455

C. opx plar 455

D. connection plar opx 455

4. 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-voiceport)#signal did wink-start



Router(config-dial-peer)#incoming called-number . . . .


A. prefix 4

B. forward digits 4

C. direct-inward-dial

D. did

c06.indd 215c06.indd 215 9/21/11 11:19:47 AM9/21/11 11:19:47 AM


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

B. One-stage dialing

C. Private Line Automatic Ringdown (PLAR)

D. Two-stage dialing

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

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

7. How are E911 calls routed to the PSAP?

A. By DNIS

B. By destination address

C. By ANI

D. By area code

8. In situations where CAMA is required, where should internal calls to 911 be routed?

A. A CUCM

B. The PSAP

C. The PSTN

D. The SRST

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

B. Timeslot 23 and channel 24.

C. Timeslot 24 and channel 24.

D. Channel 23 and timeslot 23.

E. PRI uses in-band signaling.

c06.indd 216c06.indd 216 9/21/11 11:19:47 AM9/21/11 11:19:47 AM


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

B. When identifying the sccp ccm

C. When in config-sccp-ccm mode

D. When configuring the CUCM

c06.indd 217c06.indd 217 9/21/11 11:19:48 AM9/21/11 11:19:48 AM


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 218c06.indd 218 9/21/11 11:19:48 AM9/21/11 11:19:48 AM


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.

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.

c06.indd 219c06.indd 219 9/21/11 11:19:49 AM9/21/11 11:19:49 AM



1. C. FXO ports can only send DNIS information outbound toward the PSTN.

2. B. PLAR is a feature that can be confi gured on a voice port to automatically dial a specifi c 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 confi guring 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 confi gured to utilize different analog FXS, FXO, and E&M signaling types.

10. A. When referring to T1 signaling channels and timeslots, you confi gure 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 confi guring 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 confi guring 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 confi gured to be used as a DSP farm to offl oad 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 220c06.indd 220 9/21/11 11:19:49 AM9/21/11 11:19:49 AM


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 confi guring MTP DSP farm profi les.

17. A. The register TXDSPFARM1 command specifi es the CUCM media resource’s device name, which must be identical on the CUCM and voice gateway confi gurations.

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 specifi es how the DSP resource is confi gured. 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 specifi ed.

c06.indd 221c06.indd 221 9/21/11 11:19:50 AM9/21/11 11:19:50 AM


Answers to Written Lab 6.11. 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 222c06.indd 222 9/21/11 11:19:50 AM9/21/11 11:19:50 AM

Configuring Voice Gateway Signaling Protocols


� Describe the components of a gateway.


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

Chapter

7

c07.indd 223c07.indd 223 21/09/11 11:23 AM21/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 confi gure 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 confi gured on Cisco IOS gateways that attach to the PSTN. We’ll fi rst explore some more details about each signaling protocol, including how to confi gure them and make common adjustments and how to use IOS show commands to verify proper confi guration and for troubleshooting.

Configuring H.323By default, Cisco voice gateway dial peers are confi gured 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 confi gured 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

PSTN

Internal IP

network

H.323 Q.921

Q.931

Voice

gateway

V

CUCM

M

c07.indd 224c07.indd 224 21/09/11 11:23 AM21/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

IP

network

H.323 signaling

1. Call setup

2. Call proceeding

3. Alerting

4. Connect

5. H.245 negotiations

V VCalling

party

Called

party

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, fl ow control, and jitter management

� Opening and closing media stream channels, which transport voice and video

� Determining the master or responder endpoints

� Handling modifi cation 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 225c07.indd 225 21/09/11 11:23 AM21/09/11 11:23 AM

226 Chapter 7 ■ 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

IP

network

H.323 signaling

1. Call setup and H.245 negotiations

2. Call proceeding

3. Alerting

4. Connect

V VCalling

party

Called

party

As you can imagine, the H.323 fast start method is more effi cient 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

IP

network

H.323 signaling

1. Call setup and H.245 negotiations

2. Call proceeding

4. Alerting

5. Connect

V VCalling

party

Called

party

3. RTP stream for early media

c07.indd 226c07.indd 226 21/09/11 11:23 AM21/09/11 11:23 AM


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 identifi er 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. Confi gure a destination pattern to identify how to reach remote phones on the other side of an IP connection.

3. Confi gure 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 confi gure your VoIP gateway but fi nd 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 confi guration 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 confi guring 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 227c07.indd 227 21/09/11 11:23 AM21/09/11 11:23 AM


We want to route all calls between the two sites across the IP WAN using H.323 signaling. We will start by confi guring the New York router using 4000 as our locally signifi cant dial-peer identifi er, 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 confi gure 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 confi guration setup shows you how to confi gure 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

F I G U R E 7.5 An example H.323 network

IPWAN

New YorkH.323 gateway

BostonH.323 gateway

V V

Extensions

3000-3999

Extensions

4000-4999

192.168.2.1/24192.168.1.1/24

c07.indd 228c07.indd 228 21/09/11 11:23 AM21/09/11 11:23 AM


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(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 confi gure H.323 slow start on a specifi c dial peer instead of globally on the voice gateway. To accomplish this, you must fi rst create an H.323 voice class that specifi es slow start signaling. The voice class can then be applied to any dial peer that you choose. The following example shows how to confi gure an H.323 voice class (labeled 1) for slow start connections. The voice class is then applied to dial peer 10:


Router(config)#voice class h323 1

Router(config-class)#call start slow

Router(config-class)#exit


Router(config-dial-peer)#voice-class h323 1


Router#

Configuring Codec Preference

You can use signaling protocols to specify the preferred codec and other codec-specifi c parameters to be used in the H.323 confi guration 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 229c07.indd 229 21/09/11 11:23 AM21/09/11 11:23 AM


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 specifi ed in bytes

fixed-bytes Whether the bytes specifi ed 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 confi gure preferences (voice class 30) for the following three codecs and specifi c 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 confi gure the codec preferences on a voice gateway:


Router(config)#voice class codec 30

Router(config-class)#codec preference 1 g711ulaw bytes 160

Router(config-class)#codec preference 2 g726r32 bytes 80 fixed-bytes

Router(config-class)#codec preference 3 g729br8

Router(config-class)#end

Router#

Once the codec preferences are specifi ed, they can be applied to VoIP dial peers as shown in this example, where we apply voice class 30 to dial peer 15:



Router(config-dial-peer)#voice-class codec 30


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 confi gured 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 230c07.indd 230 21/09/11 11:23 AM21/09/11 11:23 AM


are specifi ed 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 specifi ed 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 modifi ed 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 confi gure your voice gateway for UDP, as shown in the following example:



Router(conf-voi-serv)#h323

Router(conf-serv-h323)#session transport udp


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(conf-serv-h323)#session transport tcp calls-per-connecton 20


Router#

c07.indd 231c07.indd 231 21/09/11 11:23 AM21/09/11 11:23 AM


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 modifi ed 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 indefi nitely. 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(conf-serv-h323)#h225 timeout tcp call-idle value 5


Router#

Adjusting H.225 Timers

There are two H.225 timers that can be adjusted in confi guring 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 benefi cial. 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 identifi er:



Router(config-class)#

The two H.225 timeout settings you must be familiar with are these:

h225 timeout tcp establish This command specifi es 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:



Router(config-class)#h225 timeout tcp establish 3


Router#

c07.indd 232c07.indd 232 21/09/11 11:23 AM21/09/11 11:23 AM


h225 timeout setup 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:



Router(config-class)#h225 timeout setup 3


Router#

Any H.225 timer adjustments confi gured must then be applied to corresponding H.323 dial peers using the voice class h323 command followed by the unique identifi er we used. For example, we will apply our H.323 voice class 100 settings to VoIP dial peer 999, as shown here:


Router(config)#dial-peer voie 999 voip

Router(config-dial-peer)#voice-class h323 100


Router#

Binding a Virtual H.323 Gateway Address for Redundancy

The fi nal H.323 confi guration we will look at is interface binding; we will confi gure 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 confi gured 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

IPWAN

LocalH.323 gateway

SwitchRemote

H.323 gateway

VV

Multiple physical

interfaces

Interface loopback 0:

10.10.10.100/24

c07.indd 233c07.indd 233 21/09/11 11:23 AM21/09/11 11:23 AM


By confi guring 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 confi gure loopback 0 with our IP and as our virtually bound H.323 gateway source interface:


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#

H.323 show Commands

Now that you know how to confi gure H.323 signaling between two gateways, you need to familiarize yourself with two IOS show commands used to verify proper confi guration 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 confi gured 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. Confi guration of H.323 gatekeepers is discussed in Chapter 10, “Confi guring 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 234c07.indd 234 21/09/11 11:23 AM21/09/11 11:23 AM


Router#show h323 gateway h225

H.225 STATISTICS AT 00:46:12

H.225 REQUESTS SENT RECEIVED FAILED

Setup 12 53 0

Setup confirm 48 0 0

Alert 30 0 0

Progress 29 0 0

Call proceeding 53 0 0

Notify 0 0 0

Info 0 0 0

User Info 0 0 0

Facility 32 0 0

Release 44 43 1

Reject 0 0 0

Passthrough 0 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 SENT RECEIVED FAILED

Setup 0 0 0

Setup confirm 0 0 0

Alert 0 0 0

Progress 0 0 0

c07.indd 235c07.indd 235 21/09/11 11:23 AM21/09/11 11:23 AM


Call proceeding 0 0 0

Notify 0 0 0

Info 0 0 0

User Info 0 0 0

Facility 0 0 0

Release 0 0 0

Reject 0 0 0

Passthrough 0 0 0

H225 establish timeout 0

RAS failed 0

H245 failed 0

Router#

Configuring SIPSession Initiation Protocol (SIP) is a widely popular protocol thanks in part to its open-standard nature, ease of confi guration, and wide support from almost all voice hardware manufacturers. In this section, we will explore the inner workings of SIP signaling and how to confi gure 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

PSTN

Internal IP

network

SIP Q.921

Q.931

Voice

gateway

V

CUCM

M

Specifi cally, the SIP voice gateway signaling protocol is responsible for the following tasks:

� Determine the location of target endpoints.

� Determine the capabilities of target endpoints.

c07.indd 236c07.indd 236 21/09/11 11:23 AM21/09/11 11:23 AM

Configuring SIP 237

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

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

IP

network

SIP signaling

1. SIP invite (SDP offer message)

2. SIP OK (SDP media answer)

V VCalling party Called party

Here are the

multimedia

characteristics

I can work with.Here are the

multimedia

characteristics

that match

what you can

work with.

c07.indd 237c07.indd 237 21/09/11 11:23 AM21/09/11 11:23 AM


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

IP

network

SIP signaling

1. SIP invite

2. SIP OK (SDP media offer)

V VCalling party Called party

Here are the

multimedia

characteristics

I can work with.

3. SIP ACK (SDP media answer)

Here are the

multimedia

characteristics

that match

what you can

work with.

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 238c07.indd 238 21/09/11 11:23 AM21/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 LE 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 offl ine 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 confi gure 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 confi guration 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 239c07.indd 239 21/09/11 11:23 AM21/09/11 11:23 AM


In order to properly connect our SIP gateway, we will need to confi gure 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 confi guration. 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 confi guration 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 confi gure our UA settings as shown here:


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#

F I G U R E 7.10 A SIP network configured between IP gateways

PSTNInternet

Extensions

4000–4999

192.168.99.99

SCCP

signaling

10.1.1.100

Voice

gateway

SIP signaling

ITSP voice

gateway

VV

M

IP

c07.indd 240c07.indd 240 21/09/11 11:23 AM21/09/11 11:23 AM

Configuring SIP 241

Once we complete those changes, basic SIP is confi gured on our network. Next, we will need to confi gure 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 fi rst confi gure 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 confi gure session target ipv4:192.168.99.99, but since we’ve already identifi ed 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 specifi ed, then we would be required to enter the IP address of the CUCM.



Router(config-dial-peer)#session protocol sipv2

Router(config-dial-peer)#destination pattern 4...

Router(config-dial-peer)#session target sip-server


Router#

Next, we will confi gure 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 confi guration for this dial peer:




Router(config-dial-peer)#destination pattern 9T

Router(config-dial-peer)#session target 10.1.1.100


Router#

That’s really all there is to confi gure 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 modifi cations that you may need to set are discussed in the next two sections.

Configure Secure SIP Communications

SIP calls can be confi gured 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 241c07.indd 241 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi gured end to end. To confi gure SIPS globally, you must enter into config-serv-sip mode and enter the url sips command. This command specifi es 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 confi gure SIPS globally:


Router(config)#voice service voip

Router(config-voi-serv)#sip

Router(config-serv-sip)#url sips

Router(config-serv-sip)#end

Router#

Confi guring SIPS on an individual dial-peer basis requires that you enter into config-dial-peer mode for a specifi c dial peer and enter the voice-class sip url sips command, as shown here with dial peer 100:



Router(config-dial-peer)#voice-class sip url sips


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 confi gure 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 specifi es 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 confi guration commands look like this:



c07.indd 242c07.indd 242 21/09/11 11:23 AM21/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 confi gure 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(config-dial-peer)#srtp

Router(config-dial-peer)#srtp fallback


Router#

Modify SIP Voice Gateway Settings

There are several modifi cations that CVOICE candidates should be familiar with. Commonly changed default settings include these:

� Confi guring 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

� Confi guring SIP for ISDN interoperation

Let’s take a closer look at how to confi gure 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(config-sip-ua)#transport tcp


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 243c07.indd 243 21/09/11 11:23 AM21/09/11 11:23 AM


outbound message protocol behavior to TCP within individual dial peers, as shown in this example using VoIP dial peer 88:



Router(config-dial-peer)#session transport tcp


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 modifi ed, 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 less-reliable 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 244c07.indd 244 21/09/11 11:23 AM21/09/11 11:23 AM

Configuring SIP 245

TA B LE 7. 2 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(config-sip-ua)#timers trying 1000

Router(config-sip-ua)#timers connect 1000

Router(config-sip-ua)#timers expires 1000


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 245c07.indd 245 21/09/11 11:23 AM21/09/11 11:23 AM


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 LE 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(config-sip-ua)#retry invite 8

Router(config-sip-ua)#retry response 8


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 specifi es the maximum number of proxy or redirect servers that can forward requests. The default maximum is 70. To make

c07.indd 246c07.indd 246 21/09/11 11:23 AM21/09/11 11:23 AM

Configuring SIP 247

these SIP modifi cations you must be in config-sip-ua mode. Here is an example of how to change the max proxy/redirect servers to 10:



Router(config-sip-ua)#max-forwards 10


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 diffi culties when attempting to route through a fi rewall that requires you to know the source IP addresses. To help eliminate confi guration problems, the SIP source-bind feature can be used to statically assign an IP address to a specifi c 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 confi gured with either an IPv4 or IPv6 address for proper operation. Here is an example to confi gure source interface FastEthernet 0/1 to be bound for both SIP signaling and media:



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 SIP and ISDN interoperation

WANV

Ext: 5555 Detroit

voice gateway

SIP signaling

Chicago

voice gateway

S1/0

Call coming into the Chicago

voice gateway that is destined for

Ext: 5555

PSTN

c07.indd 247c07.indd 247 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi gure 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 specifi es that you wish to forward the calling name information sent out of the ISDN circuit. Here is an example of how to confi gure this on ISDN PRI serial 1/0:


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 confi gure this command in conf-voi-serv mode, as shown here:


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 248c07.indd 248 21/09/11 11:23 AM21/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 confi gured on each dial peer. Here is an example of how to confi gure CLID blocking on VoIP dial peer 101:


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 249c07.indd 249 21/09/11 11:23 AM21/09/11 11:23 AM


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

Router#

c07.indd 250c07.indd 250 21/09/11 11:23 AM21/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 confi guration settings so you can easily see if there have been any modifi cations. 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 251c07.indd 251 21/09/11 11:23 AM21/09/11 11:23 AM


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 verifi ed 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 response retry count = 6

bye retry count = 10 cancel retry count = 10

prack retry count = 10 update retry count = 6

reliable 1xx count = 6 notify retry count = 10

refer retry count = 10 register retry count = 6

info retry count = 6 subscribe retry count = 6

options retry count = 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 252c07.indd 252 21/09/11 11:23 AM21/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 MGCPCompared to H.323 and SIP, confi guring 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 253c07.indd 253 21/09/11 11:23 AM21/09/11 11:23 AM


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 notifi cation event messages. And because the call agent handles all call-routing decisions, no dial peers are confi gured 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 confi guration 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.

F I G U R E 7.12 MGCP and ISDN signaling

PSTNInternal IPnetwork

MGCP Q.921

Q.931

Voicegateway

V

CUCM

M

Q.931 information between the call agent and voice gateway. MGCP communication boundaries are shown in Figure 7.12.

c07.indd 254c07.indd 254 21/09/11 11:23 AM21/09/11 11:23 AM


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.13 An MGCP residential gateway

Voice

gateway

Switch

Analog portsV

CUCM

MGCP sig

naling

M

F I G U R E 7.14 An MGCP trunking gateway

PSTN

Voice

gateway

Trunk

Switch

V

CUCM

M

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 255c07.indd 255 21/09/11 11:23 AM21/09/11 11:23 AM


agent. Each of these messages is sent with a four-letter acronym to defi ne 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 LE 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 confi guration packages to provide simplicity when setting up your MGCP gateway. Each package serves a specifi c 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 specifi c events and signaling such

c07.indd 256c07.indd 256 21/09/11 11:23 AM21/09/11 11:23 AM


as a secure RTP (srtp-package) package and a fax transmission (fxr-package) package. Package types are confi gured on voice gateways using the mgcp package-capability command while in global confi guration 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 confi guration step that must be performed is simply to enable MGCP on your voice gateway. To do that, just type in mgcp while in global confi guration 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 confi guration 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 confi guration to add additional call agents. The voice gateway will send requests out to all confi gured call agents and will use the fi rst one that responds to a MGCP message request.

c07.indd 257c07.indd 257 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi gurations. 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, confi gure 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 fl ash, 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 modifi cation messages, and RTP/RTCP timeouts.

The following commands show how to confi gure an MGCP residential gateway:


Router(config)#mgcp

Router(config)#ccm-manager mgcp

Router(config)#mgcp call-agent 192.168.10.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.15 An MGCP residential gateway network

Voicegateway

Switch

VFXS 0/0/1

SecondaryCUCM

192.168.20.100

M

PrimaryCUCM

192.168.10.100

M

c07.indd 258c07.indd 258 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi guration mode.

The remainder of an MGCP residential gateway confi guration is performed within individual POTS dial peers. In our example, we will confi gure 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(config-dial-peer)#application mgcpapp


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 confi guration of residential gateways are identical for trunking gateways, although the specifi c MGCP packages you select will be different. Also note that the trunk-package MGCP confi guration group will be enabled by default when confi guring a trunking gateway. In our example we will use trunk-package, dtmf-package, gm-package, and rtp-package.

The remainder of the MGCP trunking confi guration is very different from the MGCP residential confi guration, however. When confi guring trunking gateways, you must specify the controller of the T1/E1 you wish to enable MGCP on. Then you must use the PRI ds0-group 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, confi gure a CUCM call agent, and enable our required MGCP group packages. Also note in the confi guration example how the MGCP line package that was used in our residential

c07.indd 259c07.indd 259 21/09/11 11:23 AM21/09/11 11:23 AM


gateway is replaced with the trunk package for our trunking gateway. The trunk package includes trunk-specifi c events and tones.

F I G U R E 7.16 An MGCP trunking gateway network

PSTNM

Voice

gateway

V

CUCM

10.165.1.100

Switch

T1 2/0


Router(config)#mgcp

Router(config)#ccm-manager 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 confi gure T1 PRI port 2/0 to enable MGCP on all 24 timeslots of DS0 group 0, which is already confi gured:



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 confi gure both residential and trunking MGCP gateways, let’s look at some of the IOS show commands used to verify our confi guration 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 confi guration settings and when comparing timeout values, as shown this example output:

c07.indd 260c07.indd 260 21/09/11 11:23 AM21/09/11 11:23 AM


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 261c07.indd 261 21/09/11 11:23 AM21/09/11 11:23 AM


MGCP quarantine of persistent events is ENABLED

MGCP dtmf-relay for VoIP is SDP controlled

MGCP dtmf-relay for voAAL2 is SDP controlled

MGCP voip modem passthrough disabled

MGCP voaal2 modem passthrough disabled

MGCP voip modem relay: Disabled

MGCP T.38 Named Signalling Event (NSE) response timer: 200

MGCP Network (IP/AAL2) Continuity Test timer: 200

MGCP ‘RTP stream loss’ timer: 5

MGCP request timeout 500

MGCP maximum exponential request timeout 4000

MGCP gateway port: 2427, MGCP maximum waiting delay 3000

MGCP restart delay 0, MGCP vad DISABLED

MGCP rtrcac DISABLED

MGCP system resource check DISABLED

MGCP xpc-codec: DISABLED, MGCP persistent hookflash: DISABLED

MGCP persistent offhook: ENABLED, MGCP persistent onhook: DISABLED

MGCP piggyback msg ENABLED, MGCP endpoint offset DISABLED

MGCP simple-sdp DISABLED

MGCP undotted-notation DISABLED

MGCP codec type g711ulaw, MGCP packetization period 20

MGCP JB threshold lwm 30, MGCP JB threshold hwm 150

MGCP LAT threshold lwm 150, MGCP LAT threshold hwm 300

MGCP PL threshold lwm 1000, MGCP PL threshold hwm 10000

MGCP CL threshold lwm 1000, MGCP CL threshold hwm 10000

MGCP playout mode is adaptive 60, 40, 1000 in msec

MGCP Fax Playout Buffer is 300 in msec

MGCP media (RTP) dscp: ef, MGCP signaling dscp: af31

MGCP default package: trunk-package

MGCP supported packages: gm-package dtmf-package trunk-package line-package

hs-package ms-package dt-package mo-package

mt-package

fxr-package md-package

MGCP Digit Map matching order: shortest match

SGCP Digit Map matching order: always left-to-right

MGCP VoAAL2 ignore-lco-codec DISABLED

MGCP T.38 Max Fax Rate is DEFAULT

MGCP T.38 Fax is ENABLED

MGCP T.38 Fax ECM is ENABLED

MGCP T.38 Fax NSF Override is DISABLED

c07.indd 262c07.indd 262 21/09/11 11:23 AM21/09/11 11:23 AM


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.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 263c07.indd 263 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi guration 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 confi gured:

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

Backhaul/Redundant link port: 2428

Failover Interval: 30 seconds

c07.indd 264c07.indd 264 21/09/11 11:23 AM21/09/11 11:23 AM

Summary 265

Keepalive Interval: 15 seconds

Last keepalive sent: 09:33:22 CST Jan 22 2011

(elapsed time: 02:17:46)

Last MGCP traffic time: 10:51:08 CST Jan 22 2011

(elapsed time: 00:00:00)

Last failover time: None

Last switchback time: None

Switchback mode: Graceful

MGCP Fallback mode: Not Selected

Last MGCP Fallback start time: None

Last MGCP Fallback end time: None

MGCP Download Tones: Disabled

TFTP retry count to shut Ports: 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#

SummaryIn 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 confi gure and tweak their settings. Additionally, it is important to know several show commands used to verify proper confi guration of your voice gateway and to use them in cases where troubleshooting is needed. We will continue to explore voice gateway confi gurations in various situations that utilize these signaling protocols in Chapter 9 of this study guide.

c07.indd 265c07.indd 265 21/09/11 11:23 AM21/09/11 11:23 AM


Exam EssentialsUnderstand 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. Confi guring signaling between two voice gateways is just a matter of confi guring 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 confi guring 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, confi gure 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 verifi cation 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. Confi guring SIP between voice gateways on a network is a matter of enabling SIP version 2 on the router, confi guring 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 confi gure 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 266c07.indd 266 21/09/11 11:23 AM21/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. Confi guring 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 confi gured, 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 verifi cation and troubleshooting MGCP including show mgcp profile, show mgcp, show mgcp statistics, and show ccm-manager.

Written Lab 7.11. What is the default H.323 initiation method?

2. You wish to confi gure a voice gateway but fi nd that the VoIP service has been manually shut down. While in global confi guration mode, you enter voice service voip, which brings you to the conf-voi-serv confi guration 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 confi guring 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?

c07.indd 267c07.indd 267 21/09/11 11:23 AM21/09/11 11:23 AM


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 confi guration package must you enable?

10. What protocol and port does MGCP operate on by default?


Hands-On LabsTo 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.

PSTN

Extensions: 3XX

10.154.79.101

Fa1/0

172.16.3.10

Local SIP

gateway

ITSP

gateway

VV

M

IP

Internal

networkFa2/0

F I G U R E 7.17 Voice gateway lab diagram

c07.indd 268c07.indd 268 21/09/11 11:23 AM21/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 confi gured. We are only concerned with confi guring the local SIP gateway.


Lab 7.1: Confi guring 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 confi gure 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 LE 7.5 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 confi guration 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. Confi gure SIP source binding by typing bind all source-interface fa2/0.

5. Return to global confi guration mode by typing exit and exit.

6. Enter into config-sip-ua mode by typing sip-ua.

7. Confi gure the SIP registrar server by typing registrar 10.154.79.101.

8. Confi gure SIP authentication to the local SIP registrar server by typing authentication username cucmsipregistrar password 0 password 101.

9. Return to global confi guration mode by typing exit.

c07.indd 269c07.indd 269 21/09/11 11:23 AM21/09/11 11:23 AM


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


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. Confi gure a destination pattern to match all external phones by typing destination-pattern 9T.

18. Point the dial peer to our internal SIP proxy (the CUCM) by typing session target 10.154.79.101.


Hands-On Lab 7.2: Modifying SIP Timers and Retries

In Lab 7.1 we confi gured 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 LE 7.6 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

c07.indd 270c07.indd 270 21/09/11 11:23 AM21/09/11 11:23 AM

Hands-On Labs 271


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 271c07.indd 271 21/09/11 11:23 AM21/09/11 11:23 AM


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

B. During the call proceeding stage

C. After the connect stage

D. After the alerting stage

2. Which signaling protocol does not need dial peers configured on the voice gateway in order to operate?

A. SIP

B. SIP v2

C. H.323

D. MGCP

3. What two functions are the responsibility of H.245 when using H.323 signaling?

A. Exchange capabilities information between endpoints.

B. Transport SDP information between endpoints.

C. Transport voice or video streams within an H.245 channel.

D. Open and close media channels.

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

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

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

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

c07.indd 272c07.indd 272 21/09/11 11:23 AM21/09/11 11:23 AM


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


B. Router(config)#dial-peer voice 101 pots

Router(config-dial-peer)#voice-class preference 10

C. Router(config)#dial-peer voice 101 voip


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)#h323-gateway voip bind srcaddr loopback 0

B. Router(config)#interface loopback0


Router(config-if)#h323-gateway voip bind srcaddr 172.16.3.1

C. Router(config)#interface loopback0


Router(config-if)#gateway voip bind srcaddr 172.16.3.1

D. Router(config)#interface loopback0


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

B. show h323 gateway h225

C. show h323 gateway

D. show h323 gateway statistics

c07.indd 273c07.indd 273 21/09/11 11:23 AM21/09/11 11:23 AM


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

B. Router(config-dial-peer)#gateway protocol sipv2

C. Router(config-dial-peer)#session protocol sip

D. Router(config-dial-peer)#gateway protocol sip

c07.indd 274c07.indd 274 21/09/11 11:23 AM21/09/11 11:23 AM


14. Which of the following commands configures SIP secure globally on a voice gateway?

A. Router(config)#voice service voip


Router(config-serv-sip)#udp sips

B. Router(config)#voice service voip


Router(config-serv-sip)#sip secure

C. Router(config)#voice service voip


Router(config-serv-sip)#url sips

D. Router(config)#voice service voip


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.

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.

c07.indd 275c07.indd 275 21/09/11 11:23 AM21/09/11 11:23 AM


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

B. show ccm-manager

C. show mgcp profile

D. show mgcp

c07.indd 276c07.indd 276 21/09/11 11:23 AM21/09/11 11:23 AM


Answers to Review Questions1. 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, fl ow 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 confi gure 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 confi gure 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 confi gured 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 modifi ed. The correct config-dial-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 277c07.indd 277 21/09/11 11:23 AM21/09/11 11:23 AM


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 278c07.indd 278 21/09/11 11:23 AM21/09/11 11:23 AM


Answers to Written Lab 7.11. 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 279c07.indd 279 21/09/11 11:23 AM21/09/11 11:23 AM

c07.indd 280c07.indd 280 21/09/11 11:23 AM21/09/11 11:23 AM

Configuring and Managing CUCM Express


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.

�

Chapter

8

c08.indd 281c08.indd 281 9/21/11 11:24:35 AM9/21/11 11:24:35 AM

The new CVOICE 8.0 exam requires that test candidates understand how to confi gure a basic voice network using a Cisco Unifi ed 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 confi gure 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 confi gure and verify voice settings and operational status for both the SCCP and SIP protocols.

Voice Network Infrastructure ConsiderationsThere 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 confi gurations, 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 briefl y 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 282c08.indd 282 9/21/11 11:24:37 AM9/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 effi cient 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 specifi c 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 specifi c switchport.

c08.indd 283c08.indd 283 9/21/11 11:24:38 AM9/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 fi ve 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 classifi cations.

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

TA B LE 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

c08.indd 284c08.indd 284 9/21/11 11:24:38 AM9/21/11 11:24:38 AM


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 classifi cation 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 confi gurable modes on its PoE-capable switches. This is known as Intelligent Power Management (IPM). This section shows how to confi gure 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 285c08.indd 285 9/21/11 11:24:39 AM9/21/11 11:24:39 AM


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 specifi c port. Finally, the static option can be useful if you have non-Cisco phones that you know use only a specifi c 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 benefi ts they provide for devices on a network. Those benefi ts include limiting broadcast messages, improved security, and logical segmentation based on business processes. These benefi ts can be extended into the VoIP realm as well. Because CVOICE candidates must know how to install and confi gure 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 286c08.indd 286 9/21/11 11:24:39 AM9/21/11 11:24:39 AM


A trunk port is a link between two Layer 2 switches that can transport traffi c from multiple VLANs. It keeps the traffi c between the VLANs separate by tagging each frame. VLAN tagging essentially places a VLAN identifi er 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 confi gure 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 confi gured to switches VLAN 10 and 20. Confi guring an 802.1Q trunk between the switches requires the following steps.

VLAN 10

Switch BFa0/1

Fa0/1

Trunk VLAN

10 and 20

VLAN 20

Switch A

F I GU R E 8 .1 A VLAN trunk

c08.indd 287c08.indd 287 9/21/11 11:24:40 AM9/21/11 11:24:40 AM


Step 1: Configure the Trunk Encapsulation Type

The fi rst step is to set the encapsulation type for the trunk interface. The command for confi guring 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 confi gure the port as a trunk, we can simply hard-code the port using the switchport mode trunk command. Let’s confi gure Switch-A and Switch-B for trunking on port Fa0/1.

Here is the confi guration 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 confi guration 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 access-layer switch, the second virtual port (port 1) is for voice traffi c 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 288c08.indd 288 9/21/11 11:24:40 AM9/21/11 11:24:40 AM


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 confi guring 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 specifi cally as a voice VLAN. In all actuality, this trunk link between our switch and the Cisco phone is not a full-fl edged 802.1Q trunk like those we have practiced confi guring 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 confi gured 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 confi gured a new VLAN (VLAN 100) for voice. We attach an IP phone to port fa0/5. We then need to confi gure 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 confi gure 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

F I GU R E 8 . 2 A Cisco IP phone switch

SwitchFa0/5 Trunk link

Cisco phone

PC

Voice VLAN

Data VLAN

c08.indd 289c08.indd 289 9/21/11 11:24:41 AM9/21/11 11:24:41 AM


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 Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Gi0/1, Gi0/2

10 Sales active 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

20 Marketing active 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

30 Management active

100 Voice active Fa0/5

1002 fddi-default act/unsup

1003 trcrf-default act/unsup

1004 fddinet-default act/unsup

1005 trbrf-default act/unsup

Switch#

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 confi gured 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 confi gure 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 confi gure DHCP on your CME router for your end devices.

c08.indd 290c08.indd 290 9/21/11 11:24:42 AM9/21/11 11:24:42 AM


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 confi guration process is to ensure that specifi c 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 specifi cally 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 specifi c addresses:


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

Specifi es 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 confi gure when setting up DHCP for your Cisco IP phones is the IP address of the TFTP server where the Cisco phone confi guration fi les are located. All Cisco phones (SIP and SCCP) must download a confi guration fi le when they fi rst boot. This fi le 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 confi guration fi le. The DHCP option command is followed by a specifi c 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 291c08.indd 291 9/21/11 11:24:42 AM9/21/11 11:24:42 AM


Here is an example of DHCP confi guration 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 confi guration steps are complete, when an IP phone confi gured 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 inter-face 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 specifi c lease will expire. The following example shows the binding for the DHCP leased IP address 192.168.100.101:

c08.indd 292c08.indd 292 9/21/11 11:24:42 AM9/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 Lease expiration Type

192.168.100.101 00a0.9802.32de Mar 01 2009 12:00 AM 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 confl ict detection. The next example shows a confl ict for the IP 192.168.100.101:

Router# show ip dhcp conflict

IP address Detection Method Detection time

192.168.100.101 Ping Mar 01 2009 12:28 PM

Configuring the Network Time Protocol

NTP should be confi gured 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 confi guration of a time source on a Cisco IOS device is quite simple. This confi guration 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 confi gured to peer with the device receiving an external clock. For example, here’s the confi guration of a router for an external NTP server that uses the external time source IP of 192.5.41.41:


Router(config)#clock timezone CHICAGO -6

Router(config)#ntp server 192.5.41.41

Router(config)#end

An Overview of CUCM ExpressCUCM 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 293c08.indd 293 9/21/11 11:24:43 AM9/21/11 11:24:43 AM


single device greatly appeals to small businesses and branch offi ces 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 Unifi ed 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 confi guring on voice gateways. These virtual dial peers are created automatically as we defi ne telephones and directory numbers. You will learn how to confi gure 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 294c08.indd 294 9/21/11 11:24:43 AM9/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 LE 8 . 2 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

c08.indd 295c08.indd 295 9/21/11 11:24:44 AM9/21/11 11:24:44 AM


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 LE 8 . 3 CUCM Express 7965 feature license bundles

License Description

FL-CCME-250 CUCM Express support for up to 250 IP phones






c08.indd 296c08.indd 296 9/21/11 11:24:44 AM9/21/11 11:24:44 AM

Initial CUCM Express Configuration 297

As you can see, you are given several ordering choices for a single phone! The CP-7965G= 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 ConfigurationCisco IP phones rely on external sources to receive information such as the fi rmware and confi guration fi les. This section details the fi les that the phones require and how to

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

c08.indd 297c08.indd 297 9/21/11 11:24:45 AM9/21/11 11:24:45 AM


confi gure them on the CUCM Express router. First, you will see how to turn CUCM Express into a TFTP server to offer up specifi c Cisco phone fi rmware fi les. Then we’ll move on to the four mandatory CUCM Express system confi gurations needed to support IP phones. Finally, you will see how to confi gure and generate individual phone confi guration 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 confi guration 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 confi gured 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 specifi cally tailored to the type of Cisco phone hardware. If you are using your CUCM Express router to handle TFTP server functionality, you must confi gure the IOS to serve up the fi rmware that your phones will request. All you need to do is fi gure out what Cisco phones you will want to allow on your network and then confi gure the router to serve the appropriate fi les. You can see all of the fi rmware fi le directories by issuing the dir flash:/phone command:

Directory of flash:/phone/

47 drw- 0 Apr 7 2009 18:18:28 +00:00 7945-7965

56 drw- 0 Apr 7 2009 18:18:56 +00:00 7937

58 drw- 0 Apr 7 2009 18:19:24 +00:00 7914

60 drw- 0 Apr 7 2009 18:19:26 +00:00 7906-7911

69 drw- 0 Apr 7 2009 18:19:52 +00:00 7920

71 drw- 0 Apr 7 2009 18:19:58 +00:00 7931

79 drw- 0 Apr 7 2009 18:20:24 +00:00 7942-7962

88 drw- 0 Apr 7 2009 18:28:46 +00:00 7921

96 drw- 0 Apr 7 2009 18:29:30 +00:00 7940-7960

101 drw- 0 Apr 7 2009 18:29:38 +00:00 7970-7971

110 drw- 0 Apr 7 2009 18:30:06 +00:00 7975

118 drw- 0 Apr 7 2009 18:30:34 +00:00 7941-7961

511664128 bytes total (395001856 bytes free)

Let’s assume that we are going to be confi guring Cisco 7945 and 7965 phones in our environment. Therefore, we need to confi gure our TFTP server to offer all of the fi les

c08.indd 298c08.indd 298 9/21/11 11:24:46 AM9/21/11 11:24:46 AM


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.

Confi guring 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/<firmware_file> 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 fi rmware 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 -rw- 2496963 Apr 7 2009 18:26:30 +00:00 apps45.8-5-3S.sbn

49 -rw- 585536 Apr 7 2009 18:26:34 +00:00 cnu45.8-5-3S.sbn

50 -rw- 2453202 Apr 7 2009 18:26:44 +00:00 cvm45sccp.8-5-3S.sbn

51 -rw- 326315 Apr 7 2009 18:26:46 +00:00 dsp45.8-5-3S.sbn

52 -rw- 555406 Apr 7 2009 18:26:48 +00:00 jar45sccp.8-5-3S.sbn

53 -rw- 638 Apr 7 2009 18:26:50 +00:00 SCCP45.8-5-3S.loads

54 -rw- 642 Apr 7 2009 18:26:50 +00:00 term45.default.loads

55 -rw- 642 Apr 7 2009 18:26:52 +00:00 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 confi gure the following:


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 299c08.indd 299 9/21/11 11:24:46 AM9/21/11 11:24:46 AM


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 confi gurations that must be set up on CUCM Express for the registration process to occur. The next few sections of this chapter show how to confi gure CUCM Express to allow Cisco phones to work with the call processor, and how to identify and serve up default confi guration fi les to your Cisco IP phones. First you’ll see how to confi gure SCCP signaling, and then you’ll explore the differences when confi guring SIP signaling between the CUCM Express and IP phones.

Configuring the Mandatory CUCM Express System

Settings Using SCCP Signaling

The majority of CUCM Express confi guration tuning happens while in config-telephony confi guration mode. There are four confi guration steps that must be accomplished to get the system to properly register phones for call processing using SCCP signaling:

1. Confi gure the source IP address for CUCM Express.

2. Confi gure 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 confi guration 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 300c08.indd 300 9/21/11 11:24:46 AM9/21/11 11:24:46 AM


We’re going to use the 192.168.10.1 IP address as our source IP for the CUCM Express. The confi guration of the CUCM Express source IP address is as follows:


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

Switch

Data

VLAN 1

192.168.1.0/24

Voice

VLAN 10

192.168.10.0/24

Cisco phone

Cisco phone

Cisco phone

CUCM Express

Trunk VLAN

1 and 10

Telephony source IP:

192.168.10.1

F I GU R E 8 . 3 A sample CUCM Express network

c08.indd 301c08.indd 301 9/21/11 11:24:47 AM9/21/11 11:24:47 AM


number extensions confi gured 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.

F I GU R E 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(config-telephony)#max-ephones 8

Router(config-telephony)#max-dn 20


Router#

The maximum number of ephones and ephone-DNs that can be confi gured 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 302c08.indd 302 9/21/11 11:24:47 AM9/21/11 11:24:47 AM


Also, if you exceed the max-dn number, you will receive an error when attempting to confi gure the maximum +1 ephone-DN. The following example has a max-dn set to 20, so on the 21st ephone-DN confi guration 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 confi guration process deals with how you handle the distribution of fi rmware for your Cisco phones. In the previous steps, we identifi ed the fi les that our Cisco phones need and have confi gured our router to serve them using TFTP. The CUCM Express telephony processes must also be confi gured 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 fi le 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 diffi cult to fi gure out which fi rmware load fi le you need to confi gure 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.

F I GU R E 8 .5 “Registration Rejected” message

c08.indd 303c08.indd 303 9/21/11 11:24:48 AM9/21/11 11:24:48 AM


Once you locate the fi rmware, you can click the link to display a table listing the correct load fi le for each phone that needs to be confi gured within config-telephony configuration mode. In Figure 8.6, you can see that you need to confi gure SCCP45.9-1-1SR1S.loads as our load fi le.

F I GU R E 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 confi guring CUCM Express to tell our Cisco 7945 and 7965 phones which fi rmware load fi les they should request:



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 confi guration fi le is the XML confi guration 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 confi guration are the source IP address and the port through which the phones can communicate with the call-processing agent. It also includes the load confi guration fi lenames we just fi nished setting up.

At this point, I’m referring to the phone confi guration fi les as “default” because there is nothing unique about the confi gurations right now. Once we begin confi guring phone

c08.indd 304c08.indd 304 9/21/11 11:24:48 AM9/21/11 11:24:48 AM


extensions and other settings unique to the phones, this information will be compiled and stored as a single phone confi guration fi le. But since none of that information is confi gured at this time, the confi guration fi les have only the default information that all the Cisco phones share.

The phone confi guration fi le is automatically updated every time a change is made that affects the confi guration. 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 confi guration prompt, the confi guration fi le updates itself. You can also manually update the phone confi guration 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 confi guration mode and fi nish your basic SCCP confi guration by confi guring ephones and ephone-DNs. Before you do that, however, we will go over the slightly different procedure for confi guring 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 confi guration 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 305c08.indd 305 9/21/11 11:24:49 AM9/21/11 11:24:49 AM


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 confi guration mode and issuing the allow-connections sip to sip command as shown here:

Router#configure trminal


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 confi gured 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 reg-ister 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 confi gured:

Router#configure trminal

Router(config)#voice register global

Router(config-register-global)#mode cme

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.

c08.indd 306c08.indd 306 9/21/11 11:24:50 AM9/21/11 11:24:50 AM

Configuring SCCP and SIP Phones and Directory Numbers 307

4. Just as with the SCCP phones, you need to confi gure 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 confi gure these settings using the same parameters as our SCCP CUCM Express confi guration 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 confi gurations, 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 confi guring 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 confi gured 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 confi gured to offer up the required SIP fi rmware fi les.

Finally, you need to generate your default confi guration profi les that are similar to the SCCP cnf-fi les. This is accomplished using the create profile command, which generates confi guration fi les that are used for provisioning SIP phones.

Configuring SCCP and SIP Phones and Directory NumbersNow that you know how to confi gure a CUCM Express router for basic operation for both SCCP and SIP, you need to confi gure the phones and directory numbers that will connect to your CUCM Express system and use it as a call-processing agent.

c08.indd 307c08.indd 307 9/21/11 11:24:50 AM9/21/11 11:24:50 AM


Configuring Basic SCCP Ephone and Ephone-DNs

Up until now, all of the confi guration 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 confi gurations 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 confi gure 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 confi guration 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 confi gure 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 confi guration mode, you give the ephone-DN an extension number. Let’s confi gure your fi rst ephone-DN with an extension of 4001 and a second ephone-DN with an extension of 4002:



Router(config-ephone-dn)#number 4001

Router(config-ephone-dn)#exit



Router(config-ephone-dn)#end

Router#

Now that you have two directory numbers confi gured, let’s apply them to two Cisco phones using the ephone confi guration command.

Configuring an SCCP Ephone

An ephone confi guration 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 confi gurations are applied. CUCM Express maps the ephone confi guration 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 confi guration settings wherever it goes.

Since you’re creating the most basic phone confi guration, the only information you’ll need to confi gure ephones is the MAC address of each phone and the ephone-DN tag you

c08.indd 308c08.indd 308 9/21/11 11:24:51 AM9/21/11 11:24:51 AM

Configuring SCCP and SIP Phones and Directory Numbers 309

wish to apply. You will also confi gure 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-ephone-type 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 specifi ed 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 confi gure two Cisco phones with your ephone-DN extension numbers. Ephone 1 will be confi gured to use extension 4001 and ephone 2 will be confi gured with extension 4002. Both phones are 7965Gs and prefer to use the G.729r8 codec for local calls only:


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)#mac-address 0014.4c7f.a49b




Router(config-ephone)#end

Router#

c08.indd 309c08.indd 309 9/21/11 11:24:51 AM9/21/11 11:24:51 AM


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 ephone-dn 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 confi guration is self-explanatory, but the button confi guration needs some explanation. The fi rst number of the button command indicates the Cisco IP phone button that is being confi gured. 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 confi guration specifi es the ephone-DN to apply to the physical phone. Since we specifi ed that ephone 1 uses ephone-DN 1, the extension on button 1 of ephone 1 will be 4001. Therefore ephone 2 will be confi gured 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 confi gure physical phones and logical directory numbers. The processes are similar to the confi guration of SCCP. In fact, some confi guration 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 confi gured using the voice register dn command followed by a unique DN tag, which is used to differentiate multiple directory numbers confi gured 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 confi gure two voice register DNs that are similar to the ephone DNs confi gured in the previous example:


Router(config)#voice register dn 1

Router(config-register-dn)#number 4001

c08.indd 310c08.indd 310 9/21/11 11:24:52 AM9/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 confi guration 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(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 OptionsThe 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 311c08.indd 311 9/21/11 11:24:52 AM9/21/11 11:24:52 AM


This section will fi rst show a typical ephone-DN shared-line confi guration, and one that has two DNs on a single telephone; both are common in key-system environments. You can then combine these options to confi gure dual-line and octo-line ephone-DNs, which are also common in small-business environments. Finally, we will look at typical PBX line confi gurations 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 confi gured 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 confi gured as buttons on every phone. This is known as a shared line. One way of confi guring this shared line is to confi gure a single ephone-DN and apply it to multiple ephones. The following key-system example confi guration 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(config-dn)#number 5555552121

extension to one phone model. There are several more directory number line options that are confi gurable for SCCP or SIP and SCCP, as shown in Table 8.5.

TA B LE 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

c08.indd 312c08.indd 312 9/21/11 11:24:53 AM9/21/11 11:24:53 AM


Router(config-dn)#ephone-dn 2

Router(config-dn)#number 5555559191

Router(config-dn)#exit


Router(config-ephone)#button 1:1 2:2


Router(config-ephone)#button 1:1 2:2


Router#

Figure 8.7 shows what ephone-DN 1 looks like after these confi gurations are made and the phone is reset.

F I GU 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 ephone-DN 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 313c08.indd 313 9/21/11 11:24:53 AM9/21/11 11:24:53 AM


Configuring Two Ephone-DNs with One Number

An alternative shared-line method is to confi gure two ephone-DNs with the same number. You then can confi gure the ephones to use the separate ephone-DN confi gurations. You set a preference on the ephone-DN confi guration 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 confi guration with a shared line using the preference confi guration command. This next confi guration example shows how to confi gure 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 confi gured to use ephone-DN 1 fi rst.




Router(config-ephone-dn)#preference 0

Router(config-ephone-dn)#ephone-dn 2





Line in use

F I GU R E 8 . 8 DN in use

c08.indd 314c08.indd 314 9/21/11 11:24:54 AM9/21/11 11:24:54 AM



Router(config-ephone)#ephone 2



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 confi gure 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(config-ephone-dn)#no huntstop










Router#

Configuring Ephone-DN Dual- and Octo-lines

Another shared-line key-system confi guration we need to look at is when the phone extensions are confi gured as dual-line and octo-line DNs. So far, we’ve confi gured 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 315c08.indd 315 9/21/11 11:24:54 AM9/21/11 11:24:54 AM


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 confi gured 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)

Confi guring ephone-DNs with dual lines is extremely benefi cial 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 confi gured with dual-line ephone-DNs. Just as in the previous confi guration example, we want to ensure that the fi rst 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 confi gure the following:


Router(config)#ephone-dn 1 dual-line




Router(config-ephone-dn)#ephone-dn 2 dual-line









Router#

In this situation, the fi rst call will always go to ephone-DN 1. But because the ephone-DN is confi gured 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 confi guration example to accomplish your goal:




c08.indd 316c08.indd 316 9/21/11 11:24:55 AM9/21/11 11:24:55 AM




Router(config-ephone-dn)#huntstop channel










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 “Confi guring Ephone Button Options” section of this chapter.

Configuring SCCP Individual Lines

PBX systems, which are more commonly found in larger offi ce environments, assign a unique phone extension to every phone. This allows the caller to reach a specifi c 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 fi ve 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 confi gured 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 confi gure the most common key-system methods of sharing a single phone number with multiple phones. Here is a very basic and common method of confi guring two PBX system phones with separate extension numbers:










c08.indd 317c08.indd 317 9/21/11 11:24:55 AM9/21/11 11:24:55 AM




Router#

Now you have two phones with separate extensions. The CUCM Express system can then be confi gured for additional features to tailor your system to your environment. Next we’ll look at how to confi gure ephone button options to enhance your SCCP phone confi gurations.

Configuring Ephone Button Options

As you saw earlier, when it’s time to assign ephone-DNs to specifi c ephones, you use the button command in ephone-config confi guration mode:

button 1:1

The separator between the line button you wish to confi gure and the ephone-DN identifi er 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 LE 8 .6 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.

c08.indd 318c08.indd 318 9/21/11 11:24:56 AM9/21/11 11:24:56 AM


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 confi gured 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 confi gured is button 2 to monitor my ephone-DN:









Router(config-ephone)#button 1:2 2m1


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.

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.

c08.indd 319c08.indd 319 9/21/11 11:24:56 AM9/21/11 11:24:56 AM


One of the drawbacks to this setup is what would happen if my phone were to be confi gured 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 confi gure 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 confi gured 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 confi gure 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

F I GU R E 8 . 9 The phone configured to monitor ext. 4040

Line

in use

c08.indd 320c08.indd 320 9/21/11 11:24:57 AM9/21/11 11:24:57 AM


overlay button option to assign multiple ephone-DNs to a single physical phone button. Ephone-DNs that are confi gured 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 specifi c department. This overlay shared-line confi guration 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 confi gured as an overlay line on button 1. When we confi gure the ephone-DN, we make sure to confi gure the unique extension fi rst. The fi rst ephone confi gured is the number that is displayed on the phone display LCD panel. The overlay line is confi gured, but that number is never seen on the phone button display. The shared line is confi gured 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 confi gured 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 confi guration looks like this:















Router(config-ephone)#button 1o1,3,4




Router#

Phone button 1 of both the phones is confi gured 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 confi guration consumes only one phone button on each phone. Now other buttons are open to be confi gured for additional lines or speed-dial capabilities if desired. Here is a show ephone for our two confi gured ephone-DNs. As you can see, the fi rst number assigned in the overlay confi guration is bound to the phone and idle. The shared number is visible but not the primary number.

c08.indd 321c08.indd 321 9/21/11 11:24:57 AM9/21/11 11:24:57 AM


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


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




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





overlay 1: 1(6001) 3(5454) 4(5454)




button 1: dn 3 number 5454 CH1 CONNECTED overlay shared

overlay 1: 2(6002) 3(5454) 4(5454)




Jitter 7 Latency 0 callingDn 5 calledDn -1

At this point, ephone-DN 3, which is number 5454, is owned and controlled by ephone-DN 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 confi gured 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 322c08.indd 322 9/21/11 11:24:58 AM9/21/11 11:24:58 AM


Router#show ephone





overlay 1: 1(6001) 3(5454) 4(5454)









overlay 1: 2(6002) 3(5454) 4(5454)





As you can see, this shared-line overlay confi guration is a very good option in many offi ce 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 confi gure our CUCM Express router with the same confi guration as the overlay example except we will use the call-waiting button separator option. We’ll also have to confi gure ephone-DN 3 as a dual-line phone so it can utilize call waiting:







c08.indd 323c08.indd 323 9/21/11 11:24:58 AM9/21/11 11:24:58 AM










Router(config-ephone)#button 1c1,3


Router(config-ephone)#button 1c2,3


Router#

So what are the results of this confi guration? 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 notifi ed 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 confi gured for call waiting (c). When the extensions confi gured as overlay lines are in use, the expansion lines begin taking calls. In this example, we have ephone-DN 1 confi gured 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 confi gured as an overlay for line 1 on the phone:








Router(config-ephone)#button 1o1,2 2x1


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 overfl ow to button 2 because both lines are busy on button 1. Always remember that overfl ow lines will be used only when all other lines are occupied.

c08.indd 324c08.indd 324 9/21/11 11:24:58 AM9/21/11 11:24:58 AM

Configuring CUCM Express Telephony Service Features 325

Configuring CUCM Express Telephony Service FeaturesThe confi guration steps for most telephony service features are performed while in config-telephony confi guration mode. These features provide multiple ways to tailor your voice environment to better fi t the needs of your end users. This section will show you how to confi gure 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 confi gured 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(config-telephony)#user-locale ES

Updating CNF files

c08.indd 325c08.indd 325 9/21/11 11:24:59 AM9/21/11 11:24:59 AM


CNF files update complete

Please issue ‘create cnf’ command after the locale change


CNF file creation is already On

Updating CNF files


Whenever we make changes to the confi guration of a telephone, we will need to reset the phone in order to obtain all of the updated confi guration and settings as manipulated.

The network-locale command modifi es 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


Please issue ‘create cnf’ command after the locale change



Updating CNF files


c08.indd 326c08.indd 326 9/21/11 11:24:59 AM9/21/11 11:24:59 AM


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 fi gure out the best confi guration 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 confi gure user-locale and network-locale ephone templates. This is an example of how the ephone templates were used to remedy this situation:



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)#ephone-template 1



Router(config-ephone)#ephone-template 2

Router(config-ephone)#exit




Updating CNF files


Router(config-telephony)#restart all

c08.indd 327c08.indd 327 9/21/11 11:25:00 AM9/21/11 11:25:00 AM


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(config-telephony)#date-format dd-mm-yy


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 confi gure 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(config-telephony)#time-format 24


Router#

This method sets up a very simple and streamlined way to confi gure ephones that fi ts the needs of the local user. Note that by default, the English (US) locale is confi gured 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 specifi ed. Ephone 2 is confi gured for user-locale 1, which is Spanish, and ephone 3 uses the French language as specifi ed in template 2.

c08.indd 328c08.indd 328 9/21/11 11:25:00 AM9/21/11 11:25:00 AM


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 notifi cation, 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 confi guration mode and use the keepalive command followed by the number of seconds in between each sent notifi cation, as shown here:



Router(config-telephony)#keepalive 60


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 modifi cations to a previously confi gured 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 confi guration 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 confi guration fi le. 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 confi guration mode and issue a restart all command. Here is an example of the output of this command:


Router(config-telephony)#restart all

Reset 2 phones: at 5 second interval - This could take several minutes per phone

Starting with 7960 phones

c08.indd 329c08.indd 329 9/21/11 11:25:01 AM9/21/11 11:25:01 AM


Router(config-telephony)#

Reset/Restart-all looking for phones registered as type 30008 7902


[output omitted]


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.


[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 confi guration 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 confi guration updates that the restart command can perform, the reset command updates the phone if any of the following were added/deleted or modifi ed:

� 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 confi guration 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 330c08.indd 330 9/21/11 11:25:01 AM9/21/11 11:25:01 AM



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



[output omitted]


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 lawful-intercept: 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)



[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



[output omitted]

Reset/Restart-all looking for phones registered as type -1 Unknown Ephone type

Reset-All issued for 2 phones

c08.indd 331c08.indd 331 9/21/11 11:25:01 AM9/21/11 11:25:01 AM


You can also reset a single phone by navigating into config-ephone confi guration 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 CommandsWhen setting up CUCM Express for the fi rst time, you may need some basic troubleshooting skills. This section goes through some of the more common troubleshooting steps, including how to fi gure 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 “Confi guring 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 confi guration 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 confi gured 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 332c08.indd 332 9/21/11 11:25:02 AM9/21/11 11:25:02 AM


May 17 18:18:54.303: DHCPD: address 192.168.10.2 mask 255.255.255.0

May 17 18:18:54.303: DHCPD: htype 1 chaddr 0021.a086.d04d

May 17 18:18:54.303: 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 Confi guration area. If your phone is not receiving an IP address, you should start by looking at a possible misconfi guration 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 confi guration fi les required to operate. If your phone is stuck with the “Registering” notifi cation 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 confi guration 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.043: TFTP: Looking for English_United_States/ipc-sccp.jar


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


Router#

c08.indd 333c08.indd 333 9/21/11 11:25:02 AM9/21/11 11:25:02 AM


Any line that begins with “Looking” means that the Cisco phone is requesting the fi le. If the TFTP server knows where a fi le is located, it will process the fi le, giving you the “Opened” statement. Finally, once the fi le 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 confi guration fi les, you should make sure that your TFTP server is confi gured 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/7960-tones.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 fl ash storage and serve them up using the tftp-server confi guration command.

Determining the State of an Ephone

Once your phones are confi gured 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 334c08.indd 334 9/21/11 11:25:03 AM9/21/11 11:25:03 AM


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.

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



button 1: dn 1 number 4001 CH1 DOWN


ephone-2[1] Mac:0021.A02E.7D9A TCP socket:[5] activeLine:0 REGISTERED in SCCP ver 12/9



button 1: dn 2 number 4002 CH1 IDLE


ephone-3[2] Mac:001E.68E1.AFE9 TCP socket:[1] activeLine:0 UNREGISTERED


IP:192.168.10.14 1556 CIPC keepalive 127 max_line 8



TA B LE 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.

c08.indd 335c08.indd 335 9/21/11 11:25:03 AM9/21/11 11:25:03 AM


There are three ephones confi gured 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, ephone-3 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 LE 8 . 8 Ephone extension states

State On- or Off-hook

Ephone Registration

State Description

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

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 336c08.indd 336 9/21/11 11:25:03 AM9/21/11 11:25:03 AM


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





ephone-3[2] Mac:001E.68E1.AFE9 TCP socket:[1] activeLine:0 UNREGISTERED


IP:192.168.10.14 1556 CIPC keepalive 127 max_line 8



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





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:




button 1: dn 2 number 4002 CH1 SEIZE

c08.indd 337c08.indd 337 9/21/11 11:25:04 AM9/21/11 11:25:04 AM






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:




button 1: dn 1 number 4001 CH1 RINGING


call ringing on line 1




button 1: dn 2 number 4002 CH1 ALERTING





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 338c08.indd 338 9/21/11 11:25:04 AM9/21/11 11:25:04 AM

Summary 339




button 1: dn 1 number 4001 CH1 CONNECTED









button 1: dn 2 number 4002 CH1 CONNECTED






SummaryAt 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 unifi ed 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 confi gure SCCP and SIP endpoints.

c08.indd 339c08.indd 339 9/21/11 11:25:05 AM9/21/11 11:25:05 AM


Exam EssentialsKnow 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 traffi c 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 confi gured 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 confi guration 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 confi gured 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 confi guration 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 confi guration fi les. For SIP phones, you must fi rst enable SIP and SIP-to-SIP calls, then

c08.indd 340c08.indd 340 9/21/11 11:25:05 AM9/21/11 11:25:05 AM

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 confi guration 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 confi guration 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 confi gured identically and share DNs. PBX systems are confi gured 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 confi guring 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.11. 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 confi guration command tells CUCM Express to serve up the flash:/phone/7945-7965/SCCP45.8-5-2-27.sbn fi le via TFTP?

4. What confi g-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?

Written Lab 8.1 341

c08.indd 341c08.indd 341 9/21/11 11:25:06 AM9/21/11 11:25:06 AM


7. What is the config-register-pool command to confi gure SIP voice register DN 5 on button 2?

8. What is the config-ephone command to confi gure 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?


Hands-On LabsTo 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.

Ext. 444

Ext. 555

CUCM Express

Telephony source IP:

192.168.10.1

F I GU R E 8 .10 CUCM Express lab diagram

These labs build on each other, so it is best to perform them in the order listed:

Lab 8.1: Confi guring CUCM Express as a TFTP Server

Lab 8.2: Confi guring CUCM Express for Basic SCCP Phone Operation

Lab 8.3: Verifying the Confi guration and Status of your Ephones

Hands-On Lab 8.1: Configuring CUCM Express as a TFTP ServerIn this lab, we are going to add 7940 phones to our voice network. In order for them to work properly, we need to confi gure the CUCM Express router as a TFTP server to serve up the fi rmware fi les that the 7940 phones require.

c08.indd 342c08.indd 342 9/21/11 11:25:06 AM9/21/11 11:25:06 AM

1. Log into your CUCM Express router and go into privileged execution confi guration mode by typing enable.

2. Check to see which fi rmware fi les the 7940 phones need by viewing the fi les on the fl ash drive. To do this, type dir flash:/phone/7940-7960. You should see something similar to the following output:

Directory of flash:/phone/7940-7960/

97 -rw- 129824 Mar 7 2011 18:14:31 +00:00 P00308000500.bin

98 -rw- 458 Mar 7 2011 18:14:31 +00:00 P00308000500.loads

99 -rw- 705536 Mar 7 2011 18:14:34 +00:00 P00308000500.sb2

100 -rw- 130228 Mar 7 2011 18:14:34 +00:00 P00308000500.sbn

3. Enter into confi guration mode by typing configure terminal.

4. Confi gure 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 flash:/phone/7940-7960/P00308000500.bin alias P00308000500.bin

tftp-server flash:/phone/7940-7960/P00308000500.loads alias P00308000500.bin

tftp-server flash:/phone/7940-7960/P00308000500.sb2 alias P00308000500.bin

tftp-server flash:/phone/7940-7960/P00308000500.sbn alias P00308000500.bin

5. Exit confi guration mode by typing end.

Hands-On Lab 8.2: Configuring CUCM Express for Basic SCCP Phone OperationIn our second lab, we will go through the basic confi guration 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 confi guration mode by typing enable.

2. Enter into confi g-telephony confi guration mode by typing configure terminal and then telephony-service.

3. Confi gure the IP source address to the address given in the diagram by typing ip source-address 192.168.10.1.

4. Confi gure 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.

Hands-On Labs 343

c08.indd 343c08.indd 343 9/21/11 11:25:07 AM9/21/11 11:25:07 AM


6. Exit config-telephony confi guration mode by typing exit.

7. Confi gure ephone-DN 1 to have the number 444 by typing ephone-dn 1 and then number 444.

8. Confi gure ephone-DN 2 to have the number 555 by typing ephone-dn 2 and then number 555.

9. Confi gure 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. Confi gure 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. Confi gure button 1 of ephone 1 to use ephone-DN 1 by typing ephone 1, pressing Enter, and then typing button 1:1.

12. Confi gure the phone type and codec preference by typing type 7940, pressing Enter, and then typing codec g729r8.

13. Confi gure button 1 of ephone 2 to use ephone-DN 2 by typing ephone 2, pressing Enter, and then typing button 1:2.

14. Confi gure the phone type and codec preference by typing type 7940, pressing Enter, and then typing codec g729r8.

15. Exit config-ephone confi guration mode by typing end.

Hands-On Lab 8.3: Verifying the Configuration and Status of Your EphonesNow that we have our phones properly confi gured, we can verify our confi guration settings and check to see if the phones are connected.

1. Log into your CUCM Express router and go into privileged exec confi guration mode by typing enable.

2. Verify the confi guration 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




c08.indd 344c08.indd 344 9/21/11 11:25:07 AM9/21/11 11:25:07 AM

Preferred Codec: g729r8





Preferred Codec: g729r8

3. From a confi guration 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)

4. From an operational standpoint, you should verify that the phones are in a REGISTERED and IDLE state (assuming the phones are not in use).

Hands-On Labs 345

c08.indd 345c08.indd 345 9/21/11 11:25:08 AM9/21/11 11:25:08 AM


Review Questions1. An ILP PoE switch can power devices of up to how many watts?

A. 6.0W

B. 15.4W

C. 6.3W

D. 7.0W

2. What protocol does a Cisco IP phone use to tell the PoE switch how much power it requires for the phone?

A. PoE protocol

B. iLBC

C. VTP

D. STP

E. CDP

3. What Cisco power-saving method helps to negotiate the exact power requirements of a Cisco IP phone?

A. IPM

B. 802.3af

C. ILP

D. CDP

4. Why is it important to configure DHCP option 150 for Cisco voice networks?

A. It defines the default gateway for the phone.

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.

5. Which of the following is not a CUCM Express license?

A. Cisco SCCP license

B. Cisco IOS license for voice capabilities

C. CUCM Express feature licenses

D. Individual user license

6. What is the tftp-server IOS command used for?

A. To identify the IP address of the TFTP server

B. To set option 150 for DHCP clients

C. To identify files the router serves via TFTP

D. To enable Secure FTP

c08.indd 346c08.indd 346 9/21/11 11:25:08 AM9/21/11 11:25:08 AM

7. What command is used to manually update the phone configuration load files on a CUCM Express system configured for SCCP endpoints?

A. create firmware

B. create cnf-files

C. load cnf-files

D. load firmware

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

B. create profile

C. source-address 192.168.1.1

D. auto assign

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






A. Shared-line, octo-line

B. Huntgroup

C. Two DNs with one telephone

D. Shared-line, overlay

E. Shared-line, extension-line


c08.indd 347c08.indd 347 9/21/11 11:25:09 AM9/21/11 11:25:09 AM


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?




button 1: dn 2 number 4002 CH1 ALERTING






A. The phone is currently in a call.

B. The phone is on-hook.

C. The phone is calling another extension.

D. The phone is receiving a call.

c08.indd 348c08.indd 348 9/21/11 11:25:09 AM9/21/11 11:25:09 AM

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

B. language-locale

C. user-locale

D. telephony-service-locale


c08.indd 349c08.indd 349 9/21/11 11:25:09 AM9/21/11 11:25:09 AM


Answers to Review Questions1. 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 confi guration fi les.

5. A. You need a license for the voice IOS, the CUCME software for a specifi c 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 confi guration SCCP load fi les using the create cnf-files command.

8. A. The initial confi guration 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 specifi es the number of telephone extensions that can be operated on CUCM Express. This command is entered while in config-register-global confi guration 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 confi guration shows two ephones with a shared-line and overlay button.

12. C. The create profile command is used to build the default confi guration load fi le for SIP endpoints. This command is entered while in config-register-global confi guration mode.

13. C. The restart all command within config-telephony confi guration mode performs a quick reset of all registered phones.

14. C. When a phone powers up and connects to the network, its fi rst 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 350c08.indd 350 9/21/11 11:25:10 AM9/21/11 11:25:10 AM

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 confi guration option that allows you to confi gure 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 351c08.indd 351 9/21/11 11:25:10 AM9/21/11 11:25:10 AM


Answers to Written Lab 8.11. 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 352c08.indd 352 9/21/11 11:25:10 AM9/21/11 11:25:10 AM

Advanced Voice Gateway Features



■ Describe path selection.

■ Describe calling privileges.


a VoIP call.

■ Describe VoIP call flows.


■ Describe dial peers and the gateway call routing process.


■ Configure digit manipulation.

■ Implement fax support on a gateway.

�

�

�

�

Chapter

9

c09.indd 353c09.indd 353 9/21/11 11:25:35 AM9/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 confi guration to further enhance the voice experience. We will begin by confi guring 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 SupportBy 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 confi gure 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 confi gure DTMF relay support for H.323, SIP, and MGCP.

Configuring H.323 DTMF Relay

H.323 DTMF relay is confi gured 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:

cisco-rtp This method uses a Cisco proprietary method of transporting DTMF tones in special RTP packets.

c09.indd 354c09.indd 354 9/21/11 11:25:36 AM9/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.

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

rtp-nte This method uses the named telephone event defi ned in RFC 2883, which specifi es 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 in-band 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 confi gured to use one of these out-of-band signaling methods. When you confi gure 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 confi gure 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 confi gure VoIP dial peer 100 to use both H245 alphanumeric and H245 signal methods:



Router(config-dial-peer)#dtmf-relay h245-alphanumeric h245-signal


Router#

So now our voice gateway is confi gured 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

Confi guration of DTMF relay using SIP is similar to the H.323 confi guration, except that your dial peer must specifi cally 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 355c09.indd 355 9/21/11 11:25:37 AM9/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 specifi es that out-of-band DTMF tones are sent in SIP-notify messages between remote voice gateways. Both DTMF relay methods can be confi gured, with the priority method being rtp-nte. Here’s an example of how to confi gure SIP signaling on VoIP dial peer 200 to use only the rtp-nte method that will also drop in-band DTMF tone digits:




Router(config-dial-peer)#dtmf-relay rtp-nte digit-drop


Router#

Configuring MGCP DTMF Relay

DTMF relay support for the MGCP voice gateway signaling protocol can be confi gured 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 confi gure the voice gateway (GW) to have control of the DTMF relay confi guration 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 confi gure 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 confi gure the RFC 2833 standard DTMF relay method, letting the voice gateway negotiate the relay method using any voice codec:


Router(config)#mgcp dtmf-relay voip codec all mode nte-gw

Router(config)#mgcp package-capability dtmf-package

Router(config)#end

Router#

c09.indd 356c09.indd 356 9/21/11 11:25:37 AM9/21/11 11:25:37 AM

Configuring Fax Support 357

Configuring Fax SupportVoice 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 fi ne for the human voice, the same cannot be said for fax transmissions. Fax transmissions are far more sensitive to the loss of fi delity 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 confi gure 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 defi ned by the ITU-T and are also defi ned 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 357c09.indd 357 9/21/11 11:25:38 AM9/21/11 11:25:38 AM


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

Voice

gateway

V

Voice

gateway

VFax

Ext: 3000

Fax to

4000 T.30 T.30Cisco proprietary RTP

VoIP

Demodulation

and

packetization

Depacketization

and

remodulation

Fax

Ext: 4000

F I GU R E 9 .1 The Cisco fax relay process

Voice

gateway

V

Voice

gateway

VFax

Ext: 3000

Fax to

4000 T.30 T.30ITU-T T.38

VoIP

Demodulation

and

packetization

Depacketization

and

remodulation

Fax

Ext: 4000

F I GU R E 9 . 2 T.38 fax relay

c09.indd 358c09.indd 358 9/21/11 11:25:38 AM9/21/11 11:25:38 AM


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 confi guration mode or on an individual dial-peer level while in conf-dial-peer confi guration 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 confi guring Cisco fax relay globally:



Router(config-voi-serv)#fax protocol


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 confi guration 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 confi guring 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 confi gurations and MGCP T.38 confi gurations.

ls-redundancy Stands for low-speed redundancy and specifi es 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 specifi es 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 359c09.indd 359 9/21/11 11:25:39 AM9/21/11 11:25:39 AM


In addition to the T.38 confi guration 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 confi gure 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(config-dial-peer)#fax protocol t38 ls-redundancy 3 hs-redundancy 3 fallback cisco


Router#

Always remember that fax relay can also be confi gured globally while in conf-voi-serv confi guration mode. The specifi c dial-peer confi gurations take precedence over the global confi gurations if both are used.

Understanding and Configuring Optional Fax SIP

and H.323 Settings

CVOICE candidates should be familiar with a few optional confi guration 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 <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 confi gured while in config-dial-peer mode. Here is an example of how to confi gure a static transmission rate of 7200 bps on VoIP dial peer 10:

c09.indd 360c09.indd 360 9/21/11 11:25:39 AM9/21/11 11:25:39 AM




Router(config-dial-peer)#fax rate 7200 voice


Router#

fax-relay The fax-relay command is used to enable/disable two distinct fax features. The command can be confi gured 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(config-voi-serv)#fax-relay ecm disable


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 offi ce, to use the IP WAN connections instead. The fi rst 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 offi ce. 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 confi guration. 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 offi ces. 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 361c09.indd 361 9/21/11 11:25:40 AM9/21/11 11:25:40 AM


A second task is to confi gure 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 SG3-compatible 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 confi guring 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 confi guration is performed on the CUCM and is outside the scope of this study guide. Therefore, we will fi rst look at how to confi gure gateway (GW)-controlled MGCP T.38 fax relay. Additionally, we will confi gure MGCP T.38 fax relay to interoperate with SIP- and H.323-confi gured T.38 gateways.

The commands needed to confi gure T.38 fax relay using MGCP are performed in global confi guration 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 specifi es 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 specifi es 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 specifi c 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 362c09.indd 362 9/21/11 11:25:40 AM9/21/11 11:25:40 AM


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 confi gure MGCP T.38 signaling to use Cisco NSEs and to enable error checking. The TSE payload size is enabled and set to 105:


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 confi guration 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 briefl y look at how to confi gure 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 confi gured while in global confi guration mode. Here is an example of how to confi gure a static transmission rate of 9600 bps:


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 confi gures the T.38 NSE response wait time to 1000 ms:


Router(config)#mgcp timer nse-response t38 1000

Router(config)#end

Router#

c09.indd 363c09.indd 363 9/21/11 11:25:41 AM9/21/11 11:25:41 AM


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 fl ow through the IP network.

Voice

gateway

V

Voice

gateway

VFax

Ext: 3000

Fax to

4000 T.30

VoIP

G.711a-law or

mu-law

enforced

Fax

Ext: 4000

F I GU R E 9 . 3 Fax pass-through

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 confi gure on a voice gateway. The voice gateway can be confi gured either globally while in conf-voi-serv confi guration mode or on a single dial peer while in config-dial-peer mode. Keep in mind that individual dial-peer confi gurations take precedence over global confi gurations.

Configuring Fax Pass-through

Global confi guration of fax pass-through is identical for H.323 and SIP. Here is an example of how to confi gure fax pass-through globally:



Router(conf-voi-serv)#fax protocol pass-through g711ulaw

c09.indd 364c09.indd 364 9/21/11 11:25:41 AM9/21/11 11:25:41 AM


Confi guration of fax pass-through for MGCP is slightly different. There are three required commands, which must be confi gured while in global confi guration 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 pass-through 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 confi gure fax pass-through on an MGCP voice gateway that uses G.711a-law:


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 confi gured to send T.30 fax transmissions to the destination fax as usual. The fax transmission passes through a voice gateway confi gured 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 365c09.indd 365 9/21/11 11:25:42 AM9/21/11 11:25:42 AM


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 confi gured identically on voice gateways running H.323 or SIP. MGCP does not support store-and-forward. The confi guration 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.

Off-ramp

voice gateway

V

On-ramp

voice gateway

VFax

Ext: 3000

Fax to

4000 T.30 T.30Email

Conversion of

T.30 fax to

TIFF and sent as

email attachment

Conversion TIFF

to T.30 fax and

sent to Ext: 4000

PC- or T.37

capable

fax

SMTP

server

Fax

Ext: 4000

IP

Network

F I GU R E 9 . 4 T.37 store-and-forward fax

c09.indd 366c09.indd 366 9/21/11 11:25:42 AM9/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 confi rmation of receipt back to the originating gateway. Because the confi guration process is complex, involving many components, and the confi guration varies greatly from one network to another, the CVOICE exam does not require you to know how to confi gure store-and-forward fax, only that you understand how it works from a design and signaling perspective.

Configuring Modem SupportModem 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 fl uctuate throughout a single connection. Modem traffi c can be confi gured using either modem pass-through 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 confi gured either globally, while in config-voi-serv confi guration 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 confi guring modem pass-through globally, you have only the nse option, which stands for named service events. The system option is available only when confi guring pass-through on dial peers. This command basically tells the voice gateway to use the options on the global confi guration. 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 specifi es 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.

system This keyword is available only on dial-peer confi gurations and is used to tell the voice gateway to use the globally confi gured modem pass-though confi guration.

codec This keyword specifi es 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.

maximum-sessions This keyword sets a maximum number of simultaneous modem pass-through sessions. The range of maximum-sessions varies by hardware platform.

c09.indd 367c09.indd 367 9/21/11 11:25:43 AM9/21/11 11:25:43 AM


The following example shows how to confi gure modem pass-through on dial peer 20 that specifi es use of the G.711-ulaw codec and the use of RFC 2198 redundancy packets:



Router(config-dial-peer)#modem passthrough nse codec g711ulaw redundancy


Router#

Configuring Modem Relay

Confi guring modem relay is nearly identical to confi guring modem pass-through, with just a few exceptions. Modem relay can be confi gured 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 Specifi es whether the voice gateway controls modem pass-through transport parameters.

Here is an example of how to confi gure modem relay on a voice gateway using NSE and gateway control functionality for SIP and H.323:



Router(config-voi-serv)#modem relay nse gw-controlled


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 confi gured 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(config)#mgcp modem relay voip mode nse gw-controlled

Router(config)#mgcp package-capability dtmf-package

Router(config)#end

Router#

Configuring Voice Backup PathsPart 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 368c09.indd 368 9/21/11 11:25:44 AM9/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 confi guration 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 confi gure 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 confi gure WAN-to-PSTN fallback, we will use Figure 9.5 as our example network.

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

Seattle

V

Las Vegas Switch

Extensions:

4XXX

V

Switch

Extensions:

5XXX

Preferred path

Backu

p p

ath

PSTN

S0/0/0:23

172.16.1.1IP WAN

F I GU R E 9 .5 WAN-to-PSTN fallback

c09.indd 369c09.indd 369 9/21/11 11:25:44 AM9/21/11 11:25:44 AM


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 offi ce 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 confi gure H.323 fallback on the router. With H.323 fallback confi gured, the router will begin using H.323 signaling (and corresponding dial peers that are confi gured locally) to route calls going into the private network and out to the PSTN. The best way to show you how to confi gure 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 370c09.indd 370 9/21/11 11:25:45 AM9/21/11 11:25:45 AM


Confi guring MGCP to H.323 fallback would require the following three confi guration steps:

1. The fi rst command we enter tells our voice gateway that we are enabling MGCP fall-back in the case that communications to the CUCM are lost:


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 confi guring the following:


Router(config)#application

Router(config-app)#global

Router(config-app-global)#service alternate default

Router(config-app-global)#end

Router#

Connection

failure

CUCM

192.168.1.2

PSTN

IP WAN

H.323 fallback

using dial peer

to PSTN

V

Voice

gateway

VSwitch

M

MG

CP

F I GU R E 9 .6 H.323 fallback

c09.indd 371c09.indd 371 9/21/11 11:25:46 AM9/21/11 11:25:46 AM


3. Then we confi gure 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 confi gure POTS dial peer 909 to accept any incoming calls and route NANP long-distance calls out the T1 CAS:



Router(config-dial-peer)#application mgcpapp

Router(config-dial-peer)#incoming called-number .

Router(config-dial-peer)#destination-pattern 91[2-8].........




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 confi gured 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 372c09.indd 372 9/21/11 11:25:46 AM9/21/11 11:25:46 AM


we need to confi gure 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 confi gure survivable remote site telephony (SRST) in conjunction with local COR profi les to get the job done. We will use Figure 9.7 as our example of COR and SRST confi guration to implement.

Connection

failure

CUCM

192.168.1.2

0/0/0:23192.168.1.1

300630013000

PSTN

IP WAN

V

SRST voice

gateway

VSwitch

M

F I GU R E 9 .7 COR and SRST

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:

� If the COR confi gured 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 defi ned on a dial peer, then the voice gateway will use the default inbound or outbound COR list confi gured. The default COR lists use the lowest priority setting and therefore will allow the call to proceed.

c09.indd 373c09.indd 373 9/21/11 11:25:47 AM9/21/11 11:25:47 AM


The confi guration of this on IOS routers begins with defi ning the COR members. These are simply labels that will defi ne specifi c 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 confi gure four commonly confi gured COR members. To do this we must fi rst enter into config-dp-cor confi guration mode by using the dial-peer cor custom command. Once we enter this mode, we can create our COR containers:


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 defi ned, 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 confi gure four COR lists that each contain their respective single COR membership that we confi gured earlier:


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)#dial-peer cor list ldout

Router(config-dp-corlist)#member ld


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(config)#dial-peer cor list 911


c09.indd 374c09.indd 374 9/21/11 11:25:47 AM9/21/11 11:25:47 AM



Router(config)#dial-peer cor list local




Router(config)#dial-peer cor list ld





Router(config)#dial-peer cor list int




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 confi gure POTS dial peer 9 and defi ne it for local destination patterns, as shown here:



Router(config-dial-peer)#destination-pattern 9[2-9]......

Router(config-dial-peer)#corlist outgoing localout


All the other required dial peers for our example are shown here:




Router(config-dial-peer)#corlist outgoing 911out






Router(config-dial-peer)#corlist outgoing 911out

c09.indd 375c09.indd 375 9/21/11 11:25:48 AM9/21/11 11:25:48 AM





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)#destination-pattern 9011T

Router(config-dial-peer)#prefix 011

Router(config-dial-peer)#corlist outgoing intout



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 confi guration of SRST on a compatible IOS gateway version is very similar to confi guring 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 confi gure SRST for SCCP. First, we need to enter into config-cm-fallback confi guration mode and defi ne our source IP address and max ephones and ephone-DNs as shown here:


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 confi gure an ephone and apply the ephone-DN of 3000 to button 1:






Router(config-ephone)#mac-address 0014.1c4d.2589

c09.indd 376c09.indd 376 9/21/11 11:25:48 AM9/21/11 11:25:48 AM

Toll Bypass and TEHO 377





Router#

Now that we have an SRST phone confi gured, 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 confi guration 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(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 confi gured 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 TEHOOne 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 traffi c 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 confi guring your IP network to utilize WAN connections for voice transport is known as toll bypass, and you already know how to confi gure this as well as how to confi gure the PSTN as a backup in case of a WAN failure. You can extend the functionality

c09.indd 377c09.indd 377 9/21/11 11:25:48 AM9/21/11 11:25:48 AM


of toll bypass, however, when you confi gure 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.

SanFran

V

Miami

Extensions:

5XXX

V

Ext 4000 call to

305-558-8442

To area code 305

PSTN

192.168.10.1 192.168.10.2IP WAN PSTN

Local hop-off to PSTN

PSTN

Area code

305

Area code

415

F I GU R E 9 . 8 A TEHO network

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 confi gure 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 confi guring TEHO on our SanFran and Miami voice gateways.

Configuring Tail End Hop Off

The secret to confi guring TEHO lies in dial-peer confi gurations and digit translations. It’s really just a matter of determining the following:

� What area codes are considered local in Miami?

� What area codes are considered local in SanFran?

c09.indd 378c09.indd 378 9/21/11 11:25:49 AM9/21/11 11:25:49 AM

Toll Bypass and TEHO 379

Then you need to do the following:

� Confi gure digit manipulation for Miami to SanFran local PSTN calls so that the remote ANI is displayed.

� Confi gure digit manipulation for SanFran to Miami local PSTN calls so that the remote ANI is displayed.

� Confi gure an outbound VoIP dial peer on the SanFran voice gateway to transport Miami PSTN calls across the IP WAN.

� Confi gure an outbound VoIP dial peer on the Miami voice gateway to transport San-Fran 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 confi gured 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 profi le 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 379c09.indd 379 9/21/11 11:25:49 AM9/21/11 11:25:49 AM


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, long-distance, 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 confi guration, we will now confi gure 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, “Confi guring Quality of Service,” of this study guide.

Configuring Call BlockingIn 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 premium-rate 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 profi le 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 380c09.indd 380 9/21/11 11:25:50 AM9/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 confi gure our specifi c rule:



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 confi gure 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(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 confi gured as our inbound dial peer for our PSTN connection. Therefore, we simply apply the following confi guration:


Router (config)#dial-peer voice 100 pots

Router(config-dial-peer)#call-block translation-profile incoming block_900


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 381c09.indd 381 9/21/11 11:25:50 AM9/21/11 11:25:50 AM


unassigned-number Unassigned Number

user-busy User Busy

Router(config-dial-peer)#call-block disconnect-cause incoming

We can test our call-blocking confi guration 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#

SummaryVoice gateways are a bit of a Swiss army knife in terms of what they can be confi gured to do for voice services, reliability, and customization. In Chapter 9, we moved beyond basic voice gateway confi guration to confi gure 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 EssentialsKnow the four methods for configuring H.323 DTMF relay. H.323 DTMF relay can be confi gured 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 confi gured 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 confi gured using the CUCM call agent (CA) or locally using the voice gateway (GW) method.

Know the three fax-relay methods. The three methods are fax relay, fax pass-through, and T.37 store-and-forward fax.

c09.indd 382c09.indd 382 9/21/11 11:25:51 AM9/21/11 11:25:51 AM

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. Cisco supports modem pass-through and modem relay.

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 confi gured similarly to the way CUCM Express is confi gured. 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 confi guring ephone-DNs and associating them to buttons on ephones.

Understand the purpose of toll bypass and TEHO. Toll bypass and TEHO are confi gured 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 confi gured 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.

Exam Essentials 383

c09.indd 383c09.indd 383 9/21/11 11:25:51 AM9/21/11 11:25:51 AM


Written Lab 9.11. What is the command that confi gures 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 confi guration methods?

6. What tone frequency does a voice gateway, confi gured for fax pass-through, listen for to detect the transmission of a line?

7. You are confi guring 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 confi guring, you should use voice translation rules and profi les to send the correct to the PSTN.


Hands-On LabsTo 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.

SiteA

V

SiteB

Ext: 888-3434

V

PSTN

S1/0:23

10.1.1.1IP WAN PSTN

Area code

555

Area code

123

Ext: 456-7890

F I GU R E 9 . 9 Toll bypass and TEHO labs

c09.indd 384c09.indd 384 9/21/11 11:25:52 AM9/21/11 11:25:52 AM

This lab assumes that basic IP networking and the local voice network is operational. We are only concerned with confi guring SiteA’s voice gateway.


Lab 9.1: Confi guring Toll Bypass and PSTN Redundancy

Lab 9.2: Confi guring TEHO

Hands-On Lab 9.1: Configuring Toll Bypass

and PSTN Redundancy

In this lab, we’re going to confi gure 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 confi gure 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.


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. Confi gure a destination-pattern to match on site-code 888 followed by four wildcard digits, by typing destination-pattern 888....

4. Confi gure the dial peer to forward all seven digits, by typing no digit-strip.

5. Confi gure the next-hop destination to send calls over the IP WAN to SiteB, by typing session-target ipv4:10.1.1.1.

6. Confi gure the dial peer to be the preferred path, by typing preference 1.


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. Confi gure a destination-pattern to match on site-code 888 followed by four wildcard digits by typing destination-pattern 888....

10. Confi gure 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. Confi gure the dial peer to forward all seven of the entered digits, by typing no digit-strip.

12. Confi gure the next-hop destination to send calls out the T1 and over to the PSTN, by typing port 1/0:23.

13. Confi gure the dial peer to be the backup path, by typing preference 2.


Hands-On Labs 385

c09.indd 385c09.indd 385 9/21/11 11:25:52 AM9/21/11 11:25:52 AM


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. Confi gure a destination pattern to match on all numbers starting with 9, by typing destination-pattern 9T.

17. Confi gure the next-hop destination to send calls out the T1 and over to the PSTN, by typing port 1/0:23.


Hands-On Lab 9.2: Configuring TEHO

In Lab 9.2 we will confi gure 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.


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 confi gured on phones at SiteA by typing rule 1 /^2/ /1123/.

4. Exit cfg-translation-rule mode by typing exit.

5. Confi gure 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-translation-profile 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. Confi gure 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. Confi gure 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.


c09.indd 386c09.indd 386 9/21/11 11:25:53 AM9/21/11 11:25:53 AM

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


C. 1. cisco-rtp

2. h245-signal


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

B. In the data channel

C. As a pulse

D. In the bearer channel

3. What voice gateway fax transport method transmits fax messages over an IP network the same way that voice messages are transported?

A. T.30

B. T.37

C. Fax relay

D. Fax pass-through

4. What fax relay method uses the concept of virtual fax interfaces?

A. T.37

B. Cisco fax relay

C. Fax pass-through

D. Store-and-forward fax

E. T.38


c09.indd 387c09.indd 387 9/21/11 11:25:53 AM9/21/11 11:25:53 AM


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

6. What is the maximum fax transmission rate for SG3 fax machines?

A. 14,400 bps

B. 28,800 bps

C. 33,600 bps

D. 56,000 bps

7. What are the two fax tone transmissions that can be used on T.38 fax relay?

A. fax protocol t38 nse

B. fax protocol t38 tse

C. fax-relay sg3-to-g3

D. fax-relay ans-disable

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

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.

9. How are faxes transmitted across the IP network using the T.37 store-and-forward method?

A. TIFF images attached in emails

B. TCL scripts attached in emails

C. In special RFC 2883 RTP packets

D. In special Cisco proprietary packets

c09.indd 388c09.indd 388 9/21/11 11:25:54 AM9/21/11 11:25:54 AM

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

B. On networks that utilize MGCP

C. On networks that utilize H.323 or SIP

D. When voice gateways are configured for SRST


c09.indd 389c09.indd 389 9/21/11 11:25:54 AM9/21/11 11:25:54 AM


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

B. Call-reject

C. Invalid-number

D. User-busy

E. Unassigned-number

c09.indd 390c09.indd 390 9/21/11 11:25:55 AM9/21/11 11:25:55 AM

Answers to Review Questions1. 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


2. A. DTMF relay transports signals out of band. If this is not confi gured, 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 confi guration mode.

13. C. When confi guring MGCP to H.323 fallback, you must confi gure 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 391c09.indd 391 9/21/11 11:25:55 AM9/21/11 11:25:55 AM


15. D. Typically, COR is confi gured on the CUCM. One exception is when a voice gateway is also confi gured 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 confi guration mode.

17. C. The correct syntax is cor incoming emergency 3 4000 4010. This is confi gured while in config-cm-fallback confi guration mode.

18. D. When you confi gure TEHO, you should also confi gure 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 confi guring call-block except reorder-reject.

c09.indd 392c09.indd 392 9/21/11 11:25:56 AM9/21/11 11:25:56 AM

Answers to Written Lab 9.11. 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 Identifi cation (ANI)


c09.indd 393c09.indd 393 9/21/11 11:25:56 AM9/21/11 11:25:56 AM

c09.indd 394c09.indd 394 9/21/11 11:25:56 AM9/21/11 11:25:56 AM

Configuring and Managing CUBE and H.323 Gateways


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.

�

Chapter

10

c10.indd 395c10.indd 395 9/21/11 11:26:22 AM9/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 offi cial 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 Unifi ed Border Element (CUBE) to see how it is different from a standard voice gateway and how it can connect two voice net-works 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 confi gured on voice gateways, as you learned in Chapter 7, “Confi guring 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 LE 10 .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 396c10.indd 396 9/21/11 11:26:24 AM9/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.

Zone1 Zone2

Gatekeeper

V

Voice

Gateway1

VVoice

Gateway2

V

F I GU R E 10 .1 A network controlled by a single H.323 gatekeeper

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 specifi cally belong to a zone itself.

There can also be multiple gatekeepers confi gured that manage different zones, as shown in Figure 10.2.

F I GU R E 10 . 2 A network controlled by multiple H.323 gatekeepers

Zone1 Zone2

Gatekeeper1 Gatekeeper2V V

Voice

Gateway1

VVoice

Gateway2

V

c10.indd 397c10.indd 397 9/21/11 11:26:24 AM9/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 confi gured as either permit or deny rules, depending

c10.indd 398c10.indd 398 9/21/11 11:26:25 AM9/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 suffi cient bandwidth is available. If, however, the gatekeeper fi nds that there is not enough bandwidth available at the current time, it can reject new calls from being made until suffi cient bandwidth has been reclaimed. CAC is one of the most common reasons for implementing a gatekeeper.

Understanding Gatekeeper SignalingGatekeepers 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 preconfi gure your H.323 voice gateways with the IP address of your

c10.indd 399c10.indd 399 9/21/11 11:26:25 AM9/21/11 11:26:25 AM


gatekeeper. Because the gateway is preconfi gured 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 preconfi gured 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 fi eld 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:

� Admission Request (ARQ)

� Admission Confi rmation (ACF)

� Admission Reject (ARJ)

c10.indd 400c10.indd 400 9/21/11 11:26:26 AM9/21/11 11:26:26 AM


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 specifi cally, 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 ProcessLet’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.

Zone1 Zone2

Gatekeeper

H.225

H.245

RTP

RTP

RAS RASV

Voice_GW_1

4444 5555

VVoice_GW_2

V

F I GU R E 10 . 3 Gatekeeper RAS discovery, registration, and admission

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 confi gured 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 401c10.indd 401 9/21/11 11:26:26 AM9/21/11 11:26:26 AM


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 fi eld 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 fi nds 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.

Zone1 Zone2

Voice_GW_1

7777 8888

VVoice_GW_2

V

RAS

location

messages

Gatekeeper1 Gatekeeper2V V

F I GU R E 10 . 4 RAS location messages

c10.indd 402c10.indd 402 9/21/11 11:26:27 AM9/21/11 11:26:27 AM


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 verifi es 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 confi gured 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.

Zone_B

Zone_C

Zone_D

Zone_A

Gatekeeper2

V

Gatekeeper3

VGatekeeper1

ARQ

LRQ #1

LRJ

LRJ

LCF

LRQ #2

LRQ #3

V

Gatekeeper4

V

F I GU R E 10 .5 Sequential location message forwarding

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 403c10.indd 403 9/21/11 11:26:27 AM9/21/11 11:26:27 AM


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:

� Bandwidth Request (BRQ)

� Bandwidth Confi rm (BCF)

� Bandwidth Reject (BRJ)

Zone_B

Zone_C

Zone_D

Zone_A

Gatekeeper2

V

Gatekeeper3

VGatekeeper1

ARQ

LCF

LRQ Blast

V

Gatekeeper4

V

F I GU R E 10 .6 Blast location message forwarding

c10.indd 404c10.indd 404 9/21/11 11:26:28 AM9/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 GatekeeperNow that you have a solid understanding of what H.323 gatekeepers offer and how they communicate, we will explore how to confi gure the following gatekeeper functions:

� Local zones

� Remote zones

� Zone prefi xes

� Technology prefi xes

We’ll go over each of these confi guration steps in the following few sections. Figure 10.7 shows the network with dual gatekeepers that will be used to show how to confi gure H.323 gatekeeper and gateway interoperation.

Zone: Miami

Miami

4XXX

S0/0V

Zone: Boston

Boston

Gatekeeper1

Domain: example.com

Gatekeeper2

3XXX

S0/0 S0/0V

V

Zone: LA

IP WAN

5XXX

Tech prefix: 1# 99#

10.99.99.1 10.5.5.1

VLA

V

F I GU R E 10 .7 H.323 multi-gatekeeper network

c10.indd 405c10.indd 405 9/21/11 11:26:28 AM9/21/11 11:26:28 AM


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 confi gure 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 qualifi ed 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 specifi ed only once in a local zone confi guration. Once the IP address is confi gured for one local zone, this address is used for all other confi gured local zones.

Here is an example of how to confi gure 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 confi gured 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 confi gure a remote zone and specify the FQDN and IP address of the remote gateway. In our example, we will confi gure a remote zone for our LA zone and specify that calls that are not confi gured 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 confi guration:



c10.indd 406c10.indd 406 9/21/11 11:26:29 AM9/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#

Configuring Zone Prefixes

Gatekeepers keep track of zones by using a unique zone prefi x. A zone prefi x uses E.164 numbers to defi ne 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 specifi c prefi x for a known local zone. If a match is made, the gatekeeper routes that call to the zone that is mapped to the zone prefi x. To confi gure zone prefi xes, 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 confi gure Gatekeeper_1 with two zone prefi x commands for the Boston and Miami local zones:



Gatekeeper1(config-gk)#zone prefix Boston 3...

Gatekeeper1(config-gk)#zone prefix Miami 4...


Gatekeeper1#

Now we’ve successfully mapped all 3XXX calls to the Boston zone and all 4XXX calls to Miami. Since we’ve already confi gured the next-hop IP address in our local zone confi guration 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 confi gure 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 confi gure 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 407c10.indd 407 9/21/11 11:26:30 AM9/21/11 11:26:30 AM


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 confi gure technology prefi xes, 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 prefi x numbers in order to include them as a prefi x when the destination number is dialed. In addition, note that the technology prefi x takes precedence over any zone prefi xes. So even though the number dialed matches a zone prefi x, the technology prefi x number will be matched fi rst and sent to the proper voice gateway. Also note that the technology prefi x will be stripped off prior to forwarding the call to the destination voice gateway. By default, no technology prefi xes are defi ned, 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 confi gure two technology prefi x commands on Gatekeeper1. To confi gure a technology prefi x, we use the gw-type-prefix command, followed by the prefi x extension and additional confi guration keywords, as shown in our confi guration:



Gatekeeper1(config-gk)#gw-type-prefix 99# gw ipaddr 10.99.99.1

Gatekeeper1(config-gk)#gw-type-prefix 1# default-technology


Gatekeeper1#

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 specifi cally 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 confi gured, 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.

c10.indd 408c10.indd 408 9/21/11 11:26:30 AM9/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 dif-ferentiate 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 specifi es 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 confi gurations identical to the fi rst, to ensure proper interoperation of H.323 services.

Voice Gateway Interoperation with GatekeepersNow that you’ve learned how to confi gure H.323 gatekeepers on an IP network, we need to shift our focus and explore how to confi gure H.323 voice gateways to interoperate with them. The following confi guration steps are required to register a voice gateway to a gatekeeper:

1. Confi gure the necessary H.323 commands on your designated H.323 signaling interface.

2. Confi gure 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 confi gure 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 confi gured 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 confi guration mode for an interface that has an IP address confi gured. 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 409c10.indd 409 9/21/11 11:26:31 AM9/21/11 11:26:31 AM


id 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 confi gured, the voice gateway will send the GRQ RAS message using multicast.

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

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

Using our network diagram in Figure 10.7, we will confi gure 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 interface

Boston(config-if)#h323-gateway voip id Boston ipaddr 10.99.99.1

Boston(config-if)#h323-gateway voip h323-id Boston

Boston(config-if)#h323-gateway voip tech-prefix 1#

Boston(config-if)#h323-gateway voip tech-prefix 99#

Boston(config)#end

Boston#

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 confi gured 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 confi guration statements should look familiar to you by now. Here is an example of how to confi gure a dial peer on our Boston voice gateway for the Miami and LA extensions:


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 410c10.indd 410 9/21/11 11:26:31 AM9/21/11 11:26:31 AM


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 confi gured 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 confi gurations set on the voice gateway, we must enable the H.323 gateway-to-gatekeeper service, by issuing the gateway global confi guration command. Note that we also include a no shutdown command while in config-gk confi guration mode to bring up the service, as shown here:


Boston(config)#gateway

Boston(config-gk)#no shutdown

Configuring Call Admission Control on H.323 GatekeepersOne 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 confi gure 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 suffi cient bandwidth.

This section shows how to confi gure call-admission control to limit bandwidth used. But before we confi gure 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:

� H.323-enabled voice gateways

� CUCM

� CUCM Business Edition

� CUCM Express

c10.indd 411c10.indd 411 9/21/11 11:26:32 AM9/21/11 11:26:32 AM


The policies that are confi gured 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 defi ne a static number that should take care of any overhead. For example, let’s say that we have fi ve 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 confi gure bandwidth limitations between H.323 zones on a gatekeeper.

Configuring CAC Bandwidth Control on H.323 Gatekeepers

To confi gure 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:

session This keyword defi nes the maximum amount of bandwidth permitted for a single H.323 stream on a zone.

interzone This keyword defi nes the maximum amount of bandwidth allowed between different zones.

total This keyword defi nes the total amount of voice bandwidth permitted (both inter-zone and intrazone) on a zone.

remote This keyword defi nes the total amount of voice bandwidth permitted between gatekeepers in a multi-gatekeeper environment.

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 specifi c bandwidth confi gurations that use the zone keyword, described next. If no specifi c bandwidth confi gurations exist, this default value is used.

c10.indd 412c10.indd 412 9/21/11 11:26:32 AM9/21/11 11:26:32 AM


zone zone-name bandwidth-amount The zone keyword, followed by a previously confi gured zone name and then a bandwidth amount in Kbps, sets the maximum amount of voice bandwidth for a specifi c zone.

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 confi gure zone bandwidth control using the bandwidth command, we will use the gatekeeper-controlled network with three zones depicted in Figure 10.8.

Gatekeeper

V

zone_CV

zone_AV

zone_BV IP WAN

F I GU R E 10 . 8 An H.323 gatekeeper bandwidth-controlled network

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 413c10.indd 413 9/21/11 11:26:33 AM9/21/11 11:26:33 AM


That should give you a solid understanding of H.323 gatekeepers and how to confi gure them. Next, we’ll look at how to verify and troubleshoot H.323 gatekeepers in a network.

Gatekeeper Verification and Troubleshooting CommandsThere are several show and debug commands that will be useful when verifying gatekeeper confi guration 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 confi gured, 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 confi gured locally.

show gatekeeper calls 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:

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 414c10.indd 414 9/21/11 11:26:33 AM9/21/11 11:26:33 AM

Gatekeeper Verification and Troubleshooting Commands 415

CallSignalAddr Port RASSignalAddr Port

10.1.1.100 1720 10.1.1.100 55136

Endpt(s): Alias E.164Addr

dst EP: voice2 4001

CallSignalAddr Port RASSignalAddr Port

10.2.1.101 1720 10.2.1.101 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 Zone Name Type Flags

-------------- ----- -------------- ---- -------- ---- -----

10.1.1.2 1720 10.1.1.2 1719 Zone1 VOIP-GW S

H323-ID: gway1 (static)

10.2.2.2 1720 10.2.2.2 1719 Zone2 VOIP-GW S

H323-ID: gway2 (static)

Total number of active registrations = 2

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 415c10.indd 415 9/21/11 11:26:33 AM9/21/11 11:26:33 AM


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 ElementDon’t be concerned about the name Cisco Unifi ed 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 IP-to-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 fi nds 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 confi gured to terminate at the CUBE or to fl ow 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 416c10.indd 416 9/21/11 11:26:34 AM9/21/11 11:26:34 AM

Introducing the Cisco Unified Border Element 417

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 addi-tional 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 confi gure 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 confi gure 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 fl ow-through and media fl ow-around, are detailed next.

CUBE

IP voice

network 2

IP voice

network 1

VoIP call leg/

dial peer

VoIP call leg/

dial peer

F I GU R E 10 . 9 CUBE VoIP-to-VoIP dial peers

c10.indd 417c10.indd 417 9/21/11 11:26:34 AM9/21/11 11:26:34 AM


Media Flow-Through

In media fl ow-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 benefi ts:

� IP address hiding for added security

� Prevention of duplicate network address spaces between separate networks

Media fl ow-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 fl ow-through between two different VoIP protocols.

While the added benefi ts of IP address hiding and duplicate address protection are useful, the fl ow-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 fl ow-around, that fi xes these problems.

Media Flow-Around

Media fl ow-around does not act as a proxy for voice/video transmissions such as RTP. Instead, the media streams fl ow 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 fl ow-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 fl ow-around between two different VoIP networks.

CUBE

IP WAN

RTP RTP

H.225/

H.245

H.225/H.245

VV

F I GU R E 10 .10 Media flow-through

c10.indd 418c10.indd 418 9/21/11 11:26:35 AM9/21/11 11:26:35 AM


CUBE

RTP

IP WAN

H.225/

H.245

H.225/H.245

VV

F I GU R E 10 .11 Media flow-around

It is important to keep in mind that you must verify that the two networks you are connecting with your CUBE using the media fl ow-around method do not have overlapping IP address space. If that is the case, you’ll need to revert to the default media fl ow-through method.

CUBE Signaling Protocol Interoperation

Now that we’ve determined how we can manipulate the fl ow of media streams, we must next look at the voice signaling protocols that can be implemented on a CUBE to provide interoperating functions. Specifi cally, the CUBE provides interoperation using either SIP or H.323. In Chapter 7 you learned that H.323 can be confi gured with either fast- or slow-start initiation and SIP can be confi gured 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 LE 10 . 2 CUBE signaling interoperation

H.323 fast

H.323-to-SIP

H.323-to-H.323

SIP-to-SIP

H.323 slowH.323 fast

H.323 slow

SIP early

SIP delayedSIP early

SIP delayed

H.323 fast

SIP delayedSIP early

H.323 slow

c10.indd 419c10.indd 419 9/21/11 11:26:35 AM9/21/11 11:26:35 AM


CUBE RSVP-CAC

Earlier in this chapter, you learned how to confi gure CAC on H.323 gatekeepers. While this static method of bandwidth control does work, it’s not very fl exible. Resource Reservation Protocol (RSVP)–based CAC, on the other hand, can be confi gured between two CUBE routers to provide a much more intelligent method of bandwidth control between two Cisco Unifi ed 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 flow-around 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.

CUBE 1Gateway1

5. H.225 call setup

2. RSVP request

1. H.225 call

setup

3. RSVP confirm

Called party

phone

Called party

phone

Gateway2CUBE 2

VV

4. H.225 call setup

F I GU R E 10 .12 RSVP-CAC signaling

c10.indd 420c10.indd 420 9/21/11 11:26:36 AM9/21/11 11:26:36 AM


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 fl ow from end to end.

CUBESIP

H.225/H.245

CUCM

Express

V

PSTN

ITSP

SCCP

MInternet

F I GU R E 10 .13 CUBE network call flow to a SIP ITSP

Don’t forget that if the SIP ITSP uses only the early-offer method, your H.323 session must be confi gured for fast start. And if SIP late-offer is confi gured between the SIP ITSP and CUBE, then H.323 slow-start initiation must be used. Also remember that media fl ow-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 421c10.indd 421 9/21/11 11:26:37 AM9/21/11 11:26:37 AM


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 confi gured 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 confi gure a CUBE in various network topologies.

Configuring the CUBEIn this section, you’ll see how to confi gure 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 fi rst get into conf-voi-serv confi guration mode by issuing the voice service voip command. Once there, you use the allow-connections command, followed by the protocol interoperation you want to use on your CUBE. This is accomplished by fi rst 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

CUBESIP

H.225/H.245

CUCM

Express

V

VV

PSTN

ITSP

Remote-GK

Remote zone RAS

Admission

RAS

Local-GK

SCCP

MInternet

F I GU R E 10 .14 CUBE network call flow through a gatekeeper

c10.indd 422c10.indd 422 9/21/11 11:26:37 AM9/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 confi gure 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.

CUBE

SIP

ntetwork

Bidirectional communication

H.323

network

F I GU R E 10 .15 An H.323-to-SIP network

We want either network to be able to initiate calls that terminate on the other side, so we must confi gure 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 fl ow-through behavior, which forces all media fl ows 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 fl ow behavior to fl ow-around. Let’s say you have a SIP-to-SIP network interconnected with a CUBE. You want to modify the media fl ow to use the fl ow-around method. There are three ways of confi guring this:

� At a global level

� At a voice-class level

� At a dial peer level

In this example, we will confi gure media flow-around on VoIP dial peer 111:


CUBE(config)#dial-peer voice 111 voip

CUBE(config-dial-peer)#media flow-around

CUBE(config-dial-peer)#end

CUBE#

c10.indd 423c10.indd 423 9/21/11 11:26:38 AM9/21/11 11:26:38 AM


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 confi gure codec transparency on VoIP dial peer 111:


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 confi guring an H.323-to-H.323 network, you need to decide how to handle the H.323 initiation process. This behavior can be modifi ed while in conf-serv-h323 configuration mode by using the call start command, followed by one of these keywords:

fast This command forces all H.323 dial peers to use H.323v2 fast-start initiation. This is the default CUBE setting for H.323.

slow This command forces all H.323 dial peers to use H.323v1 slow-start initiation.

interwork 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 confi gure this, Figure 10.16 illustrates a network that requires an H.323 fast-to-slow-start setup.

CUBE

H.323

network

Fast-start

H.323

network

Slow-start

F I GU R E 10 .16 H.323 fast-to-slow start

Focusing on CUBE1, we’ll fi rst confi gure H.323-to-H.323 protocol interoperation and then enable fast-to-slow-start signaling, as shown here:

c10.indd 424c10.indd 424 9/21/11 11:26:38 AM9/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 confi gure 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 modifi ed to use either early- or delayed-offer signaling when operating a SIP-to-SIP network. You can confi gure 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 confi gured on this CUBE will participate in early- to late-offer early-media negotiations.

CUBE Verification and Troubleshooting CommandsTo 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.

show call active voice brief 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:

CUBE#show call active voice brief

-output cut

Telephony call-legs: 0

c10.indd 425c10.indd 425 9/21/11 11:26:39 AM9/21/11 11:26:39 AM


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 fl ow-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 fl ow settings. In this example, you see output showing that the H.323 incoming call leg is set to use the fl ow-through media stream method:

c10.indd 426c10.indd 426 9/21/11 11:26:39 AM9/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 fl ow-through method, the debug output will show Flow Mode=1.

SummaryThis 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 confi gure 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 EssentialsKnow 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 confi gured and sent as a unicast GRQ RAS message, or if not statically confi gured, 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 confi gured between a voice gateway and their local gatekeeper.

Know where remote zones reside in an H.323 environment. Remote zones are the zones confi gured on a gatekeeper other than the local gatekeeper.

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 427c10.indd 427 9/21/11 11:26:39 AM9/21/11 11:26:39 AM


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 config-dial-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. The CUBE is primarily used for IP-to-IP gateway connections.

Know the four possible CUBE voice gateway signaling scenarios. They are: SIP-to-SIP, H.323-to-H.323, SIP-to-H.323, and H.323-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 fl ows.

Know the pros and cons of media flow-through. Media fl ow-through offers IP address hiding and prevention of duplicate network address schemes. The downside is that all media fl ows must terminate at the CUBE and therefore increase CPU and bandwidth load.

Know the pros and cons of media flow-around. Media fl ow-around allows the media fl ow 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.11. What config-gk confi guration mode command assigns zoneA in domain example.com

as a local zone?

2. What config-gk confi guration 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 confi guring dial peers for voice gateways in a gatekeeper-controlled network, how do you confi gure the dial peer to fi nd the next-hop IP address from the gatekeeper when in config-dial-peer confi guration mode?

6. What gatekeeper verifi cation command lets an administrator view communication messages between itself and other H.323 components in real time?

c10.indd 428c10.indd 428 9/21/11 11:26:40 AM9/21/11 11:26:40 AM

Hands-On Labs 429

7. You are confi guring a CUBE for bidirectional communication between SIP and H.323 networks. You have already confi gured H.323-to-SIP communications. What conf-voi-serv command is used to allow SIP-to-H.323 communications?

8. You are confi guring a CUBE VoIP dial peer and don’t want the media fl ow to be prox-ied. What config-dial-peer command is used to do this?

9. You have a CUBE confi gured 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 fl ow-through proxy. What command can be used to view active RTP sessions?


Hands-On LabsTo 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 confi gure 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.

Zone: Glasgow

Glasgow_gw1

5554XXX

S0/0V

Zone: London

London_gw1

GB_Gatekeeper_1

Domain: example.com

Dub_Gatekeeper_1

5553XXX

S0/0V

V

Zone: Dublin

IP WAN

5555XXX

Default

tech prefix:

1#

10.88.88.1 10.77.77.1

VDublin_gw1

V

F I GU R E 10 .17 H.323 Gatekeeper lab diagram

c10.indd 429c10.indd 429 9/21/11 11:26:40 AM9/21/11 11:26:40 AM


These labs build on each other, so it is best to perform them in the order listed:

Lab 10.1: Confi guring GB_Gatekeeper_1

Lab 10.2: Confi guring London_gw1 and Glasgow_gw1

Hands-On Lab 10.1: Configuring GB_Gatekeeper_1

In this lab, we assume that GB_Gatekeeper_1 is preconfi gured on the WAN except for the gatekeeper-specifi c settings. It is our responsibility to confi gure 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.


3. Enter into config-gk confi guration mode by typing gatekeeper.

4. Confi gure 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. Confi gure the Glasgow zone as a local zone by typing zone local Glasgow example.com.

6. Confi gure the Dublin zone as a remote zone by typing zone remote Dublin example.com 10.77.77.1.

7. Confi gure the local zone prefi x for the London zone to be 5553… by typing zone prefix London 5553...

8. Confi gure the local zone prefi x for the Glasgow zone to be 5554… by typing zone prefix London 5554...

9. Confi gure the gatekeeper to be the default technology prefi x when users key in extension 1# by typing gw-type-prefix 1# default-technology.

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 preconfi gured on the WAN except for the gatekeeper-specifi c settings and dial peers. We must confi gure the voice gateway to communicate with a gatekeeper, confi gure the VoIP dial peer pointing to the gatekeeper, and set the default technology prefi x we have set up on our gatekeeper.

1. Log into London_gw1 and go into privileged exec mode by typing enable.


c10.indd 430c10.indd 430 9/21/11 11:26:41 AM9/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. Confi gure a VoIP dial peer (dial peer 555) by typing dial-peer voice 555 voip.

10. Confi gure a destination pattern to match all seven-digit numbers beginning with 555 by typing destination pattern 555...

11. Confi gure the dial peer to use the default technology prefi x that our gatekeeper is con-fi gured for by typing tech-prefix 1#.

12. Confi gure the dial peer to look to the gatekeeper for next-hop call-routing information by typing session target ras.

13. Exit config-dial-peer confi guration 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 431c10.indd 431 9/21/11 11:26:41 AM9/21/11 11:26:41 AM


Review Questions1. Which of the following is not a mandatory H.323 gatekeeper feature?

A. Zone management

B. Address translation

C. Call authorization

D. Admission control

2. What does H.323 address translation accomplish?

A. Translates IP addresses into physical interface ports

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

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

C. RCF

D. RRJ

4. What are the two options that can be used with voice gateways to discover a local H.323 gatekeeper?

A. Using a broadcast message

B. Using a static IP address

C. Using a multicast message

D. Using a MAC address message

5. RAS location messages are sent and received between what two devices?

A. A gatekeeper and an MCU

B. A gateway and a gatekeeper

C. A gatekeeper and any H.323 compatible endpoint

D. Between two gatekeepers

E. Between two MCU’s

c10.indd 432c10.indd 432 9/21/11 11:26:42 AM9/21/11 11:26:42 AM


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

B. RRJ

C. BCF

D. RAI

7. What IOS command mode must an administrator be in to configure H.323 zones on a gatekeeper?

A. config-if

B. config-voi-serv

C. config-gk

D. config-h323-gk

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

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

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

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.

c10.indd 433c10.indd 433 9/21/11 11:26:42 AM9/21/11 11:26:42 AM


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


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


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.

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.

c10.indd 434c10.indd 434 9/21/11 11:26:43 AM9/21/11 11:26:43 AM


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.

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.

c10.indd 435c10.indd 435 9/21/11 11:26:43 AM9/21/11 11:26:43 AM


Answers to Review Questions1. C. Call authorization is an H.323 feature that can be optionally confi gured, while the

other three features are mandatory when confi guring 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 confi guring 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 confi gured while in config-gk mode on a gatekeeper.

8. B. 10.101.13.99 is the IP address of the gatekeeper you are currently confi guring. It signifi es that this is the IP that will be used to source RAS messages. This command can only be entered on a single zone-confi guration command, but it is then used for all confi gured zones.

9. C. Remote zones are confi gured while in config-gk confi guration mode, and the proper syntax is zone remote zoneA example.com 192.168.1.1.

10. B. Given the confi guration information in the question, the gatekeeper manages the Denver and Seattle zones locally.

11. D. When you are confi guring 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 confi guration 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 traffi c to 1024 Kbps.

16. B. Media fl ow-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 436c10.indd 436 9/21/11 11:26:44 AM9/21/11 11:26:44 AM

18. A, D. A CUBE can be confi gured to interoperate between a SIP early offer to H.323 fast-start initiation process or a SIP delayed offer to H.323 slow-start process only.

19. C. To access conf-voi-serv confi guration 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 confi gured for the fl ow-through method.


c10.indd 437c10.indd 437 9/21/11 11:26:44 AM9/21/11 11:26:44 AM


Answers to Written Lab 10.11. 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 438c10.indd 438 9/21/11 11:26:44 AM9/21/11 11:26:44 AM

Introduction to Quality of Service


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.

�

�

Chapter

11

c11.indd 439c11.indd 439 9/21/11 11:27:09 AM9/21/11 11:27:09 AM

As soon as IP networks were designed and implemented with suffi cient 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 traffi c 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 traffi c 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. Specifi cally, 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, “Confi guring Quality of Service,” we’ll move on to the “how” of QoS on IP networks as we explore confi guring various QoS scenarios.

Problems with Voice/Video on IP NetworksTo 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 fl ow

� Time-fl exible transmissions

� No one application or data fl ow with higher priority than another on shared links

� The ability to recover in the event of packet drops

As you can see, most data traffi c 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 440c11.indd 440 9/21/11 11:27:10 AM9/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 fl ows just described. Now a network must also provide mechanisms to carry traffi c with these characteristics:

� Small packet payloads

� Continuous transport fl ow

� Time-sensitive payloads

� A way to defi ne some data fl ows 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 modifi cations to ensure that voice/video traffi c does not suffer on an IP network. We’ll look at those factors in the next section.

Mitigating IP Network Voice IssuesNow 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 time-sensitive data can properly be transported in a reliable and effi cient manner. There are four primary issues to address:

� Providing suffi cient 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 confi gurations 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:

� Number of users

� Internal versus external calling

� Remote site bottlenecks

c11.indd 441c11.indd 441 9/21/11 11:27:10 AM9/21/11 11:27:10 AM

442 Chapter 11 ■ 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 traffi c. Table 11.1 describes the advantages of each. Again, you’ll learn how to implement these techniques in Chapter 12.

TA B LE 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 time-sensitive 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 specifi ed 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 442c11.indd 442 9/21/11 11:27:11 AM9/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 traffi c, it begins placing packets into an output queue buffer in the hope that traffi c will eventually die down and the network device can catch back up. If the traffi c 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 briefl y 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 GU R E 11.1 Network bottleneck

1000 Mbps1000 Mbps

1000 Mbps 1000 Mbps

Possible

bottleneck

45 Mbps

VVIP WAN

c11.indd 443c11.indd 443 9/21/11 11:27:11 AM9/21/11 11:27:11 AM


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 identifi ed 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 fi rst 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 confi guration 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 traffi c priority on the network to limit delay, jitter, and packet loss. Next, we can confi gure link effi ciency and compression techniques to lower our bandwidth utilization footprint. While link effi ciency and compression isn’t technically QoS, it is good to combine the two methods because they can help signifi cantly reduce bandwidth utilization and ultimately move traffi c across a network with less latency and packet drops. We’ll begin by covering QoS.

The Three-Step QoS ProcessSo 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 fl ows. While our best-effort design may work well for data, voice traffi c 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. Traffi c classifi cation

2. Traffi c marking

3. Traffi c queuing

Traffic Classification

Traffi c classifi cation is the process of identifying traffi c based on different characteristics in order to group the same traffi c types together for QoS. The identifi cation process must be performed fi rst because the equipment must be able to clearly identify certain traffi c.

c11.indd 444c11.indd 444 9/21/11 11:27:12 AM9/21/11 11:27:12 AM

QoS Policy Considerations 445

Creating voice VLANs makes it easy to identify voice traffi c, because we can assume that any packets on the voice VLAN should be classifi ed as such.

Traffic Marking

Traffi c marking is the process of fl agging critical packets so that the rest of the network can properly identify them and give them priority over all other traffi c. 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 fi eld within the Layer 2 Ethernet frame header that marks traffi c as being one of eight (0 to 7) classes. The higher the CoS value, the more priority is given. By default, voice traffi c is marked with a classifi cation 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 fi eld, 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

Traffi c queuing is the process of ordering certain types of traffi c for transport over LAN/WAN interfaces. Queues are logical storage devices that can be used for egress interface traffi c. Egress basically means that the traffi c is exiting the interface as opposed to coming into it. Queuing for ingress traffi c is not possible, because no queues are available. There are several queuing techniques, discussed under “Congestion Management,” later in this chapter.

QoS Policy ConsiderationsWith every managed network, there are network providers and network customers or users. When confi guring 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 traffi c type or application used.

The Three-Step QoS Policy Development Process

The construction of a QoS policy consists of the following three steps:

1. Consider the traffi c 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.

c11.indd 445c11.indd 445 9/21/11 11:27:12 AM9/21/11 11:27:12 AM


2. Put your various traffi c types into categories based on network requirements. The more sensitive the traffi c 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 traffi c fi ts into the QoS policy structure. Additionally, explain why some traffi c is given priority over others. In this way, your network becomes highly transparent to end users, so they understand why some traffi c 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 confi guring QoS policies on Cisco hardware. Following are the three primary methods of confi guring 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 confi gure 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 confi guring QoS using the command line requires many steps on multiple interfaces of your hardware. This often led to misconfi guration errors on the equipment, which in turn often led network administrators to scrap QoS confi gurations altogether. But if you know what you are doing and you like the fl exibility, the CLI is certainly an option for QoS.

AutoQoS

To help simplify the QoS confi guration process as well as help eliminate misconfi gurations, 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 confi guration options to choose from, depending on your network type and the device(s) connected to the interface being confi gured. The standard Cisco AutoQoS for VoIP is used to confi gure 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 confi guration across common WAN interfaces such as serial, Frame Relay, and ATM circuits. We will use AutoQoS for basic QoS confi guration in Chapter 12.

c11.indd 446c11.indd 446 9/21/11 11:27:13 AM9/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-specifi c CLI commands, a network administrator can construct a single QoS module on the IOS router or switch. Once that module has been confi gured, it can then be applied to any interface on that hardware. This gives us a highly fl exible and robust QoS confi guration system that eases confi guration and management issues.

MQC has a modular three-step hierarchical structure when confi guring a module:

1. Confi gure a traffi c class that is used to identify a priority of network traffi c such as voice.

2. Create a traffi c policy that defi nes the amount of network resources that should be reserved. The traffi c class is assigned to a traffi c policy.

3. Assign the traffi c policy to the appropriate network interface.

Chapter 12 also demonstrates using MQC for class-based QoS confi guration.

QoS Classification ModelsWe 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 traffi c 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 traffi c is considered to be best-effort, meaning that there is no guarantee that the packets will be delivered. Additionally, all traffi c 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 specifi c types of traffi c from end to end. IntServ provides these guarantees by reserving a dedicated amount of bandwidth to specifi c traffi c. Once that traffi c has been reserved, it is set aside to be used only by the intended traffi c regardless of all other traffi c. This bandwidth guarantee is why the IntServ model is often referred to as hard QoS. In a way,

c11.indd 447c11.indd 447 9/21/11 11:27:13 AM9/21/11 11:27:13 AM


IntServ carves out its own connection for specifi ed traffi c, 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 traffi c might be confi gured 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 specifi c fl ow type must have its own bandwidth reservation. That is why only the most critical applications are confi gured with IntServ. Considering that you may have hundreds or even thousands of different data fl ows, it would be impossible to confi gure 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 classifi cation the packets should be given along the path. This classifi cation is then used along the entire path of the traffi c stream to reserve a set amount of bandwidth.

While it is true that IntServ provides an absolute guarantee of bandwidth for specifi c applications, there are some major drawbacks. For one, IntServ must be confi gured at every Layer 3 device along the path of the traffi c fl ow. Because of this requirement, IntServ does not scale well. Second, when bandwidth is reserved and not in use, no other traffi c 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 traffi c. 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 classifi es (differentiates) IP traffi c fl ows and marks them for use on other QoS-aware devices along the traffi c fl ow path. This is similar to the IntServ model in terms of classifi cation. DiffServ can group together multiple data-fl ow types into a single group, however. This helps tremendously with confi guration scalability.

Another difference from IntServ is that DiffServ does not make an explicit reservation along the path for classifi ed traffi c. Instead, the DiffServ marking is used along each hop of the path that traffi c takes. Each hop could potentially give the traffi c 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 confi gured so that service is nearly guaranteed. Additionally, bandwidth is never set aside for one specifi c type of bandwidth, so a network can be more cost-effective.

c11.indd 448c11.indd 448 9/21/11 11:27:14 AM9/21/11 11:27:14 AM


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 benefi ts 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 LE 11. 2 The three QoS models compared

Model Pros Cons

Best-effort Highly scalable No traffic differentiation

No configuration required No service guarantee

IntServ 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

DiffServ Highly scalable Attempted service guarantee but not absolute

Highly granular Mildly complex to configure

Understanding the DiffServ ToS/DS Byte

DiffServ uses a traffi c-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. Specifi cally, IP Precedence uses the 3 leftmost bits of the ToS, as shown in Figure 11.2.

c11.indd 449c11.indd 449 9/21/11 11:27:14 AM9/21/11 11:27:14 AM


F I GU R E 11. 2 IP Precedence and the ToS byte

ToS byte

0 1 2

IP precedencebits

Unused

3 4 5 6 7

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 traffi c such as routing protocols. That means there are six categories that a network administrator can prioritize traffi c into. The higher the IP Precedence, the more preferred the traffi c 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 LE 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 traffi c fl ows 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 450c11.indd 450 9/21/11 11:27:15 AM9/21/11 11:27:15 AM


DSCP

The Differentiated Services Code Point (DSCP) method effectively replaces IP Precedence and is defi ned in RFC 2474. It uses a 6-bit fi eld 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 confi gure similar behavior fl ows to operate inside various classes. These similar fl ows 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 notifi cation (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 GU R E 11. 3 DSCP and the DS byte

DS byte

0 1 2

DSCP bits ECN bits

3 4 5 6 7

Now network administrators could theoretically have up to 64 different priority markings if they choose. This made DSCP almost too fl exible, 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 451c11.indd 451 9/21/11 11:27:15 AM9/21/11 11:27:15 AM


HTTP, and other noncritical and non-delay-sensitive data fl ows. 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 fl ows that require low latency, packet loss, and jitter. These characteristics are ideal for real-time traffi c such as voice and video, and therefore most voice traffi c is tagged with EF PHB. Using the 6 bits of the DSCP fi eld, 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 LE 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 LE 11.5 AF PHB binary values

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

c11.indd 452c11.indd 452 9/21/11 11:27:16 AM9/21/11 11:27:16 AM


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

� Traffi c policing and shaping

� Link effi ciency

In the next few sections, we will detail what each of these features can do for priority traffi c fl ows.

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 fi rst and which ones have to stay a longer period of time. This is where classifi cation and marking of packets comes into play. Once you can classify traffi c fl ows 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 453c11.indd 453 9/21/11 11:27:17 AM9/21/11 11:27:17 AM


Priority Queuing Priority queuing (PQ) is a strict queuing mechanism that is used to give explicit priority to certain traffi c types. These traffi c types can be divided into categories such as protocol type, source/destination IP, packet size, and incoming interface. PQ can place traffi c 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 traffi c 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 confi gured by the network administrator. The more preferred a class is, the more queue slots it is given. The queued traffi c 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 traffi c 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 round-robin 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 traffi c based on data fl ows. 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 fi eld. WFQ then places the categorized traffi c into either high- or low-bandwidth traffi c. Low-bandwidth traffi c fl ows 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 traffi c 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 fl ow level but based on all the fl ows within a

c11.indd 454c11.indd 454 9/21/11 11:27:17 AM9/21/11 11:27:17 AM


class. CBWFQ is very fair, but this fairness can sometimes prevent sensitive voice or video traffi c 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 fl ows instead of specifi c traffi c types. LLQ is perfect for voice and video because it allows an administrator to confi gure voice and video fl ows in a high-priority class. This class can then be confi gured for a strict queuing priority to ensure preferential treatment. Other traffi c 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 specifi c 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 specifi cally to service real-time traffi c.

Congestion Avoidance

Sometimes an interface’s queue gets fi lled 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 traffi c 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 congestion-avoidance 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 fi rst. 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 fi rst, triggering the host to temporarily slow down its transmissions.

WRED is ideal in bottleneck situations and is commonly confi gured on WAN interfaces, which are likely to be slower than LAN interfaces.

Traffic Policing and Shaping

Traffi c policing and shaping is all about setting maximum limits for classes of traffi c. This approach is in contrast to setting a minimum value. Traffi c shaping and policing is

c11.indd 455c11.indd 455 9/21/11 11:27:18 AM9/21/11 11:27:18 AM


also known as traffi c conditioning, because you condition your traffi c not to overreach its bandwidth boundaries.

Traffic Policing Traffi c policing is the more hard core of the two traffi c-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 confi gured policing maximum level, the packets are dropped or marked, based on confi guration 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 GU R E 11. 4 Traffic policing

Time

Dropped traffic

Maximumrate

Tra

ffic

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 traffi c-policing method that limits traffi c 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 traffi c on information such as DSCP values, class maps, and Layer 2 CoS as well as the same criteria that CAR matches on.

Traffic Shaping Traffi c shaping buffers data into queues. Because queuing techniques are only used outbound on interfaces, traffi c shaping can only be applied outbound. Also, because queues are used with traffi c shaping, those packets that are queued should eventually be transmitted. Therefore, if we graph the same interface data as we did with the traffi c policing, instead of the sawtooth graph, we should see a much smoother traffi c rate, as shown in Figure 11.5.

c11.indd 456c11.indd 456 9/21/11 11:27:18 AM9/21/11 11:27:18 AM


F I GU R E 11.5 Traffic shaping

Time

Maximumrate

Tra

ffic

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 confi guring QoS on your network for voice support, you can use two other link-effi ciency techniques to help with the consistent transport of VoIP. These techniques are compression and link fragmentation and interleaving (LFI). Again, keep in mind that link-effi ciency 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 fi rst 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

Policing vs. Shaping on Low-Speed WAN Connections

Richard was responsible for confi guring 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 traffi c policing in an attempt to proactively avoid congestion. After traffi c 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 traffi c-policing confi guration and instead confi gured traffi c 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 traffi c 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 traffi c 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.

c11.indd 457c11.indd 457 9/21/11 11:27:19 AM9/21/11 11:27:19 AM


fi xed-bandwidth link. Cisco router hardware commonly uses two forms of payload compression. The fi rst 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 confi gured on serial interfaces, as shown in Figure 11.6.

F I GU R E 11.6 An example of compression

Router-BRouter-A

T1 PPP

S1/0S1/0

cRTP compression

In general, compression should be used only on low-speed WAN links where potential bottlenecks exist. Otherwise, the benefi t 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 confi gured separately.

Link Fragmentation Interleaving

A second link-effi ciency 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 458c11.indd 458 9/21/11 11:27:19 AM9/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 traffi c. 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 signifi cantly cuts down on voice jitter. In Chapter 12 we will confi gure the two most commonly implemented LFI mechanisms, MLP LFI and FRF.12, for Frame Relay connections.

Layer 2 Class of Service and QoS Trust BoundariesThis 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 fi eld 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 classifi cation 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 confi gure 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 fi eld 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 GU R E 11.7 CoS bits in an 802.1Q frame header

Preamble DA SA

3 Bits of the TCIare for CoS

TCI FCSPT DataStart framedelimiter

c11.indd 459c11.indd 459 9/21/11 11:27:20 AM9/21/11 11:27:20 AM


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 fi eld) priorities. Remember that Cisco IP phones transport data in 802.1Q frames, so they can place voice traffi c 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 GU R E 11. 8 IP phone 802.1Q tags

SwitchFa0/5 Trunk link

Cisco phone

PC

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 traffi c to a single queue. Alternatively, an egress port can be confi gured to place traffi c into one of four queues where frames are placed into a queue. The de-queuing mechanism can be confi gured 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 traffi c 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 traffi c 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 confi gure the trust boundary at the Distribution layer. Figure 11.9 illustrates where trust boundaries can be implemented within a typical network.

c11.indd 460c11.indd 460 9/21/11 11:27:21 AM9/21/11 11:27:21 AM

QoS Baseline Models 461

F I GU R E 11. 9 Trust boundaries

Si

Trust at

Distribution layerTrust at

Access layerTrust cisco

phonesTrust any

endpoint

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 ModelsWhen 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 classifi cation 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 461c11.indd 461 9/21/11 11:27:22 AM9/21/11 11:27:22 AM


F I GU R E 11.10 The Cisco QoS baseline model compared with 5- and 8-class models

Voice

Cisco QoS

baseline

8-Class

model

5-Class

model

Video conf

Call signaling

Video stream

Routing

Network mgmt

Critical

Transactional

Bulk data

Best-effort

Scavenger Scavenger Scavenger

Voice

Real-Time

Call signalingCall signaling

Network

control

Critical dataCritical data

Bulk data

Best-effort Best-effort

Network

control

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

c11.indd 462c11.indd 462 9/21/11 11:27:22 AM9/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 classifi cation 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 classifi cation 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 confi gurations.

TA B LE 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 confi gurations, such as voice, include call admission control. CAC is used to ensure that only a specifi ed number of simultaneous calls can be made. This is typically done on WAN interfaces that may be a possible bottleneck.

c11.indd 463c11.indd 463 9/21/11 11:27:23 AM9/21/11 11:27:23 AM


SummaryThis 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 traffi c classifi cation, 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 confi guring QoS on Cisco routers and switches.

Exam EssentialsUnderstand how to resolve potential problems with voice/video on IP networks. Time-sensitive traffi c such as voice and video can suffer from delay, jitter, and packet loss. To resolve these problems, network administrators should provide suffi cient bandwidth, eliminate bottlenecks, use QoS to prioritize traffi c, and use link-effi ciency techniques to reduce bandwidth requirements.

Understand the three-step QoS process. QoS can be broken down into three steps. First is the classifi cation of data. Next is the marking of classifi ed traffi c. And the third is using interface queuing techniques on marked traffi c.

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 confi gure 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 classifi cation models with which to categorize traffi c. 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 traffi c.

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 464c11.indd 464 9/21/11 11:27:23 AM9/21/11 11:27:23 AM

Written Lab 11.1 465

Know the four DiffServ quality features. DiffServ can be confi gured for the following quality features: congestion management, congestion avoidance, traffi c policing/shaping, and link effi ciency techniques.

Understand CoS markings. Class of Service markings are 3 bits contained with Layer 2 Ethernet frames that can be used for marking traffi c 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 traffi c be classifi ed into 11 specifi c groups based on traffi c type and sensitivity to delay.

Written Lab 11.11. Of all the possible methods used to prevent delay problems on time-sensitive IP traffi c,

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 confi guration structure?

4. Which QoS classifi cation model is also called soft QoS?

5. When using IP Precedence, what is voice traffi c commonly marked as?

6. When using DSCP, what is voice traffi c 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 traffi c policing and traffi c shaping is that traffi c policing drops packets outright instead of using what?

10. A Cisco Catalyst switch operating at Layer 2 can understand which type of QoS markings?


c11.indd 465c11.indd 465 9/21/11 11:27:24 AM9/21/11 11:27:24 AM


Review Questions1. Which of the following is not a characteristic of voice traffic on an IP network?

A. Small packet payloads

B. Time sensitive

C. Sensitive to compression

D. Sensitive to packet loss

2. What type of delay should a network administrator focus most on reducing using QoS mechanisms?

A. Fixed delay

B. Variable delay

C. Compression delay

D. Signaling delay

3. What is another name for an occurrence when an output interface queue fills up and begins discarding packets?

A. Delay

B. Jitter

C. Frame overflow

D. Tail drop

4. Which of the following is not a reason for packet loss on a router interface that has limited bandwidth?

A. Input queue drops

B. Tail drops

C. DSCP marking of 0

D. CRC errors

5. Which QoS classification model uses either the ToS or DS byte to mark packets?

A. DiffServ

B. IntServ

C. Best-effort

D. Both IntServ and DiffServ

6. IP Precedence marking uses which bits of the ToS IP header field?

A. The 6 leftmost bits

B. The 4 leftmost bits

C. The 3 leftmost bits

D. The 4 rightmost bits

c11.indd 466c11.indd 466 9/21/11 11:27:24 AM9/21/11 11:27:24 AM


7. According to best-practice strategies, network administrators can use IP Precedence to classify traffic into how many different groups?

A. 6

B. 7

C. 8

D. 46

8. What is the decimal equivalent to the AF binary value11?

A. 8

B. 10

C. 36

D. 46

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

B. Traffic shaping

C. RED

D. Traffic policing

c11.indd 467c11.indd 467 9/21/11 11:27:24 AM9/21/11 11:27:24 AM


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

B. AF41, 46, and 7

C. EF, 46, and 5

D. AF41, 42, and 5

E. AF41, 46, and 1

c11.indd 468c11.indd 468 9/21/11 11:27:25 AM9/21/11 11:27:25 AM


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

B. Transactional

C. Scavenger

D. Call signaling

c11.indd 469c11.indd 469 9/21/11 11:27:25 AM9/21/11 11:27:25 AM


Answers to Review Questions1. C. Voice traffi c 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 traffi c.

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

5. A. Of the three QoS classifi cation 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 traffi c and therefore should not be used. Therefore, there are six available classes to group traffi c under.

8. B. AF11 is equivalent to 10 in decimal.

9. C, D. Voice traffi c is commonly classifi ed 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 traffi c. All other traffi c 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 traffi c policing. CAR is the older method, used for legacy traffi c, and class-based is the newer method that is commonly implemented in new installations.

14. B. Traffi c policing will drop packets outright, whereas traffi c shaping places them into queues. While voice or video packets may be delayed, it’s better than not getting the packet at all. Traffi c 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 470c11.indd 470 9/21/11 11:27:25 AM9/21/11 11:27:25 AM

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 traffi c into one of the 11 different class categories. Depending on your network size and traffi c types, not all classes need to be used.

18. C. According to the Cisco QoS baseline model, voice traffi c 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 traffi c is recommended to have no bandwidth guarantee at all.


c11.indd 471c11.indd 471 9/21/11 11:27:26 AM9/21/11 11:27:26 AM


Answers to Written Lab 11.11. Increasing bandwidth

2. Traffi c classifi cation, traffi c marking, and traffi c 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 472c11.indd 472 9/21/11 11:27:26 AM9/21/11 11:27:26 AM

Configuring Quality of Service


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.

■ Enable QoS mechanisms on switches using AutoQoS.

■ Configure Low Latency Queuing.

�

Chapter

12

c12.indd 473c12.indd 473 9/21/11 11:27:51 AM9/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 traffi c fl ow, set policies, and apply them to interfaces. In addition, we will look at how to confi gure class-based link effi ciency techniques, traffi c policing and shaping, trust boundaries, and Layer 2 to Layer 3 mapping modifi cations. At the end of this chapter, you should have a solid understanding of how to confi gure key QoS components as well as how to verify their operation.

Configuring QoS Policies Using AutoQoSIf 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 verifi cation of interface types and link speeds. The AutoQoS confi guration 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 confi gurations are uniform on all network equipment.

AutoQoS can be confi gured on both routers and switches, although their confi gurations 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 confi gured on WAN interfaces that may be bottlenecks at some point along a path. AutoQoS may confi gure the following features on WAN interfaces:

� Automatic classifi cation of RTP, cRTP, and voice gateway signaling protocols (SCCP, H.323, SIP, MGCP)

� Automatic building of service policies for priority traffi c

� LLQ implementation for high-priority traffi c

� Traffi c shaping where appropriate

� Link fragmentation where appropriate

� cRTP compression where appropriate

c12.indd 474c12.indd 474 9/21/11 11:27:53 AM9/21/11 11:27:53 AM

Configuring QoS Policies Using AutoQoS 475

The automatic classification function within AutoQoS uses the Network-Based 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 confi gured 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 confi guring 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 traffi c for voice. It can be confi gured on either routers or switches. Larger networks with a substantial number of remote site WAN connections may benefi t from additional prioritization for traffi c 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 fi t. Note that QoS for the Enterprise can be confi gured only on routers and not switches. We’ll start by going through the AutoQoS for VoIP confi guration for both routers and switches followed by confi guring AutoQoS for the Enterprise, while pointing out differences between the two implementation methods along the way.

Configuring AutoQoS for VoIP on a Router

Confi guring AutoQoS on routers is truly a magical thing to see. It seems magical because AutoQoS intelligently recognizes a network setup and appropriately confi gures 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 475c12.indd 475 9/21/11 11:27:53 AM9/21/11 11:27:53 AM

476 Chapter 12 ■ 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 confi gure AutoQoS for VoIP on a router, we will use Figure 12.1 as our example network.

F I GU R E 12 .1 AutoQoS for VoIP on a router

CUCM

Express

S0/0

256 KbpsSwitch SwitchRouter-A Router-B

S0/0

We will confi gure the interface serial 0/0 of Router-A shown in the diagram. To show you what AutoQoS for VoIP will confi gure for our particular router, here is the current confi guration 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 confi gure 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 confi guration for this interface. The number of actual confi gurations made is fairly staggering. But don’t take my word for it: you can use

c12.indd 476c12.indd 476 9/21/11 11:27:54 AM9/21/11 11:27:54 AM


the show auto qos command on Router-A to see exactly what the router chose to confi gure 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



!

c12.indd 477c12.indd 477 9/21/11 11:27:54 AM9/21/11 11:27:54 AM


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 confi guration on Router-A now consists of the following:

� Policy maps and class maps to classify and mark our voice and voice-related traffi c

� Access lists for VoIP RTCP and control packets

� RMON settings to trigger alerts via SNMP based on thresholds

� A PPP multilink confi guration on the serial 0/0 interface along with LFI confi gurations

� Compressed RTP confi guration 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 confi gured four different classes with which to mark packets and enforce policy. Specifi cally, our voice (RTP) traffi c 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 478c12.indd 478 9/21/11 11:27:55 AM9/21/11 11:27:55 AM


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 confi gure switches.

Configuring AutoQoS for VoIP on a Switch

There are only three options for confi guring AutoQoS on a switch interface using the auto qos voip command. Once you understand these three options, confi guring QoS on your Cisco Catalyst will be a snap! Here is the output of the switch when confi guring 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:

cisco-phone 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 classifi cation for its traffi c. 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-softphone 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 identifi ed as a Cisco phone.

trust The trust option basically means that the switch will trust any CoS/ToS value received and treat the traffi c accordingly. Be cautious when confi guring this on access ports, because people “in the know” can manipulate the classifi cation markings of data traffi c on their PCs and have their data sent as priority traffi c when it should be treated as normal traffi c. 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 confi guring QoS on a production network. Assume that the Sales, Marketing, Management, and Voice VLANs are preconfi gured on the network. Switchport Fa0/5 is confi gured to use VLAN 10 for data and VLAN 100 for voice traffi c. Also assume that 802.1Q trunking is confi gured between the switch and the CUCM Express router.

c12.indd 479c12.indd 479 9/21/11 11:27:55 AM9/21/11 11:27:55 AM


F I GU R E 12 . 2 AutoQoS for VoIP on a switch

CUCM

Express

Fa0/1

802.1Q

Trunk

Trust boundary

Fa0/1 Fa0/5Fa0/5

Switch-A Switch-B

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 confi guration 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-confi guration mode and confi gure AutoQoS to trust Cisco phones attached to Fa0/5.


Switch-A(config)#interface fastEthernet 0/5

Switch-A(config-if)#auto qos voip cisco-phone


Let’s see exactly what AutoQoS has confi gured on our port, using the show run interface fastEthernet 0/5 command a second time:

Switch-A#sh run int fa0/5



!


switchport access vlan 10

c12.indd 480c12.indd 480 9/21/11 11:27:56 AM9/21/11 11:27:56 AM


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 cos-map 1 0 1


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 confi gured all kinds of things on the interface, including trust settings, weighted round-robin (WRR) queuing policies, and priority queuing specifi cally for VoIP traffi c. 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 confi gured using the auto qos voip trust command. To show you what is actually confi gured using the AutoQoS command, we will do a show run interface fa0/1 command to view the initial confi guration settings:

Switch-A#show run interface fa0/1



!


switchport trunk encapsulation dot1q

switchport trunk allowed vlan 10,20,100

switchport mode trunk

Now we will confi gure AutoQoS to trust markings passing through Fa0/1:


Switch-A(config)#interface fastEthernet 0/1

Switch-A(config-if)#auto qos voip trust


c12.indd 481c12.indd 481 9/21/11 11:27:56 AM9/21/11 11:27:56 AM


You can now view our new running confi guration for our switch uplink to see the differences between the auto qos voip trust confi gurations and the auto qos voip cisco-phone output:

Switch-A#show run interface fa0/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 cos-map 3 3 6 7

wrr-queue cos-map 4 5

priority-queue out

Notice that from a QoS confi guration standpoint, the only difference between the trust and cisco-phone confi guration is the auto qos voip trust command.

After confi guring AutoQoS for VoIP on the switch, you will also fi nd a couple of global confi gurations in the running confi guration shown here:

Switch-A#show run | include mls qos


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 482c12.indd 482 9/21/11 11:27:56 AM9/21/11 11:27:56 AM


The confi guration of the opposite-end switch in our example diagram should be identical. Once you’ve completed confi guring 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 classifi es and marks traffi c 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 traffi c with LLQ, AutoQoS for the Enterprise classifi es other forms of application traffi c 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” classifi cation 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 fl ows. If you wish to use the critical classifi cation and markings, you’ll have to go back and confi gure it manually by specifying what traffi c 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 traffi c the router sees and classifi es according to Cisco best-practice policies.

AutoQoS for the Enterprise will also identify low-speed WAN links and confi gure compression and link-effi ciency 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 traffi c passing through a specifi c interface. The router monitors its local interfaces and collects baseline information about the data fl ows 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 suffi cient time to collect data and classify it, AutoQoS for the Enterprise automatically creates QoS templates for classifi cation, marking, queuing, and link effi ciency. 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 confi gure Router-A with AutoQoS for the Enterprise.

c12.indd 483c12.indd 483 9/21/11 11:27:57 AM9/21/11 11:27:57 AM


F I GU R E 12 . 3 AutoQoS for the Enterprise

IP phones

IP phones

Switch SwitchRouter-A

S0/0S0/0

1540

Kbps Router-B

CUCM

Desktop

computers Desktop

computers

Application

servers

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 confi guration, but keep in mind that Router-B must go through the same process.

In the AutoQoS discovery phase we will enable the discovery of traffi c on our serial 0/0 interface by using the auto discovery qos command. This command will use NBAR to discover and classify traffi c. Any traffi c 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 confi gured with, we would use the auto discovery qos trust command. This would disable NBAR discovery and solely rely on DSCP marking for classifi cation. In our example, we will use NBAR for classifi cation, as shown here:



Router-A(config-if)#auto discovery qos


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 traffi c fl ows. You’ll notice in the interface confi guration 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 484c12.indd 484 9/21/11 11:27:57 AM9/21/11 11:27:57 AM


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 specifi c 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 traffi c the router has identifi ed and the suggested confi guration 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 Total

Protocol (kbps/%) (kbps/%) (bytes)

----------- ----------- -------- ------------

rtp audio 3/<1 517/52 703323

Class Interactive Video:

No data found.

Class Control:

Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate).




----------- ----------- -------- ------------

h323 0/0 75/7 30212

rtcp 0/0 7/<1 1540

Class Streaming Video:

No data found.

Class Transactional:

No data found.

Class Bulk:





----------- ----------- -------- ------------

c12.indd 485c12.indd 485 9/21/11 11:27:58 AM9/21/11 11:27:58 AM


ftp 0/0 330/31 74480

Class Scavenger:

No data found.

Class Management:





----------- ----------- -------- ------------

dhcp 0/0 84/8 115543

ldap 0/0 169/16 55434

Class Routing:





----------- ----------- -------- ------------

icmp 0/0 2/<1 300

Class Best Effort:

Current Bandwidth Estimation: 355 Kbps/34% (AverageRate).




----------- ----------- -------- ------------

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 486c12.indd 486 9/21/11 11:27:58 AM9/21/11 11:27:58 AM


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 identifi ed several different data fl ows using NBAR and classifi ed 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 specifi c network may use all or only a few of the possible classes. Additionally, at the end of the command, you can see the recommended confi guration 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 confi gurations remained on the confi guration. 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 confi guration 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 487c12.indd 487 9/21/11 11:27:58 AM9/21/11 11:27:58 AM


Configuring AutoQoS Implementation Phase

After you have completed the discovery phase and reviewed the confi guration that AutoQoS for the Enterprise has recommended specifi cally 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(config-if)#auto qos


Router-A#

This command applies all of the QoS classifi cation, marking, and queuing confi gurations. In addition, it will confi gure any link-effi ciency 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-effi ciency 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 confi guration tool called Modular QoS CLI (MQC).

Configuring QoS Policies Using MQCYou’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 confi guration 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 confi guration steps involved, MQC lets administrators decide for themselves how data fl ows should be classifi ed and marked, and what queuing policies to use. MQC uses a structured three-step command process, as shown here:

c12.indd 488c12.indd 488 9/21/11 11:27:59 AM9/21/11 11:27:59 AM

Configuring QoS Policies Using MQC 489

class-map Class maps are used to confi gure different traffi c 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 confi gure your most specifi c matching statements fi rst.

policy-map Policy maps are used to associate a traffi c class type with one or more QoS operations. This is your set or do function.

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

The beauty of MQC lies in its highly scalable and modular nature. Classifi cations 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 GU R E 12 . 4 MQC structure

Class 1

Class 2

Class 3

class-map policy-map

Policy

service-policy

Interface

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 confi guration process, using Figure 12.5 as our example network.

F I GU R E 12 .5 MQC network example

IP WAN

Router-A

S0/0

c12.indd 489c12.indd 489 9/21/11 11:27:59 AM9/21/11 11:27:59 AM


Configuring Class Maps

The fi rst step of any QoS policy is to segment various types of traffi c into classes. Using MQC, this process is kicked off by using the class-map command while in global confi guration 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 confi gured within the class, your packet needs to meet only one of the requirements.

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

Again, note that the match-any and match-all keywords are optional. If the class-map command simply has a unique identifi er in the statement and no keyword, that class map is a match-any class map.

In our fi rst example, we will confi gure a class map named class-1, where we want to trigger on any one match statement:


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 confi gure our match statements.

The process of confi guring 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 LE 12 .1 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.

c12.indd 490c12.indd 490 9/21/11 11:28:00 AM9/21/11 11:28:00 AM


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 traffi c marked with either an IP Precedence of 5 or a DSCP of 46:


Router(config)#class-map voice

c12.indd 491c12.indd 491 9/21/11 11:28:01 AM9/21/11 11:28:01 AM


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 confi gure a second class map that uses an access-list as well as DSCP PHB values CS6 and CS2 for our network control fl ows. First we’ll confi gure 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 traffi c:


Router(config)#access-list 10 permit 10.0.1.0 0.0.0.255




Router(config)#class-map match-all network

Router(config-cmap)#match access-group 10

Router(config-cmap)#match dscp cs2 cs6


Router#

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 traffi c using NBAR. In this example, we will create a new match-any class map named web and use NBAR to identify HTTP and HTTPS traffi c:


Router(config)#class-map web

Router(config-cmap)#match protocol http

Router(config-cmap)#match protocol secure-http


Router#

So as you can see, there are multiple ways to classify traffi c, using all sorts of differentiation techniques, including ACLs, IP precedence/DSCP values, and NBAR. Now that we have classifi ed some traffi c, let’s see how we can apply QoS policies using the policy-map command.

c12.indd 492c12.indd 492 9/21/11 11:28:01 AM9/21/11 11:28:01 AM


Configuring Policy Maps

To apply various QoS policies to classes we have created, we use the policy-map global confi guration command followed by a unique name for the policy. We will then be placed into config-pmap confi guration mode. Here, we can identify a class map by its unique name. We will then be put into config-pmap-c confi guration mode. It is within this confi guration 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 LE 12 . 2 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.

c12.indd 493c12.indd 493 9/21/11 11:28:02 AM9/21/11 11:28:02 AM


We will use our three previously confi gured class maps and apply them to a single policy map in our example. We will call the policy policyWAN and apply specifi c traffi c condition settings for each class, as shown here:


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)#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 traffi c 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 traffi c is simply handed a DSCP value of 0. Next, you will learn how to apply our policies to interfaces using the service-policy interface confi guration command.

The Parent and Child Relationship

Nathan was working on confi guring classes and policies using MQC. He wanted an elegant way to apply CBWFQ on a wide range of traffi c (a class named big) and enable traffi c 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 traffi c and a “child” map that would use the parent priority settings but also enable traffi c policing, as shown in this example:


Router(config)#policy-map child

Router(config-pmap)#class big

Router(config-pmap-c)#priority 30


c12.indd 494c12.indd 494 9/21/11 11:28:02 AM9/21/11 11:28:02 AM


Applying Policy Maps to Interfaces with a Service Policy

The fi nal step in the MQC process, after we have defi ned traffi c in classes and confi gured QoS policies, is to apply those policies to an interface. To do this, we navigate to config-if confi guration 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 traffi c 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(config)#interface s0/0

Router(config-if)#service-policy output policyWAN


Router#

That’s all there is to MQC! To recap, you must perform the following MQC steps:

1. Confi gure a class map.

2. Confi gure 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 confi gurations 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 confi gured using MQC. The last of these commands, show policy-map interface, can be used to verify packet matching and queue usage on interfaces confi gured with QoS policies.

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#

Now Nathan has a single policy map named parent that polices all traffi c and at the same time applies PQ to a subset policy map named child.

c12.indd 495c12.indd 495 9/21/11 11:28:03 AM9/21/11 11:28:03 AM


show class-map Use this command to quickly view all of the class maps confi gured 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 confi gurations 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 traffi c 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 496c12.indd 496 9/21/11 11:28:03 AM9/21/11 11:28:03 AM


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


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


Match: any

Router#

Notice that at the end of this command is a map identifi ed as class-default. While we did not confi gure this class map, it is always included anytime you apply a policy to an interface. This class map is used for all other traffi c that does not match a confi gured class map.

c12.indd 497c12.indd 497 9/21/11 11:28:03 AM9/21/11 11:28:03 AM


Now that you understand how to confi gure QoS using MQC, we will take a look at how to confi gure RED and WRED, which as you learned in Chapter 11 are congestion-avoidance techniques for bottlenecked links.

Configuring Congestion-Avoidance TechniquesRandom Early Detect (RED) is a congestion-avoidance technique that is set into motion when queues begin to fi ll up, and packets need to be discarded on bottleneck interfaces. Before the queue buffer completely fi lls and sensitive traffi c 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 fi ll 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 traffi c. All of the TCP transmissions slow down simultaneously and then begin speeding up simultaneously, and ultimately buffers overfl ow 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 fl ow 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 confi gured directly on the interface, but we will use class-based WRED (CB-WRED) for our examples. Also keep in mind that CBWFQ must be confi gured in conjunction with WRED within a policy map.

We can confi gure 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 defi ned and create a policy map. Within the policy map we reference the class map of traffi c 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 classifi es a group of TCP data packets fl owing through an interface. We will create a policy map for this class and give it a CBWFQ percent of 10. Additionally, we will confi gure WRED to use DSCP markings, as shown here:

Router(config-pmap)#class tcp-traffic


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 498c12.indd 498 9/21/11 11:28:04 AM9/21/11 11:28:04 AM

Configuring Congestion-Avoidance Techniques 499

(or precedence if using IP Precedence). We then need to confi gure 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 specifi c 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 GU R E 12 .6 WRED packet drop procedure

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

Queue size

Minimum

threshold

Maximum

threshold

Pa

cke

t d

rop

pro

ba

bilit

y

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 confi guration process by defi ning minimum, maximum, and mark-probability numbers for the three DSCP values shown here:

Router(config-pmap-c)#random-detect dscp af13 25 100 4



c12.indd 499c12.indd 499 9/21/11 11:28:04 AM9/21/11 11:28:04 AM


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 confi gurations for AF12 and AF11 as well, although their minimum thresholds are different.

Next, let’s look at how we can confi gure class-based traffi c policing and shaping to help condition and control traffi c rates.

Configuring Class-Based Traffic Policing and ShapingQoS techniques such as priority queuing (PQ) and class-based weighted fair queuing (CBWFQ) focus on setting minimum-bandwidth requirements for certain types of traffi c. While this is important, sometimes it is just as important to set maximum-bandwidth levels for traffi c fl ows as well. This is especially critical when dealing with traffi c that can handle dropped packets and still function. On Cisco routers, there are two methods for confi guring maximum levels of traffi c, known as traffi c policing and traffi c 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 traffi c policing and shaping use. Next we’ll show how to confi gure traffi c policing, which is the stricter of the two options. Last, we will go on to confi gure traffi c shaping, which utilizes queues to slow down TCP fl ows.

Understanding Token Buckets

Traffi c policing and shaping use the concept of token buckets to manage traffi c. The token bucket is used to regulate data in a fl ow to manage overall bandwidth of an interface. The token bucket mean rate equation defi nes the average (mean) rate of transfer for traffi c on a specifi c 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 traffi c can be sent on a token within a specifi c time interval without disrupting other traffi c.

Time Interval (Tc) This number tells us the time in seconds allowed for a burst of traffi c.

c12.indd 500c12.indd 500 9/21/11 11:28:05 AM9/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 traffi c (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 traffi c-policing example, the maximum traffi c rate for this interface cannot go over 64 Kbps or it will either be dropped or discarded. Policed traffi c that is at or below this rate is our burst-conforming (Bc) traffi c. Any data fl ows that go above the CIR are called burst-exceeding (Be) traffi c.

Let’s take a closer look at the token bucket itself. The bucket always has a fi xed capacity size. If the bucket completely fi lls up, all new tokens are dropped. Tokens are metaphors used to describe a router’s permission for a source device to send a specifi ed 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 specifi ed 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 traffi c policing or traffi c shaping:

Not Enough Tokens: Traffic Policing When there are not enough tokens to send a packet with traffi c 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 traffi c shaping, the packet is placed into a queue and waits until enough free tokens are available.

Let’s next examine the different traffi c-policing bucket types and how to confi gure them.

Understanding Traffic-Policing Token Buckets

Traffi c 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 single-bucket method.

c12.indd 501c12.indd 501 9/21/11 11:28:05 AM9/21/11 11:28:05 AM


F I GU R E 12 .7 A single token bucket

Exceed-action

performed on

these tokens

Conform-action

performed on

these tokens

Bc

Exceeding

the CIR

Token

flow (CIR)

As you can see from Figure 12.7, there are two possible outcomes for single-bucket traffi c:

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 traffi c conforms to the rules. The bucket tokens are used to remove the conforming data from the bucket, and specifi c actions are performed on that data that meet the conform rules. One of these actions is commonly a forward action, so traffi c 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 traffi c exceeds the rule limits. The exceeding data remains in the token bucket, and specifi c 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 traffi c that fi ts into the Be bucket will be categorized and handled differently. If the exceeding traffi c does not fi t into the Be bucket, it is considered to be in violation.

F I GU R E 12 . 8 Dual-bucket, single-rate model

Conform-action

performed on

these tokens

Exceed-action

performed on

these tokens

Bc

Be

Exceeding

the CIR

Token

flow (CIR) Violate-action

performed on

these tokens

c12.indd 502c12.indd 502 9/21/11 11:28:06 AM9/21/11 11:28:06 AM


Here are the three specifi c outcomes of traffi c 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 traffi c conforms to the rules and the conformed traffi c is handled accordingly.

Exceed-action If the packet is higher than the CIR and cannot fi t into the fi rst Bc bucket, it exceeds the limit. However, there is a second bucket that it can possibly fi t into. This is the Be bucket. If the CIR overfl ow packet data can fi t inside this bucket, it is classifi ed as an exceed-action traffi c type and specifi c actions can be performed on this data.

Violate-action If the number of overfl ow bytes in the packet is greater than the number of token bytes available in the Be bucket, the traffi c is considered to be in violation of the policing rules. The data remains in the bucket and specifi c 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 GU R E 12 . 9 Dual-bucket, dual-rate method

Violate-actionperformed onthese tokens

Exceedingthe PIR

Tokenflow (CIR)

Tokenflow (PIR)

Conform-actionperformed onthese tokens

Exceed-actionperformed onthese tokens

Exceedingthe CIR

c12.indd 503c12.indd 503 9/21/11 11:28:06 AM9/21/11 11:28:06 AM


You’ll notice that in this situation, there are two different traffi c 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 fi rst 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 traffi c 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 traffi c. If so, the traffi c does indeed meet the conform-action rules; if not, the traffi c 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 traffi c conforms to the rules and the conformed traffi c is handled accordingly.

Exceed-action If the packet is higher than the CIR and cannot fi t 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 traffi c is considered to be in violation and abides by the violate-action rules.

Having two different traffi c rates allows for the following benefi ts:

� Improved bandwidth manageability

� Sustained (non-bursty) excess traffi c rates

� Preferred rate limiting on network edges for packet conforming and marking

Configuring Class-Based Traffic Policing

With class-based traffi c policing, we can manipulate packets and data fl ows in one of the two following ways:

� Setting a rate that limits (or drops completely) the data fl ow transmission rate on packets coming into or out of an interface.

� Marking packets using CoS, IP Precedence, and/or DSCP.

Class-based traffi c policing confi guration occurs during the policy-map stage, after we have defi ned a class of traffi c we wish to police. We will use the police command followed by one or several keywords. The best way to understand how to confi gure traffi c 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:

� CIR = 8000

� Bc = 2000

� Be = 4000

c12.indd 504c12.indd 504 9/21/11 11:28:07 AM9/21/11 11:28:07 AM


For any traffi c that conforms to the CIR, we will transmit the data. For traffi c that falls into the exceed-action category, we will re-mark it with a DSCP value of 0. Finally, any traffi c that falls into the violate-action category is immediately dropped. Because we are using the violate-action keyword, we know we are confi guring a dual-bucket policing strategy.

For our policing and shaping confi guration examples, we will use Figure 12.10 as our sample network.

F I GU R E 12 .10 A traffic-policing network example

LANLAN

Router-A Router-B

S0/0

256 Kbps

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(config)#policy-map policyPOLICE

Router-A(config-pmap-c)#class police-me

Router-A(config-pmap-c)#police 8000 2000 4000 conform-action transmit exceed-action 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 fi gure 12.10. With traffi c policing, we have the ability to apply the policy for either inbound or outbound traffi c. In our particular case, we will choose to apply the policy to outbound traffi c, as shown here:


Router-A(config)#interface s0/0

Router-A(config-if)#service-policy output policyPOLICE


Router-A#

c12.indd 505c12.indd 505 9/21/11 11:28:08 AM9/21/11 11:28:08 AM


Next, you’ll learn how to confi gure the other rate-limiting technique using traffi c-shaping methods.

Configuring Class-Based Traffic Shaping

Confi guring class-based traffi c shaping is done in a similar manner as traffi c policing on policy-map confi gurations of a specifi c class of traffi c. The command used to confi gure traffi c 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 confi gure generic traffi c 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 confi gure the average rate, this limits traffi c 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 traffi c 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, confi guring traffi c shaping using an average rate is preferred and implemented in most situations.

When confi guring using the shape command followed either by average or peak, we will confi gure only the average/peak bps for the classifi ed traffi c. Optionally, we can manually set the Bc and Be rates. If we do not manually confi gure 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 506c12.indd 506 9/21/11 11:28:08 AM9/21/11 11:28:08 AM


Peak_rate � 16000 � 2

Peak_rate � 32000 or 32 Kbps

Let’s look at a traffi c-shaping confi guration example again using Figure 12.10 as our network.

We have two classes already confi gured 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(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#

From this confi guration, traffi c defi ned 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


Match: dscp ef (46)

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

128000/128000 1984 7936 7936 62 992

c12.indd 507c12.indd 507 9/21/11 11:28:09 AM9/21/11 11:28:09 AM


Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 0 0 0 0 no

Class-map: tolerant (match-all)

0 packets, 0 bytes


Match: dscp default (0)

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

128000/64000 2000 8000 8000 125 2000

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 0 0 0 0 no

Class-map: class-default (match-any)

0 packets, 0 bytes


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 TechniquesSometimes QoS just isn’t enough to provide effi cient transport for sensitive traffi c. 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 508c12.indd 508 9/21/11 11:28:09 AM9/21/11 11:28:09 AM

Configuring Link Efficiency Techniques 509

more effi cient. In this section I’ll show how to use LFI on both MLP and Frame Relay connections as well as how to confi gure 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 traffi c fl ows

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 traffi c. LFI is recommended on links at or below 768 Kbps and is an optional confi guration 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 confi gure 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 traffi c over point-to-point links including ISDN. While the protocol does have built-in abilities to load-balance traffi c 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 traffi c so it can avoid serialization delays. The queuing mechanism used to differentiate between time-sensitive and regular traffi c is WFQ, which can differentiate traffi c fl ows at Layers 3 and 4.

To confi gure MLP, you must fi rst create an MLP virtual interface by using the interface multilink command followed by a unique virtual interface identifi er. The virtual interface identifi er 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 identifi er:


Router(config)#interface multilink 1

Router(config-if)#

At this point, we are in config-if confi guration mode, and we should fi rst confi gure an IP address on it. Note that the virtual interface contains the IP address and not the

c12.indd 509c12.indd 509 9/21/11 11:28:09 AM9/21/11 11:28:09 AM


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 confi guration 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 specifi c delay timer. This is very useful for voice traffi c, 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 confi guration:


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 confi gure LFI on interface serial 0/1. We must fi rst 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 virtual-multilink 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#

At this point, MLP is up and running on your interface. Make sure that you also confi gure 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 traffi c such as voice over these circuits, you can experience congestion problems quickly. In this section, you will learn how to confi gure FRF.12, which is a specifi cation 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 510c12.indd 510 9/21/11 11:28:10 AM9/21/11 11:28:10 AM

Configuring Link Efficiency Techniques 511

fragments any frame larger than the confi gured fragment size. Because of this, you must be cautious in setting your fragmentation size so you don’t accidentally fragment time-sensitive 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 traffi c shaping must also be confi gured 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 identifi er is used to confi gure 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 fi gure 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 confi gure our Frame Relay traffi c-shaping confi guration as shown in this example, where we confi gure a Frame Relay class named Frag-Me:


Router(config)#map-class frame-relay Frag-Me

Router(config-map-class)#frame-relay fragment 320

Router(config-map-class)#frame-relay cir 128000

Router(config-map-class)#frame-relay fair-queue

Router(config-map-class)#exit

Router(config)#

Now it’s time to apply our Frame Relay fragment and shaping class to the Frame Relay interface with a confi gured DLCI. Similar to MLP, we must modify our Layer 2 protocol from HDLC to Frame Relay. Also remember that we must enable Frame Relay traffi c shaping on the physical interface.

We can then confi gure 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(config-if)#frame-relay traffic-shaping

c12.indd 511c12.indd 511 9/21/11 11:28:10 AM9/21/11 11:28:10 AM


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

Serial0/0.1 100 end-to-end 320 643 790 0

Router#

Now that you understand how to confi gure LFI for MLP and Frame Relay connections, let’s move on to learn how to confi gure 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 confi guration method, we can confi gure traffi c for compression as well as multiple other QoS policies such as PQ and CBWFQ.

The command used to confi gure CB header compression while within config-pmap-c confi guration 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 confi guration, 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 traffi c and will enable cRTP compression:



Router(config-cmap)#match dscp ef

Router(config-cmap)#exit

Router(config)#policy-map policyRTPcompress

Router(config-pmap)#class voice


Router(config-pmap-c)#compression header ip rtp


Router#

c12.indd 512c12.indd 512 9/21/11 11:28:11 AM9/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 confi gured on them. Here is an example of how to apply our policy map to interface serial 0/0:



Router(config-if)#service-policy output policyRTPcompress


Router#

Configuring Trust BoundariesChapter 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 confi gure trust boundaries on an Access layer switch, we must be in config-if confi guration 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 GU R E 12 .11 Access switch trust boundary configuration

SwitchGi0/5

VLAN 10

Trusted markings

Untrusted markings

VLAN 99

The mls qos trust command is used to set what type of traffi c 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 513c12.indd 513 9/21/11 11:28:11 AM9/21/11 11:28:11 AM


cos Trusts all Layer 2 CoS markings and rewrites the DSCP markings using the default CoS-to-DSCP map.

dscp Trusts the DSCP markings and rewrites the CoS markings using the default DSCP-to-CoS map.

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 confi guring 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-to-DSCP map.

Another popular confi guration 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 confi gure an Access layer switchport with both a voice (10) and data (99) VLAN. In addition, the switchport will be confi gured to trust CoS markings from Cisco IP phones:


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#

c12.indd 514c12.indd 514 9/21/11 11:28:12 AM9/21/11 11:28:12 AM

Configuring CoS-to-DSCP Mappings 515

One fi nal switch interface confi guration command that you should be familiar with is mls qos cos, followed by a CoS value. This command statically assigns a CoS value to traffi c 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 confi gure our switch interface gi0/5 to assign frames with a CoS of 1 if they come in untagged:


Switch(config)#interface gi0/5

Switch(config-if)#mls qos cos 1


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 MappingsAs you know, trust boundaries are confi gured to trust (or not to trust) QoS markings that come into a port. When a switch is confi gured 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 traffi c 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 confi gured to trust the CoS values and rewrite the DSCP value using the default CoS-to-DSCP mappings.

F I GU R E 12 .12 CoS-to-DSCP default mapping

Router

trust DSCP CoS = 5

DSCP = 40

Cos markings 0 1 2 3 4 5 6 7

0 8 16 24 32 40 48 56DSCP markings

CoS = 5

DSCP = 46

Switch

trust CoS

CoS-to-DSCP lookup

and remapping

c12.indd 515c12.indd 515 9/21/11 11:28:12 AM9/21/11 11:28:12 AM


You’ll notice that when the switch remaps the DSCP value, it changes from 46 to 40. Best-practice documentation states that RTP traffi c should be classifi ed 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 confi gured globally on the switch. This example shows a commonly remapped CoS-to-DSCP mapping:


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 modifi ed. 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 confi gure up to 13 DSCP markings to a single CoS number. Each CoS value is confi gured using a single CLI command. For example, we will confi gure 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(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 516c12.indd 516 9/21/11 11:28:13 AM9/21/11 11:28:13 AM

Exam Essentials 517

SummaryQuality 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 traffi c so it gets the interface priority that it requires. The CVOICE version 8.0 exam now requires that certifi cation candidates know the two primary QoS confi guration 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 EssentialsKnow the two different AutoQoS types. They are AutoQoS for VoIP and AutoQoS for the Enterprise.

Understand when AutoQoS for the Enterprise is recommended. AutoQoS for the Enterprise is used on larger networks with a signifi cant number of remote sites interconnected with WAN connections.

Know what type of AutoQoS can be configured on Cisco Catalyst switches. Cisco Catalyst switches can only be confi gured for AutoQoS for VoIP.

Know the two phases of AutoQoS for the Enterprise. The fi rst phase is called the AutoQoS autodiscovery phase and is used to discover interfaces and data fl ows on a network. The second phase creates QoS templates based on the fi ndings 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 fi ll up. WRED uses classifi cation markings to drop less-important packets fi rst.

Understand the concept of a token bucket. A token bucket is used to regulate data in a fl ow 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 traffi c with a lower DSCP value that is recommended by Cisco.

c12.indd 517c12.indd 517 9/21/11 11:28:13 AM9/21/11 11:28:13 AM


Written Lab 12.11. What Cisco equipment can Auto-QoS for VoIP be confi gured on?

2. AutoQoS for the Enterprise is recommended on large networks with multiple connections.

3. What Cisco switch AutoQoS command is used to confi gure an interface to trust DSCP and/or CoS markings?

4. What router interface command is used to confi gure AutoQoS for the Enterprise to monitor and classify traffi c using NBAR?

5. What class-map command will confi gure a class named voice and set it to classify traffi c 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 confi gure 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?


Hands-On LabsTo complete the labs in this section, you need a Cisco Catalyst switch for Layer 2 QoS confi gurations. 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 GU R E 12 .13 QoS lab diagram

Phone(VLAN 5)

PC(VLAN 101)

Switch

Fa0/5

Fa0/0S0/0

Fa0/0

Router

Remote site

c12.indd 518c12.indd 518 9/21/11 11:28:14 AM9/21/11 11:28:14 AM

Hands-On Labs 519


Lab 12.1: Confi guring a Switchport to Trust Cisco IP Phone QoS Markings

Lab 12.2: Modifying CoS-to-DSCP Mappings

Lab 12.3: Confi guring 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 confi gure our access port on fa0/5 to place traffi c coming from the phone on VLAN 5 and from the PC on VLAN 101. Additionally, we will confi gure 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 confi guration mode by typing enable and then configure terminal.

2. We can then begin to confi gure the Cisco IP phone that is attached to fa0/5 by fi rst entering into interface confi guration mode by typing interface fa 0/5.

3. We will confi gure this port as an Access layer port by typing switchport mode access.

4. Now we will confi gure the switchport to place voice traffi c on VLAN 5 by typing switchport voice vlan 5.

5. Next, we will confi gure all other traffi c coming from the PC to use VLAN 101 for transport by typing switchport access vlan 101.

6. Our fi rst QoS command is to confi gure the port to trust CoS markings by typing mls qos trust cos.

7. Lastly, we will confi gure 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 confi guration 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 traffi c 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 confi guring QoS on our switch, we need to confi gure mapping rules so that our voice traffi c will receive the proper QoS on the network. We will use the following CoS-to-DSCP mappings according to Table 12.3.

c12.indd 519c12.indd 519 9/21/11 11:28:14 AM9/21/11 11:28:14 AM


TA B LE 12 . 3 CoS-to-DSCP mappings

CoS Markings DSCP Markings

0 0

1 10

2 18

3 26

4 34

5 46

6 48

7 56


2. Confi gure the CoS-to-DSCP mappings by typing mls qos map cos-dscp 0 10 18 26 34 46 48 56.

3. Exit global confi guration 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 confi guration to the router QoS confi guration. In this lab we will use MQC to confi gure QoS to match our voice traffi c coming from our switch. We will then apply QoS policies and apply them to the outbound serial 0/0 interface. We will fi rst confi gure 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 confi gured our switch to trust markings from the Cisco IP phone and modifi ed the CoS to DSCP mappings so voice traffi c will be marked with a DSCP value of 46.

1. Log into the switch and go into confi guration mode by typing enable and then configure terminal.

2. Confi gure 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 confi guration mode by typing exit.

c12.indd 520c12.indd 520 9/21/11 11:28:15 AM9/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 traffi c that is matched against the class map rules should be handled. In our example, we will give our voice traffi c a strict priority queuing capability up to 60 percent of the total link bandwidth.

5. Confi gure and name our policy map by typing policy-map voice-policy.

6. Specify the voice-traffi c class map by typing class voice-policy.

7. Apply the QoS strict-priority queuing mechanism for this traffi c by typing priority percent 60.

8. Exit out of policy-map confi guration mode by typing exit.

Finally, we will apply the policy to our serial interface 0/0 so the voice traffi c can have plenty of bandwidth across the WAN to the remote network.

9. Enter into interface confi guration 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 confi guration mode by typing end.

c12.indd 521c12.indd 521 9/21/11 11:28:15 AM9/21/11 11:28:15 AM


Review Questions1. AutoQoS works in conjunction with which two features?

A. CDP

B. SIP

C. CEF

D. NBAR

E. H.323

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

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

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

B. trust cisco-phone

C. trust dscp

D. trust

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

B. dscp

C. trust

D. cisco-softphone

5. What two global configuration commands will be found after enabling AutoQoS on one or more interfaces on a Cisco switch?

A. mls qos

B. mls qos trust cos

C. mls qos trust dscp

D. mls qos map cos-dscp 0 8 16 26 32 46 48 56

c12.indd 522c12.indd 522 9/21/11 11:28:16 AM9/21/11 11:28:16 AM


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

B. show auto discovery qos

C. show mls qos auto discovery

D. show auto discovery mls qos

7. Which of the following switch-interface commands will trust DSCP markings coming from an upstream router?

A. auto qos voip trust

B. qos voip trust

C. qos voip trust dscp

D. mls qos trust dscp

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

B. class-best-effort

C. class-default

D. class-network

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

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.

c12.indd 523c12.indd 523 9/21/11 11:28:16 AM9/21/11 11:28:16 AM


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


B. Router(config)#policy-map mypolicy Router(config-pmap)#class ipt


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

C. CQ

D. CBWFQ

c12.indd 524c12.indd 524 9/21/11 11:28:17 AM9/21/11 11:28:17 AM


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-dscp-transmit 0

What token bucket structure is used?

A. Single-bucket

B. Single-bucket with dual-rates

C. Dual-bucket with single-rates

D. Dual-bucket with dual-rates

c12.indd 525c12.indd 525 9/21/11 11:28:17 AM9/21/11 11:28:17 AM


Answers to Review Questions1. C, D. The automatic classifi cation function of AutoQoS uses NBAR to identify and classify

traffi c at Layer 4. NBAR requires that CEF be enabled.

2. C. The automatic classifi cation 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 traffi c found and classifi ed while monitoring. Additionally, the command output shows suggested QoS confi guration commands based on the traffi c-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 traffi c 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 classifi ed into this class.

11. C. The match access-group class-map command followed by the access-list number should be confi gured 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 traffi c.

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 specifi c 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 526c12.indd 526 9/21/11 11:28:17 AM9/21/11 11:28:17 AM


16. D. CIR = Bc / Tc CIR = 56,000 / 0.25 CIR = 224,000 bps or 224 Kbps

17. D. Traffi c that exceeds the CIR is considered to be Be traffi c and is placed into the Be token bucket.

18. A. All of these token outcomes for tokens are possible except for the overfl ow-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 527c12.indd 527 9/21/11 11:28:18 AM9/21/11 11:28:18 AM


Answers to Written Lab 12.11. 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 528c12.indd 528 9/21/11 11:28:18 AM9/21/11 11:28:18 AM

About theCompanion CD

IN THIS APPENDIX:

What you’ll find on the CD.

System requirements.

Using the CD.

Troubleshooting.

�

�

�

�

Appendix

bapp.indd 529bapp.indd 529 9/20/11 1:34:45 PM9/20/11 1:34:45 PM

What You’ll Find on the CDThe 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 fl ashcards 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/.


Troubleshooting 531

System RequirementsMake 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 fi les 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 CDTo 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.

TroubleshootingWiley 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


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.


IndexNote to the Reader: Throughout this index boldfaced page numbers indicate primary discussions of a topic. Italicized page numbers indicate illustrations.

AA-law algorithm, 55access codes for private plans, 117access-group option, 490, 492access-list option, 492ACF (Admission Confirmation) message,

400–401Adaptive Differential Pulse Code Modulation

(ADPCM), 155Adaptive MultiRate Wideband

(AMR-WB), 155address signaling, 35–37, 36–37address translation, 398Admission Confirmation (ACF) message,

400–401Admission Reject (ARJ) message, 400–401Admission Request (ARQ) message,

400–401ADPCM (Adaptive Differential Pulse Code

Modulation), 155AF (Assured Forwarding) PHB, 452–453agents

call processing, 15–17, 17fax relay, 362SIP, 86, 240

AIM (AOL Instant Messenger), 156ALERTING ephone extension state, 336, 338aliases, directory, 299allow-connections command, 422–423allow-connections sip to sip

command, 306alternate mark inversion (AMI), 59, 59AMI option, 63, 192ampersands (&) in regular expressions, 128AMR-WB (Adaptive MultiRate

Wideband), 155analog telephones, 3analog telephony adapters (ATAs), 15analog-to-digital conversion

compression process, 54–55encoding process, 53–54, 54overview, 51–52

quantization, 53, 53signal sampling, 52–53, 52

analog-to-IP adapters, 15analog voice, 34

conversion to digital. See analog-to-digital conversion

exam essentials, 66–67ports, 34–35

FXO outbound, 184–187, 185FXS and FXO PLAR OPX,

180–184, 180FXS basic, 47–50FXS/DID inbound, 184–187, 185

review questions, 69–74signaling, 35

address, 35–37, 36–37E&M, 41–46, 44–46ground-start, 40–41, 41informational, 37–38supervisory, 38–41, 39, 41

summary, 66T1 CAS to analog cross-connect, 191–195,

191written lab, 67–68, 75

ANI (Automatic Number Identification), 112, 188–189

ani mapping command, 213answer-address command, 112answer (ANS) tones, 362AOL Instant Messenger (AIM), 156application mgcpapp command, 259application-specific packets, 82application-specific routing (ASR), 91applications, 15area codes, 8, 115, 190ARJ (Admission Reject) message, 400–401ARQ (Admission Request) message, 400–401ASR (application-specific routing), 91associate application SCCP command, 199associate ccm command, 201associate profile command, 201Assured Forwarding (AF) PHB, 452–453asterisks (*) in regular expressions, 128

bindex.indd 533bindex.indd 533 9/20/11 1:38:36 PM9/20/11 1:38:36 PM

ATA 180 series phones, 15ATAs (analog telephony adapters), 15AUCX (audit connection) command, 256audible rings, 310audio fidelity, 148, 148AUEP (audit endpoint) command, 256Authentication and Message Integrity packets, 83authentication username command, 269authentication username password command,

240authorization, call, 398–399auto command, 285auto assign command, 310auto discovery qos command, 484, 488auto discovery qos trust command, 484auto qos command, 488auto qos cisco-phone command, 480–481auto qos voip command, 475–476, 481auto qos voip cisco-phone command, 482auto qos voip trust command, 481–482autodiscovery phase in AutoQoS, 483–487Automatic Number Identification (ANI), 112,

188–189AutoQoS, 446, 474–475

autodiscovery phase, 483–487enterprises, 475, 483, 484implementation phase, 488installation phase, 483VoIP, 475

on routers, 475–479, 476on switches, 479–483, 480

average keyword, 506

BB (bearer) channels, 61b (silent with beep) ephone button

separator, 318B8ZS (Bipolar 8-bit Zero Substitution),

59, 60, 192B8ZS option, 63BA (behavior aggregate) in DSCP, 451Baby Bell companies, 8background noise, 149–151, 150backhauled connections, 7backslashes (\) in regular expressions, 128–130backup paths, voice, 368–369

COR, 372–377, 373MGCP-to-H.323 fallback, 370–372, 371SRST, 376–377WAN-to-PSTN fallback, 369–370, 369

backward compatibility of inline power switches, 284–285

bandwidthH.323 gatekeepers, 398–399

CAC control, 411–414, 413RAS messages, 404–405

IP voice, 164calculations, 165, 167–169, 169codec bit rate, 166–167packet and frame size information,

165–166, 166providing, 441–442

bandwidth commandH.323 gatekeepers, 412–413QoS policy maps, 493

Bandwidth Confirm (BCF) message, 404–405Bandwidth Reject (BRJ) message, 404–405Bandwidth Request (BRQ) message, 404–405baseline models in QoS, 461–463, 462Basic Rate Interface (BRI), 56, 61Bc (Burst Conforming) size for token buckets,

500–501, 506BCF (Bandwidth Confirm) message, 404–405Be (burst-exceeding) traffic for token buckets,

501–502, 506bearer (B) channels, 61behavior aggregate (BA) in DSCP, 451Bell, Alexander Graham, 2Best-effort QoS model, 447, 449bind command, 247bind all source-interface command, 269bind control source-interface

command, 306bind interface command, 201bind srcaddr command, 409binding

SIP sources to IP addresses, 247virtual H.323 gateway addresses,

233–234, 233Bipolar 8-bit Zero Substitution (B8ZS),

59, 60, 192bipolar variations, 59bit rate for codecs, 166–167blast method for location message

forwarding, 403bottlenecks

end-to-end delays, 442packet loss from, 443–444, 443as quality issue, 151–152

boundaries, trustconfiguring, 513–515, 513identifying, 460–461, 461

534 ATA 180 series phones – boundaries, trust


BRI (Basic Rate Interface), 56, 61BRJ (Bandwidth Reject) message, 404–405BRQ (Bandwidth Request) message, 404–405buffer packets in traffic policing, 456buffering delay, 152Burst Conforming (Bc) size for token buckets,

500–501, 506burst-exceeding (Be) traffic for token buckets,

501–502, 506Busy informational signals, 38button command

ephone, 318SCCP, 344

button separator options for ephone, 318–319expansion line, 324monitor line, 319–320, 320overlay line, 320–323overlay with call waiting, 323–324watch phone, 320

Bye retry type, 246bytes setting, 230

Cc (overlay with call waiting) ephone button

separator, 319, 323–324C549 DSP chipset (PVDM), 157–158C5510 DSP chips (PVDM2), 157, 159–160CA (call agent) fax relay method, 362call-admission control (CAC), 90–91, 93, 398,

411–414, 413, 417call admission messages, 400–401call agent (CA) fax relay method, 362call authorization, 398–399call-block disconnect-cause incoming

command, 381call blocking, 380–382call clarity, codecs for, 164call control devices, 87call flow differences, 421–422, 421–422call management in H.323, 399call processing agents, 15–17, 17call-processing clusters, 90, 90call progress (CP) tones, 38call routing, 108

call legs, 110–111, 111POTS dial peers, 108–109VoIP dial peers, 109–110, 110

call signaling, 17, 17call start config-serv-h232

command, 228

call waiting, 323–324Call waiting informational signals, 38called type in translation profiles, 131caller-ID blocking, 249calling privileges, 90, 104calling type in translation profiles, 131CAMA (Centralized Automatic Messaging

Accounting) trunks, 188–191, 189, 213Cancel retry type, 246CAR (Committed Access Rate), 456carets (^) in regular expressions, 128–130CAS (Channel Associated Signaling), 56, 60–61categories of traffic, 446CB (class-based) header compression,

512–513CB (class-based) QoS, 488–489CB-WRED (class-based WRED), 498CBWFQ (class-based weighted fair queuing),

454–455CC (Country Code) in E.164, 113–114ccm-manager mgcp command, 257CCME licenses, 297CCS (Common Channel Signaling), 56, 61–62CDP (Cisco Discovery Protocol), 285, 514CEF (Cisco Express Forwarding), 475central office (CO)

overview, 4–5, 4trunks, 7, 7

central office code in NANP, 115Centralized Automatic Messaging Accounting

(CAMA) trunks, 188–191, 189, 213

centralized call-control systems, 93centralized services deployment model,

20, 21cfg-translation-profile mode, 131, 381CH1 licenses, 297Channel Associated Signaling (CAS),

56, 60–61child maps, 494CIR (Committed Information Rate), 500–501Cisco Cius Tablet, 14, 14Cisco Discovery Protocol (CDP), 285, 514Cisco Express Forwarding (CEF), 475Cisco fax relay, 357–359, 358Cisco IP Communicator, 13–14cisco option, 360cisco-phone option, 479Cisco products overview. See Unified

Communications Model overviewcisco-rtp option, 354–355cisco-softphone option, 479

BRI (Basic Rate Interface) – cisco-softphone option 535


Cisco Unified Border Element (CUBE), 396, 421–422, 421–422

codec transparency, 424debug voip ipipgw command, 426–427exam essentials, 427–428features, 417H.323 fast-to-slow signaling, 424–425hands-on labs, 429–431, 429media flow-around, 418–419, 419, 423media flow-through, 418, 418overview, 416, 417protocol interoperation, 422–423, 423review questions, 432–437RSVP-CAC, 420, 420show call active voice brief command,

425–426show call history voice brief command,

426show voip rtp connections

command, 426signaling protocol interoperation,

419, 419SIP delayed-to-early-offer signaling, 425summary, 427written lab, 428–429, 438

Cisco Unified Communications Manager (CUCM), 16, 420

configuring, 201–202, 202gatekeepers, 89–90IP soft phones, 13–14RTP, 79

Cisco Unified Communications Manager Business Edition (CUCMBE), 16

Cisco Unified Communications Manager Express (CUCME), 16, 294–295

Cisco Unified Mobile Communicator, 13–14Cisco Unified Personal Communicator, 13Cisco Video Advantage product, 14Cius tablet, 14, 14clarity, voice codecs for, 160–163class-based (CB) header compression,

512–513class-based (CB) QoS, 488–489class-based traffic policing

configuring, 504–505, 505description, 456token buckets, 500–504, 502–503

class-based traffic shaping, 500configuring, 506–508token buckets, 500–501

class-based weighted fair queuing (CBWFQ), 454–455

class-based WRED (CB-WRED), 498class-default command, 497class-map command, 489–490class-map voice-traffic command, 520class maps, 489–492Class of Restriction (COR), 372–377, 373Class of Service (CoS), 445, 459–460, 459–460Class Selector (CS) PHB, 453class voice-policy command, 521classification, traffic, 444–445classification markings, baseline, 462–463classification models in QoS

Best-effort, 447, 449DiffServ. See DiffServ QoS modelIntServ, 447–449

clear call history voice command, 426clear h323 gateway h225 command, 235clear mgcp statistics command, 264CLI (command line interface) in QoS, 446clid command, 127clid strip pi-restrict command, 249clid substitute name command, 248clock source command, 63–64clock source line command, 213clock timezone command, 293clocking, 63–65, 192CO (central office)

overview, 4–5, 4trunks, 7, 7

codec commandephones, 309modem pass-through, 367SCCP, 344

codec complexity command, 158–159codec preference command, 229–230codec transparent command, 424codecs

bit rate, 166–167choosing, 163–164complexity, 156–160CUBE negotiation, 417H.323 preference, 229–231transparency, 424types, 153–156

cold spares, 297colons (:) ephone button separator, 318comfort-noise command, 151comfort noise synthesis, 151command line interface (CLI) in QoS, 446commas (,) for prefix adding, 125Committed Access Rate (CAR), 456committed burst (Bc), 506

536 Cisco Unified Border Element (CUBE) – committed burst (Bc)


Committed Information Rate (CIR), 500–501

Common Channel Signaling (CCS), 56, 61–62companding, 55compatibility

codecs, 158–159ephone-DN line, 163inline power switches, 284–285

complexity of codecs, 156–160, 164compressed RTP (cRTP)

header compression, 166overhead, 82–83

compressionanalog-to-digital conversion, 54–55CB header, 512–513end-to-end delays, 442link efficiency, 457–458, 458packets, 493

compression command, 493compression header ip command, 512conf-dial-peer mode, 359–360conf-serv-sip mode, 306conf-voi-serv mode

CUBE, 422fax pass-through, 364fax relay, 360H.323, 227, 229modem pass-through, 367SIP, 248

conference calling, 147, 147config-class mode, 232config-cm-fallback mode, 376–377config-cmap mode, 490config-controller mode

T1 CAS, 192T1 PRI, 196

config-dial-peer mode, 354fax pass-through, 364H.323, 354outbound dial peers, 214SIP, 242–243, 425

config-dp-cor mode, 374config-dsp-farm-profile mode, 199config-ephone mode, 330, 332config-ephone-dn mode, 308config-ephone-type mode, 309config-gk mode, 406, 411–412config-if mode

AutoQoS, 475, 488MLP, 509QoS, 495trust boundaries, 513

config-pmap mode, 493config-pmap-c mode, 493, 512config-register-global structure, 306config-sccp-ccm mode, 201config-serv-h323 mode, 231config-serv-sip mode, 242, 247config-sip-ua mode, 240–241, 243–247config-telephony mode, 300, 304–305, 310,

325, 329config-voi-serv mode, 242, 359, 425config-voicecard mode, 158config-voiceport mode, 180–181, 207configure terminal command, 47–50conflicts, IP address, 293conform-actions with token buckets,

502–504, 502–503Confucius, 170Congestion informational signals, 38congestion management

avoidance techniques, 498–500, 499baseline congestion, 463DiffServ, 453–455

connect timer, 245connect voice-port command, 194CONNECTED ephone extension state, 336, 338–339connection plar command, 183Contributing Source (CSRC) field in RTP

headers, 81controller command, 63conversion, analog-to-digital. See analog-to-

digital conversionCOR (Class of Restriction),

372–377, 373CoS (Class of Service), 445, 459–460, 459–460cos option

class maps, 491trust boundaries, 514

CoS-to-DSCP mappings, 514–516, 515, 519–520country codes

E.164 telephone numbers, 113–114FXS ports, 47–48progress tones, 181–182

CP (call progress) tones, 38cp-tone command, 47CPE (customer premise equipment), 35cptone command, 181–182CQ (custom queuing) mechanism, 454CRC (cyclic redundancy check) feature, 58CRCX (create connection) command, 256create cnf-files command, 305create profile command, 307cRTP (compressed RTP)

Committed Information Rate (CIR) – cRTP (compressed RTP) 537


cRTP (compressed RTP) (continued)header compression, 166overhead, 82–83

CS (Class Selector) PHB, 453csim start command, 209CSRC (Contributing Source) field in RTP

headers, 81CSRC counter field in RTP headers, 80CUBE. See Cisco Unified Border Element (CUBE)CUCM (Cisco Unified Communications

Manager), 16, 420configuring, 201–202, 202gatekeepers, 89–90IP soft phones, 13–14RTP, 79

CUCM Express, 281–282capabilities, 294–295date and time format, 328default phone configuration file, 304–305ephones

button options. See button separator options for ephone

extension states, 336–339registration states, 335–336state, 334–335

exam essentials, 340–341firmware load files, 303–304, 304hands-on labs, 342–345, 342hardware requirements, 295initial configuration, 297–298IP phone

keepalive timer, 329restart vs. reset, 329–332

overview, 293–294review questions, 346–351SCCP

ephone configuration, 308–310, 314–317ephone directory number, 308ephone-DN line configuration,

311–313, 313–314individual lines, 317–318phone operation, 343–344signaling, 300–305, 301–304

SIPsignaling, 305–307voice register DNs, 310–311

software licensing, 296–297summary, 339as TFTP server, 298–300, 342–343troubleshooting

DHCP, 332–333phone registrations, 332TFTP, 333–334

user locale and network locale, 325–328voice network infrastructure

power options for IP phones, 282–286VLANs, 286–290, 287, 289VoIP support, 290–293

written lab, 341–342, 352CUCMBE (Cisco Unified Communications

Manager Business Edition), 16CUCME (Cisco Unified Communications

Manager Express), 16, 294–295custom queuing (CQ) mechanism, 454customer premise equipment (CPE), 35cyclic redundancy check (CRC) feature, 58

DD (delta) channel, 61date-format command, 328date format in CUCM Express, 328de-jitter buffer delay, 152debug dialpeer command, 209–210debug ip dhcp server events command, 332debug ras command, 415–416debug tftp events command, 333debug voice translation command, 134debug voip dialpeer command, 134debug voip ipipgw command,

426–427DECEASED ephone registration state,

335–337default command, 412default-technology keyword, 409defaults

DHCP routers, 291–292dial peer 0, 112PHB, 451phone configuration files, 304–305SIP retry settings, 246zone bandwidth, 412

delay, network, 151–152delay-dial command, 50delay-dial E&M signaling, 46, 46delayed offer in SIP, 238, 238delayed-to-early-offer signaling, 425delta (D) channel, 61demarcation point (demarc) points, 5, 5deployment models, 20

centralized services, 20, 21distributed services, 21, 21geographical diversity, 22–23, 23inter-networking of services, 22, 22

538 cRTP (compressed RTP) – deployment models


deregulation, 8destination-address mac option, 491destination-pattern command

dial-plan digit manipulation, 123DNIS, 112FSX ports, 184outbound dial peers, 112–113, 214POTS dial peer, 109SIP, 270tool bypass, 385–386VoIP dial peers, 109wildcards, 117–120, 119, 121

detector state in voice port tests, 207dhcp-config mode, 291DHCP relay command, 292DHCP (Dynamic Host Control Protocol) services

monitoring and troubleshooting, 292–293, 332–333

for voice, 290–292dial peer 0, 112dial-peer command

FSX ports, 184H.323, 228

dial-peer cor custom command, 374dial-peer voice command, 214

H.323, 227POTS, 109SIP, 270tool bypass, 385–386VoIP, 109

dial-peer voice 911 pots command, 214dial peers

gatekeeper interoperations, 410–411inbound rules, 111–112outbound rules, 112–113POTS, 372, 381T1 CAS, 194wildcards, 117–121, 119, 121

dial-plan digit manipulation, 104, 123digit stripping, 123–124forwarding last X digits, 124–125number substitution, 126–127prefixes, 125translation rules and profiles, 127–132verifying, 132–134

dial plan path-selection process, 104call routing, 108–111, 110–111International Numbering Plan,

113–114, 114NANP, 114–116, 115private plans, 116–117PSTN, 113

site-code dialing, 122–123, 122strategies, 111–113voice call types, 104–108, 105–108wildcards, 117–121, 119, 121

Dial tone informational signals, 38dial-type command, 49, 183Dialed Number Identification Service (DNIS)

interfaces, 111–112DID (direct inward dial)

inbound ports, 184–187, 185PSTN, 116ranges 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, 453congestion avoidance, 455congestion management, 453–455link-efficiency techniques, 457–459, 458traffic policing and shaping, 455–457,

456–457DiffServ ToS/DS byte, 449–450, 450digit-collection methods, IP phones,

305–306digit-drop keyword, 355–356digit manipulation. See dial-plan digit

manipulationdigit stripping, 123–124digital ports, 56

configuring, 63–65CUCM, 201–202, 202DSP profiles, 199–200SCCP, 200–201T1 CAS to analog cross-connect,

191–195, 191T1 PRI, 195–198, 195

digital signal processors (DSPs), 18, 146, 156–159chipsets, 157–160CUCM configuration, 201–202, 202delay from, 152exam essentials, 210–211farms, 198–199, 198profiles, 199–200SCCP communications, 200–201status, 205–206summary, 210voice gateway functions, 146–147, 147written lab, 211

digital telephones, 3digital trunks, 54digital voice, 51

deregulation – digital voice 539


digital voice (continued)analog-to-digital conversion, 51–55, 52–54exam essentials, 66–67framing, 57–58, 58multiplexing, 56–57, 57physical transport, 59, 59–60port configuration, 63–65port types, 56review questions, 69–74signaling, 60–63summary, 66written lab, 67–68, 75

dir flash command, 298–299, 343direct inward dial (DID)

inbound ports, 184–187, 185PSTN, 116ranges and extensions, 122

direct-inward-dial command, 185–186directory aliases, 299discard-class command, 491disconnect timer, 245discovery messages in H.323, 399–400discrete signals, 52distributed call-control systems, 93distributed services deployment model, 21, 21DLCX (delete connection) command, 256DNIS (Dialed Number Identification Service)

interfaces, 111–112DNs

configuring, 301–302SCCP, 308SIP voice register, 307, 310–311

DNS servers, 291–292dollar signs ($) in regular expressions,

128–129domain names, 87, 291–292DOWN ephone extension state, 336–337drop option, 493drop precedence, 452dropped calls, 159ds0-group command

MGCP, 259T1 CAS circuits, 64, 193–194

DSCP (Differentiated Services Code Point), 445, 451–453, 451, 514

dscp commandclass maps, 491trust boundaries, 514

dscp-based command, 498DSCP or IP Precedence Value setting, 499DSCP-to-CoS mappings, 514dspfarm_assist keyword, 309

DSPs. See digital signal processors (DSPs)

DTMF (dual-tone multi-frequency), 36, 37

dtmf command, 49dtmf-package packages, 258–259, 356dtmf-relay command, 354, 356DTMF relay support, 354

H.323, 354–355MGCP, 356SIP, 355–356

dual-bucket traffic, 502–504, 502–503dual-line phones, 315–317dual-tone multi-frequency (DTMF), 36, 37dynamic auto trunk mode, 288dynamic desirable trunk mode, 288dynamic gatekeeper discovery, 400Dynamic Host Control Protocol (DHCP)

servicesmonitoring and troubleshooting,

292–293, 332–333for voice, 290–292

EE.164 standard, 113–114, 114E wire in E&M signaling, 42E1 ports, 56E&M ports and signaling, 35, 41–42

configuring, 50line-seizure, 43–46, 44–46physical wiring types, 42–43trunks, 187–188, 187

E911 callingoutbound dial peers, 214ports, 213trunks, 188–189, 189X11 services, 116

Early Media in H.323, 226, 226early-offer forced command, 425early offer in SIP, 237, 237earth wire in E&M signaling, 42–43echo and echo cancellation, 148–149echo-cancel command, 149echo return loss (ERL) levels,

207, 209ECM (error correction mode), 361–362ecm command, 362ecm disable command, 361ECN (explicit congestion notification), 451

540 digital voice – ECN (explicit congestion notification)


edge devices, 3EF (Expedited Forwarding) PHB, 452egress interface traffic, 445802.1Q trunk links, 289802.3af standard, 284–285email, TIFF-attached, 366emergency calls

outbound dial peers, 214ports, 213trunks, 188–189, 189X11 services, 116

en-bloc digit collection, 305–306encapsulation, trunk, 288encapsulation ppp command, 510encoding process in analog-to-digital conversion,

53–54, 54encryption

payloads, 83SIP passwords, 240

end command, 213end-to-end delays, 442endpoints, 11

analog-to-IP adapters, 15codec issues, 164gatekeepers for, 90IP soft phones, 13–14private plans, 117SIP

availability, 239capabilities, 237–239, 237–238locations, 237

video phones and tablets, 14, 14wired IP phones, 12–13

enterprisesAutoQoS for, 483, 484wired IP phones, 12–13

EPCF (endpoint configuration) command, 256ephone-config mode, 318ephone-dn command, 344ephone-DNs

configuring, 301–303, 302–303dual- and octo-lines, 315–317SCCP line configuration, 311–313,

313–314two with one number, 314–315

ephone-type command, 309ephones, 307

button options. See button separator options for ephone

configuring, 301–303, 302–303directory number, 308extension states, 336–339

registration states, 335–336SCCP configuration, 308–310state, 334–335, 344–345

ERL (echo return loss) levels, 207, 209error correction mode (ECM), 361–362ESF (Extended Super Frame), 58, 58exceed-action for token buckets, 502–505,

502–503excess burst (Be) rate, 506exit command, 213expansion line (x) ephone button separator,

319, 324Expedited Forwarding (EF) PHB, 452expires timer, 245explicit congestion notification (ECN), 451Extended Super Frame (ESF), 58, 58extension field in RTP headers, 80extension states for ephones, 336–339extensions in PBX systems, 10, 317

Ff (feature ring) ephone button separator, 318f8 cipher mode, 83fallback, 87

MGCP-to-H.323, 370–372, 371WAN-to-PSTN, 369–370, 369

fallback keyword, 360farms, DSP, 198–199, 198fast command, 424fast start in H.323, 226, 228–229fast-to-slow signaling, 424–425fax protocol t38 command, 359fax rate command, 360fax-relay command, 361fax-relay ans-disable command, 362fax-relay sg3-to-g3 command, 362fax transmission package, 257faxes

fax relay, 357–359, 358MGCP settings, 364, 364pass-through, 364–365SIP and H.323 settings, 360T.37 store-and-forward, 365–367, 366T.38, 362–363

feature licenses for CUCM Express, 296feature ring (f) ephone button separator, 318FIFO (first-in first-out) queuing

mechanism, 453filters, low-pass, 52

edge devices – filters, low-pass 541


firewalls in VoIP, 80firmware load command, 307firmware load files, 303–304, 304first-in first-out (FIFO) queuing

mechanism, 453fixed-bytes setting, 230fixed delay, 151–152flex option, 160flow option, 491Foreign Exchange Office (FXO) ports, 35, 40

configuring, 49–50, 180–184, 180outbound, 184–187, 185

Foreign Exchange Station (FXS) ports, 34configuring, 47–49, 180–184, 180inbound, 184–187, 185

forward-digits command, 124–125, 214forward-digits all command, 214forward-digits shutdown command, 191FQDNs (fully qualified domain

names), 406fr-de option, 491fr-dlci option, 491Frame Relay, 510–512frame-relay fragment command, 511frames

calculations, 165, 167–169, 169compression techniques, 457–458, 458digital voice, 57–58, 58frame errors and packet loss, 443size information, 165–166, 166

framing command, 63, 192framing esf command, 213FRF.12, 510–511fully qualified domain names (FQDNs), 406FXO (Foreign Exchange Office) ports, 35, 40

configuring, 49–50, 180–184, 180outbound, 184–187, 185

fxr-package package, 257FXS (Foreign Exchange Station) ports, 34

configuring, 47–49, 180–184, 180inbound, 184–187, 185

GG.711 codec, 54–55, 154G.711mu-law and G.711a-law, 364G.722 codec, 155G.723.1 codec, 154–155G.726 codec, 155G.728 codec, 155

G.729 codec, 155–156gatekeeper command, 406Gatekeeper Confirm (GCF) message, 399–400Gatekeeper Reject (GRJ) message, 399–400Gatekeeper Request (GRQ) message,

399–400gatekeepers. See H.323 gatekeepersgateway command, 411gateway force option, 362gateways. See voice gatewaysGCF (Gatekeeper Confirm) message,

399–400generic traffic shaping (GTS), 506geographical diversity deployment model,

22–23, 23glare, 40gm-package packages, 258–259Goodbye RTCP packets, 82GRJ (Gatekeeper Reject) message, 399–400ground-start signaling, 40–41, 41ground wire in supervisory signaling, 38–39groundstart signaling, 181group 3 fax machines, 357growth, dialing plans for, 113GRQ (Gatekeeper Request) message,

399–400GSM Full Rate (GSMFR) codec, 156GTS (generic traffic shaping), 506gw-controlled command, 368gw-priority command, 407gw-type-prefix command, 408, 430

HH.225 protocol

description, 85settings, 231–232timers, 232–233

H.235 protocol, 85H.245 protocol, 85H.323 gatekeepers, 89–91, 89–90, 396

address translation, 398bandwidth control, 398bandwidth management, 399call admission control, 398, 411–414, 413call authorization, 398–399call management, 399configuration overview, 405, 405debug ras command, 415–416dial peers, 410–411

542 firewalls in VoIP – H.323 gatekeepers


enabling, 411exam essentials, 427–428hands-on labs, 429–431, 429interface commands, 409–410overview, 396RAS messages, 399–400

bandwidth, 404–405call admission, 400–401location, 402–404, 402–404registration, 400resource availability, 404

review questions, 432–437sample network, 401–402, 401show gatekeeper calls command, 414–415show gatekeeper endpoints

command, 415show gatekeeper status command, 414signaling, 399–401summary, 427technology prefixes, 408–409written lab, 428–429, 438zones

local, 406managing, 397–398, 397prefixes, 407remote, 406–407

H.323 protocolcodec preference, 229–231DTMF relay, 354–355fast and slow start connections, 228–229fast-to-slow signaling, 424–425fax settings, 360gatekeepers. See H.323 gatekeepersgateway configuration, 227–228, 228H.225 settings, 231–233MCU, 91–92MGCP-to-H.323 fallback, 370–372, 371overview, 84–85, 224–226, 224–226proxy servers, 91sample network, 92–93, 92session transport mode, 231show gateway command, 234show h323 gateway h225 command, 234–236T.38 fax relay with, 359–360virtual gateway addresses, 233–234, 233

H.450 protocol, 85h225 timeout setup command, 233h225 timeout tcp call-idle command, 232h225 timeout tcp establish command, 232h245-alphanumeric method, 355h245-signal method, 355

h323-gateway voip command, 409h323-gateway voip interface

command, 431h323-id command, 410hardware

codec compatibility, 163CUCM Express, 295voice gateways, 18–19, 19

header compression, 458header fields in RTP, 80–81high-complexity codec calls, 157–160high-speed fax relay redundancy, 359house wiring, 5hs-redundancy option, 359–360hs_redundancy option, 362huntstop command, 315–316huntstop channel command, 316hybrid systems, 323hyphens (-) in dates, 328

Iid keyword, 410identifier setting, 200IDLE ephone extension state, 336–337IEEE 802.3af standard, 284–285IETF (Internet Engineering Task Force)

protocols, 85IFP (Internet fax packets), 358ignored packets, 443iLBC (Internet Low Bit Rate Codec), 156ILP (inline power) functionality, 283–286immediate signaling type, 50immediate-start E&M signaling, 44, 44impedance

FXS ports, 48mismatches, 149

impedance command, 207implementation phase in AutoQoS, 488inbound calls, translation profiles for, 132inbound dial-peer rules, 111–112inbound SIP transport protocols, 243–244incoming called-number command,

111–112, 185informational signaling, 35, 37–38inhibit command, 362inject-tone state, 207inline power (ILP) functionality, 283–286input-interface option, 491

H.323 protocol – input-interface option 543


input queue drops, 443installation phase in AutoQoS, 483Integrated Services Digital Network (ISDN)

BRI, 56, 61with H.323, 224, 224with MGCP, 253–254, 254PRI, 62, 64–65, 195–198, 195with SIP, 236, 236, 247–249, 247

Intelligent Power Management (IPM), 285–286inter-networking of services deployment model,

22, 22interactive voice response (IVR) services, 354intercluster trunk calls, 108, 108interdigit timeout, 118interexchange networks, 9interface binding, 233–234, 233interface command for voice gateways, 409interface commands for H.323 gatekeepers,

409–410interface multilink command, 509interface serial command, 213, 521internal T1 CAS option, 63international calling, 8, 9international networks, 9International Numbering Plan,

113–114, 114Internet Engineering Task Force (IETF) protocols,

85Internet fax packets (IFP), 358Internet Low Bit Rate Codec (iLBC), 156Internet Protocol Telephony (IPT), 11Internet Speech Audio Codec (iSAC), 156Internet Telephony Service Providers

(ITSPs), 12, 154, 416, 421–422, 421–422

interoffice trunks, 7–8, 8interwork command, 424interzone keyword command, 412IntServ QoS model, 447–449Invite SIP retry type, 246IOS licenses, 296IP addresses

binding SIP sources to, 247conflicts, 293CUBE, 417CUCM Express, 300–301, 301DHCP

monitoring and troubleshooting, 292–293, 332–333

for voice, 290–292ip command for class maps, 491

ip dhcp excluded address command, 291ip dhcp pool command, 291ip-helper address command, 292IP networks

bandwidth, 441–442end-to-end delays, 442jitter, 442packet loss, 443–444, 443SIP configuration, 239–241, 240voice issues, 441–444, 443voice/video on, 440–441

IP phonesdigit-collection methods, 305–306keepalive timers, 329power options, 282–286restart vs. reset, 329–332soft phones, 13–14VLAN configuration, 288–290, 289wired, 12–13wireless, 13

IP Precedence in ToS byte, 449–450, 450ip source-address command, 307, 343IP-to-IP gateways, 416IP to PSTN translations, 87IP/UDP header size, 165IP voice bandwidth consumption, 164

calculations, 165, 167–169, 169codec bit rate, 166–167packet and frame size information,

165–166, 166providing, 441–442

IPM (Intelligent Power Management), 285–286IPSec, 166, 166IPT (Internet Protocol Telephony), 11iSAC (Internet Speech Audio

Codec), 156ISDN. See Integrated Services Digital Network

(ISDN)isdn incoming-voice command, 197isdn incoming-voice voice command, 213isdn supp-service name calling

command, 248isdn switch-type command, 64, 196isdn switch-type primary-ni

command, 212ISR router series, 19ITSPs (Internet Telephony Service Providers), 12,

154, 416, 421–422, 421–422ITU-T T.38 fax relay, 358–359, 358IVR (interactive voice response)

services, 354

544 input queue drops – IVR (interactive voice response)services


Jjitter, network, 152–153, 152, 442

Kkeepalive command, 329keepalive timers, phone, 329key systems, 10–11, 311–312

Llanguages in CUCM Express, 325–328LATAs (Local Access and Transport Areas), 8Layer 2 CoS, 459–460, 459–460Layer 2 header size, 165LCF (Location Confirm) message,

402–404, 403LdapDirectories.xml files, 334leases, DHCP, 291–292legacy PBX, 187–188, 187LFI (link fragmentation and interleaving),

457–459, 509–512licensing CUCM Express, 296–297lightweight registration messages, 400Lincoln, Abraham, 443line command, 63line-package packages, 256, 258line seizure, 40

E&M signaling, 43–46, 44–46ephone extension state, 336–338

linecode command, 63, 192linecode b8zs command, 213link efficiency, 457, 508–509

compression, 457–458, 458, 512–513LFI, 509–512

link fragmentation and interleaving (LFI), 457–459, 509–512

listener echo, 149lists in regular expressions, 128LLQ (Low Latency Queuing), 455load files in CUCM Express, 303–304, 304Local Access and Transport Areas (LATAs), 8local calls, 105, 105local loop, 5, 5local name segment in MGCP, 87local zones, 406locales in CUCM Express, 325–328Location Confirm (LCF) message,

402–404, 403

location messages in RAS, 402–404, 402–404Location Reject (LRJ) message, 402–403, 403Location Request (LRQ) message,

402–404, 403log option, 493loop-start signaling, 39–40, 39, 181loopback interface, 233–234, 233loopback state in voice port tests, 207loopstart signaling, 181low-bit-rate keyword, 356low-complexity codec calls, 157–160Low Latency Queuing (LLQ), 455low-pass filters, 52low-speed fax relay redundancy, 359low-speed WAN connections, 457LRJ (Location Reject) message, 402–403, 403LRQ (Location Request) message,

402–404, 403ls-redundancy option, 359–360ls_redundancy option, 362

Mm (monitor line) ephone button separator,

318–320, 320M wire in E&M signaling, 42mac-address command, 310, 344MAC addresses for ephones, 310magnet wire in E&M signaling, 42–43management, dialing plans for, 113map-class frame-relay command, 511maps

class, 490–492CoS-to-DSCP, 514–516, 515, 519–520policy, 493–495

Mark Probability Denominator setting, 499marker field in RTP headers, 81marking traffic, 445match-all command, 490, 492match-any command, 490, 492max-dn command, 302–303, 343max-ephones command, 302, 343max-forwards command, SIP, 246max-pool command, 307maximum sessions command, 199–200, 367maximum sessions hardware command, 200Maximum Threshold (Number Of Packets)

setting, 499MC (Multipoint Controller), 92MCU (Multipoint Control Unit), 91–92MDCX (modify connection) command, 256

jitter, network – MDCX (modify connection) command 545


Mean Opinion Score (MOS) test, 161–162media flow-around, 418–419, 419, 423media flow-around command, 423media flow-through, 418, 418Media Gateway Control Protocol

(MGCP), 87–88DTMF relay, 356fallback, 87, 370–372, 371fax relay with, 362–363fax settings, 364, 364overview, 253–254, 254residential gateways, 254–255, 255,

257–259, 258show ccm-manager command, 264–265show mgcp command, 261–263show mgcp profile command, 260–261show mgcp statistics command, 263–264trunking gateways, 255–257, 255,

259–260, 260media termination point (MTP), 146–147medium-complexity codec calls, 157–160mgcp call-agent command, 257, 259mgcp dtmf-relay voip codec

command, 356mgcp fax rate command, 363mgcp fax t38 command, 362mgcp fax t38 inhibit command, 365mgcp modem passthrough voip mode nse

command, 365mgcp modem relay voip mode command, 368mgcp package-capability command, 257–258mgcp package-capability rtp-package

command, 365mgcp timer nse-response t38

command, 363MGCP-to-H.323 fallback, 370–372, 371mgcp tse payload command, 363Minimum Threshold (Number Of Packets)

setting, 499minus signs (-) in regular expressions, 128MLP (multilink PPP), 509–510mls qos command, 482mls qos map command, 516mls qos trust command, 513–514mls qos trust cos command, 519mode cme command, 306modem relay command, 368modems, 367

pass-through, 367–368relay, 368

modular QoS CLI (MQC) method, 447policies using, 488–498, 489,

520–521

show class-map command, 496show policy-map command, 496show policy-map interface command,

496–497MOH (music on hold), 150monitor line (m) ephone button separator,

318–320, 320monitoring DHCP service, 292–293MOS (Mean Opinion Score) test,

161–162MP (Multipoint Processor), 92mpls option, class maps, 491MQC. See modular QoS CLI (MQC) methodMTP (media termination point), 146–147mu-law codecs, 365multilink PPP (MLP), 509–510multiplexing, 54, 56–57, 57Multipoint Control Unit (MCU), 91–92Multipoint Controller (MC), 92Multipoint Processor (MP), 92music on hold (MOH), 150

Nnamed service events (NSE), 359NANP (North American Numbering Plan),

114–116, 115, 190narrowband communication, codecs for, 154narrowband sampling, 148, 148national calling PSTN, 8, 9National Destination Code (NDC), 113–114National Institute of Standards and Technology

(NIST), 293NBAR (Network-Based Application Recognition)

feature, 475NDC (National Destination Code), 113–114netflow-sampler option, 493Network-Based Application Recognition (NBAR)

feature, 475network capacity in codec selection, 164network delay, 151–152network infrastructure, 20network jitter, 152–153, 152network-locale command, 326–327network locales in CUCM Express, 325–328network-number command, 127Network Time Protocol (NTP), 290, 293never command in PoE, 2859951 IP video phone, 14NIST (National Institute of Standards and

Technology), 293

546 Mean Opinion Score (MOS) test – NIST


no command in QoS policy maps, 493no digit-strip command

CAMA, 191forwarding digits, 124–125tool bypass, 385WAN-to-PSTN fallback, 369

no huntstop command, 315, 321no maximum sessions command, 200no shutdown command

CAMA, 190–191, 213DSP profiles, 199FSX ports, 182H.323 service, 411local zones, 406voice port tests, 207VoIP service, 227

noise, background, 149–151, 150non-standard facilities (NSF) code, 362none keyword in SIP, 248normal ring (:) ephone button separator, 318North American Numbering Plan (NANP),

114–116, 115, 190not option for class maps, 491NPD (Numbering Dialing Plan) in emergency

calls, 190NSE (named service events), 359nse keyword

modem pass-through, 367T.38 fax relay, 359

NSF (non-standard facilities) code, 362nsf option, 362NTFY (notify) command, 256NTP (Network Time Protocol), 290, 293ntp server command, 293NULL ciphers, 83NULL rules, 129num-exp command, 126number command, 310–311Number not in service informational

signals, 38number substitution, 126–127Numbering Dialing Plan (NPD) in emergency

calls, 190Nyquist, Harry, 52Nyquist Sampling Theorem, 52, 52

Oo (overlay line) ephone button separator,

319–323octo-line phones, 315–317

off-hook statepulse dialing, 36supervisory signaling, 38–39, 39

off-net calls, 106, 106off-premises extension (OPX), 180off-ramp gateways, 366–367, 366on-hook state

pulse dialing, 36supervisory signaling, 38–39, 39

on-net calls, 105, 105on-net-to-off-net calls, 106, 107on-ramp gateways, 366–367, 366one-stage dialing, 186operation command, 50option command in DHCP, 291OPX (off-premises extension), 180out-of-band signaling, 61outbound calls, translation profiles for, 132outbound dial peers

to PSAP, 214to PSTN, 214rules, 112–113

outbound SIP transport protocols, 243–244overlay line (o) ephone button separator,

319–323overlay with call waiting (c) ephone button

separator, 319, 323–324override keyword in trust boundaries, 515overruns, packet loss from, 443

Ppackages, 256–259packet loss concealment (PLC)

methods, 153packet option for class maps, 491packetization delay, 152packets

information for, 165–166, 166loss of, 153, 443–444, 443

packets per second (PPS), 165, 167–168padding field in RTP headers, 80PAM (pulse-amplitude modulation), 51parent maps, 494parentheses ()

destination pattern wildcards, 120in regular expressions, 128–130

pass-throughfax, 364–365modems, 367–368

pass-through keyword, 360

no command in QoS policy maps – pass-through keyword 547


pass-through dscp keywords, 514passwords in SIP, 240Payload Encryption packets, 83payload type field in RTP headers, 81PBX (private branch exchange) systems, 10

E&M trunks with, 187–188, 187extensions, 317

PBX-to-PBX calls, 107, 107PBX-to-PBX switch connections, 40PBX-to-PSTN switch connections, 40PCM (pulse-code modulation),

53, 53, 55, 154peak information rate (PIR), 504peak keyword, 506peer-to-peer architecture, 84–85peer-to-peer protocols

H.323, 224SIP, 236UDP, 86

per-hop behaviors (PHB), 451–453percent signs (%) in destination pattern

wildcards, 120Perceptual Evaluation of Speech Quality (PESQ)

measure, 163Perceptual Objective Listening Quality Analysis

(POLQA), 163Perceptual Speech Quality Measure (PSQM),

162–163periods (.)

destination pattern wildcards, 118–119, 119

in regular expressions, 128–130PESQ (Perceptual Evaluation of Speech Quality)

measure, 163phantom power, 283PHB (per-hop behaviors), 451–453phone configuration files, 304–305phone registrations, 332phone switches, 3–4phones, IP. See IP phonesphysical transport in digital voice, 59, 59–60physical wiring in E&M signaling, 42–43PIR (peak information rate), 504PLAR (Private Line Automatic Ringdown),

180–184PLC (packet loss concealment) methods, 153plus signs (+)

destination pattern wildcards, 120in regular expressions, 128

PoE (Power over Ethernet) switches, 283–285police command, 493, 504policy-map command, 489, 492–493policy-map voice-policy command, 521

policy maps, 493–495QoS, 489service policies, 495

POLQA (Perceptual Objective Listening Quality Analysis), 163

poolsDHCP, 291voice register, 311

port commandoutbound dial peers, 214POTS dial peer, 109

portsanalog voice

configuring, 47–50types, 34–35

digital. See digital voiceinbound dial-peer rules, 112

POTS dial peers, 108–109, 372, 381power

IP phones, 282–286supervisory signaling, 38, 40

power bricks, 282–283power injectors, 283power inline command, 285Power over Ethernet (PoE) switches, 283–285powered patch panels, 283ppp multilink command, 510ppp multilink fragment-delay

command, 510ppp multilink-group command, 510ppp multilink interleave command, 510PPP multilink LFI configuration, 478PPS (packets per second), 165, 167–168PQ (priority queuing), 454–455prec-based keyword, 498precedence option, 491predictor compression method, 458preference command

ephone DNs, 314–315overlay lines, 321tool bypass, 385WAN-to-PSTN fallback, 369

prefix adding, 125prefix command, 125

CAMA, 191tool bypass, 385

prefixestechnology, 408–409zone, 407

PRI (Primary Rate Interface), 62, 64–65, 195–198, 195

pri-group timeslots command, 65, 213primary-5ess command, 65

548 pass-through dscp keywords – primary-5ess command


primary-qsig command, 65Primary Rate Interface (PRI), 62, 64–65,

195–198, 195priorities

call-processing units, 201end-to-end delays, 442gateways, 408IP Precedence, 450QoS policy maps, 493traffic marking, 445

priority percent command, 521priority queuing (PQ), 454–455priority setting

QoS policy maps, 493SCCP, 200

private branch exchange (PBX) systems, 10E&M trunks with, 187–188, 187extensions, 317

Private Line Automatic Ringdown (PLAR), 180–184

private numbering plans, 116–117private switches, 4private telephone systems, 2, 9–10profiles

dial-plan digit manipulation, 127–132DSP, 199–200translation, 131–132

propagation delay, 151–152protocol internetworking, 417protocol interoperation, 422–423, 423protocol option for class maps, 491proxies, CUBE, 417proxy servers

H.323, 91SIP, 86–87, 246–247

PSAPs (Public Safety Answering Points)CAMA trunks, 189outbound dial peers to, 214

PSQM (Perceptual Speech Quality Measure), 162–163

public switched telephone network (PSTN), 3, 8–9, 9

central office, 4–5, 4local loop, 5, 5with MGCP, 253–254, 254number substitution, 126numbering plan, 113outbound dial peers to, 214redundancy, 385–386with SIP, 247–248, 247termination, 146WAN-to-PSTN fallback, 369–370, 369

public telephone systems, 2pulse-amplitude modulation (PAM), 51pulse-code modulation (PCM),

53, 53, 55, 154pulse command, 49pulse dialing, 36, 36pulse interval command, 182PVDM (C549 DSP chipset), 157–158PVDM2 (C5510 DSP chips), 157,

159–160PVDM3 (C5510 DSP chips), 157, 159

QQ.921 signaling, 253Q.931 signaling, 62, 253Q signaling (QSIG), 62–63QoS. See Quality of Service (QoS)qos-group option, 491QSIG (Q signaling), 62–63quality considerations, 147–148

audio fidelity, 148, 148background noise, 149–151, 150echo and echo cancellation, 148–149network delay, 151–152network jitter, 152–153, 152packet loss, 153

Quality of Service (QoS), 439–440AutoQoS. See AutoQoSbaseline models, 461–463, 462Best-effort model, 447, 449class-based, 488–489class maps, 490–492command line interface, 446congestion management, 453–455, 463,

498–500, 499CoS-to-DSCP mappings, 514–516, 515DiffServ model, 448, 453–459DiffServ ToS/DS byte, 449–450, 450DSCP method, 451–453, 451exam essentials, 464–465, 517hands-on labs, 518–521, 518IntServ model, 447–448Layer 2 classification, 459–460, 459–460link efficiency techniques, 457–458, 458,

508–513mitigating IP network voice issues,

441–444, 443models comparison, 448policies

primary-qsig command – Quality of Service (QoS) 549


Quality of Service (QoS) (continued)considerations, 445–447using MQC, 488–498, 489

policy maps, 493–495review questions, 466–471, 522–527settings, 153show class-map command, 496show policy-map command, 496show policy-map interface command,

496–497summary, 464, 517three-step process, 444–445traffic policing and shaping, 455–457,

456–457, 500–508, 502–503, 505trust boundaries

configuring, 513–515, 513identifying, 460–461, 461

voice/video on IP networks, 440–441written lab, 465, 472, 518, 528

quantization in analog-to-digital conversion, 53, 53

question marks (?)destination pattern wildcards, 120in regular expressions, 128

queue-limit option, 493queuing

delay, 152traffic, 445, 456

RR wire in E&M signaling, 42R1 wire in E&M signaling, 42RAC (Resource Availability

Confirmation), 404RAI (Resource Availability Indicator), 404random-detect command, 493, 498Random Early Detection (RED) tool,

455, 498RAS. See Registration Admission and Status

(RAS) messagesRBS (robbed-bit signaling), 60RCF (Registration Confirm) message, 400Real-time Transport Control Protocol (RTCP),

81–82Real-time Transport Protocol (RTP),

17, 78–81header fields, 80–81header size, 165

Receiver off-hook informational signals, 38Receiver Report packets, 81

RED (Random Early Detection) tool, 455, 498

redirect-called type, 131redirect servers

maximum, 246–247SIP with ISDN, 247–249, 247

redundancygateways, 407–408modem pass-through, 367PSTN, 385–386

redundancy keyword, 367register device-name command, 201register servers, 87REGISTERED ephone registration state,

335–339registrar server command, 306Registration Admission and Status (RAS)

messages, 398bandwidth, 404–405call admission, 400–401location, 402–404, 402–404registration, 400resource availability, 404

Registration Confirm (RCF) message, 400registration messages, 400Registration Reject (RRJ) message, 400“Registration Rejected” message, 302, 303Registration Request (RRQ) message, 400registration states for ephones, 335–336registrations, phone, 332regular expressions, 128relay

fax, 357–359, 358, 362–363modem, 368

relay state in voice port tests, 207remote keyword, 412remote zones in H.323, 406–407Reorder informational signals, 38repeaters for analog signal, 51Replay Protection packets, 83reset, IP phone, 330–332reset command, 330reset all command, 330residential gateways, 254–255, 255, 257–259, 258Resource Availability Confirmation

(RAC), 404Resource Availability Indicator (RAI), 404resource availability messages, 404Resource in Progress (RIP), 404Resource Reservation Protocol (RSVP)

CAC, 420, 420QoS, 448

550 Quality of Service (QoS) – Resource Reservation Protocol (RSVP)


Response retry type, 246restart, IP phone, 329–330restart command, 330restart all command, 329retries, SIP, 245–246, 270–271retry invite command, 271retry response command, 271right-to-use licenses, 297Ring-back informational signals, 38ring cadence command, 182ring frequency command, 182ring number command, 183RINGING ephone extension state, 336, 338ringing time, 149RIP (Resource in Progress), 404robbed-bit signaling (RBS), 60rotary dialing, 36, 36routers

DHCP, 291–292Enterprise, 483, 484VoIP on, 475–479, 476

RQNT (request for notification) command, 256RRJ (Registration Reject) message, 400RRQ (Registration Request) message, 400RSIP (restart in progress) command, 256RSVP (Resource Reservation Protocol)

CAC, 420, 420QoS, 448

RTCP (Real-time Transport Control Protocol), 81–82

RTP (Real-time Transport Protocol), 17, 78–81header fields, 80–81header size, 165

rtp-nte method, 355–356rtp-package packages, 258–259

Ss (silent ring) ephone button separator, 318sampling

analog-to-digital conversion, 52–53, 52audio fidelity, 148, 148

SB (signal battery) wire, 42–43SB-ADPCM (Sub-Band Adaptive Differential

Pulse Code Modulation), 155SBCS (Smart Business Communications System)

suite, 12SC (Subscriber Code), 113–115SCCP. See Skinny Client Control Protocol (SCCP)sccp cucm group command, 201

sccp local command, 200SDP (Session Description Protocol)

with MGCP, 254with SIP, 237–238, 238

second-number strip command, 127secure codec option, 160secure RTP (sRTP), 83, 242–243secure RTP packages, 257security

CUBE deployment, 417SIP, 241–243voice packets, 166, 166

Segmented Integer Counter Mode cipher mode, 83SEIZE ephone extension state, 336–338seizure, line, 40

E&M signaling, 43–46, 44–46ephone extension state, 336–338

Sender Report packets, 81separators, button. See button separator options

for ephonesequence field in RTP headers, 81serialization delay, 152, 458service policies

policy maps, 495QoS, 489

service-policy command, 489, 493–495, 513service-policy output voice-policy command,

521service-type mgcp command, 257Session Description Protocol (SDP)

with MGCP, 254with SIP, 237–238, 238

Session Initiation Protocol (SIP), 17, 85–87basic configuration, 269–270call signaling, 12CUCM signaling, 305–307delayed-to-early-offer signaling, 425DTMF relay, 355–356endpoints

availability, 239capabilities, 237–239, 237–238locations, 237

ephone-DN line compatibility, 312fax relay with, 359–360fax settings, 360IP voice gateways, 239–241, 240overview, 236–237register servers, 87secure communications, 241–243sessions, 239show sip-ua calls command, 252–253show sip-ua retry command, 252

Response retry type – Session Initiation Protocol (SIP) 551


Session Initiation Protocol (SIP) (continued)show sip-ua statistics command,

249–251show sip-ua status command, 251show sip-ua timers command, 252timers and retries, 270–271voice gateway settings, 243

binding sources to IP addresses, 247inbound and outbound transport

protocols, 243–244ISDN call-ID blocking, 249ISDN interoperation settings, 247–248, 247proxy and redirect servers, 246–247signaling retries, 245–246signaling timers, 244–245

voice register DNs, 310–311voice register pools, 311

session keyword, gatekeepers, 412session protocol sipv2 command,

241, 270, 355session target command

SIP, 270tool bypass, 385VoIP dial peer, 109

session target ipv4 command, 227, 241session target ras command, 410session target sip-server command, 241session transport mode in H.323, 231session transport tcp calls-per-connection

command, 231session transport udp command, 231sessions, SIP, 239set option in QoS policy maps, 4937921G wireless IP phone, 137925G and 7925G-EX wireless IP

phones, 137985G IP video phone, 14SF (Super Frame), 57–58, 58SG (signal ground) wire, 42–43SG3 (Super Group 3) fax transmissions, 362shape command, 493, 506shared lines with ephone-DN, 312–313, 313–314show auto discovery qos command, 485–487show auto qos command, 477–478show call active voice brief command,

425–426show call history voice brief command, 426show ccm-manager command, 264–265show ccm-manager fallback-mgcp command, 372show class-map command, 496show connection all command, 195show controller command, 205

show dial-peer command, 132–133show dialplan number command, 133–134show ephone command, 321–323, 335–336,

338, 344show frame-relay fragment command, 512show gatekeeper calls command,

414–415show gatekeeper endpoints command, 415show gatekeeper status command, 414show gateway command, 227, 234show h323 gateway h225 command,

234–236show ip dhcp binding command, 292–293show ip dhcp conflict command, 293show mgcp command, 261–263show mgcp profile command, 260–261show mgcp statistics command, 263–264show mls qos maps command, 516show policy-map command, 496show policy-map interface command,

495–497, 507–508show power inline command, 286show run interface fa0/1

command, 481show run interface fastEthernet 0/5

command, 480show sip-ua calls command,

252–253show sip-ua retry command, 252, 271show sip-ua statistics command,

249–251show sip-ua status command, 251show sip-ua timers command,

252, 271show telephony-service tftp-bindings

command, 334show vlan brief command, 290show voice dsp command, 160,

205–206show voice port command, 203–205show voice port summary command,

196–197show voip rtp connections command, 426shutdown command

CAMA, 190–191, 213voice port tests, 207

shutdown forced command, 227side-car modules, 309signal battery (SB) wire, 42–43signal command for FSX ports, 181signal cama command, 213signal ground (SG) wire, 42–43

552 Session Initiation Protocol (SIP) – signal ground (SG) wire


signal groundstart command, 49signal loopstart command, 47signaling

analog voice, 35address, 35–37, 36–37E&M, 41–46, 44–46ground-start, 40–41, 41informational, 37–38supervisory, 38–41, 39, 41

call, 17, 17digital voice, 60–63gatekeeper, 399–401retries, 245–246timers, 244–245

signaling forward command, 248signaling protocols

with CUBE, 419, 419voice gateway. See voice gateway signaling

protocolssilent ring (s) ephone button separator, 318silent rings, 310silent with beep (b) ephone button

separator, 318simplicity, dialing plans for, 113single-bucket traffic, 502–503,

502–503SIP. See Session Initiation Protocol (SIP)SIP ITSP, 421–422, 421–422sip-notify method, 356SIP secure (SIPS) mechanism, 241sip-server command, 241sip-ua command, SIP, 271SIPS (SIP secure) mechanism, 241site-code dialing, 122–123, 122sites in private plans, 117size of frames, 165–166, 166Skinny Client Control Protocol (SCCP),

17, 88configuring, 200–201CUCM Express, 300–305, 301–304with DSP farms, 198, 198ephone configuration, 308–310ephone directory number, 308ephone-DN line configuration, 311–313,

313–314individual lines, 317–318phone operation, 343–344

slashes (/)in dates, 328in regular expressions, 128–130

slow command, 424slow start connections in H.323, 228–229

slow start initiation mode in H.323, 225, 225

small businesses, wired IP phones for, 12Smart Business Communications System (SBCS)

suite, 12Smart Phone Control Protocol (SPCP), 12soft phones, 13–14software-activated voice licensing, 297software licensing for CUCM Express, 296–297source-address command, 307source-address mac command, 491source-bind feature, 247Source Description packets, 82source IP addresses in CUCM Express,

300–301, 301SPA 300 and 500 series IP phones, 12spare phones, 297SPCP (Smart Phone Control Protocol), 12square brackets ([])

destination pattern wildcards, 118–120, 120in regular expressions, 128

SRST (Survivable Remote Site Telephony), 21configuring, 376–377with COR, 373, 373with MGCP, 254

sRTP (secure RTP), 83, 242–243srtp command, 242–243srtp fallback command, 242–243srtp-package package, 257SSDC5, 43SSRC (Synchronization Source Identifier) field in

RTP headers, 81stacker compression method, 458standards for dialing plans, 113states, ephones, 344–345

extensions, 336–339registration, 335–336

static command, 285station-id command, 182store-and-forward fax, 365–367, 366stripping, digit, 123–124Sub-Band Adaptive Differential Pulse Code

Modulation (SB-ADPCM), 155Subscriber Code (SC), 113–115substitution, number, 126–127Super Frame (SF), 57–58, 58Super Group 3 (SG3) fax transmissions, 362supervisory signaling, 35, 38–41, 39, 41Survivable Remote Site Telephony (SRST), 21

configuring, 376–377with COR, 373, 373with MGCP, 254

signal groundstart command – Survivable Remote Site Telephony (SRST) 553


switches and switchports, 3–4, 519inline power, 283–286QoS markings, 519in voice port tests, 207VoIP on, 479–483, 480

switchport access vlan command, 519switchport mode access command, 519switchport mode trunk command, 288switchport trunk encapsulation

command, 288switchport voice vlan command, 289, 519synchronization

CAS, 60CCS, 61ISDN, 62TCP, 498time, 290, 293

Synchronization Source Identifier (SSRC) field in RTP headers, 81

system keyword, 367

TT.30 fax machines, 357–358T.37 fax, 365–367, 366T.38 fax relay

with H.323 and SIP, 359–360with MGCP, 362–363

T wildcard, 118, 121, 121T wire in E&M signaling, 42T1 circuits

CAS configuration, 63–64, 191–195, 191ports, 56–57, 57PRI configurations, 64–65, 195–198, 195,

212–213T1 wire in E&M signaling, 42tablets, 14, 14Tag Control Information (TCI), 459tagged image file format (TIFF),

365–366tail end hop off (TEHO), 377–380,

378, 386talker echo, 149Tc (Time Interval) in token buckets, 500TCI (Tag Control Information), 459TCL (Tool Command Language) scripts, 366TCP (Transmission Control Protocol)

RTP with, 79with SIP, 86synchronization, 498

tcp-traffic keyword, 498TDM (time-division multiplexing),

56–57, 57tech-prefix keyword, 410technology prefixes, 408–409TEHO (tail end hop off), 377–380,

378, 386telephony. See traditional telephonytelephony-service command, 343telephony service event (TSE) payload

size, 363termination, PSTN, 146test voice port command, 206–209test voice translation-rule command,

130, 382tftp-server flash command, 299–300TFTP servers

CUCM Express as, 298–300, 342–343DHCP, 291–292troubleshooting, 333–334

tie trunks, 6–7, 6TIFF (tagged image file format), 365–366time

CUCM Express format, 328synchronizing, 290, 293

time-division multiplexing (TDM), 56–57, 57Time Interval (Tc) in token buckets, 500time-sensitive traffic in end-to-end delays, 442time to live (TTL) in registration

messages, 400time zones, 293timeouts, interdigit, 118timers

H.225, 232–233keepalive, 329SIP, 244–245, 270–271

timers command, 245timers connect command, 271timers disconnect command, 271timers trying command, 271timeslots command, 259timestamp field in RTP headers, 81tip wire in supervisory signaling, 38–39TLS (Transport Layer Security),

86, 241token buckets, 500–504, 502–503toll bypass, 377–380, 378, 385–386tone suppression for faxes, 362Tool Command Language (TCL)

scripts, 366ToS (Type of Service) byte, 449–450, 450total keyword, 412

554 switches and switchports – total keyword


touch-tone pads, 36, 37traditional telephony, 2–3

central office, 4–5, 4edge devices, 3exam essentials, 24local loop, 5, 5phone switches, 3–4private systems, 9–10PSTN, 8–9, 9review questions, 26–31summary, 23–24trunks, 6–8, 6–8written lab, 25, 32

traffic classification in QoS, 444–445traffic marking in QoS, 445traffic policing and shaping

class-based, 504–508DiffServ features, 455–457, 456–457token buckets, 500–504, 502–503

traffic queuing in QoS, 445transcoding, 146translate command, 131translation-profile command, 132, 386translation profiles, 131–132translation rules in dial-plan digit manipulation,

127–132Transmission Control Protocol (TCP)

RTP with, 79with SIP, 86synchronization, 498

transmission rate for faxes, 360transparent setting for H.323 codecs, 230transport

digital voice, 59, 59–60SIP protocols, 243–244

Transport Layer Security (TLS) protocol, 86, 241

transport tcp command, 243triggers for FSX ports, 184troubleshooting

Cisco phone registrations, 332DHCP, 292–293, 332–333TFTP, 333–334

trunk encapsulation command, 288trunk-package packages, 256, 258–259trunking gateways

configuring, 259–260, 260overview, 255–257, 255

trunks, 6CAMA, 188–191, 189, 213central office, 7, 7digital, 54

E&M, 187–188, 187intercluster, 108, 108interoffice, 7–8, 8tie, 6–7, 6VLANs, 286–288, 287

trust boundariesconfiguring, 513–515, 513identifying, 460–461, 461

trust keyword in AutoQoS, 475–476, 479trying timer, 245TSE (telephony service event) payload

size, 363TTL (time to live) in registration messages, 400tunnels for voice packets, 166, 1662900 and 3900 series ISR routers, 19two-stage dialing, 186type command for ephones, 309Type of Service (ToS) byte, 449–450, 450

Uu-law algorithm, 55UAC (user agent clients), 86UAS (user agent servers), 86UAs (user agents) in SIP, 86, 240UC500 series products, 12UDP (User Datagram Protocol), 79–80, 86unconditional keyword, 248Unified Communications Model overview, 11

applications, 15call processing agents, 15–17, 17endpoints, 11–15, 14exam essentials, 24network infrastructure, 20–23, 21–23review questions, 26–31summary, 23–24voice gateways, 18–19, 19written lab, 25, 32

Uniform Resource Locators (URLs), 86Unity Express voicemail module, 294UNREGISTERED ephone registration state,

335–337upgrades of key systems, 10url sips command, 242URLs (Uniform Resource Locators), 86User agent clients (UAC), 86User agent servers (UAS), 86user agents (UAs) in SIP, 86, 240User Datagram Protocol (UDP),

79–80, 86

touch-tone pads – User Datagram Protocol (UDP) 555


user licenses for Cisco phone, 297user-locale command, 325–326user locales in CUCM Express, 325–328usernames in SIP, 240

VVAD (Voice Activity Detection), 150–151,

150, 156variable delay, 152version field in RTP headers, 80version setting in SCCP, 200VG200 series appliances, 15video phones, 14, 14violate-action command, 505violate-actions for token buckets, 503–505virtual dial peers in CUCM, 294virtual gateway addresses, 233–234, 233vlan option for class maps, 491VLANs

configuring and verifying, 288–290, 289trunks, 286–288, 287

voiceanalog. See analog voiceclipping, 150digital. See digital voiceIOS licenses, 296IP network issues, 441–444, 443

Voice Activity Detection (VAD), 150–151, 150, 156voice backup paths, 368–369

COR, 372–377, 373MGCP-to-H.323 fallback, 370–372, 371SRST, 376–377WAN-to-PSTN fallback, 369–370, 369

voice call typesintercluster trunk, 108, 108local, 105, 105off-net, 106, 106on-net, 105, 105on-net-to-off-net, 106, 107PBX-to-PBX, 107, 107

voice class codec command, 230voice class h323 command, 232–233voice-class sip url sips command, 242Voice Codec Bandwidth Calculator,

169, 169voice codecs, 153

clarity, 160–163complexity, 156–160types, 153–156

voice gateway ports, 179–180CAMA trunks, 188–191, 189csim start command, 209CUCM, 201–202, 202debug dialpeer command, 209–210DSP profiles, 199–200E&M trunks, 187–188, 187exam essentials, 210–211FXS and FXO PLAR OPX, 180–184, 180FXS/DID inbound and FXO outbound,

184–187, 185hands-on labs, 212–214, 212review questions, 215–221SCCP, 200–201show controller command, 205show voice dsp command, 205–206show voice port command, 203–205summary, 210T1 CAS to analog cross-connect,

191–195, 191T1 PRI, 195–198, 195test voice port command, 206–209written lab, 211, 222

voice gateway signaling protocols, 83–84, 84, 223–224

comparisons, 88exam essentials, 266–267H.323. See H.323 protocolhands-on labs, 268–271, 268MGCP. See Media Gateway Control Protocol

(MGCP)review questions, 272–278SCCP, 88selecting, 93SIP. See Session Initiation Protocol (SIP)summary, 265written lab, 267–268, 279

voice gateways, 18–19, 19, 353–354call blocking, 380–382dial peers, 410–411DSP farms on, 198–199, 198DSP functions, 146–147, 147DTMF relay support, 354–356exam essentials, 382–383fax. See faxesH.323 interface commands, 409–410H.323 service on, 411hands-on labs, 384–386, 384modems, 367–368redundancy, 407–408review questions, 387–392

556 user licenses for Cisco phone – voice gateways


SIP settings, 243–249, 247summary, 382toll bypass and TEHO, 377–380, 378voice backup paths. See voice backup pathswritten lab, 384, 393

voice media transmission protocols, 78cRTP, 82–83RTCP, 81–82RTP, 78–81sRTP, 83

voice network infrastructure considerationspower options for IP phones,

282–286VLANs, 286–290, 287, 289VoIP support, 290–293

voice payload size, 165voice-port command, 47–50, 63voice register dn command, 310voice register DNs, 310–311voice register global command, 306voice register pools, 307, 311voice service voip command, 227,

229, 269, 422voice translation-profile command,

131, 386voice translation-rule command,

129, 386voice transport, 17, 17voice/video hardware protocols, 93voice/video on IP networks, 440–441voice VLANs

configuring and verifying, 288–290, 289trunks, 286–288, 287

VoIP AutoQoS policieson routers, 475–479, 476on switches, 479–483, 480

VoIP design, 145–146codecs

clarity concerns, 160–163selecting, 163–164types, 153–160

exam essentials, 170–171IP voice bandwidth consumption, 164–169,

166, 169quality considerations, 147–153, 148,

150, 152review questions, 172–177summary, 170voice gateway DSP functions,

146–147, 147written lab, 171, 178

VoIP network infrastructure support, 290–293VoIP operation, 77

exam essentials, 94–95firewalls, 80gatekeepers, 89–91, 89–90H.323

MCU, 91–92proxy servers, 91sample network, 92–93, 92

review questions, 96–101summary, 94voice gateway signaling protocols,

83–88, 84, 93voice media transmission protocols,

78–83, 79written lab, 95, 102

VoIP path-selection process, 103dial peers, 109–110, 110dial-plan digit manipulation. See dial-plan

digit manipulationdial plans. See dial plan path-selection

processexam essentials, 135–136review questions, 137–142summary, 135written lab, 136, 143

Ww (watch phone) ephone button separator,

318, 320WAN connections, 457WAN-to-PSTN fallback, 369–370, 369watch phone (w) ephone button separator,

318, 320weighted fair queuing (WFQ), 454Weighted Random Early Detection (WRED), 451,

455, 498–500, 499white noise, 151wideband communication, codecs for, 154–155wideband sampling frequencies, 148, 148wildcards

dial-peer configurations, 117–121, 119, 121in digit stripping, 124in prefix adding, 125in regular expressions, 128–129

wink-start command, 50wink-start dialing, 185wink-start E&M signaling, 44–45, 45

voice media transmission protocols – wink-start E&M signaling 557


wired IP phones, 12–13wireless IP phones, 13WRED (Weighted Random Early Detection), 451,

455, 498–500, 499

Xx (expansion line) ephone button separator,

319, 324X11 services, 116

Zzone keyword, 413zone local command, 406, 430zone prefix command, 407, 430zones

H.323 gatekeepers, 397–398, 397local, 406prefixes, 407remote, 406–407

558 wired IP phones – zones


Glossary

bgloss.indd 1bgloss.indd 1 8/19/11 12:40:26 PM8/19/11 12:40:26 PM

2 Glossary

802.3af An IETF standard PoE method for powering networked devices.

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

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 best-practice configurations for an interface and applies them for you.

AutoQoS autodiscovery phase 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 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.

Bbackhaul Trunks used to transport multiple voice calls between the private site and the service provider core network.

Basic Rate Interface (BRI) See ISDN Basic Rate Interface (BRI).


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.

bottleneck The part of a network between two points where bandwidth is at its lowest. This is the area where congestion is most likely.

Ccall admission control (CAC) 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 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 call-control functions on an IPT network. From a Cisco perspective, call-processing agents are any of the three Cisco Unified Communications Managers.

call waiting The ability of a phone to receive two or more simultaneous calls.

caller ID See: Automatic Number Identification (ANI).

central office (CO) 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) trunk Circuits that connect a private business PBX to the PSTN.

Centralized Automatic Messaging Accounting (CAMA) A specialized trunk configuration often used in North America for connecting to emergency services (E911).

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.

Cisco Discovery Protocol A Cisco proprietary Layer 2 messaging protocol that is commonly used between Cisco devices to determine neighboring devices and their capabilities.

Cisco fax relay Cisco’s proprietary fax relay method, which uses special RTP packets to transport the communication stream.


4 Glossary

Cisco phone user license A license for each individual phone endpoint.

Cisco power injector 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.

Cisco Unified Communications Manager Business Edition (CUCMBE) 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 Express (CUCME) 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.

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.

Class Selector (CS) PHB 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-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.

Common Channel Signaling (CCS) A digital signaling method that uses in-band signaling by taking an entire channel out of the TDM structure to use exclusively for signaling.


Glossary 5

companding A bandwidth-saving technique used to reduce the total number of bits that are required for the digital circuit to be encoded and transported.

compressed RTP (cRTP) 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.

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

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.

custom queuing (CQ) 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.

customer premise equipment (CPE) Telephone equipment owned by a private party that connects to the PSTN network.

Ddefault PHB A PHB classification describing traffic that requires only best-effort QoS. The default PHB has a binary value of 000000.

default phone configuration file An XML configuration file that provides a Cisco IP phone with all the general information it needs to communicate with the CUCM Express system.

demarc The termination point that separates cabling responsibility between the customer’s house wiring and the PSTN local-loop wiring.

DHCP relay A configuration setting that relays DHCP messages between requesting endpoints and a DHCP server that resides on a different IP subnet.

Dial Peer 0 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 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.


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.

Differentiated Services Code Point (DSCP) 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.

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

digit stripping A digit-manipulation technique that removes digits that are explicitly defined in dial-peer rules.

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.

digital trunk A PSTN connection capable of transporting multiple digitized voice streams across a single cable.

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.

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


Glossary 7

dual-tone multi-frequency (DTMF) A method of inputting telephone digits using buttons that sends two distinct tones to the phone switch to indicate a specific dialed digit.

dynamic gatekeeper discovery The method in which an H.323 device sends gatekeeper request (GRQ) RAS messages in a multicast to discover its local gatekeeper.

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.

EE&M port An analog port commonly used to connect two PBX systems together.

E&M signaling An analog signaling protocol used to communicate between PBX systems or PSTN network switches.

E.164 See International Numbering Plan.

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

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.

ephone 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-dn A CUCM Express configuration statement that represents the telephone extension configured on each phone that is running SCCP.

error correction mode (ECM) A fax feature that can be enabled to better ensure the proper receipt of all fax-transmission packets.

expansion An ephone button separator option used to expand line coverage for an overlay button.

expedited forwarding (EF) PHB A PHB classification system used for IP data flows that require low-latency packet loss and jitter.


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.

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

fax pass-through 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 relay 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 transmission rate A static transmit rate (measured in bps) at which the fax is transmitted over an IP network.

fidelity The accuracy of a copied signal (such as voice) compared to the original.

firmware load file A file on the CUCM Express system used to tell the registering Cisco phones which firmware they are to download.

First-In, First-Out (FIFO) 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.

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.

Foreign Exchange Station (FXS) An analog port commonly used to connect analog end devices such as a telephone or fax machine.

FRF.12 An LFI mechanism that can be configured on Frame Relay circuits.


Glossary 9

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

gateway signaling protocols Protocols used to communicate signaling between voice gateways or between a voice gateway and a call agent.

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

ground-start signaling A supervisory signaling type that uses grounding wires for the signaling of the line to be seized.

group 3 A fax standard transmission method that supports speeds up to 14.4 Kbps.

HH.323 A suite of protocols for the signaling of voice, video, and data using a peer-to-peer architecture.

H.323 Early Media 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 fast start 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 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.

H.323 slow start 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.

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 The combination of PBX and key-system functionalities.


10 Glossary

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

Integrated Services Digital Network (ISDN) 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.

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.

international network The level within the PSTN hierarchy where international long-distance charges are incurred.

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.

Internet Telephony Service Provider (ITSP) 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.

interoffice trunk Backhaul connections that interconnect central offices. Calls made between interconnected COs are considered to be local.

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.


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.

ISDN Basic Rate Interface (BRI) 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.

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

Kkey system A telephone system used in small businesses for the sharing of external PSTN lines on multiple phones.

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

line seizure A telephone line state when a phone transitions from an on-hook to an off-hook state.

link efficiency A QoS method used to make the transport of data flows more efficient, including techniques such as compression and LFI techniques.

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.

local call A VoIP call type where source and destination phones are connected to the same call-processing agent or voice gateway.

local loop The physical wiring between a customer’s private phone equipment and the PSTN central office (CO).


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.

Low Latency Queuing (LLQ) 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-complexity codec A codec that requires a low amount of DSP processing power.

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

Media Termination Point (MTP) A method used to set up logical terminations to offload voice duties such as call hold, transfer, park, conference calling, and DTMF generation.

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.

MGCP residential gateway 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 trunking 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.

Modular QoS CLI (MQC) A Cisco QoS configuration method that uses a modular three-step hierarchical approach to configuring classes and policies and applying the policies to interfaces.

monitor line An ephone button separator option used to monitor the status (on- or off-hook) of a single ephone-DN.


Glossary 13

Multilink PPP (MLP) A Layer 2 transport mechanism defined in RFC 1990 that encapsulates Layer 3 traffic over point-to-point links including ISDN.

multiplexing Combining multiple analog or digital signals over a shared physical medium.

multipoint control units (MCU) Devices used to control and facilitate H.323 multimedia content such as audio and video for a point-to-multipoint communication.

Nnamed signaling events (NSE) 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.

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

Network Time Protocol (NTP) A service that synchronizes the internal clocks on networked equipment.

non-standard facilities (NSF) Proprietary (non-T.30) capability codes that are exchanged between two fax machines to determine possible fax transmission methods.

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.

number expansion A digit-manipulation technique that matches one string of digits and then substitutes different digits before forwarding them to the next destination.

Nyquist sampling theorem A mathematical equation used to find the optimal method for sampling the human voice for transport on a telephone network.

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


14 Glossary

one-stage dialing When a voice network is configured so that a call is not terminated until the endpoint phone is reached.

on-hook When the analog circuit between the ring and tip is severed and the battery (ring) cannot power the tip lead.

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.

out-of-band signaling 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.

overlay An ephone button separator option used to associate multiple ephone-DNs with a single-line button.

Ppacket loss 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 concealment 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.

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.

Perceptual Objective Listening Quality Analysis (POLQA) 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 Speech Quality Measure (PSQM) 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.


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.

powered patch panel A device that sits in between an IP phone and a non-PoE-capable switch that provides power to multiple phone endpoints.

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

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.

Primary Rate Interface (PRI) Digital circuit that uses either 23 or 32 channel T1/E1 ports. Out-of-band signaling is used.

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.

private numbering plan Numbering plan for the configuration of private telephone networks within an organization.

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

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.


16 Glossary

proxy A device that acts as an intermediary for connected clients.

Public Safety Answering Point (PSAP) The name for the CO that is the first hop connecting a private voice network CAMA trunk to E911 services.

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.

pulse-code modulation (PCM) The process of translating sampled analog signals into a numbering system. This is also referred to as quantization.

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

Quality of Service (QoS) A set of traffic-control mechanisms used to give time-sensitive traffic priority on the network to limit delay, jitter, and packet loss.

quantization The process of translating sampled analog signals into a numbering system. This is also referred to as pulse-code modulation.

RRandom Early Detection (RED) 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.

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.

Registration Admission and Status (RAS) An H.225 message protocol that is used to communicate the registration process between H.323 gatekeepers and H.323 endpoints and voice gateways.


Glossary 17

remote zones H.323 zones that are not configured locally and are handled by an external gatekeeper.

reset A full reboot of a Cisco IP phone.

Resource Reservation Protocol (RSVP) A Transport layer protocol that is designed to reserve bandwidth resources dynamically across an IP network.

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.

robbed-bit signaling (RBS) 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.

SSecure RTP (sRTP) Protocol that provides authentication, data encryption, and relay protection for RTP packets.

seizure The process of taking a telephone connection off-hook, which reserves the line for a telephone call.

service policy The third tier of a class-based QoS policy that is used to apply policy maps to router interfaces including subinterfaces and virtual circuits.

Session Description Protocol (SDP) An RFC 2327 protocol that uses standard ASCII codes for describing and negotiating multimedia sessions.

Session Initiation Protocol (SIP) 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.

shared line The term used to describe an ephone-DN that is applied to two or more IP phones.

SIP delayed offer A method of exchanging SDP messages using SIP where the target device sends the initial request in a SIP OK message.

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.


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 user agent (UA) SIP endpoint device that can be considered either a UAC or a UAS device.

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.

Skinny Client Control Protocol (SCCP) 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.

source IP address The IP address that defines the location of the CUCM Express call-processing unit.

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

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.

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

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.

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


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.

technology prefix A special E.164 prefix number that can be dialed by endpoints to take advantage of special H.323 features.

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.

toll bypass The voice design of configuring your IP network to utilize WAN connections for voice transport and therefore avoiding long-distance charges.

tone suppression A configuration method used to block fax tone transmissions so they can be transported at a lower rate.

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.

traffic classification The process of identifying traffic based on different characteristics in order to group same-traffic types together for QoS.


20 Glossary

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

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

transcoding The process of translating data between two different codecs.

translation rule 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 regular expressions Defined characters used to provide an easy and structured method to match number strings used for matching and manipulating number strings within translation rules.

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.

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


Glossary 21

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

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.

voice clipping A side effect of VAD in which the first few milliseconds of a user’s voice are not transmitted to the remote party.

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.

voice register pool 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 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.

Wwatch phone An ephone button separator option used to monitor the status (on- or off-hook) of all ephone-DNs assigned to a 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.

Weighted Random Early Detection (WRED) 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.

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


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.

wink A term used to describe the on-off-on hook transition when using E&M wink-start supervisory signaling.

WRED See Weighted Random Early Detection (WRED).

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


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

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.

John Wiley & Sons, Inc.

End-User License Agreement

bmeddis.indd 559bmeddis.indd 559 9/20/11 1:41:47 PM9/20/11 1:41:47 PM

he Best CVOICE v8.0 Book/CD Package on the Market!T

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.

�

�

�

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.

�

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.

�

�

bmedinst.indd 560bmedinst.indd 560 9/21/11 2:59:32 PM9/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 fl ows. 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 Confi gure VLANs. 5

Implement Cisco Unifi ed Communications Manager Express to Support Endpoints Using CLI

Describe the appropriate software components needed to support endpoints. 8

Confi gure DHCP, NTP, and TFTP. 8

Describe the differences between the different types of ephones and ephone-dns. 8

Confi gure Cisco Unifi ed Communications Manager Express endpoints. 8

Describe the Components of a Gateway

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

Perf.indd 1Perf.indd 1 8/29/11 2:33:16 PM8/29/11 2:33:16 PM

OBJECTIVE CHAPTER

Implement a Gateway

Confi gure analog voice ports. 2, 6

Confi gure digital voice ports. 2, 6

Confi gure dial peers. 4, 6

Confi gure digit manipulation. 4, 7, 9

Confi gure calling privileges. 7

Verify a dial-plan implementation. 4, 6, 7

Implement fax support on a gateway. 9

Implement Cisco Unifi ed Border Element

Describe the Cisco Unifi ed Border Element features and functionality. 10

Confi gure Cisco Unifi ed Border Element to provide address hiding. 10

Confi gure Cisco Unifi ed Border Element to provide protocol and media internetworking. 10

Confi gure Cisco Unifi ed Border Element to provide call admission control. 10

Verify Cisco Unifi ed Border Element confi guration 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 traffi c. 5, 11

Describe and Confi gure the DiffServ QoS Model

Describe the DiffServ QoS model. 11

Describe marking based on CoS, DSCP, and IP Precedence. 11

Confi gure Layer 2 to Layer 3 QoS mapping. 12

Describe trust boundaries. 11

Confi gure trust boundary on Cisco switches. 12

Describe the operations of the QoS classifi cations and marking mechanisms. 11, 12

Describe Low Latency Queuing. 11, 12

Describe the operations of the QoS WAN link effi ciency mechanisms. 11, 12

Enable QoS mechanisms on switches using AutoQoS. 12

Confi gure Low Latency Queuing. 12

Perf.indd 2Perf.indd 2 8/29/11 2:33:17 PM8/29/11 2:33:17 PM

Documents

Sybex.cvoice.8.0.Implementing.cisco.unified.communications.voice.over.IP.and.QoS.v8.0.(Exam.642 437).2011.RETAiL.ebook DeBTB00k