Troubleshooting guide

4-16
Cisco Broadband Local Integrated Services Solution Troubleshooting Guide
OL-5169-01
Chapter 4 Troubleshooting with Call Flows
Call Flow Analysis
If this is a new service, verify that the line was properly provisioned in the Call Agent, and data was input
to DHCP/LDAP. Allow time for the provisioning changes to flow through.
Assuming that the MTA is connected and has been working, you need to trace the call flow.
See Chapter 4, “Troubleshooting with Call Flows,” for the procedure for tracing a call flow.
An analysis of the call flows can reveal one of the following scenarios and narrow your investigation:
• MTA is not sending a NTFY message on off-hook.
Check the MTA configuration file to verify the proper notified entity (Call Agent), DHCP settings,
and endpoint settings; then reset the MTA and verify this information again.
• MTA sent a NTFY message, but the Call Agent did not receive it (you can see repeated NTFY
messages from the modem).
Trace the route to view the hops the packet makes on the way to the Call Agent to isolate where the
problem is occurring. If a particular router is causing the problem, more than one customer will be
involved and the problem router will be in their common path. Fixing a routing problem may require
further investigation into routing tables.
• The Call Agent received the NTFY message, but did not respond (no ACK or RQNT messages seen
at Call Agent links).
– The problem is with the Call Agent.
– The connection manager cluster may require restart. In this scenario, multiple lines are affected,
all belonging to the same cluster.
• The Call Agent sent an ACK message (in response to an initial NTFY message from the MTA), but
it was not received by the MTA. Do either of the following:
– Turn on debug for the MTA to determine the problem.
– The problem is in the network.
Trace the route from the Call Agent to the MTA to see where the route stops.
Fixing the problem may require further investigation into routing tables.
No Post-Dial Cut-Through (No Ringback) — On-Net to On-Net
In this scenario, the customer receives dial tone, dials the number, and then expects to hear ringback
(or a network announcement), but instead hears nothing.
If the caller is able to receive dial tone, then the Call Agent and originating MTA were able to exchange
messages. This implies that there is no basic network connectivity problem with the originating MTA;
however, connectivity problems with the terminating MTA are not ruled out.
The call flow extract below shows the message exchange required to reach the point where ringing is
heard. To reach this point, MGCP messages must be exchanged to create VoIP “connections” on the
originating and terminating MTAs. Calls fail if they cannot get past this stage; that is, the CRCX to the
originating or terminating end is not successful, resulting in a NAK from the gateway instead of an ACK.