Outbound Calls, No Message When Aswered By Human

[Guest BlackBird]

Hi,

I am using VG7, on a SP3 SP1 system.

 

I attempted to place calls from my system, the call process seems to be working correctly(phone rings, etc.) the problem comes when a human answers the phone, then the message is not delivered, there is just a silent line which hangs eventually as it times out. I attached the log files for your review, could you please advice?

 

Thank you,

-r

Config.zip

[Guest BlackBird]

Update: I just tried a couple of calls, this time when the human answered there was a substantial delay before the message was played to the human.

 

To recap, when the human answers at times there is no message played then the system hangs up, and at other times there is a long delay before the message is played back - sound like some of the setting in the vg.ini might need adjustment, I tried a few setting combination without much luck.

 

-r

[SupportTeam]

Did the person answering the call say something after the answered the call (eg: "Hello.." etc.). On analog systems Dialogic card needs to hear something being spoken before it reports that call is answered. On T1/E1 ISDN systems the script can be started immediately when handset is picked up by person answering the call. Please see: http://www.voiceguide.com/vghelp/source/ht...tcallanswer.htm

[Guest BlackBird]

Yes, on all of the attempts I performed when answering the call I provided a greeting (hello or good afternoon, etc..), I even counted the seconds aloud (one one thousand, two one th..) in order to generate back ground noise. Would you like me to provide another set of logs?

 

[SupportTeam]

In all 3 calls captured in the trace the Dialogic card reported that it thinks that an answering machine answered the call. The system then records what it hears on the line into a file (in this case C:\Program Files\VoiceGuide\temp\RecAm_1.wav) until it hears silence, and then starts the answering machine script.

 

Suggest you listen to RecAm_1.wav file to see what is recorded on the line that postpones the start of the script.

 

The log file will also show you when number was dialed, when answer was detected and when the script was started.

 

123444.296 10 1 state Dialing 1787...

...

123453.656 6 1 rvns add [OutDial_Result]{Answered_Machine}

...

123453.656 6 1 RecSoundStart [C:\Program Files\VoiceGuide\temp\RecAm_1.wav] ok

...

123501.515 6 1 ScriptEvent EV_SILENCE_DETECTED ||

...

123501.515 6 1 state Run Answer Machine script [C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12775AnsMach.vgs]

 

Trace shows that system is repeatedly detecting FAX tones. You may want to double check your FAX tone definition and change it to something which would not result in multiple fax tone reporting.

[Guest BlackBird]

With regards to your recommendation "You may want to double check your FAX tone definition and change it to something which would not result in multiple fax tone reporting"

 

Where is the Fax tone definition checked or set? Is there a parameter in VG where I could set the fax parameters? I looked into the vg.ini and failed to see an entry for fax.

 

I was modified two FAX specific parameters in my sip adapter (see image inside the attached zip file):

FEX CED Detect Enable = No

FEX CNG Detect Enable = No

 

I am not sure if that is what you meant with "Fax tone definition", but, the result is that VG no longer detects the line as a fax line. Now the calls are detected as either NoAnswer, Answer_Human, Answer_Machine.

 

 

I also made the changed the following setting in the vg.ini to the following values:

 

SilenceDetectLevel=1

 

AM_SilenceDetectLength=40

 

AM_SilenceDetectLevel=10

 

AM_WelcMsgMinLen=20

 

Do you foresee any negative side effects with these changes?

 

 

After the changes mentioned above, the current behavior is that when an outbound call is made, the message is delivered, albeit with the following inconsistencies:

 

1. After dialing a number at times the message is delivered immediately after answering the phone, but at times the message is delivered 30 to 40 seconds after answering the phone.

How/Where can I tell VG to deliver the message as soon as the phone is answered by a human?

 

2. After dialing a number at times the message is not delivered, and the entry is tagged in the CdrOut as NoAnswer, but the entry is then removed from the callque table even thought the RetriesLeft parameter is set to 3, since it is removed no further retry attempts are made to dial out the "NoAnswer" phone entry.

Should an entry tagged "NoAnswer" remain in the callque table to exhaust the RetriesLeft entry?

 

Log files attached with image.

 

Regards,

-r

vg.zip

[SupportTeam]

times the message is delivered 30 to 40 seconds after answering the phone.

