[fluffybunny]

I have a voicemail system which is hanging up on callers when they retrieve messages. What happens is that callers are routed to a mailbox and then immediately hang-up. (i.e. they dont want to leave a message). The system then records a short amount of dial tone (i.e. continuous dual tone) as the message, before doing a "hang up detect" and dropping the line.

The subscriber then calls in to pick up the message, and hears the dial tone, but so does the system and it detects the recorded dial tone (which is being played back) as hang up tone, and drops the line!

I have tried to set the min message length to 4 seconds but it is still doing it from time to time. Setting this to more than 4 seconds runs the risk of short (legitimate) messages not being recorded.

Any ideas?

I guess one solution is to switch off "hang up detect" during playback of messages, and then switch it on again once the message has finished playing. (ok, it wont drop the line if a caller actually hangs up during the message but I can live with that.)

Thanks

Simon

[SupportTeam]

This should not be happening as the busy tone should usually be truncated/removed from the end of recorded messages.

Could you please post a copy of VoiceGuide's Trace Logs which captures the problem, 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
NumberLoader=0
VoicemailManager=0
EmailSender=0
TapiWrapOcx=10
SapiWrapOcx=0

Then restart VG and make the two test calls which demonstrate 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.

[fluffybunny]

Its proving really difficult to simulate this and log the error as it is a live system. I can leave logging on and zip up an enourmous log file but it might take you ages to sift through it to find the call which caused the problem.

I'll try to get an example logged but until then can I ask a couple of questions:

1. I have a min valid message length set to 4 seconds. Does the system remove the busy tone from the end of the message and then see if the message is greater than the min message length, or could it see a 5 second message, keep it as a valid message, but then remove 3 seconds of busy tone leaving a 2 second message?

2. I refer to busy tone above, but I am actually detecting dial tone for disconnect not busy tone (i.e. continuous tone rather than a cadance). Does the RecCutifHangupBytes_Dialogic parameter in vg.ini refer to both detecting hangup by busy tone, and detecting hangup by dial tone?

3. Another problem is that this is a very busy system and I am experiencing long delays between when the caller logs in to hear voicemail and the system telling them how many messages they have. This is because the system only deletes the WAV file when messages are deleted, and leaves the VOX file in place. So, in my wmsave folder I have 4,120 (redundant) vox files which have not been deleted when the wav files have been removed. I manually deleted these myself and the system is now running normal speed. Can you delete the vox file as well as the wav file when deleting messages?

Best wishes

Simon

[fluffybunny]

Ok, got one.

Attached is a call which went to voicemail and caller hung up during default greeting message. Result is a short message containing dial tone, even though the minimum message length was set to 4 seconds.

When you try to listen to the message the system plays the dial tone, and immediately detects it as a hang up signal and drops the line.

Best wishes

Simon

Attached File(s)

•  hup.zip (22.03K)
  Number of downloads: 48

[fluffybunny]

Right, a little more information.

It seems that the minimum message length had been reset to 0 (probably by someone going to the Global Tab and clicking the "reset all boxes" button, which always defaults to 0 no matter what is set in vg.ini....sooo annoying!)

Setting the min message length back to 4 seems to prevent short messages of dial tone being recorded.

Having said this, changing RecCutifHangupBytes_Dialogic in vg.ini seems to have no effect at all on how much dial tone is removed from the end of the message. The actual amount of dial tone left on the message is usually about a second or so(irrespective of whether RecCutifHangupBytes_Dialogic is set to 14000 or 80000), but it does vary a little from message to message. Sometimes (on a longer message) I can record 3 or 4 seconds of dial tone at the end, but in these cases it often doesent cause a hang up.

In other words the system seems to play longer messages (say 10 seconds in length) with a short burst of 3 or 4 seconds of dial tone at the end ok, but if you get a very short messge with a short burst of dial tone at the end it hangs up on the caller! Clearly I have a big system now with lots of mailboxes with short messages containing dial tone in, and these keep cutting callers off when trying to listen to messages.

Big problem.

Best wishes

Simon

[SupportTeam]

probably by someone going to the Global Tab and clicking the "reset all boxes" button, which always defaults to 0 no matter what is set in vg.ini....sooo annoying!

This bug is now fixed in the attached voicemail manager.

