Dtmf Other_Leg Fail

[invoso.com]

Hi,

 

we found VG not correct recognizing DTMF tones.

 

All dtmf tones on other_leg are not identified as OTHER_LEG and dtmf tone from other_leg vg see as initial line signal.

 

any side dtmf tone is recognized as initial line signal.

 

in log file connection between lines: 16 and 101

 

 

starting wait to dtmf code:

175200.749 9 16 6 state [switch_disconnect_recorded_call] Playing wav ()

 

and in lines:

175212.233 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34
175212.233 21 16 6 q_scr + evScriptEvent 49 1
175212.233 21 101 34 q_scr + evScriptEvent 49 OTHER_LEG_1

 

vg see dtmf tone as first line not other leg.

 

Why?

 

I used smartphones to test.

 

1010_1748_vgEngine - Kopia (2).zip

1010_ktTel.zip

[SupportTeam]

Attached trace shows that call on port 6 made an outgoing call on port 34 and the two call were bridged together:

 

175200.621 9 16 6 state [Transfer Call fa with CALLER ID] in_leg 6 <=> 34 502131658

 

 

The connection was then recorded:

 

175200.646 15 16 6 rem Record_2Lines_Start [16,16,101,C:\callrecord\ID20161010_175145_41_6_70320_175200.wav] options=[]

 

 

and about 12 seconds into the connected call the caller on port 6 pressed the key "1" on their keypad:

 

175212.233 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34

 

 

The script running on port 6 did not do anything as no path to react to DTMF 1 event was set in module [switch_disconnect_recorded_call] in which that script was at the time:

 

175212.233 9 16 6 state [switch_disconnect_recorded_call] Number Input 1
175212.233 9 16 6 path {1} not found

 

 

The event as passed to the outgoing call on port 34, but as there was no script running on port 34 that event was just ignored:

 

175212.233 9 101 34 q_scr run evScriptEvent sCode=[OTHER_LEG_1] iActionID=0, crn=0
175212.233 9 101 34 se OTHER_LEG_1 49 0|0|0 || LineState=LS_XFER_9_WAITENDCALL_DialingSide
175212.233 9 101 34 LsXfer_9_WaitEndCall_OutLeg : [49:OTHER_LEG_1] 0,0,0 ,,

 

 

further "1" keypresses were made by caller on port 6, but again no matching paths were specified in module [switch_disconnect_recorded_call], so no action was taken:

 

 

175221.219 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34
...
175221.220 9 16 6 state [switch_disconnect_recorded_call] Number Input 11
175221.221 9 16 6 path {11} not found

 

175226.761 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34
...
175226.761 9 16 6 state [switch_disconnect_recorded_call] Number Input 111
175226.761 9 16 6 path {111} not found

 

175236.289 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34
...
175236.289 9 16 6 state [switch_disconnect_recorded_call] Number Input 1111
175236.289 9 16 6 path {1111} not found

 

175244.739 21 16 6 ev dtmf 1 (41943046,49,0) iConferenceOtherLegLid=101, iConferenceOtherLegIvrDevPort=34
...
175244.739 9 16 6 state [switch_disconnect_recorded_call] Number Input 11111
175244.739 9 16 6 path {11111} not found

 

 

The above DTMF "1" keypresses were passed onto port 34 as "OTHER_LEG_1" events:

 

175212.233 21 101 34 q_scr + evScriptEvent 49 OTHER_LEG_1
175212.233 9 101 34 se OTHER_LEG_1 49 0|0|0 || LineState=LS_XFER_9_WAITENDCALL_DialingSide

and

175226.761 21 101 34 q_scr + evScriptEvent 49 OTHER_LEG_1
175226.762 9 101 34 se OTHER_LEG_1 49 0|0|0 || LineState=LS_XFER_9_WAITENDCALL_DialingSide

etc.

But as no script was running on port 34 those "OTHER_LEG_1" events were just ignored.

 

 

 

