G Pankaj Bhagchandani, Pankaj Bhagchandani, Pankaj G Bhagchandani, Pankaj Bhagchandani G, Pankaj G: Pankaj Bhagchandani, Pankaj Bhagchandani G, G Pankaj Bhagchandani, G Pankaj Bhagchandani G, Pankaj G Bhagchandani G, Pankaj G Bhagchandani,

Debug Command Output on Cisco IOS Voice Gateways

The debugging capability for Cisco voice gateways enables you to identify and track a specific call in a multiple-call environment. This capability allows you to correlate call information between gateways or to identify specific debug messages associated with a single call when multiple voice calls were simultaneously active.

Voice debug output contains a standardized header to the debug outputs of multiple voice modules, such as voice telephony service provider (VTSP), call control application program interface (CCAPI), session application (SSAPP), and interactive voice response (IVR).

The following information can be found in the Cisco IOS Debug Command Reference:

•

Using debug commands is contained in the "Using Debug Commands" chapter.

•

Conditionally triggered debugging is contained in the "Conditionally-Triggered Debugging" chapter.

•

Details about individual debug commands are listed.

This chapter contains the following information:

•

Voice Debug Concepts

•

Managing the Voice Call Debug Output

•

Sample Output Examples for the Enhanced debug Commands

Voice Debug Concepts

The following concepts provide background for the enhanced debug capabilities on Cisco voice gateways:

•

Debug Header Format

•

CallEntry ID and GUID Call Legs

•

Enabling Command Profile Debugging

•

Enabling Individual Debug Commands for CCAPI, TSP, and VTSP Debugging

Debug Header Format

You can control the contents of the standardized header with the following display options:

•

Short 6-byte global unique identifier (GUID)

•

Full 16-byte GUID

•

Short header that contains only the CallEntry ID

The format of the GUID headers is as follows:
//CallEntryID/GUID/Module-dependent-list/Function-name:

The format of the short header is as follows:
//CallEntryID/Function-name:

The parameters in the header are as follows:

•

CallEntryID—Numerically identifies a specific call leg such as an incoming ISDN call or an outgoing H.323 call. The CallentryID ranges from 1 to 32767. When the CallEntryID is not available to the function producing the debug message, the header displays the CallEntryID field as "-1."

•

GUID—Each call is assigned a GUID, which is generally used for billing purposes. The GUID is a 16-byte quantity that uniquely identifies a call throughout the entire network and over time. Gateway information and time stamp are embedded in the GUID. The GUID is sometimes called a conference point. See the "CallEntry ID and GUID Call Legs" section for an example of the GUID and CallEntry ID call legs.

By default, the debug header displays a more compact 6-byte form of the GUID that is generally unique enough for debugging purposes. If you need to correlate GUID information to third-party devices or to conduct debugging sessions lasting more than a month, you can display the full 16-byte header with the voice call debug command using the full-guid keyword.

When the GUID information is unavailable to the module producing the debug message, the header displays the GUID field as blank or filled with "x" characters (/xxxxxxx/). For non-IVR debugs, if the GUID field is unavailable, the header is //CallentryID/xxxxxxxx/. For IVR debugs, the header is //CallentryID//. IVR rarely has GUID information but reserves the space in order to have field-by-field consistency.

•

Module-dependent-list—These parameters are dependent on which module is used. The dependent parameters for the various modules are shown inTable 1.

Table 1 Module-Dependent List Parameters
Module	Dependent Parameters
CCAPI	None.
VTSP	Port name, channel number, DSP slot, and DSP channel number.
SSAPP	Dial-peer number and the number of the connection through the dial peer. (Multiple sessions can be associated with a single dial peer.)
IVR	See the "IVR Module-Dependent List" section.

•

Function-name—Identifies call progress though the internal modules of the Cisco IOS code. This is free-form debugging used by developers.

IVR Module-Dependent List

The module-dependent list for IVR information has the following form:
<Module Name> : [LP:] [<OBJ><OBJ-ID>: [<OBJ><OBJ-ID>:[...]]]

Module names are shown in Table 2. The LP parameter is the link point, which is the point where two or more objects can be associated . The OBJ parameter is the object name, shown in Table 3. The OBJ-ID is a numeric identifier for the object. The ranges are also shown in Table 3.

Table 2 IVR Module Names
Module Name	Module
AAPL	Application infrastructure
DCM	Digit collect
DPM	Dynamic prompt
MCM	Media content
MSM	Media stream
MSW	Media service wrapper
PCM	Place call (call setup)
RTSP	Real-time streaming protocol (RTSP) client
TCL2	Tcl IVR 2