Trace provided shows that call was ended due to Loop Current drop, and not Dialogic detecting a disconnect tone. If Dialogic did not detect disconnect tone on recording then it's unexpected for it to be detecting it on playback. To resolve the problem you are having it looks like we should be truncating recording upon detecting loop current drop as well.

The new version of VG for Dialogic (attached) lets you truncate upon the loop current drop event as well. Place the settings below in VG.INI's [PlayRecordConfig] section:

;When a recording is finished due to a busy or disconnect signal being detected
;the recorded message will be truncated (to remove the busy tone recording from the message.)
;time to be truncated is specified in 100ms units.
RecCut_EndRecDueTo_ToneDisconnect=30

;When a recording is finished due to a dtmf being detected
;the recorded message will be truncated (to remove the dtmf tone recording from the message.)
;time to be truncated is specified in 100ms units.
RecCut_EndRecDueTo_ToneDtmf=5

;When a recording is finished due to loop current drop.
;the recorded message will be truncated (to remove the dtmf tone recording from the message.)
;time to be truncated is specified in 100ms units.
RecCut_EndRecDueTo_DlgcDE_LCOF=10

Attached File(s)

•  VgVmMgr.zip (64.67K)
  Number of downloads: 49
•  VgMulti_3211.zip (485.98K)
  Number of downloads: 60

[fluffybunny]

Thats great, thanks very much.

Can you clarify the other 2 points as well?

1. I have a min valid message length set to 4 seconds. Does the system remove the busy tone from the end of the message and then see if the message is greater than the min message length, or could it see a 5 second message, keep it as a valid message, but then remove 3 seconds of busy tone leaving a 2 second message on the system? In other words is the "Minimum Message Length" tested before or after truncation?

2. Can you delete the vox file as well as the wav file when deleting messages? My vmsave directory keeps filling up with redundant VOX files which are left behind after the corresponding WAV has been deleted.

One other problem I am now experiencing is that on occasions the system tries to play a WAV file (a message left in a mailbox) and creates a 0kb vox file. This results in the message not being played. I've tried to delete the VOX and dialled in again to play the message but again it creates a 0kb VOX file. Is this a known problem? I'll try to log it and send you the trace and the wav file its trying to play.


Thanks

Simon

[fluffybunny]

Latest info ...

Re: the further problem with 0kb vox files being created, I turned on logging in vg.ini and restarted Voiceguide, whereupon it all started working again ok!

So, I dont know what was happening there, but whatever was happening, its not now, and the restart seems to have cured that problem at least.

[SupportTeam]

Attached .exe will report message length as it is after truncation. Previous version did not always take truncation into consideration when reporting recorded message length.

This exe will also delete the .voxvoicemail files.

Place attached .VBS in VG's \system\vm\ subdirectory.

Regarding VG's inablity to sometimes convert a particular .WAV file - are you sure that that .WAV file is not opened in exclusive mode by some other application at the same time?

Attached File(s)

•  VgMulti_3233.zip (488.39K)
  Number of downloads: 56
•  vm_deletefile.zip (864bytes)
  Number of downloads: 43

[fluffybunny]

I copied the 2 files onto the system and tested them out, but unfortunately the VOX file still wasnt deleted. Interestingly, the VOX file was created at the time when the message was recorded. I always thought that it recorded the WAV only and then did a WAV to VOX conversion when the message was listened to.

The attached log shows the message being recorded and then the message being listened to. As I said though, the VOX file remained after the caller selected to delete the message.

With regard to the WAV to VOX conversion problem, it occurred again today and went away when I restarted Voiceguide. In short we get a problem where a voicemail user dials in to listen to messages, and they press 1 to hear the new message, but it doesent play anything and just goes back to the menu. The VOX file is 0kb. If you delete the VOX and try again, the same thing happens and we are left with a 0kb VOX file again.

I have left logging on, so when it happenes again I can provide a log file, albeit very large in size as this voicemail system has 300 users and records several hundred messages a day.

Attached File(s)

•  log2.zip (20.99K)
  Number of downloads: 40

[SupportTeam]

The VOX file is 0kb.

