I’ve been asked by a few colleagues and peers to explain the journey I’ve been on when migrating a H.323 based video conferencing environment into a Skype for Business based environment.
My story starts a little before H.323, as I started out installing H.320 (ISDN) based codecs. These used three basic rate ISDN lines (BRIs) that were mixed together to give a 384kbps signal path. We progressed to using primary rate circuits and cutting out six channels to provide 384 kbps conferences, but in a more efficient manner. This system had its problems. One glitch on the line and the channels would drop, meaning a manual redial and time lost. Dialling-up a connection was sometimes hit and miss, requiring both endpoints to be re-booted. The communication costs were also high, so we looked to save money by moving to an IP based solution as soon as it was feasible.
The IP communication path across dedicated IP circuits, or even public internet, was less sensitive to glitches, so a vast improvement over ISDN, but heavy background infrastructure was still required. In the case of Cisco (formerly Tandberg), VCS controllers, MCU bridges and gateways were needed to be able to run a global deployment. Maintenance costs on background infrastructure were heavy. In our case it was over $1 million per annum, and that was just servicing dedicated video conferencing rooms!
A few years ago the IT department rolled out Microsoft Lync (now Skype for Business) to everyone’s desktop; that’s around 50,000 users. Very quickly it became the method of choice for communicating and presenting to colleagues around the globe. Users then began to ask if we could add their desktop ‘VC’ system into a room-based video call. The answer was yes, but there was an added complication; the H.323 based room systems and Skype for Business systems don’t use the same protocol. Some translation was required, so yet another box (or six) were needed to be added to the background infrastructure.
This all worked but it was a little clunky. Around this time, we needed to replace some end-of life equipment, while at the same time trying to cut operating costs, so, we looked around to try and find a Skype for Business room-based system. It was at this time that we came across StarLeaf.
Back then StarLeaf was well established as a cloud-based video conferencing service that not only had its own endpoints, but could incorporate Skype for Business and any standards-based codec into a call. The problem was that, being at a bank, I wasn’t allowed to register our codecs to the cloud. StarLeaf had the answer for me; Teamline. Teamline by StarLeaf features a family of codecs designed to register natively to a Skype server and act just as any desktop would.
I begged, borrowed and stole a Teamline codec (formally known as a GTm), installed it on the network and started a simple POC test. It all worked well, we had to get around a few internal issues (such as giving an inanimate object an email account), but generally there were no issues that could be considered roadblocks.
The plan was to replace a number of H.323 codecs in London while the building was undergoing a re-fit. This was a four-year project to strip out the old facilities services and to replace and update the working environment. It was at this stage we started making demands from StarLeaf’s Teamline. We needed to be able to control the units from a Crestron control system, so a fully functional API was required. We also discovered that the Teamline control panel held some of the Skype for Business credentials for the system so it couldn’t be removed; we’d have to place two touch panels in the meeting room, even though one should not be touched by the user. This was not a good place to be, so we asked Teamline to see if the credentials could be stored in another way so that the touch panel could be removed.
This is when the vendor really stepped up to the plate. Not only did they make it possible to remove their touch panel, (which wasn’t ideal, as any feature changes in the Teamline room system might require the Crestron Controller to be reprogrammed - always an expensive exercise), but they also redesigned their front-end UI so that other control functions, like lighting and window shades, could be added to the Teamline touch controller. At this time, I asked if we could use the codec to switch PC inputs directly onto the display screen even when not in a call, effectively making it a simple system switcher. This enabled us to reduce the amount of kit in the room and make the ROI a lot healthier.
The Teamline engineers said they’d look into it. Well we’ve all heard that from manufacturers before, haven’t we? Normally it’s several months or even years before anything gets done, but not in this case. The team came back within six weeks with a prototype UI for me to look at and approve. Within three months it was in the GA product.
While this was happening, my IT colleagues came up with a request for a video meeting room estate management application. After all, if all goes well we’ll have over 500 units in operation around the world within three years. Teamline had a management platform in the cloud (Maestro), which wouldn’t work for us, so they set about creating an on-premise version that IT could drop onto a VM in the data center. That arrived in short order and we started a set of roadmap sessions to develop new features that would make it truly useful. Cisco and Polycom had developed their platforms over a number of years, so asking Teamline to do it all in one go was a heavy burden.
Customer support was and has always been exemplarily. Teamline dispatched an engineer to New York to work with our Crestron programmer when we first started working with the API. The Teamline engineer even re-wrote the base code over the weekend to fix an issue and to add new features to the API. The company also sent engineers to our London office when we had an audio issue, even though that issue was not with the Teamline system, but in how the microphone and DSP had been configured.
So, what do I think of the experience? Well, we wouldn’t be where we are today without the help of an agile manufacturer who saw the benefit in working with a potentially global customer to ensure that our first steps into the field of Skype for Business in a meeting room were well supported. We made no promises on future orders and stated that we wouldn’t pay any extra for the features we were asking to be added. ‘If it doesn’t make commercial sense, then don’t do it’, was the phrase I used. They did everything I asked; from first deployment into a meeting room, through to a bunch of rooms going live with fresh faced users, the process took around six months. Try getting either of the big two to respond that quickly!