We are setting up Microsoft Teams direct routing to coexist with Genesys Cloud.
Our SBC (AudioCodes M800) needs to route calls from the PSTN to either Teams or GC depending on the DID. The SBC’s routing table determines the destination. But the OAuth integration between GC and Teams is confusing - where does OAuth fit in?
OAuth is used for the PRESENCE SYNC between GC and Teams, not for the call routing.
Call routing is pure SIP between the SBC and both platforms. OAuth authenticates the Teams-GC presence integration so that when an agent goes ‘Busy’ in Teams, their GC status updates automatically. You need to register an Azure AD app with Presence.ReadWrite.All permissions.
# Azure AD OAuth App Registration for Teams-GC integration
New-AzureADApplication -DisplayName "GC-Teams-Presence-Sync" `
-RequiredResourceAccess @(
@{ResourceAppId="00000003-0000-0000-c000-000000000000";
ResourceAccess=@(
@{Id="9a5d68dd-52b0-4cc2-bd40-abcdef123456";Type="Scope"}
)}
)
Grant admin consent after registration. The GC admin configures the OAuth client ID/secret in the Teams integration settings.
We manage 15 BYOC trunks, and adding the Teams direct routing SBC as a 16th trunk increased our operational complexity significantly.
The AudioCodes M800 routes calls to both GC (via BYOC Premises) and Teams (via Teams Direct Routing). SIP traffic from both platforms shares the same SBC, which means a firmware bug on the SBC can simultaneously impact both GC calls and Teams calls.
Does the Teams integration support call controls (answer, hold, transfer) from the Teams client?
Our agents want to answer GC calls from the Teams app on their phone when they are away from their desk. Is this possible, or does the agent have to be in the GC browser client?
From an executive perspective, this limitation reduces the ROI of the Teams integration.
If agents still need the GC client open to answer calls, the Teams integration only provides presence sync - not a unified communications experience. Many competitors (including CXone) offer native Teams calling integration where agents CAN answer contact center calls from Teams.
I’ve helped many community members set up Teams integration over the years.
The most common mistake is configuring the GC Teams integration to sync presence bidirectionally when it should be unidirectional. If GC pushes ‘On Queue’ status to Teams, Teams interprets it as ‘Busy’ and blocks all Teams calls. Usually you want GC → Teams sync only, not the reverse.
We load-tested the Teams-GC presence sync with 3,000 agents.
At 3,000 agents, the OAuth token refresh creates approximately 100 API calls per minute to the Microsoft Graph API. Microsoft’s rate limit for Graph API is 10,000 requests per 10 minutes per app. We are well within limits, but at 10,000 agents you’d approach the ceiling.
Under GDPR, the Teams-GC presence sync transfers employee status data between two cloud platforms.
If GC is hosted in AWS EU-West and Teams is in Azure West Europe, the data transfer is between two EU data centers, which is compliant. But verify that Microsoft’s Graph API calls don’t route through US data centers, which would create an unintended transatlantic data transfer.
In CIC, the Polycom/Teams integration was a thick client plugin.
The GC integration is fully cloud-to-cloud, which is architecturally cleaner. But it means the integration’s reliability depends on the network path between AWS and Azure. We’ve seen presence sync delays of up to 30 seconds when one cloud provider has regional latency issues.
No. GC calls cannot be answered from the Teams client.
The Teams integration is presence-only. Call media stays within GC’s WebRTC infrastructure. The agent must use the GC browser client, native desktop app, or a custom Embeddable Framework application to answer calls. Teams is only used for internal communications and presence synchronization.