ktruk Report post Posted 02/09/2006 03:01 PM A couple of weeks back, I was looking at doing TAPI based call transfers (ie: not using the Generate tones method) and had a problem with the operation. Blind transfers to available lines works great. But if the line is busy, then the the current script restarts from the top. Suggestions to create some sort of run-time flag have proved unsuccessful, since a) VG thinks its a new call, so RVs won't work, and writing files via VBS and reading them back creates its own problems. Therefore, I asked for a way to detect for an unavailable line using the TAPI error message that comes back to VG and be able to act upon it, maybe with a path statement {error} or some other workaround that avoids the issue, like a timeout path so that after initiaing the transfer, on {timeout 0} goto [skipTransfer] would avoid the error condition. see: http://voiceguide.com/forums/index.php?showtopic=3600 and: http://voiceguide.com/forums/index.php?showtopic=3601 In response you posted 5.2.5027 and asked if that has cured the problem. I took the new exe and overwrote the existing 5015 and re-ran the app. Again, if the line is free, it works as expected. Again, if the line is busy, VG restarts the current script. So, no change in operation, but I haven't made any path changes or other modifications anywhere. If this new exe has some work-around code, please tell me how it is activated otherwise I conclude that it does not fix the problem. Here is the debug trace of a transfer call being put thru to a busy ext, getting the transfer error, then the script restarting from the top, and trying again to route thru to the busy ext... If there is anything more I need to do, let me know, or maybe you need to revisit the code and check it again. Thanks again for the help - I remain optomistic that we can solve this problem shortly! 143846.76 24 timer clear 143846.77 24 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER 143847.16 24 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER 143847.17 24 ScriptEventCode 9012 iLineState=1900 143847.17 24 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER 143847.18 24 timer set 30 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 143847.19 24 rv replace start: [$RV[GetExt]] 143847.20 24 rv ns [PathSysVoice]{C:\Program Files\VoiceGuide\system\voice\}[PathApp]{C:\Program Files\VoiceGuide\}[PathDataVm]{C:\Program Files\VoiceGuide\data\}[PathVgSys]{C:\Program Files\VoiceGuide\system\}[scriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\}[scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon}[$RV_STARTTIME]{09/02/2006 14:38:36}[$RV_DEVICEID]{24}[$RV_CIDNAME]{}[PathApp]{C:\Program Files\VoiceGuide\}[$RV_CIDNUMBER]{20}[$RV_DNIS]{60}[DNIS]{60}[startMenu]{2}[GetExt]{76}[GetExt_PathTaken]{success} 143847.21 24 rv replace end: [76] 143847.22 24 state [Transfer] Blind Transfer to 76 (TAPI) 143847.23 24 lineBlindTransfer(66118,76,0) in LsXferStart => 66254 143847.37 24 tapi callstate start 143847.38 24 tapi callstate ONHOLD 66118 0 0 143849.55 24 tapi Reply (LineEvReply) err 66254 LINEERR_OPERATIONFAILED [80000048] 143849.56 24 tapi callstate start 143849.57 24 tapi callstate CONNECTED 66118 1 0 143849.59 24 callstate CONNECTED 66118,1,0 143849.59 24 WorkingModeTAPI@Connected=BlindTransfer 143849.59 24 WorkingModeScript@Connected= 143849.61 24 Inband detection not enabled 143849.61 24 StartLoadedVgs at 09/02/2006 14:38:49, script interpretor VgMulti v5.2.5027 0 143849.63 24 rv ns add [scriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\} 143849.63 24 rv ns add [scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon} 143849.64 24 rv lg add [$RV_STARTTIME]{09/02/2006 14:38:49} 143849.65 24 rv lg add [$RV_DEVICEID]{24} 143849.66 24 rv lg add [$RV_CIDNAME]{} 143849.68 24 rv ns add [PathApp]{C:\Program Files\VoiceGuide\} 143849.68 24 rv lg add [$RV_CIDNUMBER]{20} 143849.70 24 rv lg add [$RV_DNIS]{60} 143849.70 24 rv lg add [DNIS]{60} 143849.73 24 timer clear 143849.73 24 state [startMenu] Playing 143849.75 24 tts generate start[To test sound playback and recording, press 1, to test call transfer press 2] 143849.75 24 tts generate wait 143849.77 24 RunModule PLAY end 143849.89 24 tts generate finish. lineCallState=CONNECTED 143849.89 24 amchk test AMdet in TtsToWavFileFinished => False 143849.89 24 state [startMenu] Playing (C:\Program Files\VoiceGuide\temp\tts_24_2.wav) 143849.91 24 play set playid=296495 143849.93 24 PlaySoundStart ok [C:\Program Files\VoiceGuide\temp\tts_24_2.wav] 143849.93 24 timer clear 143856.27 24 play end current play (playid=296495) 143856.27 24 ScriptEventCode 8001 iLineState=1100 143856.29 24 LsPlayMsg EV_PLAY_FINISHED 143856.29 24 eng set timer EV_TIMEOUT_REPLAYMSG time=3 143856.30 24 timer set 3 EV_TIMEOUT_REPLAYMSG 143857.57 24 dtmf 2 (66118,50,2) 143857.57 24 ScriptEventCode 50 iLineState=1101 143857.57 24 LsPlayMsgFinished 2 143857.59 24 rv lg add [startMenu]{2} 143857.60 24 timer clear 143857.61 24 state [GetExt] Number Input 143857.62 24 state [GetExt] Playing (ext.wav) 143857.63 24 play set playid=304216 143857.64 24 PlaySoundStart ok [C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\ext.wav] 143857.64 24 timer clear 143900.23 24 play end current play (playid=304216) 143900.24 24 ScriptEventCode 8001 iLineState=1300 143900.25 24 LsGetNbrsPlayWelcMsg EV_PLAY_FINISHED 143900.26 24 eng set timer EV_TIMEOUT_REPLAYMSG time=5 143900.26 24 timer set 5 EV_TIMEOUT_REPLAYMSG 143901.30 24 dtmf 7 (66118,55,2) 143901.30 24 ScriptEventCode 55 iLineState=1301 143901.31 24 LsGetNbrsRxDigits 7 143901.32 24 state [GetExt] Number Input 7 143901.33 24 path {7} not found 143901.34 24 timer set 20 EV_TIMEOUT_GOTOMODULE 143901.71 24 dtmf 6 (66118,54,2) 143901.72 24 ScriptEventCode 54 iLineState=1301 143901.73 24 LsGetNbrsRxDigits 6 143901.73 24 state [GetExt] Number Input 76 143901.74 24 path {76} not found 143901.75 24 timer set 20 EV_TIMEOUT_GOTOMODULE 143902.12 24 dtmf # (66118,35,2) 143902.13 24 ScriptEventCode 35 iLineState=1301 143902.14 24 LsGetNbrsRxDigits # 143902.15 24 timer clear 143902.16 24 rv lg add [GetExt]{76} 143902.16 24 path {76} not found 143902.17 24 rv ns add [GetExt_PathTaken]{success} 143902.18 24 timer clear 143902.19 24 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER 143902.58 24 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER 143902.58 24 ScriptEventCode 9012 iLineState=1900 143902.59 24 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER 143902.60 24 timer set 30 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 143902.61 24 rv replace start: [$RV[GetExt]] 143902.62 24 rv ns [PathSysVoice]{C:\Program Files\VoiceGuide\system\voice\}[PathApp]{C:\Program Files\VoiceGuide\}[PathDataVm]{C:\Program Files\VoiceGuide\data\}[PathVgSys]{C:\Program Files\VoiceGuide\system\}[scriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\}[scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon}[$RV_STARTTIME]{09/02/2006 14:38:36}[$RV_DEVICEID]{24}[$RV_CIDNAME]{}[PathApp]{C:\Program Files\VoiceGuide\}[$RV_CIDNUMBER]{20}[$RV_DNIS]{60}[DNIS]{60}[startMenu]{2}[GetExt]{76}[GetExt_PathTaken]{success} ScriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\}[scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon}[$RV_STARTTIME]{09/02/2006 14:38:49}[$RV_DEVICEID]{24}[$RV_CIDNAME]{}[PathApp]{C:\Program Files\VoiceGuide\}[$RV_CIDNUMBER]{20}[$RV_DNIS]{60}[DNIS]{60}[startMenu]{2}[GetExt]{76}[GetExt_PathTaken]{success} 143902.63 24 rv replace end: [76] 143902.64 24 state [Transfer] Blind Transfer to 76 (TAPI) 143902.65 24 lineBlindTransfer(66118,76,0) in LsXferStart => 66289 143902.79 24 tapi callstate start 143902.80 24 tapi callstate ONHOLD 66118 0 0 143904.98 24 tapi Reply (LineEvReply) err 66289 LINEERR_OPERATIONFAILED [80000048] 143904.98 24 tapi callstate start 143904.00 24 tapi callstate CONNECTED 66118 1 0 143905.01 24 callstate CONNECTED 66118,1,0 143905.02 24 WorkingModeTAPI@Connected=BlindTransfer 143905.03 24 WorkingModeScript@Connected= 143905.04 24 Inband detection not enabled 143905.05 24 StartLoadedVgs at 09/02/2006 14:39:05, script interpretor VgMulti v5.2.5027 0 143905.05 24 rv ns add [scriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\} 143905.07 24 rv ns add [scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon} 143905.07 24 rv lg add [$RV_STARTTIME]{09/02/2006 14:39:05} 143905.09 24 rv lg add [$RV_DEVICEID]{24} 143905.10 24 rv lg add [$RV_CIDNAME]{} 143905.11 24 rv ns add [PathApp]{C:\Program Files\VoiceGuide\} 143905.12 24 rv lg add [$RV_CIDNUMBER]{20} 143905.13 24 rv lg add [$RV_DNIS]{60} 143905.14 24 rv lg add [DNIS]{60} 143905.15 24 timer clear Share this post Link to post
SupportTeam Report post Posted 02/09/2006 11:50 PM to create some sort of run-time flag have proved unsuccessful, since a) VG thinks its a new call, so RVs won't work. The only other option to get this TAPI based system working would be to save the transfer state in a database and check against that at the beginning of the script. If is exactly these types of problems with the various TAPI drivers out there that results in us recommending that Dialogic cards be used for systems where call transfers are required. None of these issues exit on Dialogic based systems. Share this post Link to post
ktruk Report post Posted 02/10/2006 10:22 AM The problem with maintaining some system independent flag is that you cannot ensure that its consistent. Most of the time it will work to some limited extent, but even if you trap the script restart, you lose all the other essential RVs that control the call or hold data to that point, so the call becomes either useless, or there is a huge amount of work to store and recover the RV data (imagine getting credit-card data, then being put thru to sales, it fails, so you lose all the account and credit-card data). Hardly a great solution. Thing is, I think you are shirking your responsibility a little here. Clearly there is a detectable error condition, which should be reported as some sort of TAPI event and all that is needed is to interpret this within the context of call-transfer module, so, that if you get the error, and you're in a call-transfer operation, you do something graceful about it, like exit using the {false} path. Restarting the script from the top is not a graceful exit! As for Dialogic - it is NOT a solution as I need a BRI solution and Dialogic don't have a solution in the BRI space. I realise you cannot believe that we customers have limited budgets, which dont run to PRI, but take it from me, its true. As soon as Dialogic bring back a BRI solution I promise you I will buy it, but for now its not an option. 143902.65 24 lineBlindTransfer(66118,76,0) in LsXferStart => 66289 143902.79 24 tapi callstate start 143902.80 24 tapi callstate ONHOLD 66118 0 0 143904.98 24 tapi Reply (LineEvReply) err 66289 LINEERR_OPERATIONFAILED [80000048] Is there nothing you can do to trap this situation or come up with some workaround? c'mon fellas, I know you can do it...one way or another! Share this post Link to post
SupportTeam Report post Posted 02/10/2006 11:36 PM or there is a huge amount of work to store and recover the RV data You can use the COM function RvGet_All which should return all RVs defined on line, save that in a database and then afterwards use COM command RvSet_RvList to restore all the RVs retrieved from the database. The application's code probably could be changed around to handle what is happening on this system in a more graceful way, perhaps even the app may be made to work as you outline - if you'd like to have this work carried out please send an email to sales@voiceguide.com for a quote on getting this work done. Share this post Link to post
ktruk Report post Posted 02/13/2006 10:34 AM You can use the COM function RvGet_All which should return all RVs defined on line, save that in a database and then afterwards use COM command RvSet_RvList to restore all the RVs retrieved from the database. Yes, this will help, but it doesn't solve the problem. However, you also have to decide if you are handling a new call in or working with an existing call. I think you can only time the restart so that you don't confuse new calls with restarted calls. Using CLIP is okay, but not all calls have clip. Bottom line is that this kludge is horrible and it looks like I'm going to have to pay you to fix your code. Share this post Link to post
SupportTeam Report post Posted 02/13/2006 09:15 PM A lot of the TPAI hardware out there just does not support recovery from transfers to busy/disconnected/etc number call transfers, with some terminating the call on busy being encountered and some getting themselves into a state where ending the call is the only option. (This is the main reason why we say that for system doing call transfers Dialogic cards should be used - Dialogic cards allow full control over the transfers and recovery, and VG for Dialogic software has not problems with taking back calls on which busy/etc has been detected) From the devices we’ve seen that do react to a busy number in some workable way they all have slightly different ways of handling this situation. Supporting call recovery on busy/disconnected/etc pretty much means coding for individual devices. In your case it looks like we are going to be trying to add code to handle the Eicon card's TAPI driver's reactions... Share this post Link to post
ktruk Report post Posted 02/13/2006 10:29 PM I think you are just guessing at the quality of Eicon's product, afterall, we are not talking about cheap voice-modems, but world-class telephony hardware from a well known and respected global manufacturer. I can understand your hesitation in taking on a new hardware platform, but I think its a viable and attractive alternative to dialogic. Based on your previous answers to my numerable posts about this problem, I am led to believe that Vg is incapable of reacting to some situations (like TAPI error conditions) and other limitations, so to blame the Eicon drivers without testing them is a little premature. I am told that Eicon provide very comprehensive TAPI call handling in their hardware/drivers. Their current product is widely supported by a number of third-party call-centre packages which offer comprehesive call transfer and conferencing solutions. Their hardware is also natively supported by a number of other CTI/IVR applications and systems. They have a comprehensively consolidated API which includes support for CAPI and TAPI across their entire product offering from single-line BRI to quad-span T1/E1 PRI cards, all, I'm told, will work with the same drivers or API calls. (I gather like GlobalCall is supposed to do). I accept that no product is perfect and certainly I have experienced problems with the quality of their claimed TAPI support with their first generation v1 cards, ie: they don't work (as previously posted). I appreciate that your development is centered on Dialogic hardware, but Dialogic do not offer me a BRI solution. (I will raise another topic to explore a possible E1 solution with you later). If they did, as stated previously I would buy it. I will cooperate any way I can to derive a solution here, including escalating any concerns or issues to Eicon if that will help. Eicon appear to be a 'switched on' company and I am sure that their local office would be very willing to work with you. As for the native VG-for-dialogic-patch, judging by the number of releases since I last tried it 6 months ago, would suggest that it may be getting closer to being a solution, but it certainly did not work any better than the TAPI Vg with respect to call-transfers back then and the dual wav/vox sound files are an irritation. I suppose the line we could take is: lets give it a go, if it works or can be made to work with a reasonable effort/cost, then everybodies happy! If its a pain, then I guess we drop the idea and come up another solution. If you are absolutely sure this is a complete waste of time, I will leave it at that and save us both the trouble. Share this post Link to post
SupportTeam Report post Posted 02/13/2006 11:33 PM The traces you supplied are being looked at now to ascertain how much work would be required to handle the busy/disconnected situations. Once that is done we will contact you be email. Share this post Link to post
ktruk Report post Posted 02/21/2006 07:43 PM Any news on this please, its been some time. I also asked for advice on going down a PRI/E1 route but still connecting to a local PBX fro call distribution. I would appreciate some feedback on both points please. Many thanks ! Share this post Link to post
SupportTeam Report post Posted 02/21/2006 10:29 PM Please update system with attached exe and then post traces of a successful transfer and of a failed/rejected transfer. VgMulti_5.2.5034.zip Share this post Link to post
ktruk Report post Posted 02/23/2006 11:46 AM Please find attached traces as requested, using the patch posted above. In the zip is the VGS used and the VG.INI file, just in case this is of some use. Two calls were made: 1st, succesful to a free-line, 2nd, failed with TAPI error code 8000048, to a busy line, VG restarted the current script exactly as previous posts describe. As can be seen in the VGS, only a simple call-transfer module is used. Many days have passed since I first raised this important issue. I would really appreciate your best effort on this problem. Many thanks. xfer_2.zip Share this post Link to post
SupportTeam Report post Posted 02/24/2006 03:24 AM OK, lets try this one more time. Please run tests as before with this new version. VgMulti_5.2.5035.zip Share this post Link to post
ktruk Report post Posted 02/24/2006 09:45 AM Thanks, I will get on to it straight away - is there anything I should do to enable any features? like adding {fail} paths or other settings? Share this post Link to post
SupportTeam Report post Posted 02/24/2006 10:44 AM Nothing is needed to enable it, but it's the "fail" path that will be taken if the call transfer fails. If the transfer fails and there is no "fail" path then VG should just hangup the call. Share this post Link to post
ktruk Report post Posted 02/24/2006 01:55 PM Tests completed and full logs attached. Exact same results. If target line available, line rings, call completes no problem. If target line "busy" then get same TAPI error as highlighted below and script restarts from beginning, just as reported a few weeks ago. The same test script was used as attached in previous zip file, again just the VGMULTI.EXE changed. There has to be something seriously, fundamentally, wrong with your code if you can't react to standard TAPI error code - Is there nothing else we can do to work around this problem? This is driving me absolutely nuts. Here is a snippet of the vgm log: 133803.59 13 rv replace end: [76] 133803.59 13 state [Transfer] Blind Transfer to 76 (TAPI) 133803.60 13 lineBlindTransfer(65608,76,0) in LsXferStart => 65921 133803.60 13 tapi callstate start 133803.60 13 tapi callstate ONHOLD 65608 0 0 133805.74 13 tapi Reply (LineEvReply) err 65921 LINEERR_OPERATIONFAILED [80000048] LineCallState=ONHOLD 133805.76 13 tapi callstate start 133805.76 13 tapi callstate CONNECTED 65608 1 0 133805.76 13 callstate CONNECTED 65608,1,0 133805.76 13 WorkingModeTAPI@Connected=BlindTransfer 133805.76 13 WorkingModeScript@Connected= 133805.77 13 Inband detection not enabled 133805.77 13 StartLoadedVgs at 24/02/2006 13:38:05, script interpretor VgMulti v5.2.5035 7 133805.77 13 rv ns add [scriptsPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\} 133805.77 13 rv ns add [scriptPath]{C:\Program Files\VoiceGuide\Scripts\KTR\Eicon} 133805.77 13 rv lg add [$RV_STARTTIME]{24/02/2006 13:38:05} 133805.77 13 rv lg add [$RV_DEVICEID]{13} 133805.77 13 rv lg add [$RV_CIDNAME]{} 133805.77 13 rv ns add [PathApp]{C:\Program Files\VoiceGuide\} 133805.77 13 rv lg add [$RV_CIDNUMBER]{43} 133805.77 13 rv lg add [$RV_DNIS]{60} 133805.77 13 rv lg add [DNIS]{60} log.zip Share this post Link to post
SupportTeam Report post Posted 02/24/2006 11:15 PM Sometimes it takes a few attempts if we do not have a test system here to replicate your setup - which in case of the Eicon BRI card we do not. Please try attached .exe VgMulti_5.2.5036.zip Share this post Link to post
ktruk Report post Posted 02/26/2006 02:14 PM NEARLY THERE !! Okay, this latest patch is nearly working: Attached are the complete logs from 3 calls. 1. Working call transfer to a free line. Works as expected and as in previous versions 2. Call transfer to busy line, no fail path defined Works as desired, in as much it connects the call to a Busy signal, then hangs up the line (without the script restarting) leaving the caller listening to busy signal. Excellent! 3. Call transfer to busy line with a {Fail} path This nearly works, it seems to take the busy path (hoorray!!) but then the next step is interrupted by the script restarting, before the next module really 'kicks-in'. I suspect some timer needs setting/clearing. The tests above were done with the same test script as previously, except that a play-module was added with a fail-path link from the call-transfer module, to test the path handling. If you are looking to spotting the general line error code 8000048 perhaps you could also incorporate the 8000005 code (LINEERR-CALLUNAVAIL), as the ComISDN driver seems to issue this if it can't find a free line, which is like the equivalent of a busy signal. I know this is something different, but I just found this and perhaps it might be easier to add this now rather than later. If its a pain, lets just get the 8000048 code handled first! All three calls detailed in attached end-2-end logs. I reckon you are very close to fixing this now and I am very grateful. Perhaps a little more work will get this nut cracked, hopefully. I didn't realise you didn't have an Eicon board to setup/test, would it help if I helped to get you one? Thanks again. log.zip Share this post Link to post
SupportTeam Report post Posted 02/27/2006 01:49 AM Attached .exe should handle the "fail" path better. We would probably not be setting up a test station just for Eicon BRI as very few license holders are using Eicon BRI cards, and we get very few enquiries relating to Eicon. We have quite a few testing stations set up (majority of them using Dialogic cards) and the test station configurations reflect what the customers are using. VgMulti_5.2.5039.zip Share this post Link to post
ktruk Report post Posted 02/27/2006 10:19 AM Many thanks!!! This is much better. A quick test now shows that the {fail] path is now taken and the module/script does continue and completes as desired. However, as mentioned previously, I am using ComISDN to transfer the call, and due to the way our PBX works, it does a line-interconnect to transfer the call. This works, provided the next line is free. If it fails to find a free line to use, it causes a TAPI error: "LINEERR_CALLUNAVAIL [80000005]" as mentioned previously. I have asked ComISDN to address this, but I wonder if you could try to handle this error? My test script is as before, with 2 extra modules. It just runs a wav play via the {fail} path, followed by a TTS module which can take a '1' to go back to the script entry point (replay the script). The debug traces appear to show the same sequence of events leading up to the error, but when the transfer fails, it deallocates the call, then it takes the {fail} path. Then after several seconds it plays the WAV, then it doesn't complete the TTS play module that follows. The trace shows 'no call on the line' and the line is held open, but nothing happens until you hangup. Maybe this is a very simple thing to do? Anyway, here is a snippet from the attached log: (I've snipped out any 'line 13' lines, just leaving the 'line14' traces... 094721.53 14 state [Transfer] Blind Transfer to 76 (TAPI) 094721.53 14 lineBlindTransfer(66480,76,0) in LsXferStart => 65745 094721.53 14 tapi Reply (LineEvReply) err 65745 LINEERR_CALLUNAVAIL [80000005] LineCallState=CONNECTED ... 094751.61 14 timer fired EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 094751.61 14 ScriptEventCode 9021 iLineState=1900 094751.61 14 LsXferStart EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 094751.61 14 Transfer timed out 094751.61 14 lineDrop(0) in DropConsultingCall_Fail => LINEERR_INVALCALLHANDLE [80000018] 094751.61 14 lineDeallocateCall(0) => LINEERR_INVALCALLHANDLE [80000018] 094751.61 14 timer clear 094751.61 14 state [xFailed] Playing 094751.61 14 state [xFailed] Playing (done.wav) 094751.61 14 play set playid=957204 094751.63 14 PlaySoundStart ok [C:\Program Files\VoiceGuide\Scripts\KTR\Eicon\done.wav] 094751.63 14 timer clear 094751.63 14 RunModule PLAY end 094751.66 -1 dial start any summary:|13:hc>0|14:rdy=0|15:idx=0|16:idx=0|17:idx=0|18:idx=0|19:idx=0|20:idx=0| 094753.61 0 sys cleanup Start 094753.61 0 sys cleanup End 094758.27 14 play end current play (playid=957204) 094758.27 14 ScriptEventCode 8001 iLineState=1100 094758.28 14 LsPlayMsg EV_PLAY_FINISHED 094758.28 14 timer set 10 EV_TIMEOUT_HANGUP 094758.28 14 timer set 0 EV_TIMEOUT_GOTOMODULE 094758.28 14 ScriptEventCode 9002 iLineState=1101 094758.28 14 LsPlayMsgFinished EV_TIMEOUT_GOTOMODULE 094758.28 14 rv lg add [xFailed]{timeout} 094758.28 14 timer clear 094758.28 14 state [NxtModule] Playing 094758.28 14 tts generate start[This shows that the script does continue. Press 1 to go to start of press hash to exit] 094758.28 14 tts generate wait 094758.28 14 RunModule PLAY end 094758.38 14 tts generate finish. lineCallState=CONNECTED 094758.38 14 amchk test AMdet in TtsToWavFileFinished => False 094758.38 14 tts play abort as no call on line The attached logs detail a call on one line, while a second call uses the second b-channel. I am pretty confident that addressing this issue will close off this call-transfer problem. Many thanks again. PS: I understand your test-bench issues. Thanks for your patience. log.zip Share this post Link to post
SupportTeam Report post Posted 02/28/2006 05:07 AM OK, let's see if this .exe handles ComISDN's LINEERR_CALLUNAVAIL error. Please post traces as usual. VgMulti_5.2.5042.zip Share this post Link to post
ktruk Report post Posted 02/28/2006 10:51 AM Good news: WHOOPEE! I think its all working! 1. The calls are transferred to free extentions. 2. Busy extentions take the {fail} path. 3. Unavailable lines take the {LINEERR_CALLUNAVAIL} path (yes, I spotted this!) Just for info: I've attached the logs of 4 calls, 1: normally connected call, 2: Call to busy, 3: Line unavailable, 4: normally connected after busy becomes free. Thank you so much. Please pass on my grateful thanks to your patient programmers. Tim @ KTRUK log.zip Share this post Link to post
SupportTeam Report post Posted 02/28/2006 09:17 PM Good to hear it's all working! Share this post Link to post