Enhanced Debug Capabilities for Cisco Voice Gateways [Cisco IOS Software Releases 12.2 T]

Table Of Contents

Enhanced Debug Capabilities for Cisco Voice Gateways

Contents

Information About Enhanced Debug Capabilities for Cisco Voice Gateways

Debug Header Format

IVR Module Dependent List

CallEntry ID and GUID Call Legs

How to Manage the Voice Call Debug Output

Sample Output Examples for the Enhanced Debug Commands

Full GUID Header Example

Short Header Example

Setup and Teardown Example

Additional References

Related Documents

MIBs

Technical Assistance

Command Reference

debug rtsp all

debug rtsp api

debug rtsp client

debug rtsp error

debug rtsp pmh

debug rtsp session

debug rtsp socket

debug voip ccapi error

debug voip ccapi inout

debug voip ivr all

debug voip ivr applib

debug voip ivr callsetup

debug voip ivr digitcollect

debug voip ivr dynamic

debug voip ivr error

debug voip ivr script

debug voip ivr settlement

debug voip ivr states

debug voip ivr tclcommands

debug voip rawmsg

debug vtsp all

debug vtsp dsp

debug vtsp error

debug vtsp event

debug vtsp port

debug vtsp rtp

debug vtsp send-nse

debug vtsp session

debug vtsp stats

debug vtsp tone

debug vtsp vofr subframe

voice call debug

Enhanced Debug Capabilities for Cisco Voice Gateways

This feature module describes enhanced debugging capabilities for Cisco voice gateways.

Feature Specifications for the Enhanced Debug Capabilities for Cisco Voice Gateways

Feature History

Release

Modification

12.2(11)T

This feature added a call identification header for Cisco voice gateways to the following Cisco routers: Cisco 2600 series, Cisco 3620, Cisco 3640, and Cisco 3660; on the following universal gateways: Cisco AS5350, Cisco AS5400, and Cisco AS5850; on the following universal access servers: Cisco AS5300, and Cisco AS5800; and, on the Cisco MC3810 multiservice access concentrators.

12.2(15)T

The header-only option was removed and the short-header option was added.

Supported Platforms

Cisco 2600 series, Cisco 3620, Cisco 3640, and Cisco 3660, Cisco AS5300, Cisco AS5350, Cisco AS5400, Cisco AS5800, Cisco AS5850, and Cisco MC3810 multiservice access concentrators.

Finding Support Information for Platforms and Cisco IOS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.

Contents

•Information About Enhanced Debug Capabilities for Cisco Voice Gateways

•How to Manage the Voice Call Debug Output

•Sample Output Examples for the Enhanced Debug Commands

•Additional References

•Command Reference

Information About Enhanced Debug Capabilities for Cisco Voice Gateways

The enhanced debugging capability for Cisco voice gateways provides improvements to the debugging output in order to identify and track a specific call in a multiple-call environment. Before the implementation of this feature, it was difficult to correlate call information between gateways or to identify specific debug messages associated with a single call, when multiple voice calls were simultaneously active. The output was unstructured and presented in a free form.

This feature adds 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).

Use the following concepts to better understand the enhanced debug capabilities on Cisco voice gateways:

•Debug Header Format, page 2

•CallEntry ID and GUID Call Legs, page 4

Debug Header Format

The user can control the contents of the standardized header. The display options for the header are as follows:

•Short 6-byte GUID

•Full 16-byte GUID

•Short header which contains only the CallEntry ID

The format of the GUID headers are 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 between 1 and 32767. When the CallEntryID is not available to the function producing the debug message, the header displays the CallEntryID field as "-1."

•GUID—The global unique identifier (GUID) is a "meeting point" of multiple call legs, sometimes called a conference point. 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 all time. Gateway information and timestamp are embedded in the GUID. See the "CallEntry ID and GUID Call Legs" section on page 4 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 there is a need to correlate GUID information to third-party devices or to conduct debugging sessions lasting more than a month, the user 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" (/xxxxxxx/). For non-IVR debugs, if the GUID field is unavailable, the header displays as //CallentryID/xxxxxxxx/. For IVR debugs, the header displays as //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 in Table 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 (there can be multiple sessions 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 1. The LP parameter is the link point, which is the point where two or more objects can be associated together. The OBJ parameter is the object name, shown in Table 2. The OBJ-ID is a numeric identifier for the object and the ranges are also shown in Table 2.

Table 2 IVR Module Names

Module Name

Module

AAPL

Application infrastruction

DCM

Digit collect

DPM

Dynamic prompt

MCM

Media content

MSM

Media stream

MSW

Media service wrapper

PCM

Place call (call setup)

RTSP

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 1. 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 illustrated example, call legs 1, 2, and 5 use GUID A, while leg 4 uses GUID B. Leg 3 is across the POTS network, so no GUID is associated with it. Note that there is a CallEntry ID for each incoming or outgoing call on each gateway.

