VoiceGuide IVR Software Main Page
Jump to content

Monitored Transfer Problem, Dialogic D4/pci

Recommended Posts

Hi,

 

I'm having a problem with my new PBX and doing monitored transfers. VG starts the transfer and then hangs up while the extension is still ringing. It sometimes is successful but not often. My best guess is that the ring back tone is being detected as an answer and not ring back, but I'm not certain. Here are the relevant parts of the log for two calls when the extension was left ringing in both cases:

 

When Successful:

 

164343.31 1 fn RunModule start [Transfer Call,[Transfer Call To Desk],2,,]

164343.31 1 timer clear

164343.31 1 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER

164343.75 1 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER

164343.75 1 event EV_TIMEOUT_READYTOBEGINTRANSFER, iCode=9012 state=1901

164343.75 1 LsXfer_1_Start : 9012(EV_TIMEOUT_READYTOBEGINTRANSFER),EV_TIMEOUT_READYTOBEGINTRANSFER,0,0,0,,,

164343.75 1 path {EV_TIMEOUT_READYTOBEGINTRANSFER} not found

164343.75 1 timeout on transfer attempt set by VG.INI [PBX] AnnouncedTransfersMaxWaitTime (25 sec)

164343.75 1 timer set 25 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

164343.75 1 state [Transfer Call To Desk] Monitored Hookflash Transfer to 15

164343.75 1 dialing sTransferPrefix [!]

164344.41 1 tw DialogicEvent 132,TDX_DIAL,0,0,0,,,

164344.41 1 event TDX_DIAL, iCode=132 state=1902

164344.41 1 LsXfer_2_OnEndHook1PlayDestNbr 132,TDX_DIAL,0,0,0,,,

164344.41 1 VG.INI [PBX] Transfer_Prefix_PauseAfter = 2 sec

164344.41 1 timer set 2 EV_TIMEOUT_Transfer_Prefix_PauseAfter

164344.41 1 tw PlayEnd 1 0

164344.41 1 play end id=0, (current ID)

164344.41 1 event EV_PLAY_FINISHED, iCode=8001 state=1902

164344.41 1 LsXfer_2_OnEndHook1PlayDestNbr 8001,EV_PLAY_FINISHED,0,0,0,,,

164346.59 1 timer fired EV_TIMEOUT_Transfer_Prefix_PauseAfter

164346.59 1 event EV_TIMEOUT_Transfer_Prefix_PauseAfter, iCode=9030 state=1902

164346.59 1 LsXfer_2_OnEndHook1PlayDestNbr 9030,EV_TIMEOUT_Transfer_Prefix_PauseAfter,0,0,0,,,

164346.59 1 Dial(15, cp on) call

164346.88 1 Dial(15) ok

164346.88 1 timer set 25 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

164414.22 1 timer fired EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

164414.22 1 event EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG, iCode=9021 state=1903

164414.22 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 9021,EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG,0,0,0,,,

164414.22 1 Transfer timed out

164414.22 1 xfer dial [!] in Xfer_DialCmdCode_RetreiveOriginalCall

164414.91 1 tw DialogicEvent 132,TDX_DIAL,0,0,0,,,

164414.91 1 event TDX_DIAL, iCode=132 state=1906

164414.91 1 LsXfer_5B : 132(EV_UNKNOWN_132),TDX_DIAL,0,0,0,,,

164414.91 1 sXferDialResult_SuccOrFail=

164414.91 1 XferGoDownSpecifiedPath iXferModule_PathsToTake_Max=3 (1)=timeout (2)= (3)=

164414.91 1 path 'timeout' not found

164414.91 1 next module is [No Answer] (idx=3)

164414.91 1 XferGoDownSpecifiedPath: going down False path (iXferType=12)

164414.91 1 fn RunModule start [Play,[No Answer],3,,]

 

 

When unsuccessful:

 

164502.50 1 fn RunModule start [Transfer Call,[Transfer Call To Desk],2,,]

164502.50 1 timer clear

164502.50 1 timer set 0.4 EV_TIMEOUT_READYTOBEGINTRANSFER

164502.94 1 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER

164502.94 1 event EV_TIMEOUT_READYTOBEGINTRANSFER, iCode=9012 state=1901

164502.94 1 LsXfer_1_Start : 9012(EV_TIMEOUT_READYTOBEGINTRANSFER),EV_TIMEOUT_READYTOBEGINTRANSFER,0,0,0,,,

164502.94 1 path {EV_TIMEOUT_READYTOBEGINTRANSFER} not found