Did you have a look at the recorded "RecAm" file to see why it continued to record for such a long time? When this happens again please .ZIP up and post the file here. (from 0206_1022 trace the filename is: C:\Program Files\VoiceGuide\temp\RecAm_1.wav)

 

2. After dialing a number at times the message is not delivered, and the entry is tagged in the CdrOut as NoAnswer, but the entry is then removed from the callque table even thought the RetriesLeft parameter is set to 3, since it is removed no further retry attempts are made to dial out the "NoAnswer" phone entry.

The call was actually reported as answered by the Dialogic card and the script was ran, but the answer classification was the rarely used "No Ringback" cause, and looks like there was a bug in the version of VoiceGuide that you are using that would not correctly classify this then in the CDR log.

 

This bug was fixed in the latest version of VoiceGuide. Please download the latest version form our WWW and update to this new version.

 

 

102653.125 5 vgEngine version: 7.0.3240.37858 (RELEASE Build)

102653.125 5 created on: Fri 14/11/2008 21:01:56.05

 

 

102819.750 10 1 state Dialing 17877916831

102846.812 18 1 CDR (out) : "12804","17877916831","","","","0","","C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12804.vgs","","2009-02-06 10:28:19","NULL","2009-02-06 10:28:46",27,0,"ANSWERED_HUMAN",""

 

 

102946.750 10 1 state Dialing 17874782634

103028.921 6 1 LsWaitAfterDialingOut : 133,TDX_CALLP,9,0,0,CR_NORB,,

103028.921 6 1 state Human answer. Start [C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12805.vgs]

103038.343 18 1 CDR (out) : "12805","17874782634","","","","0","","C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12805.vgs","","2009-02-06 10:29:46","NULL","2009-02-06 10:30:38",52,0,"NOANSWER",""

 

103143.750 10 1 state Dialing 17874782634

103236.921 18 1 CDR (out) : "12806","17874782634","","","","0","","C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12806.vgs","","2009-02-06 10:31:43","NULL","2009-02-06 10:32:36",53,0,"ANSWERED_HUMAN",""

[Guest BlackBird]

Sorry, I forgot to send the file, I will do so as soon as I get access to the machine.

 

Also I will proceed to download the latest VG7 version as you recommended in order to fix the bug (would not correctly classify this then in the CDR log) in my current version.

 

