Voice over IP for the Cisco AS5800 Debug Commands

Note This section documents VoIP debug commands. All other commands used with this feature are documented in the Cisco IOS Release 11.3 Debug Command Reference.

debug voip aaa

To enable or disable debugging messages for the gateway aaa to be output to the system console, use the debug voip aaa privileged EXEC command.

debug voip aaa
no debug voip aaa

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

debug voip ccapi error

To trace error logs in the call control API, use the debug voip ccapi error privileged EXEC command. Use the no form of this command to disable debugging output.

[no] debug voip ccapi error

Command Mode

Privileged EXEC

Usage Guidelines

The debug voip ccapi error EXEC command traces the error logs in the call control API. Error logs are generated during normal call processing, when there are insufficient resources, or when there are problems in the underlying network-specific code, the higher call session application, or the call control API itself.

This debug command shows error events or unexpected behavior in system software. In most cases, no events will be generated.

debug voip ccapi inout

To trace the execution path through the call control API, use the debug voip ccapi inout privileged EXEC command

debug voip ccapi inout
[no] debug voip ccapi inout

Command Mode

Privileged EXEC

Usage Guidelines

The debug voip ccapi inout EXEC 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. You can use the output from this command to understand how calls are being handled by the router.

This command shows how a call flows through the system. Using this debug level, you can see the call setup and teardown operations performed on both the telephony and network call legs.

Example

Example 6-1 shows the call setup indicated and accepted by the router:

Example 6-1: Sample Debug VoIP ccapi Inout Output

5800# debug voip ccapi inout
cc_api_call_setup_ind (vdbPtr=0x60BFB530, callInfo={called=, calling=, fdest=0}, callID=0x60BFAEB8)
cc_process_call_setup_ind (event=0x60B68478)
sess_appl: ev(14), cid(1), disp(0)
ccCallSetContext (callID=0x1, context=0x60A7B094)
ccCallSetPeer (callID=0x1, peer=0x60C0A868, voice_peer_tag=2, encapType=1, dest-pat=+14085231001, answer=)
ccCallSetupAck (callID=0x1)

Example 6-2 shows the caller entering DTMF digits until a dial-peer is matched:

Example 6-2: Sample Debug VoIP ccapi Inout Output

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=4, mode=0)
sess_appl: ev(8), cid(1), disp(0)
ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=1, mode=0)
sess_appl: ev(8), cid(1), disp(0)
ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=0, mode=0)
sess_appl: ev(8), cid(1), disp(0)
ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=0, mode=0)
sess_appl: ev(8), cid(1), disp(0)
ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=1, mode=0)
sess_appl: ev(8), cid(1), disp(0)
ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
ccCallProceeding (callID=0x1, prog_ind=0x0)
ssaSetupPeer cid(1), destPat(+14085241001), matched(8), prefix(), peer(60C0E710)

Example 6-3 shows the call setup over the IP network to the remote router:

Example 6-3: Sample Debug VoIP ccapi Inout Output

ccCallSetupRequest (peer=0x60C0E710, dest=, params=0x60A7B0A8 mode=0, *callID=0x60B6C110)
ccIFCallSetupRequest: (vdbPtr=0x60B6C5D4, dest=, callParams={called=+14085241001, calling=+14085231001, fdest=0, voice_peer_tag=104}, mode=0x0)
ccCallSetContext (callID=0x2, context=0x60A7B2A8)

Example 6-4 shows the called party is alerted, a CODEC is negotiated, and voice path is cut through:

Example 6-4: Sample Debug VoIP ccapi Inout Output

cc_api_call_alert(vdbPtr=0x60B6C5D4, callID=0x2, prog_ind=0x8, sig_ind=0x1)
sess_appl: ev(6), cid(2), disp(0)
ssa: cid(2)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)-cid2(1)st2(1)oldst2(0)
ccCallAlert (callID=0x1, prog_ind=0x8, sig_ind=0x1)
ccConferenceCreate (confID=0x60B6C150, callID1=0x1, callID2=0x2, tag=0x0)
cc_api_bridge_done (confID=0x1, srcIF=0x60B6C5D4, srcCallID=0x2, dstCallID=0x1, disposition=0, tag=0x0)
cc_api_bridge_done (confID=0x1, srcIF=0x60BFB530, srcCallID=0x1, dstCallID=0x2, disposition=0, tag=0x0)
cc_api_caps_ind (dstVdbPtr=0x60B6C5D4, dstCallId=0x2,srcCallId=0x1, caps={codec=0x7, fax_rate=0x7F, vad=0x3})
cc_api_caps_ind (dstVdbPtr=0x60BFB530, dstCallId=0x1,srcCallId=0x2, caps={codec=0x4, fax_rate=0x2, vad=0x2})
cc_api_caps_ack (dstVdbPtr=0x60BFB530, dstCallId=0x1,srcCallId=0x2, caps={codec=0x4, fax_rate=0x2, vad=0x2})
cc_api_caps_ack (dstVdbPtr=0x60B6C5D4, dstCallId=0x2,srcCallId=0x1, caps={codec=0x4, fax_rate=0x2, vad=0x2})
sess_appl: ev(17), cid(1), disp(0)
ssa: cid(1)st(3)oldst(0)cfid(1)csize(0)in(1)fDest(0)-cid2(2)st2(3)oldst2(1)

Example 6-5 shows that the call is connected and voice is active:

Example 6-5: Sample Debug VoIP ccapi Inout Output

cc_api_call_connected(vdbPtr=0x60B6C5D4, callID=0x2)
sess_appl: ev(7), cid(2), disp(0)
ssa: cid(2)st(4)oldst(1)cfid(1)csize(0)in(0)fDest(0)-cid2(1)st2(4)oldst2(3)
ccCallConnect (callID=0x1)

Example 6-6 shows how the system processes voice statistics and monitors voice quality during the call:

Example 6-6: Sample Debug VoIP ccapi Inout Output

ccapi_request_rt_packet_stats (requestorIF=0x60B6C5D4, requestorCID=0x2,
      requestedCID=0x1, tag=0x60A7C598)
cc_api_request_rt_packet_stats_done (requestedIF=0x60BFB530, requestedCID=0x1,
      tag=0x60A7A4C4)
ccapi_request_rt_packet_stats (requestorIF=0x60B6C5D4, requestorCID=0x2,
      requestedCID=0x1, tag=0x60A7C598)
cc_api_request_rt_packet_stats_done (requestedIF=0x60BFB530, requestedCID=0x1,
      tag=0x60C1FE54)
ccapi_request_rt_packet_stats (requestorIF=0x60B6C5D4, requestorCID=0x2,
      requestedCID=0x1, tag=0x60A7C598)
cc_api_request_rt_packet_stats_done (requestedIF=0x60BFB530, requestedCID=0x1,
      tag=0x60A7A5F4)
ccapi_request_rt_packet_stats (requestorIF=0x60B6C5D4, requestorCID=0x2,
      requestedCID=0x1, tag=0x60A7C598)