Figure 1 GUIDs and CallEntry IDs in a Conference Call

How to Manage the Voice Call Debug Output

The debug output for calls on Cisco voice gateways is managed by using the voice call debug command in global configuration mode. When this command is enabled, the standardized header appears when voice debugs are used.

SUMMARY STEPS

1. enable

2. configure {terminal | memory | network}

3. voice call debug {full-guid | short-header }

4. exit

5. debug {rstp | voip ccapi | voip ivr | voip rawmsg | vtsp}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable
Example:

Router> enable

Enables privileged EXEC mode.

•Enter your password if prompted.

Step 2

configure terminal
Example:

Router# configure terminal

Enters global configuration mode.

Step 3

voice call debug {full-guid | short-header}
Example:

Router(config)# voice call debug full-guid

Specifies the full GUID or short header for debugging a voice call in a multiple-call environment.

•full-guid—Displays the GUID in a 16-byte header. When the no version of this command is input with the full-guid keyword, the short 6-byte version displays. This is the default.

•short-header—Displays the CallEntry ID in the header without displaying the GUID or module-specific parameters.

Step 4

exit
Example:

Router(config)# exit

Exits to privileged EXEC mode.

Step 5

debug rtsp {all | api | client | error | pmh | session | socket}
debug voip ccapi {error | inout}
debug voip ivr {all | applib | callsetup | digitcollect | dynamic | error | script | settlement | states | tclcommands}
debug voip rawmsg
debug vtsp {all | dsp | error | event | port | rtp | send-nse | session | stats | vofr subframe | tone}
Example:

Router# debug voip ccapi inout

Enter the appropriate debug command for your troubleshooting needs. The debug commands that support the standardized header and detailed examples of the individual debug commands are in the "Command Reference" section.

The debug commands that support the standardized header include the following:

•debug rtsp all

•debug rtsp api

•debug rtsp client

•debug rtsp error

•debug rtsp pmh

•debug rtsp socket

•debug voip ccapi error

•debug voip ccapi inout

•debug voip ivr all

•debug voip ivr applib

•debug voip ivr callsetup

•debug voip ivr digitcollect

•debug voip ivr dynamic

•debug voip ivr error

•debug voip ivr script

•debug voip ivr settlement

•debug voip ivr states

•debug voip ivr tclcommands

•debug voip rawmsg

•debug vtsp all

•debug vtsp dsp

•debug vtsp error

•debug vtsp event

•debug vtsp port

•debug vtsp rtp

•debug vtsp send-nse

•debug vtsp session

•debug vtsp stats

•debug vtsp vofr subframe

•debug vtsp tone

For detailed examples of these debug commands, see the "Command Reference" section.

Sample Output Examples for the Enhanced Debug Commands

This section provides sample output examples for the enhanced debug commands, including:

•Full GUID Header Example

•Short Header Example

•Setup and Teardown Example

Full GUID Header Example

The following is sample output for the voice call debug command when the full-guid keyword is specified:
Router(config)# voice call debug full-guid
!
00:05:12: //1/0E2C8A90-BC00-11D5-8002-DACCFDCEF87D/VTSP:(0:D):0:0:4385/vtsp_insert_cdb: 
00:05:12: //-1/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: 
In the first line, the following parameters are described:

•1 denotes the CallEntry ID.

•0E2C8A90-BC00-11D5-8002-DACCFDCEF87D is the GUID.

•VTSP:(0:D):0:0:4385 is the module and its dependent parameters. In this case, the module is VTSP, the port number is 0:D, the channel number is 0, the DSP slot is 0, and the DSP channel number is 4385.

•vtsp_insert_cdb: is the function name.

In the second line, the following parameters are described:

•-1 indicates that the CallEntry ID for the CCAPI module is unavailable.

•xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx indicates that the GUID is unavailable.

•CCAPI is the module.

•cc_incr_if_call_volume: is the function name.

Short Header Example

The following is sample output for the voice call debug command when the header-only keyword is specified:
Router(config)# voice call debug short-header
!
00:10:12: //-1/cc_incr_if_call_volume:
00:10:12: //9/vtsp_open_voice_and_set_params:
In the first line, the CallEntry ID is not available, and in the following line the CallEntry ID is 9. The remainder of the line displays the function name.

Setup and Teardown Example

