Lines Go Inactive (?)

[Guest rmonicat]

Today was the first test of the system in a nearly real environment.

After a few calls some VG stopped using some lines.

In the attached log file, there is a trace where I fired three calls on lines 5,6,7, but only call on lines 5 and 7 were actually dialed.

 

In the last run lines 6 and 7 went inactive.

There are some error messages related to structures initialization.

log.zip

[SupportTeam]

Trace shows 3 calls were queued:

 

200607,95 0 cl Dialer_OutDialQueAdd 101, 0, 0, 0, , 5, 1, ... etc

200608,11 0 cl Dialer_OutDialQueAdd 104, 0, 0, 0, , 6, 1, ... etc

200608,28 0 cl Dialer_OutDialQueAdd 105, 0, 0, 0, , 7, 1, ... etc

 

and then two calls were made:

 

200608,42 5 Dialing: 101

200608,45 7 Dialing: 105

 

with everything looking OK.

 

It does look like the call on line '6' was not made as that line was not enabled for outbound dialing... see: "View" -> "Line Device Config" menu - is the "Allow dialout on this line" selected for line 6?

[Guest rmonicat]

It was enabled.

After dialing ok in line 6 for some time, it stoped using it.

In some other run it stoped using lines 6 and 7.

Can there be any problem in dialout database?

[SupportTeam]

I'll arrange for a version of vgmulti.exe which has better debugging around this area which should be able to tell us exactly what is happening here.

 

I'd expect this will be available tomorrow.

[Guest rmonicat]

Thank you for your help.

I'm in a hurry for implementing VG... I'll be waiting for you.

[Guest rmonicat]

Please, look at this secuence.

 

Start VG

 

Launched 3 call on lines

5 = Unanswered (I did not answer)

6 = Unanswered (I did not answer)

7 = Busy (It was not busy) !!!!

 

Launched same 3 call again

5 = Unanswered (I did not answer)

6 = Unanswered (I did not answer)

7 = was not dialed (looking at VG screen) !!!

 

Drop VG

 

Line 5 : exiting

Line 6 : exiting

Line 7 : waiting for a call !!!!

Line 8 : exiting

 

 

Start vg

******* end of secuence *******

 

Second call in line 7 was never dialed. In a previuos secuence it was dialed after VG was reinitialized.

 

 

I tried all lines using PBXpert without problems.

 

Notice that there is an error message in file 0518sw

 

111029.312 fn TAPI_ERR:LINEERR_OPERATIONUNAVAIL !!!

tresdial.zip

[SupportTeam]

Looks like there was a bug in the 5.2.2003 update given to you before...

 

Please try the new .exe

 

Regarding the detection of "busy" when call is not answered then you will need to set the Dialoigc's TSP's tone settings a bit stricter - right now it looks like the 'ringback' tone sent by Telco is pretty close to what the 'busy' or 'disconnected' tone configuration in the TSP specifies...

 

The TAPI_ERR:LINEERR_OPERATIONUNAVAIL is there as VG is unable to retrieve the picture icon from the TSP - that message can be ignored as it does not affect anything.

VgMulti_5.2.2006.zip

[Guest rmonicat]

I enjoyed the day of today listening three phones ringing.

 

Definitely a time diagram problem.

 

Please take a look at these tests. Inside ZIP file attached there are ZIP files for each run. I used three phones and never picked up any of then.

 

File "uno a uno".

More 100 calls fired with a 22 seconds interval between each. WITHOUT ERRORS.

Each call was launched after the last one ended in VG screen.

 

File "sin intervalo"

Calls were launched without delay between each. You can see a LOT of Busy or Contacted_Human falsely reported codes.

 

File "cada 10 segundos"

Calls were launched same as in "sin intervalo" adding a 10 seconds delay between calls.

You can see a MUCH LOWER error rate.

 

File "variando tiempos"

A test varying the interval. There are errors ONLY when the time between one call and the other is lower than 6 seconds. There are NO ERRORS above that time.

The time mentioned is between calls sent to DIFERENT LINES not the same.

 

My conclusions.

 

a) From "uno a uno" I guess that the mayor problem is not in Dialogic Software or parameters. May be it will deserve attention after present step.

 

The time rate at which calls are introduced in the system produces erroneous results. Caused by the way VG handles Dialogic or VG internal problems... ??

 

C) May be that time diagram and not rate is the problem . It is not included, but I tested "cada 10 segundos” introducing an additional time delay almost synchronizing the moment that calls were launched with the moment that they ended in VG. Error rate was much higher.

 

 

Thank you for your help.

consulta_tiempos.zip

