Component Resources Documentation for IP Telephony For an overview of how to use the tool, see the introductory PDF on the home page. “Putting VoIP cards in a PBX does not constitute IP. Telephony. IPT enables a whole raft of communication that the PBX cannot match. The user is still locked in . Cisco IP Phone Series and Cisco Unified IP Phones Series solutions/collateral/business-video/business-video/

Cisco Ip Telephony Pdf

Language:English, Portuguese, Arabic
Genre:Fiction & Literature
Published (Last):16.12.2015
ePub File Size:23.83 MB
PDF File Size:11.29 MB
Distribution:Free* [*Registration needed]
Uploaded by: LINCOLN

Release (5). With such a high level of industry interest regarding IP telephony, . – IP Telephony and VoIP (Voice over IP) are not the same! • Although VoIP and IP Telephony are designed for different network sizes .. CISCO , , . - Ebook download as PDF File .pdf), Text File .txt) or read book online.

He has ten years of experience in telecommunications. His primary areas of expertise include call routing, call control, and telephone features.

He was a member of the team that developed and implemented the Cisco CallManager software from its early stages, and he was directly involved in developing the system architecture and design. She is responsible for technically leading the resolution of some of the most critical problems in voice and IP Telephony, spreading technical knowledge to other teams, and working with Cisco business units and the field to head IP Telephony solutions.

She has been working as a network engineer for more than five years. He is responsible for helping Cisco customers design, implement, and troubleshoot IP Telephony solutions in their environment. He has been working for Cisco as a network engineer for more than six years. Since he has been an independent contractor for the Cisco Systems' IT department. During the course of his tenure, his main focus has been the design, implementation, and maintenance of VoIP, IP Telephony, voice and video applications, and the integration of AVVID technologies into solutions.

Acknowledgments Paul Giralt I want to first thank Anne Smith for all her hard work and guidance throughout this entire project. There is no way this book would exist without her constant dedication and attention to detail. Thanks to Chris Cleveland for his excellent work as development editor on this book and for being so flexible when it comes to the unpredictable schedules of a TAC engineer.

Thanks to Dave Hanes for his excellent fax troubleshooting presentations and Andy Pepperell for his explanation of fax and modem passthrough.

Thanks to all the developers in Richardson and San Jose that I have worked with over the years. Your insight into the inner workings of CallManager has helped me understand how to better troubleshoot the product. Special thanks to Bill Benninghoff for always answering any question I throw his way and for always being so thorough in his explanations.

Also thanks to Chris Pearce for his excellent grasp on the intricacies of call routing. Also thanks to all the other unnamed authors for the documentation scattered throughout various web pages. Every customer I work with helps me understand a little more about IP Telephony.

Paul in particular spent a lot of time with me, bringing me up to speed on these technologies, and for that, I am indebted to him.

I'd also like to thank all the brilliant development engineers who patiently helped me understand CallManager so well over the past few years. I'd like to thank Susan Sauter.

She is a brilliant engineer, and so much of what I know about IP Phones came from her patient instruction. Chris Pearce has also helped me so much over the last few years in understanding dial plans. The chapter on applications is based on the hard work of Dave Bicknell. Without his efforts, that chapter would not be even close to what it should be. Stefano Giorcelli's excellent directory documentation also was so very helpful!

The TAC is on the front lines of troubleshooting, and much of the help I received was from the experiences that only solid TAC engineers could provide. Also, the technical reviewers of this book were so helpful. Thank you so much to everyone for their hard work! I really believe this is a great book, and one of the biggest reasons for that is Paul Giralt's invaluable contribution and hard work on this project.

I couldn't have done this without him! My manager, Shaik Kaleem, was very supportive of this project that I undertook on my own time, and I greatly appreciate that support. Finally, I'd like to thank Anne Smith. This project would never have happened without her tireless work and skillful help. I am so grateful for Anne's effort. She worked so very hard over this past year, and Paul Giralt and I would have been lost without her.

Anne Smith My many thanks go to Paul Giralt and Addis Hallmark for making this book a reality with their knowledge, experience, hard work, and sacrifice.

In particular, I thank Paul for a highly enjoyable working experience.

Paul's dedication to the quality, accuracy, and comprehensiveness of this book was unsurpassed; he spent countless hours reviewing every page of technical information and his experience with the many components in the Cisco AVVID IP Telephony solution made his extensive contribution invaluable.