In the following example, the debug voip ccapi inout command used with the voice call debug full-guid command traces the execution path through the call control API, which serves as the interface between the call session application and the underlying network-specific software. This output shows how calls are being handled by the voice gateway. Using this debug level, you can see the call setup and teardown operations performed on both the telephony and network call legs.
Router# debug voip ccapi inout
*Mar  1 15:35:53.588: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer: 
usrContainer[0x638C1BF0], magic[FACE0FFF]
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: 
container=0x638C1BF0, tagID=6, dataSize=16, instID=-1,modifier=1
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: 
tdObject[0x638BC1AC], nxtElem[0x0], magic[0xFACE0FFF] tagID[6], dataLen[16], modif[1]
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding 
tdObject[0x638BC1AC] instID[-1] into container[0x638C1BF0]
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: 
container=0x638C1BF0, tagID=5, dataSize=276, instID=-1,modifier=1
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: 
tdObject[0x63401148], nxtElem[0x0], magic[0xFACE0FFF] tagID[5], dataLen[276], modif[1]
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding 
tdObject[0x63401148] instID[-1] into container[0x638C1BF0]
Note In the following lines, the call control API (CCAPI) receives the call setup. The called number is 34999, and the calling number is 55555. The calling number matches dial peer 10002.
*Mar  1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:
*Mar  1 15:35:53.592: cc_api_call_setup_ind:
*Mar  1 15:35:53.592:  cisco-username=
*Mar  1 15:35:53.596: ----- ccCallInfo IE subfields -----
*Mar  1 15:35:53.596:  cisco-ani=55555
*Mar  1 15:35:53.596:  cisco-anitype=0
*Mar  1 15:35:53.596:  cisco-aniplan=0
*Mar  1 15:35:53.596:  cisco-anipi=0 
*Mar  1 15:35:53.596:  cisco-anisi=0
*Mar  1 15:35:53.596:  dest=34999
*Mar  1 15:35:53.596:  cisco-desttype=0
*Mar  1 15:35:53.596:  cisco-destplan=0 
*Mar  1 15:35:53.596:  cisco-rdn=
*Mar  1 15:35:53.596:  cisco-rdntype=-1
*Mar  1 15:35:53.596:  cisco-rdnplan=-1 
*Mar  1 15:35:53.596:  cisco-rdnpi=-1
*Mar  1 15:35:53.596:  cisco-rdnsi=-1
*Mar  1 15:35:53.596:  cisco-redirectreason=-1
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x637EC1E0, 
callInfo={called=34999,called_oct3=0x80,calling=55555,calling_oct3=0x80,calling_oct3a=0x0,
calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=10002, 
prog_ind=0,callingIE_present 1, src_route_label=, tgt_route_label= 
clid_transparent=0},callID=0x637B4278)
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind:
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: type 13 , prot 0
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.596: ccCheckClipClir: calling number is: "55555", calling oct3a is: 0x0
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.596: Calling Party number is User Provided
*Mar  1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.596: Leaving ccCheckClipClir
  calling number is: "55555"
  calling oct3 is:  0x80
  calling oct3a is: 0x0
Note In the next line, 44 is the CallEntry ID.
*Mar  1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 
0 
*Mar  1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current call volume: 1
*Mar  1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry's incoming TRUE.
*Mar  1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incomingis TRUE
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: 
profileTable[0x6380E11C], numBuckets[11], numEntries[0]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking 
necessary profileTable updaters...
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: 
Updating profileTable[0x6380E11C] with objects in container[0x638C1BF0]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: 
obtained key[5] for the tag[6]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: 
profileTable[0x6380E11C], tdObject[0x638BC1AC]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: 
obtained key[0] for the tag[5]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: 
profileTable[0x6380E11C], tdObject[0x63401148]
*Mar  1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:
*Mar  1 15:35:53.600: ccTDUtilDumpAllElemInProfileTab: profileTable[0x6380E11C],
 numBuckets[11], numEntries[2]