[Guest rmonicat]

Sorry. I forgot to mention that today any line became inactive.

[SupportTeam]

I forgot to mention that today any line became inactive.

I assume that means that no lines went 'inactive' after updating to latest patch...? I assume that's the case as you mention that 'all 3 phones were ringing all day'.

There are errors ONLY when the time between one call and the other is lower than 6 seconds. There are NO ERRORS above that time.

This is all pretty surprising as the wait time between calls on the line should not be affecting the frequency spectrum analysis which Dialogic card performs to determine if a call has been answered.

 

What I'd recommend you do is set up a script with a single record module which records for 15-20 seconds. - This way when you get false detections of the call being answered when you believe the line is still ringing then at least we will have a recording of what is happening on the line immediately after a 'call answer' was reported by Dialogic.

 

All that the trace from VG will show is "Dialogic reported call was answered" - there is no Dialogic-related info in the trace to tell us on what basis Dialogic believe call was answered (eg: 'ringback goes away' or 'speech detected' etc) indeed Dialogic does not make this info available - so it's pretty hard to find out just why Dialogic determined that the call is answered.

 

In our experience call answer detection works very well so there was never a need to delve deeper into it...

 

I think we mentioned before ( http://voiceguide.com/forums/index.php?showtopic=1569 ) that the most likely cause of false detections her could be the 'ringback' timeout setting... have you increased these ringback timeout values in the Dialogic TSP ?

[Guest rmonicat]

I increased timeout to 800 ms. Do you recommend some higher time?

[SupportTeam]

I'd first increase ringback timeout to a very high value - say 30 seconds (a setting of 3000) and see what happens, then if all is OK start decreasing it and see at what time you start getting false-detect problems...

[Guest rmonicat]

I set timeout to 3000 and rebooted the machine.

In the attached file the result files are contained.

waves files are contained in the "wave files" directory and do not have wav extension. They can be heared just renaming them to .wav.

prueba_sonidos.zip

[SupportTeam]

We can see from trace that there have been a few detections of 'busy' and 'human answered' amongst the majority of 'no answers'.

 

Please note however that some of the recordings made did not record a ringback tone, but what sounds like a part of a 'busy' tone - please see these two files:

 

w_5_2004_05_20_08_09_06.wav

w_5_2004_05_20_08_09_19.wav

 

... so maybe although the lines are ringing the Dialogic card is actually hearing something other then ringback sometimes?

 

Also, all the 'human answered' detections are made by port 5 only. Maybe it's just port 5 on your card that has something wrong with it?

[Guest rmonicat]

While testing VG-Dialogic lines did not go inactive...

Sorrowfully when using the real dialer system this problem seems to be alive yet.

In the attached trace you can see two calls that were delayed without any visible reason. They were queued at a moment when two lines were available.VG screen showed them free and the function line_state reported them as Idle.

I have embedded comments in the trace just search for "====".

The system we are developing is a dialer so, when a call is not dialed without a known reason, the systems stops. As operator’s performance is the main goal of this system, we need to dial several numbers simultaneously and immediately after the operator requested a new contact.

 

 

Thank you.

sedetiene.zip

[SupportTeam]

It looks like the problems with this system occur when a call is not answered. In these situations your "OnNotConnected" script (llamadanoatendida.vbs) runs and it looks like from within that script you call the COM function Line_Hangup().

 

Calling the OCX function Line_Hangup() at the same time as the line is in the process of hanging up is not necessary - and you can see in the trace that you subsequently get errors because of clash of issuing a second simltaneous 'line hangup' instruction at the same time to the Dialoigc card:

 

122958,47 6 tapi Reply (LineEvReply) err 66229 LINEERR_INVALCALLSTATE [8000001C]

 

And then as a result of these errors occurring on the line, that line is no longer used for dialing out.

 

This happened on these two calls:

 

122936,50 6 Dialing: 9,,,48024321

123413,89 7 Dialing: 9,,,44832327

 

on first call line 6 was taken out of action, and on second call line 7 was taken out of action.

 

I'd recommend you stop calling Line_Hangup() from llamadanoatendida.vbs

 

 

All this took some time to debug. Form now on when you encounter problems with VG operations could you please supply the following:

 

1. Full scripts which we can use to reproduce the problem.

 

and

 

2. Full set of scripts which are similar but do not exhibit the problem.

 

ie: we will need to have identified for us what function that is called or action that is carried out that results is a problem - we will then be able to respond with a solution or explanation to your problem much quicker.

[Guest rmonicat]

After implementing your recommendation, the system has been working for two days, without problems, in a real environment .

Thank you very much.