soundofheaven.info Science TROUBLESHOOTING CISCO IP TELEPHONY PAUL GIRALT PDF

Troubleshooting cisco ip telephony paul giralt pdf

Friday, March 15, 2019 admin Comments(0)

Reveals the methodology you need to resolve complex problems in an IP telephony networkMaster troubleshooting techniques and methodologies for all parts. Paul has troubleshot problems in some of Cisco's largest IP Telephony . My many thanks go to Paul Giralt and Addis Hallmark for making this book a reality. Troubleshooting Cisco IP Telephony Full - Ebook download as PDF File .pdf), Paul Giralt I want to first thank Anne Smith for all her hard work and guidance.


Author: THANH HIETALA
Language: English, Spanish, Japanese
Country: Montenegro
Genre: Lifestyle
Pages: 342
Published (Last): 10.04.2016
ISBN: 701-9-74059-682-7
ePub File Size: 15.69 MB
PDF File Size: 17.55 MB
Distribution: Free* [*Regsitration Required]
Downloads: 43415
Uploaded by: SIGNE

configuring, administering, and troubleshooting the Cisco IP Telephony solution . My many thanks go to Paul Giralt and Addis Hallmark for making this book a. By Paul Giralt, Addis Hallmark, Anne Smith; Published Dec 11, by Cisco Press. Troubleshooting Cisco IP Telephony shows you how to break down. By Paul Giralt, Anne Smith; Published Feb 9, by Cisco Press. The only complete, authoritative guide to troubleshooting Cisco IP - now Offers a systematic methodology for identifying and resolving IP telephony problems, plus .

IP Phones. Developing a Troubleshooting Methodology or Approach. You also see the first callReference value. As long as the terminating device provided the correct IP address and port number and CallManager relayed this information correctly. CallManager includes several performance objects that let you monitor various counters related to the operation of the CallManager services and associated devices.

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.

Ip telephony paul pdf giralt cisco troubleshooting

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.

127615104-Troubleshooting-Cisco-IP-Telephony-Full.pdf

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.

Paul telephony pdf giralt ip troubleshooting cisco

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

Telephony ip pdf paul giralt cisco troubleshooting

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.

Troubleshooting Cisco IP Telephony, 2nd Edition

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. On the other hand. In the case of a service-affecting problem during production hours. In contrast. The following list is a general guide for steps to take when troubleshooting an IP Telephony problem: Step 1.

Gather information from the end users. Use topology information to isolate the problem. During a new install or scheduled outage window. Identify and isolate the problem. Verify IP network integrity. Gather data about the problem: Note that although percent CPU of a high-level process can cause sluggish behavior or delayed dial tone. Use deductive reasoning to narrow the list of possible causes. After you restore service. Analyze the data you collected about the problem: For example.

Production Versus Nonproduction Outages Troubleshooting a problem can occur in one of two timeframes: Troubleshooting a problem can be broken down into two stages: The downside of this approach is that you might not be able to further troubleshoot the problem when the process is restarted.

Determine the problem's timeframe. 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. Step 2. Determine the proper troubleshooting tool s. 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.

One of the first lines of defense is possessing current topology information.

Troubleshooting Cisco IP Telephony, Chapter 1: Methodology and Approach

If you encounter an event where you are unable to determine the root cause due to insufficient information. To help you visualize the big picture. You must also determine which parts of the problem are symptoms and which are the root cause of the problem. When multiple problems occur simultaneously. Troubleshoot the dropped-call problem first because keeping calls connected is more critical than removing the occasional echo on an active call.

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. You've encountered a problem. As of CallManager 3. So although the symptom is a phone reset.

With so many different pieces composing an IP Telephony network. The network diagram should include network addressing information and the names of all the devices. In this case. Look at the percent CPU as a possible symptom but not necessarily the root cause. This information will prove invaluable when you try to isolate which components are involved in a particular problem. One of the most important pieces of topology information is a detailed network diagram usually created using Microsoft Visio or a similar application.

It should also clearly show how the devices are interconnected and the port numbers being used for these interconnections. The first thing to do is gather as much information about the problem as possible. Step 1: In fact. Using Topology Information to Isolate the Problem You can take many proactive steps to help make the troubleshooting process easier.

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

