Recently I faced an interesting problem again, that I want to share with you. Should you ever have the same problem, I hope you will find this post and that you can save some time searching for the root cause. There had been a customer call, that Media Manager plays no recording.
A short look into the recordings page seemed to be fine. The system showed all made recordings. But as soon as you clicked the play button the small player window appeared. Unfortunately you couldn’t hear anything. It looked similar to the following picture with the exception that the length of the recording has been shown as zero seconds.
How Media Manager works
Until a recording is available in Media Manager it has to go a long way. It is required to have an additional hard disk in the server, that has to be initialized through the server’s web interface. Obviously Voicemail Pro is also needed.
Within the IP Office configuration you have to define, what kind of calls are recorded and where the recording has to be stored. If you use Media Manager you have to configure IP Office to store the recordings in the Voice Recording Library (VRL) instead of in a mailbox. As soon as IP Office decides to record a call, it creates a kind of a three party conference call with both call parties as well as the voicemail server as participants. That way Voicemail Pro is able to record the call. The recording will be stored in the VRL path on the primary hard disk of the Application Server (or of the Primary Server) first.
In the next step there will be an entry in the Media Manager database created. That entry contains information about the call (time stamp, participants, duration, …) and the path on the additional hard disk, where the file should be stored later.
Finally the file will be – obviously regardless of the consequence – moved from the VRL path to the target path on the additional hard disk.
Searching for the issue
While searching for the cause of the issue, that recordings couldn’t be played, I tried to follow the steps the recording takes. I have been able to see that the recording file had been stored in the VRL path. Next, the file should disappear there and should appear on the additional hard disk. But that hasn’t been that case. Compared with other – working – Installations, I figured out, that the access rights of the additional hard disk had been wrong.
To understand that, you have to know that Media Manager is running as user “Tomcat” and moves the files in that user context. But I was able to see that the user “root” instead of “Tomcat” is the owner of the target directories and all other users only have the rights to read files. On a working installation all users had file writing rights. Now it became clear what happened. Media Manager tries to move the file from the VRL path onto the additional hard disk. During this task the file is deleted from the original path but not placed in the target path. That’s why the call is listed in the user’s web interface but the link to the recordings file leads to a non existing file.
With that new knowledge it was easy to solve the issue. I only had to adjust the folder rights on the additional hard disk, so that it matched with the working installation.
chmod 777 /additional-hdd#1/
Again it was a small issue that led into a bigger problem. I faced a similar issue with Voicemail Pro in the past, where wrong folder access rights had been the cause that no more user variables could be stored.
With that adjustment Media Manager now works as expected. Sadfully all the older recordings are lost. From my point of view Avaya has two weaknesses. First, it doesn’t make sense to configure a directory with full access for everyone. Second, I can’t understand, why the script that moves the files, doesn’t copy the file first and deletes it only after checking for the existence at the target path. That way it still wouldn’t be possible to play the recordings, but the recordings wouldn’t have been lost forever. Afterwards it has not been possible to figure out the root cause for the wrong access rights. The server had been upgraded in the past. Perhaps during that process the issue occurred.