Learn Azure Communication Services Day 4 – ACS vs Microsoft Teams: the discussion

Today, we’re going to look at how Azure Communication Services fits into Microsoft’s communication strategy alongside Microsoft Teams. There’s a fair bit of confusion at the moment about what runs on what, which is better than what, and so on. I’m hoping to de-mystify some of this.

Product vs Service

Microsoft Teams is a product. Azure Communication Services is a platform. That’s an important and fundamental difference. ACS is a platform which developers use in order to add communication services into their products, but by itself, ACS is not a product. There’s no end-user application to download, nothing to enable. If you want an out-the-box communications product for your user, that’s Microsoft Teams, not ACS. If you want developers to be able to add communications workloads into new or existing solutions, that’s ACS.

How are Teams and ACS related?

This is the best image I’ve found to explain this (if you ignore the Dynamics reference):

If this is still confusing to you, try this. Internally at Microsoft, the voice/video/chat workloads in Teams are provided by IC3 (Intelligent conversation and communication cloud). From an old job post about IC3:

The IC3 Data Platform teams own multiple critical infrastructure micro-services for an ever-expanding number of end-customer features in both Microsoft Teams and Skype for Business. Built using the Azure Cloud, we provide O365-compliant API and Storage services to dozens of micro-services for Teams/SfB, with well over 1 Billion requests each day to our services and growing exponentially. From signing in, to connecting calls/meetings, to configuring user settings, calls to our services enable so many critical scenarios that our customers rely on. With an aggressive list of customer features coming over the next year (and beyond), along with massive growth in usage, the scope and impact of IC3 Platform teams are only expected to grow.

You can think of Azure Communication Services as a limited, public API to IC3. It allows developers access to use this same platform for their own communication workloads.

That’s why people say that Teams is “built on ACS”.

What does Teams do that ACS doesn’t?

Remember that Teams is a product and ACS is a platform. That means that this sort of comparison isn’t very helpful because it’s comparing different things. However, there are some areas where I think ACS is lacking behind Teams in its provision of communications services. It’s worth remember that we are still VERY early in the ACS lifecycle (not even GA as I write this!) so all/some of these features may be added over time.

• It’s still in preview. Right now the only place you can provision an ACS instance is in the US Region.
• There’s no management or administration experience. There’s no equivalent to the Teams Call Quality Dashboard, and no in-built reporting of calls.
• There’s no native recording of calls.
• There’s no Direct Routing.
• There’s no support for SIP Phones.

What does ACS do that Teams doesn’t?

ACS has features that aren’t applicable to Teams, such as sending SMS etc. but I’m going to focus on the one area that will be of most interest to Microsoft Teams Platform Developers:

• An ACS-enabled application can make/receive VoIP calls and host/join Group Calls. This is similar to Teams calls and meetings but with the freedom to develop or embed your own interface entirely separately from Teams.
• ACS-enabled applications can use the new Teams Interop feature to join Microsoft Teams meetings as a guest user. This is a huge step-change for Teams development: it’s not possible to do this today without ACS.

Teams Interop Considerations

The Teams Interop feature in ACS is still in public preview so it may still evolve between now and when it becomes generally available. However, I’ve noticed the following things that developers should consider when evaluating which approach is best:

• There’s no integration with Microsoft Teams presence. Meaning, if you deploy an ACS application to a user that also have Teams, now they have two ways to receive incoming calls and if they answer on ACS, nothing is going to magically change their Teams presence to “In a call”, leaving them open to receive another call in Teams.
• Today, there’s no peer-to-peer calling between ACS and Teams users.
• Today, Teams users can’t join an ACS-hosted group call.

The other important thing to be aware of is that any calls made using Azure Communication Services are billed on a per-minute basis and deducted from your Azure credits, NOT your Microsoft 365 Phone System account. E3, E5 or any other Microsoft 365 license that includes calling doesn’t apply to ACS calls.

Does ACS integrate with Cloud Communications API?

The Cloud Communications API is a Microsoft Graph-based API that surfaces calling and online meeting information from Microsoft Teams, including the ability to handle incoming calls, transfer calls etc. There’s seemingly a lot of overlap with this and some of the functionality provided by ACS and so it’s natural to ask if there is integration between the two.

However, the answer is no. According to Compare Azure Communication Services:

“Microsoft Graph Cloud Communication APIs allow organizations to build communication experiences tied to Azure Active Directory users with M365 licenses. This is ideal for applications tied to Azure Active Directory or where you want to extend productivity experiences in Microsoft Teams….[Cloud Communications APIs are] not directly interoperable with Communication Services at this time.”

Azure Communication Service is also not interoperable with Azure PlayFab Party, but I don’t have any experience of that.

---

Today we’ve looked at ACS functionality in comparison to Microsoft Teams. In the upcoming posts we’re going to jump into writing code for a simple VoIP client. Links for all blog posts can be found at learnACS.dev. You can also subscribe to my YouTube channel for videos about ACS (and much more!).