The outgoing call on port 34 eventually disconnected about 50 seconds after it was made (the recipeint of that outgoing call hung up) :

 

175248.566 21 101 34 ev CallState GCEV_DISCONNECTED, crn=280005b, iEvent=0 ,16384,0,64, s1:, s2:, s3:]

 

 

and the OTHER_LEG_DISCONNECTED event was passed to port 6, but as no path to match that event was set in module [switch_disconnect_recorded_call], the call on port 6 was just hung up:

 

 

175248.567 9 101 34 send OTHER_LEG_DISCONNECTED to OtherLegLid=16
175248.568 9 16 6 path {OTHER_LEG_DISCONNECTED} not found
175248.568 9 16 6 hanging up 1st leg of call (other leg cause)
175248.568 9 16 6 q_scr + cmdHangupCall 0

 

So it looks like system behaved as expected, and perhaps what is needed here is for module [switch_disconnect_recorded_call] to have the following path added to it::

 

on {1} goto [someModule]

 

 

This would then allow for that module to react to DTMF "1" keypress.

[invoso.com]

Hi,

 

Problem is VG not reacting on OTHER_LEG_1 we don't know why but recognizing as calling line tones?

Each dtmf tone showed above was generated by other_leg not calling one.

 

Problem is we use some dtmf commands on other_leg (agent line) to decide about next process (step) in script and we need to protect script against action by caller side (accidental, unexpected key pressing or receiving dtmf tone)

[SupportTeam]

Did you need port 34 to do something when DTMF "1" was pressed on port 6 ?

 

There was no script started on port 34, so there was no script running on the outgoing leg of the call transfer/bridge (over port 34) that could react to any events that were sent to port 34.

 

If you would like to start a VoiceGuide script on the outgoing leg of the call please use the Script_Goto function on that channel.

More information on Script_Goto: http://www.voiceguide.com/vghelp/source/html/com_script_goto.htm

[invoso.com]

Dear Support Team.

 

Problem is that port 6 not reacting on dtmf signalisation on port 34.

 

VG should recognizing OTHER_LEG_1 on port 6 not (1) when I press 1 on port 34. But VG see 1 from port 34 as 1 on port 6.

 

It looks as VG not recognizing DTMF tones on OTHER_LEG_()

[SupportTeam]

The conversation on that bridged call is being recorded, and the 'voice device' from port 6 is being used to record both sides of the call.

So port 6's 'voice device' can hear both sides of the call and will report any DTMFs hears on either side.

 

If this call:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_1], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

was changed to:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_2], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

then port 34's 'voice device' would report any DTMFs, and the DTMF events would be raised from port 34.

 

 

If you do not want for the 'voice device' that is doing the 2-line recording to report any DTMF tones, but want to be able to detect DTMF tones from separately from each side of the conversation, it may be possible to set that up, but it requires more 'voice device' resources to be added to the system would be a custom solution.

[invoso.com]

