Answer Timeout

[Guest jackthehack]

On occasion, when a call attempt times out, the line is not dropped, and the subsequent call attempt reports no dial tone, whereupon the the line is dropped successfully. Attached are the logs of a test where repeated call attempts (not redials) are made to a line that is allowed to time out. Usually vg reports "Uncontactable_NoAnswer", however, at 111003.75 vg reports "Uncontactable_Timeout", and the line is not dropped.

 

Can this be avoided? Thanks,

 

Jack

sample_vgm.txt

sample_tw.txt

[SupportTeam]

When telephone line is picked up the telephone company should play the dial tone.

 

If the Dialogic card is reporting that it cannot hear the dialtone then it means that either:

 

A: the telephone company is not playing the dial tone, or

B: the dial tone is played so distorted that the Dialogic card cannot detect it, or

C: the Dialogic card is not able to detect the Dial tone correctly.

 

You should probably be asking the phone company why aren’t they playing the Dial tone.

It is rare for just the tone detection on the Dialogic card to be faulty with rest of the card working, so it's probably not C.

 

The Dialogic card indicated that it do 'hang up' and the 'pick up' before making the call, with a bit over 2 seconds 'on hook' before going 'off-hook' to make next call:

 

 

111003,80 1 tw DialogicEvent 135,TDX_SETHOOK,0,0,0,DX_ONHOOK,,

111003,80 1 event TDX_SETHOOK, iCode=135 state=900

111003,80 1 LsAwaitingCalls EV_UNKNOWN_135

 

111006,20 1 state Dialing xxxxxxxxxx

111006,25 1 tw DialogicEvent 135,TDX_SETHOOK,0,0,0,DX_OFFHOOK,CALL_OUTBOUND,

111006,25 1 event TDX_SETHOOK, iCode=135 state=5200

111006,25 1 LsWaitAfterDialingOut : 135,TDX_SETHOOK,0,0,0,DX_OFFHOOK,CALL_OUTBOUND,

111006,44 1 tw DialogicEvent 134,TDX_CST,46881,0,0,DE_LCON,,

...

111009,48 1 event NODIALTONE, iCode=133 state=5200

111009,48 1 LsWaitAfterDialingOut : 133,NODIALTONE,17,0,0,CR_NODIALTONE,,

[Guest jackthehack]

I am not concerned with the absence of of the dial tone. The absence of the dial tone is expected because the telephone line has not been successfully 'hungup' following the previous call attempt. I am concerned with why the call did not properly hangup after it timed out. I indicated that my test executed the same call repeatedly, under what were to the best of my knowledge, identical circumstances, and allowed to time out without being answered. All call attempts returned "Uncontactable_NoAnswer", except one, which returned "Uncontactable_Timeout". It was the call that returned "Uncontactable_Timeout", that resulted in the line not being properly hungup, and the consequent absense of the dial tone. Why is it that when I make identical calls that are allowed to time out, most of them return "Uncontactable_NoAnswer", while some of them return "Uncontactable_Timeout". What is the connection between the "Uncontactable_Timeout" result as opposed to the "Uncontactable_NoAnswer " result that prevents the line from being 'hungup'. I have repeated this test numerous times with consistent results.

 

What Am I doing wrong?

[SupportTeam]

Do you have the "tw" log available capturing this situation? The "tw" log will give us more information about what the Dialogic card is doing.

[Guest jackthehack]

I believe I attached it with my original post.

[SupportTeam]

OK, sorry about that, only first attachment was forwarded to the person answering the question.

 

Looking at the tw trace we see that on call before the No Dialtone call the end of call was due to a timeout event in VoiceGuide and the hangup was performed slightly differently in this case, due to the Dialogic card not returning within it's call timeout period. VoiceGuide very soon after the timeout takes over and hangs up the call. We have not seen any problems before due to the slightly different way hangup is made but perhaps that is what is causing problems here.

 

What Dialogic card and SR drivers are you using? How fast is your CPU?

 

