[cisco-voip] Lift phone not hanging up

Nathan Reeves nathan.a.reeves at gmail.com
Mon Sep 17 03:51:58 EDT 2018


I've seen something similar last week with an analogue intercom system (but
connecting to a VG320).

Ended up applying a couple of 'tone dialtone ..' commands to the dial-peer
which is associated with the peer connected to the analogue endpoint:

dial-peer voice YYYY pots
 no tone dialtone remote-onhook
 tone busytone remote-onhook
 service stcapp
 port 0/0/XX

This allowed the VG to pick up on the hangup alot quicker than previously.

Hope this provides some help.

Nathan

On Mon, Sep 17, 2018 at 3:19 PM James Andrewartha <
jandrewartha at ccgs.wa.edu.au> wrote:

> Hi voipers,
>
> We have a new building with a new Kone lift which has a phone that
> doesn't detect the end of call and hang up. It's connected to a VG224
> that then goes to CUCM 10.5, then via H.232 to a 2921 that has our ISDN.
>
> I ran "debug voice application stcapp port 2/23" while the lift techs
> made a call, they said it connected, spoke to the operator at the other
> end who hung up, then it took two minutes to pick up on the hangup, and
> then still made a different noise for another minute.
>
> I think the debug logs confirm this, the call starts at 05:20:00,
> connects and then there is a slightly more than 2 minute gap
>
> > Sep 13 05:20:07.949: 2/23   :     stcapp_call_info_eh::caller_name=Lift
> - D
> > Sep 13 05:20:07.949: 2/23   :     Irrelevant CALL_INFO message is ignore!
> > Sep 13 05:20:07.949: 2/23   :     No state change
> > Sep 13 05:20:07.953: 2/23   : ==> Received
> event:STCAPP_DC_EV_DEVICE_CALL_INFO
> > Sep 13 05:20:07.953: 2/23   :     Call State:ACTIVE
> > Sep 13 05:20:07.953: 2/23   : stcapp_conn_call_info_eh
> > Sep 13 05:20:07.953: 2/23   : stcapp_get_ccb_ptr
> > Sep 13 05:20:07.953: 2/23   :     stcapp_call_info_eh::caller_name=Lift
> - D
> > Sep 13 05:20:07.953: 2/23   :     Irrelevant CALL_INFO message is ignore!
> > Sep 13 05:20:07.953: 2/23   :     No state change
> > Sep 13 05:22:32.238: 2/23   : stcapp_get_dcb_and_lcb
> > Sep 13 05:22:32.238: 2/23   : stcapp_screen_api_event
> > Sep 13 05:22:32.238: 2/23   :
>  event:STCAPP_DC_EV_MEDIA_CLOSE_RCV_CHNL received.
> > Sep 13 05:22:32.242: 2/23   : stcapp_screen_close_rcv_chnl
> > Sep 13 05:22:32.242: 2/23   : ==> Received
> event:STCAPP_DC_EV_MEDIA_CLOSE_RCV_CHNL
> > Sep 13 05:22:32.242: 2/23   :     Call State:ACTIVE
> > Sep 13 05:22:32.242: 2/23   : stcapp_close_rcv_chnl_eh
> > Sep 13 05:22:32.242: 2/23   :     call_ref=44869558
>
> and then the call state goes to ONHOOK_PEND, then REM_ONHOOK_PEND,
> OFFHOOK, 15 seconds it receives an inter-digit timeout which it ignores,
> waits another 45 seconds, CONNECTING, ACTIVE_PENDING, waits 8 seconds,
> ONHOOK_PEND, ONHOOK_DISCONNECT and then it's cleaned up.
>
> Anyway, this is way beyond my ken and our other lift phones don't have
> this problem, does anyone have any thoughts on how to further debug this
> or fix it? My only idea is to bypass CUCM and have the VG224 talk
> directly to the 2921, which I've done for some of our security systems.
> The lift tech said there's some options they can tune but would prefer
> to leave things at defaults if possible.
>
> Thanks,
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180917/0bcdd35f/attachment.html>


More information about the cisco-voip mailing list