LCS to Teams: A History of ice Contact Center with Microsoft

From the early 2000s to our Teams Contact Center Certification earlier this year, ComputerTalk has been working alongside Microsoft for a long time to build the best products and integrations that we can for our customers.

Early History with Microsoft Speech Server

ComputerTalk has been visiting and working with the Microsoft Redmond Campus for years. On one such occasion, about 15 years ago, there was a Technology Adoption Program (TAP) event for a new version of a product called Microsoft Speech Server (MSS).  ComputerTalk had already started building a Microsoft practice around custom speech applications to complement our contact center business. We got involved with MSS because we were working on a project to more closely integrate ice with third-party Interactive Voice Response (IVR) systems.  At that event, we got to spend four days with the product group and learn all about the plans for what was supposed to become Speech Server 2007.  We ended up working closely with those folks in the following couple of years, including an in-person ice/Speech Server demo that involved shipping physical servers down ahead of time (it was 2006 at that point, and when you needed telephony cards to run ice, you didn’t have many options). 

Bringing Instant Messaging Into the IT Space

Parallel to this, in early 2006, we started looking into a product called Live Communications Server (LCS) 2005.  At the time, LCS 2003 had been released, and LCS 2005 had just come out into Microsoft Developer Network (MSDN), billed as an enterprise instant messaging (IM) system. The story goes that Microsoft discovered that customers were using MSN Messenger (or ICQ, AIM, or Yahoo messenger) for chat inside organizations (including inside Microsoft), so they decided to come up with an IT-manageable version of MSN messenger, called Live Communications Server. 

What was interesting about LCS though, was that it used Session Initiation Protocol (SIP) for instant messaging. This is the same protocol we’d been implementing for use in ice 6.0 since it’s the standard protocol for Voice over Internet Protocol (IP) signaling.  We wondered if there was a way to adapt our chat protocol that we’d built (for a product called iceChat) to use LCS IM so that ice could handle instant messaging conversations for customers doing things like internal help desk.  Since there were no documented Application Programming Interfaces (APIs) at the time, our solution was to use Wireshark to read the message capture of an LCS IM session and reverse engineer the whole protocol.  This worked surprisingly well, and we rolled IM support into ice 6. 

From LCS to OCS

Along the way with this process, we started getting invited to preview events for what was being promoted as Office Communications Server (OCS), the next evolution of LCS.  Evidently, the LCS product was being rolled into the wider Office server product line, and the limited voice capabilities of OCS (you could make peer-to-peer calls, but it wasn’t very widely used) were being expanded on.  We already had our IM implementation, but the prospect of being able to leverage OCS for voice was interesting to us. 

Working with early versions of OCS 2007, we actually managed to get voice calls from OCS into ice, and started trying to add in support for things like video, screen share, and IM to voice elevation.  This was something that was only possible because we had a team that knew SIP backwards and forwards at this point, and because we were using a pretty flexible SIP stack where we could manipulate the messaging at will.  Microsoft used the SIP Requests for Comments (RFCs) more as a suggested starting point than a rule at that point, so interoperating directly with OCS was challenging.  To be fair, it also wasn’t officially supported.  Still, we used our experiments with SIP interop to show the product groups what was possible and to push for more official interoperability support with platforms like ice. 

So, at the time, this meant we had two parallel Microsoft initiatives: one with the Speech Server product team, who had some great development tools and APIs that we could use for building advanced speech IVRs for ice; and one with the OCS product team, which was building this new collaboration product into something very interesting that we could use for chat, and possibly voice and video as well.  Then, in mid-2006, we got a call from the Speech Server product group that changed everything: the Speech Server 2007 release (which by this point had been pushed back a couple of times) wasn’t going to happen, and instead, the tech was going to be rolled into OCS 2007.

A Potential PBX Replacement

In actual fact, it took a while for those efforts to come up with much that was interesting.  OCS 2007 shipped, and for the first time, there were a couple of different APIs for it.  The Speech Server 2007 components were their own piece, as was the Communicator (client) software development kit (SDK) for custom clients. But there was also a new Unified Communications Managed API (UCMA) 1.0 that allowed developers to work with the SIP stack, build chatbots, and work with presence.  It was pretty clear that the integration efforts would take some time, and Microsoft was also shifting priorities with this product.

