Presence Sync : fonctionnement et architecture

À quoi cela sert

Presence Sync synchronise l'état de présence entre Microsoft Teams et la téléphonie Cisco. Le cas le plus fréquent : un collaborateur est en communication sur le téléphone de bureau Cisco. Sans synchronisation, Teams l'affiche toujours comme disponible, des collègues l'appellent ou lui écrivent et interrompent la communication. Avec Presence Sync, il est affiché comme « In a call » dans Teams tant que l'appel est établi.

Ce chapitre explique la fonction avant toute configuration : quelle variante correspond à quel client Cisco, quel état est transféré dans quel sens, comment se déroule une exécution de synchronisation, quelles interfaces et autorisations sont concernées et ce qui est transmis à Microsoft. La configuration elle-même est décrite dans les chapitres suivants.

Presence Sync est un module à part entière, avec son propre espace de travail et son propre service d'arrière-plan. Il ne nécessite ni le Teams SBC ni l'ACD. Un profil de présence n'a ni port SIP, ni nom d'hôte, ni certificat.

Prérequis

• Aucune autorisation n'est nécessaire pour lire ce chapitre. Pour la configuration, les rôles indiqués dans le chapitre sur le profil de présence s'appliquent.
• Vous savez avec quel client Cisco les utilisateurs travaillent : téléphones de bureau et Jabber avec Cisco IM and Presence, ou l'application Webex. La variante en dépend.
• Vous avez accès à Microsoft Entra pour créer un enregistrement d'application et accorder le consentement administrateur.
• Pour la variante Jabber : un CUCM dont la supervision des appels est configurée dans EasyUC et, pour l'état Jabber, un Cisco IM and Presence avec un service web de présence joignable.

Pas à pas : comment procéder

1. Déterminez la variante à l'aide du tableau Les variantes en un coup d'œil.
2. Lisez les tableaux d'états et clarifiez avec le service métier quels sens sont nécessaires. Souvent, CUCM-Anrufstatus → Teams (état d'appel du CUCM) suffit.
3. À l'aide du tableau Interfaces et autorisations, vérifiez quels comptes et quelles validations vous devez préparer.
4. Lisez la section Limites afin que les attentes concernant « Do not disturb » et « Presenting » soient justes.
5. Configurez ensuite Presence Sync avec la liste de contrôle de bout en bout.

Champs et options : les variantes en un coup d'œil

Tableau d'états : Cisco → Teams

Tableau d'états : Teams → Cisco Jabber

Déroulement d'une exécution de synchronisation

1. Toutes les 5 secondes, le service de présence vérifie pour quels profils l'intervalle configuré est écoulé. Un verrou dans la base de données empêche deux exécutions de publier en même temps pour le même profil.
2. Il charge l'association des utilisateurs du profil. Les correspondances ambiguës sont exclues et comptent comme conflits.
3. Il lit les sources des sens activés : appels établis de la connexion CUCM, état Jabber depuis le service web de présence, état Teams depuis Microsoft Graph.
4. Pour chaque utilisateur, il compare l'état lu avec le dernier état observé. Seul un changement crée une entrée dans Presence Live. Les interrogations sans changement n'écrivent rien.
5. Il détermine l'état cible selon les tableaux d'états. Les états qui ne peuvent pas être transférés sont consignés comme ignorés avec un motif.
6. Il publie les nouveaux états, renouvelle les états existants avant leur expiration et supprime les états dont la source a pris fin.
7. Il enregistre l'état, le message et l'heure de l'exécution sur le profil. L'interface affiche ces valeurs sous Last check.
8. Si la synchronisation est désactivée ou si le module est arrêté, le service supprime uniquement les états définis par EasyUC. Les paramètres du profil sont conservés.

Flux de données et emplacements de stockage

Interfaces et autorisations

Limites

• « Do not disturb » n'est transféré dans aucun des deux sens. Les deux éditeurs traitent cet état comme une décision personnelle de l'utilisateur, qu'EasyUC n'écrase pas.
• « Presenting » ne peut pas être déduit de façon fiable de l'état Jabber et n'est pas transféré.
• Depuis Jabber, seuls « Available » et « Away » parviennent à Teams. Un état d'appel provient exclusivement de la supervision des appels du CUCM.
• Les lignes CUCM partagées (shared lines) ne sont pas attribuées à un utilisateur unique et ne définissent aucun état d'appel.
• Un seul profil de présence peut publier par application Entra. Un seul profil peut écrire dans Jabber par utilisateur d'application dans IM and Presence.
• La synchronisation interroge les éditeurs de façon cyclique. Les états qui durent moins longtemps que l'intervalle peuvent passer inaperçus.
• En mode Webex, Beobachtet (observé) signifie qu'EasyUC a lu un état source. Cela ne confirme pas un transfert individuel par Cisco.
• La façon dont Jabber affiche un état défini de l'extérieur et le fusionne avec ses propres sources dépend de la version d'IM and Presence et de Jabber. Vérifiez ce point avec vos versions lors de la recette.

Vérifier le résultat et circonscrire les erreurs

• Vous avez compris la fonction lorsque vous pouvez prédire, pour un utilisateur de test, ce que Teams affiche pendant un appel sur le téléphone Cisco et ce qui n'est pas transféré.
• Si l'attente ne correspond pas au comportement, ouvrez Presence Live et lisez l'entrée de l'utilisateur. Le résultat et le motif indiquent ce qu'EasyUC a fait ou omis.
• Si un utilisateur n'apparaît pas du tout dans le journal, il n'est pas associé de façon unique. Vérifiez l'association dans le profil avec Zuordnung prüfen (vérifier l'association).
• Les différents messages, avec leur signification et leur remède, figurent dans le chapitre sur les cas d'erreur.