cc_api_request_rt_packet_stats_done (requestedIF=0x60BFB530, requestedCID=0x1,
      tag=0x60A7A6D8)
ccapi_request_rt_packet_stats (requestorIF=0x60B6C5D4, requestorCID=0x2,
      requestedCID=0x1, tag=0x60A7C598)
cc_api_request_rt_packet_stats_done (requestedIF=0x60BFB530, requestedCID=0x1,
      tag=0x60A7ACBC)

Example 6-7 shows that disconnection is indicated from the calling party, call legs are torn down and disconnected:

Example 6-7: Sample Debug VoIP ccapi Inout Output

cc_api_call_disconnected(vdbPtr=0x60BFB530, callID=0x1, cause=0x10)
sess_appl: ev(9), cid(1), disp(0)
ssa: cid(1)st(5)oldst(3)cfid(1)csize(0)in(1)fDest(0)-cid2(2)st2(5)oldst2(4)
ccConferenceDestroy (confID=0x1, tag=0x0)
cc_api_bridge_done (confID=0x1, srcIF=0x60B6C5D4, srcCallID=0x2, dstCallID=0x1, disposition=0 tag=0x0)
cc_api_bridge_done (confID=0x1, srcIF=0x60BFB530, srcCallID=0x1, dstCallID=0x2, disposition=0 tag=0x0)
sess_appl: ev(18), cid(1), disp(0)
ssa: cid(1)st(6)oldst(5)cfid(-1)csize(0)in(1)fDest(0)-cid2(2)st2(6)oldst2(4)
ccCallDisconnect (callID=0x1, cause=0x10 tag=0x0)
ccCallDisconnect (callID=0x2, cause=0x10 tag=0x0)
cc_api_call_disconnect_done(vdbPtr=0x60B6C5D4, callID=0x2, disp=0, tag=0x0)
sess_appl: ev(10), cid(2), disp(0)
ssa: cid(2)st(7)oldst(4)cfid(-1)csize(0)in(0)fDest(0)-cid2(1)st2(7)oldst2(6)
cc_api_call_disconnect_done(vdbPtr=0x60BFB530, callID=0x1, disp=0, tag=0x0)
sess_appl: ev(10), cid(1), disp(0)
ssa: cid(1)st(7)oldst(6)cfid(-1)csize(1)in(1)fDest(0)

debug voip ivr

To debug the IVR application, use the debug voip ivr privileged EXEC command. IVR debug messages will be displayed when a call is being actively handled by the IVR scripts. Error output should only occur if something is not working or an error condition has been raised. States output supplies information about the current status of the IVR script and the different events which are occurring in that state.

debug voip ivr [states | error | all]
no debug voip ivr [states | error | all]

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

There are two types of messages:

Error---These messages should only be displayed if an error occurred.
States---These debug messages will display a lot of information about how IVR is handling each call.

debug vtsp all

To show debugging information for all of the debug vtsp commands, use the debug vtsp all EXEC command. Use the no form of this command to disable debugging output.

debug vtsp all
[no] debug vtsp all

Command Mode

Privileged EXEC

Usage Guidelines

The debug vtsp all command enables the following debug vtsp commands: debug vtsp session, debug vtsp error, and debug vtsp dsp. For more information or sample output, refer to the individual commands in this chapter.

debug vtsp dsp

To show messages from the DSP on the VFC to the access server, use the debug vtsp dsp privileged EXEC command

debug vtsp dsp
[no] debug vtsp dsp

Command Mode

Privileged EXEC

Usage Guidelines

The debug vtsp dsp command shows messages from the DSP on the VFC to the router; this command can be useful if you suspect that the VFC is not functional. It is a simple way to check of the VFC is responding to off-hook indications.

Sample Display

Example 6-8 shows the collection of DTMF digits from the DSP.

Example 6-8: Sample Debug Vtsp Dsp Output

*Nov 30 00:44:34.491: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=3
*Nov 30 00:44:36.267: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=1
*Nov 30 00:44:36.571: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
*Nov 30 00:44:36.711: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
*Nov 30 00:44:37.147: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=2

debug vtsp signal

To trace how the router interacts with the DSP based on signaling indications from the signaling stack and requests from the application, use the debug vtsp signal privileged EXEC command. Use the no form of this command to disable debugging output.

debug vtsp signal
[no] debug vtsp signal

Usage Guidelines

The debug vtsp signal command traces how the router interacts with the DSP based on the signaling indications from the signaling stack and requests from the application. This debug command displays information about how each network indication and application request is handled, signaling indications, and DSP control messages.

This debug level shows the internal workings of the voice telephony call state machine.

Sample Display

Example 6-9 shows that the call has been accepted and that the system is now checking for incoming dial-peer matches.

Example 6-9: Sample Debug Vtsp Signal Output

Accept call and check for incoming dial-peer match:

*Nov 30 00:46:19.535: vtsp_tsp_call_accept_check (sdb=0x60CD4C58,
calling_number=408 called_number=1): peer_tag=0
*Nov 30 00:46:19.535: vtsp_tsp_call_setup_ind (sdb=0x60CD4C58,
tdm_info=0x60B80044, tsp_info=0x60B09EB0, calling_number=408 called_number=1):
peer_tag=1

Example 6-10 shows that a DSP has been allocated to handle the call and indicated the call to the higher layer code.

Example 6-10: Sample Debug Vtsp Signal Output

*Nov 30 00:46:19.535: vtsp_do_call_setup_ind:
*Nov 30 00:46:19.535: dsp_open_voice_channel: [0:D:12] packet_len=12
channel_id=8737 packet_id=74 alaw_ulaw_select=0 transport_protocol=2
*Nov 30 00:46:19.535: dsp_set_playout_delay: [0:D:12] packet_len=18
channel_id=8737 packet_id=76 mode=1 initial=60 min=4 max=200 fax_nom=300 
*Nov 30 00:46:19.535: dsp_echo_canceller_control: [0:D:12] packet_len=10
channel_id=8737 packet_id=66 flags=0x0
*Nov 30 00:46:19.539: dsp_set_gains: [0:D:12] packet_len=12 channel_id=8737
packet_id=91 in_gain=0 out_gain=0
*Nov 30 00:46:19.539: dsp_vad_enable: [0:D:12] packet_len=10 channel_id=8737
packet_id=78 thresh=-38
*Nov 30 00:46:19.559: vtsp_process_event: [0:D:12, 0.3, 13] act_setup_ind_ack

Example 6-11 shows that the higher layer code has accepted the call, placed the DSP in DTMF mode, and collected digits.

Example 6-11: Sample Debug Vtsp Signal Output

