SupportTeam Report post Posted 09/09/2003 07:46 AM Again we see in the trace that the Dialogic driver reported a "DISCONNECTED". 083533.95 7 Loop Current Drop detected - but in VG.INI LoopCurrentDrop = Ignore 083533.96 7 callstate DISCONNECTED 65945,0,0 083533.96 7 LsXferPlayAnn EV_REMOTEPARTY_DISCONNECT 083533.96 7 lineDrop(65945) in DropConsultingCall_Fail => 65911 If this is what the card is reporting then there isn't much else that we can do about this... it does look as if the telephone company lines are dropping the loop current - which always indicates end of call - so you should ask the phone company why it is doing this... and ask them for how long are they dropping the loop current for... You could then try changing the "Minimal LCOFF" setting in the Dialogic TSP configuration to specify a longer time then for how long the loop current is dropped... if the LC drop is temporary then this could be a workaround... Dialogic detection of loop current drop is very reliable - I don't think that it's mistakenly detecting something else here... There are two questions with all this: 1. How come the hookflash length which for so long has been a problem has suddenly fixed itself? What happened? 2. How come that all of a sudden we get loop current drop a few seconds after conferencing in the second person - when we did not see anything all along until a couple days ago? Were there any changes made on the system which affected all of this or did the phone company make some changes on their side? Also: I'll probably be a lot quicker to just get a D41JCT card instead of trying to chase down the phone company to answer questions about the loop current drop... Share this post Link to post
health4us Report post Posted 09/09/2003 07:53 AM ok to answer your questions. to fix the flash time issue i formatted computer and reinstalled everything and it worked. there has only been changes in the voiceguide software since the problem with the conference calls loop problem so it is not a telefonica prob for sure - the prob lies somewherre in the change to v.5.1.. Share this post Link to post
SupportTeam Report post Posted 09/09/2003 08:23 AM to fix the flash time issue i formatted computer and reinstalled everything and it worked. Good to hear. There does appear to be some hidden bug in Dialogic drivers which results in the flash timing quietly breaking - we suspect that the hookflash timing can be broken by updating the Windows' system DLLs with versions that are from other service packs then that which the Dialogic installation notes specify to use... Regarding LC drop - could you please try changing the "Minimal LCOFF" setting in the Dialogic TSP configuration to specify a long time (eg: set to 500 to specify 5 seconds) and see if this resolves the problem. Also, please try setting it to 0 - maybe this will disable loop current drop detection within the Dialogic driver. It's the LC drop that's causing the Dialogic driver to send "DISCONNECTED" and once it does it will no longer accept commands to the "DISCONNECTED" line... Share this post Link to post
health4us Report post Posted 09/09/2003 09:03 AM tried both setting and it did not fix the prob - anymore ideas as this time I can't blame Telefonica as it was working. the prob with v5 was that the success path was never taken so that is why the upgrade was done.. now with the upgrade it seems to have made things worse. Anymore ideas what to do? Share this post Link to post
SupportTeam Report post Posted 09/09/2003 09:56 AM If it was working with a previos version then perhaps the better option is to go back to using the previous version for now... Share this post Link to post
health4us Report post Posted 09/09/2003 10:19 AM I agree but the prob with the previous version was that the success path was never taken when a transfer was a success and i need this but to work obviously. Matt Share this post Link to post
SupportTeam Report post Posted 09/09/2003 11:19 AM In v5.0 the second leg of call was not a separate conferencing call - so when the second leg dialed a busy number this caused the original call to think the busy was on it's line, the TAPI driver would close down the call and then VoiceGuide would hangup the line. In v5.1 onwards the "conferencing call" feature of the TAPI driver is used to make the second call, so that if the 2nd number is busy then only that "conferencing call" will be regarded as finished - and the main call can still go on - to make other conferencing call attempts for example... When testing v5.1 on our test systems we have not seen the Dialogic drivers report any "Loop Current drop" events - it all works fine on our test setups here, we don’t see any "Loop Current Drop" events after making the second call... that's why we're trying to ascertain what are the differences between our setup and the setup of your system... and the phone lines used seem to be what the difference is here... Can you perhaps run a quick test using different phone lines, or phone lines on which the 3 way conference is disabled... You can see trace from our v5.1 test system below: 210619.27 13 linedevstate 2048 0 0 210619.27 13 callstate OFFERING 66289 0 4 210619.27 13 Answer the call at 9/09/2003 9:06:19 PM 210619.30 13 lineAnswer(66289) => 66306 210619.30 13 callinfo CALLEDID 210619.30 13 callinfo ORIGIN 210619.31 13 ring 0 210619.83 13 callstate CONNECTED 66289,1,0 210619.83 13 WorkingModeTAPI@Connected= 210619.84 13 WorkingModeScript@Connected= 210619.89 13 Inband detection not enabled 210619.91 13 StartLoadedVgs at 9/09/2003 9:06:19 PM 210619.91 13 tapi Reply (LineEvReply) ok 66306 0 210619.91 13 TimeoutClear 210619.91 13 TimeoutSet 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER 210619.92 13 callinfo MONITORMODES 210620.34 13 Timer fired EV_TIMEOUT_READYTOBEGINTRANSFER 210620.34 13 ScriptEventCode 9012 iLineState=1900 210620.34 13 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER 210620.34 13 TimeoutSet 30 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG 210620.36 13 [Transfer Call 1] Announced Conference to 16 (TAPI) 210620.36 13 fn SrSetupConferenceTapi 210620.36 13 [Transfer Call 1] Number: 16 210620.39 13 lineSetupConference(66289,66049,0,0) in SrSetupConferenceTapi => 66323 210621.47 13 tapi Reply (LineEvReply) ok 66323 0 210621.47 13 callstate CONFERENCED 66289 0 0 210621.47 13 linedevstate 2048 0 0 210621.48 13 callstate DIALTONE 66493 2 0 210621.48 13 lineDial(66493,16) => 66476 210621.48 13 linedevstate 2048 0 0 210621.50 13 callstate ONHOLDPENDCONF 66271 0 0 210621.50 13 callstate DIALING 66493 0 0 210621.50 13 callstate PROCEEDING 66493 0 0 210621.50 13 callinfo CALLEDID 210623.02 13 callstate CONNECTED 66493,1,0 210623.03 13 WorkingModeTAPI@Connected=SetupConferenceAnnounced 210623.03 13 WorkingModeScript@Connected= 210623.03 13 lineMonitorDigits(66493) => 0 210623.03 13 fn PlaySoundStartNumbers TsfrCallFrom.wav, TsfrAskAccept.wav, , Digits 210623.05 13 twcal PlaySayNumber C:\Projects\vg32\system\voice\TsfrCallFrom.wav, C:\Projects\vg32\system\voice\TsfrAskAccept.wav, , , 1 210623.19 13 PlaySoundStartNumbers ok 210623.19 13 TimeoutClear 210623.19 13 wa(6929,64778101) 210623.19 13 tapi Reply (LineEvReply) ok 66476 0 210630.16 13 wb(64778101) 210630.22 13 Play End line[13] (id=647781) 210630.22 13 ScriptEventCode 8001 iLineState=1906 210630.22 13 LsXferPlayAnn EV_PLAY_FINISHED 210630.22 13 LsXferPlayAnn EV_TIMEOUT_REPLAYMSG 210630.23 13 fn PlaySoundStartNumbers TsfrCallFrom.wav, TsfrAskAccept.wav, , Digits 210630.23 13 twcal PlaySayNumber C:\Projects\vg32\system\voice\TsfrCallFrom.wav, C:\Projects\vg32\system\voice\TsfrAskAccept.wav, , , 1 210630.27 13 PlaySoundStartNumbers ok 210630.28 13 TimeoutClear 210630.28 13 wa(6929,65496801) 210636.63 13 dtmf 1 (66493,49,2) Share this post Link to post