*Mar  1 15:35:53.600: Bucket { 0 } ------>0x63401148[0x0,t-5,l-276,d-0x63401168,
m-1,u-56153,g-FACE0FFF]
*Mar  1 15:35:53.604:
*Mar  1 15:35:53.604: Bucket { 5 } 
------>0x638BC1AC[0x0,t-6,l-16,d-0x638BC1CC,m-1,u-56153,g-FACE0FFF]
*Mar  1 15:35:53.604:
*Mar  1 15:35:53.604: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: 
Container[0x638C1BF0]
*Mar  1 15:35:53.604: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: not the VoIP or 
MMoIP
*Mar  1 15:35:53.608: //-1/xxxxxxxxxxxx/CCAPI/cc_process_call_setup_ind: (event=
0x63073AA0)
Note In the next line, 45F2AAE28044 is the GUID. The tag 10002 entry shows that the incoming dial-peer matched the CallEntry ID.
*Mar  1 15:35:53.608: //44/45F2AAE28044/CCAPI/cc_process_call_setup_ind: >>>>CCAPI handed 
cid 44 with tag 10002 to app "DEFAULT" 
*Mar  1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(24=CC_EV_CALL_SETUP_IND), cid(44), disp(0)
*Mar  1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(SSA_EV_CALL_SETUP_IND), 
cid(44), disp(0)
*Mar  1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/ssaCallSetupInd:
Note The next line shows CallEntry ID in hexadecimal form, 0x2C (44 in decimal). The CallEntry ID and GUID numbers have been identified. The incoming dial-peer is 10002.
*Mar  1 15:35:53.608: //44/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0x2C, 
context=0x634A430C) 
*Mar  1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: cid(44), 
st(SSA_CS_MAPPING),oldst(0), ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1 
*Mar  1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: src route label=, 
tgt route label= tg_label_flag 0x0
*Mar  1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: finalDest 
cllng(55555), clled(34999) tgt_route_label()tg_label_flag 0x0
*Mar  1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: cid(44), 
st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0
Note For CallEntry ID 44, two dial-peer tags (10001 and 20002) were matched with called number 34999.
*Mar  1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaDebugPeers: ssaSetupPeer cid(44) 
peer list: tag(10001) called number (34999) tag(20002) called number
(34999) 
*Mar  1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaSetupPeer: dialpeer tags in 
rotary= 10001  20002
Note The next line shows that 5 digits were matched for this dial-peer and no prefix was added. The encapType (2) entry indicates a VoIP call.
*Mar  1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaSetupPeer: cid(44), 
destPat(34999), matched(5), prefix(), peer(637B0984), peer->encapType (2)
*Mar  1 15:35:53.612: //-1/xxxxxxxxxxxx/CCAPI/cc_can_gateway: Call legs: In=6, Out=1
Note The next line shows the voice gateway sending out a call-proceeding message to the incoming call leg with a progress indicator of 0x0.
*Mar  1 15:35:53.612: //44/xxxxxxxxxxxx/CCAPI/ccCallProceeding: (callID=0x2C, 
prog_ind=0x0) 
Note The next line shows the voice gateway sending out the call-setup request to the outgoing call leg. The dial peer is 10001 with the incoming CallEntry ID being 0x2C.
*Mar  1 15:35:53.612: //44/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: (Inbound call= 0x2C, 
outbound peer =10001, dest=,
        params=0x63085D80 mode=0, *callID=0x63086314, prog_ind = 0callingIE_present 1) 
*Mar  1 15:35:53.612: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:
*Mar  1 15:35:53.612: ccCallSetupRequest numbering_type 0x80 
*Mar  1 15:35:53.612: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:
*Mar  1 15:35:53.616: ccCallSetupRequest: calling number is:55555
*Mar  1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: calling oct3ais:0x0
*Mar  1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.616: ccCheckClipClir: calling number is: "55555", calling oct3a is: 0x0
*Mar  1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.616: Calling Party number is User Provided
*Mar  1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
*Mar  1 15:35:53.616: Leaving ccCheckClipClir
  calling number is: "55555"
  calling oct3 is:  0x80
  calling oct3a is: 0x0