*Nov 30 00:46:19.559: dsp_voice_mode: [0:D:12] packet_len=20 channel_id=8737
packet_id=73 coding_type=1 voice_field_size=160 VAD_flag=0 echo_length=64
comfort_noise=1 fax_detect=1
*Nov 30 00:46:19.559: dsp_dtmf_mode: [0:D:12] packet_len=10 channel_id=8737
packet_id=65 dtmf_or_mf=0
*Nov 30 00:46:19.559: dsp_cp_tone_on: [0:D:12] packet_len=30 channel_id=8737
packet_id=72 tone_id=3 n_freq=2 freq_of_first=350 freq_of_second=440
amp_of_first=4000 amp_of_second=4000 direction=1 on_time_first=65535
off_time_first=0 on_time_second=65535 off_time_second=0
*Nov 30 00:46:19.559: vtsp_timer: 278792
*Nov 30 00:46:22.059: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.059: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.059: vtsp_timer: 279042
*Nov 30 00:46:22.363: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.363: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.363: vtsp_timer: 279072
*Nov 30 00:46:22.639: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.639: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.639: vtsp_timer: 279100
*Nov 30 00:46:22.843: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.843: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.843: vtsp_timer: 279120
*Nov 30 00:46:23.663: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:23.663: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.663: vtsp_timer: 279202

Example 6-12 shows that the call proceeded and that DTMF was disabled.

Example 6-12: Sample Debug Vtsp Signal Output

*Nov 30 00:46:23.663: vtsp_process_event: [0:D:12, 0.4, 15] act_dcollect_proc 
*Nov 30 00:46:23.663: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.663: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68

Example 6-13 shows that the telephony call leg was conferenced with the packet network call leg and performed capabilities exchange with the network-side call leg.

Example 6-13: Sample Debug Vtsp Signal Output

*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 17] act_bridge 
*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 22] act_caps_ind 
*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 23] act_caps_ack 
Go into voice mode with codec indicated in caps exchange.
*Nov 30 00:46:23.699: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.699: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:23.699: dsp_voice_mode: [0:D:12] packet_len=20 channel_id=8737
packet_id=73 coding_type=6 voice_field_size=20 VAD_flag=1 echo_length=64
comfort_noise=1 fax_detect=1

Example 6-14 shows the call connected at remote side.

Example 6-14: Sample Debug Vtsp Signal Output

*Nov 30 00:46:23.779: vtsp_process_event: [0:D:12, 0.5, 10] act_connect

Example 6-15 shows that disconnect was indicated, and passed to upper layers.

Example 6-15: Sample Debug Vtsp Signal Output

*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 5] act_generate_disc

Example 6-16 shows that the conference was torn down and disconnect handshake completed.

Example 6-16: Sample Debug Vtsp Signal Output

*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 18] act_bdrop 
*Nov 30 00:46:30.267: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 20] act_disconnect 
*Nov 30 00:46:30.267: dsp_get_error_stat: [0:D:12] packet_len=10 channel_id=0
packet_id=6 reset_flag=1
*Nov 30 00:46:30.267: vtsp_timer: 279862

Example 6-17 shows that the final DSP statistics were retrieved.

Example 6-17: Sample Debug Vtsp Signal Output

*Nov 30 00:46:30.275: vtsp_process_event: [0:D:12, 0.17, 30] act_get_error 
*Nov 30 00:46:30.275: 0:D:12: rx_dropped=0 tx_dropped=0 rx_control=353
tx_control=338 tx_control_dropped=0 dsp_mode_channel_1=2 dsp_mode_channel_2=0
c[0]=71 c[1]=71 c[2]=71 c[3]=71 c[4]=68 c[5]=71 c[6]=68 c[7]=73 c[8]=83 c[9]=84
c[10]=87 c[11]=83 c[12]=84 c[13]=87 c[14]=71 c[15]=6
*Nov 30 00:46:30.275: dsp_get_levels: [0:D:12] packet_len=8 channel_id=8737
packet_id=89
*Nov 30 00:46:30.279: vtsp_process_event: [0:D:12, 0.17, 34] act_get_levels 
*Nov 30 00:46:30.279: dsp_get_tx_stats: [0:D:12] packet_len=10 channel_id=8737
packet_id=86 reset_flag=1
*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.17, 31] act_stats_complete 
*Nov 30 00:46:30.287: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.287: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:30.287: vtsp_timer: 279864

Example 6-18 shows that the DSP channel was closed and released.

Example 6-18: Sample Debug Vtsp Signal Output

*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.18, 6] act_wrelease_release 
*Nov 30 00:46:30.287: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.287: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:30.287: dsp_close_voice_channel: [0:D:12] packet_len=8
channel_id=8737 packet_id=75
*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.16, 42] act_terminate

debug cch323 h225

The debug cch323 h225 command provides the trace of the state transition of the H.225 state machine based on the processed events. The no form of this command disables debugging output.

debug cch323 h225

no debug cch323 h225

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

State Descriptions

The state definitions of the different states of the H.225 state machine are as follows:

H225_IDLE---This is the initial state of the H.225 state machine. The H.225 state machine is in this state before issuing a call setup request (for the outbound IP call case) or ready to receive an incoming IP call.
H225_SETUP---This is the call setup state. The state machine transitions to this state after sending out a call setup request, or after the reception of an incoming call indication.
H225_ALERT---This is the call alerting state. The state machine transitions to this state after sending the alerting message or after the reception of an alerting message from the peer.
H225_CALLPROC---This is the call proceeding state.
H225_ACTIVE---This is the Call connected state. In this state, the call is active. The state machine transitions to this state after sending the connect message to the peer or after the reception of the connect message from the peer.
H225_WAIT_FOR_ARQ---This is the state where the H.225 state machine is waiting for the completion of the ARQ process from the RAS state machine.
H225_WAIT_FOR_DRQ---This is the state where the H.225 state machine is waiting for the completion of the DRQ process from the RAS state machine.
H225_WAIT_FOR_H245---This is the state where the H.225 state machine is waiting for the success or failure from the H.245 state machine.

Events Description

The event definitions of the different events of the H.225 state machine are as follows:

H225_EVENT_NONE--- No event.
H225_EVENT_ALERT---This event indicates the H.225 state machine to send an alerting message to the peer.
H225_EVENT_ALERT_IND---This event indicates the H.225 state machine that an alerting message is received from the peer.
H225_EVENT_CALLPROC---This event indicates the H.225 state machine to send a call proceeding message to the peer
H225_EVENT_CALLPROC_IND---This event indicates the H.225 state machine that a call proceeding message is received from the peer.
H225_EVENT_REJECT---This event indicates the H.225 state machine to reject the call setup request from the peer.
H225_EVENT_REJECT_IND---This event indicates the H.225 state machine that a call setup request to the peer is rejected.
H225_EVENT_RELEASE---This event indicates the H.225 state machine to send a release complete message to the peer.
H225_EVENT_RELEASE_IND---This event indicates the H.225 state machine that a release complete message is received from the peer.
H225_EVENT_SETUP---This event indicates the H.225 state machine to send a setup message to the peer.
H225_EVENT_SETUP_IND---This event indicates the H.225 state machine that a setup message is received from the peer.
H225_EVENT_SETUP_CFM---This event indicates the H.225 state machine to send a connect message to the peer.
H225_EVENT_SETUP_CFM_IND---This event indicates the H.225 state machine that a connect message from the peer.
H225_EVENT_RAS_SUCCESS---This event indicates the H.225 state machine that the pending RAS operation is successful.
H225_EVENT_RAS_FAILED---This event indicates the H.225 state machine that the pending RAS operation failed.
H225_EVENT_H245_SUCCESS---This event indicates the H.225 state machine that the pending H.245 operation is successful.
H225_EVENT_H245_FAILED---This event indicates the H.225 state machine that the pending H.245 operation failed.