You mean, during recorded call first argument vg.Record_2Lines_Start($RV[Conf_LineId_2] determine line to be sensitive for dtmf signaling (or any other activity?)

 

After stop recording line and disconnecting $RV[Conf_LineId_2] line $RV[Conf_LineId_1] will be again sensitive and can receive and acting on client dtmf tones?

[invoso.com]

Sorry, but without call recording is this same.

$RV[Conf_LineId_2] is completely deaf on any dtmf tones!

in case caller pressing 1 log file shows:

 

105615.656 22 40 14 q_scr + evScriptEvent 49 1
105615.656 22 93 31 q_scr + evScriptEvent 49 OTHER_LEG_1

 

when Agent pressing any dtmf tone VG not showing any data in log file.

 

Please fix it ASAP

 

 

v7.5.6058.32621 (02-Aug-16 17:07:21.55)

[SupportTeam]

On our test systems we are seeing that if call recording is in place then the line/device that is recording the conversation sees DTMFs from both parties, and, furthermore, the other line/device continues to see DTMFs pressed on that line as well.

 

And on our test systems both lines raise OTHER_LEG events on the other channel that is bridged.

 

The traces provided at beginning of this thread look as if they are showing DTMFs just being pressed by original caller on the line that is doing the recording (and then the OTHER_LEG is raised on the outgoing leg).

 

Is it possible that the telephone used by the person attached to the outgoing leg of the call (the leg that is not doing the recording) is just not sending any DTMFs or that they are distorted to the point of not being detected by the Dialogic card?

 

In the traces posted at beginning of this thread who is the 'agent'? is 'agent' the person at number 502131658 that was dialed on port 34 ?

 

Who is pressing all these DTMF 1 on that call? The 'agent' or the customer' ? If customer' is pressing all these DTMF 1s then why do they keep on pressing that key? Or is this just a test call and both parties are pressing keys during this connection?

 

That call was recorded into file C:\callrecord\ID20161010_175145_41_6_70320_175200.wav

Can you please post that recording ?

[invoso.com]

As You wish.

ID20161010_175145_41_6_70320_175200.wav

[invoso.com]

Hi,

 

In our system any dtmf tone on Agent side is not detected by VG. If You want I can send You access number and redirect call to other your number to test.

 

Only on caller line VG detecting dtmf signaling (but both sides hear dtmf tone).

[invoso.com]

connection between line 18 and 33

 

dtmf send by line 33 shown on log:

155043.290  22  52  18 ev    dtmf 1   (43516177,49,0) iConferenceOtherLegLid=98, iConferenceOtherLegIvrDevPort=33
155043.290  22  52  18       q_scr +     evScriptEvent 49 1
155043.290  22  98  33       q_scr +     evScriptEvent 49 OTHER_LEG_1
155043.290   9  52  18       q_scr run   evScriptEvent sCode=[1] iActionID=0, crn=0 [0|0|0|0|0][|||||] 00:00:00 max:9|00:00:00.0430025
155043.290   9  52  18       se    1 49  0|0|0  || LineState=LS_GETNBRS_RXDIGITS
155043.290   9  52  18       LsGetNbrsRxDigits lCode=49 lCode2Str=1 sCode=1
155043.290   9  52  18 state [switch_disconnect_recorded_call] Number Input 1
155043.290   9  52  18       path {1} not found
155043.290   9  52  18 t     timer set   7200 sec : EV_TIMEOUT_GOTOMODULE
155043.290   9  52  18       not asr event
155043.290   9  98  33       q_scr run   evScriptEvent sCode=[OTHER_LEG_1] iActionID=0, crn=0 [0|0|0|0|0][|||||] 00:00:00 max:9|00:00:00.0430025
155043.290   9  98  33       se    OTHER_LEG_1 49  0|0|0  || LineState=LS_XFER_9_WAITENDCALL_DialingSide
155043.290   9  98  33       LsXfer_9_WaitEndCall_OutLeg : [49:OTHER_LEG_1] 0,0,0   ,,

Paths in module has option for {OTHER_LEG_1} not for {1} to eliminate caller (client) activity durring conversation.

 

 

it mean VG not identify line which is source of dtmf tone?

[SupportTeam]

ID20161010_175145_41_6_70320_175200.wav recording shows that only the the DTMF 1 key-presses (697Hz+1209Hz) were heard by the system on that connected call.

 

VoiceGuide traces show that those key-presses must have been made by the person that was on port 6 of the call (the caller/client).

 

No sound of any key-presses made by party on port 34 (agent) were heard.

 

If party on port 34 (agent) did press some keys during that call then you should look at the equipment used by the agent and any equipment in between the agent and the Dialogic card in VoiceGuide system. If VoIP/SIP used on any part of that connection then you may want look at that the VoIP/SIP media converting equipment first. Those media converters often clamp DTMF tones and/or do not re-generate them correctly.

 

As a test of what is and isn't heard by the system please do the following:

 

Once call is connected and the recording started have the caller/client party say something and then press key "1", and then have the agent say something and then press key "2".

 

Then post all the VoiceGuide logs and the recording of that conversation. This will give clear picture of what is heard on the line and what events are generated.

 

 

 

A second test could be done by changing

 

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_1], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

to:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_2], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

 

and then again have the client call in, and, once transfer is connected and the recording started, have the caller/client party say something and then press key "1", and then have the agent say something and then press key "2".

This will allow you to compare how the generated events are different depending on which voice device was used for recording.

 

 

 

NB. Using:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_1], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

 

is the right option if you want to be able to identify that the DTMF came from agent leg.

[invoso.com]

Hi,

 

previous test showing no matter option recording or not.

 

VG is not recognizing dtmf signaling side (dtmf signals on $RV[Conf_LineId_2] are same as on $RV[Conf_LineId_1]) and is not recognizing OTHER_LEG_1 on $RV[Conf_LineId_1]

[SupportTeam]

Please perform the outlined tests and post traces and recordings.

 

Please ensure that, as advised, during each of the test calls : first one party speaks and presses a key, and then another party speaks and presses a key.

[invoso.com]

As you wish.

 

1. first call with recording any dtmf from each side viewed on line 1 (1212)

2. second call without recording

 

In case 1. in log file VG see any dtmf activity but in wrong lines (any dtmf on 31 line is identified as dtmf on 1 line)

595 125206.726  5064   3       ev idx=169 : evttype=134(134), crn=0, data=045EEE78(09ED1260), len=4(4) q: 0/9
596 125206.726  5064   3 ev    TDX_CST (CST Event Received)
597 125206.726  5064   3       TDX_CST DE_DIGITS data=50 [2], KeysUsed=0
598 125206.726  5064   2       Event_Dtmf iParam1=0x32 iParam2=0x0
599 125206.726  5064   2 r     dtmf 2

In case 2. in log is hole between

125420.052  17   2   1       ws    do not check iRunWait status as !bCanFireModuleCompletedEvent
125434.073  21   2   1 ev    dtmf 1   (41943122,49,0) iConferenceOtherLegLid=93, iConferenceOtherLegIvrDevPort=31

this dtmf 1 was on client line, but previous I send dtmf 1 and dtmf 2 and no trace about this tones.

 

 

1013_ktTel.zip

ID20161013_124852_41_1_50020.mp3

1013_1250_vgEngine.zip

[SupportTeam]

Please post this recording:

 

C:\callrecord\ID20161013_125118_41_1_50020_125143.wav

 

(the above recording is what was made while the posted 1013_1250_vgEngine trace was running)

 

The posted ID20161013_124852_41_1_50020 recording would have been captured in the vgEngine trace prior to the 1013_1250_vgEngine.txt log.

Please post that prior vgEngine log as well if possible.

[SupportTeam]

Both the recordings:

 

ID20161013_124852
ID20161013_125118

 

appear to be made using this recording command:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_1], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

 

 

Could you please make a test on your system that uses this command instead:

 

strRet = vg.Record_2Lines_Start($RV[Conf_LineId_2], $RV[Conf_LineId_1], $RV[Conf_LineId_2], "C:\callrecord\$RV[session_id]_$RV_HH$RV_NN$RV_SS.wav", "")

 

and post the recording and traces as before.

[SupportTeam]

Right now the traces from your system show that tone detection does not seem to work on Voice device attached to port 31 (dxxxB9C1).

 

On our test systems all ports are detecting DTMFs correctly, so more investigation is required to establish what is happening on your system.

 

Suggest testing this card by making outgoing calls on a number of ports to confirm which ports work and which ports do not:

 

 

 

Can you please use the Dialer to place a call on port 31 (dtiB2T1) to the agent's telephone, and just run any script that accepts any DTMF digit input (eg. the Credit Card Payment demo script)

 