Table 3 Object Names and Identifier Values
Object Name	Description	Identifier Range
CN	Connection	-2147483647 to 2147483647 with 0 and -1 being invalid (either) or unavailable (latter)
DP	Dynamic prompt	1 to -4294967295 or 0 (invalid or unavailable)
GS	Generic stream	1 to -4294967295 or 0 (invalid or unavailable)
HN	Handler	0 to -4294967295
LG	Call leg	1 to -2147483647 or -1 (invalid or unavailable)
MC	Media content	1 to -4294967295 or 0 (invalid or unavailable)
MR	Media content reader	1 to -4294967295 or 0 (invalid or unavailable)
MS	Media stream	1 to -4294967295 or 0 (invalid or unavailable)
RS	RTSP session	1 to -4294967295 or 0 (invalid or unavailable)

CallEntry ID and GUID Call Legs

The parts of the call that are identified by CallEntry IDs and GUIDs are shown in Figure 8. The example shown in the figure is a conference call in which two of the participants are on the same IP network and the third participant is called over the POTS network. Most of the IP-based voice signaling protocols (like H.225) carry the GUID information between gateways. Traditional voice connections such as POTS and ISDN have no means to carry a GUID. A voice gateway creates a new GUID when one is not available from the call originator. In the example, call legs 1, 2, and 5 use GUID A, and leg 4 uses GUID B. Leg 3 is across the POTS network, so no GUID is associated with it. There is a CallEntry ID for each incoming or outgoing call on each gateway.

Figure 8 GUIDs and CallEntry IDs in a Conference Call

Enabling Command Profile Debugging

You can enable a set of debugs based upon a specific profile. You can enable the following profiles:

•

Fax Debug Profile

•

Modem Debug Profile

•

Voice Debug Profile

Enabling the debugging on each of these profiles produces many types of debug information. The advantage of using profile debugging is that instead of having to enable several debug commands to get a full picture of the problem, you can enable a profile which gives you all of the debugs that are appropriate.

When profile debugging is enabled, a large number of debug messages are produced which might affect system performance. For this reason, you should only use profile debugging during low traffic periods or on a non-production system.

Caution

The debug voip profile commands generate debug messages from many VoIP components, which generates a large number of debug messages. The number of messages can cause a performance impact on your router. This command should only be used during low traffic periods.

Fax Debug Profile

The debug commands that are activated within the fax debug profile depends on the syntax that you use when you enable the command. The syntax for the fax debug profile is as follows:

debug voip profile fax { mail | relay { application | signaling }}

For more information on command syntax, refer to the Cisco IOS Debug Command Reference.

If you use the debug voip profile fax mail command, you enable the following debug commands for an onramp or offramp fax mail call:

•

debug crm all

•

debug csm voice

•

debug fax fmsp all

•

debug fax mta all

•

debug fax mmoip aaa

•

debug isdn q931

•

debug tgrm all

•

debug voip application all

•

debug voip application vxml all

•

debug voip ccapi all

•

debug voip dsm all

•

debug voip dspapi all

•

debug voip hpi all

•

debug voip ivr all

•

debug voip vtsp all

The following debug commands are enabled for access servers with MICA modem cards:

•

debug fax receive all

•

debug fax send all

•

debug fax fmail client

•

debug fax fmail server

•

debug fax text-to-fax

•

debug fax tiff reader

•

debug fax tiff writer

The following debug options are enabled for access servers with universal port dial feature cards:

•

debug fax fmsp all

•

debug fax foip all

•

debug fax dmsp all

•

debug fax mspi all

•

debug voip application vxml all

•

debug voip ivr all

If you use the debug voip profile fax relay command, you enable the debug fax relay t30 all-level-1 and the sets specified by either the application orsignaling keyword.

For the debug voip profile fax relay application command, the following debugs are enabled for fax relay applications:

•

debug voip application all

•

debug voip application vxml all

•

debug voip ccapi all

•

debug voip dialpeer all

•

debug voip ivr all

For the debug voip profile fax relay signaling command, the following debugs are enabled for fax relay signaling:

•

debug cch323 all

•

debug ccsip error

•

debug ccsip messages

•

debug cdapi detail

•

debug cdapi events

•

debug crm all

•

debug csm voice

•

debug gtd error

•

debug gtd events

•

debug h225 asn1

•

debug h225 events

•

debug h225 q931

•

debug h245 asn1

•

debug h245 event

•

debug isdn q931

•

debug mgcp errors

•

debug mgcp events

•

debug mgcp media

•

debug mgcp packets

•

debug mgcp voipcac

•

debug rtpspi all

•

debug tgrm all

•

debug voip ccapi all

•

debug voip dsm all

•

debug voip dspapi all

•

debug voip hpi all

•

debug voip rawmsg

•

debug voip tsp all

•

debug voip vtsp all

For detailed information about the individual debug commands, refer to the Cisco IOS Debug Command Reference.

Modem Debug Profile

The debug commands that are activated within the modem debug profile depends on the syntax that you use when you enable the command. The syntax for the modem debug profile is as follows:

debug voip profile modem { pass-through signaling | relay signaling }

For more information on command syntax, refer to the Cisco IOS Debug Command Reference.

If you use the debug voip profile modem pass-through signaling command, you enable the following debug commands for modem pass-through signaling:

•

debug cch323 all

•

debug ccsip error

•

debug ccsip messages

•

debug cdapi detail

•