Example

20:59:17:Set new event H225_EVENT_SETUP
20:59:17:H225 FSM:received event H225_EVENT_SETUP while at state H225_IDLE
20:59:17:Changing from H225_IDLE state to H225_SETUP state
20:59:17:cch323_h225_receiver:received msg of type SETUPCFM_CHOSEN
20:59:17:H225 FSM:received event H225_EVENT_SETUP_CFM_IND while at state 
H225_SETUP
20:59:17:Changing from H225_SETUP state to H225_ACTIVE state
20:59:17:Set new event H225_EVENT_H245_SUCCESS
20:59:17:H225 FSM:received event H225_EVENT_H245_SUCCESS while at state 
H225_ACTIVE
20:59:20:Set new event H225_EVENT_RELEASE
20:59:20:H225 FSM:received event H225_EVENT_RELEASE while at state 
H225_ACTIVE
20:59:20:Changing from H225_ACTIVE state to H225_WAIT_FOR_DRQ state
20:59:20:Set new event H225_EVENT_RAS_SUCCESS
20:59:20:H225 FSM:received event H225_EVENT_RAS_SUCCESS while at state 
H225_WAIT_FOR_DRQ
20:59:20:Changing from H225_WAIT_FOR_DRQ state to H225_IDLE state

debug cch323 h245

The debug cch323 h245 command provides the trace of the state transition of the H.245 state machine based on the processed events. The no form of this command disables debugging output.

debug cch323 h245

no debug cch323 h245

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

The H.245 state machines include the following three state machines:

Master Slave Determination state machine
Capability Exchange state machine
Open Logical Channel state machine

State Definitions

The definitions are listed:

H245_MS_NONE---This is the initial state of the master slave determination state machine.
H245_MS_WAIT---In this state, a Master Slave Determination message is sent, waiting for the reply.
H245_MS_DONE--- The result is in.
H245_CAP_NONE---This is the initial state of the capabilities exchange state machine.
H245_CAP_WAIT---In this state, a cap exchange message is sent, waiting for reply.
H245_CAP_DONE---The result is in.
H245_OLC_NONE---This is the initial state of the open logical channel state machine.
H245_OLC_WAIT---OLC message sent, waiting for reply.
H245_OLC_DONE---OLC done.

Event definitions

H245_EVENT_MSD---Send MSD message
H245_EVENT_MS_CFM---Send MSD acknowledge message
H245_EVENT_MS_REJ---Send MSD reject message
H245_EVENT_MS_IND--- Received MSD message
H245_EVENT_CAP---Send CAP message
H245_EVENT_CAP_CFM---Send CAP acknowledge message
H245_EVENT_CAP_REJ---Send CAP reject
H245_EVENT_CAP_IND---Received CAP message
H245_EVENT_OLC---Send OLC message
H245_EVENT_OLC_CFM---Send OLC acknowledge message
H245_EVENT_OLC_REJ---Send OLC reject message
H245_EVENT_OLC_IND---Received OLC message

Example

20:58:23:Changing to new event H245_EVENT_MSD
20:58:23:H245 MS FSM:received event H245_EVENT_MSD while at state 
H245_MS_NONE
20:58:23:changing from H245_MS_NONE state to H245_MS_WAIT state
20:58:23:Changing to new event H245_EVENT_CAP
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP while at state 
H245_CAP_NONE
20:58:23:changing from H245_CAP_NONE state to H245_CAP_WAIT state
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_MS_DETERMINE_INDICATION
20:58:23:Changing to new event H245_EVENT_MS_IND
20:58:23:H245 MS FSM:received event H245_EVENT_MS_IND while at state 
H245_MS_WAIT
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_CAP_TRANSFER_INDICATION
20:58:23:Changing to new event H245_EVENT_CAP_IND
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_IND while at state 
H245_CAP_WAIT
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_MS_DETERMINE_CONFIRM
20:58:23:Changing to new event H245_EVENT_MS_CFM
20:58:23:H245 MS FSM:received event H245_EVENT_MS_CFM while at state 
H245_MS_WAIT
20:58:23:changing from H245_MS_WAIT state to H245_MS_DONE state
0:58:23:cch323_h245_receiver:received msg of type M_H245_CAP_TRANSFER_CONFIRM
20:58:23:Changing to new event H245_EVENT_CAP_CFM
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_CFM while at state 
H245_CAP_WAIT
20:58:23:changing from H245_CAP_WAIT state to H245_CAP_DONE state
20:58:23:Changing to new event H245_EVENT_OLC
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC while at state
H245_OLC_NONE
20:58:23:changing from H245_OLC_NONE state to H245_OLC_WAIT state
20:58:23:cch323_h245_receiver:received msg of type 
M_H245_UCHAN_ESTABLISH_INDICATION
20:58:23:Changing to new event H245_EVENT_OLC_IND
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_IND while at state 
H245_OLC_WAIT
20:58:23:cch323_h245_receiver:received msg of type M_H245_UCHAN_ESTAB_ACK
20:58:23:Changing to new event H245_EVENT_OLC_CFM
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_CFM while at state 
H245_OLC_WAIT
20:58:23:changing from H245_OLC_WAIT state to H245_OLC_DONE state

debug cch323 ras

The debug cch323 ras command provides the trace of the state transition of the RAS state machine based on the processed events.The no form of this command disables debugging output.

debug cch323 ras

no debug cch323 ras

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

RAS operates in two state machines. One global state machine controls the overall RAS operation of the Gateway. The other state machine is a per call state machine that controls the active calls.

State Definitions

The state definitions of the different states of the RAS state machine follow:

CCH323_RAS_STATE_NONE---This is the initial state of the RAS state machine.
CCH323_RAS_STATE_GRQ---The state machine is in the GRQ state. In this state, the gateway is in the process of discovering a gatekeeper.
CCH323_RAS_STATE_RRQ---The state machine is in the RRQ state. In this state, the gateway is in the process of registering with a gatekeeper.
CCH323_RAS_STATE_IDLE---The global state machine is in the idle state.
CCH323_RAS_STATE_URQ---The state machine is in the URQ state. In this state, the gateway is in the process of unregistering with a gatekeeper.
CCH323_RAS_STATE_ARQ---The per call state machine is in the process of admitting a new call.
CCH323_RAS_STATE_ACTIVE---The per call state machine is in the call active state.
CCH323_RAS_STATE_DRQ---The per call state machine is in the process of disengaging an active call.

Event Definitions

These are the event definitions of the different states of the RAS state machine:

