Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

FXO remains busy incoming IVR

Hi all,

I am running CISCO-2811 voice gateway with CUCM 7.1.3 along with UCCX 7.0.1 for IVR auto attendant. 


When someone calls on incoming PSTN and IVR starts script. if caller disconnects the call without dialing extension/operation to make a call, line remains busy more than 2 minutes and interesting is that after approximately 1 minute IVR generates a call with same Caller ID who disconnected the call 1 minutes before.

If someone calls on incoming PSTN IVR and dial any extension/operator then after disconnecting call, FXO line works fine.

Please help me. Thank you!


Rizwan Haider

New Member

Hi Rizwan,

Hi Rizwan, May you please let me know the ios code on the router, and if u may attach the outputs of debug voice ccapi inout, debug voip vtsp all debug vpm signal along with the outputs of show voice dsp detail, show voice dsp group all and show voice port summ and a show tech from the router for a working and a non working call. Does this issue go post a reboot of the router? The new caller id generated is in reference to the uccx or the gateway? Thanks Himank
New Member

Hi Himank,Thank you for the

Hi Himank,

Thank you for the reply and giving me support. Following are the answers.

1. code is "flash:c2800nm-adventerprisek9-mz.151-4.M6.bin"

2. i have attached the output.

3. Same problem after reloading the router.

4. Caller ID is my mobile number when i receive the call though gateway and UCCX.

Thank you :-)



Rizwan Haider

For your nonworking call, I

For your nonworking call, I see call comes in at 19:02:11 and ends at 19:03:50.  Is that not correct?


Jun  3 19:03:50.815: //79/6800A6578065/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Jun  3 19:03:50.815: //79/6800A6578065/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Jun  3 19:03:50.815: //79/6800A6578065/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Jun  3 19:03:50.815: //80/6800A6578065/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
Jun  3 19:03:50.815: //80/6800A6578065/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Jun  3 19:03:50.819: //80/6800A6578065/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Jun  3 19:03:50.819: //79/6800A6578065/VTSP:(0/3/1):-1:5:2/vtsp_process_event:  
   [state:S_CONNECT, event:E_CC_DISCONNECT]
Jun  3 19:03:50.819: //79/6800A6578065/VTSP:(0/3/1):-1:5:2/act_disconnect:  
   Cause Value=16


Which gateway protocol are you using?  MGCP/SIP/H.323?

New Member

Hi Brian Meade,I am using H

Hi Brian Meade,

Actually i made the call and once IVR initialized then immediately i disconnected the call. Total call duration was around 5 to 8 seconds only.


I am using H.323 gateway.

Run these debugs: debug vpm

Run these debugs:


debug vpm signal

debug voice ccapi inout

debug cch323 all

debug h225 asn1

debug h225 q931

debug h245 asn1

debug voip vtsp all

New Member

Hi Brian,I have attached the

Hi Brian,

I have attached the output. 


Thank you so much for helping. 

Here's the incoming release

Here's the incoming release complete from CUCM:

Jun  3 23:17:15.810: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225
  Q931 Message IE Decodes
Protocol Discriminator : 0x08
CRV Length             : 2
CRV Value              : 0x8002
Message Type           : 0x5A: RELEASE_COMP
 Cause: Length Of IE=2
 Data 8090
 User-User: Length Of IE=34
 Data 052580060008914A000511001100D2649213EAAB11E38009A2BF5DC7FF0A10800100
Jun  3 23:17:15.810: //4/D263F5EB8007/H323/validate_crv: 
Jun  3 23:17:15.810: H225.0 INCOMING ENCODE BUFFER::= 2580060008914A000511001100D2649213EAAB11E38009A2BF5DC7FF0A10800100
Jun  3 23:17:15.810: 
Jun  3 23:17:15.810: H225.0 INCOMING PDU ::=

value H323_UserInformation ::= 
        h323-message-body releaseComplete : 
          protocolIdentifier { 0 0 8 2250 0 5 }
            guid 'D2649213EAAB11E38009A2BF5DC7FF0A'H
        h245Tunneling FALSE


3 seconds later is when the FXO goes on-hook:

Jun  3 23:17:19.226: htsp_process_event: [0/3/1, FXOLS_ONHOOK, E_DSP_SIG_0100]



Was this when you expected the call to end or is this significantly later?


We may need to look at your IVR script to see if the delay in disconnection is coming from there.

New Member

Hi Brian, where i can give

Hi Brian,


where i can give you desktop access to show configuration?

Give me your ID so we can make a session. thank you so much.

Rizwan, It's probably easier



It's probably easier for you to just upload the .aef file on here.



New Member

Hi,I have attached aa.aef


I have attached aa.aef script file from UCCX 7. Please go through. thank you so much. 

Have you tried using the

Have you tried using the reactive debugging to see what step it is potentially getting hung at?

New Member

No, I didn't check that.

No, I didn't check that.

New Member

Hi brian, what you suggest me

Hi brian, 

what you suggest me now to resolve the issue?

Watch this video by Alex

Watch this video by Alex Hannah-


It should show you how to go through the reactive debug and see where the source of delay before the terminate step occurs.

New Member

Hi brian,Let me go through

Hi brian,

Let me go through and see the source of delay. thank you!