*Mar  1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: after ccCheckClipClir - 
calling oct3a is:0x0
Note The next line shows that all digits are passed.
*Mar  1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: dest pattern 34999, 
called 34999, digit_strip 0 
*Mar  1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:
*Mar  1 15:35:53.616: callingNumber=55555, calledNumber=34999, redirectNumber= 
display_info= calling_oct3a=0
*Mar  1 15:35:53.616: accountNumber=, 
finalDestFlag=1,guid=45f2.aae2.1571.11cc.8044.95f5.fabb.6b0f
*Mar  1 15:35:53.616: peer_tag=10001
*Mar  1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:
*Mar  1 15:35:53.616: ccCallSetupRequest:
*Mar  1 15:35:53.616:  cisco-username=
*Mar  1 15:35:53.616: ----- ccCallInfo IE subfields -----
*Mar  1 15:35:53.616:  cisco-ani=55555
*Mar  1 15:35:53.616:  cisco-anitype=0
*Mar  1 15:35:53.616:  cisco-aniplan=0
*Mar  1 15:35:53.616:  cisco-anipi=0
*Mar  1 15:35:53.616:  cisco-anisi=0
*Mar  1 15:35:53.620:  dest=34999
*Mar  1 15:35:53.620:  cisco-desttype=0
*Mar  1 15:35:53.620:  cisco-destplan=0
*Mar  1 15:35:53.620:  cisco-rdn=
*Mar  1 15:35:53.620:  cisco-rdntype=-1
*Mar  1 15:35:53.620:  cisco-rdnplan=-1
*Mar  1 15:35:53.620:  cisco-rdnpi=-1
*Mar  1 15:35:53.620:  cisco-rdnsi=-1
*Mar  1 15:35:53.620:  cisco-redirectreason=-1
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: 
(vdbPtr=0x62EC61A4, dest=, callParams={called=34999,called_oct3=0x80, 
calling=55555,calling_oct3=0x80, calling_oct3a= 0x0, calling_xlated=false,  
subscriber_type_str=RegularLine, fdest=1, voice_peer_tag=10001},mode=0x0)
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
*Mar  1 15:35:53.620: ccIFCallSetupRequestPrivate: src route label  tgt route label 
tg_label_flag 0x0
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:  vdbPtr type = 
1
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: 
(vdbPtr=0x62EC61A4, dest=, callParams={called=34999, called_oct3 0x80,  calling=55555, 
calling_oct3 0x80, calling_oct3a 0x0, calling_xlated=false,  fdest=1, 
voice_peer_tag=10001}, mode=0x0, xltrc=-5)
*Mar  1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
Note In the next line, outgoing CallEntry ID 45 is bound to the same GUID 45F2AAE28044.
*Mar  1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: not incoming entry 
*Mar  1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: entry's incoming 
FALSE.
*Mar  1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: is_incomingis FALSE
*Mar  1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/ccSaveDialpeerTag: (callID=0x2C, 
dialpeer_tag=10001)
*Mar  1 15:35:53.624: //45/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0x2D, 
context=0x634A537C) 0x2D (decimal 45 is the second call leg ID).
*Mar  1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/ccCallReportDigits: (callID=0x2C,enable=0x0)
Note The next line shows that the voice gateway informs the incoming call leg that digits were forwarded.
*Mar  1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/cc_api_call_report_digits_done: 
(vdbPtr=0x637EC1E0, callID=0x2C, disp=0)
*Mar  1 15:35:53.624: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(54=CC_EV_CALL_REPORT_DIGITS_DONE), cid(44), disp(0)
*Mar  1 15:35:53.624: //44/45F2AAE28044/SS
Router#APP:10002:-1/ssaTraceSct: 
cid(44)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
*Mar  1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaTraceSct: 
-cid2(45)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)
*Mar  1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaDebugPeers: ssaReportDigitsDone 
cid(44) peer list: tag(20002) called number (34999)
*Mar  1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaReportDigitsDone: callid=44 
Reporting disabled.
*Mar  1 15:35:53.628: //-1/xxxxxxxxxxxx/CCAPI/cc_api_supported_data: data_mode=0x10082
*Mar  1 15:35:53.628: //45/xxxxxxxxxxxx/CCAPI/cc_api_get_ic_leg_obtained_numbers: 
callID=0x2D
Note The next two lines show the IP address of the terminating gateway and that the terminating gateway is reached through Ethernet port 0/0.
*Mar  1 15:35:53.628: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: remote IP is 
171.69.85.111 
*Mar  1 15:35:53.632: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: hwidb is Ethernet0/0 
*Mar  1 15:35:53.632: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: create entry in 
list: 1
*Mar  1 15:35:53.636: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetInstanceCount: For tagID[1] of 
callID[45]
*Mar  1 15:35:53.636: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No 
profileTable set for callID[45]
*Mar  1 15:35:53.636: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetInstanceCount: For tagID[2] of 
callID[45]
*Mar  1 15:35:53.636: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No 
profileTable set for callID[45]
Note The next line shows that the voice gateway received a call proceeding message from the terminating gateway, and then the following line shows that the voice gateway received a call alert from the terminating gateway.
*Mar  1 15:35:53.740: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_proceeding: (vdbPtr=0x62EC61A4, 
callID=0x2D,
      prog_ind=0x0) 