At every turn, Paul's dedication, commitment to quality, tireless drive for accuracy, and constant positive attitude made working with him a rewarding experience. As always, my thanks and great admiration go to Richard Platt and Scott Veibell.

Current deployments range from extremely distributed enterprises with hundreds of remote offices to small person offices. Geographically, systems are deployed across the world, including exotic locations such as Antarctica and the International Space Station! For example, manageability and serviceability are achieved through either a browseable interface or an XML SOAP-based protocol for integration with existing IT systems. Geography disappears as a problem because telephony functions, manageability, and serviceability all traverse the IP network.

Nevertheless, this unification and standardization of telephony on IP networks also presents unique challenges.

Voice quality can be impacted by poor IP network design. Capacity planning requires consideration of IP address numbering. Music on Hold as a multicast stream requires proper switch and router configuration.

These are only a few examples of the unique considerations that must be given to IP Telephony deployments. The wisdom contained herein has been gained over the course of thousands of real customer experiences. Paul Giralt and Addis Hallmark are two of the very best troubleshooters in the industry, and Anne Smith has written about and worked with the system since the earliest releases. Paul has been with Cisco's customer support organization for several years.

His depth and breadth of knowledge across all Cisco products are legendary, including his most recent focus on IP Telephony.

I have seen him in action at some very large and sensitive customer installations, where he resolved extremely difficult problems and provided excellent guidance during upgrades and installations. We were fortunate to get him back, inasmuch as our customers were loathe to let him leave! He has been personally engaged with many key customers during deployment and operation and has received numerous rave reviews from customers. Addis also has been instrumental in the security design aspects of Cisco CallManager.

She has been engaged with the technology since its inception at Selsius Systems. I highly recommend this book to any individual or organization involved in installing, operating, or troubleshooting one of the most exciting advances in the long history of telephony.

Written by three of its pioneers, this book serves as a guide for the rest of the pioneers who aren't afraid to help their organization communicate in its own way, the better way, the IP way.

Richard B. This book teaches you the troubleshooting skills you need to isolate and resolve IP telephony problems. IP telephony is a relatively new technology with many different components. Additionally, the network infrastructure plays an important role in prioritizing voice packets to ensure quality of service QoS. With all these components involved in transmitting voice across packet networks, it is essential that you be able to identify and resolve issues in the entire solution.

This requires knowledge of the functionality of these components and how they interact with each other, as well as what tools are available to help you find the root cause when problems arise. This book educates you about the techniques, tools, and methodologies involved in troubleshooting an IP telephony system.

Updates to this book may be provided after publication. You should periodically check the ciscopress. This book intends to deliver a methodology you can follow when troubleshooting problems in an IP telephony network, particularly a Cisco IP Telephony solution. This book provides detailed troubleshooting information that applies to a variety of problems that can occur in any IP telephony deployment. Who Should Read This Book? This book is designed to teach you how to isolate and correct problems in an IP telephony network.

You will best be able to assimilate the information in this book if you already have a working knowledge of a CIPT network. How This Book Is Organized Although you could read this book cover-to-cover, it is designed to help you find solutions to specific problems. The chapters are organized by the various components of a Cisco IP Telephony solution. Four appendixes provide reference information. This appendix provides a list of applicable protocols and codecs with descriptions and the standards body corresponding to the protocol or the Request for Comments RFC number.

Compression rates are given for each codec. This file shows you how each part of an NANP number corresponds to a specific placeholder. It is particularly useful when you're learning how to apply route filters. This appendix lists and describes the performance objects and counters in a Cisco IP Telephony network. Some pertinent Windows counters are also described. Best Practices In a perfect world, there would be no need for this book, because systems would always run perfectly.

Unfortunately, in the real world, problems do arise, and they usually don't go away on their own. Best practices include not only design considerations but also monitoring and management. A properly monitored system can detect failures before they become service-affecting. Each chapter contains a section outlining best practices as they apply to the chapter topic. In a properly designed network, you can achieve High Availability in an IP Telephony Environment High availability for IP telephony is based on distribution and core layers in the network and servers call processing, application servers, and so on.

BellCore Specification GR defines what criteria must be met to achieve "five 9s" A careful examination of this document is recommended if you are interested in understanding Note that many "events" are not counted against five 9s reliability.

