ktruk Report post Posted 01/17/2006 08:09 PM Hi, I am using the latest 5.2.5015 VG in a TAPI call transfer mode to do blindtransfers behind an ISDN PBX, but have some issues: 1. When the call is transferred to an idle extention, the transfer succeeds, but shortly after when VG initialises the line, a TAPI error is reported, but the line returns to a ready condition and will accept further calls. 2. If the transfer fails (ie: the ext is busy) a different TAPI error code is reported and the script is restarted from the beginning. If I add a fail (or success) path, it is ignored. I wonder if it would be possible to add/fix the "{fail}" path or return the error code as an "{error xx}", so that the error could be acted upon to redirect the module path? Here are some debug traces to illustrate what I mean: 141526.51 16 timer clear 141526.52 16 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER 141526.83 16 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER 141526.84 16 ScriptEventCode 9012 iLineState=1900 141526.84 16 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER 141526.85 16 timer set 5 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 141526.86 16 state [TransferCall] Blind Transfer to 150 (TAPI) 141526.87 16 lineBlindTransfer(65828,150,0) in LsXferStart => 65572 141526.99 16 devstate NUMCALLS 0 0 141526.99 16 devstate OTHER 0 0 141527.76 16 tapi Reply (LineEvReply) ok 65572 0 <transfer worked!! 141527.78 16 tapi callstate start 141527.79 16 tapi callstate DISCONNECTED 65828 1 0 141527.79 16 ScriptEventCode 9250 iLineState=1900 141527.80 16 LsXferStart EV_REMOTEPARTY_DISCONNECT 141527.81 16 rv lg add [Hangup Time]{17/01/2006 14:15:27} 141527.82 16 state Hanging up call... 141527.83 16 RecSoundStop ok 141527.84 16 PlaySoundStop err=0 141527.85 16 timer set 2 EV_TIMEOUT_WAITFORIDLEAFTERLINEDROP 141527.86 16 fnHangupCall end 141527.87 16 devstate NUMCALLS 0 0 141527.88 16 devstate OTHER 0 0 141527.89 16 tapi callstate start 141527.90 16 tapi callstate IDLE 65828 0 0 141527.91 16 WorkingMode@Idle= 141527.92 16 timer clear 141527.93 16 timer set 1 EV_TIMEOUT_TIMETOREINITLINE 141527.94 16 devstate NUMCALLS 0 0 141527.95 16 devstate OTHER 0 0 141527.96 16 tapi Reply (LineEvReply) err 65589 LINEERR_INVALCALLSTATE [8000001C] 141528.88 16 timer fired EV_TIMEOUT_TIMETOREINITLINE 141528.88 16 ScriptEventCode 9008 iLineState=900 141528.89 16 LsAwaitingCalls EV_TIMEOUT_TIMETOREINITLINE 141528.89 16 ReinitTelephony due to IDLE 141528.91 16 tapic lineDeallocateCall(MainCall:65828) 0 141528.93 16 lineOpen(16)=> 141528.93 16 state Waiting for a call... 141528.93 16 LineHandle=65657 141528.95 16 amchk set AMdet=False in Reinit@idle 141528.95 16 timer set 3 EV_TIMEOUT_ATERIDLE_ALLOWOUT 141529.62 0 dial start any summary:|16:rdy=0|17:idx=0|18:idx=0|19:idx=0|20:idx=0|21:idx=0|22:idx=0| 141531.97 16 timer fired EV_TIMEOUT_ATERIDLE_ALLOWOUT 141531.98 16 ScriptEventCode 9013 iLineState=900 141532.73 0 dial start any summary:|16:idx=0|17:idx=0|18:idx=0|19:idx=0|20:idx=0|21:idx=0|22:idx=0| Looking at the above, I wonder if the line error is due to the line still ringing at the called extention? As mentioned, the transfer works, the error is just annoying, but can be ignored. The next case is a failed transfer, followed by a restart of the whole script: 143824.63 16 timer clear 143824.68 16 RunModule PLAY end 143827.68 16 dtmf 1 (65744,49,2) 143827.71 16 ScriptEventCode 49 iLineState=1100 143827.77 16 LsPlayMsg 1 143827.82 16 PlaySoundStop err=0 143827.88 16 rv lg add [Welcome]{1} 143827.93 16 timer clear 143827.99 16 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER 143828.35 16 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER 143828.37 16 ScriptEventCode 9012 iLineState=1900 143828.43 16 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER 143828.48 16 timer set 5 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 143828.54 16 state [TransferCall] Blind Transfer to 150 (TAPI) 143828.60 16 lineBlindTransfer(65744,150,0) in LsXferStart => 66086 143828.73 16 devstate NUMCALLS 0 0 143828.76 16 devstate OTHER 0 0 143830.98 16 tapi Reply (LineEvReply) err 66086 LINEERR_OPERATIONFAILED [80000048] <<<Line busy so get TAPI error, then next, script restarts... 143831.07 16 tapi callstate start 143831.09 16 tapi callstate CONNECTED 65744 1 0 143831.15 16 callstate CONNECTED 65744,1,0 143831.21 16 WorkingModeTAPI@Connected=BlindTransfer 143831.27 16 WorkingModeScript@Connected= 143831.32 16 Inband detection not enabled 143831.38 16 StartLoadedVgs at 17/01/2006 14:38:31, script interpretor VgMulti v5.2.5015 7 143831.43 16 rv ns add [scriptsPath]{C:\Program Files\VoiceGuide\Scripts\Internet Portal\} 143831.49 16 rv ns add [scriptPath]{C:\Program Files\VoiceGuide\Scripts\Internet Portal} 143831.55 16 rv lg add [$RV_STARTTIME]{17/01/2006 14:38:31} 143831.60 16 rv lg add [$RV_DEVICEID]{16} 143831.66 16 rv lg add [$RV_CIDNAME]{} 143831.72 16 rv ns add [PathApp]{C:\Program Files\VoiceGuide\} 143831.77 16 rv lg add [$RV_CIDNUMBER]{030} 143831.83 16 rv lg add [$RV_DNIS]{60} 143831.88 16 rv lg add [DNIS]{60} 143831.94 16 devstate NUMCALLS 0 0 143832.00 16 devstate OTHER 0 0 143832.09 16 timer clear 143832.13 16 state [Welcome] Playing So, just to recap, I want to avoid the script restart, and ideally, act on the fail/error code... on {fail} goto [xxx] or, take last part of error code, "80000048" as a hex word/byte? on {error 48} goto [xxx] Would it be possible to fix the above? PS: I have to use the TAPI mode of call transfer, I cannot use "generate" mode. Share this post Link to post
SupportTeam Report post Posted 01/17/2006 10:06 PM VG for Dialogic lets you act on these sort of errors, but the TAPI version of VG cannot trigger on error messages like the ones you mention. 1. When the call is transferred to an idle extention, the transfer succeeds, but shortly after when VG initialises the line, a TAPI error is reported, but the line returns to a ready condition and will accept further calls. So does this error reported by the drives affect the operation in any way? From what I understand here the transfer has succeeded and then the line awaits a new call - so functionally all is OK? 2. If the transfer fails (ie: the ext is busy) a different TAPI error code is reported and the script is restarted from the beginning. If I add a fail (or success) path, it is ignored. The TAPI driver here returns CONNECTED as well - which is what to VG indicates the start of a new call... You could workaround this by setting a flag somewhere (Database?) that would indicate that the script is about to do a transfer and then at start of script check if the flag is set - if it is then play a 'transfer failed' message. (flag would need to be cleared in an 'after hangup' script). Share this post Link to post
ktruk Report post Posted 01/18/2006 09:19 AM Avoiding the script restart is the priority. Taking the caller back to the start of a 30 module script is a real ugly pain. I will try the flag idea, but have to say I don't like to put in code-frigs to work around product deficiencies, but I will give it a go and let you know if it works Seems to me that hooking into the "on {fail}" path is the proper thing to do - and I would really prefer to do it this way, as its consistent with VoiceGuide operation generally. I am not using Dialogic hardware at the moment for this app, so VG4Dialogic is not an option. Thanks for the response. Share this post Link to post
ktruk Report post Posted 01/18/2006 10:08 AM The TAPI driver here returns CONNECTED as well - which is what to VG indicates the start of a new call... Actually, since you mentioned that the call had been connected, I think this is correct... since the PABX supports queuing on busy, I remember getting a queuing message briefly for about 2.5 seconds. Looking at the trace (2nd one listed above) there is about a 2.5 second delay between the lineBlindTransfer @ 143828.60 and the script restarting @ 143831.21. I guess the script restart is what reinits the line causing the queuing to be abandoned. My utopian heaven would be to avoid the script restart after connecting and the line remains queued (perhaps taking an "on {fail}" or "on {success}" path) then I would finally get what I really want. If the TAPI drivers return an "CONNECTED" state (or an LINEERR_* state), surely this is detectable within VG as part of the general path management? The way this should work is pretty obvious, 1. do the transfer, 2. wait for/act upon Tapi event status message, take path (success/fail), allow script to take a success path to a module that waits for x seconds (queing time) or take a fail path to some other module that plays a message. Perhaps this is more of a "conferancing" operation? I know that TAPI supports conferancing, it it possible to have VG support this type of TAPI function in the call transfer module? If an extra-payment custom mod is possible, let me know. Just a couple of points on your previous response: the TAPI version of VG cannot trigger on error messages like the ones you mention.I find it really hard to appreciate why these states cannot be detected and acted upon, when you are reporting them in the trace! So does this error reported by the drives affect the operation in any way? No, it works, but the error condition is annoying, but I will live with it. Finally, please read my previous posty regarding this issue above - many thanks again - tim. Share this post Link to post
SupportTeam Report post Posted 01/19/2006 04:36 AM If the TAPI drivers return an "CONNECTED" state (or an LINEERR_* state), surely this is detectable within VG as part of the general path management? If could be, but the TAPI version of VG currently does not pass the ERROR events and linestate events (CONNECTED etc) to the script interpreter, so the script interpreter cannot act on these (and does not even know they happened). The way that VG (TAPI) acts upon receiving the CONNECTED event is built-in, resulting in a script being started as you can see on your system. If an extra-payment custom mod is possible, let me know. Guess it would be, but the modification would not be trivial. You may want to send an email to sales@voiceguide.com to see what the quote would be. I find it really hard to appreciate why these states cannot be detected and acted upon, when you are reporting them in the trace! Just not the way it's programmed right now. Possible to change it but the change may not be that easy... Share this post Link to post
ktruk Report post Posted 01/19/2006 10:41 PM Firstly, having considered the situation, I really think that the VG script restarting is a bug in the call-transfer code. I can think of no reason why VG should restart the script as opposed to just hanging up or following the {fail} path. You say that VG cannot respond to TAPI error or status conditions, but clearly it is responding, since VG restarts when it encounters this "error" and does not restart when it doesn't!! Therefore, something is happening here, wouldn't you agree? I guess you are constrained by what the TapiWrap.ocx can or cannot do for you! Can I clarify some specific details here, as it may help! Firstly, I am using the TAPI version of VG, AND using the TAPI transfer mode "LineBlindTransfer" - not the lineGenerate "Generate" call transfer method. Now, I asked for this TAPI transfer mode to be fixed/implemented last December that resulted in 5.2.5015 to be released, specifically to support this method of call transfer. I now suspect that possibly this TAPI modification may be slightly flawed, as the normal "generate" method (as far as I can recall, but am unable to test) does not restart the current script if a transfer fails. Because this code is "new" and perhaps a little untested, I think it is worth double checking it - the normal "generate" code is probably okay, its just my modified bit that needs looking at! Perhaps you can refer this problem to the programmers for a second look, just in case something has been overlooked in the rush to provide a quick fix last month? And finally, since the error effectively aborts a "successful" connection, perhaps the programmers could provide some form of "rough" bypass for the error, that either tricks VG into skipping the error or at least not abandoning the call/restarting. One idea may be putting a "on {timeout 0} goto [xxx]" (or similar) in the call transfer paths section so as soon as the transfer is initiated, the timeout path is taken regardless of the outcome of the transfer. (Perhaps force a "success" codition and take the success path?) What do you think? Kindly talk it over with the programmers, together I hope we can come up with something - Thanks - Tim PS: I will persevere with the restart flag as suggested, but so far, I haven't got this to work. Share this post Link to post