In early 2008 we started hearing about what would become OCS 2007 R2.  While it might look like a minor release, R2 was pretty significant in what it added to the voice space, and it was the first time you could legitimately replace a private branch exchange (PBX) with a Microsoft server.  At the time, we were still a ways off from Office 365 being a thing, and most organizations ran their own set of servers for things like email and chat, along with having a PBX (usually run by a PBX team, not IT) for their corporate phones.  Now, all of a sudden, there was an option where IT, who was already used to running Microsoft servers, could deploy a server product that offered dial-in audioconferencing and public switched telephone network (PSTN) calling, as well as internal chat, desktop sharing, and video calling. In a lot of cases, this started to negate the need for a PBX (although it would be a few years before Microsoft would start making this claim).  Given Microsoft’s track record, this is where we started to wonder whether Microsoft was about to overtake the PBX and “desk phone” market and how we could tie our fortunes to theirs. 

New Opportunities with UCMA 3.0

While the OCS 2007 R2 release definitely started seeing more adoption, it would be the next release that really changed ComputerTalk.  In 2009, we saw the first bits of what would become Lync 2010, and more importantly, UCMA 3.0.  This was the convergence where the Speech Server and SIP DNA finally became a single, somewhat cohesive API surface.  It would allow us to do things like automate placing and receiving calls, create multiparty conferences, and manipulate those conferences at a very low level, changing the programming of the audio mix inside a session.  There was even some great potential for the future, with classes like “AudioVideoCall” promising the ability to handle video in a later release.  Clearly, this was a huge step forward for Microsoft, and a huge opportunity for ComputerTalk. 

Previously, the Telephony Interaction Manager (TIM) layer of ice would carry out operations like playing prompts, moving calls around in conferences, starting recordings, etc. by talking to a set of Natural Microsystems (NMS) boards for hardware telephony.  The challenge was that these boards were expensive, proprietary, and not virtualizable, so we had started looking for alternatives already.  When UCMA 3.0 came along, we decided to go all in on Microsoft, and rebuild our TIM layer on UCMA.  We’d have the best of both worlds: a generic SIP/media API that could virtualize, and an integration with Microsoft that could help us become the definitive contact center for the Lync world.  We were in a unique position here because we were able to adapt an existing, mature, contact center platform to be Lync native, rather than inventing a new contact center from scratch. 

Lync and ice 7.0

Lync Server 2010 launched in late 2010, and was the first release where Microsoft claimed to be able to answer a PBX RFP with their software.  At the time we were busy working on what would become ice 7.0, the most substantial rework of our core product that we’d ever attempted.  Through 2010 and 2011, we continued to work with the product group on refining UCMA and Lync server into what we’d need to power ice, and in 2012, a few things happened.  First, Microsoft released Lync Server 2013, which broke through to even more enterprises.  Second, we released ice 7.0 as a fully Lync-native contact center product.  In this version, agents could handle calls and chats in the Lync client, and we shipped a webchat client that would relay chats from web users to agents over UCMA through ice. It also featured full compatibility for the rich set of applications customers had built on ice Workflow.  Finally, in 2012, Microsoft also released its first certified contact center applications program.  We had actually been working with the product group to refine what the certified Contact Center test plan would contain leading up to this, and were one of the first contact centers to be independently certified on Lync 2013. 

Following the Lync 2013 release, both Microsoft and ComputerTalk started looking at “what’s next” as well as refining the releases that were in market as more customers came online.  This is where we really started to stretch Lync to its limits, which started a years-long process of optimizing, refactoring, and tuning the way that ice and conferencing interact.  We continued to share these learnings with Microsoft, who incorporated our feedback into core Lync features where they could.  This included things like clearing conference metadata out of the fabric, and ensuring that conference dialouts were connected as soon as possible (without waiting for direct candidates to time out).  We also latched onto new features as they released, with features like support for Skype Video through ice being available in ice the same day as the Skype/Lync interop was announced in 2014. 

From Lync to Skype for Business