CCH323_RAS_EVENT_NONE---Nothing
CCH323_RAS_EVENT_GWUP---Gateway is coming up
CCH323_RAS_EVENT_GWDWN---Gateway is going down
CCH323_RAS_EVENT_NEWCALL:---New call
CCH323_RAS_EVENT_CALLDISC---Call disconnect
CCH323_RAS_EVENT_GCF---Received GCF
CCH323_RAS_EVENT_GRJ---Received GRJ
CCH323_RAS_EVENT_ACF---Received ACF
CCH323_RAS_EVENT_ARJ---Received ARJ
CCH323_RAS_EVENT_SEND_RRQ---Send RRQ
CCH323_RAS_EVENT_RCF---Received RCF
CCH323_RAS_EVENT_RRJ---Received RRJ
CCH323_RAS_EVENT_SEND_URQ---Send URQ
CCH323_RAS_EVENT_URQ---Received URQ
CCH323_RAS_EVENT_UCF---Received UCF
CCH323_RAS_EVENT_SEND_UCF---Send UCF
CCH323_RAS_EVENT_URJ---Received URJ
CCH323_RAS_EVENT_BCF---Received BCF
CCH323_RAS_EVENT_BRJ---Received BRJ
CCH323_RAS_EVENT_DRQ---Received DRQ
CCH323_RAS_EVENT_DCF---Received DCF
CCH323_RAS_EVENT_SEND_DCF---Send DCF
CCH323_RAS_EVENT_DRJ---Received DRJ
CCH323_RAS_EVENT_IRQ---Received IRQ
CCH323_RAS_EVENT_IRR---Send IRR
CCH323_RAS_EVENT_TIMEOUT---Message timeout

Example

20:58:49:Changing to new event CCH323_RAS_EVENT_SEND_RRQ
cch323_run_ras_sm:received event CCH323_RAS_EVENT_SEND_RRQ while at CCH323_RAS_STATE_IDLE state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_RRQ state
cch323_ras_receiver:received msg of type RCF_CHOSEN
cch323_run_ras_sm:received event CCH323_RAS_EVENT_RCF while at CCH323_RAS_STATE_RRQ state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_NEWCALL while at CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_ARQ
cch323_ras_receiver:received msg of type ACF_CHOSEN
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_ACF while at 
CCH323_RAS_STATE_ARQ state
20:58:59:cch323_percall_ras_sm:changing to new state 
CCH323_RAS_STATE_ACTIVE
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_CALLDISC while
at CCH323_RAS_STATE_ACTIVE state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_DRQ
cch323_ras_receiver:received msg of type DCF_CHOSEN
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_DCF while at
CCH323_RAS_STATE_DRQ state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_IDLE
20:59:04:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_IRR while at 
CCH323_RAS_STATE_ACTIVE state
20:59:04:cch323_percall_ras_sm:changing to new state 
CCH323_RAS_STATE_ACTIVE

debug csm voice

The show csm command is used to display the Call Switching Module (CSM) call status information.

show csm voice {(shelf/slot/port) | CR}

show csm modem {(shelf/slot/port) | CR | group}

Syntax Description

You can either get the information for all the ports or for a specific one by giving shelf/slot/port.

shelf

Indicates that the particular nitro shelf which is 1 for a single shelf system.

slot

Indicates that the slot and can have a value from 1 to 16.

port

Indicates that the port can have a value of 0 to 143 for modem and 0 to 191 for voice.

group

modems you can also get the information for a specific modem group.

Command Mode

Privileged EXEC.

Usage Guidelines

This command first appeared in Cisco IOS Release 12.0(4)XL.

Example

5800#sh csm voice 1/4/0  
shelf 1, slot 4, port 0
VDEV_INFO:slot 4, port 0
vdev_status(0):VDEV_STATUS_UNLOCKED
ring_no_answer=0, ic_failure=0, ic_complete=0
dial_failure=0, oc_failure=0, oc_complete=0
oc_busy=0, oc_no_dial_tone=0, oc_dial_timeout=0
remote_link_disc=0, busyout=0, modem_reset=0
call_duration_started=00:00:00, call_duration_ended=00:00:00, 
total_call_duration=00:00:00
 
5800#sh csm modem 1/4/0  
VDEV_INFO:slot 4, port 0
vdev_status(0x00000001):VDEV_STATUS_ACTIVE_CALL.
csm_state(0x00000207)=CSM_IC7_CONNECTED, csm_event_proc=0x6086DEE4, current call thru PRI line
invalid_event_count=0, wdt_timeout_count=0
watchdog timer is not activated
wait_for_bchan:False
pri_chnl=(T1 1/2/1:22), vdev_chnl=(s4, c0)
start_chan_p=0, chan_p=64BD2E80, call_id=0x0002, bchan_num=22
The calling party phone number = 
The called party phone number  = 3366874
ring_no_answer=0, ic_failure=0, ic_complete=1
dial_failure=0, oc_failure=0, oc_complete=0
oc_busy=0, oc_no_dial_tone=0, oc_dial_timeout=0
remote_link_disc=0, busyout=0, modem_reset=0
call_duration_started=00:03:39, call_duration_ended=00:00:00, 
total_call_duration=00:00:00

debug csm modem

The debug csm command is used to display the Call Switching Module (CSM) call status debugging information.

debug csm voice {(shelf/slot/port) | CR}

debug csm modem {CR}

Syntax Description

For modem there is no other argument expected and it will turn ON all modem debugging. For voice you can either get the debugging information for all the ports or for a specific one by giving shelf/slot/port.

Command Mode

Privileged EXEC.

Usage Guidelines

This command first appeared in Cisco IOS Release 12.0(4)XL.

debug h225

Use the debug h225 command to display additional information about the actual contents of H.225 RAS messages. Use the no form of this command to disable debug output.

debug h225 {asn1 | events}
no debug voip aaa

Syntax Description

asn1	Indicates that only the ASN.1 contents of any H.225 message sent or received will be displayed.
events	Indicates that key Q.931 events that occur when placing a H.323 call from one gateway to another will be displayed.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Both versions of the debug H225 command display information about H.225 messages. H.225 messages are used to exchange RAS information between gateways and gatekeepers and to exchange Q.931 information between gateways.

The debug h225 events command displays key Q.931 events that occur when placing a H.323 call from one gateway to another. Q.931 events are carried in H.225 messages. This command enables you to monitor Q.931 state changes such as setup, alert, connected, and released.

Note Although the debug information includes the hexadecimal output of the entire H.225 message, only the key state changes are decoded.

The debug h225 asn1command displays the ASN.1 contents of any H.225 message sent or received that contains ASN.1 content. Not all H.225 messages contain ASN.1 content. Some messages contain both Q.931 information and ASN.1 information; if you enter this command, only ASN.1 information will be displayed.

Example

The following sample output for the debug h225 events command shows a call being placed from gateway GW13 to gateway GW14. Before the call was placed, the gateway exchanged RAS messages with the gatekeeper. Because RAS messages do not contain Q.931 information, these messages do not appear in this output.

5800# debug h225 events
H.225 Event Messages debugging is on
5800#
 
*Mar  2 02:47:14.689:      H225Lib::h225TConn:connect in progress on socket [2]
*Mar  2 02:47:14.689:      H225Lib::h225TConn:Q.931 Call State is initialized to be [Null].
*Mar  2 02:47:14.697:Hex representation of the SETUP TPKT to send.0300004D080200DC05040380C0A36C0991313323313333303070099131342331343330307E0026050080060008914A000102004B1F5E5D8990006C0000000005BF7454000C0700000000000000
*Mar  2 02:47:14.701:
*Mar  2 02:47:14.701:      H225Lib::h225SetupRequest:Q.931 SETUP sent from socket [2]
*Mar  2 02:47:14.701:      H225Lib::h225SetupRequest:Q.931 Call State changed to [Call Initiated].
*Mar  2 02:47:14.729:Hex representation of the received TPKT03000021080280DC013401017E0012050340060008914A000100000109350E2B28
*Mar  2 02:47:14.729:
*Mar  2 02:47:14.729:      H225Lib::h225RecvData:Q.931 ALERTING received from socket [2]
*Mar  2 02:47:14.729:      H225Lib::h225RecvData:Q.931 Call State changed to [Call Delivered].
*Mar  2 02:47:17.565:Hex representation of the received TPKT03000034080280DC07040380C0A37E0023050240060008914A0001000109350E2B2802004B1F5E5D8990006C0000000005BF7454
*Mar  2 02:47:17.569:
*Mar  2 02:47:17.569:      H225Lib::h225RecvData:Q.931 CONNECT received from socket [2]
*Mar  2 02:47:17.569:      H225Lib::h225RecvData:Q.931 Call State changed to [Active].
*Mar  2 02:47:23.273:Hex representation of the received TPKT0300001A080280DC5A080280107E000A050500060008914A0001
*Mar  2 02:47:23.273:
*Mar  2 02:47:23.273:      H225Lib::h225RecvData:Q.931 RELEASE COMPLETE received from socket [2]
*Mar  2 02:47:23.273:      H225Lib::h225RecvData:Q.931 Call State changed to [Null].
*Mar  2 02:47:23.293:Hex representation of the RELEASE COMPLETE TPKT to send.0300001A080200DC5A080280107E000A050500060008914A0001
*Mar  2 02:47:23.293:
*Mar  2 02:47:23.293:      H225Lib::h225TerminateRequest:Q.931 RELEASE COMPLETE sent from socket [2]. Call state changed to [Null].
*Mar  2 02:47:23.293:      H225Lib::h225TClose:TCP connection from socket [2] closed

The following output shows the same call being placed from gateway GW13 to gateway GW14 using the debug h225 asn1 command. The output is very long but you can track the following information:

The admission request to the gatekeeper.
The admission confirmation from the gatekeeper.
The ASN.1 portion of the H.225/Q.931 setup message from the calling gateway to the called gateway.
The ASN.1 portion of the H.225/Q.931 setup response from the called gateway, indicating that the call has proceeded to alerting state.
The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been connected.
The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been released.
The ANS.1 portion of the H.225 RAS message from the calling gateway to the gatekeeper, informing it that the call has been disengaged.
The ASN.1 portion of the H.225 RAS message from the gatekeeper to the calling gateway, confirming the disengage request.
The ASN.1 portion of the H.225/Q.931 release complete message sent from the called gateway to the calling gateway.

5800# debug h225 asn1
H.225 ASN1 Messages debugging is on
5800#
 
