<div dir="ltr"><div dir="ltr">I've seen something similar last week with an analogue intercom system (but connecting to a VG320).<div><br></div><div>Ended up applying a couple of 'tone dialtone ..' commands to the dial-peer which is associated with the peer connected to the analogue endpoint:</div><div><br></div><div><div>dial-peer voice YYYY pots</div><div> no tone dialtone remote-onhook</div><div> tone busytone remote-onhook</div><div> service stcapp</div><div> port 0/0/XX</div></div><div><br></div><div>This allowed the VG to pick up on the hangup alot quicker than previously.</div><div><br></div><div>Hope this provides some help.</div><div><br></div><div>Nathan</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 3:19 PM James Andrewartha <<a href="mailto:jandrewartha@ccgs.wa.edu.au">jandrewartha@ccgs.wa.edu.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi voipers,<br>
<br>
We have a new building with a new Kone lift which has a phone that<br>
doesn't detect the end of call and hang up. It's connected to a VG224<br>
that then goes to CUCM 10.5, then via H.232 to a 2921 that has our ISDN.<br>
<br>
I ran "debug voice application stcapp port 2/23" while the lift techs<br>
made a call, they said it connected, spoke to the operator at the other<br>
end who hung up, then it took two minutes to pick up on the hangup, and<br>
then still made a different noise for another minute.<br>
<br>
I think the debug logs confirm this, the call starts at 05:20:00,<br>
connects and then there is a slightly more than 2 minute gap<br>
<br>
> Sep 13 05:20:07.949: 2/23 : stcapp_call_info_eh::caller_name=Lift - D<br>
> Sep 13 05:20:07.949: 2/23 : Irrelevant CALL_INFO message is ignore!<br>
> Sep 13 05:20:07.949: 2/23 : No state change<br>
> Sep 13 05:20:07.953: 2/23 : ==> Received event:STCAPP_DC_EV_DEVICE_CALL_INFO<br>
> Sep 13 05:20:07.953: 2/23 : Call State:ACTIVE<br>
> Sep 13 05:20:07.953: 2/23 : stcapp_conn_call_info_eh<br>
> Sep 13 05:20:07.953: 2/23 : stcapp_get_ccb_ptr<br>
> Sep 13 05:20:07.953: 2/23 : stcapp_call_info_eh::caller_name=Lift - D<br>
> Sep 13 05:20:07.953: 2/23 : Irrelevant CALL_INFO message is ignore!<br>
> Sep 13 05:20:07.953: 2/23 : No state change<br>
> Sep 13 05:22:32.238: 2/23 : stcapp_get_dcb_and_lcb<br>
> Sep 13 05:22:32.238: 2/23 : stcapp_screen_api_event<br>
> Sep 13 05:22:32.238: 2/23 : event:STCAPP_DC_EV_MEDIA_CLOSE_RCV_CHNL received.<br>
> Sep 13 05:22:32.242: 2/23 : stcapp_screen_close_rcv_chnl<br>
> Sep 13 05:22:32.242: 2/23 : ==> Received event:STCAPP_DC_EV_MEDIA_CLOSE_RCV_CHNL<br>
> Sep 13 05:22:32.242: 2/23 : Call State:ACTIVE<br>
> Sep 13 05:22:32.242: 2/23 : stcapp_close_rcv_chnl_eh<br>
> Sep 13 05:22:32.242: 2/23 : call_ref=44869558<br>
<br>
and then the call state goes to ONHOOK_PEND, then REM_ONHOOK_PEND,<br>
OFFHOOK, 15 seconds it receives an inter-digit timeout which it ignores,<br>
waits another 45 seconds, CONNECTING, ACTIVE_PENDING, waits 8 seconds,<br>
ONHOOK_PEND, ONHOOK_DISCONNECT and then it's cleaned up.<br>
<br>
Anyway, this is way beyond my ken and our other lift phones don't have<br>
this problem, does anyone have any thoughts on how to further debug this<br>
or fix it? My only idea is to bypass CUCM and have the VG224 talk<br>
directly to the 2921, which I've done for some of our security systems.<br>
The lift tech said there's some options they can tune but would prefer<br>
to leave things at defaults if possible.<br>
<br>
Thanks,<br>
<br>
-- <br>
James Andrewartha<br>
Network & Projects Engineer<br>
Christ Church Grammar School<br>
Claremont, Western Australia<br>
Ph. (08) 9442 1757<br>
Mob. 0424 160 877<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>