Improper call termination after GCEV_DISCONNECTED with active Web Service

[Maciej Zasadzki ADVICOS]

We encounter situations where, after a call disconnects, VoiceGuide does not properly terminate the session. In the attached example, during the processing of the Web Service target_user_data, a disconnect occurs (GCEV_DISCONNECTED), with the line in LS_WS_CALL state. Likely due to asynchronicity, upon receiving a 200 OK response, VoiceGuide continues executing the script flow instead of terminating. Consequently, the call remains active until the 20-minute timeout set in the transfer module. Only after that timeout does proper termination occur (GCEV_DROPCALL, GCEV_RELEASECALL, RecEnd).

How should we configure VoiceGuide so that after GCEV_DISCONNECTED, the Web Service callback does not continue the normal script flow but immediately ends the session? Attached is an anonymized log.

 

 

 

 

vgEngine_FORUM_FINAL.log

[SupportTeam]

Please post the ktTel trace capturing these times.

Looks like something interrupted the stopping of the recording that was initiated here:

073716.714   20  17   5    83       HangupCall qScr exec src=LineEvCallState_DISCONNECTED, opt=, crn_in=6020011, L1=Disconnected, L2=Running_Normal, lPlayId=0, lRecId=2021317501
073716.714   20  17   5    83       HangupCall crn_connected=0, crn_NewCallArriving=0, crn_CurrentMakeCall=0, crn_InProcessOfReleasing=6020011
073716.714   20  17   5    83       rec_stop begin trunc100ms=0, rec_id=2021317501, caller=Line_Hangup_Main
073716.714   20  17   5    83       rec_stop lRec_Id_InProcessOfStopping=2021317501, lRecId=0
073716.715   20  17   5    83       HangupCall sScriptToRunOnHangup=[C:\VoiceGuide\Scripts\TERMINATION_SCRIPT.vgs]
073716.715   20  17   5    83       HangupCall lRec_Id_InProcessOfStopping=2021317501, wait till recording cmpletes

also, a quick fix would be to check the value of the $RV[Conf_LineId_2] or other similar Result Variable, before getting the original line to just hold for 20 minutes in the "Wait_till_end_of_call" module:

073718.004   20  17   5    83 state [Wait_till_end_of_call] Playing wav () | 
073718.007   20  17   5    83 t     timer set   10 sec : EV_TIMEOUT_HANGUP
073718.008   20  17   5    83 t     timer set   1200 sec : EV_TIMEOUT_GOTOMODULE

The attached trace does not show the Result Variable assignments, so looks like trace was captured at a lower log level.

[Maciej Zasadzki ADVICOS]

OK,

I have added a check for the Conf_LineId_2 value.

I am also attaching the ktTel trace file covering this case.

0924_ktTel_SANITIZED_v9.txt

[SupportTeam]

Trace shows the callflow performing an outbound call on another channel and bridging both calls immediately upon the outgoing call being answered. 2 recordings where then started using API calls: one of each side of the call..

The incoming call was hung up soon after outgoing call was connected. The related outgoing call leg was automatically disconnected, but the original incoming leg of call was not hung up as the channel was awaiting the ending of the recording on that line before starting the 'after hangup script' that was set to run on this leg. The 'end-of-record' event however did not arrive...

It appears that the system thought that a 2-line recording was happening on this line, which let to wrong approach in the stopping of recording.

One possible explanation of how the system could have got into this state is that a 2-line recording was started on that same channel using an API call on a previous call, and that 2-line call recording flag was not cleared from the previous call... we would need to see traces of what happened on that channel on the previous calls to confirm,  but this would still be a bug as the system ought to handle that case...

In-script detection of end of conference is best way to handle this situation for now.  A fix for this 2-line recording interference issue should be available in next version release.