*Mar  1 15:35:53.740: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_alert: (vdbPtr=0x62EC61A4, 
callID=0x2D, prog_ind=0x0, sig_ind=0x1) 
*Mar  1 15:35:53.744: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(21=CC_EV_CALL_PROCEEDING), cid(45), disp(0)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
cid(45)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_PROCEEDING)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(0)fDest(0)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
-cid2(44)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaCallProc:
*Mar  1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaIgnore: cid(45), 
st(SSA_CS_CALL_SETTING),oldst(1), ev(21)
*Mar  1 15:35:53.744: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(7=CC_EV_CALL_ALERT), 
cid(45), disp(0)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
cid(45)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_ALERT)oldst(SSA_CS_CALL_SETTING)cfid(-1)csize
(0)in(0)fDest(0)
*Mar  1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
-cid2(44)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
*Mar  1 15:35:53.744: //44/45F2AAE28044/SSAPP:10002:-1/ssaAlert:
*Mar  1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)
Router#
Note The voice gateway forwarded a call alert to the originating gateway.
*Mar  1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccCallAlert: (callID=0x2C, prog_ind=0x0, 
sig_ind=0x1) 
Router#
Note The phone is answered at the called number.
Router#!call answered 
Router#
Note The voice gateway receives a connect message from the terminating gateway.
*Mar  1 15:36:05.016: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_connected: (vdbPtr=0x62EC61A4, 
callID=0x2D), prog_ind = 0 
*Mar  1 15:36:05.016: //45/45F2AAE28044/CCAPI/cc_api_call_connected: setting 
callEntry->connected to TRUE
Note The next line shows that the call accounting starts. The leg_type=False message means this is for an outgoing call. The line that follows shows that AAA accounting is not configured.
*Mar  1 15:36:05.016: //45/45F2AAE28044/CCAPI/cc_api_call_connected: calling accounting 
start for callID=45 leg_type=0 
*Mar  1 15:36:05.020: //45/xxxxxxxxxxxx/CCAPI/ccCallSetAAA_Accounting: callID=0x2D, 
accounting=0 
*Mar  1 15:36:05.020: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(8=CC_EV_CALL_CONNECTED), 
cid(45), disp(0)
*Mar  1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
cid(45)st(SSA_CS_ALERT_RCVD)ev(SSA_EV_CALL_CONNECTED)
oldst(SSA_CS_CALL_SETTING)cfid(-1)csize(0)in(0)fDest(0)
*Mar  1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
-cid2(44)st2(SSA_CS_ALERT_RCVD)oldst2(SSA_CS_CALL_SETTING)
*Mar  1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaConnect:
*Mar  1 15:36:05.020: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)
Note The next lines show a conference being set up between the two call legs 0x2C and 0x2D. Bridge complete messages are sent to both the terminating and originating gateways.
*Mar  1 15:36:05.020: //44/xxxxxxxxxxxx/CCAPI/ccConferenceCreate: (confID=0x63086424, 
callID1=0x2C, callID2=0x2D, tag=0x0) 
*Mar  1 15:36:05.020: //45/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done: 
(confID=0x15,srcIF=0x62EC61A4, srcCallID=0x2D, dstCallID=0x2C, disposition=0, tag=0x0)
*Mar  1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done: 
(confID=0x15,srcIF=0x637EC1E0, srcCallID=0x2C, dstCallID=0x2D, disposition=0, tag=0x0)
Note Here, the voice gateway sets up negotiating capability with the originating telephony leg.
*Mar  1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (dstVdbPtr=0x62EC61A4, 
dstCallId=0x2D, srcCallId=0x2C,
     caps={codec=0x2887F, fax_rate=0xBF, vad=0x3, modem=0x2
           codec_bytes=0, signal_type=3})
*Mar  1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (Playout: mode 0, initial 
60,min 40, max 300) 
*Mar  1 15:36:05.024: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(29=CC_EV_CONF_CREATE_DONE), cid(44), disp(0)
*Mar  1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: 
cid(44)st(SSA_CS_CONFERENCING)ev(SSA_EV_CONF_CREATE_DONE)
oldst(SSA_CS_CALL_SETTING)cfid(21)csize(2)in(1)fDest(1)
*Mar  1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: 
-cid2(45)st2(SSA_CS_CONFERENCING)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaConfCreateDone:
*Mar  1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/ccCallConnect: (callID=0x2C), prog_ind = 0
*Mar  1 15:36:05.024: //44/45F2AAE28044/CCAPI/ccCallConnect: setting callEntry->connected 
to TRUE
*Mar  1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaDebugPeers: ssaFlushPeerTagQueue 
cid(44) peer list: tag(20002) called number (34999)
*Mar  1 15:36:05.028: //-1/xxxxxxxxxxxx/CCAPI/cc_process_notify_bridge_done: 
(event=0x63067FC0)
Note The voice gateway sets up negotiating capability with the terminating VoIP leg.
*Mar  1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (dstVdbPtr=0x637EC1E0, 
dstCallId=0x2C, srcCallId=0x2D,
     caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0
           codec_bytes=20, signal_type=2})
*Mar  1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (Playout: mode 0, initial 
60,min 40, max 300) 
Note The capabilities are acknowledged for both call legs.
*Mar  1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ack: (dstVdbPtr=0x637EC1E0, 
dstCallId=0x2C, srcCallId=0x2D,
    caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0
           codec_bytes=20, signal_type=2, seq_num_start=2944})
*Mar  1 15:36:05.028: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ack: (dstVdbPtr=0x62EC
61A4, dstCallId=0x2D, srcCallId=0x2C,
     caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0
           codec_bytes=20, signal_type=2, seq_num_start=2944})
*Mar  1 15:36:05.032: //44/xxxxxxxxxxxx/CCAPI/cc_api_voice_mode_event: callID=0x2C
*Mar  1 15:36:05.032: //44/45F2AAE28044/CCAPI/cc_api_voice_mode_event: Call Pointer 
=634A430C
*Mar  1 15:36:05.032: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(52=CC_EV_VOICE_MODE_DONE), cid(44), disp(0)
*Mar  1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct:
Router#
Router#cid(44)st(SSA_CS_ACTIVE)ev(SSA_EV_VOICE_MODE_DONE)oldst(SSA_CS_CONFERENCING)cfid(21
)csize(2)in(1)fDest(1)
*Mar  1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: 
-cid2(45)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaIgnore: cid(44), 
st(SSA_CS_ACTIVE),oldst(5), ev(52)
Router#
Router#! digit punched
Router#
Note The phone at the terminating gateway enters digit 1.
*Mar  1 15:36:11.204: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPt
r=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,
    digit=1, digit_begin_flags=0x0, rtp_timestamp=0x0
    rtp_expiration=0x0, dest_mask=0x2)