Some of these events include the following:. The Command Reference describes these conventions as follows:. In actual configuration examples and output not general command syntax , boldface indicates commands that the user inputs such as a show command.

Table I-1 provides a brief primer on the OSI reference model layers and the functions of each.

About the Technical Reviewers

Table I Also specifies characteristics such as voltage, cable types, and cable pinouts. Data link Combines bytes of data into frames.

Also performs error detection and recovery for the data contained in the frame. Can fragment and reassemble data if the upper-layer protocol is sending data larger than the data link layer can accept.

Allows for multiplexing of various conversations using a single network-layer address. Can also ensure data is presented to the upper layers in the same order it was transmitted. Can also provide flow control. Session Sets up, coordinates, and terminates network Operating systems Layer 5 connections between applications.

Also deals with and application session and connection coordination between access scheduling network endpoints. Can perform special processing, such as encryption, or can perform operations such as ensuring byte-ordering is correct. Comments for the Authors The authors are interested in your comments and suggestions about this book. Please send feedback to the following address:.

Cisco Documentation This book provides comprehensive troubleshooting information and methodology. However, details about common procedures might not be provided. You should be familiar with and regularly use the documentation that is provided with the Cisco IP Telephony system to supplement the information in this book.

You can examine the following books at a technical bookseller near you or online by entering the title in the search box at www. You can find information on how to integrate and configure packetized voice networks in the book Integrating Voice and Data Networks ISBN Throughout this book, you will see a number of icons used to designate Cisco-specific and general networking devices, peripherals, and other items. The following icon legend explains what these icons represent.

IFC Active Directory domain name problems Active Directory integration troubleshooting and overview Active Directory schema modifications Active Directory—users added in Active Directory don't show up in CallManager Administration Adding a user fails Alarms red and yellow on a digital interface "Already in conference" message Attendant Console client configuration Attendant Console—fast busy on calls to a pilot point Attendant Console—line states won't update Attendant Console—lines are disabled Attendant Console—login failed Attendant Console—longest idle algorithm is not working properly Attendant Console—new user doesn't display.

Chapter 1. Troubleshooting Methodology and Approach It's 5: You recognize the phone number— it's your CEO's administrative assistant. As the administrator of the company's phone IP Telephony network, you assume there's a big problem.

You rush into work and find the CEO's administrative assistant, who states that several calls for the CEO have been disconnected in the middle of the call, including a call from a very important customer. Where do you start? Troubleshooting a Cisco IP Telephony network can be a daunting task. Rather than describing step-by-step how to solve specific problems subsequent chapters provide that information , this chapter focuses on teaching a good troubleshooting methodology: A typical IP Telephony network consists of—at the very least—one or more of the following components:.

These components are in addition to the data network infrastructure that supports voice over IP VoIP traffic. More-complex installations can have dozens of servers for different services and redundancy, each server running a variety of applications, as well as hundreds or thousands of IP phones and a large number of voice gateways. The Skinny protocol is covered in greater detail in Chapter 5. Some clues lead you to additional clues. As soon as you've got all the clues. In addition to the information in this book.

On the other hand. Understanding the Skinny protocol is essential to understanding how the phone operates and how to troubleshoot problems with it. Before exploring the myriad of tools. Gather data about the problem: Use deductive reasoning to narrow the list of possible causes. Identify and isolate the problem. CallManager provides many diagnostic traces if they are enabled prior to the problem that you can reference after a problem has occurred to see what was happening on CallManager at the time of the problem.

In the case of a service-affecting problem during production hours. Determine the problem's timeframe. For example. Note that although percent CPU of a high-level process can cause sluggish behavior or delayed dial tone. Step 2. The downside of this approach is that you might not be able to further troubleshoot the problem when the process is restarted. Gather information from the end users. During a new install or scheduled outage window. Analyze the data you collected about the problem: Use topology information to isolate the problem.

The following list is a general guide for steps to take when troubleshooting an IP Telephony problem: Step 1. In contrast. Determine the proper troubleshooting tool s. Production Versus Nonproduction Outages Troubleshooting a problem can occur in one of two timeframes: After you restore service.

