Dialout And Conference

[Guest miva]

Using VG7 and the dialout and conference module (blind) to connect callers we've noted that when the outgoing leg hangs up, the incoming leg and VG stay connected indefinetly. This can be an issue as many people who dial in using mobile phones don't hang up the call if the other party hangs up, they assume the call will automatically disconnect.

 

However if the incoming caller hangs up it works fine and clears down both legs of the call, but not if only the outgoing leg hangs up.

 

Is this standard or could there be a problem? If it's a problem we'll post the log files, but if its standard, is there a way around it?

 

Thanks for your help.

[SupportTeam]

There could be a number of reasons why the original incoming call is not automatically ended when the conference call completes.

Not having the original caller automatically disconnect is actually the desired behavior on many installed systems - this allows for the original caller to be taken through more IVR scripts (eg. for agent rating) or let them make another conference etc.

 

So basically whether the original call is hung up on or not usually depends on the script used.

 

as many people who dial in using mobile phones don't hang up the call if the other party hangs up, they assume the call will automatically disconnect.

They just put their phone in their pocket instead of pressing the 'hangup' button on their phone, right?

(guess that this would not be affecting flip-top or slide-open phones)

 

Please post traces (.ZIPed) capturing the conference call (both vgEngine and ktTel) and post the script that you are using and we can then see what is happening and how to change the script to have original caller hangup as well.

[Guest miva]

They just put their phone in their pocket instead of pressing the 'hangup' button on their phone, right?

(guess that this would not be affecting flip-top or slide-open phones)

 

Yes exactly. Occasionally people stay connected without realizing until our timer disconnects the call. We'd like a way to drop the call if either leg detects hangup.

 

Please find logs attached.

Logs.zip

[SupportTeam]

It looks like this script after conferencing the two calls together proceeds to run some Evaluate Expression, Database Query and Run VBScript modules, setup in some sort of a loop.

 

If the script is doing such processing it must listen out for events signaling end of call on another line. If the script stayed in the Transfer Call module then the Transfer Call module takes care of all this, but as this script is doing customized processing during the call then the script needs to be setup to handle end of conference events.

 

One way to do this is to handle the call disconnect/idle events. The events to look out for are:

 

OTHER_LEG_DISCONNECTED

OTHER_LEG_IDLE

 

You can see these events firing if you look in the vgEngine trace.

 

So you need a path like this:

 

on {OTHER_LEG_IDLE} goto [some module title]

 

but that path needs to be in all the modules in your loop, as you do not know in which module of thr loop the script will be in when the event arrives. Also if you do database updates in the lop (and it looks like you do) then using event paths is not a good idea. They would interrupt the database query.

 

So these approaches are better:

 

Check for value of $RV[TsRoutedTo] in the loop. The value of $RV[TsRoutedTo] will be an integer if call is conferenced, and will be set to an empty string if call is no longer conferenced (and call will not be conferenced if the other leg hangs up.

 

You can see in vgEngine trace when the various $RVs are set and cleared.

 

 

Another way would be to have a VBScript module in your loop check for status of the other line, using the COM function:

 

set vg = CreateObject("vgServices.CommandLink")

sOtherLineCallState = vg.Line_State_CallState($RV[Conf_LineId_1])

set vg = Nothing

 

the sOtherLineCallState will hold the callstate of the line the other call was on.

 

If you want to post your script then we can better suggest the best approach in your case.