Has anyone run into this? Just got 2 back to back here in the office. Pretty sure the calls came in on the same analog line but I haven't changed any settings.
I had the same issue with an IPO 4.0 with analog trunks. I used the following source number entry on 'NoUser' to fix the problem:
VM_TRUNCATE_TIME=1
I am using a value of '1', but I think you may put a value of 0 through 7. The number represents the number of time 'cut' from the end of the voicemail message. Z
Having exactly the same issue. If you look at your voicemail log files you will see the following:
----------------------------------------------------
09:11:27.968 - StartRecording C:\Program Files\Avaya\IP Office\Voicemail Pro\VM\Greetings\MSG04420.WAV
09:11:44.265 - Receive CLOSE for session 179, call-id 0
09:11:44.265 - Removed 9656 bytes from recording (0.603500 secs)
09:11:44.265 - Removed 112000 bytes from recording (7.000000 secs)
09:11:44.265 - EndRecording
---------------------------------------------
Notice that you see the "Removed . . . bytes....." VM Pro is successfully telling you that it is truncating the message but I am not sure why. I have a support call in the works as we speak. I currently only have POTS lines to test so not sure if issue is on PRI, etc... I have also tested this internally (i.e. if you call from one extension to another and leave a VM) and it does not create this issue. The voicemail is fine when used internally and I have not captured the "Removed...." when doing so.
One more thing - I have tried this about 50 times so far (calling in on different trunks, leaving different voicemail lengths, etc...) and the amount of the message that seems to be truncated is around the 7 second mark (Please review your log files) and the byte sizes seem to be about the same as well no matter what!
I had a field trial system running 4.0, and I learned of the fix early in the trial period (I had reported the issue). I am in the U.S., and it seems that the GA version requires me to keep that adjustment. Z
I set the value to 1 as mentioned by "TheZCom" and the problem went away (after reviewing the log files you will see only 1 second removed and very little data (bytes). I'm thinking of testing the 0 as opposed to 1 however I'm not sure how any of this ties together with the No User. Ronromano - the 1 should have worked for you. I did the same thing (implemented the No User change) but did not reboot. As soon as I rebooted the problem was resolved!
Ok - I set the value to zero "0" and the log files still show a very small byte amount of data being removed however it works perfect. Thanks for all the help and any technical insight as to why this is the way it is with 4.0 would be great.
One more question. In a SCN scenario do all the originating IPO's need to have the No User modified or just the central IPO where the call is passed to over the IP Line? Perhaps I should just set them all just to be safe?
Wait, now my hunt groups won't go to voicemail until they ring for 45 seconds regardless of how long my "no answer" interval is. It worked fine before I made the change to the "No User". Any thoughts?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.