Troubleshooting a problem can be broken down into two stages: Verify IP network integrity. You've encountered a problem. The first thing to do is gather as much information about the problem as possible. Troubleshoot the dropped-call problem first because keeping calls connected is more critical than removing the occasional echo on an active call.

If you encounter an event where you are unable to determine the root cause due to insufficient information. As of CallManager 3. Look at the percent CPU as a possible symptom but not necessarily the root cause. When multiple problems occur simultaneously. You must also determine which parts of the problem are symptoms and which are the root cause of the problem. To help you visualize the big picture. Step 1: You must always remember to look at the big picture when searching for the root cause and not let the symptoms of the problem lead you in the wrong direction.

It should also clearly show how the devices are interconnected and the port numbers being used for these interconnections. The network diagram should include network addressing information and the names of all the devices.

One of the first lines of defense is possessing current topology information. Identifying and Isolating the Problem Half the battle in troubleshooting a problem is determining which piece of the puzzle is the source of the problem.

In fact. Using Topology Information to Isolate the Problem You can take many proactive steps to help make the troubleshooting process easier. In this case. This information will prove invaluable when you try to isolate which components are involved in a particular problem. With so many different pieces composing an IP Telephony network. So although the symptom is a phone reset. One of the most important pieces of topology information is a detailed network diagram usually created using Microsoft Visio or a similar application.

Many customers keep all this topology information on a web server as well.

Notice that device names and IP addresses are listed in the diagram. For a small network. Knowing where a call is. Figure You also need documentation of your dial plan. This makes troubleshooting easier by allowing you to quickly look up devices to access them. Because Figure is a high-level diagram. Some deployments. For larger deployments. For medium. Be sure to keep this information in a secure location. Figure shows a typical high-level topology diagram for a large enterprise IP Telephony network.

In addition to the network diagram. It's necessary when you're trying to isolate the problem to a particular part of the network. Gathering Information from the User Information the user provides can be vital to your ability to correct a problem.

If any patch panels exist between devices. Try to gather as much detail as possible on exactly what the problem is. Often when troubleshooting a problem.

To further isolate the problem. Use all the topology information you have to narrow down which pieces of the network might be involved in the problem you are trying to troubleshoot.

Without a network diagram. A general topological understanding of the network or at least the piece of the network in question helps when you're trying to differentiate the problem from its symptoms. If the user's phone is connected to Access Switch 1A. The more detail about the problem you can gather before you begin troubleshooting.

If you're going to keep topology information highly recommended. When your topology information is complete. Assume that the network you are troubleshooting looks like Figure If a topology drawing is not available. What is worse than not having topology information? Having incorrect topology information can lead to countless hours heading down the wrong path.

Users can get quite irritated if you have to ask them for the same piece of information two or three times. You can use this as search criteria if you need to look through traces. It is important to know whether they are attempting to do this at 9: Determining the problem's earliest occurrence can help correlate the problem with other changes that might have been made to the system or other events that occurred around the same time.

Sometimes the information provided by an end user is not enough to even begin troubleshooting. As another example. Here is some general information to collect from users: Also point out to the user the importance of letting you know immediately after a problem occurs. When relying on end users to give "when" information about a problem.

This includes what buttons were pressed and in what order. This includes text messages displayed on the phone or recorded announcements. As long as you have the time on your CallManagers and network devices synchronized. Sometimes the proper diagnostic tools are not enabled when the problem occurs. You check the voice mail system and notice that at the time the problem was reported.

Many users report that they get a busy signal when dialing into their voice mail. Determining the Problem's Timeframe In addition to what the problem is. The phone's time is synchronized with the clock on the CallManager to which the phone is registered.

This might change the problem from a troubleshooting issue to a load-balancing or equipment- expansion issue. Be sure to turn on tracing or debugs before making the request so that when the problem occurs again.

Clearly in this example you need more voice mail ports or servers to handle call volume. Using Deductive Reasoning to Narrow the List of Possible Causes The next part of your fact-finding mission is to identify the various components that might be involved and to eliminate as many components as possible.

The more you can isolate the problem. He might think the problem happens only on his phone. The answer to this question helps determine which parts of the system are being used when the problem occurs. The user probably won't know the answer. Step 2: Analyzing the Data Collected About the Problem Now that you have collected data from a variety of sources.

In some cases. If so. If you have information about when. You will find more detailed questions similar to these throughout this book when troubleshooting particular problems. TIP Although it is important to use information about when the problem started happening.

