Outbound Call Problem

[Guest fmonroy]

Hello, I have a problem generating calls:

VoiceGuide for Dialogic 6.0.3310

 

It dials correctly and the line rings.

When it reaches the timeout the "Waiting for a call..." message appears, but the line keeps ringing and don't stop until I close and reopen VoiceGuide, then it resets the line and the call ends.

 

It doesn't happen using the TAPI version of VoiceGuide.

 

What configuration parameters should I compare and change to get the same behavior in both versions?

 

Thank you.

[SupportTeam]

What lines are you using to dial out?

 

Could you please post a copy of VoiceGuide's Trace Logs which captures the outgoing call, this will allow us to see what happened.

 

Enable logging by setting the log levels to 10 in VG.INI as per below:

[Log]

 

VoiceGuide=10

 

ktTel=10

Then restart VG and make a test call which demonstrates the problem.

 

Trace files will be created in VG's \log\ subdirectory.

 

Please post the traces.

 

When posting traces/scripts please .ZIP them up and post them as attachments.

[Guest fmonroy]

What lines are you using to dial out?

The first line of a D4/PCI.

 

Could you please post a copy of VoiceGuide's Trace Logs which captures the outgoing call, this will allow us to see what happened.

Sure, they are attached.

Logs.zip

[SupportTeam]

Trace shows that VoiceGuiude did hangup.

 

The system made a call at 5:07pm:

 

170740.19 1 dial [4,5643046,703191707,1,2359,MoTuWeThFrSaSu,[,,1,,],3,NONE,D:\Test\Test.vgs,D:\Test\Test.vgs,none,15,1,1,,none] (search started at 170740.19)

 

170740.19 1 dial DialOnLine start tel[5643046] ann[NONE] vgs[D:\Test\Test.vgs] am[D:\Test\Test.vgs] rv[none] cid[]

 

and about 15 seconds after dialing (which is the timeout within which you specified call must end if not answered) VoiceGuide ended the call by hanging up:

 

170757.98 1 state Hanging up call... [EV_TIMEOUT_MAKECALL_NORESPONSE]

 

And Dialogic card confirmed it has placed the line back on-hook:

 

170758.000 001 ocxfn LineDrop(sLineId=1, sOpt=0)

170758.000 001 dx_sethook(1) call

170758.015 001 dx_sethook 1 DX_ONHOOK ok

170758.015 001 ev TDX_SETHOOK (SetHook Completed)

 

170758.03 1 tw DialogicEvent 135,TDX_SETHOOK,0,0,0,DX_ONHOOK,,

 

If the destination telephone is still ringing you should ask your phone company why are then continuing with the call when you hung up the.

 

Easy test to do is to unplug the line from the Dialogic card and plug it into a telephone handset, then make a call using the handset and hangup after destination phone starts ringing, and see if the destination continues to ring...

[Guest fmonroy]

I noticed that, the problem is not with the line, let me repeat something in the post:

It doesn't happen using the TAPI version of VoiceGuide.

So again:

What configuration parameters should I compare and change to get the same behavior in both versions?

[SupportTeam]

Have you done a test with a telephone handset using the same line and calling the same number (5643046) ?

 

Another test you should try is this:

 

In Config.xml set the <AllowDialout> field to be "1" for only the first line and "0" for all others - so only first line can make outgoing calls.

Then load 2 or more calls into the system (each call to a different number) and see how the different numbers ring. If the line attached to the Dialogic card is not hung up properly by the then the second call will not ring the second number.

 

Use the 15 second timeout as in previous example - that way the line is hung up after 15 seconds and the next call is made.

[Guest fmonroy]

Have you done a test with a telephone handset using the same line and calling the same number (5643046) ?

I did it several times, dialing into that number when hung up, it stopped to ring: normal behavior.

 

Another test you should try is this:

 

In Config.xml set the <AllowDialout> field to be "1" for only the first line and "0" for all others - so only first line can make outgoing calls.