Prior to download and installing the latest version of VG7, I would like to confirm with you the following: there were private component build drops to fix bugs I found with ktTtsSapi.dll (http://voiceguide.com/forums/index.php?s=&showtopic=5916&view=findpost&p=26421 ) and another issue with MS SQL ( http://voiceguide.com/forums/index.php?sho...amp;#entry26256 ) - would your build process include these fixes in the latest release? or would I need to continue to apply the KtTtsSapi.dll in order to prevent the old bug from reappearing.

 

 

-r

[SupportTeam]

would your build process include these fixes in the latest release?

Yes. All previous bug fixes are included in newer releases.

[Guest BlackBird]

I downloaded and installed the latest version of VoiceGuide 7 and produced a fresh set of logs with it (attached zip file, includes the RecAm_), while calling two phones I own.

 

The current behavior when answered by a human is:

 

a. When loading and calling two phone numbers (concurrent calls scenario), both numbers rang, but to one number the message was delivered and to the other number the message was not.

 

With the second number where the phone rang but the message was not delivered, the entry was tagged in the CdrOut as BUSY, and again the entry was removed from the Callque table without exhausting the retry attempts (set to 3). Imo, if the number is not answered_human or answered_machine, shouldn't it remain in the Callque table until the retry attempts = 0? at which time then the entry is removed from the callque table.

 

 

b. When calling one number (478....) the message was delivered, but there was about a 5 second delay before the message was delivered.

 

regards,

-r

RecAm_3.zip

[SupportTeam]

Looks like in this version the "NO_RINGBACK" type answer bug was still not fixed. Will check on this and should be able to provide a version where this fix was included in by Monday.

 

a. When loading and calling two phone numbers (concurrent calls scenario), both numbers rang, but to one number the message was delivered and to the other number the message was not.

Trace shows that script was started in both cases. The script extract indicates that message was played at 02:36:15 on the call on line 1.

 

With the second number where the phone rang but the message was not delivered, the entry was tagged in the CdrOut as BUSY, and again the entry was removed from the Callque table without exhausting the retry attempts (set to 3). Imo, if the number is not answered_human or answered_machine, shouldn't it remain in the Callque table until the retry attempts = 0? at which time then the entry is removed from the callque table.

The CDR was has wrong value as per bug above. When the Dialogic card returns "NO_RINGBACK" type answer then it means that the Dialogic card never heard any Ringback tones, and it did not hear any speech that it can categorize as Answering Machine or Human. Eventually it times out and reports a "NO_RINGBACK" event, which theoretically should be treated as an answer, although in practice it probably isn't. Hence looks like there was a bit of confusion over how to treat this case.

 

NB. If you want more reliable answer detection you should look at using T1/E1 ISDN lines. You would not get "NO_RINGBACK" type events on T1/E1 ISDN lines. As you are finding out you cannot tell on analog lines with 100% accuracy whether outgoing call has been answered or not - so you cannot really treat CDRs as 100% accurate for outgoing calls. For 100% ANSWER/NOANSWER/BUSY accuracy you need ISDN.

 

b. When calling one number (478....) the message was delivered, but there was about a 5 second delay before the message was delivered.

If the Dialogic card reports an AnsweringMachine answer then the start of script will be delayed until the Dialogic card hears about 2-3 seconds of silence on the line. This is the delay that you may be seeing.

 

 

023533.078 6 1 state Dialing 17874782634...

 

023533.125 6 3 state Dialing 17877916831...

 

023543.531 6 3 state Machine Answer. Wait for end of welcome message...

 

023551.031 6 3 state [Play 1] Playing wav (C:\Inetpub\wwwroot\Vocalico\Audiofiles\12812_NoConfirm.wav)

 

023604.906 6 3 CDR (out) : "12812","17877916831","","","","0","","C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12812AnsMach.vgs","","2009-02-07 02:35:33","NULL","2009-02-07 02:36:04",32,0,"ANSWERED_MACHINE",""

 

023615.250 18 1 ev Dialogic 133,TDX_CALLP, crn=20000001, 9,0,0,CR_NORB,,

023615.250 18 1 qScr add evScriptEvent 133 TDX_CALLP

023615.250 6 1 qScr run evScriptEvent TDX_CALLP, iActionID=0, crn=20000001[9|0|0|0|0][CR_NORB|||||]

023615.250 6 1 ScriptEvent TDX_CALLP CR_NORB||

 

023615.250 6 1 state [Play 1] Playing wav (C:\Inetpub\wwwroot\Vocalico\Audiofiles\12812_NoConfirm.wav)

 

023629.062 6 1 CDR (out) : "12812","17874782634","","","","0","","C:\Program Files\VoiceGuide\Scripts\VocalicoUserJobs\12812.vgs","","2009-02-07 02:35:33","NULL","2009-02-07 02:36:29",56,0,"NOANSWER",""

[Guest BlackBird]

Thank you, for the clarification with regards to item #a., I look forward to the new build, and sorry for creating more work to your team due to the pesky bugs..

 

NB. If you want more reliable answer detection you should look at using T1/E1 ISDN lines. You would not get "NO_RINGBACK" type events on T1/E1 ISDN lines. As you are finding out you cannot tell on analog lines with 100% accuracy whether outgoing call has been answered or not - so you cannot really treat CDRs as 100% accurate for outgoing calls. For 100% ANSWER/NOANSWER/BUSY accuracy you need ISDN.

 

I am looking for a reasonable compromise without resorting to a T1/E1 ISDN line - due to cost when looking at the initial volume of calls we will sustain.

I should mention that for this test, I am interfacing an analog Dialogic card to broadband via a SIP adapter (Linksys SPA8000), using Callcentric as the VOIP provider, I am hoping that tweaking either the SIP adapter settings or perhaps changing Callcentric my yield (while not perfect, but) better results. Any recommendations specific to my current settings would be welcome..

 

 

If the Dialogic card reports an AnsweringMachine answer then the start of script will be delayed until the Dialogic card hears about 2-3 seconds of silence on the line. This is the delay that you may be seeing.

 

The odd thing is that I pick up the line and greet the call, before the fifth ring, which is usually when the AM kicks in. Is there a way to optimize this behavior by changing parameters in the vg.ini? Are there any known good values that would rectify or curb this behavior for the following params?

SilenceDetectLevel=

AM_SilenceDetectLength=

AM_SilenceDetectLevel=

AM_WelcMsgMinLen=

 

-r

[SupportTeam]

The odd thing is that I pick up the line and greet the call, before the fifth ring, which is usually when the AM kicks in. Is there a way to optimize this behavior by changing parameters in the vg.ini? Are there any known good values that would rectify or curb this behavior for the following params?

You can try reducing the AM_SilenceDetectLength parameter but then in situations where call is answered by answering machine you are more likely to have the system start the script before the answering machine starts recording.

[Guest BlackBird]

I modified, the parameter you recommended, after a bit of trial and error, it seems that the level of 30 (3 seconds) seems like a good compromise.

 

One thing I noticed, is that when a human picks up the phone, the person needs to raise their voice, almost yelling, in order for the call not to be classified "AnsweringMachine". Would the "SilenceDetectLevel" parameter (currently set at 10) be the param to modify in order to break the silence detection while speaking at a lower tone? thus a normal tone of voice would be detected as HumanAnswered instead.

 

[SupportTeam]

The silence detection is only used to determine when the answering machine message has finished. That setting does not affect the Live vs Machine discrimination.

 

Below is some more info that you may want to look into, although Dialogic’s default settings are probably the best compromise settings and we recommend you leave them as they are.

 

 

 

With current v7 you are able to access all entries in the Dialogic DX_CAP structure, which includes Dialogic's low level settings.

eg settings which affect the Answering Machine / Live Answer detection timeouts:

 

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>

[Guest BlackBird]

Thanks for leading me in the direction of the Dialogic API, I looked at it last week, frankly it look a bit daunting, with the recommended params you pointed out the information seems a bit easy for me to digest.

 

I also noticed that in my broadband line there seems to be quite a bit of noise (background interference) so I will look into that, since, as I understand from talking to a local Telco, the interference could make a difference in the detection.

 

regards,

-r

[Guest BlackBird]

sorry, I did mean to ask on my previous posting, since the control of the Dialogic settings is based on a per-call basis - I would like to confirm that the following understanding on my part is correct:

 

After I alter the value of either of the following Dialogic settings:

 

ca_cnosig

ca_noanswer

ca_pamd_failtime

 

and later on, I perform an outbound call where the CallOptions field is left blank (null), would the default values be reinstated for the above parameters? or would I need to explicitly assign the default values?

 

Btw, kudos for the great design feature in VG7, to allow the modification of these low level Dialogic settings.

 

-r

[SupportTeam]

there seems to be quite a bit of noise (background interference) so I will look into that, since, as I understand from talking to a local Telco, the interference could make a difference in the detection.

Background noise would definitely affect Human/Machine detection.

 

The <DX_CAP> values would need to be set in the CallOptions field for every call on which you want the custom values used. The Call Options setting apply only to call for which they are defined and do not affect other calls.

 

Sounds like you should really get the background noise sorted out first. Its the background noise that is most likely the cause of the problems.

[SupportTeam]

BTW. the silence detection length can be set on a per-call basis by adding a statement like this to the CallOptions field:

 

<TPT><DX_MAXSIL>15</DX_MAXSIL></TPT>

 

the MAXSIL value is in 100ms units, so a value of 15 corresponds to 1.5 seconds.

[SupportTeam]

The CR_NORB CDR classification should be fixed in this version:

[old link removed]

In the "NORINGBACK" cases the connection result reported in the CDR will be ANSWERED_NORINGBACK

[Guest BlackBird]

Thank for the updates on post #19 & #20

 

I am investigating with Callcentric (my VOIP provider) the static noise issue, while that is getting sorted out, I downloaded the latest release of VG7 from the site, since the Voiceguide link provided in post #20 generates a web page error (404)

 

Here is what I got so far:

1. At CallCentric's request I updated the following SIP adapter settings - RTP Packet Size; changed from 0.030 to 0.020, change the codec from 729a to 711u. After testing I found that the RTP Packet Size set at 0.020 with coded 729a yielded better results.

 

2. With the latest VG7 version installed I performed a few calls, and noticed that calls that are tagged "ANSWERED_NORINGBACK" where removed from the Callque table, no further retries were made to complete these type of calls.

 

3. I also performed a few calls where both lines where busye, and noticed that calls that are tagged "BUSY" remained from the Callque table, the calls where retried as expected.

 

4. I also noticed improvement in the detection (Human vs. AM), when passing the following Dialogic api arguments within the Calloptions field:

<DX_CAP><ca_cnosig>4000</ca_cnosig><ca_pamd_failtime>4000</ca_pamd_failtime></DX_CAP>

 

Although, I noticed better results, these where consistent, since at times I experienced long delays before the message was delivered.

 

 

With regards to items number 2 (above), should calls tagged "ANSWERED_NORINGBACK" be sent to the Callque table until the retries attempt is exhausted?

 

regards,

-r

 

 

 

 

 

[SupportTeam]

With regards to items number 2 (above), should calls tagged "ANSWERED_NORINGBACK" be sent to the Callque table until the retries attempt is exhausted?

On analog lines hearing no ringback (and no other tones) means that call was answered immediately, before the line even started for ringing for long enough for Dialogic to detect the Ringing. This behavior is the accepted as the correct choice by Dialogic and that's how Dialogic treats this case as well.

 

We can change the VoiceGuide software to let it treat the ANSWERED_NORINGBACK the same as "BUSY", but that would require a custom modification to the software just for you. Contact sales@voiceguide.com if you would like to look into getting this done.

 

Reliance on tone detection to determine outbound call progress is the reason why analog lines are rarely used for professional outbound solutions, and T1/E1 ISDN is used.

[Guest BlackBird]

On this thread:

post #7 ( http://voiceguide.com/forums/index.php?sho...ost&p=26914 ) and

post # 11 ( http://voiceguide.com/forums/index.php?sho...amp;#entry26929 )

 

it was mentioned that the "NO_RINGBACK" was a known issue to be fixed.

 

Looks like in this version the "NO_RINGBACK" type answer bug was still not fixed. Will check on this and should be able to provide a version where this fix was included in by Monday.

 

the above statement, was made in the context of calls classified "N0_RINGBACK" are being removed out of the callque table without exhausting the retry attempts, so I am a bit confused, if the Callque removal behavior was not the bug fixed, then, could you please share, what was the bug fix about with the new release of VG 7 (v7.0.9_09...) ?

 

On analog lines hearing no ringback (and no other tones) means that call was answered immediately, before the line even started for ringing for long enough for Dialogic to detect the Ringing. This behavior is the accepted as the correct choice by Dialogic and that's how Dialogic treats this case as well.

 

Please let me contribute my two humble cents with the following:

 

a. During my test the calls are answered after the 2nd to 3rd ring, with the VG line status monitor open to track the call transaction - no calls where answered without being active in the line status monitor, which believe obtains its status comes from the Dialogic card, thus, the Dialogic card had long enough to detect the transaction.

 

b. I am not using analog lines to place my calls, I think I clarified my VOIP set up on post #12 on this thread.

 

c. Even if Dialogic accepted the behavior, the end result is erratic, meaning the outbound message is not delivered. Since VG has the ability to catch/trap this specific status, IMO, correcting the end user result (allow the call to be retried, when the retries is set to be > 0) would make VG7 a more robust and reliable product, making it an even better product beyond what it already is, that is, in my book VG as a product and its support team rocks!

 

-r

[SupportTeam]

what was the bug fix about with the new release of VG 7

To correctly classify this case in the CDR logs.

 

a. During my test the calls are answered after the 2nd to 3rd ring, with the VG line status monitor open to track the call transaction - no calls where answered without being active in the line status monitor, which believe obtains its status comes from the Dialogic card, thus, the Dialogic card had long enough to detect the transaction.

The number was dialed, but looks like the Dialogic card was not detecting any ringback tones. You may need to set the RINGBACK tone definitions in ConfigLine.xml to better match the tones played. This topic shoes how to set the tones: http://www.voiceguide.com/vghelp/source/ht...ctiondetect.htm

 

b. I am not using analog lines to place my calls, I think I clarified my VOIP set up on post #12 on this thread.

You are using a VoIP<->Analog converted and the analog connection is attached to the Dialogic card, right? Traces show that you are using an Analog Dialogic card (D/41JCT ?).

 

As it looks like that Ringbacks sometimes get detected and sometimes do not it's possible that the VoIP<->Analog adapter is not playing them back reliably. Some VoIP<->Analog adapters have such issues. But it may be a good idea to confirm what those tones are and confirm that ConfigLine.xml is setup appropriately.

 

Treating the 'NoRingback' situation as 'Answered' is on balance the right choice. If the number cannot be reached the PBX/Switch (or the VoIP Adapter) should play a tone (disconnect/busy/etc). In absence of any disconnect/busy/etc tones silence should be treated as an answered call. This is how Dialogic classifies this situation and on balance treating this situation as 'answered' is the more correct choice then treating it as 'not answered'. If silence was to be treated as not answered it means that there is an error with the PBX/Switch playing (or Dialogic detecting) the appropriate disconnected/busy/etc tones, and you should look at fixing this error rather then trying to treat silence as ‘not answered’.

[Guest BlackBird]

you should look at fixing this error rather then trying to treat silence as ‘not answered’.

 

At the end of the day, my experience has been so far that the outbound message is not delivered consistently when "NO_RINGBACK" is encountered, thus I can't treat silence as answered. If the consistency remains during the rest of my tests then I do have an easier fix, which is to write a trigger in SQL so that when the specific error is found in the Cdrout table, then the entry is re-entered into the Callque table for another attempt. This fix is more attainable (at least for me) than the alternative fixes (endless tweaks of the adapter, config the tone definition, etc.)

 

btw, thanks for the excellent pointers and feedback!

 

-r

[Guest BlackBird]

Just wanted to bring up one more behavior, this afternoon I received new SIP adapter settings instructions from Callcentric (my VOIP supplier).

 

In order to create a new baseline, before making the changes to my sip adapter settings, I stopped and restarted VG7 (no other changes were made,) using the Outbound Call Loader VG7 dialed my trusty phone, but, while looking at Line Status, I noticed that every attempt to dial out was met with a "Hanging up...[CR_CEPT in LsWaitAfterDialingOut]", this is the first time I noticed this error.

 

Thinking that the problem comes from my VOIP account or SIP adapter, I connected a conventional phone and was able to dial out without any issues. I then proceeded to modify the SIP adapter to match Callcentric's recommendations:

 

RTP Packet Size: 0.20

Network Jitter Level: low

Jitter Buffer Adjustment: down only

 

With the new settings, when dialing out using my conventional phone the difference with regards to the Voice clarity/quality its amazingly good, no operator intercept tones, no longer I hear the static noise associated with previous calls. However, when I attempt to dial out using VG7, I continue to get the following error "Hanging up...[CR_CEPT in LsWaitAfterDialingOut]", where does this new error comes from? Can I change settings in the vg.ini to fix it? I tried padding the phone number with a few commas, but no luck, any ideas? Please, see attached log files.

 

regards,

-r

vgEngine.zip

[SupportTeam]

CR_CEPT means that the Dialogic card detected a SIT (a Tri-tone, also known as Operator Intercept tone). A Tri-tone means that the call cannot be made.

 

140509.078 18 1 ev Dialogic 133,TDX_CALLP, crn=20000001, 11,0,0,CR_CEPT,999Hz 0ms | 0Hz 0ms | 0Hz 0ms,

 

Noise on the line can result in false detections of this. Another user who also uses a VoIP adaptor has had similar problems recently. see: http://voiceguide.com/forums/index.php?showtopic=6012

 

Suggest you try using the blow in the CallOptions:

 

<DX_CAP><ca_lowerfrq>1500</ca_lowerfrq></DX_CAP>

[Guest BlackBird]

Thank you, Thank you, for the pointer....

 

At first I tried <DX_CAP><ca_lowerfrq>1500</ca_lowerfrq></DX_CAP>

but I received an error along the lines of "CR_ERROR"

 

I then tried <DX_CAP><ca_lowerfrq>999</ca_lowerfrq></DX_CAP>

no errors and the outbound call was placed successfully.

 

I played around with the Dialogic api switches, and found a pretty good compromise with the following combination of switches:

 

<DX_CAP><ca_cnosig>1250</ca_cnosig>

<ca_pamd_failtime>1250</ca_pamd_failtime>

<ca_lowerfrq>999</ca_lowerfrq></DX_CAP>

 

The end result is that the call detection has improved, and the outbound message is being delivered consistently. I will continue to test with the new api values while calling a wider audience.

 

I really appreciate your support and guidance!

 

Regards,

-r

[Guest BlackBird]

In order to get closure with the issue raised initially in this thread, I want to share with you my latest test findings (and pop a few questions):

 

1. I placed a number of calls while using the Calloptions api switches mentioned in thread #28, despite my optimism about the Dialogic api switches, the bottom line is that the amount of outbound calls found with the condition "NORINGBACK" or where Dialogic determined that the answerer was an AM even though a Human answered the call (which led to erratic message delivery) yielded a high percentile (over 60% + ) of undelivered calls.

 

2. In an effort to eradicate what I believe is the culprit of my the high failure to deliver outbound messages, I attempted to isolate the source of the interfering static noise found during every call made from my system. I have two broadband lines in my office, one DSL and one Cable, after a series of test via both lines I determined that the Dialogic card, the SIP adapter or the SIP adapter settings, where not the source. I installed a softphone (x-lite) in my system and placed outbound calls while alternating the broadband source between my dsl provider and my cable provider, and found that the source of the noise to be my VOIP provider, since the presence of interfering noise was consistent during the test calls using the softphone as well.

 

that said, in the interest to find a solution, I got the following questions:

 

a. Based on your interactions with the Voiceguide community, could you recommend a VOIP carrier (my calls are mainly to the US and US territories) being used by other VG users, where the outbound call success rate is reasonably high?

 

b. Picking up on your recommendation to rely on a T1/E1 ISDN connection (thread #22) (disclaimer: I am a novice on telco so please forgive my raw/rough understanding):

• If I rely on a T1/E1 ISDN connection, I would need to have a VOIP provider, correct? if yes, then..
• Since in my case the VOIP provider service is generating the noise, how would a T1/E1 ISDN help solving the noise interference issue which hurts the Dialogic detection between AM and Human?
• For my initial call volume a T1 would be a wee bit too much (in terms of bandwidth and cost) are you aware of companies that would lease fractionated T1/E1 ISDN connection in chunks of 256kbs?
• Could the Dialogic D/240JCT-T1 be used with a fractionated T1/E1 ISDN connection?
• My plan is to start with 8 active lines, I know that on my final implementation Voiceguide would use the number of active licenses only, but I am not sure about managing the resources on the Dialogic D/240JCT-T1. On the card, would I be able to activate ports 1 to 8 and deactivate the reamaining 16 ports to prevent VG from placing calls via an invalid port?

Regards,

-r

[SupportTeam]

the bottom line is that the amount of outbound calls found with the condition "NORINGBACK" or where Dialogic determined that the answerer was an AM even though a Human answered the call (which led to erratic message delivery) yielded a high percentile (over 60% + ) of undelivered calls.

If you are getting a high percentage of NORINGBACK situations then maybe you have not setup the tone detection parameters (for ringback/busy/etc tones). You need to configure these tones in the ConfigLine.xml file if you are using analog lines for outbound calls.

 

and found that the source of the noise to be my VOIP provider, since the presence of interfering noise was consistent during the test calls using the softphone as well.

Yes. That's fairly common. That is why the cheap VoIP provider are not used for professional IVR systems. Human vs Machine discrimination is affected by any background noice.

 

a. Based on your interactions with the Voiceguide community, could you recommend a VOIP carrier

No. And especially not on outbound calls.

 

If I rely on a T1/E1 ISDN connection, I would need to have a VOIP provider, correct?

No. ISDN services are supplied directly by Telcos and these services provide you with a digital 8kHz voice path that is usually not altered/degraded/compressed along the way.

 

For my initial call volume a T1 would be a wee bit too much (in terms of bandwidth and cost) are you aware of companies that would lease fractionated T1/E1 ISDN connection in chunks of 256kbs?

T1 lines are not leased in kbps, the count of voice channels enabled is used. You would need to contact telcos in your local area to see which ones can supply a T1 to your premises.

 

Could the Dialogic D/240JCT-T1 be used with a fractionated T1/E1 ISDN connection?

Yes.

 

My plan is to start with 8 active lines, I know that on my final implementation Voiceguide would use the number of active licenses only, but I am not sure about managing the resources on the Dialogic D/240JCT-T1. On the card, would I be able to activate ports 1 to 8 and deactivate the reamaining 16 ports to prevent VG from placing calls via an invalid port?

You just specify in Config.xml which channels on the D/240JCT VoiceGuide should open. VoiceGuide will not use ports that it was not told to open.