Additional tools and traces are covered in the chapter associated with diagnosing certain types of problems. If you fix the problem for that one user. Check your physical layer connectivity cables.

Determining the Proper Troubleshooting Tool After you narrow down the appropriate component s causing a problem and have detailed information from the user s experiencing the problem. Continue working your way up the stack until you reach the application layer Layer 7. Although not all of the following apply to every problem. Upon further investigation. You should use the tracing and debugging facilities available in CallManager and other devices to determine exactly what is happening.

When you reach this layer. As an example. Then make sure you have Layer 2 connectivity by checking for errors on ports. Most components have multiple troubleshooting tools available to help you. The network is always a consideration when you encounter certain problems. Use your topology information to help obtain this information. You would then check Layer 3. Chapter 6. Chapter 3. Network health is especially important during the discussion of voice quality problems in Chapter 7.

Taking the layered approach. A degraded network or a network outage can cause a wide range of problems. The CEO has a phone that stores information locally about missed calls. Most users do not pay attention to specifics like this unless they have been instructed to. Eager to resolve the problem.. This step is the most demanding on your troubleshooting skills because you analyze the detailed information provided in the various tools and use it to search for additional clues using other tools.

Sometimes the problem description you have is not detailed enough to determine which tool to use. This case study applies the methodology previously described. The only data you have is the page you received at 5: You must gather the data before you can begin the analysis. You notice that the second call was placed to the same area code and prefix as the call that was received. He states that at various times during the previous day and one time this morning.

Gathering the Data As part of the data-gathering stage. You notice that a call was received at 5: Because CallManager is central to almost all problems. The following case study shows how this troubleshooting methodology works in a real-world scenario. This is the extent of the information he remembers. Case Study: Please help ASAP! You head into the CEO's office and look at the list of received calls and placed calls for the morning.

She remembers that she was on the phone with a customer for about 15 minutes when the call was disconnected. She immediately called the customer back.

You ask the CEO about the two calls. The telephone company has set up the inbound calls so that the 32 gateways are redundant whereby if one of the gateways is down. She also confirms that the first call that was received was the dropped call. Armed with this information. Now you know that the problematic call was received at approximately 5: You refer to your topology diagram to isolate the components that are involved.

This lets you isolate which CallManager in the cluster is involved in the signaling for this phone. Figure 1- 2 shows a high-level diagram of the network topology. While you are looking at the CEO's phone.

Related titles

All outbound calls prefer the first gateway. You also know that the problematic call was an inbound call. You ask the CEO and her admin if all the dropped calls were inbound calls. You then look at the configuration for the two gateways at Remote Site 2 and note that they are both configured to send incoming calls to CallManager Subscriber 3 as their preferred CallManager and CallManager Backup 1 in case CallManager Subscriber 3 fails.

You know that the call this morning was during a time of day where there is little phone activity. With the information you have so far. As far as they can remember. So far you know that the problematic call was to the CEO. With just the information you have so far. Remember that all inbound calls to the remote site come in through Primary Rate Interfaces PRIs connected to the remote voice gateways and that inbound calls to the site prefer the second gateway.

As shown in Figure It is unlikely that all the channels on the first PRI were in use during a time of low call volume. This is not to say that other users are not experiencing similar problems. Determine whether these calls all come directly to the user or if the call flow has any intermediate steps. Now that you know the problem is related to inbound calls. Armed with this knowledge.

For the sake of this example. At this point. Keep in mind that you haven't eliminated the possibility that the problem is on CallManager or is network- related. If the problem is more widespread than this one user. The phone and voice gateway never directly exchange signaling data.

You can then analyze the trace files to discover the device that disconnects the call from CallManager's perspective—in other words. After combing through the trace file. Now it is time to start analyzing the data. Because nearly all signaling for a call must go through one or more CallManager servers.

The CCM traces discussed in Chapter 3 indicate which gateway the calls are coming from. After you isolate the problem. This concludes the data-gathering piece of your investigation. All signaling goes through CallManager. A call between the CEO's phone and the voice gateway has two distinct signaling connections. The trace includes all the messaging between CallManager and both the phone and the gateway.