Then load 2 or more calls into the system (each call to a different number) and see how the different numbers ring. If the line attached to the Dialogic card is not hung up properly by the then the second call will not ring the second number.

 

Use the 15 second timeout as in previous example - that way the line is hung up after 15 seconds and the next call is made.

Done. It dialed the first number, it started to ring, then at the 15 secs timeout, the colsole said that it was ready to receive calls but it was still ringing.

 

After 3 secs it said that it was dialing to the other number but the same line was ringing, after the 15 secs timeout it was the same and beyond that 15 secs. Then I restarted VG and it stopped.

 

I'm sending logs from this test.

 

It seems like the dialogic card is not receiving correctly the signal to hang the call.

 

The weird thing is that using the TAPI version it works well.

 

I'm at Mexico, maybe some signaling is different and need to be configured at VG for Dialogic.

 

What you think?

 

 

Thank you.

Test.zip

[SupportTeam]

Traces show your Dialogic card is acting like it did hangup the first call after timeout and it then did pickup the line again after a few seconds and dial the second number.

 

We did a similar test on our test system here and fist call was hung up when connection timeout was reached and a new call was made ok on the same line.

 

Below are traces from your system. Dialogic card is responding as expected.

Can you try using different phone lines?

 

004737.05 1 state Dialing 5643046

004737.08 1 timer set 15 EV_TIMEOUT_MAKECALL_NORESPONSE

004737.63 1 LsWaitAfterDialingOut : 135,TDX_SETHOOK,0,0,0,DX_OFFHOOK,CALL_OUTBOUND,

004753.42 1 timer fired EV_TIMEOUT_MAKECALL_NORESPONSE

004753.42 1 DialoutProcessFailedDial start sCalledFrom=[LsWaitAfterDialingOut-EV_TIMEOUT_MAKECALL_NORESPONSE] RetriesLeft=0

004753.45 1 rvns add [OutDial_Result]{Uncontactable_Timeout}

 

004756.13 1 state Dialing 0446861695633

004756.16 1 timer set 15 EV_TIMEOUT_MAKECALL_NORESPONSE

004812.45 1 timer fired EV_TIMEOUT_MAKECALL_NORESPONSE

004812.45 1 DialoutProcessFailedDial start sCalledFrom=[LsWaitAfterDialingOut-EV_TIMEOUT_MAKECALL_NORESPONSE] RetriesLeft=0

004812.45 1 rvns add [OutDial_Result]{Uncontactable_Timeout}

 

 

 

004737.046 001 ocxfn LineMakeCall(linedev=1, hcall=0, 5643046, callprog=DX_PAMDOPTEN, timeout=15, params:[0,0,cid=,]) chdev=1, dtidev=0

004737.078 dx_sethook(1, DX_OFFHOOK) ok

004737.609 001 ev TDX_SETHOOK (SetHook Completed)

004737.609 001 loop current is present. RLS_LCSENSE flag not set.

004737.906 dx_dial([5643046], with call progress) ok

004753.515 001 ocxfn LineDrop(sLineId=1, sOpt=0)

004753.515 001 dx_sethook(1) call

004753.515 001 dx_sethook 1 DX_ONHOOK ok

004753.515 001 ev TDX_SETHOOK (SetHook Completed)

004753.531 001 ocxev DoFireDialogic(dwIdx=9, 1, 135, [TDX_SETHOOK], 0, 0, 0, [DX_ONHOOK], [], []) (dwIdx=9)

004753.531 001 ev TDX_CALLP (Call Progress Completed)

004753.531 001 TDX_CALLP CR_UNKNOWN (unknown:53)

004753.546 001 ev TDX_CST (CST Event Received)

004753.546 001 ev TDX_CST DE_LCON data=65535

004753.546 001 ocxev DoFireDialogic completed

004753.546 001 te LINE_CALLSTATE(1, 0x1, 0x1, 0x0, 0x0) LINE_CALLSTATE-LINECALLSTATE_IDLE

 

 

 

