Friday, September 12, 2014

Sametime 9 Video Manager startup issue

Here´s a weird situation me an my colleague had to figure out one day.

The issue we noticed was that Video calls peer-to-peer was working fine, but when adding in a third caller, we got a error and the video call stopped working.

So immediatly we thought that the MCU was the source of the problem.
After a PMR regarding the MCU, we actually figured out that the issue was within the VMGR server.

We noticed this in the SystemOut.log, when starting up the VMGR.

[9/9/14 10:04:18:177 CEST] 00000041 DmaStartupSer E com.polycom.proximo.startup.DmaStartupServlet init Startup Serlvet experienced Problems: java.lang.RuntimeException: System version is null

java.lang.RuntimeException: System version is null

at com.polycom.proximo.service.core.CoreUtil.getSystemVersion(

at com.polycom.proximo.core.mbean.CoreService.getSystemVersion( 

After googling up stuff, we came into the track that there´s a lot of .sh and .pl scripts that actually gets fired when launching the VMGR. The scripts are all Polycom related.

The location of the scripts are here:
And the script which we found logical of testing was the "" script.

When we ran this script manually, we got a output that said "0.0.0". Could this be why the SystemOut.log said "System version is null"?

Ok, we opened up the script and had a look at the content of it:
And we found this:
if [ ! "${PROXIMO_HOME}" ]; then
Then, we had a look at the file it refers to, the "system_version" and it´s content said
So here´s what we did:
We figured that the "" script just didn´t know where the $PROXIMO_HOME system variable was.
So we typed in this to create the system variable:
export PROXIMO_HOME=/opt/IBM/WebSphere/MediaServerPNVMGR/proximo
Then we did a manual launch of the "" file again, and now the result was different. The output was:
So, why this system variable had dissapeared from the VMGR server startup sequense, we don´t know.

Here´s what we did to create this system variable every time the VMGR server launches.

We edited the "/etc/init.d/STMediaServer_was.init" startup script, and inserted this:

This ensures us that the PROXIMO_HOME system variable is there each and every time the VMGR server launches.

A better approach is to set this export command into the "/etc/profile" file. 
I put mine at the bottom of the file.

Then we restarted the VMGR, and the SystemOut.log error message was gone + we were able to have more than 2 people in a video call!!

No comments: