Taking Back A Dial And Conference Call

[ktruk]

Hi, after making a Dial and Conference call using a dialogic JCT card (but the standard voiceguide tapi version), is it possible to take back the call after the conference has been connected?

 

What I want to do is hangup the 2nd leg only after a timeout and reconnect to the original inbound call to process further. Basically, pass the call on to the voicemail system or run any further modules.

 

I see from the debug trace that each call leg is handled by VG/Tapi and that when you hangup, each leg is terminated separately.

 

So, in a nutshell is it possible to "un-conference" or have the software changed to support this highly use feature?

[SupportTeam]

after making a Dial and Conference call using a dialogic JCT card (but the standard voiceguide tapi version), is it possible to take back the call after the conference has been connected?

Not in the TAPI version.

It is possible in "VG for Dialogic" though.

[ktruk]

I think I've got a work-around solution to this, which works with the v5.2.5029 version you posted recently.

 

I've attached a test script, I wonder if you would be good enough to take a look at it and tell me if there is anything wrong with it.

 

Essentially, the script runs a dial & conference connection. The timeout path runs a VBS script with the following code:

 

'attempt to hangup bridged call here...

iLineID = $RV_LINEID
iNewLine = "$RV[Conf_LineID_2]"

set vg = CreateObject("VoiceGuide.CommandLink")
result = vg.Bridge_Disconnect(iLineID, iNewLine)
vg.Line_Hangup iNewLine

vg.Run_ResultReturn iLineID, "success"
set vg = nothing

 

This disconnects the bridge, then hangs up the second leg. The original call is "retrieved" and the script can continue, say to play a message or pass teh caller to voice-mail.

 

This route is taken if the call is not answered, after a timeout path of say 30-60 secs. If however the call is connected, then pressing 1 bypasses the timeout path and runs an endless loop, which keeps the call open. (Unfortunately, the 1 is heard on both lines, but is can live with this.)

 

Now this works, but is not ideal. I wonder if you could improve this, perhaps allowing the 2nd leg to take the call without the 1 being heard on both lines (which it is) and perhaps having some way to "tread-water" without the cumbersome endless null play module? perhaps allow the "success" path to be taken when the call connects (it doesn't seem to at the moment)

 

One other nuance I have noticed is that an inbound call in to the line that is being bridged (perhaps part-way thru the process) is sometimes connected. I guess this can be eliminated by specifying which lines to use.

 

This script could potentially save me a lot of effort trying to bounce unansered calls back to the IVR system for call recording/message taking. I really would like to see this built-in to the call-transfer process somehow, or perhaps improved in some way.

 

Would you be kind enough to spare a few minutes to mull it over with your dev-team and warn me of any hidden issues or consider improving it in some way?

 

Many thanks!

 

PS: If you are wondering why I need to do this, its because my PBX doesn't queue on transfered calls, but bridging calls does queue, otherwise I would use one of the announced conference options.

[ktruk]

Doh!

TestTransfer.vgs

[SupportTeam]

The only immediate comment would be to not use this path in the [DoNothing] module:

 

on {timeout 0} goto [DoNothing]

 

Specify a long timeout - like this:

 

on {timeout 600} goto [DoNothing]