004756.125 001 ocxfn LineMakeCall(linedev=1, hcall=0, 0446861695633, callprog=DX_PAMDOPTEN, timeout=15, params:[0,0,cid=,]) chdev=1, dtidev=0

004756.156 dx_sethook(1, DX_OFFHOOK) ok

004756.156 001 ev TDX_SETHOOK (SetHook Completed)

004756.156 001 loop current is present. RLS_LCSENSE flag not set.

004756.437 dx_dial([0446861695633], with call progress) ok

004756.437 001 ev TDX_CST (CST Event Received)

004756.437 001 ev TDX_CST DE_LCON data=65535

004812.484 001 ocxfn LineDrop(sLineId=1, sOpt=0)

004812.484 001 dx_sethook(1) call

004812.500 001 dx_sethook 1 DX_ONHOOK ok

004812.500 001 ev TDX_SETHOOK (SetHook Completed)

004812.500 001 ocxev DoFireDialogic(dwIdx=15, 1, 135, [TDX_SETHOOK], 0, 0, 0, [DX_ONHOOK], [], []) (dwIdx=15)

004812.500 001 ocxev DoFireDialogic completed

004812.500 001 te LINE_CALLSTATE(1, 0x1, 0x1, 0x0, 0x0) LINE_CALLSTATE-LINECALLSTATE_IDLE

004812.500 001 ev TDX_CALLP (Call Progress Completed)

004812.500 001 TDX_CALLP CR_UNKNOWN (unknown:48)

[Guest fmonroy]

No, I have no more lines, but they are working well, the problem is not in the lines, it's in the VG configuration; I know this because the TAPI version works perfect with the same card and with the same lines calling to the same number.

 

I see a lot of configuration options at the xml files about frequencies, timing and so, but I have no idea how are they handled. Do you have any guide to configure these parameters?

[SupportTeam]

None of the parameters in Config xml files affect the basic command of the Dialogic card picking up the line (equivalent of picking up the handset) and then hanging up the line (equivalent of hanging up the handset).

 

We see in traces that when VG tells the Dialogic card to pickup and hangup the Dialogic card responds that it has done that.

 

Traces showed the dialing also seems fine.

 

The most likely explanation would be that the PBX/Switch is not detecting the hangup.

 

Don’t know why the TAPI version's hangup would be detected while the Dialogic version's hangup would not be detected.

 

There is nothing in Config xml files to affect how the hangup is performed. A hangup just like putting the handset on hook (which breaks the electrical loop connection). There are no 'different types' of hangup on analog systems. It's just like placing the handset 'on hook' at that's it.

[Guest fmonroy]

It's good to know that. I will reinstall the dialogic drivers; maybe the problem is corrupted software.

 

I will let you know results.

 

Thank you.

[SupportTeam]

Also run tests with outgoing calls timing out 60 (or more) seconds after dialing out, just to make sure it's not timing related.

Did you use 15 second timeouts with TAPI version?

[Guest hogi]

I experienced the same problem myself but after making sure all the scripts ends with the "hangup module" and "enabled" disconnect tone in the DCM manager th eproblem went away.

[Guest fmonroy]

Wow, a lot of tests, and it is going weirder!

 

I experienced the same problem myself but after making sure all the scripts ends with the "hangup module" and "enabled" disconnect tone in the DCM manager th eproblem went away.

Hogi, it's is behaving the same way after changing that parameter.

 

I will explain the scenario:

 