164502.94 1 timeout on transfer attempt set by VG.INI [PBX] AnnouncedTransfersMaxWaitTime (25 sec)

164502.94 1 timer set 25 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

164502.94 1 state [Transfer Call To Desk] Monitored Hookflash Transfer to 15

164502.94 1 dialing sTransferPrefix [!]

164503.61 1 tw DialogicEvent 132,TDX_DIAL,0,0,0,,,

164503.61 1 event TDX_DIAL, iCode=132 state=1902

164503.61 1 LsXfer_2_OnEndHook1PlayDestNbr 132,TDX_DIAL,0,0,0,,,

164503.61 1 VG.INI [PBX] Transfer_Prefix_PauseAfter = 2 sec

164503.61 1 timer set 2 EV_TIMEOUT_Transfer_Prefix_PauseAfter

164503.61 1 tw PlayEnd 1 0

164503.61 1 play end id=0, (current ID)

164503.61 1 event EV_PLAY_FINISHED, iCode=8001 state=1902

164503.61 1 LsXfer_2_OnEndHook1PlayDestNbr 8001,EV_PLAY_FINISHED,0,0,0,,,

164505.78 1 timer fired EV_TIMEOUT_Transfer_Prefix_PauseAfter

164505.78 1 event EV_TIMEOUT_Transfer_Prefix_PauseAfter, iCode=9030 state=1902

164505.78 1 LsXfer_2_OnEndHook1PlayDestNbr 9030,EV_TIMEOUT_Transfer_Prefix_PauseAfter,0,0,0,,,

164505.78 1 Dial(15, cp on) call

164506.06 1 Dial(15) ok

164506.06 1 timer set 25 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

164524.94 1 tw DialogicEvent 133,TDX_CALLP,10,1,0,TDX_CALLP,CR_CNCT,CON_CAD

164524.94 1 event CADENCE, iCode=133 state=1903

164524.94 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CADENCE,10,1,0,CR_CNCT,CON_CAD,

164524.94 1 event CONNECT, iCode=133 state=1903

164524.94 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CONNECT,10,1,0,CR_CNCT,CON_CAD,

164524.94 1 event CON_CAD, iCode=133 state=1903

164524.94 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CON_CAD,10,1,0,CR_CNCT,CON_CAD,

164524.94 1 event CR_CNCT, iCode=133 state=1903

164524.94 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CR_CNCT,10,1,0,CR_CNCT,CON_CAD,

164524.94 1 event TDX_CALLP, iCode=133 state=1903

164524.94 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,TDX_CALLP,10,1,0,CR_CNCT,CON_CAD,

164524.94 1 LsXfer_3 CR_CNCT on an XT_HOOK_MONITORED

164524.94 1 xfer dial

164524.97 1 tw DialogicEvent 132,TDX_DIAL,0,0,0,,,

164524.97 1 event TDX_DIAL, iCode=132 state=1905

164524.97 1 LsXfer_5A : 132(EV_UNKNOWN_132),TDX_DIAL,0,0,0,,,

164524.97 1 sXferDialResult_SuccOrFail=

164524.97 1 HangupCall start (LsXfer_5A)

164524.97 1 rv add [Hangup Time]{5/16/2007 4:45:24 PM}

164524.97 1 state Hanging up call... [LsXfer_5A]

 

 

 

I have attached a wav of my ringback. I imported it into cooledit and came up with the following parameters for my configline.xml:

 

- <Tone Name="Call Progress Tone TID_RNGBK1">

<Notes>Ringback 1 Default Setting</Notes>

<ID>TID_RNGBK1</ID>

<Freq1>479</Freq1>

<Freq1Dev>138</Freq1Dev>

<Freq2>0</Freq2>

<Freq2Dev>0</Freq2Dev>

<On>120</On>

<OnDev>105</OnDev>

<Off>300</Off>

<OffDev>200</OffDev>

<Count>1</Count>

</Tone>

- <Tone Name="Call Progress Tone TID_RNGBK2">

<Notes>Ringback 2 Default Setting</Notes>

<ID>TID_RNGBK2</ID>

<Freq1>479</Freq1>

<Freq1Dev>138</Freq1Dev>

<Freq2>438</Freq2>

<Freq2Dev>138</Freq2Dev>

<On>120</On>

<OnDev>105</OnDev>

<Off>300</Off>

<OffDev>200</OffDev>

<Count>1</Count>

</Tone>

 

I didn't know what to do for the *Dev values so I left them at default.

 

I've been at this all day now... Thanks for any ideas.

 

Dave

testringback.wav

Share this post