Speaking of Skype, in 2014 we started hearing about how the Microsoft acquisition of Skype was going to impact Lync, which went through its fourth name change to Skype for Business (SFB) Server.  Again, ComputerTalk was one of  the first applications to receive the Skype for Business 2015 certification with our new ice 8.0 release.  Momentum was definitely growing in the market for Lync (now Skype for Business) as a PBX, and ice being able to integrate with any on-premises infrastructure was a fantastic story, but unified communications (UC) in the cloud was also finally starting to take form.

ComputerTalk knows a thing or two about running cloud services.  We’d been operating ice as a hosted service since we started in 1987 and had always told customers that it was their choice where they’d run ice: as an on-premises server in their data center or as a service running in ours.  By 2015, we were solidly in the cloud services business, and customer-premises equipment (CPE) installs were becoming fewer and further between.  At the same time, we’d been watching this service called “BPOS” (Business Productivity Online Suite) from Microsoft that was offering items like email as a service.  Of course, this would later evolve into Office 365 (and then into Microsoft 365) and offer Skype for Business as a core feature, but that was still a few years off. 

Between about 2012 and 2014, Microsoft had an initiative running to allow third parties to host multitenant Lync configurations that could offer most of the Enterprise Voice features that Microsoft wasn’t offering themselves.  This is something that we investigated pretty thoroughly, since adding Lync as a service to our existing Contact Center as a Service offering was an attractive idea.  Again, this meant working with another aspect of the product group in Microsoft to make sure that the features that ice needed to operate worked well in this new multitenant version of Lync server, and working with the independent software vendor (ISV) partner community to show how Contact Center can complement UC as a Service.  In the end, support for Lync Hosting Pack (LHP) wound down pretty quickly, for the most part because Microsoft started offering a better version of this service themselves as part of Office 365.  What did not change, however, was the support we invested in for federation and multi-cloud solutions, where ice runs in our cloud, and Lync (or Skype for Business) in another.  Since we always made sure that we had a way to connect an agent to a contact center using only a voice call and a data connection, we could support a hybrid cloud scenario.  As Office 365 became dominant, our focus shifted to making sure that ice worked well before, during, and after a migration.  Again, working with the Skype for Business product group, we made sure that voice, chat, and video scenarios all worked with federated Office 365 users, which made the onboarding process much easier from an end user perspective. 

The Introduction of Teams

In 2017, Microsoft launched a new application called Teams. At first this was viewed as a third communication platform that wasn’t really email and wasn’t really chat, but as we’d soon find out, there was a much larger plan for this new application.  We’d been hearing for a while how unsustainable Skype for Business online was, and having some experience with LHP and running our own SFB infrastructure to power our own cloud, we could understand why that was true.  Users needed to be homed on servers, and servers were part of a tenant, so operating at a scale of hundreds of thousands of tenants must have been a nightmare to manage.  This means that when we got the early briefing on the plans for SFB online to be replaced with Teams, we weren’t really surprised once we saw the architecture diagrams.  We then started to talk with product about what the new API layers for Teams would look like, and what the “cloud UCMA” would be. 

As cloud calling started to come together, we went to the Teams product group (which was a blend of both old and new faces by this point), and discussed what we’ve learned over the last 8-10 years of building on Microsoft Telephony, and what we could do together that would be awesome.  What we ended up zeroing in on first was how to optimize the agent experience for Teams, which is why we developed iceBar for Teams as a Teams-native contact center endpoint.  We also worked with the TAP team on early release features like Direct Routing, to make sure that agents had the fastest and most reliable audio connections to ice.  We also pioneered the contact center certification program yet again, working with the team on the requirements, and being one of the first applications to certify on Teams. 

What’s Next?

Looking forward from here, there is certainly a lot going on in the Microsoft UC/Collaboration space to be excited about.  Right now, we’re working with pre-release versions of a lot of different Microsoft APIs, and coming up with new ways to deliver contact center as a service.  One of our core realizations a few years back was that the underlying tech matters less now than it did in 2011.  Back then, having a contact center that would plug into your existing Lync infrastructure, use your SIP trunks and dial plans, and have a common management platform was an important feature.  Now though, if that contact center is running as a service, the underlying tech doesn’t matter as much as the agent experience, which is why we’re focusing on things like better chat, voice, video, screen share, and collaboration using both Teams and non-Teams clients.  ComputerTalk and Microsoft have a pretty deep history, but the future is, in a lot of ways, much more interesting.