175041.78   1 dial  [17,5643046,703211750,1,2359,MoTuWeThFrSaSu,[,,],3,NONE,D:\Test\Test.vgs,D:\Test\Test.vgs,none,30,0,1,,none] (search started at 175041.77)
175041.78   1 dial  DialOnLine start tel[5643046] ann[NONE] vgs[D:\Test\Test.vgs] am[D:\Test\Test.vgs] rv[none] cid[]
175041.78   1 rv    clear all
175041.78   1 rv    add [OutDial_RetriesLeft]{0}
175041.78   1 dial  making call tel[5643046] ann[NONE] vgs[D:\Test\Test.vgs] am[D:\Test\Test.vgs] OnHangup[] rv[none[OutDial_RetriesLeft]{0}]
175041.78   1       script interpretor: VgMulti v6.0.3310
175041.80   1 state Dialing 5643046
175041.83   1       lineMakeCall=>[]
175041.83   1 timer set 30  EV_TIMEOUT_MAKECALL_NORESPONSE
175042.38   1 tw    DialogicEvent 135,TDX_SETHOOK,0,0,0,DX_OFFHOOK,CALL_OUTBOUND,
175042.38   1 event TDX_SETHOOK, iCode=135 state=5200
175042.38   1       LsWaitAfterDialingOut : 135,TDX_SETHOOK,0,0,0,DX_OFFHOOK,CALL_OUTBOUND,

Dialing and all seems to be happy until here.

 

After that

 

175102.89   1 tw    DialogicEvent 133,TDX_CALLP,10,1,0,TDX_CALLP,CR_CNCT,CON_CAD
175102.89   1 event CADENCE, iCode=133 state=5200
175102.89   1       LsWaitAfterDialingOut : 133,CADENCE,10,1,0,CR_CNCT,CON_CAD,
175102.89   1 event CONNECT, iCode=133 state=5200
175102.89   1       LsWaitAfterDialingOut : 133,CONNECT,10,1,0,CR_CNCT,CON_CAD,
175102.89   1 event CON_CAD, iCode=133 state=5200
175102.89   1       LsWaitAfterDialingOut : 133,CON_CAD,10,1,0,CR_CNCT,CON_CAD,
175102.91   1 event CR_CNCT, iCode=133 state=5200
175102.91   1       LsWaitAfterDialingOut : 133,CR_CNCT,10,1,0,CON_CAD,,
175102.91   1 event TDX_CALLP, iCode=133 state=5200
175102.91   1       LsWaitAfterDialingOut : 133,TDX_CALLP,10,1,0,CR_CNCT,CON_CAD,
175102.91   1       LineEvCallState_OutgoingCallWasAnswered 10,1,0
175102.91   1 init  OnCallAnswered_StartScript start
175102.91   1 init  StartLoadedVgs_InitLineState start
175102.91   1 rv    add [$RV_STARTTIME]{21/03/2007 5:51:02 PM}
175102.91   1 rv    add [$RV_DEVICEID]{1}
175102.91   1 rv    add [DlgcNetworkResource]{dxxxB1C1}
175102.91   1 rv    add [DlgcVoiceResource]{dxxxB1C1}
175102.91   1 rv    add [$RV_CIDNAME]{}
175102.91   1 rvns  add [PathApp]{C:\Program Files\VoiceGuide for Dialogic\}
175102.91   1 WARN  rv ScriptsPath could not be set as LineState(iLineId).iVgsIdx = 0 in StartLoadedVgs_InitLineState
175102.91   1 rv    add [$RV_CALLEDNUMBER]{5643046}
175102.91   1       set LineState().hCall = 603500 in OnCallAnswered_StartScript
175102.91   0 dial  callque delete id=17 (MSAccess)
175102.91   1 rvns  add [OutDial_Result]{Contacted_Human}

20 seconds elapsed and it said that someone answered the line (wrong because it was still ringing), then the script ran and at the hang up module executed it almost correctly ending the ringing.

 

After that I connected handset devices at both lines and dialed to check if some strange signal could be heard but nothing, just the ringing tone.

 

Do you know what those lines at 175102.89 say?

 

I think these are tone frequencies related and used PBXpert to train the lines. All worked fine but the disconnect tone, these are the results:

I recorded the Mix Output from the sound card and I'm attaching the sound file (the pitch is high, not the same as hearing directly at the handset): tones.mp3

The most weird is that TAPI version works perfect, even with 5 seconds timeout!!!

 

Any idea?

 

I will work temporarily on the TAPI version, but I'm interested to get it working, so I can send any information you need to diagnose the problem.

 