*Mar  1 15:36:11.504: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: 
(dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,
    digit=1,duration=300,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x2), 
digit_tone_mode=0
Note The phone at the terminating gateway enters digit 2.
*Mar  1 15:36:11.604: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: 
(dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,
    digit=2, digit_begin_flags=0x0, rtp_timestamp=0x0
    rtp_expiration=0x0, dest_mask=0x2)
*Mar  1 15:36:11.904: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=
0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,
    digit=2,duration=300,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x2), 
digit_tone_mode=0
Router#
*Mar  1 15:36:14.476: //-1/xxxxxxxxxxxx/CCAPI/cc_handle_periodic_timer: Calling the 
callback, ccTimerctx - 0x628B6330
*Mar  1 15:36:14.476: //-1/xxxxxxxxxxxx/CCAPI/ccTimerStart: ccTimerctx - 0x628B6330
Router#
Router#!call hung up  The user at the terminating gateway hangs up the call.
Router#
Note The voice gateway receives a disconnect message from the terminating gateway. The cause code is 0x10 which is normal call clearing.
*Mar  1 15:36:22.916: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnected: (vdbPtr=
0x62EC61A4, callID=0x2D, cause=0x10)
*Mar  1 15:36:22.920: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(11=CC_EV_CALL_DISCONNECTED), cid(45), disp(0)
*Mar  1 15:36:22.920: //45/45F2AAE28044/SSAPP:0:21/ssaTraceSct: 
cid(45)st(SSA_CS_ACTIVE)ev(SSA_EV_CALL_DISCONNECTED)
oldst(SSA_CS_ALERT_RCVD)cfid(21)csize(2)in(0)fDest(0)
*Mar  1 15:36:22.920: //45/45F2AAE28044/SSAPP:0:21/ssaTraceSct: 
-cid2(44)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ACTIVE)
*Mar  1 15:36:22.920: ssa: Disconnected cid(45) state(5) cause(0x10)
Note The voice gateway begins tearing down the conference and dropping the bridge.
*Mar  1 15:36:22.920: //-1/xxxxxxxxxxxx/CCAPI/ccConferenceDestroy: (confID=0x15, tag=0x0) 
*Mar  1 15:36:22.920: //45/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done: (confID=0x15, 
srcIF=0x62EC61A4, srcCallID=0x2D, dstCallID=0x2C, disposition=0 tag=0x0)
*Mar  1 15:36:22.920: //44/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done: (confID=0x15, 
srcIF=0x637EC1E0, srcCallID=0x2C, dstCallID=0x2D, disposition=0 tag=0x0)
*Mar  1 15:36:22.924: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(30=CC_EV_CONF_DESTROY_DONE), cid(44), disp(0)
*Mar  1 15:36:22.924: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: 
cid(44)st(SSA_CS_CONF_DESTROYING)ev(SSA_EV_CONF_DESTROY_DONE)
oldst(SSA_CS_ACTIVE)cfid(21)csize(2)in(1)fDest(1)
*Mar  1 15:36:22.924: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: -cid2(45)st2
(SSA_CS_CONF_DESTROYING)oldst2(SSA_CS_ACTIVE)
*Mar  1 15:36:22.924: //45/45F2AAE28044/SSAPP:0:-1/ssaConfDestroyDone:
*Mar  1 15:36:22.924: //44/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: (callID=0x2C, cause=0x10 
tag=0x0)
Note The voice gateway stops call accounting on the incoming call, indicated by the leg_type=True message. The cause code is then set for the originating leg.
*Mar  1 15:36:22.924: //44/45F2AAE28044/CCAPI/ccCallDisconnect: calling accounting start 
for callID=44 leg_type=1 
*Mar  1 15:36:22.924: //44/45F2AAE28044/CCAPI/ccCallDisconnect: existing_cause = 0x0, 
new_cause = 0x10 
*Mar  1 15:36:22.924: //44/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2C)
*Mar  1 15:36:22.924: //45/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: (callID=0x2D, cause=0x10 
tag=0x0)
Note The voice gateway stops call accounting for the outgoing call, indicated by the leg_type=False message. The cause code is verified for the terminating leg.
*Mar  1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: calling accounting start 
for callID=45 leg_type=0
*Mar  1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: existing_cause = 0x10, 
new_cause = 0x10 
*Mar  1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: using the existing_cause 
0x10
*Mar  1 15:36:22.928: //45/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2D)
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_api_icpif: expect factor = 0
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/g113_calculate_impairment: (delay=79,
      loss=0), Io=0 Iq=0 Idte=0 Idd=0 Ie=10 Itot=10
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: the remote IP is 
171.69.85.111
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: hwidb is Ethernet0/0
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: reduce callnum of 
entry: 0, voip: 0, mmoip: 0
*Mar  1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: remove anentry
*Mar  1 15:36:22.932: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect_done: 
(vdbPtr=0x62EC61A4, callID=0x2D, disp=0, tag=0x0)
*Mar  1 15:36:22.932: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No 
profileTable set for callID[45]
*Mar  1 15:36:22.936: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByRef: No tdObjectfound in 
profileTable for tagID[6] of callID[45]
*Mar  1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: not incoming entry
*Mar  1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: entry's incoming 
FALSE.
*Mar  1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: is_incomingis FALSE
*Mar  1 15:36:22.940: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(12=CC_EV_CALL_DISCONNECT_DONE), cid(45), disp(0)
*Mar  1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: cid(45)st(SSA_CS
_DISCONNECTING)ev(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_ACTIVE)cfid(-1)csize(2)in(0)fDe
st(0)
*Mar  1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: 
-cid2(44)st2(SSA_CS_DISCONNECTING)oldst2(SSA_CS_CONF_DESTROYING)
*Mar  1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaDisconnectDone:
*Mar  1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaAAA_CheckAccounting: accounting 
generation enabled
*Mar  1 15:36:22.940: //45/xxxxxxxxxxxx/CCAPI/ccCallSetAAA_Accounting: callID=0x2D, 
accounting=0
*Mar  1 15:36:22.944: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: not the VoIP or 
MMoIP
*Mar  1 15:36:22.948: //44/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect_done: 
(vdbPtr=0x637EC1E0, callID=0x2C, disp=0, tag=0x0)
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: 
ccFreeRawMsgInfo(0x6307595C)
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: Decrement call volume 
counter 1
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: current call volume: 0
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: entry's incoming TRUE.
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: is_incomingis TRUE
*Mar  1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: Deleting 
profileTable[0x6380E11C]
*Mar  1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDHashProfileTab: Destructor 
Profile Table (0x6380E11C)
*Mar  1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructInstanceTDObject: 
tdObject[0x63401148] tagID[5]
*Mar  1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructInstanceTDObject: 
tdObject[0x638BC1AC] tagID[6]
*Mar  1 15:36:22.956: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: 
ev(12=CC_EV_CALL_DISCONNECT_DONE), cid(44), disp(0)
*Mar  1 15:36:22.956: //44/45F2AAE28044/SSAPP:10002:-1/ssaTraceSct: 
cid(44)st(SSA_CS_DISCONNECTING)ev(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_CONF_DESTROYING
)cfid(-1)csize(1)in(1)fDest(1)
Router#
*Mar  1 15:36:22.956: //44/45F2AAE28044/SSAPP:10002:-1/ssaDisconnectDone:
Additional References