Attached .exe will wait longer for Dialogic Call Progress to return to ensure that the Dialogic card's Call Progress always completes by itself and VoiceGuide no longer forces hangup before Call Progress completes.

 

Please update to latest version of VG for Dialogic and then update that latest install with attached .exe.

 

Please let us know if that resolves the problem for you.

 

 

 

Notes:

 

The call progress seems to complete with some delay on this sytem after dx_stopch is issued, and returns after dx_sethook call:

 

111003.750 001 dx_stopch call in RecStop

...

111003.781 001 dx_sethook(1) call

111003.781 001 ev TDX_CALLP (Call Progress Completed)

111003.781 001 TDX_CALLP CR_UNKNOWN (unknown:76)

111003.781 001 dx_sethook 1 DX_ONHOOK ok

 

 

 

Here is what we see in the TW trace (abridged):

 

110534.062 001 ocxfn LineMakeCall

...

110534.843 dx_dial([Lxxxxxxxxxx], with call progress) ok

110639.468 001 ev TDX_CALLP (Call Progress Completed)

110639.468 001 TDX_CALLP CR_NOANS (called line did not answer)

...

110639.468 001 dx_stopch 1 ok

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

110639.484 001 dx_sethook(1) call

110639.484 001 dx_sethook 1 DX_ONHOOK ok

110639.484 001 ocxev DoFireDialogic completed

110639.515 001 ev TDX_SETHOOK (SetHook Completed)

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

 

110642.093 001 ocxfn LineMakeCall

...

110642.859 dx_dial([Lxxxxxxxxxx], with call progress) ok

110747.578 001 ev TDX_CALLP (Call Progress Completed)

110747.578 001 TDX_CALLP CR_NOANS (called line did not answer)

...

110747.578 001 dx_stopch 1 ok

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

110747.593 001 dx_sethook(1) call

110747.593 001 dx_sethook 1 DX_ONHOOK ok

110747.593 001 ocxev DoFireDialogic completed

110747.625 001 ev TDX_SETHOOK (SetHook Completed)

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

 

110750.140 001 ocxfn LineMakeCall

...

110750.921 dx_dial([Lxxxxxxxxxx], with call progress) ok

110855.562 001 ev TDX_CALLP (Call Progress Completed)

110855.562 001 TDX_CALLP CR_NOANS (called line did not answer)

...

110855.578 001 dx_stopch 1 ok

110855.593 001 dx_sethook 1 DX_ONHOOK ok

110855.593 001 ocxev DoFireDialogic completed

110855.625 001 ev TDX_SETHOOK (SetHook Completed)

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

 

 

110858.171 001 ocxfn LineMakeCall

110858.937 dx_dial([Lxxxxxxxxxx], with call progress) ok

111003.750 001 ocxfn RecStop(hLine=1, lRecId=0, lParam1=0, lParam2=0, strParam1=, strParam2=)

111003.750 001 dx_stopch call in RecStop

111003.750 001 dx_stopch 1 ok

111003.765 001 ocxfn PlayStop(hLine=1, lPlayId=0(0x0), lParam1=0, lParam2=0, strParam1=, strParam2=)

111003.765 001 dx_stopch call in PlayStop

111003.781 001 dx_stopch 1 ok

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

111003.781 001 dx_sethook(1) call

111003.781 001 ev TDX_CALLP (Call Progress Completed)

111003.781 001 TDX_CALLP CR_UNKNOWN (unknown:76)

111003.781 001 dx_sethook 1 DX_ONHOOK ok

111003.781 001 ocxev DoFireDialogic(dwIdx=177, 1, 133, [TDX_CALLP], 76, 0, 0, [CR_UNKNOWN], [], []) (dwIdx=177)

111003.796 001 ocxev DoFireDialogic completed

111003.796 001 ev TDX_SETHOOK (SetHook Completed)

111003.796 001 ocxev DoFireDialogic(dwIdx=178, 1, 135, [TDX_SETHOOK], 0, 0, 0, [DX_ONHOOK], [], []) (dwIdx=178)