One is the communication between CallManager and the voice gateway. The other is the communication between CallManager and the phone. So how do you determine which one is causing the problem? One important distinction to make that will become evident as you read through this book is that many problems can be narrowed down to being either signaling-related or voice packet-related. You know that the call in question was set up around 5: Chapter 3 provides more details on where to find these traces and how to read them.

Analyzing the Data As soon as you have a clear understanding of the problem you're trying to resolve.. This eliminates the CEO's phone as a cause of the problem because the. As part of the data analysis stage. If you don't know the times that the other calls were dropped. If there were a network problem. Figure shows you've narrowed down the network to only a few devices. Network After You Continue Narrowing Down the Possible Suspects The next step is to go to the suspected gateway and try to determine why one of the calls was dropped.

It would not hurt to look through the network devices between CallManager and the voice gateway to ensure that there are no network errors. This involves turning on additional debugs on the gateway to determine if the gateway is disconnecting the call or just passing along information. Because the user indicated that there were three drops. Because CallManager received a message from the gateway telling it to disconnect the call.

Depending on what you discover on the gateway debugs. When deployed in a large enterprise. As you begin this journey. Chapter 2.

IP Telephony Architecture Overview. Chapter 6 discusses these considerations in detail. Which debugs to use depends on the gateway model and the type of interface to the PSTN. This is why it is so important to narrow down the problem to a small subset of devices: You do not want to turn on debugs on dozens of gateways.

Then dig deeper into each component by breaking the problem into more manageable pieces. Many basic problems can be avoided by using a consistent troubleshooting approach. The point of this example is not to teach you how to troubleshoot a specific problem or to find out exactly why the user's calls are being dropped.

It is vital that you always follow a consistent approach to troubleshooting. Summary This chapter discussed the methodology you should employ to successfully troubleshoot problems in an IP Telephony network.

What areas are you unsure about? Are you strong in IP but weak in call processing skills? Are you familiar with the basic protocols that are used? Consider where you are now. Conclusions As this case study has demonstrated. You should become familiar with the methodologies discussed here.

The same principles can be applied to almost any problem you are troubleshooting. So remember. It is to show you how to approach a problem in order to isolate it and break it into more manageable pieces. While waiting for the problem to reoccur. Your network design must be built for high availability. Triple call processing server redundancy improves overall system availability. CallManager clustering yields scalability of up to With this overview as the starting point.

The infrastructure includes switches and routers. A voice-enabled network is a quality of service QoS -enabled network that gives precedence to voice. By interlinking multiple clusters. IP phones. This chapter covers the basic components of the IP Telephony architecture in order to get a big-picture viewpoint of the system. Video and Integrated Data includes many different components that come together to form a comprehensive architecture for voice. Multiple CallManager servers are clustered and managed as a single entity.

The benefit of this distributed architecture is improved system availability and scalability. Figure shows an example of each separate site connecting via the PSTN.

Multiple sites exist. Multiple-Site Deployment Model. Figure shows an example of these components located at a single site. Centralized Deployment Model. Figure illustrates the centralized deployment model. Centralized Deployment Model A centralized call processing deployment model centrally locates CallManager. Locations-based call admission control prevents over-subscription of the WAN.

At each remote site. The centralized call processing model is really the same as the single-site deployment model with the addition of remote sites across the WAN. Figure depicts a distributed deployment model.

CallManager and applications are located at each site with up to One hundred or more sites could be interconnected via H.

Distributed Deployment Model In a distributed deployment model. Distributed Deployment Model. Although infrastructure is not the primary focus of this book. Cisco Unity. Figure shows the Cisco family of IP Phones. Cisco offers several models with different functions. Table Clients consist primarily of IP phones. It includes the following features: Available features include call park. It has the following Module features: Up to two Cisco s can be connected to a Multicolor button illumination allows you to identify which lines are ringing.

The phones can also receive power down the line from any of the Cisco inline power-capable switches or the Cisco inline power patch panel. The Expansion Module lets you add 14 buttons to the existing six buttons on the phone. A second version of the phone. The system administrator can designate separate VLANs A dedicated headset port eliminates the need for a separate.

The phone provides a mute button for the handset and headset microphones. You can attach a headset by removing the handset and using the port into which the handset cord was attached. Because these phones are largely soft key-based. The 14 buttons on each Expansion Module can be programmed as directory numbers or speed dial buttons. The plugs into a standard RJ Ethernet connection. Cisco IP Phone This low-end phone features on-hook dialing and call monitor mode but does not include speakerphone capability.

