This week’s Sametime PMR was a problem with Audio / Video on a newly deployed infrastructure. This is a long blog but hopefully you’ll find it all useful. The installs all went fine and the peer to peer calling worked, which meant the clients were able to register with the proxy registrar. However multi user or meeting video was failing.
The first thing you need to know about ST Audio / Video is that there are several moving parts – in this instance all servers are installed on SLES11
- Proxy Registrar / Conference Manager – in this environment both these applications are installed into one instance of STMediaServer
- Video Manager which is a WebSphere server installed as a standalone node (outside the SSC cell) and requires SolidDB (which the Video Manager installer places and configures)
- VMCU – the Video MCU which will handle the multi way video traffic via the Video Manager
The second thing you need to know – and it’s not well documented at all – is that the start order of those elements is vitally important. Start them in the wrong order and you won’t get any audio / video at all (if you check your Sametime client preferences you will not see any A/V components or options). So what’s the start and stop order?
Start with Video Manager components
- Soliddb must be started first using /opt/soliddb/soliddb-7.0/bin/solid -c /opt/soliddb/soliddb-7.0/eval/standalone*
- Once started the Video manager can be started using the server name STMediaServer
- Start the Video MCU by typing : service soft_mcu start (also “status” and “stop”) work
- Start the PR/CM WebSphere server STMediaServer
To stop all elements do 4-3-2-1 in reverse
To stop soliddb type solsql then when prompted for login details use the name and password admin
issue the commands (with a semi colon at the end of each line)
admin command ‘force shutdown’;
*soliddb listens on port 2315 – you can verify it’s running or stopped by doing a netstat. On linux that’s
netstat -an | grep -i “2315”
(the solid.ini file in /opt/soliddb/solidb-7.0/eval/standalone will tell you which port is being used by the server)
The next thing you need to know is that even if it all installed perfectly you must go through the process of exchanging certificates between the PR/CM in the SSC cell and the Video Manager standalone server. This is documented here and this is where my PMR occurred The problem was once the certificates were exchanged we lost all video completely. Even peer to peer. I assumed it was a small problem, maybe my start order or I wasn’t letting everything have enough time to start but no.. the problem was that we were using a wildcard certificate.
IBM do support wildcards, they have to since the ST Advanced server and ST Proxy server must share a certificate. Unfortunately we discovered that the underlying video software (which actually comes from Polycom licensed to IBM) doesn’t support a wildcard certificate so when I did the exchange, everything broke. Once I knew that I reverted the Video servers (PR/CM and Video Manager) to the IBM installed certificate (since the clients don’t directly connect there) and everything started working.
I am waiting to hear back from L3 if using the mixed certificates (wildcard for ST Proxy, Meeting and Advanced and IBM installed for the Video and SSC) will present any problems but right now we are back in business with all ST features.
Regarding the startup order. You are correct about 1 and 2. But you can restart the MCU and SP/CM at any given moment. They will reconnect eventually via a keep alive mechanism.
Agreed but I wanted a simple startup order that would reflect as few errors in the logs as possible so that’s what I use. Similarly for shutdown I found the VMCU often had to be restarted if I shut down the VMGR first but I may have been unlucky with that.
To be honest, I don’t have any issues with the startup order (have several ST9 envs running). Only thing you need to keep in mind is to start the solidDB first than the VMGR. As Peter mentioned the VMGR, SIPREG, CONFMGR and MCU’s do send out keep alive messages and will connect eventually after a restart of one those servers.
There should be no reason that the startup order for VMGR and VMCU matters. We start and stop these independently all the time. If the VMCU¹s are not there, then VMGR will just loop trying to connect.
Ping me via email or DM; I have more info to share…
The whole theory of us manually doing anything like this is plain dumb. There is no reason they have not somehow accounted for the startup and shutdowns in services, dependencies and other ways
Hear hear. All this manual copying, configuring, starting of services. Too much voodoo!
Hi Gabriella, do you have any updates to this issue? We’re having the same issue at a customer site where they are using wildcard certificates.
I have spoken to both IBM and Polycom who say there should be no issues with my current configuration of wildcard for ST Meeting , ST Proxy, ST Advanced and the IBM installed certificates for the PR/CM and Video Manager. Apparently there is a problem in the underlying code which will require a fix but no word on that yet.
Thanks Gabriella for the response, appreciate it! 🙂