111003.796 001 ocxev DoFireDialogic completed

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

111003.828 001 ev TDX_CST (CST Event Received)

111003.828 001 ev TDX_CST DE_LCON data=46881

111003.828 001 ocxev DoFireDialogic(dwIdx=180, 1, 134, [TDX_CST], 46881, 0, 0, [DE_LCON], [], []) (dwIdx=180)

111003.828 001 ocxev DoFireDialogic completed

111003.890 001 ocxfn RingsBeforeAnswer(lLineId=1, lRings=2, lParam1=0, strParam2=)

 

 

111006.203 001 ocxfn LineMakeCall(linedev=1, hcall=0, xxxxxxxxxx, callprog=DX_PAMDOPTEN, timeout=60, params:[0,0,cid=,]) chdev=1, dtidev=0

...

111006.437 dx_dial([Lxxxxxxxxxx], with call progress) ok

111006.437 001 ev TDX_CST (CST Event Received)

111006.437 001 ev TDX_CST DE_LCON data=46881

111006.437 001 ocxev DoFireDialogic(dwIdx=182, 1, 134, [TDX_CST], 46881, 0, 0, [DE_LCON], [], []) (dwIdx=182)

111006.437 001 ocxev DoFireDialogic completed

111009.484 001 ev TDX_CALLP (Call Progress Completed)

111009.484 001 TDX_CALLP CR_NODIALTONE (called line failed to produce a dial tone (PerfectCall Call Analysis only))

VgMulti_6.0.3319.zip

[Guest jackthehack]

I am using a D/4PCI and SR5.1.1.

Intel Celeron 3.33GHz.

 

I will update and get back to you.

 

Thanks very much.

[Guest jackthehack]

I installed the latest version of VG, 6.0.3310, and overwrote the executable with version 6.0.3319, as supplied. I continue to experience the same results.

 

I neglected to mention in my original post that the telephone line being dialed out on is VOIP. I re-tested, dialing out on a POTS line (to the VOIP line), and obtained the same results. I believe I have discovered however, why the test results I sent to you were inconsistent. In other words, why given the same circumstances VG usually returned "Uncontactable_NoAnswer", while sometimes returning "Uncontactable_Timeout".

 

My VOIP service provides a user configurable timeout of its own. I have discovered that if I configure the VOIP line to time out BEFORE Vg times out, "Uncontactable_NoAnswer" is returned, and the line subsequently drops properly. If on the other hand, Vg times out before the line itself, "Uncontactable_Timeout" is returned, and the line is not dropped. The logs that I provided you with reflect a VOIP line timeout of 61s. compared with a Vg timeout of 60s. I suppose that owing to some discrepency and/or tolerance in how the time is counted, the VOIP line was effectively timing out before Vg most of the time, but not all of the time.

 

This workaround of setting the VOIP line to timeout before Vg in order to produce a properly hungup line, seems to be satisfactory for my purposes. I remain however, curious as to why an "Uncontactable_Timeout" result fails to hangup the line.

 

If I can be of service by providing additional information or conducting further tests, it will be my pleasure to do so.

 

Thanks for your attention.

[SupportTeam]

Thank you for posting results of your investigation and the workaround.

 

Could you please also post the vgm and tw traces from v6.0.3319 capturing this problem?

 

We definitely would like to resolve this issue from VoiceGuide’s side as well.

[Guest jackthehack]

Per your request, attached are the logs of my test with v6.0.3319. I have included the results where VG times out, as well as where VOIP times out, as previously discussed.

 

I should point out that a 'Hangup the Call' module, always results in a proper hangup.

 

If you could describe the difference in the way that VG will attempt to hangup a call between encountering a 'Hangup the Call' module and I timeout, I might be able to tweak my VOIP adapter (SIP) to suit.

 

Cheers

VG_TIMEOUT_tw.txt

VG_TIMEOUT_vgm.txt

VOIP_TIMEOUT_tw.txt

VOIP_TIMEOUT_vgm.txt