Outbound Call Answer Delay Too Long

[LTympanick]

Hi,

 

I have Dialogic 6.x, VG 6.0.3377 and a Dialogic T1 card running ISDN service with a carrier here in the States.

 

Your doc on Call Answering says the following under Dialogic Digital Cards:

 

If answering machine detection is enabled and recipient of call does not say anything after answering the call then the Dialogic card will timeout out after a few seconds of receiving the 'handset is offhook' signal and report the call as connected.

 

That few seconds appears to be 10 - 20 on my system.

 

Any way to make that timeout shorter?

 

Thanks

[SupportTeam]

10 seconds sounds about right on ISDN systems. On analog system it would be a bit less on average as the timeout is counted from the end of the last ringback.

 

Usually this is not something that is encountered as most people do say something to the phone after answering it ("hello" or something similar).

 

It may be possible to decrease this timeout, but most likely we would only be able to provide an option to change this in v7 of VoiceGuide.

 

Which Dialogic card and Dialogic drivers are you using ? D/240JCT and SR6.0?

 

[LTympanick]

Hi

 

Thanks for your response.

 

Yes I am using a Dialogic D/240JCT and Dialogic SR 6.0 PCI R171.

 

I do have plans to upgrade to System 7 so that wouldn't bother me if indeed this could be a VG or Dialogic param that could be controlled by us. So you're saying it is not the phone company that controls this?

 

Thanks.

[SupportTeam]

The time it takes for the Live/AM answer detection to timeout is controlled by the Dialogic card, as it is the Dialogic card that is performing the detection.

 

We should be able to adjust the timeout in the Dialogic's own algorithm, or on ISDN lines we would also be able to override this detection altogether by timing out inside the VoiceGuide software (as VoiceGuide is informed of the precise time the handset is lifted by call recipient if ISDN lines are used).

 

So we should be able to provide a parameter that lets you adjust the timeout. We will be able to confirm this tomorrow.

 

On how many calls do you see this situation where the call is answered but the person answering the call does not say anything and waits for the calling person/system tom start speaking?

 

 

[SupportTeam]

Have confirmed that we will be able to expose Dialogic's low level settings which affects the Answering Machine / Live Answer detection timeouts.

 

With this new version you will be able to access all entries in the Dialogic DX_CAP structure, including:

 

ca_cnosig

ca_noanswer

ca_pamd_failtime

 

There are about 30-40 settings in the DX_CAP structure, all of which are accessible to you, so you will have total control (on a per-call basis) over how the Dialogic card can do the detection.

 

For more information on the fields in the DX_CAP structure you will need to read Dialogic's documentation - see the "Voice API" file.

 

To change setting to your value (instead of using the default) you will be able to use an expression like this in the "Call Options" field (same field where CallerID to be used on the outgoing call is specified):

 

<DX_CAP><ca_cnosig>500</ca_cnosig><ca_pamd_failtime>200</ca_pamd_failtime></DX_CAP>

 

Access to DX_CAP will be made available in next release of VoiceGuide, but if you want to place an order soon then just write in the Comments field on order from that you would like to get the version which gives you access the DX_CAP and this version will be made available sooner.

[LTympanick]

The time it takes for the Live/AM answer detection to timeout is controlled by the Dialogic card, as it is the Dialogic card that is performing the detection.

 

We should be able to adjust the timeout in the Dialogic's own algorithm, or on ISDN lines we would also be able to override this detection altogether by timing out inside the VoiceGuide software (as VoiceGuide is informed of the precise time the handset is lifted by call recipient if ISDN lines are used).

 

So we should be able to provide a parameter that lets you adjust the timeout. We will be able to confirm this tomorrow.

 

On how many calls do you see this situation where the call is answered but the person answering the call does not say anything and waits for the calling person/system tom start speaking?

 

I'm not sure but I suspect it's a lot because many people can see it's my system calling them through their caller-id and they know it's a computer system calling so there's a natural reluctance to say hello since they know what's coming and it's awkward to say hello when you know it's a machine on the other end. I've had some of my customers bring it up to me already so I know it's an issue with some at the very least.

 

[SupportTeam]

many people can see it's my system calling them through their caller-id and they know it's a computer system calling so there's a natural reluctance to say hello since they know what's coming and it's awkward to say hello when you know it's a machine on the other end. I've had some of my customers bring it up to me already so I know it's an issue with some at the very least.

Sounds like reducing the detection timeout would be the right thing to try then. You would need to experiment with various values to see which ones would work for you best.

 

Another approach maybe to not use any call answer detection but use a Record module at the very beginning of the script. When the record times out due to silence you can look at how long the recording took and if it was a short time then assume it was a Live Person and if it was a long time then assume it was an Answering Machine.

[LTympanick]

OK...I'm ready to upgrade to v7.0.9...

 

To handle this issue and my other issue where in v6 on busy system, VG will crash on me at very random times....Kills me because once I'm down, my customers can't get in until I restart VG...

 

VG v6 Exe Crashes (goes Into Microsoft Debugger) ( LJT 3SD Hingham ) Please read the whole post...BTW...Terminal Services wasn't the issue...I still see the totally random crash even without it....It is so hard to reproduce except with the 1st call after a total system reboot....Most likely some kind of Dialogic issue with v6. Will run fine until system gets busy and then goes into Microsoft Debugger..still happens to me even to this day....

 

Been living with this for quite a while but I am now determined to upgrade to v7 to see if I can get rid of this problem once and for all.

 

Will this upgrade cost me and if so how much?

 

Thanks,

 

LJT Hingham

[SupportTeam]

For upgrade pricing and all other license related questions please contact sales@voiceguide.com. Some guidelines on upgrade pricing are also listed at the bottom of the order form.

 

Note that VoiceGuide v6 is meant to be used with Dialogic SR5.x series of drivers, and VoiceGuide v7 is meant to be used with Dialogic SR6.x series of drivers (the drivers for use with VG v7 are provided on our Downloads page). I think that you are already using SR6.x drivers on your system so v7 would be the VG version to use.