Some deployments. In addition to the network diagram. Notice that device names and IP addresses are listed in the diagram. Many customers keep all this topology information on a web server as well. If the user's phone is connected to Access Switch 1A. Gathering Information from the User Information the user provides can be vital to your ability to correct a 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.

Try to gather as much detail as possible on exactly what the problem is. Assume that the network you are troubleshooting looks like Figure The more detail about the problem you can gather before you begin troubleshooting. If a topology drawing is not available. IP addressing for all network devices routers.

Without a network diagram. If you're going to keep topology information highly recommended. When your topology information is complete. What is worse than not having topology information? Having incorrect topology information can lead to countless hours heading down the wrong path.

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 any patch panels exist between devices. Often when troubleshooting a problem. To further isolate the problem. It's necessary when you're trying to isolate the problem to a particular part of the network.

Users can get quite irritated if you have to ask them for the same piece of information two or three times. Many users report that they get a busy signal when dialing into their voice mail.

Phone numbers for all parties involved in the problematic call or calls.. Clearly in this example you need more voice mail ports or servers to handle call volume. When relying on end users to give "when" information about a problem. Also point out to the user the importance of letting you know immediately after a problem occurs. Sometimes the proper diagnostic tools are not enabled when the problem occurs.

It is important to know whether they are attempting to do this at 9: This might change the problem from a troubleshooting issue to a load-balancing or equipmentexpansion issue. 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.

This includes text messages displayed on the phone or recorded announcements. Be sure to turn on tracing or debugs before making the request so that when the problem occurs again.

User observations. Here is some general information to collect from users: Sometimes the information provided by an end user is not enough to even begin troubleshooting. As another example. Information about the user's device. You can use this as search criteria if you need to look through traces. As long as you have the time on your CallManagers and network devices synchronized.

Determining the Problem's Timeframe In addition to what the problem is. You check the voice mail system and notice that at the time the problem was reported.

The phone's time is synchronized with the clock on the CallManager to which the phone is registered. Actions performed by the user when the problem occurred. This includes what buttons were pressed and in what order. TIP Although it is important to use information about when the problem started happening.

The user probably won't know the answer. In some cases. If so. The more you can isolate the problem. He might think the problem happens only on his phone. Step 2: Analyzing the Data Collected About the Problem Now that you have collected data from a variety of sources. Does the problem happen only between IP phones. What numbers are being called when the problem occurs? The answer to this question helps determine which parts of the system are being used when the problem occurs.

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. If you have information about when. Although not all of the following apply to every problem.

The network is always a consideration when you encounter certain problems. You should use the tracing and debugging facilities available in CallManager and other devices to determine exactly what is happening. You would then check Layer 3. Use your topology information to help obtain this information. Network health is especially important during the discussion of voice quality problems in Chapter 7. As an example. Check your physical layer connectivity cables.

Upon further investigation. A degraded network or a network outage can cause a wide range of problems.

If you fix the problem for that one user. Additional tools and traces are covered in the chapter associated with diagnosing certain types of problems. Most components have multiple troubleshooting tools available to help you.

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. Taking the layered approach. Chapter 3. Then make sure you have Layer 2 connectivity by checking for errors on ports.

Continue working your way up the stack until you reach the application layer Layer 7. When you reach this layer. Chapter 6. You head into the CEO's office and look at the list of received calls and placed calls for the morning. Sometimes the problem description you have is not detailed enough to determine which tool to use. You notice that a call was received at 5: Please help ASAP!

He states that at various times during the previous day and one time this morning. The following case study shows how this troubleshooting methodology works in a real-world scenario. Eager to resolve the problem. This is the extent of the information he remembers. 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.

Case Study: You must gather the data before you can begin the analysis. The only data you have is the page you received at 5: You notice that the second call was placed to the same area code and prefix as the call that was received.

This case study applies the methodology previously described. 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. Because CallManager is central to almost all problems. Gathering the Data As part of the data-gathering stage. Now you know that the problematic call was received at approximately 5: The telephone company has set up the inbound calls so that the 32 gateways are redundant whereby if one of the gateways is down.

This lets you isolate which CallManager in the cluster is involved in the signaling for this phone. You refer to your topology diagram to isolate the components that are involved. She also confirms that the first call that was received was the dropped call. All outbound calls prefer the first gateway. Armed with this information. While you are looking at the CEO's phone. Figure 12 shows a high-level diagram of the network topology. She remembers that she was on the phone with a customer for about 15 minutes when the call was disconnected.

