Yealink Forums
BUG - inbound hold/unhold/hangup not work via remote control for some accounts - Printable Version

+- Yealink Forums (http://forum.yealink.com/forum)
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: General topics (/forumdisplay.php?fid=15)
+--- Thread: BUG - inbound hold/unhold/hangup not work via remote control for some accounts (/showthread.php?tid=42207)



BUG - inbound hold/unhold/hangup not work via remote control for some accounts - nSolvePaul - 11-02-2018 11:18 AM

Via remote control I am experiencing a bug whereby the phone will NOT hangup/hold/unhold an INBOUND call for an account connected to a 3CX voip system.

Yet for another voip provider (Gradwell) remote control works fine.
And for the 3CX account it will hangup/hold/unhold an OUTBOUND call via remote control.
And for the 3CX account it will Answer an inbound call via remote control.

We are seeing this bug on xx.83.0.35, xx.83.0.50 and xx.84.0.10
We are seeing this bug on T46S and T23

Please advise how to get this resolved and what logs are needed.


RE: BUG - inbound hold/unhold/hangup not work via remote control for some accounts - nSolvePaul - 11-02-2018 01:11 PM

Here are the syslogs from the T46S when I request a Hold but it fails to action it:

Code:
11-02-2018    13:05:02    User.Info    192.168.10.105    Nov  2 13:05:05 GUI [1415:1415]: TALK<6+info  > 905.827.411:RTCP-XR private report Id[32792][1]
11-02-2018    13:05:02    User.Info    192.168.10.105    Nov  2 13:05:05 GUI [1415:1415]: TALK<6+info  > 905.826.568:RTCP-XR private report Id[32792][2]
11-02-2018    13:05:00    User.Notice    192.168.10.105    Nov  2 13:05:03 ipvp[1298.1298]: IPVP<5+notice> 903.298.440:Message=0x00000001(0x00000000+0x00000000+0)
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:05:00 GUI [1415:1415]: TALK<6+info  > 900.827.343:RTCP-XR private report Id[32792][1]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:05:00 GUI [1415:1415]: TALK<6+info  > 900.826.492:RTCP-XR private report Id[32792][2]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.974.095:CActionUri::ProcessRegisterAcc[HOLD:32791]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.973.612:bIdenticalIP [0] bIdenticalUser [0]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.967.322:SetCTIBind IP = [] TerminalType = [] Name = [] UserName = [] BindType = []
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.966.684:SetFwdCfgCode After Formatted [HOLD:32791]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.966.281:CActionUri::ProcessSetForward[HOLD:32791]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.965.812:Action(HOLD:32791)
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.965.365:Action URI: IP(192.168.10.114)
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.964.735:Action URI: IP(key=HOLD:32791&RIP=192.168.10.114)
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: CUIT<6+info  > 899.963.246:Allow to Remote Control !
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: CUIT<6+info  > 899.960.522:CAccessManager::ProcessMsg:0x60d07, lParam:0
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: URIL<6+info  > 899.959.226:URICode [key=HOLD:32791&RIP=192.168.10.114]
11-02-2018    13:04:57    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: IDUI<6+info  > 899.957.852:CScreenSaverManager OnExitScreenSavers[0]
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1415:1415]: IDUI<6+info  > 899.952.678:CScreenSaverManager MsgID(396551), wPram(0), lParm(0)
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.956.150:[DoService:104]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~end request[200]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
11-02-2018    13:04:56    User.Error    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <3+error > 899.951.684:[CallDskMsgTimeoutEx:153]CallDskMsgTimeoutEx [0x60d07] lret[1]
11-02-2018    13:04:56    User.Error    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <3+error > 899.950.903:[SendNow:202]Post msg : [DONOW:NULL] [app_vpPhone], 0x60d07, 0, 0, [key=HOLD:32791&RIP=192.168.10.114]
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.949.118:[Common_RegMatch:643]The reg[^192\.168\.10\.[0-9]{1,3}$] is matched [192.168.10.114].
11-02-2018    13:04:56    User.Error    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <3+error > 899.946.007:[VerifyUMEAction:295]Error: The AURemoteIP is empty!
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.944.550:[DoActionURI:66]ip:192.168.10.114 Action URI: key=HOLD:32791
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.943.402:[SetPwdLockState:421]m_nLoginTryTimes[0], m_iLockTimeStart[0]
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.941.688:[CheckPassword:255]login success, role[admin] user[admin]
11-02-2018    13:04:56    User.Info    192.168.10.105    Nov  2 13:04:59 GUI [1927:1927]: WEB <6+info  > 899.935.600:[DoService:62]~~~~~~~~~~~~~~~~~[192.168.10.114] url[/servlet?m=mod_action&key=HOLD:32791]

Attached two logs one showing when remote control hold works and one when it does not.

Please advise if you need more information or if there is another channel to report bugs


RE: BUG - inbound hold/unhold/hangup not work via remote control for some accounts - nSolvePaul - 11-02-2018 03:10 PM

Turned out to be a configuration setting in the 3CX voip back end - sorted now