Presence Sync: how it works and architecture

What it is for

Presence Sync synchronises the presence status between Microsoft Teams and Cisco telephony. The most common case: an employee is on a call on the Cisco desk phone. Without synchronisation, Teams still shows them as available, colleagues call or write and interrupt the call. With Presence Sync they are shown as "In a call" in Teams for as long as the call is connected.

This chapter explains the function before you set anything up: which variant belongs to which Cisco client, which state is transferred in which direction, how a single synchronisation run proceeds, which interfaces and permissions are involved and what is transferred to Microsoft. The setup itself is described in the following chapters.

Presence Sync is a module of its own with its own workspace and its own background service. It needs neither the Teams SBC nor the ACD. A presence profile has no SIP port, no host name and no certificate.

Prerequisites

• You need no permission to read this chapter. For the setup, the roles from the chapter on the presence profile apply.
• You know which Cisco client the users work with: desk phones and Jabber with Cisco IM and Presence, or the Webex App. The variant depends on this.
• You have access to Microsoft Entra to create an app registration and grant admin consent.
• For the Jabber variant: a CUCM with call monitoring set up in EasyUC and, for the Jabber status, a Cisco IM and Presence with a reachable presence web service.

Step by step: how to proceed

1. Determine the variant using the table Variants at a glance.
2. Read the state tables and clarify with the business department which directions are needed. Often CUCM-Anrufstatus → Teams (CUCM call status) is enough.
3. Use the table Interfaces and permissions to check which accounts and approvals you have to prepare.
4. Read the section Limits so that the expectations for "Do not disturb" and "Presenting" are right.
5. Then set up Presence Sync with the end-to-end checklist.

Fields and options: variants at a glance

State table: Cisco → Teams

State table: Teams → Cisco Jabber

How a synchronisation run proceeds

1. Every 5 seconds the presence service checks for which profiles the configured interval has elapsed. A lock in the database prevents two runs from publishing for the same profile at the same time.
2. It loads the user mapping of the profile. Ambiguous matches are excluded and count as conflicts.
3. It reads the sources of the directions that are switched on: connected calls of the CUCM connection, Jabber status from the presence web service, Teams status from Microsoft Graph.
4. For each user it compares the state it has read with the last one observed. Only a change creates an entry in Presence Live. Unchanged queries write nothing.
5. It determines the target state according to the state tables. States that cannot be transferred are logged as skipped with a reason.
6. It publishes new states, refreshes existing ones before they expire and removes states whose source has ended.
7. It stores status, message and time of the run at the profile. The interface shows these values under Last check.
8. If synchronisation is switched off or the module is stopped, the service removes only the states set by EasyUC. The settings of the profile are kept.

Data flow and storage locations

Interfaces and permissions

Limits

• "Do not disturb" is not transferred in either direction. Both vendors treat this state as a personal decision of the user, which EasyUC does not overwrite.
• "Presenting" cannot be derived reliably from the Jabber status and is not transferred.
• From Jabber, only "Available" and "Away" reach Teams. A call status comes exclusively from the call monitoring of the CUCM.
• Shared CUCM lines (shared lines) are not attributed to a single user and set no call status.
• Only one presence profile may publish per Entra app. Only one profile may write to Jabber per application user in IM and Presence.
• The synchronisation polls the vendors cyclically. States that last less than the interval can go unnoticed.
• In Webex mode, Beobachtet (observed) means that EasyUC has read a source status. It does not confirm an individual transfer by Cisco.
• How Jabber displays a status set from outside and merges it with its own sources depends on the version of IM and Presence and Jabber. Check this with your versions during acceptance testing.

Check the result and narrow down errors

• You have understood the function when you can predict for a test user what Teams shows during a call on the Cisco phone and what is not transferred.
• If the expectation does not match the behaviour, open Presence Live and read the entry of the user. Result and reason state what EasyUC did or omitted.
• If a user does not appear in the log at all, they are not mapped uniquely. Check the mapping in the profile with Zuordnung prüfen (check mapping).
• The individual messages with meaning and remedy are in the chapter on error patterns.