You ask the CEO about the two calls. She immediately called the customer back. Two gateways at each remote site used for both inbound and outbound calls. With just the information you have so far. As shown in Figure You know that the call this morning was during a time of day where there is little phone activity. 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.

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. It is unlikely that all the channels on the first PRI were in use during a time of low call volume.

You also know that the problematic call was an inbound call. With the information you have so far. As far as they can remember. You ask the CEO and her admin if all the dropped calls were inbound calls. So far you know that the problematic call was to the CEO.

Paul Giralt Without Ch# 6

At this point. Now that you know the problem is related to inbound calls. Keep in mind that you haven't eliminated the possibility that the problem is on CallManager or is networkrelated. Determine whether these calls all come directly to the user or if the call flow has any intermediate steps. Armed with this knowledge. If the problem is more widespread than this one user. For the sake of this example. This is not to say that other users are not experiencing similar problems.

After combing through the trace file. The phone and voice gateway never directly exchange signaling data. Now it is time to start analyzing the data.

You can then analyze the trace files to discover the device that disconnects the call from CallManager's perspective—in other words. Analyzing the Data As soon as you have a clear understanding of the problem you're trying to resolve.

As part of the data analysis stage. You know that the call in question was set up around 5: The other is the communication between CallManager and the phone. The CCM traces discussed in Chapter 3 indicate which gateway the calls are coming from. This concludes the data-gathering piece of your investigation.

One is the communication between CallManager and the voice gateway. The trace includes all the messaging between CallManager and both the phone and the gateway. Because nearly all signaling for a call must go through one or more CallManager servers.

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. All signaling goes through CallManager. After you isolate the problem. Chapter 3 provides more details on where to find these traces and how to read them.

This eliminates the CEO's phone as a cause of the problem because the. A call between the CEO's phone and the voice gateway has two distinct signaling connections. It would not hurt to look through the network devices between CallManager and the voice gateway to ensure that there are no network errors. Figure shows you've narrowed down the network to only a few devices.

Because the user indicated that there were three drops. Because CallManager received a message from the gateway telling it to disconnect the call. This involves turning on additional debugs on the gateway to determine if the gateway is disconnecting the call or just passing along information. 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.

If you don't know the times that the other calls were dropped. If there were a network problem. 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.

When deployed in a large enterprise. While waiting for the problem to reoccur. So remember. Which debugs to use depends on the gateway model and the type of interface to the PSTN.

The same principles can be applied to almost any problem you are troubleshooting. Depending on what you discover on the gateway debugs. It is to show you how to approach a problem in order to isolate it and break it into more manageable pieces.

You should become familiar with the methodologies discussed here. 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. As you begin this journey. IP Telephony Architecture Overview.

Many basic problems can be avoided by using a consistent troubleshooting approach. Conclusions As this case study has demonstrated.

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

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. Chapter 2. Then dig deeper into each component by breaking the problem into more manageable pieces.

The infrastructure includes switches and routers. The benefit of this distributed architecture is improved system availability and scalability. By interlinking multiple clusters. IP phones. With this overview as the starting point. Multiple CallManager servers are clustered and managed as a single entity. Your network design must be built for high availability. Triple call processing server redundancy improves overall system availability.

Video and Integrated Data includes many different components that come together to form a comprehensive architecture for voice. A voice-enabled network is a quality of service QoS -enabled network that gives precedence to voice. This chapter covers the basic components of the IP Telephony architecture in order to get a big-picture viewpoint of the system. CallManager clustering yields scalability of up to Multiple sites exist.

Multiple-Site Deployment Model. Figure shows an example of each separate site connecting via the PSTN. Figure shows an example of these components located at a single 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. At each remote site. Centralized Deployment Model. Locations-based call admission control prevents over-subscription of the WAN. Centralized Deployment Model A centralized call processing deployment model centrally locates CallManager.

Figure illustrates the centralized deployment model. Distributed Deployment Model. Figure depicts a distributed deployment model. Distributed Deployment Model In a distributed deployment model. One hundred or more sites could be interconnected via H. CallManager and applications are located at each site with up to Cisco Unity. Although infrastructure is not the primary focus of this book.

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. An expansion module for the Cisco IP Phone that provides 14 additional line or speed dial buttons.

