Guest davclark Report post Posted 05/17/2007 01:08 AM 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
SupportTeam Report post Posted 05/17/2007 01:37 AM 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
Guest davclark Report post Posted 05/17/2007 08:22 AM 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
SupportTeam Report post Posted 05/17/2007 08:43 AM 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
Guest davclark Report post Posted 05/18/2007 08:16 PM 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
Guest davclark Report post Posted 05/18/2007 09:55 PM 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
Guest davclark Report post Posted 05/19/2007 12:11 AM 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
SupportTeam Report post Posted 05/19/2007 01:32 AM 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