value RasMessage ::= admissionRequest :
*Mar  2 02:48:18.445:  {
*Mar  2 02:48:18.445:    requestSeqNum 03320,
*Mar  2 02:48:18.445:    callType pointToPoint :NULL,
*Mar  2 02:48:18.445:    callModel direct :NULL,
*Mar  2 02:48:18.445:    endpointIdentifier "60D6BA4C00000001",
*Mar  2 02:48:18.445:    destinationInfo 
*Mar  2 02:48:18.445:    {
*Mar  2 02:48:18.445:      e164 :"14#14300"
*Mar  2 02:48:18.445:    },
*Mar  2 02:48:18.449:    srcInfo 
*Mar  2 02:48:18.449:    {
*Mar  2 02:48:18.449:      e164 :"13#13300"
*Mar  2 02:48:18.449:    },
*Mar  2 02:48:18.449:    bandWidth 0640,
*Mar  2 02:48:18.449:    callReferenceValue 0224,
*Mar  2 02:48:18.449:    conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:18.449:    activeMC FALSE,
*Mar  2 02:48:18.449:    answerCall FALSE
*Mar  2 02:48:18.449:  }
*Mar  2 02:48:18.449:25800CF7 00F00036 00300044 00360042 00410034 00430030 00300030 00300030
00300030 00310103 80470476 33010380 46046633 40028000 E04B1F5E 5D899000
72000000 0005C067 A400
29000CF7 40028000 0109350E 06B80077 
value RasMessage ::= admissionConfirm :
*Mar  2 02:48:18.469:  {
*Mar  2 02:48:18.469:    requestSeqNum 03320,
*Mar  2 02:48:18.469:    bandWidth 0640,
*Mar  2 02:48:18.469:    callModel direct :NULL,
*Mar  2 02:48:18.469:    destCallSignalAddress ipAddress :
*Mar  2 02:48:18.469:      {
*Mar  2 02:48:18.469:        ip '0109350E'H,
*Mar  2 02:48:18.469:        port 01720
*Mar  2 02:48:18.469:      },
*Mar  2 02:48:18.469:    irrFrequency 0120
*Mar  2 02:48:18.473:  }
*Mar  2 02:48:18.473:value H323-UserInformation ::= 
*Mar  2 02:48:18.481:{
*Mar  2 02:48:18.481:  h323-uu-pdu 
*Mar  2 02:48:18.481:  {
*Mar  2 02:48:18.481:    h323-message-body setup :
*Mar  2 02:48:18.481:      {
*Mar  2 02:48:18.481:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:18.481:        sourceInfo 
*Mar  2 02:48:18.481:        {
*Mar  2 02:48:18.481:          terminal 
*Mar  2 02:48:18.481:          {
*Mar  2 02:48:18.481:          },
*Mar  2 02:48:18.481:          mc FALSE,
*Mar  2 02:48:18.481:          undefinedNode FALSE
*Mar  2 02:48:18.481:        },
*Mar  2 02:48:18.481:        activeMC FALSE,
*Mar  2 02:48:18.481:        conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:18.481:        conferenceGoal create :NULL,
*Mar  2 02:48:18.485:        callType pointToPoint :NULL,
*Mar  2 02:48:18.485:        sourceCallSignalAddress ipAddress :
*Mar  2 02:48:18.485:          {
*Mar  2 02:48:18.485:            ip '00000000'H,
*Mar  2 02:48:18.485:            port 00
*Mar  2 02:48:18.485:          }
*Mar  2 02:48:18.485:      }
*Mar  2 02:48:18.485:  }
*Mar  2 02:48:18.485:}
*Mar  2 02:48:18.485:00800600 08914A00 0102004B 1F5E5D89 90007200 00000005 C067A400 0C070000
00000000 00
value H323-UserInformation ::= 
*Mar  2 02:48:18.525:{
*Mar  2 02:48:18.525:  h323-uu-pdu 
*Mar  2 02:48:18.525:  {
*Mar  2 02:48:18.525:    h323-message-body alerting :
*Mar  2 02:48:18.525:      {
*Mar  2 02:48:18.525:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:18.525:        destinationInfo 
*Mar  2 02:48:18.525:        {
*Mar  2 02:48:18.525:          mc FALSE,
*Mar  2 02:48:18.525:          undefinedNode FALSE
*Mar  2 02:48:18.525:        },
*Mar  2 02:48:18.525:        h245Address ipAddress :
*Mar  2 02:48:18.525:          {
*Mar  2 02:48:18.525:            ip '0109350E'H,
*Mar  2 02:48:18.525:            port 011050
*Mar  2 02:48:18.525:          }
*Mar  2 02:48:18.525:      }
*Mar  2 02:48:18.525:  }
*Mar  2 02:48:18.525:}
*Mar  2 02:48:18.525:value H323-UserInformation ::= 
*Mar  2 02:48:22.753:{
*Mar  2 02:48:22.753:  h323-uu-pdu 
*Mar  2 02:48:22.753:  {
*Mar  2 02:48:22.753:    h323-message-body connect :
*Mar  2 02:48:22.753:      {
*Mar  2 02:48:22.753:        protocolIdentifier { 0 0 8 2250 0 1 },
*Mar  2 02:48:22.753:        h245Address ipAddress :
*Mar  2 02:48:22.753:          {
*Mar  2 02:48:22.753:            ip '0109350E'H,
*Mar  2 02:48:22.753:            port 011050
*Mar  2 02:48:22.753:          },
*Mar  2 02:48:22.753:        destinationInfo 
*Mar  2 02:48:22.753:        {
*Mar  2 02:48:22.753:          terminal 
*Mar  2 02:48:22.753:          {
*Mar  2 02:48:22.753:          },
*Mar  2 02:48:22.757:          mc FALSE,
*Mar  2 02:48:22.757:          undefinedNode FALSE
*Mar  2 02:48:22.757:        },
*Mar  2 02:48:22.757:        conferenceID '4B1F5E5D899000720000000005C067A4'H
*Mar  2 02:48:22.757:      }
*Mar  2 02:48:22.757:  }
*Mar  2 02:48:22.757:}
*Mar  2 02:48:22.757:value H323-UserInformation ::= 
*Mar  2 02:48:27.109:{
*Mar  2 02:48:27.109:  h323-uu-pdu 
*Mar  2 02:48:27.109:  {
*Mar  2 02:48:27.109:    h323-message-body releaseComplete :
*Mar  2 02:48:27.109:      {
*Mar  2 02:48:27.109:        protocolIdentifier { 0 0 8 2250 0 1 }
*Mar  2 02:48:27.109:      }
*Mar  2 02:48:27.109:  }
*Mar  2 02:48:27.109:}
*Mar  2 02:48:27.109:value RasMessage ::= disengageRequest :
*Mar  2 02:48:27.117:  {
*Mar  2 02:48:27.117:    requestSeqNum 03321,
*Mar  2 02:48:27.117:    endpointIdentifier "60D6BA4C00000001",
*Mar  2 02:48:27.117:    conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar  2 02:48:27.121:    callReferenceValue 0224,
*Mar  2 02:48:27.121:    disengageReason normalDrop :NULL
*Mar  2 02:48:27.121:  }
*Mar  2 02:48:27.121:3C0CF81E 00360030 00440036 00420041 00340043 00300030 00300030 00300030
00300031 4B1F5E5D 89900072 00000000 05C067A4 00E020
400CF8
value RasMessage ::= disengageConfirm :
*Mar  2 02:48:27.133:  {
*Mar  2 02:48:27.133:    requestSeqNum 03321
*Mar  2 02:48:27.133:  }
*Mar  2 02:48:27.133:value H323-UserInformation ::= 
*Mar  2 02:48:27.133:{
*Mar  2 02:48:27.133:  h323-uu-pdu 
*Mar  2 02:48:27.133:  {
*Mar  2 02:48:27.133:    h323-message-body releaseComplete :
*Mar  2 02:48:27.133:      {
*Mar  2 02:48:27.133:        protocolIdentifier { 0 0 8 2250 0 1 }
*Mar  2 02:48:27.133:      }
*Mar  2 02:48:27.133:  }
*Mar  2 02:48:27.133:}
*Mar  2 02:48:27.133:05000600 08914A00 01
.

debug ras

Use the debug voip ccapi command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in ITU-T specification H.225. Use the no form of this command to disable debug output.

debug ras
no debug ras

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Use the debug ras command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in ITU-T specification H.225.

Example

In the following output, gateway GW13.cisco.com sends a RAS registration request message (RRQ) to gatekeeper GK15.cisco.com at IP address 172.9.53.15. GW13.cisco.com then receives a registration confirmation (RCF) message from the gatekeeper. If there is no response, it could mean that the gatekeeper is offline or improperly addressed. If you receive a reject message (RRJ), it could mean that the gatekeeper is unable to handle another gateway or that the registration information is incorrect.

5800# debug ras 
*Mar 13 19:53:34.231:      RASlib::ras_sendto:msg length 105 from
                            172.9.53.13:8658 to 1.9.53.15:1719
