TAPI Call Transfer on BRI ISDN and Eicon BRI card

[ktruk]

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

[SupportTeam]

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.

[ktruk]

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!

[SupportTeam]

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.

[ktruk]

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.

[SupportTeam]

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...

[ktruk]

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.

[SupportTeam]

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.

[ktruk]

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 !

[SupportTeam]

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

[ktruk]

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

[SupportTeam]

OK, lets try this one more time.

Please run tests as before with this new version.

VgMulti_5.2.5035.zip

[ktruk]

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?

[SupportTeam]

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.

[ktruk]

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

[SupportTeam]

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

[ktruk]

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

[SupportTeam]

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

[ktruk]

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

[SupportTeam]

OK, let's see if this .exe handles ComISDN's LINEERR_CALLUNAVAIL error.

 

Please post traces as usual.

VgMulti_5.2.5042.zip

[ktruk]

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

[SupportTeam]

Good to hear it's all working!