This will test if port dtiB2T1 and the voice device associated with it (dxxxB9C1) actually detects any DTMF tones at all...

 

Probably a good idea to make a number of these calls on different channels on the the seconds E1 trunk - so ports 31-60 and see which ones work and which ones do not.

 

 

Also, instead of making all the agent side outgoing calls go out on ports 31-60, try doing a test where the outgoing agent leg of the call goes out on a port that we can see has detected DTMFs before, eg: port 2

 

So the incoming call is on port 1 (dtiB1T1) and outgoing call is on port 2 (dtiB1T2).

 

We can see that port 2's voice device (dxxxB1C2) can detect DTMF tones - so using that port for the outgoing leg of the call will hopefully result in same performance as we are seeing here on our test systems - where DTMF detection on the outgoing call leg is working fine.

 

 

 

Also, please run this Dialogic application:

 

its_sysinfo.exe

 

and post it's output here.

 

also please post VoiceGuide's Config.xml and ConfigLine.xml configuration files.

 

Once we can see the its_sysinfo.exe system configuration report, and VoiceGuide config files, we can advise if anything there needs to be changed.

[invoso.com]

Completely new server with newest VG (evaluation mode)

 

 

its_sysinfo.zip

ID20161014_132348_43_1_50020.mp3

vgEngine.zip

[SupportTeam]

Could you please post the ktTel trace as well.

[invoso.com]

as you wish.

1014_ktTel.zip

[SupportTeam]

What is playing that female "please hold on line" voice prompt in the ID20161014_132348_43_1_50020 recording?

Is the female prompt played by the system that answered the dialed 502131638 number?

 

The male voice in that recording is the caller/client, right ?

132348.165  23   2   1 ev    CallState GCEV_OFFERED, crn=2800021, iEvent=0 ,2,0,8, s1:502131638|, s2:221623299, s3:           l ! 502131638p  221623299}   ]. build_date: 24-Aug-16 14:02:12.73
132348.166   9   2   1 state <offered> : cid=502131638 , dnis=221623299

132358.471  23   2   1 ev    dtmf 2   

132439.379   9   4   2       ktTel_MakeCall_Enqueue([502131638],DX_PVDENABLE, 60,0,2,502131638,<calltype>DialAndConf</calltype><CallerId>502131638</CallerId><RV>[CDR_user]{ID20161014_132348_43_1_50020}</RV>) call

132446.540  23   4   2 ev    CallState GCEV_CONNECTED,

132446.542   9   2   1       TwoCalls_Bridge 2<=>4  (dtiB1T1<=>dtiB1T2)
132446.542   9   2   1       q_tel +     cmd_PlayStop [0,0,0,0,0][||||]

132446.543   9   2   1 state [Transfer Call fa with CALLER ID] in_leg  1 <=> 2 502131638
132446.543   9   4   2 state [Transfer Call fa with CALLER ID] out_leg 1 <=> 2 502131638

132446.549  30   2   1 rem   Record_2Lines_Start [2,2,4,C:\callrecord\ID20161014_132348_43_1_50020_132446.wav] options=[]

132446.550  23   2   1 ev    PlayEnd 2 821721 [bytes_played:56144:56144, bytes_in_file1009999]

132451.111  23   2   1 ev    dtmf 1
132451.341  23   2   1 ev    dtmf 1
132451.986  23   2   1 ev    dtmf 1
132452.291  23   2   1 ev    dtmf 1
132452.551  23   2   1 ev    dtmf 1

132502.786  23   2   1 ev    dtmf 2
132503.181  23   2   1 ev    dtmf 2
132503.831  23   2   1 ev    dtmf 2
132504.201  23   2   1 ev    dtmf 2

132513.337  23   2   1 ev    dtmf 2   
132515.122  23   2   1 ev    dtmf 2   


132517.292  23   4   2 ev    CallState GCEV_DISCONNECTED, crn=2800023