These phones feature a large pixel-based display that allows for XML-based applications on the phone. The is an IP-based. Using Skinny on these gateways allows the gateway to provide features such as message waiting indicators MWI.

Each port on these gateways registers individually as a phone device. MGCP provides the following services: Although the does not accept inline power from a Cisco inline power-capable switch. CallManager controls routing and tones and provides supplementary services to the gateway. These gateways interoperate with CallManager using various protocols. Two gateways.

Compared to MGCP. Windows Cisco ER features a real-time location-tracking database and improved routing capabilities to direct emergency calls to the appropriate Public Safety Answering Point PSAP based on the caller's location.

Summary This chapter provided an overview of the primary components that are involved in the Cisco IP Telephony architecture. When troubleshooting. Personal Assistant provides rule-based call routing.

Windows NT. Depending on the problem you encounter and your particular skill set. These traces are usually reserved for Cisco development engineering use. Later chapters demonstrate the use of these tools in different scenarios you might encounter.

This chapter covers the following topics: If you are strong in IP. In addition. SDL traces describe the events occurring in the CallManager software at a code level. CCM trace files provide information about call processing events and all messages exchanged between Skinny.

The resulting matrix shows when each bug was integrated or fixed if applicable. The Enhanced Q. Signaling also occurs between the respective CallManagers of each endpoint device. When trace files are collected for analysis. This distributed architecture creates a highly available and scalable system. Time synchronization is critical.

This ensures consistent timestamps regardless of which device you are looking at. CallManager Serviceability. When you synchronize the time on all involved servers.

Also points you to a section in the "Introduction" with a recommended reading list. As endpoints such as IP phones and voice gateways call each other. Time Synchronization Time synchronization is simply making sure that all the participating CallManager servers and network devices have the same exact time. A large CallManager cluster can have eight or more separate servers. In addition to CallManager servers. It also makes the troubleshooting process more involved because you have to collect traces from all participating servers to see the full picture of what happened.

The various information elements are decoded for ease of reading. If a problem occurs. Step 4. You can configure CallManager to point to specific time servers see Example To synchronize with a remote Time Server.

Example Allow several minutes for the update to take place. Sample ntp.

Synchronizing Time Manually on CallManager Servers Use the following steps to manually configure time synchronization. Synchronize the clock by using one of the following commands from a command prompt. Step 3. Configure the C: Use the following steps to configure the CallManager server to automatically synchronize—and stay synchronized—with a Time Server. This file contains the list of time servers that CallManager will synchronize with.

Expand the Services and Applications section. Right-click My Computer and select Manage. Verify that the NetworkTimeProtocol service is configured to launch automatically upon startup. Double-click the NetworkTimeProtocol service.

You can do this by configuring the command ntp master on the IOS device. First you must configure the time zone. You should configure the IOS device to take daylight savings time into account as well if you live in a time zone that observes daylight savings time. For Cisco IOS devices. If you are not making the device an NTP master. Once your time zone is configured properly.

If you do not have a device on the network running NTP. To enable NTP. Future chapters continue to show CCM trace examples as you learn how to troubleshoot more problems.

After you learn a few tricks. CCM traces are usually the first place to look when troubleshooting most problems. Later in this chapter you also learn about the Q.

It is not a substitute for learning how to read the CCM trace. By the end of this section. You can analyze problems related to device registration. Then enable the NTP client using the command set ntp client enable. Once you have the time zone configured properly. As you learn which trace settings are required for specific problems. Setting the Appropriate Trace Level and Flags CallManager allows you to select from a variety of different options that adjust which events are logged to the CCM trace files.

For this reason. Figure shows the top half of the Trace Configuration page. When you are beginning to learn how to read CCM trace files. See the later "Q.


If you configure the trace to collect too much information. If you know exactly what you are looking for. Unfortunately you can never predict what problems will come up. This must be selected for any of the trace settings to be available. First thing to note is the Trace On checkbox. CallManager Serviceability provides six different levels.

Because of the distributed nature of CallManager. You generally want to keep the same level of tracing enabled on all the servers in the cluster unless you are absolutely certain the problem is isolated to a single server in the cluster. The Apply to All Nodes checkbox allows you to apply the specified trace settings to all CallManager servers in the cluster.