Thank you very much.

[SupportTeam]

Do you know what those lines at 175102.89 say?

They CON_CAD or CADENCE connection event indicates that the Dialogic card decided that call must have been answered as it timed out awaiting for ringback (ringing) signal to be present.

 

If the ringback tone definition is not set to match the ringback tone, then the Dialogic card will not hear the ringing and will decide that the outgoing call must have been answered as there is no ringing heard.

 

You should record the ringback/ringing tone, analyze it, and then set the ringback tone definition in ConfigLine.xml file appropriately.

[Guest fmonroy]

I found tones for Mexico in Internet, and are the same that PBXpert detects:

• Dial tone is 425Hz constant
• Busy / Disconnecet are: 425Hz, 250ms ON, 250ms OFF
• Ring / Ringback are: 425Hz, 1s ON, 4s OFF

This is how I configured ConfigLine.xml, can you please review it?

<Tone Name="Call Progress Tone TID_BUSY1">
<Notes>Default Setting</Notes>
<ID>TID_BUSY1</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>25</On>
<OnDev>5</OnDev>
<Off>25</Off>
<OffDev>5</OffDev>
<Count>3</Count>
</Tone>

<Tone Name="Call Progress Tone TID_BUSY2">
<Notes>Default Setting</Notes>
<ID>TID_BUSY2</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>25</On>
<OnDev>5</OnDev>
<Off>25</Off>
<OffDev>5</OffDev>
<Count>3</Count>
</Tone>

<Tone Name="Call Progress Tone TID_DIAL_LCL">
<Notes>Default Setting</Notes>
<ID>TID_DIAL_LCL</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>100</On>
<OnDev>0</OnDev>
<Off>0</Off>
<OffDev>0</OffDev>
<Count>0</Count>
</Tone>

<Tone Name="Call Progress Tone TID_DIAL_INTL">
<Notes>Default Setting</Notes>
<ID>TID_DIAL_INTL</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>100</On>
<OnDev>0</OnDev>
<Off>0</Off>
<OffDev>0</OffDev>
<Count>0</Count>
</Tone>

<Tone Name="Call Progress Tone TID_DIAL_XTRA">
<Notes>Default Setting</Notes>
<ID>TID_DIAL_XTRA</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>100</On>
<OnDev>0</OnDev>
<Off>0</Off>
<OffDev>0</OffDev>
<Count>0</Count>
</Tone>

<Tone Name="Call Progress Tone TID_DISCONNECT">
<Notes>Default Setting</Notes>
<ID>TID_DISCONNECT</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>25</On>
<OnDev>5</OnDev>
<Off>25</Off>
<OffDev>5</OffDev>
<Count>4</Count>
</Tone>

<Tone Name="Call Progress Tone TID_FAX1">
<Notes>Default Setting</Notes>
<ID>TID_FAX1</ID>
<Freq1>2150</Freq1>
<Freq1Dev>50</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>25</On>
<OnDev>25</OnDev>
<Off>0</Off>
<OffDev>0</OffDev>
<Count>1</Count>
</Tone>

<Tone Name="Call Progress Tone TID_FAX2">
<Notes>Default Setting</Notes>
<ID>TID_FAX2</ID>
<Freq1>1100</Freq1>
<Freq1Dev>50</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>25</On>
<OnDev>25</OnDev>
<Off>0</Off>
<OffDev>0</OffDev>
<Count>1</Count>
</Tone>

<Tone Name="Call Progress Tone TID_RNGBK1">
<Notes>Ringback 1 Default Setting</Notes>
<ID>TID_RNGBK1</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>100</On>
<OnDev>10</OnDev>
<Off>400</Off>
<OffDev>40</OffDev>
<Count>1</Count>
</Tone>

<Tone Name="Call Progress Tone TID_RNGBK2">
<Notes>Ringback 2 Default Setting</Notes>
<ID>TID_RNGBK2</ID>
<Freq1>425</Freq1>
<Freq1Dev>40</Freq1Dev>
<Freq2>0</Freq2>
<Freq2Dev>0</Freq2Dev>
<On>100</On>
<OnDev>10</OnDev>
<Off>400</Off>
<OffDev>40</OffDev>
<Count>1</Count>
</Tone>