It has the following features: The Expansion Module lets you add 14 buttons to the existing six buttons on the phone. 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. The 14 buttons on each Expansion Module can be programmed as directory numbers or speed dial buttons. The system administrator can designate separate VLANs Because these phones are largely soft key-based.

You can attach a headset by removing the handset and using the port into which the handset cord was attached. 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. A second version of the phone. Up to two Cisco s can be connected to a These phones feature a large pixel-based display that allows for XML-based applications on the phone. A dedicated headset port eliminates the need for a separate.

The phone provides a mute button for the handset and headset microphones. Multicolor button illumination allows you to identify which lines are ringing. CallManager controls routing and tones and provides supplementary services to the gateway. Compared to MGCP. The is an IP-based. MGCP provides the following services: Two gateways. Although the does not accept inline power from a Cisco inline power-capable switch. Using Skinny on these gateways allows the gateway to provide features such as message waiting indicators MWI.

These gateways interoperate with CallManager using various protocols. Each port on these gateways registers individually as a phone device. Windows NT. Personal Assistant provides rule-based call routing. Cisco Emergency Responder— An application that allows emergency agencies to identify the location of callers and eliminates the need for any administration when phones or people move from one location to another. 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.

Personal Assistant— A software application that selectively handles calls and helps you make outgoing calls. Windows When troubleshooting. These traces are usually reserved for Cisco development engineering use. This chapter covers the following topics: In addition. SDL traces describe the events occurring in the CallManager software at a code level. CCEmail— Details the third-party alerting tool that can be used in conjunction with PerfMon to configure alerts for the performance counters.

Later chapters demonstrate the use of these tools in different scenarios you might encounter. Depending on the problem you encounter and your particular skill set. If you are strong in IP. Event Viewer— Briefly explains the function of another built-in Windows tool that plays a key role in troubleshooting CallManager.

CCM trace files provide information about call processing events and all messages exchanged between Skinny. This ensures consistent timestamps regardless of which device you are looking at. CallManager Serviceability. The various information elements are decoded for ease of reading.

Cisco Bug Toolkit formerly Bug Navigator — Describes the web-based tool that allows you to find known bugs based on software version. If a problem occurs. Sniffer traces— Discusses when and why to use a network packet-capture tool. When you synchronize the time on all involved servers. When trace files are collected for analysis. As endpoints such as IP phones and voice gateways call each other.

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

Voice Codec Bandwidth Calculator— Describes how to use the Voice Codec Bandwidth Calculator to determine the bandwidth used by different codecs with various voice protocols over different media. This distributed architecture creates a highly available and scalable system. Time Synchronization Time synchronization is simply making sure that all the participating CallManager servers and network devices have the same exact time.

Time synchronization is critical. Also points you to a section in the "Introduction" with a recommended reading list. In addition to CallManager servers. A large CallManager cluster can have eight or more separate servers.

Verify IP network integrity. Determine the proper troubleshooting tool s , and use them to find the root cause. Production Versus Nonproduction Outages Troubleshooting a problem can occur in one of two timeframes: In the case of a service-affecting problem during production hours, the focus should be to quickly restore service by either resolving the problem or finding a suitable workaround. In contrast, when a problem is found during a new install or scheduled outage window, the focus should be on determining the root cause to ensure the problem is completely diagnosed and resolved so that it does not have the potential to become service-affecting.

For example, if users are encountering a delayed dial tone or sluggish behavior on their phones, you might discover that a high-level process on CallManager is consuming percent of the CPU on one of the servers. During a new install or scheduled outage window, it's a good idea to investigate what is causing the CPU consumption to ensure that the problem does not return during production hours. However, if this problem occurs during production hours, the best approach is to stop or restart the offending process and let the redundant systems take over to quickly restore service.

After you restore service, perform a root-cause analysis to try to determine why that process was consuming the CPU. The downside of this approach is that you might not be able to further troubleshoot the problem when the process is restarted.

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

Note that although percent CPU of a high-level process can cause sluggish behavior or delayed dial tone, do not infer from this that percent CPU is necessarily always a bad thing. As of CallManager 3. Look at the percent CPU as a possible symptom but not necessarily the root cause. In this case, you observe the symptoms of sluggish or delayed dial tone and percent CPU utilization and make a correlation between the two.