Link to post

The Dialogic card reports that the call was answered as it detected a "CADENCE BREAK".

 

Cadence Break means that the Dialogic card was hearing ringback but then after a while it did not hear ringback any more, so it deduced that the call must have be answered...

 

try using this definition:

 

<Tone Name="Call Progress Tone TID_RNGBK1">

<Notes>Ringback 1 Default Setting</Notes>

<ID>TID_RNGBK1</ID>

<Freq1>430</Freq1>

<Freq1Dev>40</Freq1Dev>

<Freq2>480</Freq2>

<Freq2Dev>40</Freq2Dev>

<On>120</On>

<OnDev>50</OnDev>

<Off>300</Off>

<OffDev>100</OffDev>

<Count>1</Count>

</Tone>

 

It is possible the ringback tone gets distorted and that's why the Dialogic card thinks it's no longer there.

Distorted ringback was the reason behind this recent long thread: http://voiceguide.com/forums/index.php?showtopic=4910

 

In situations where the ringback detection is unreliable using Dial and Conference (Tromboning) approach may be the required.

Share this post


Link to post

I tried those parameters, but I'm still getting very inconsistent results. about 80% of the time the call gets dropped or continues ringing endlessly (the transfer module seems to ignore the time-out in these cases???) The other 20% of the time the script actually continues on to the "No Answer" module. When I switch to announced transfers, I do not have the problem at all, but it's going to get very annoying to have to deal with an announced transfer every time the phone rings and so I'd like to avoid this solution. It seems odd that the announced transfers module doesn't have a problem identifying when the phone is answered.

 

The PBX I am using is an AVAYA Partner ACS. This model is in common use in the USA and seems to be manufactured to pretty high standards (originally AT&T design). I recorded ringback for 4 cycles and analyzed it with audacity. Nothing I can see indicates that the ringback tones are sloppy. The variation in timings is insignificant. I came up with <off> values of 3.000, 2.999, 2.999 and 2.998 seconds and <on> values of 1.202, 1.201, 1.201, and 1.201. Spectrum analyzer shows nice clear peaks at 440 hz and 480 hz for each tone. The only thing I did notice is that the very first ring after the transfer is mixed in with the DTMF of the last digit dialed in the extension, making it seem distorted or possibly shorter in duration from the reference point of the Dialogic card. If the ringback detection code takes the first ringback tone heard after the transfer and uses it as a pattern for future ringback tones then maybe it's using a bad "Template" to compare the following ring tones with. That's just some wild hypothesizing on my part but I'm really wondering what is happening here. Is there any way to tune the ringback detection parameters to minimize the effect of the very first ring? What about increasing the <count> or <ondev>, <offdev>

 

By the way, I tried to run PBXpert but was again getting very inconsistent success with rings being detected only a small fraction of the time. Is this an indication of something?

 

Thanks,

Dave

Share this post


Link to post
It seems odd that the announced transfers module doesn't have a problem identifying when the phone is answered.

The answer detection process should be the same. Does the announce message always start play after you say 'Hello' or do you see it sometimes starting to playing before the call was answered?

 

I'm really wondering what is happening here.

What Dialogic card are you using? If it's old then maybe the card itself is faulty - maybe the line interface circuitry on the card causes intermittent problems - but you would be able to detect all of these by doing a number of recordings and seeing if there are any distortions apparent...

 

Is there any way to tune the ringback detection parameters to minimize the effect of the very first ring?

The connection cause is "CADENCE" - this happens when the Dialogic card detects a ringback tone but then the ringback is not detected any more. So distortions on the first ringback would not be affecting it. If the Dialogic card did not detect any ringbacks at all the connect cause would be "NO RINGBACK".

 

By the way, I tried to run PBXpert but was again getting very inconsistent success with rings being detected only a small fraction of the time. Is this an indication of something?

It shows that other software is also seeing inconsistent reporting of ringbacks on this system...

 

Those inconsistent ringbacks are usually detected if a number of recordings is made, but if you did a number of these recordings and found all ringbacks to be recorded clearly then it suggests that the tone detection circuitry/processing on the Dialogic card itself is at fault... it's pretty rare for this to happen though.

Share this post


Link to post
The answer detection process should be the same. Does the announce message always start play after you say 'Hello' or do you see it sometimes starting to playing before the call was answered?

 

I experimented a bit with this and it turns out that it does start to play the announce message before I answer if I wait long enough. In a dial and conference transfer how is it that the answer is more successfully detected? Isn't it still just looking for a cadence break to determine if the call was answered?

 