This sounds like a bug that was present in someversion of ktTel.ocx but was fixes a while back now. Please download latest VoiceGuide for Dialogic and get ktTel.ocx from this newest version and then put that OCX on your system (in Windows' System32 directory).

but unfortunately the VOX file still wasnt deleted.

Looked at the trace and we can see that this voicemail script is not using the vm_deletefile.vbs script (as it should). We'll modify that voicemail script to use the vm_deletefile.vbs to do the deletion and then you should see it deleting VOX as well since the new vm_deletefile.vbe which was provided a couple posts back deletes both the WAV and the VOX.

We'll post a new version of this vmLogin.vgs script here in a couple of days.

[SupportTeam]

Please place the files in vm.zip inf VG's \system\vm\ subdirectory, and place files in exe.zip in VG's directory.

This new set should result in .vox being deleted as well in all the situations.

Attached File(s)

•  vm.zip (21.66K)
  Number of downloads: 43

[fluffybunny]

That's excellent, thanks. (Although I think you forgot to attach exe.zip?)

I updated ktTel.ocx on Saturday, but this morning I have the same problem. My customer is reporting that they cant listen to messages and I have a load of 0Kb VOX files in the vmsave directory. I have deleted the VOX's and restarted the system and all is well again.

So, it looks like we still have the problem with WAV -> VOX conversion.

I have put logging on and will post the log files as soon as the problem is reported again. It is usually within 24 hours or so.

Thanks

Simon

[SupportTeam]

Here are the .exe files.

Attached File(s)

•  exe.zip (585.94K)
  Number of downloads: 41

[fluffybunny]

Thanks for that. I managed to get onto the system yesterday and installed the new scripts and the new exe's. The good news is that the VOX's are now being deleted along with the WAV's so thats good.

However, I note that the "Global" tab has had the button to reset all mailboxes removed, which is fine, BUT I am noticing that although I have a minimum message length set to 5 seconds, I am now seeing some 3 second messages in some mailboxes, and these are just a couple of seconds of silence followed by a very small amount of dial tone (i.e. hang up tone). When the system tries to play these messages it causes the line to hang up as, I think, it is detecting the dialtone, that is recorded, as hangup tone.

The funny thing is that on longer messages there is no dial tone left at the end of the message as it seems this is being truncated successfully. It is only on very short messages that the truncation doesent seem to take off all the dial tone.

So, either I need to ensure the min message length stops these 3 second "hang-ups" being recorded, or we need to look into why there is still some dial tone left on the end of very short messages. (or both!)

Thanks

Simon

[fluffybunny]

And as a demonstration, here are two messages that have been recorded on the system, one long and one short.

Attached File(s)

•  wavs.zip (116.98K)
  Number of downloads: 48

[SupportTeam]

Please post traces capturing the recording and playback of these short messages with hangup tone problems and the .WAV and .VOX files.

Or just .ZIP up and email to support@voiceguiode.com entire days tw and vgm trace and the short .WAV and .VOX files recorded on that day.

[fluffybunny]

Attached are 2 examples of recordings. One is a caller "hang up" where they are routed to a mailbox and they don't leave a message, they just hang up, and anohter is a slightly longer message where the caller leaves a message before hanging up.

The log files are also attached.

By the way, I havent experienced the 0kb VOX file since the last time I posted about the problem. The only difference with the system (apart from the last set of exe's and scripts you sent me) is that I have logging on. I'll carry on monitoring and let you know if I see anything.

[fluffybunny]

Sorry, I seem to ba unable to attache the zip file. I have emailed it to support@voiceguide.com instead

[SupportTeam]

Both of the files we received in the email were more then 5 seconds long.

The recording of file 1068_1220155511_1_4__ was ended due to loop current drop. The tone recorded in the file was not recognized as any of the pre-defined tones in the Dialogic card.

If you want the tone recorded in 1068_1220155511_1_4__ to be detectable by the Dialogic card you should find out it's frequency(ies) and set the tone definition in Dialogic configuration appropriately.

155511.859 004 dlgc open save file(strFname=C:\Program Files\VoiceGuide\data\VmSave\1068_1220155511_1_4__.vox) => 6
...
155519.703 004 ocxev DoFireDialogic(dwIdx=3587, 4, 134, [TDX_CST], 0, 0, 0, [DE_LCOF], [], []) (dwIdx=3587)
...
155519.718 004 ocxfn RecStopTruncate(sLineId=4, strSaveFname=, lTruncTime=2000 (milliseconds), lTruncBytes=0)

[fluffybunny]

1. The file which is 5 seconds long is shown on the voicemail manager as being 4 seconds long.

2. Attached is a recording made today (with the log files) which is 1 second long. The minimum file length is still set to 5 seconds.

3. The 2 files I sent to you previously showed one having a length of dial tone (the hang up tone) appended to the end of it, and one without, although both recordings were terminated with a hang up. Why was the dial tone truncated in one recording and not the other?

Attached File(s)

•  files2.zip (1.83MB)
  Number of downloads: 40

[fluffybunny]

My client is putting me under severe pressure to sort out these problems. Can you possibly post me an update please so I can re-assure my client we are giving our best endeavours to rectify the problem? Many thanks.

[SupportTeam]

1. The file which is 5 seconds long is shown on the voicemail manager as being 4 seconds long.

From the traces we could see that the recording time was just barely over 5 seconds, but amount of data received from Dialogic was just under 5 seconds. We should probably have the voicemail manager show the length to nearest second, rather then just chop off the figures after the decimal point.

2. Attached is a recording made today (with the log files) which is 1 second long. The minimum file length is still set to 5 seconds.

Trace shows recording was ended by caller pressing "4" key, which is an option indicating that caller wants to delete the recorded file and start recording again.
So the the file 1067_1222123012_1_4__.wav should have been deleted but the script in vmLm.vgs' [VmLmMenu] module. Can you try running some tests on your sysem and seeing if your current version of voicemail scripts installed on the system deletes the recorded file when "4" is pressed while recording?

Attached versions of scripts will explicitly log in vgm trace file deletion confirmation or deletion failure for this option.

123012.11 4 state [VmLmRec] Recording C:\Program Files\VoiceGuide\data\VmSave\1067_1222123012_1_4__.wav
...
123014.28 4 tw dtmf 4 (4,52,52)
...
123014.33 4 RecEndTime=45014.28, RecStartTime=45012.11, Diff=2.171875
123014.33 4 rv rec length: VmLmRec_RecLen100ms = 17
...
123014.42 4 state [VmLmMenu] Running VB Script...

3. The 2 files I sent to you previously showed one having a length of dial tone (the hang up tone) appended to the end of it, and one without, although both recordings were terminated with a hang up. Why was the dial tone truncated in one recording and not the other?

I think this question was answered a few posts back(?). here is the relevant quote from the few posts back:

The recording of file 1068_1220155511_1_4__ was ended due to loop current drop. The tone recorded in the file was not recognized as any of the pre-defined tones in the Dialogic card.

You may want to make the disconnect tone definition which you've set on this system broader to give you better disconnect tone detection reliability. Your current setting of: f1:350:15, f2:442:15, cad:100:20,0:0, count:1 allows for only +-15Hz tolerance. That is pretty low. Tolerance should be about 10% of frequency value.

Alternatively make the value of RecCut_EndRecDueTo_DlgcDE_LCOF larger. eg: If 5 seconds of disconnect tone in played before your phone company drops loop current then the value of RecCut_EndRecDueTo_DlgcDE_LCOF should be a bit over 50 - eg: 55 or 60.

Attached File(s)

•  vm_delete_tracing.zip (5.13K)
  Number of downloads: 43

[fluffybunny]

Thanks for that information. I will try the new script and report back the results.

In the meantime, my major problem is with detection of hang-up tone. I note your comments on the narrowness of the tolerance, but any wider and I get false hang up detections when recording messages, particularly when there is noisey background noise.

There remains one over-riding problem which is proving to be a show stopper. It is (as I reported earlier) when there is a short message recorded, with a second or two of dial tone at the end of it. When this is played back to the caller, as soon as the dial tone is played back, the system detects this as a hang up and drops the line. I have tried all manner of ways to truncate the dial tone but on most longer messages it truncates perfectly but on very short messages it doesent, and leaves 1 or 2 seconds of dial tone which is enough to cause a disconnect

However, I think my problem may be due to how hang-up detect is set up. At the moment, the ONLY way hang up detect will work is if I have DISCONNECT TONE set to YES in the Dialogic DCM config. If I set this to OFF (as you have previously advised in another thread) Hang up detect just will not work.

Attached are a number of tests I have done. Each zip contains log files and associated configline.xml

Test1.zip - A hang up with DISCONNECT TONE set to ON using DCM, and the wrong hang up tone frequencies in configline.xml. This failed to detect hang up as you would expect.

Test2.zip - A hang up with DISCONNECT TONE set to ON using DCM, and the correct hang up tone frequencies in configline.xml. This detected hang up as you would expect.

Test3.zip - A hang up with DISCONNECT TONE set to OFF using DCM, and the correct hang up tone frequencies in configline.xml. This failed to detect hang up.

Test4.zip - A hang up with DISCONNECT TONE set to OFF using DCM, and the correct hang up tone frequencies in configline.xml, but with very generous tolerances (+/-100). This failed to detect hang up.

Test5.zip - I even thought that the dial tone settings were screwing up disconnect tone detection as they were the same so I set all dial tones to invalid frequencies, and left the disconnect tone set correctly. This didnt work either.

hg_up_tone.zip - A recording of the hang up tone.

Do you have any ideas why my system doesent detect hang-up tone unless DISCONNECT TONE is set ON in DCM config?

If having DISCONNECT TONE set to ON is correct, then why does the system hang up when playing back short messages with a second or so of dial tone recorded at the end? (I have posted examples of the files previously)

Please help, because at the moment I am having to dial into the system remotely 3 or 4 times a day to manually delete short messages which have dial tone recorded at the end of them.

Attached File(s)

•  hgup_tone.zip (45.91K)
  Number of downloads: 40
•  test1.zip (12.03K)
  Number of downloads: 42
•  test2.zip (10.86K)
  Number of downloads: 40
•  test3.zip (12.04K)
  Number of downloads: 40
•  test4.zip (12.01K)
  Number of downloads: 38
•  test5.zip (12.05K)
  Number of downloads: 41

[SupportTeam]

In the meantime, my major problem is with detection of hang-up tone. I note your comments on the narrowness of the tolerance, but any wider and I get false hang up detections when recording messages, particularly when there is noisey background noise.

If the hangup tone played by the phone company or PBX cannot be detected reliably then you should maybe consider moving to an ISDN T1/E1 line.

I have tried all manner of ways to truncate the dial tone but on most longer messages it truncates perfectly but on very short messages it doesent, and leaves 1 or 2 seconds of dial tone which is enough to cause a disconnect

Have you tried changing the value of the RecCut_EndRecDueTo_DlgcDE_LCOF setting as per our previous comments?

Test2.zip - A hang up with DISCONNECT TONE set to ON using DCM, and the correct hang up tone frequencies in configline.xml. This detected hang up as you would expect.

Trace shows Dialogic card reported Loop Current Drop, it did not report detecting any disconnect tone beforehand:

183116.14 3 state [Welcome] Playing (C:\FreshDirect\Voice\WELCOME.WAV)
...
183119.05 3 tw DialogicEvent 134,TDX_CST,0,0,0,DE_LCOF,,

Test3.zip - A hang up with DISCONNECT TONE set to OFF using DCM, and the correct hang up tone frequencies in configline.xml. This failed to detect hang up.

Test4.zip - A hang up with DISCONNECT TONE set to OFF using DCM, and the correct hang up tone frequencies in configline.xml, but with very generous tolerances (+/-100). This failed to detect hang up.

And in these cases traces show that there was no loop current drop on the line either. Previous traces showed that loop current was being dropped when caller hung up so it's strange that loop current drop has not happened on these calls. Maybe setting DISCONNECT TONE set to OFF using DCM supresses reporting of the Loop Current Drop event as well ?

why does the system hang up when playing back short messages with a second or so of dial tone recorded at the end? (I have posted examples of the files previously)

From previous traces we could see that setting the value of RecCut_EndRecDueTo_DlgcDE_LCOF to be higher (say about 60?) would have resulted in the recording being truncated to remove the tone from the end.

Have you done the test we recommend beforehand to see if your current version of scripts deletes the recorded file when "4" is pressed while recording?

As mentioned beforehand we have supplied in previous post scripts which will save in vgm log file the confirmation of whether the file deletion was successful or not – it’s probably best if you updated to using this new version of scripts.

[fluffybunny]

Thanks very much for your full reply, and I'm sorry for being such a pain! I expect you're getting sick of hearing from me.

I shall be loading on the updated script onto the system today and will send logs back as soon as possible. The problem of messages not being deleted after a caller pressing 4 is very low priority though as it isn't really affecting service.

The problem of hang ups is severely affecting service though.

If the hangup tone played by the phone company or PBX cannot be detected reliably then you should maybe consider moving to an ISDN T1/E1 line.

The system is providing an internal voicemail service for a medical companies 350 employees and is connected to their PBX using analogue extensions. Migrating across to an ISDN line isn't an option unfortunately.

Have you tried changing the value of the RecCut_EndRecDueTo_DlgcDE_LCOF setting as per our previous comments?

I have, but I am worried I will start to chop the end of valid messages. It seems that longer messages are truncated right to the end of the speech part of the message, and yet very short messages, such as early hang ups still have a very short amount of dial tone recorded at the end. Increasing this value therefore might result in chopping off the end of a valid message

Trace shows Dialogic card reported Loop Current Drop, it did not report detecting any disconnect tone beforehand:

Exactly! But there WAS no drop of loop current on the line. (Test1 proves this). What I think is happening is that the Dialogic is detecting the tone set reliably (comparing the results of Test1 and Test2) and translating this into a drop of loop current.

And in these cases traces show that there was no loop current drop on the line either. Previous traces showed that loop current was being dropped when caller hung up so it's strange that loop current drop has not happened on these calls. Maybe setting DISCONNECT TONE set to OFF using DCM supresses reporting of the Loop Current Drop event as well ?

As I mention above, there is no drop of loop current on hang up. The only indication we get is 4 seconds (ish) of Dial Tone followed by continuous Number Unobtainable tone (singal tone, 400hz). I suspect the Dialogic detects the tone set that we have specified in configline.xml, and translates this into a drop of loop current when it detects the hang up tones, provided the DISCONNECT TONE is set to ON using DCM. If it is set to OFF then the dialogic does not signal to us drop of loop current, but in addition it doesent signal to us detection of the hang up tones, which I assume it should. However we know it can detect the tones because of the results of Test2. If it WAS a real drop of loop current then Test1 would have signalled drop of loop current, but it didn't.


The Dialogic can detect the hang up tones reliably, (albeit it signals drop of loop current), and this is proved by comparing results of Test1 and Test2. I say reliably because I ring the system and every time I hang up on the system voiceguide successfully drops the line within 1 or 2 seconds. (When DCM has the DISCONNECT TONE set to ON).

So, it seems to me that when DCM has DISCONNECT TONE set to OFF, the Dialogic is not sending back a drop of loop current signal, but in addition either the dialogic is not signalling back to voiceguide it has detected the hang up tones, or it is and voiceguide is not responding to the signal.

I am quite happy to leave the DISCONNECT TONE set to ON in DCM, and accecpt that the dialogic will signal back drop of loop current to voiceguide on hang up, but we still have this problem of voiceguide hanging up when a short burst of dial tone is recorded at the end of a message and when it is played back it causes voiceguide to hang up.

I can try to increase the RecCut_EndRecDueTo_DlgcDE_LCOF setting, but this may well start to chop the end of valid messages.

To summarize, the problem is that when playing back messages which have a small amount of dial tone recorded at the end of the message, it causes voiceguide to hang up. The possible solutions seem to me to be :

1. Increase the RecCut_EndRecDueTo_DlgcDE_LCOF setting, to ensure there is no dial tone recorded in the first place. This runs the risk of chopping the end off valid messages as currently some messages are truncated right back to the end of the spech part of the message, and some have a very small anount of dial tone recorded at the end.

2. Have the ability to turn off detection of hang up tones / loop current during playback of messages. This will mean if we do get a hang up during playback, then the message will continue playing until it reaches the end. For long messages this might mean the hang up tone has stopped by the time we get to the end of the message and we will have to rely on voiceguide timing out in order to drop the line.

3. Establish if the fact that the Dialogic is sending back drop of loop current indication instead of hang up tone detect is causing voiceguide to malfunction in some way.

Is there any way of determining if the hang up tone came from the pbx or from the recording? if we could establish this then we could ignore one (the one from the recording) and act on the other. Its a long shot, I know, but I'm running out of ideas.

Incidentally, this system was installed to replace an older DOS based dialogic system I had installed on this site (same PBX) 8 years ago, and the voicemail software I used then detected hang up tone perfectly, so I know there must be a solution!

Thanks very much for all your help so far.

[fluffybunny]

Ok, Hold everything. I've found a fix for this.

On hang up the phone system actually gives me 1.9 seconds of silence, then 15 seconds of Dial Tone (dual tone, 340 / 440 hz) and then continuous Number Unobtainable tone (single tone, 400 hz). Note I was detecting the Dial tone to give me a nice speedy hang up detect.

So, I now have DISCONNECT TONE set to ON in DCM, and I am detecting the Number Unobtainable tone instead of the first Dial tone. I then truncate 15 seconds off the message. This means if truncation doesent work too well, and leaves a small amount of dial tone at the end of the message it doesent matter during playback, because it isnt recognised as a hang up tone.

The only drawback is it now takes 15 seconds for voiceguide to drop the line (i.e. it waits until dial tone has stopped and it detects NU tone immediately), but hey....I can live with that!

Also I have attached are the log files showing your great new script which seems to now delete the message when someone presses "4" to delete a recording and re-record it again.

The only 2 other things I've noticed is that long messages (say 45 seconds) are being reported in the voice manager as being only 36 seconds long, and the system is playing messages in the "new first" order despite having "old first" set in vg.ini

I'll post logs showing this in a moment when I get a chance to get back on the system.

Once again, many thanks for puting up with all this stuff I keep hitting you with, I know you'll get your reward in heaven ;o)

Attached File(s)

•  logs.zip (27.65K)
  Number of downloads: 35

[fluffybunny]

Here are the logs showing the system playing "newest first" although vg.ini is specifying "oldest first" in vg.ini

All the best

Simon

Attached File(s)

•  logs2.zip (22.11K)
  Number of downloads: 38

[SupportTeam]

Ok, Hold everything. I've found a fix for this.

On hang up the phone system actually gives me 1.9 seconds of silence, then 15 seconds of Dial Tone (dual tone, 340 / 440 hz) and then continuous Number Unobtainable tone (single tone, 400 hz). Note I was detecting the Dial tone to give me a nice speedy hang up detect.

So, I now have DISCONNECT TONE set to ON in DCM, and I am detecting the Number Unobtainable tone instead of the first Dial tone.

OK, sounds like detecting a single frequency tone is working more reliably on this system then trying to detect dual frequency Dial tone. Thanks for letting us know how you resolved this.

long messages (say 45 seconds) are being reported in the voice manager as being only 36 seconds long,

What is the version of Voicemail Manager which you are using?

the system is playing messages in the "new first" order despite having "old first" set in vg.ini

The newest voicemail scripts do not get this "Newest or Oldest first" setting from the VG.INI

You''ll need to look at the voicemail script's themselves.

See vmLogin.vgs and look at modules [VmMmMenu] and [VmRmMenu] (and maybe others?). Look at function DirFind_DelimList

[fluffybunny]

OK, sounds like detecting a single frequency tone is working more reliably on this system than trying to detect dual frequency Dial tone.

I'm not sure about this. My experience is that it detects both dual and single tones equally reliably. I put it down to a Dialogic fault in that it is detecting the hang up tone as a real hang up when it is playing a recording of the hang up tone. To me that is illogical.

What is the version of Voicemail Manager which you are using?

V6.0.8

The newest voicemail scripts do not get this "Newest or Oldest first" setting from the VG.INI You''ll need to look at the voicemail script's themselves.

This seems to me to be a retrograde step. I used to be able to define this in VG.INI (indeed the vg.ini entry is still there). When I installed this system a couple of months ago it was playing "oldest first" (presumably by picking up from VG.INI) and at some point this has changed to newest first. It also doesent sound like a simple thing to change back again because of:

look at modules [VmMmMenu] and [VmRmMenu] (and maybe others?).

Any clues as to which others?

[SupportTeam]

Any clues as to which others?

The "maybe others?" comment would have related to the possibility of other modules which use the DirFind_DelimList function. Its the DirFind_DelimList function which places the found voicemail messages in a particular order. Doing a text search through other scripts suggests no other modules apart from the two mentioned use the DirFind_DelimList function.