If you encounter an event where you are unable to determine the root cause due to insufficient information, it is a good idea to turn on the appropriate traces to ensure that if the problem reoccurs, you will have enough data to identify the root cause.

Sometimes, several service-affecting problems occur simultaneously. In fact, this is not uncommon, because multiple problems often manifest themselves as symptoms of the same root cause. When multiple problems occur simultaneously, focus on the problem that has the greatest impact on users. For example, if some users are reporting dropped calls and others are reporting occasional echo, the two problems are probably unrelated.

Troubleshoot the dropped-call problem first because keeping calls connected is more critical than removing the occasional echo on an active call. Step 1: Gathering Data About the Problem So you've just installed a new IP Telephony network, or you've been given the task of maintaining one—or maybe you've taken your first CallManager out of the box and are having problems getting it to run.

You've encountered a problem. The first thing to do is gather as much information about the problem as possible. 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. With so many different pieces composing an IP Telephony network, the first step is to isolate the problem and, if multiple problems are being reported, determine which of the problems might be related to each other and which should be identified as separate problems.

You must also determine which parts of the problem are symptoms and which are the root cause of the problem. For example, if a user complains of a phone resetting itself, it might seem logical to first assume that something is wrong with the phone. However, the problem might lie with CallManager or one of the many routers and switches that make up the underlying data network. So although the symptom is a phone reset, the root cause could be a WAN network outage or CallManager failure.

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.

To help you visualize the big picture, detailed topology information is essential. Using Topology Information to Isolate the Problem You can take many proactive steps to help make the troubleshooting process easier.

One of the first lines of defense is possessing current topology information. One of the most important pieces of topology information is a detailed network diagram usually created using Microsoft Visio or a similar application. The network diagram should include network addressing information and the names of all the devices. It should also clearly show how the devices are interconnected and the port numbers being used for these interconnections.

This information will prove invaluable when you try to isolate which components are involved in a particular problem. For medium- to larger-sized networks, you should have a high-level overview topology that gives you a general idea of how things are connected and then several more-detailed diagrams for each piece of the network that drill down to the interface level on your network devices.

Figure shows a typical high-level topology diagram for a large enterprise IP Telephony network. Notice that device names and IP addresses are listed in the diagram. This makes troubleshooting easier by allowing you to quickly look up devices to access them. Because Figure is a high-level diagram, it does not get down to the interface level of each device. Figure Sample High-Level Topology Diagram 4.

Most networks are not as large as the one shown in Figure However, no matter the size of your network, a similar topology diagram is very useful for quickly sharing information about your network with others who might be assisting you in troubleshooting. In addition to the network diagram, you should use some method to store information such as IP address assignments, device names, password information, and so on.

For a small network, you can use something as simple as a spreadsheet or even a plain text file. For larger deployments, some kind of database or network management application such as CiscoWorks is recommended.

Many customers keep all this topology information on a web server as well, making it quickly and easily accessible to others when it is needed the most. Be sure to keep this information in a secure location. You also need documentation of your dial plan. Some deployments, especially those heavily utilizing toll-bypass, have very complex dial plans.

Knowing where a call is supposed to go just by knowing the phone number and from where it is dialed helps you quickly understand a problem. When your topology information is complete, it should include all the following information: If any patch panels exist between devices, the port numbers should be listed. If you are troubleshooting a network you didn't design, topology is one of the first pieces of information you should obtain, if it's available.

If a topology drawing is not available, it is a good idea to spend time obtaining this information from someone who is familiar with the network and then making a quick sketch.

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. It's necessary when you're trying to isolate the problem to a particular part of the network. For example, if a user reports hearing choppy audio when making a conference call, it is essential to know exactly where in the network the conference bridge device is located in relation to the user's phone, including all the intermediate network devices.

Without a network diagram, finding this information could waste precious time. Assume that the network you are troubleshooting looks like Figure If the user's phone is connected to Access Switch 1A, the other conference participants are on Access Switch 1Z, and the conference bridge device is on Voice Switch 1A, you can see that the number of devices is greatly reduced from or more switches and routers to four or five. What is worse than not having topology information?

Having incorrect topology information can lead to countless hours heading down the wrong path. If you're going to keep topology information highly recommended , make sure you keep it current. 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. To further isolate the problem, interview the end users who reported the problem to gather additional information.