What Dialogic card are you using? If it's old then maybe the card itself is faulty - maybe the line interface circuitry on the card causes intermittent problems - but you would be able to detect all of these by doing a number of recordings and seeing if there are any distortions apparent...

 

My card is a D4/PCI, several years old but not ancient. During all my testing with the card it has never mis-detected DTMF key presses, the ringback recordings look very clean, voice mail sounds clean and, I just recorded a minute of a clean and steady DTMF tone. The resulting wave form looks great in audacity and sounds great.

 

I tried putting a different PBX into the mix and I'm getting the same problems with PBXpert not detecting rings. Since PBxpert is having issues also, it shouldn't be a VoiceGuide thing. Anyhow I'm going to try doing a few more recordings of ringback and if nothing comes to light, I'll try installing the card into a different computer. Beyond that I'm stumped. May need a new card.

 

Thanks for your help,

Dave

Share this post


Link to post

Ok, I noticed something unusual. I decided to put some wild numbers into my configline.xml file just to see what would happen. So I put in the following:

 

163656.796 tone TID_RNGBK1:254 338:138 280:0 100:105 200:200 1

163656.796 tone TID_RNGBK2:256 338:138 280:138 100:105 200:200 1

 

Where the Audacity analysis suggested something more like:

 

114555.375 tone TID_RNGBK1:254 440:40 480:40 120:50 300:100 1

114555.375 tone TID_RNGBK2:256 440:40 480:40 120:50 300:100 1

 

 

So the numbers I put in were way off in both frequency and timing, yet I got identical results as I had been getting before with my monitored transfers. VG first detected the ringback, then later a cadence break occurred, as shown below:

 

163738.55 1 Dial(15, cp on) call

163738.81 1 Dial(15) ok

163738.81 1 timer set 25 EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

163755.44 0 sys cleanup Start

163755.44 0 sys cleanup End

163757.48 1 tw DialogicEvent 133,TDX_CALLP,10,1,0,TDX_CALLP,CR_CNCT,CON_CAD

163757.48 1 event CADENCE, iCode=133 state=1903

163757.48 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CADENCE,10,1,0,CR_CNCT,CON_CAD,

163757.48 1 event CONNECT, iCode=133 state=1903

163757.48 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CONNECT,10,1,0,CR_CNCT,CON_CAD,

163757.48 1 event CON_CAD, iCode=133 state=1903

163757.48 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CON_CAD,10,1,0,CR_CNCT,CON_CAD,

163757.48 1 event CR_CNCT, iCode=133 state=1903

163757.48 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,CR_CNCT,10,1,0,CR_CNCT,CON_CAD,

163757.48 1 event TDX_CALLP, iCode=133 state=1903

163757.48 1 LsXfer_3_AfterDialDestNbrWaitForCallProgInfo 133,TDX_CALLP,10,1,0,CR_CNCT,CON_CAD,

163757.48 1 LsXfer_3 CR_CNCT on an XT_HOOK_MONITORED

163757.48 1 xfer dial

 

So it detected ringback for nearly 20 seconds even with the wild parameters. I'm wondering if the configline.xml is not taking precedence in the ringback detection parameters? Surely it should have never detected ringback at all or at least immediately detected a cadence break. Could there be something awry in my installation files or hardware parameters?

Share this post


Link to post

I reinstalled the card on a different computer and got pretty much the same results with my transfers. I recorded several minutes of ringbacks and all of them look and sound great in Audacity. I ran PBXpert on the new computer and got some interesting results. Very erratic tone frequency analysis and a choppy trace display. I listened in while PBXpert was doing some of the testing and the choppy trace does not correspond with anything I could detect by listening to the tones. So at this point I'm thinking it may be a hardware problem. The card does not have a problem with tones that are short, like DTMF but longer tones are giving problems. I noticed during the PBXpert dialtone test there seemed to be a "Bounce" in the trace just before the line was hung up. If it is a hardware problem, it must just be in the analysis side since my recordings have been very reliable.

 

But I'm still wondering why changing the configline.xml numbers to wildly off figures did not result in VoiceGuide immediately detecting a cadence break. I just want to be sure of the problem before I go and buy another $$$ card.

Share this post


Link to post
it turns out that it does start to play the announce message before I answer if I wait long enough.

That would be due to the cadence break.

 

In a dial and conference transfer how is it that the answer is more successfully detected? Isn't it still just looking for a cadence break to determine if the call was answered?

If you say "Hello" then that will be detected as "Voice" and the connection will be reported immediately.

 

Looks like you should try using a different Dialogic card...

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×