Troubleshooting guide

4-14
Cisco Broadband Local Integrated Services Solution Troubleshooting Guide
OL-5169-01
Chapter 4 Troubleshooting with Call Flows
Call Flow Analysis
• The MTA has been successfully provisioned and is ready for use.
• The call attempt is successful (that is, the call flow is complete without errors).
• You know the approximate time that the call was made.
The time of the call is used to find the likely location of the MGCP messages in the LAN analyzer
trace. It is important that the analyzer time, which is used to timestamp messages, be synchronized
with network time—the time that the trouble is reported. Without accurate time information, it may
be more difficult to locate the messaging associated with the call instance in question, especially if
the endpoint has made several calls during the day.
The following steps describe how to link call flow messages together:
Step 1 To trace the call, begin by identifying the endpoint ID associated with the troubled phone number. For
example, if a caller reports inability to get dial tone, use provisioning records to identify which endpoint
ID has been assigned to this customer.
The single most important field in correlating MGCP messages is the endpoint ID. This parameter
identifies the logical name of the endpoint being controlled by the Call Agent. Most trouble reports begin
by identifying a phone number, such as:
• Which end has trouble; for example, “The customer cannot call from 404-524-1234.”
• Which end cannot be reached; for example, “Caller gets reorder tone when dialing 515-223-1256.”
The endpoint ID is critical because it is always constant. The IP address assigned to the customer’s phone
may change, since IP addresses are dynamically assigned by DHCP, but the endpoint ID remains static.
Step 2 Find the approximate time that the call attempt was made; then locate the NTFY message around that
time period with the desired endpoint ID. The NTFY should indicate an off-hook (HU observed event)
and should contain a transactionID. Write down the originating IP address from the NTFY. This tells you
the IP address currently assigned to the MTA, which should not change during the call setup (although
it could change between calls). The originating IP address is necessary to identify ACK messages that
come from the MTA.
Identify the source and destination IP addresses of the nodes involved in the call setup (refer to the
example in Step 1). This allows you to find the ACK (or NACK) messages for each MGCP command.
The ACKs (or NACKs) are critical for determining if a node has trouble with a requested command.
Here is a sample notify message and a return acknowledge message to demonstrate how values are
repeated to connect the two messages:
NTFY xsactionID=1 sourceIP=<X> destIP=<Y>
ACK xsactionID=1 sourceIP=<Y> destIP=<X>
Step 3 The Call Agent responds to the NTFY with an ACK that echoes the transaction ID. Make note of the
originating IP address in the ACK. This is the current IP address of the Call Agent, and (in most cases)
remains the same over the duration of the call.
At this point, the following information is known: the MTA endpointID involved in the call, the IP
address of the MTA, and the IP address of the call agent. The IP address of the egress gateway (in this
example, the TGW) is not yet known.
Step 4 Find the MGCP command messages (and ACKs) associated with call setup at the originating side by
looking for MGCP messages that include the MTA endpoint ID, up to and including the CRCX to the
MTA.