Other_Leg_ Keypress Events

[invoso.com]

in version:

v7.5.6386.35139 (2017-06-26 18:31:19.24)

 

VG again don't recognize source channel of dtmf signalisation.

153542.860  23  20  10 ev    dtmf 0   (47710282,48,0) iConferenceOtherLegLid=117, iConferenceOtherLegIvrDevPort=58
153542.860  23  20  10       q_scr +     evScriptEvent 48 0
153542.860  23 117  58       q_scr +     evScriptEvent 48 OTHER_LEG_0
153542.860   9  20  10       q_scr run   evScriptEvent sCode=[0] iActionID=0, crn=0 [0|0|0|0|0][|||||] 00:00:00 max:4|00:00:00.0310018
153542.860   9  20  10       se    0 48  0|0|0  || LineState=LS_GETNBRS_RXDIGITS
153542.860   9  20  10       LsGetNbrsRxDigits lCode=48 lCode2Str=0 sCode=0
153542.860   9  20  10 state [Wait till end of recorded call_PBX_02_03] Number Input 0
153542.860   9  20  10       path {0} not found
153542.860   9  20  10 t     timer set   7200 sec : EV_TIMEOUT_GOTOMODULE
153542.860   9 117  58       q_scr run   evScriptEvent sCode=[OTHER_LEG_0] iActionID=0, crn=0 [0|0|0|0|0][|||||] 00:00:00 max:4|00:00:00.0310018
153542.860   9 117  58       se    OTHER_LEG_0 48  0|0|0  || LineState=LS_XFER_9_WaitEndCall_OutLeg
153542.860   9 117  58       LsXfer_9_WaitEndCall_OutLeg : [48:OTHER_LEG_0] 0,0,0   ,,

In one of previous VG version this bug was solved.

Again VG detect any dtmf signalization as client line dtmf and on agent line still as OTHER_LEG_

[SupportTeam]

In the trace excerpt provided we can see that the keypress of 0 on port 10:

153542.860  23  20  10 ev    dtmf 0   (47710282,48,0) iConferenceOtherLegLid=117, iConferenceOtherLegIvrDevPort=58

Did result in "OTHER_LEG_X" event on port 58:

153542.860   9 117  58       se    OTHER_LEG_0 48  0|0|0  || LineState=LS_XFER_9_WaitEndCall_OutLeg
153542.860   9 117  58       LsXfer_9_WaitEndCall_OutLeg : [48:OTHER_LEG_0] 0,0,0   ,,

Is the script on port 58 perhaps not in the right state/module, and that is why it does not react as you would like it to?

 

Post 58 is in "LsXfer_9_WaitEndCall_OutLeg" state.

"LsXfer_9_WaitEndCall_OutLeg" state is just an outgoing leg of a 2-line call transfer.

That port is not running any VoiceGuide script of its own on it.

 

 

To better comment on this can you post a scrip demonstrating what you are trying to achieve, and the trace that captures the entire call (and preferably system startup as well)

[invoso.com]

Our script is simple. We transfer call to agent and agent will per DTMF tone forward caller to next module.

Problem is we need to identify dtmf source side to eliminate caller unexpected tone activity.

 

we expect only VG identify on Caller side OTHER_LEG activity initialized by Agent.

153542.860  23  20  10       q_scr +     evScriptEvent 48 0
153542.860  23 117  58       q_scr +     evScriptEvent 48 OTHER_LEG_0

this log shows what happen when Agent send 0 DTMF tone, VG recognize as Caller activity.

 

Other way, we need separate Agent dtmf activity to allow access to special IVR functions for Caller.

[SupportTeam]

The trace shows that there was one keypress detection: from call that was connected to the system's port 10. (and then OTHER_LEG event was sent to port 58).

 

Can you please .ZIP up and post the entire vgEngine trace and the ktTel trace for the day. We can then better see what happened on this system prior to this coo being connected.

 

Also, was the call on port 10 listening to the call on 'speakerphone' ? That is the only way that a keypress on port 58 would be detected by system listening to sound from call connected to port 10.

[invoso.com]

We test VG v7.4.5536.24656 (27-Feb-15 13:41:52.12) and there was:

143429.613   7   4   2 state [Wait till end of recorded call_PBX_02_03_2] Playing wav ()
143429.613   7   4   2       se    0 48  0|0|0  || LineState=LS_GETNBRS_PLAYWELCOMEMSG
143429.613   7   4   2       LsGetNbrsPlayWelcMsg 0,0
143429.613   7   4   2       play  PlaySoundStop ok
143429.613   7   4   2 state [Wait till end of recorded call_PBX_02_03_2] Number Input 0
143429.617   7 124  43       se    OTHER_LEG_0 48  0|0|0  || LineState=LS_XFER_9_WAITENDCALL_DialingSide
143429.617   7 124  43       ct    calltrack_set ID=0, guid=f76c9a7c-b432-4b9c-a4b5-7eca6b5d88eb
143429.617   7 124  43       LsXfer_9_WaitEndCall_OutLeg : [48:OTHER_LEG_0] 0,0,0   ,,
143429.617   7   4   2       se    OTHER_LEG_0 48  0|0|0  || LineState=LS_GETNBRS_RXDIGITS
143429.617   7   4   2       LsGetNbrsRxDigits lCode=48 lCode2Str=0 sCode=OTHER_LEG_0

It was perfect detect, AGENT on 124 43 send dtmf 0.

 

 

it is best way to identify dtmf source.

[SupportTeam]

Can you please .ZIP up and post the entire vgEngine traces and the ktTel trace for the day for this test system.

We can then see what happened on those calls/system prior to this call being connected.

 

(eg. are you doing any 2- line call recording on this connection and using the 'voice resource' from port 58 to do the 2-line recording?)