'frozen' Lines

[Guest Buzby]

Hi again,

 

Have come across a very intermittent fault (i.e. once in thousands and thousands of calls) in which a line appears to 'freeze'.

 

It does this apparantly when someone has called into the line, then leaves the line in frozen state somewhere in the script which becomes unavailable for further calls even if the user hangs-up.

 

I have tried using the hang-up button on this particular line, but I receive the message: "Hanging up call... [Default Handler 60:9001]" but the line does not go back to the 'Waiting for a call...' status and thus remains unavailable. It stays this way until VG is shutdown and restarted - but all other lines remaining working regardless.

 

I have attached some cut-down log files so you can see the fault. Note the short log from 4/12 was a day after the fault occured when I first noticed and decided to attempt to shut down the line unsuccessfully.

 

Any help you can offer would be much appreciated as always.

 

Best wishes.

1203tw.txt

1203vgm.txt

1204vgm.txt

[SupportTeam]

Thanks for the traces - they let us better see what is happening on the system and let us provide an answer/resolution faster.

 

One thing that stands out here is that the script takes about a second to answer the call - this is what's most likely causing the problem.

 

Please update your system with attached files. This new version should allow you to take as long as you like before answering the call (up to 30-90 seconds or so, depending on telco).

 

If you encounter any problems in the future please post the traces as before.

ISDN_issue_ACCEPT.zip

[Guest Buzby]

Thank you so far - unfortunately however, had to uninstall the 6.0.3202 patch sent and revert to 6.0.3201 as it causes major problems with our systems answering calls.

 

It seems that the vast majority of calls get hung-up before the main script gets started. I think this is a side-effect of the changes made in the pre-answering handling code.

 

Have attached traces showing three separate calls that terminated prior to being answered - none of these calls actually physically hung-up thus it seems VoiceGuide was hanging-up by itself.

 

Many thanks.

1206tw.txt

1206vgm.txt

[SupportTeam]

Please try with attached files and post traces as before.

 

Which Dialogic System Release drivers are installed on this system?

TPT_removed.zip

[Guest Buzby]

Ok, have loaded up the version, and the first few test calls seem to answer correctly - see logs below.

 

Will have to wait until our system becomes busy in about 6 hours before I'll know fully whether this fix works properly. Will update a bit later on.

 

Presumably this version also includes the fix for the 'long answer time freeze' fault above?

 

Our Dialogic SR is 5.1.1 with all the service packs & patches applied. Would like to upgrade to SR 6.0 but cannot find the free download link mentioned by some - everything I find mentions a licenced & paid-for version!

 

Best wishes.

1207tw.txt

1207vgm.txt

[SupportTeam]

Presumably this version also includes the fix for the 'long answer time freeze' fault above?

Trace shows that the first call that arrived on system after it was started was answered about 1.5 seconds after it arrived, so looks like this version is capable of answering calls after a delay and continuing with the call after this late answer:

021733.078 002 ev GCEV_OFFERED (ktTelControl v2.3.8, Dec 7 2006 12:01:56)

021733.078 002 ocxev DoFireDialogic(dwIdx=16, 2, 2084, [GCEV_OFFERED], 2084, 0, 0, [], [], []) (dwIdx=16)

021733.078 002 could not retrieve CALLNAME

021733.078 002 ocxev CallerId(sLineId=2, hCall=0(0x0), crn=33601158(0x200b686) strCallerID=[7884233061], strName=[], strDialed=[630940])

...

021734.578 002 ocxfn LineAnswer(lLineId=2, lParam=0, strParam=)

021734.578 gc_AcceptCall(33601158(0x200b686), 0, EV_ASYNC) ok

021734.578 002 ev GCEV_ACCEPT

021734.625 002 ev GCEV_ANSWERED (ktTelControl v2.3.8, Dec 7 2006 12:01:56)

Easy to check if the system will answer calls after a longer delay - just modify the script to introduce enough pause to force call answer after 5 or 10 seconds. ie: set script to "start without answer" and then have some delay before jumping to the first Play module.

 

 

See: http://resource.intel.com/telecom/support/...serviceUpdates/ and click on the link for latest SR6.0PCI Service Update - I think you'll find that the Service Updates do not timeout after 10 hours and can be clean-installed without previous SR6.0 install present.

[Guest Buzby]

Hello again,

 

Unfortunately our systems are still showing exactly the same problem, even on version 6.0.3202.

 

I have the traces, but am having severe difficulties getting them formatted, as they run to around 1.4Gb per day - you'll probably find that the traces will be very similar to the ones shown at the top of this thread.

 

This leads me to believe that the length of time for answering the call seems to be irrelevant in causing the problem - we are currently taking around 2000 calls per day, of which quite a few have a lengthy startup time, yet still only seeing 1 or 2 frozen lines per week. I can give you VNC access if that makes things easier?

 

The difficulty comes in trying to reset the line back to normal by restarting VoiceGuide because it can be hard to find a 'quiet' period when no calls are coming in.

[SupportTeam]

Could you please .ZIP up the logs and email them to support@voiceguide.com, quoting this thread link in the email, and indicate which lines became frozen and around what time they became frozen.

 

We will look through the logs and report here what they showed.

 

Can you schedule automated restart at say 3am or do you get calls at that time as well?

 

(please send vgm and tw .zips in separate emails).