For additional information related to enhanced debugging for Cisco voice gateways, refer to the following references:

Related Documents

Related Topic

Document Title

Debug commands: complete command syntax, defaults, usage guidelines, and examples

Cisco IOS Debug Command Reference, Release 12.2 T

Cisco IOS voice configuration

Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2

Cisco IOS voice command reference

Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2 T

Platform-specific information

Use the appropriate documenation for your platform:

•Cisco 2600 Series product documentation

•Cisco 3600 Series product documentation

•Cisco AS5300 product documentation

•Cisco AS5350 product documentation

•Cisco AS5400 product documentation

•Cisco AS5800 product documentation

•Cisco AS5850 product documentation

•Cisco MC3810 product documentation

MIBs

MIBs¹

MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

¹Not all supported MIBs are listed.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://tools.cisco.com/ITDIT/MIBS/servlet/index

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

http://www.cisco.com/register

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, tools, and lots more. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/public/support/tac/home.shtml

Command Reference

This section documents modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2T command reference publications.

Modified Commands

•debug rtsp all

•debug rtsp api

•debug rtsp client

•debug rtsp error

•debug rtsp pmh

•debug rtsp session

•debug rtsp socket

•debug voip ccapi error

•debug voip ccapi inout

•debug voip ivr all

•debug voip ivr applib

•

Hierarchical Navigation

Cisco IOS Software Releases 12.2 T

Enhanced Debug Capabilities for Cisco Voice Gateways

Downloads

Table Of Contents

Enhanced Debug Capabilities for Cisco Voice Gateways

Contents

Information About Enhanced Debug Capabilities for Cisco Voice Gateways

Debug Header Format

IVR Module Dependent List

CallEntry ID and GUID Call Legs

How to Manage the Voice Call Debug Output

SUMMARY STEPS

DETAILED STEPS

Sample Output Examples for the Enhanced Debug Commands

Full GUID Header Example

Short Header Example

Setup and Teardown Example

Additional References

Related Documents

MIBs

Technical Assistance

Command Reference