Dial And Conference

[Guest fsoudbakhsh]

If some one hang-up the phone at the time Dial and Conference module wants to dial the number the VG will jam and it does not hang-up nor it will go to next module.

 

Please see the attached log file.

What can I do to solve this problem

diiling.rar

[SupportTeam]

The trace file is over 1.3MB and has captured a few different calls.

 

Which is the call you'd like us to look at?

 

What is the timestamp of the line which shows one side hanging up?

[Guest fsoudbakhsh]

I have copy and paste the text file into the doc file, and highlighted the problem at page 88.

 

Please note that I have hang-up manually the line that was jammed and used for dial and conference.

hangup_problem.zip

[SupportTeam]

Trace shows that both lines 2 and 3 show "Waiting for a call..." within one second of being disconnected (which is what the highlighted entry shows), so all looks fine there...

 

The trace provided previously also shows only one disconnection of a conferenced call and again both lines involved in that trace show "Waiting for a call..." soon afterwards... so again all looks fine there...

 

maybe you should describe step by step:

 

a. what the scenario is,

b. what you see happening on VG's Status screen (if visible),

c. what is it that callers do and hear during all this time.

[Guest fsoudbakhsh]

a. what the scenario is

When VG star running Dial and conference module, if customer hang up right at this time, VG would jam on Dial and Conference module. It will not hang up nor it will move to next module.

 

 

b. what you see happening on VG's Status screen (if visible),

On status screen I see Dial and Conference module which contain the telephone number and the name of the dialogic channel it's brigaded.

 

 

c. what is it that callers do and hear during all this time.

Caller already hang up. That is why this problem accrue.

[SupportTeam]

On status screen I see Dial and Conference module which contain the telephone number and the name of the dialogic channel it's brigaded.

The calls that we've seen in the trace all sow that status screen was updated to "Waiting for call...".

 

Please indicate the exact timestamp of the call that was hung up on and then we can pick up the trace from there.

 

Are these the 'seized' lines incoming lines or outgoing lines or both?

[Guest fsoudbakhsh]

The calls that we've seen in the trace all sow that status screen was updated to "Waiting for call...".

 

Please see the attached file which demonstrate the problem. The line you are seeing in this picture is busy for hours.

 

I also attached logs files, I don’t think you would get a lot information out of log file because I have lower the data entering to log file to 0. this is because we discover when the log file get big in memory size, none of the line would answers the calls.

 

Perhaps you programmers need to come up with a solution for log file problem too. Because I am going to prepare myself to place an order for 30 lines license. And I am worry that log file would become my major problem as the number of my lines increases.

 

Thanks again for helping me.

log.zip

[SupportTeam]

The traces don't contain any useful information - looks like the log level was set very low...

 

Can you please set log level to 9 or 10, and then reproduce the problem. the post the traces and indicate:

 

1. which line was seized

2. approx time

3. quote *exactly* what was show in that line's status - especially the number it was dialing and the line with which it was trying to establish the conference.

[Guest fsoudbakhsh]

1. which line was seized.

 

Please see jpg file in ZIP file I sent you.

 

2. approx time.

 

The time I remote access the computer was 4:00 am in Middle East. People leave the office at 11:30 PM. So it should happened some time between 11:30PM to 4:00AM.

 

3. quote *exactly* what was show in that line's status - especially the number it was dialing and the line with which it was trying to establish the conference.

 

Please see the JPG file in zip file.

 

Can you please set log level to 9 or 10, and then reproduce the problem. the post the traces and indicate:

 

No unfortunate I can not set log level to 9 or 10 because my line are get in used fast and when log file get big in memory size, no line will answer the phone. Plus this problem is happen some time. I can not risk no-answer problem due to large log file for this problem.

 

I also understand that you can not help me without the log file. Previously I sent you a log file that contains this problem. You told me that the line was return to “Wait for Call”. You are right, the line which initiate the call would return to “Wait for Call” but the line which was used for Dial and conference is seized. Please see the JPG file in zip file.

 

My recommendation to your programmers is to write a code for check both lines in dial and conference every 5 second if the line which is used for conference call is busy at the same time. If one that used for conference is busy and other one which initiates the call is not, hang up the line which was use for conference call.

 

Please also solve the problem with Log file. When they get busy lines are not answering the calls.

 

Thanks.

[SupportTeam]

No unfortunate I can not set log level to 9 or 10 because my line are get in used fast and when log file get big in memory size, no line will answer the phone.

That should not happen. We run tests here which cause the trace files reach well over a 1GB (ie: over 1024MB) and there are an problems with that affecting call answer..

 

Even if the Hard Disk runs out of disk space due to trace files using up all of it, that will not stop VoiceGuide from answering calls.

 

What sort of system are you using. Please give system specs and details cards used.

[Guest fsoudbakhsh]

let me return to my first problem (dial and conference module jam ) then I will create a new topic for log file.

 

In regard to dial and conference module jam, we notice that when the jam happened, after few minutes a disconnect tone will be appear for 20 second. Since we don’t have this disconnect tone in our configline.xml file, VG doesn’t hang up, that is why after disconnect tone stops, dial and conference call will jam forever.

 

I have recorded and attached the disconnect tone to this topic. I would be appreciation if you would analyze the tone for me.

 

Thanks a lot.

newtone.rar

[SupportTeam]

we notice that when the jam happened, after few minutes a disconnect tone will be appear for 20 second. Since we don’t have this disconnect tone in our configline.xml file, VG doesn’t hang up, that is why after disconnect tone stops, dial and conference call will jam forever.

Sounds like this just another case of the phone company playing a disconnect tone which is not specified in your list of disconnect tones for which VG should listen for detect...

 

And the "Jam" is just the system maintainig the connection as none of the defined disconnect tones played on the line...

 

If you are going to use analog lines to do "Dial and Conference" (and I understand that's basically all that this system is doing as it's a pre-paid calling card system) then you see why it is essential that the PBX reliably signals end of call using disconnect tones or loop current drop... as that's the only way that the system can detect that the end of call.

 

That's why we repeatedly strongly recommend using a Digital T1/E1 ISD system for any platform whichj makes high use of call switching - the digital lines will give you reliable signalling when either party hangs up

 

All this I think has already been extensively covered in a few other threads, including this one:

http://voiceguide.com/forums/index.php?showtopic=3163

 

Instructions on how to get the cadence and frequencies of any tone can be found here: http://www.voiceguide.com/vghelp/html/Disc...ctionDetect.htm

[Guest fsoudbakhsh]

I wish it would be easy to get digital lines in every county.

Obtaining digital line in some countries is either impossible or extremely expansive.

 

Fortunately we don’t have major problem with our analog lines, except some time facing new disconnect tone. I believe once we have cover all disconnect tones we would not have any more problem.

 

Here is my suggestion for you. As you have listed the recommended modem. Start listing disconnect tones.