*Mar 13 19:53:34.231:      RASLib::RASSendRRQ:RRQ (seq# 36939) sent
                            to 172.9.53.15
*Mar 13 19:53:34.247:      RASLib::RASRecvData:successfully rcvd
                            message of length 105 from 172.9.53.15:1719
*Mar 13 19:53:34.251:      RASLib::RASRecvData:RCF (seq# 36939) rcvd
                            from [172.9.53.15:1719] on sock [0x6168356C

debug voip aaa

The debug voip aaa command is used to enable or disable debugging messages for gateway aaa to be output to the system console.

debug voip aaa

no debug voip aaa

Syntax Description

This command has no keywords or arguments.

Command Mode

global exec

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

debug voip ccapi

The debug voip ccapi command is used for debugging the call control API.

debug voip ccapi

no debug voip ccapi

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

Example

5800# show debug
voip:
  voip ccAPI function enter/exit debugging is on
Oct  9 17:39:20.267:cc_api_call_setup_ind (vdbPtr=0x60ED5134,
callInfo={called=3001, calling=4004, fdest=0 peer_tag=1},
callID=0x6104B374)
Oct  9 17:39:20.275:cc_process_call_setup_ind (event=0x60D45CF0) handed
call to app "sess"
Oct  9 17:39:20.279:ccAppInitialize (name=App for callId  3
, appHandle=0x6103DD44)
Oct  9 17:39:20.279:ccCallSetContext (callID=0x3, context=0x6103DD3C)
Oct  9 17:39:20.279:ccCallSetupAck (callID=0x3)
Oct  9 17:39:20.279:ccGenerateTone (callID=0x3 tone=8)
Oct  9 17:39:20.279:ccCallApp (callID=0x3)
Oct  9 17:39:20.279:ccCallSetContext (callID=0x3, context=0x60DC4594)
00:11:31:%RADIUS-6-SERVERALIVE:Radius server 171.69.184.73 is
responding
again (previously dead).
Oct 9 17:39:22.808:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:23.069:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:23.399:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=5, mode=0)
Oct  9 17:39:23.652:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=1, mode=0)
Oct  9 17:39:24.041:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=0, mode=0)
Oct  9 17:39:24.294:cc_api_call_digit (vdbPtr=0x60ED5134, callID=0x3,
digit=0, mode=0)
Oct  9 17:39:24.294:ccCallAppReturn (callID=0x3)
Oct  9 17:39:24.294:ccCallApp (callID=0x3)
Oct  9 17:39:24.294:ccCallSetContext (callID=0x3, context=0x6105DC90)
Oct  9 17:39:24.294:ccCallProceeding (callID=0x3, prog_ind=0x0)
Oct  9 17:39:24.294:ccCallSetupRequest (peer=0x60FE4068, dest=,
params=0x6105DB70 mode=0, *callID=0x60D50978)
Oct  9 17:39:24.294:callingNumber=4004, calledNumber=115100,
redirectNumber=
Oct  9 17:39:24.294:accountNumber=, finalDestFlag=0,
guid=3c85.5d28.2861.0004.0000.0000.000a.8dfc
Oct  9 17:39:24.294:peer_tag=115
Oct  9 17:39:24.294:ccIFCallSetupRequest:(vdbPtr=0x60D4A268, dest=,
callParams={called=115100, calling=4004, fdest=0, voice_peer_tag=115},
mode=0x0)
Oct  9 17:39:24.294:ccCallSetContext (callID=0x4, context=0x6105DD78)
Oct  9 17:39:26.350:cc_api_call_alert(vdbPtr=0x60D4A268, callID=0x4,
prog_ind=0x8, sig_ind=0x0)
Oct  9 17:39:26.350:ccCallAlert (callID=0x3, prog_ind=0x8, sig_ind=0x0)
Oct  9 17:39:26.350:ccConferenceCreate (confID=0x60D509C8, callID1=0x3,
callID2=0x4, tag=0x0)
Oct  9 17:39:26.350:cc_api_bridge_done (confID=0x1, srcIF=0x60D4A268,
srcCallID=0x4, dstCallID=0x3, disposition=0, tag=0x0)
Oct  9 17:39:26.350:cc_api_bridge_done (confID=0x1, srcIF=0x60ED5134,
srcCallID=0x3, dstCallID=0x4, disposition=0, tag=0x0)
Oct  9 17:39:26.350:cc_api_caps_ind (dstVdbPtr=0x60D4A268,
dstCallId=0x4,srcCallId=0x3, caps={codec=0x7, fax_rate=0x7F, vad=0x3})
Oct  9 17:39:26.350:cc_api_caps_ind (dstVdbPtr=0x60ED5134,
dstCallId=0x3,srcCallId=0x4, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.350:cc_api_caps_ack (dstVdbPtr=0x60ED5134,
dstCallId=0x3,srcCallId=0x4, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.350:cc_api_caps_ack (dstVdbPtr=0x60D4A268,
dstCallId=0x4,srcCallId=0x3, caps={codec=0x4, fax_rate=0x2, vad=0x2})
Oct  9 17:39:26.430:cc_api_call_connected(vdbPtr=0x60D4A268,
callID=0x4)
Oct  9 17:39:26.430:ccCallConnect (callID=0x3)
Oct  9 17:39:26.430:ccCallAppReturn (callID=0x3)
Oct  9 17:39:26.430:ccCallSetContext (callID=0x4, context=0x6103DD3C)
Oct  9 17:39:30.683:cc_api_call_disconnected(vdbPtr=0x60D4A268,
callID=0x4, cause=0x10)
Oct  9 17:39:30.683:ccCallDisconnect (callID=0x4, cause=0x10 tag=0x0)
Oct  9 17:39:30.683:ccConferenceDestroy (confID=0x1, tag=0x0)
Oct  9 17:39:30.687:cc_api_bridge_done (confID=0x1, srcIF=0x60D4A268,
srcCallID=0x4, dstCallID=0x3, disposition=0 tag=0x0)
Oct  9 17:39:30.727:cc_api_call_disconnect_done(vdbPtr=0x60D4A268,
callID=0x4, disp=0, tag=0x0)
Oct  9 17:39:30.727:cc_api_bridge_done (confID=0x1, srcIF=0x60ED5134,
srcCallID=0x3, dstCallID=0x4, disposition=0 tag=0x0)
Oct  9 17:39:30.727:ccCallDisconnect (callID=0x3, cause=0x10 tag=0x0)
Oct  9 17:39:30.779:cc_api_call_disconnect_done(vdbPtr=0x60ED5134,
callID=0x3, disp=0, tag=0x0)
00:11:42:%LINK-3-UPDOWN:Interface Serial0:18, changed state to down

debug voip ivr

The debug voip ivr command is used to debug the IVR application. IVR debug messages will be displayed when a call is being actively handled by the IVR scripts. Error output should only occur if something is not working or an error condition has been raised. States output supplies information about the current status of the IVR script and the different events which are occurring in that state.

debug voip ivr [states | error | all]

no debug voip ivr [states | error | all]

Syntax Description

This command has no keywords or arguments.

Default

Disabled

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3(6)NA2.

There are two types of messages:

Error---These messages should only be displayed if an error occurred.
States---These debug messages will display a lot of information about how IVR is handling each call.

shelf	Indicates that the particular nitro shelf which is 1 for a single shelf system.
slot	Indicates that the slot and can have a value from 1 to 16.
port	Indicates that the port can have a value of 0 to 143 for modem and 0 to 191 for voice.
group	modems you can also get the information for a specific modem group.

Table of Contents

Voice over IP for the Cisco AS5800 Debug Commands

Syntax Description

Default

Command Mode

Usage Guidelines

Command Mode

Usage Guidelines

Command Mode

Usage Guidelines

Example

Syntax Description

Default

Command Mode

Usage Guidelines

Command Mode

Usage Guidelines

Command Mode

Usage Guidelines

Sample Display

Usage Guidelines

Sample Display

Syntax Description

Default

Command Mode

Usage Guidelines

State Descriptions

Events Description

Example

Syntax Description

Default

Command Mode

Usage Guidelines

State Definitions

Event definitions

Example

Syntax Description

Default

Command Mode

Usage Guidelines

State Definitions

Event Definitions

Example

Syntax Description

Command Mode

Usage Guidelines

Example

Syntax Description

Command Mode

Usage Guidelines

Syntax Description

Default

Command Mode

Usage Guidelines

Example

Syntax Description

Default

Command Mode

Usage Guidelines

Example

Syntax Description

Command Mode

Default

Command Mode

Usage Guidelines

Syntax Description

Default

Command Mode

Usage Guidelines

Example

Syntax Description

Default

Command Mode

Usage Guidelines