Ignite 2020: Introducing Azure Communication Services

Microsoft Teams’ growth has exploded as the COVID-19 pandemic has forced more and more companies to shift to home working and virtual meetings. With more than 5 billion daily meeting minutes, Teams relies heavily on Azure’s global network of fiber-connected hyperscale data centers and its growing number of metroscale edge sites. It’s a powerful set of technologies, with support for text, voice, and video communications, all wrapped up in apps that run on the Web, on PCs, and on mobile devices.

What if you could take advantage of those same services in your own code, using them to add global, stress-tested, reliable communications features without spending time learning how to construct calls in WebRTC? With the launch of a public preview of Azure Communication Services (ACS), now you can. Microsoft is unbundling many of Teams’ foundational services, turning them into APIs that can be quickly integrated into new and existing apps.

As Scott Van Vliet, CVP, Intelligent Communications at Azure noted, “The service that my team runs that powers Teams has been built on Azure since day one, so we were kind of born in the cloud with Teams. And thinking about the value we get from being on the Azure platform, we started thinking about what are ways in which we think people can leverage this platform?” The pandemic may have accelerated Microsoft’s plans to release ACS to help companies improve their remote working, but it’s an expansion that’s clearly been in the works for some time. The mature APIs used by Teams are ready to launch a fully fledged service that’s able to support as wide a set of scenarios as possible.

Building Teams’ back-end services into your code

Building on the internal APIs used in Teams, ACS is designed to support many different communication scenarios: one-to-one, one-to-many, many-to-many, browser, apps, bots, and even the public switched telephony network. You can also mix different options in the same app, much like Teams where you can change your communications mode as your interactions deepen or become more focused. It’s easy to image an ACS-based customer service application starting as text chat in a bot and then moving to a human agent when more complex answers are required, or even to a video call if problem diagnosis calls for images.

Developing with ACS is much like working with any other Azure service. Microsoft has provided a series of SDKs and client libraries to help you build code, treating ACS as a data plane that links application end points routing calls and messages. Browser-based applications can use the provided ACS JavaScript libraries. Similarly you can build these services into native desktop and mobile apps, tying in other Azure services like Windows Notifications to add additional features, or working with platform-specific APIs such as Google Firebase on Android and Apple Push Notifications on iOS.

Use REST-based voice and video with ACS

Access to the service is via REST APIs, so you can use it with your choice of languages and platforms. If you prefer to use an SDK, these will be available for .NET Core (ready for .NET 5 in November, with support for .NET Standard 2.0), JavaScript, Java, and Python. They will be joined by client SDKs for both iOS and Android. The client libraries that underpin the SDKs are a mix of open and closed source; the open versions are available on GitHub. With many call center and CRM applications written in Java, it’s not surprising to see it among the first set of languages supported, giving platform providers the opportunity to add support or for you to write your own extensions.

The libraries cover key ACS functions: Chat, SMS, and Calling, as well as administration and call management tools. Some tools, such as service administration, have Azure CLI support as well, allowing you to build automation scripts alongside support for software-driven Azure Resource Manager service provisioning. If you’re going to run ACS at scale, you’re going to need automation as part of any management application, especially around issuing and revoking client access keys. Libraries will be available through familiar repositories, such as NuGet for .NET, and the underlying REST APIs are documented in Open API Swagger format, making it simple to bring them into Visual Studio, Postman, or other development tools.

If you’ve worked with Azure APIs, you should find using ACS in your code familiar. All the APIs need access tokens, which you generate and distribute as calls are being made to reduce the risk of tokens being stored and reused. Once a token has been delivered to a client, it can authenticate a connection to ACS. It’s a good idea to have all call-related features in an application disabled until it’s been authenticated. Once a client is authenticated, you can start using the various APIs, choosing appropriate functions for your app. The Call library is perhaps the most featured, as it handles both peer-to-peer and PSTN-based voice and video calls, as well as screen sharing.

Some features are missing; for example, there’s no presence indicator, and if you want to use presence it’s worth combining ACS with some of the tools and services built into Office 365. Once in a call, you have access to many of the features Microsoft uses in Teams, with support for call lobbies, screen sharing, and traditional voice and video calls. Applications can use ACS features to support caller management, so in large meetings there’s the ability to manage the active speaker and remotely toggle microphone mute. Initially it will support 50 people in a call, but plans are to significantly increase the number in the future.

Reach out and call someone: Access the phone network from Azure

One of the more interesting aspects of ACS is its support for PSTN connections (launching in October) so you can work with both voice calls and SMS. These should allow you to create more inclusive experiences, using tools like Azure Cognitive Services to build more comprehensive voice recognition, with Language Understanding (LUIS) helping determine caller intent and routing messages appropriately. SMS support in the Bot Framework means you can quickly turn what was a one-way messaging channel into a two-way connection. Microsoft is building tools for phone number provisioning into the Azure Portal, simplifying setting up telephony services. Azure will provide tools to help manage phone numbers as part of the Portal.

Building an application using ACS does require some thought, especially if you’re trying to prevent abuse of calling privileges and tokens. End points need to be authorized before they can access the service, with access tokens used to manage connections. Those tokens need to be distributed by your application and embedded in connection strings. Your code will need to ensure that tokens are invalidated once a conversation ends.

Expanding the Microsoft communications portfolio with APIs

ACS is an intriguing expansion of Microsoft’s communications platform, entering the same telephony API market as companies such as Twilio. It’s going to be an interesting challenge, coming up against companies with deep telco relationships and a decade or so of developer buy-in. Starting from scratch here would be nearly impossible, so it’s good Microsoft is building on an existing, trusted platform. Companies familiar with Teams and its performance will be able to judge the service before they write a line of code.

That expansion goes a lot further than the familiar phone and PC platforms. As most of the service functionality is hosted in Azure, and the client libraries use languages such as JavaScript, you’ll be able to deploy a Node runtime to an IoT (Internet of Things) device, and give it access to SMS messaging for mobile applications that need cellular connectivity but don’t need a full data connection. You can build voice into consumer devices, maybe adding a communications loop to a doorbell or to low-cost meeting room hardware without requiring a full PC.

There’s a big opportunity here to use these APIs to provide voice and video service to frontline workers, for example providing video-based peer support to field service engineers, allowing them to share experience and get help from colleagues familiar with a problem in real time. Adding integration with other Azure Services—such as real-time translation—can help break down barriers and increase the reach of applications without adding to development costs and time.

As Nick McQuire, SVP of Enterprise Research at analysts CCS Insight, points out, the lack of communication tools for application developers is a gap that’s been clearly shown by the rapid shift in how people work, and it’s one that its experience with Teams is allowing Microsoft to fill. “The shift to remote everything during the pandemic has meant that developers are now more attracted by communications-based features in their applications. It’s an area of opportunity that telcos worldwide have failed to grasp over the past few years and, above all, shows that Microsoft has ascended to become one of the world’s most important communications companies as well.”

Even though ACS is launching as a relatively mature service, it’s clear that more can be done with it. You currently need a reasonable level of coding experience to build an ACS application, which limits its audiences to those who have available developer resources. With end points for Microsoft’s low-code Power Platform in the roadmap, there’s an interesting future ahead for a platform that democratizes one-to-one and many-to-many communications.