3-way Calls

[SupportTeam]

Kevin wrote:

 

Ok, the problem I've been running into with the patch is.. when try to do a 3 way blind conference call, the hookflash goes over ok and dials out (adjusted to "50" for US phone system) but it doesn't click back over. I've tried all the numbers up to 50 and they either don't dial out or don't click back over when they do.

 

On top of that, when both calls are hung up, voiceguide doesn't disconnect. It'll disconnect only if either caller presses (*).

 

The only time this feature worked for me was when I tried it with VG 5.2.5012a without the patch, and tapi and wave enabled. It even hung up like it was supposed to after either party hung up.

[SupportTeam]

when try to do a 3 way blind conference call, the hookflash goes over ok and dials out (adjusted to "50" for US phone system) but it doesn't click back over. I've tried all the numbers up to 50 and they either don't dial out or don't click back over when they do.

Could you please post a copy of VoiceGuide's Debug Printout which captures the problem, this will allow us to see what happened.

 

When running the script click on VoiceGuide's View menu and select 'Event Trace Log' option - any log information will then appear in this window. You must open the trace window before making the call.

 

When posting traces/scripts please .ZIP them up and post them as attachments.

 

On top of that, when both calls are hung up, voiceguide doesn't disconnect. It'll disconnect only if either caller presses (*).

Sounds like the busy tone detecton settings are not set right. See: http://www.voiceguide.com/vghelp/html/Disc...ctionDetect.htm

[czardoff]

I've attached the trace log for my problem:

vglog1.zip

[SupportTeam]

Looks like there is a problem and we'll look into this.

 

In the meantime could you please see if this works:

 

For the number, specify:

 

2580884,!

 

instead of just

 

2580884

 

That should result in the hookflash being issued after the number is dialed (the comma is a pause) which is what is required to complete the 3 -way call immediately.

 

Have you tried using the "monitored" or "announced" 3-way conference options?

[czardoff]

Ok. The "monitored" and "announced" options for 3 way worked this time. The system connected the two callers together fine for each. That seems solved.

 

Now there's just the issue of Voiceguide hanging up if one or both callers hang up.

I'll try to play with the "busy tone detection settings" as stated in the previous thread/response.

 

To get started...

 

Are the Dialogic Tapi settings for the disconnect tone detection different from VG for Dialogic settings? Because when I tried using VG without the patch, it transferred and hung up like it should when either caller hung up with no problems.

 

 

But one thing seems to stand out to me and thats the lines in the trace log that say:

 

path {de_lcof} not found

loop current off ignored as current module is VGMTYPE_XFER

 

 

What does that mean? "loop current off ignored.."

 

Here's the log with the announced transfer:

vglogannounced3way.zip

[SupportTeam]

Are the Dialogic Tapi settings for the disconnect tone detection different from VG for Dialogic settings?

They should be pretty much the same... You can compare them by looking at the TSP config and the ConfigLine.xml file.

 

But the other thing you noted may explain why TAPI version hangs up OK and the VG-Dialogic does not:

What does that mean? "loop current off ignored.."

Loop current drop is usually used to indicate end of call, and VG will usually hangup if loop current drop is detected. However some phone companies do all kinds of strange loop current changes during call transfers, so VG is designed to ignore all loop current changes while in Call Transfer module.

 

The Dialogic TAPI drivers will end the call immediately when the lop current drop is detected (which causes some problems with some phone companies when doing transfers).

 

So it looks like in your case it was the Loop Current Drop that was used as a signal to end the call. I take it that the two loop current drops visible in trace were corresponding to the times when the two legs of the call hung up?

 

We've made the option of whether to hangup or not in Call Transfer module when a loop current drop is detected settable in VG.INI

 

Update to attached .exe and in VG.INI section [PBX] add this entry:

 

Transfer_HangupOnLCOFF=1

 

Another alternative is to use a "Success" path to leave the Call Transfer module and point it to a Play module which does not play anything and has a long Timeout path...

 

And yet another alternative is to record the disconnect tone played on the line when callers hangup and modify ConfigLine.xml file to correctly detect the disconnect tone.

VgMulti_6.0.3078.zip

[czardoff]

Alright. After comparing the "Dialogic" TSP and ConfigLine.xml file, I assume the "Call Progress Tone TID_DISCONNECT", is the default setting that [VGf-D] uses. I also saw the "DISCONNECT TAPI 1/2" settings. I assume these are not really used in VGf-D because you say it doesn't use TAPI drivers. The TSP and Tapi settings in VGf-D match.

 

 

I guess the reason why you created the new patch was to solve the problems of the loop current drops during call transfer on funny acting phone company systems.

 

I think in my case, my phone company here in the U.S. (Bellsouth) won't have any problems if I just used VG 5.2.5012a. Like I said before, everything worked fine with it when I was troubleshooting and testing. The only problem I had was when looking at the registration screen for that version, it didn't display my two D4PCI cards (I don't know why that happened--they displayed when I added the patch though). But if you think I will have problems in the future using 8 lines with TAPI/Wave, then of course the patch is the solution.

 

Now.

If you still suggest the patch, couldn't I just put both TAPI settings in the ConfigLine.xml file in such a way that they are defined as "TID_DISCONNECT_1" and "TID_DISCONNECT_2" ?

 

 

As for this...

I take it that the two loop current drops visible in trace were corresponding to the times when the two legs of the call hung up?

 

Not necessarily. After testing it I noticed that if one leg hangs up and the other stays on, voiceguide does nothing to the trace--it just stays put at this line:

 

8001(EV_PLAY_FINISHED),EV_PLAY_FINISHED,0,0,0,,, (iModuleIdx=3)

214738.81 1 path {ev_play_finished} not found

 

Its only after the second leg has been hung up for 10 seconds that the log reports the first "loop current ignored" line group, and then about 55 seconds later it reports the second set---and thats it. The log will remain at that point until I manually hang voiceguide up.

[SupportTeam]

I assume these are not really used in VGf-D because you say it doesn't use TAPI drivers. The TSP and Tapi settings in VGf-D match. I assume these are not really used in VGf-D because you say it doesn't use TAPI drivers. The TSP and Tapi settings in VGf-D match.

All valid tone definitions in ConfigLine.xml are loaded in. The "TAPI" bit in the name just indicates that these settings are copies of what were the default definitions shipped with Dialogic TSP.

But if you think I will have problems in the future using 8 lines with TAPI/Wave, then of course the patch is the solution.

There are known problems with Dialogic’s Wave drivers. With 8 lines there is a high chance you will encounter these problems. Basically the sound files just don't play every now and then when you use Dialogic's Wave drivers.

[czardoff]

I did the update and it tested well. It conferences, and hangs up accurately, although both parties have to hang up in order for voiceguide to do so, but I think that's just how our 3 way works.

 

Another job well done folks. I'll also try to record the disconnect tone and apply it to the Config file just to test it. I don't anticipate any other problems with this issue. So I guess that's it.

 

Thanks Team. You're the Best.