This is useful when you are troubleshooting a problem that is occurring on more than one CallManager server. The Trace Filter Settings area allows you to specify the exact parameters of your trace.

Table describes the trace fields to choose from. This level is best suited for debugging difficult problems. It can cause performance degradation on CallManager.

All system and device initialization traces are at this level. Most are reasonably self-explanatory.

Activates the logging of events related to the legacy gateways. Enable Activates a trace of miscellaneous devices. CallManager uses asynchronous tracing to reduce the impact that trace file generation has on call processing. For CallManager releases 3. In release 3. This level includes nearly everything that is included in Detailed with the exception of KeepAlives. Miscellaneous Trace Enable Conference Activates a trace of the conference bridges. Enable DT. Other trace levels are provided.

If you are not troubleshooting problems related to missed KeepAlives.


Use this level to Bridge Trace trace conference bridge statuses such as. Trace Enable Forward Activates a trace of call forwarding and all subsystems not and Miscellaneous covered by another checkbox. Activates CallManager real-time information traces used by the Time Information real-time information server. Enable All Phone Activates a trace of phone devices. Figure shows the bottom half of the Trace Configuration page. The non-device option is a catch-all.

Tracing based on specific devices is very useful when you know which devices are involved in the problem. When that checkbox is selected. Once you've specified the trace settings. For each server on which you're running trace. The Maximum No. We don't recommend going above One downside to this. You should never need to or be asked to enable this checkbox. The trace output is then sent to the path specified in the File Name field.

The new trace settings take effect immediately when you click Update. This could be servera-ccm. At these average sizes. In most cases. For traces to be logged to a file. The downside. The Enable Debug Output String checkbox sends debugging information to a Microsoft development tool useful only to Cisco development engineers. We're going to skip discussion of the Enable XML Formatted Output for "Trace Analysis" checkbox for a moment to finish the fields related to file settings.

The default of for the Maximum No. If you do not enable XML-formatted output. Set the service you want to retrieve the trace files for such as Cisco CallManager.

The Trace Configuration page in CallManager Serviceability validates the filename and ensures that it has a. Do not use a filename that exists on another computer. Depending on the time period you specified. It is a good practice to have each server use a filename format that has the server name in it. Click Update to save your settings. With Trace Analysis. If you did. Use a filename that exists on the computer running the trace.

Assuming you don't go above That way. Trace shows all events as specified in. We generally recommend that you do not use the trace collection utility for anything other than very small traces on a system that is not busy. Manually copy the traces off the server s in question and analyze them offline. It is usually quicker and easier to manually collect the traces yourself using either Terminal Services or VNC discussed later in this chapter to access the CallManager server and copy the files to another machine for analysis.

If you choose to view the text- based output in a new window. If you specify a device name. In this dialog box. Once the trace has been gathered. Trace Type Select this checkbox if you want to include the trace type in the trace output. Information Select this checkbox if you want to include a description of what the trace found in the trace output. CM Node. Date and Time. Figure shows a trace file formatted as XML output and filtered to display only one CallManager host.

Source IP. Date and Select this checkbox if you want to include the date and time of each Time event listed in the trace output. Alarm shows only specific messages that meet the criteria of being an information Alarm message. IP Address Select this checkbox if you want to include the device's source IP address in the trace output. Cluster Select this checkbox if you want to include the cluster name in the trace output.

Device Name Select this checkbox if you want to include the device name in the trace output. Correlation Select this checkbox if you want to include the number that correlates Tag traces with each other in the trace output.

Application Select this checkbox if you want to include the directory numbers Name DNs and other service-specific information in the trace output. The following section describes how to read a text-based CCM trace.Phone A calls Phone B. This chapter explains proper IP phone behavior and examines problems that can occur after an IP phone successfully registers.

Although not all of the following apply to every problem. Once you have the time zone configured properly. If insufficient disk or CPU bandwidth exists to write the trace file. Voice quality can be impacted by poor IP network design. Acknowledgments Paul Giralt I want to first thank Anne Smith for all her hard work and guidance throughout this entire project. Can also ensure data is presented to the upper layers in the same order it was transmitted.

Trace Type Select this checkbox if you want to include the trace type in the trace output. You can place an alert on any counter in PerfMon.