After this change the events are generated the same way.

 

I think VG is not reading this file and working with some default values that are not compatible with Mexico's signaling, but only the dialer part when the line is still ringing. I think this because, when a script is running and it calls the hangup module, it works perfectly.

 

What do you think?

[SupportTeam]

The ringback definition is matching the specs you supplied.

 

It is best however to just record it using a Record module in VoiceGuide script and analyze it as per instructions in the Help file.

[Guest fmonroy]

I'm sure those are the correct frequences. I generated with pc and are exactly as heard from line.

 

Please check if that is a bug in the dialing phase.

[SupportTeam]

Ringback detection works fine on our test systems and we are for every person who has set the parameters correctly (you can look back though this forum for examples).

 

Suggest you record the ringback tone using VoiceGuide's Record module and confirm frequencies by analyzing the sound file.

[Guest fmonroy]

Hello guys, this is the analysis you suggested to do:

(I only get the disconnect tone from the record module; for the others I used speaker + mic, some noise at the signal but the results look good)

 

DialTone 425Hz Constant

RingBack 425Hz

9.600 ON

10.600 OFF

14.610 ON

15.610 OFF

19.613 ON

20.613 OFF

Disconnect Tone 426Hz

1.924 ON

2.244 OFF 0.32

2.564 ON 0.32

2.884 OFF 0.32

Busy Tone 425Hz

5.490 ON

5.966 OFF 0.476

6.482 ON 0.516

6.967 OFF 0.485

7.485 ON 0.518

7.967 OFF 0.482

 

In synthesis:

 

Dialtone: OK

Ringback: OK

Disconnect Tone: changes cadence

Busy Tone: changes cadence

 

I will test these new values and let you know.

[Guest fmonroy]

Same behavior: The system is detecting incorrectly an event, I need to know what it's detecting to correct it.

Can you please explain in detail what, every line and field here, mean?:

231559.09   1 tw    DialogicEvent 133,TDX_CALLP,10,1,0,TDX_CALLP,CR_CNCT,CON_CAD
231559.09   1 event CADENCE, iCode=133 state=5200
231559.09   1       LsWaitAfterDialingOut : 133,CADENCE,10,1,0,CR_CNCT,CON_CAD,
231559.09   1 event CONNECT, iCode=133 state=5200
231559.09   1       LsWaitAfterDialingOut : 133,CONNECT,10,1,0,CR_CNCT,CON_CAD,
231559.09   1 event CON_CAD, iCode=133 state=5200
231559.09   1       LsWaitAfterDialingOut : 133,CON_CAD,10,1,0,CR_CNCT,CON_CAD,
231559.09   1 event CR_CNCT, iCode=133 state=5200
231559.09   1       LsWaitAfterDialingOut : 133,CR_CNCT,10,1,0,CON_CAD,,
231559.09   1 event TDX_CALLP, iCode=133 state=5200
231559.09   1       LsWaitAfterDialingOut : 133,TDX_CALLP,10,1,0,CR_CNCT,CON_CAD,
231559.09   1       LineEvCallState_OutgoingCallWasAnswered 10,1,0

[SupportTeam]

All these lines just indicate that the Dialogic card could not detect the Ringback tone so it's call progress detection algorithm is reporting 'Connection as no Ringback was heard'.

 

The CON_CAD is the code for "Connect due to Cadence Break" - which refers to the ringback cadence.

 

A number of events get generated at the same time as a result of "Connect due to Cadence Break".

[Guest fmonroy]

Please send me the parameters that the TAPI version uses to set them at the Dialogic version, they work perfect.

[SupportTeam]

The TAPI parameters can be seen when you view the Properties windows of the Dialogic TAPI driver. The VoiceGuide Help file shows how to reach the TAPI driver Properties window.