FXO remains busy incoming IVR

[haider.rizwan]

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!

Regards,

Rizwan Haider

[Himank Pande]

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

[haider.rizwan]

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 :-)

Regards

Rizwan Haider

[Brian Meade]

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?

[haider.rizwan]

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.

[Brian Meade]

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

[haider.rizwan]

Hi Brian,

I have attached the output. 

Thank you so much for helping. 

[Brian Meade]

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-uu-pdu 
      {
        h323-message-body releaseComplete : 
        {
          protocolIdentifier { 0 0 8 2250 0 5 }
          callIdentifier 
          {
            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.

[haider.rizwan]

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.

[Brian Meade]

Rizwan,

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

Brian

[haider.rizwan]

Hi,

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

[Brian Meade]

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

[haider.rizwan]

No, I didn't check that.

[haider.rizwan]

Hi brian, 

what you suggest me now to resolve the issue?

[Brian Meade]

Watch this video by Alex Hannah- https://www.youtube.com/watch?v=LpXAuW0_ypw

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