Gathering Information from the User Information the user provides can be vital to your ability to correct a problem. Try to gather as much detail as possible on exactly what the problem is. Often when troubleshooting a problem, you might realize that what you've been troubleshooting for hours is not really the problem the user encountered.

The more detail about the problem you can gather before you begin troubleshooting, the easier it is to find a resolution—and that means less frustration for you.

Here is some general information to collect from users: You can use this as search criteria if you need to look through traces. This includes what buttons were pressed and in what order.

This includes text messages displayed on the phone or recorded announcements. For example, if the user experienced a problem while using a phone, get the phone's MAC address and IP address, along with registration information and any other statistics available from the phone.

Sometimes the information provided by an end user is not enough to even begin troubleshooting. For example, if a user has trouble transferring calls, you should ask what steps the user took when the problem happened and, if possible, when the problem occurred so that you can examine traces. Sometimes the proper diagnostic tools are not enabled when the problem occurs, forcing you to ask the user to inform you the next time the problem occurs.

Be sure to turn on tracing or debugs before making the request so that when the problem occurs again, you will have captured the data. Users can get quite irritated if you have to ask them for the same piece of information two or three times. Also point out to the user the importance of letting you know immediately after a problem occurs, as many of the diagnostic trace files overwrite themselves within several hours or days depending on the amount of traffic on your system.

Determining the Problem's Timeframe In addition to what the problem is, you should try to determine when the problem occurred. 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.

For example, assume that a regular workday begins at 9 a. Many users report that they get a busy signal when dialing into their voice mail. It is important to know whether they are attempting to do this at 9: This might change the problem from a troubleshooting issue to a load-balancing or equipment-expansion issue. You check the voice mail system and notice that at the time the problem was reported, all the voice mail ports were in use. Clearly in this example you need more voice mail ports or servers to handle call volume.

However, if the problem occurs at As another example, if a user reports that her phone was not working for 10 minutes and you know there was a network outage in her part of the building at that time, you can be relatively sure that the problem was due to the network outage.

When relying on end users to give quot;whenquot; information about a problem, ask them to note the time on their phone when the problem occurred. The phone's time is synchronized with the clock on the CallManager to which the phone is registered. As long as you have the time on your CallManagers and network devices synchronized, having a phone-based time from the user makes finding the proper trace files very easy.

In some cases, the information about when a problem occurred might be the only piece of information you have other than a limited description of the problem at hand.

Paul pdf troubleshooting giralt cisco ip telephony

If you have information about when, you might be able to look through trace files during that timeframe to search for anything abnormal. TIP Although it is important to use information about when the problem started happening, it is equally important to not assume that the problem was a direct result of an event.

For example, if a user reports a problem the day after an upgrade was performed on CallManager, you might give some credence to the notion that the upgrade might have caused the problem, but don't automatically assume that this is the root cause. Step 2: 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, the easier it is to find the root cause. For example, if a user complains about choppy voice quality, consider some of the following questions to help isolate the real problem, and think about how the answer will help narrow your focus: If so, you can probably eliminate hundreds or thousands of other phones as suspects. However, keep in mind a single user's perspective. He might think the problem happens only on his phone, so you'll have to ask other users to see if the problem is more widespread than a single phone.

The answer to this question helps determine which parts of the system are being used when the problem occurs. For example, if the user never experiences poor audio quality when calling certain numbers but always experiences it when calling other numbers, this is a big clue.

The user probably won't know the answer, but you'll be able to answer this question yourself after you answer the preceding question about which numbers are being called when the problem happens. You will find more detailed questions similar to these throughout this book when troubleshooting particular problems. Although not all of the following apply to every problem, where applicable, you must check all of the following pieces involved in the call.

Use your topology information to help obtain this information. For example, if all the users on a particular floor are having the same problem, concentrate on the problem a particular user is having. If you fix the problem for that one user, in most cases you fix it for all the affected users.

Verifying IP Network Integrity 7. One thing that people often forget is that your IP Telephony network is only as good as your IP network. A degraded network or a network outage can cause a wide range of problems, ranging from slight voice quality problems to a total inability to make or receive calls on one or more phones. The network is always a consideration when you encounter certain problems, so network health issues are covered throughout this book. Check your physical layer connectivity cables, patch panels, fiber connectors, and so on.

Then make sure you have Layer 2 connectivity by checking for errors on ports, ensuring that Layer 2 switches are functioning properly, and so forth. Continue working your way up the stack until you reach the application layer Layer 7. As an example, two of the most common reasons for one-way audio where one side of the conversation cannot hear the other are the lack of an IP route from one phone to another and the lack of a default gateway being configured on a phone.

Taking the layered approach, you would first check the cabling and switches to make sure that there are no errors on the ports. You would then check Layer 3, the network layer, by ensuring that IP routing is working correctly.

When you reach this layer, you discover that for some reason the IP packets from one phone are unable to reach the other phone. Upon further investigation, you might discover that there was a missing IP route on one of the routers in the network or a missing default gateway on one of the end devices such as an IP phone or voice gateway. 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, you must select the proper tool s to troubleshoot the problem.

Most components have multiple troubleshooting tools available to help you. Chapter 3, quot;Understanding the Troubleshooting Tools,quot; provides more details about some of the tools available for troubleshooting CallManager. You should use the tracing and debugging facilities available in CallManager and other devices to determine exactly what is happening. Additional tools and traces are covered in the chapter associated with diagnosing certain types of problems.

Because CallManager is central to almost all problems, information about various portions of the CCM trace facilities appears throughout this book. 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.

In this case, you should try various tools in search of anything that looks out of the ordinary. The following case study shows how this troubleshooting methodology works in a real-world scenario.

Case Study: The only data you have is the page you received at 5: Please help ASAP! This case study applies the methodology previously described. You must gather the data before you can begin the analysis. Gathering the Data As part of the data-gathering stage, you should do the following: He states that at various times during the previous day and one time this morning, the CEO is on the phone when, all of the sudden, the call is disconnected.

Eager to resolve the problem, you ask the administrative assistant for the following information: This is the extent of the information he remembers.

Most users do not pay attention to specifics like this unless they have been instructed to, but all is not lost. The CEO has a phone that stores information locally about missed calls, received calls, and placed calls. You head into the CEO's office and look at the list of received calls and placed calls for the morning. You notice that a call was received at 5: You notice that the second call was placed to the same area code and prefix as the call that was received.

You ask the CEO about the two calls. 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. She also confirms that the first call that was received was the dropped call. Now you know that the problematic call was received at approximately 5: This lets you isolate which CallManager in the cluster is involved in the signaling for this phone.

Armed with this information, you can begin the task of isolating the problem. You refer to your topology diagram to isolate the components that are involved. Figure shows a high-level diagram of the network topology. The telephone company has set up the inbound calls so that the 32 gateways are redundant whereby if one of the gateways is down, all your incoming calls can still use any of the other remaining gateways. All outbound calls prefer the first gateway, and inbound calls prefer the second gateway, although each can handle both inbound and outbound calls should one fail.

As shown in Figure , the executive offices are at a remote site across the WAN. With just the information you have so far, you can eliminate a large portion of the network. So far you know that the problematic call was to the CEO. 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.

As far as they can remember, they were. You know that the call this morning was during a time of day where there is little phone activity. 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.

It is unlikely that all the channels on the first PRI were in use during a time of low call volume, so you assume that the call probably came in through the second gateway, although you still keep it in the back of your mind that the call might have come in through the first gateway at the remote site.

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.

With the information you have so far, you can narrow down the possible suspect devices to the network shown in Figure Armed with this knowledge, you can immediately isolate the problem to the user's phone and the two gateways being used for inbound calls. Keep in mind that you haven't eliminated the possibility that the problem is on CallManager or is network-related. Now that you know the problem is related to inbound calls, it makes sense to try to understand the call flow for an inbound call to this user.

Determine whether these calls all come directly to the user or if the call flow has any intermediate steps, such as Cisco IP Auto Attendant Cisco IP AA or an operator who transfers the call to the end user.

You have now eliminated Cisco IP AA from the picture, as well as the possibility that other phones or users are involved in this user's problems. This is not to say that other users are not experiencing similar problems, but the focus here is on solving this particular user's problem.

If the problem is more widespread than this one user, you will probably find it as you continue to troubleshoot this user's problem. At this point, the problem has been isolated to the following culprits: This concludes the data-gathering piece of your investigation. Now it is time to start analyzing the data. After you isolate the problem, you must break it into smaller pieces.