Fonctionnement du serveur de conversation permanente dans Lync Server 2013

 

Rubrique Dernière modification : 2012-11-21

Lync Server 2013, Persistent Chat Server vous permet de participer à des conversations multipartes basées sur des sujets qui persistent au fil du temps. Le serveur de conversation permanente peut aider votre organisation à effectuer les opérations suivantes :

  • Améliorer la communication entre les équipes géographiquement dispersées et interfonctionnels

  • Élargir la sensibilisation et la participation à l’information

  • Améliorer la communication avec votre organisation étendue

  • Réduire la surcharge d’informations

  • Améliorer la sensibilisation aux informations

  • Augmenter la dispersion des connaissances et des informations importantes

Vous pouvez déployer le serveur de conversation permanente en tant que rôle facultatif avec Lync Server 2013. Les services de conversation permanente s’exécutent sur un pool dédié, et un pool de serveurs de conversation permanente dépend d’un pool de serveurs Lync pour router les messages vers celui-ci. Les clients utilisent la communication de conversation eXtensible via SIP (XCCOS). Les serveurs frontaux Lync Server sont configurés pour acheminer le trafic vers un pool de serveurs de conversation permanente.

architecture High-Level

Les diagrammes suivants fournissent des perspectives générales de l’architecture et des services du serveur de conversation permanente.

Architecture de haut niveau du serveur de conversation permanente

Architecture du serveur de conversation permanente.

Services de haut niveau du serveur de conversation permanente

Composants du serveur de conversation permanente.

Deux services s’exécutent sur les serveurs frontaux du serveur de conversation permanente :

  • Conversation permanente (canal)

  • Conformité

Service de conversation permanente (canal)

Le service de conversation permanente (canal) est le service principal responsable du serveur de conversation permanente. Ce service fournit les fonctions suivantes :

  • acceptation des messages entrants ;

  • inscription et listage des participants en ligne dans une salle de conversation permanente ;

  • retransmission des messages vers les abonnés à d’autres canaux ;

  • Implémente une logique pour la gestion des canaux, l’invitation de salle de conversation, la recherche et les nouvelles notifications de contenu

Le service de conversation permanente (canal) stocke et accède au contenu de la salle de conversation et à d’autres métadonnées système (règles d’autorisation, et ainsi de suite) à l’aide du magasin de conversation permanente. Ce service stocke les fichiers qui sont chargés dans les salles de conversation dans le magasin de fichiers de conversation permanente.

Service de conformité

Le service conformité est un composant facultatif du serveur de conversation permanente et est responsable de l’archivage du contenu et des événements de conversation dans le magasin de conformité des conversations permanentes. Si le règlement de votre organisation impose un archivage de l’activité de conversation permanente, vous pouvez déployer le service de conformité de conversation permanente facultatif. Le service conformité est installé sur chaque serveur de conversation permanente dans un pool de conversations permanentes. Lorsqu’elle est configurée, la conformité du serveur de conversation permanente enregistre l’activité des utilisateurs, comme la jonction et le départ des salles, ainsi que la publication et la lecture des messages. Le service conformité stocke les fichiers qui doivent être archivés dans le magasin de fichiers de conformité de conversation permanente.

Services web de conversation permanente

Sur les serveurs frontaux Lync Server, deux services s’exécutent qui dépendent d’Internet Information Services (IIS) et sont implémentés en tant que composants web :

  • Services web de conversation permanente pour le chargement/téléchargement de fichiers Responsable de la publication et de la récupération de fichiers à partir de salles de conversation.

  • Services web de conversation permanente pour la gestion des salles de conversation Chargé de fournir aux utilisateurs la possibilité de gérer leurs salles de conversation et de créer de nouvelles salles de conversation.

Comment utiliser le serveur de conversation permanente ?

Le serveur de conversation permanente est un rôle de serveur facultatif au sein de l’infrastructure Lync Server 2013. Si vous installez le rôle Serveur de conversation permanente, tous les utilisateurs qui ont été activés par le biais d’une stratégie par un administrateur peuvent utiliser la conversation permanente avec le client Lync 2013.

Pour plus d’informations sur le déploiement d’un serveur de conversation permanente et pour permettre aux utilisateurs d’exploiter les fonctionnalités par stratégie, consultez Déploiement d’un serveur de conversation permanente dans Lync Server 2013.

Pour plus d’informations sur la configuration des paramètres de votre déploiement de serveur de conversation permanente, consultez Déploiement d’un serveur de conversation permanente dans Lync Server 2013 et Gestion de Lync Server 2013, serveur de conversation permanente.

Pour plus d’informations sur la façon d’activer les utilisateurs par stratégie afin qu’ils puissent tirer parti des fonctionnalités de conversation permanente dans le client Lync 2013, consultez Déploiement d’un serveur de conversation permanente dans Lync Server 2013 et Gestion de Lync Server 2013, serveur de conversation permanente.

Si vous avez déployé la conformité de conversation permanente, consultez Gestion de Lync Server 2013, serveur de conversation permanente pour plus d’informations sur la configuration des paramètres de conformité.

Flux d’appels de conversation permanente

Le client de conversation permanente communique avec le service de conversation permanente à l’aide de XCCOS. Les séquences suivantes décrivent le processus de connexion et un scénario classique d’abonnement à la salle et de publication de messages.

Connexion

Le diagramme de flux d’appels suivant et les étapes décrivent le processus de connexion.

Flux d’appel de connexion du client de conversation permanente

Diagramme du flux d’appels du serveur de conversation permanente.

  1. Le client de conversation permanente envoie d’abord un ABONNEMENT SIP pour récupérer le document d’approvisionnement dans la bande à partir du serveur. Ce document indique si la conversation permanente est activée ou désactivée pour l’utilisateur et la liste des URI SIP pour le pool de serveurs de conversation permanente.

  2. Le client de conversation permanente envoie un message SIP INVITE à l’URI SIP du serveur de conversation permanente qu’il a obtenu à l’étape précédente. La séquence INVITE est suivie de 200 OK et ACK, et le client de conversation permanente a maintenant ouvert une session SIP avec un point de terminaison de serveur de conversation permanente. Par conséquent, le client de conversation permanente communique avec le serveur de conversation permanente en envoyant des messages SIP INFO qui contiennent des messages de conversation ou des commandes demandant au serveur d’effectuer une action. Tous ces messages sont reconnus avec un service 200 OK ou 503 indisponible (c’est-à-dire en cas de charge importante du serveur). Si le client reçoit une réponse 503, il réessaye le message. (Cet exemple n’inclut pas de réponse 503.) Si le serveur accepte le message ou la commande et envoie 200 OK, il fournit une réponse au client sous la forme d’un message INFO SIP distinct. Cette réponse inclut une référence à la commande d’origine.

  3. Le client de conversation permanente envoie un message SIP INFO qui contient la commande XCCOS getserverinfo . Le serveur de conversation permanente répond avec un nouveau message SIP INFO qui contient des informations sur la configuration du service de conversation permanente.

  4. Le client de conversation permanente envoie un message SIP INFO qui contient la commande getassociations XCCOS. Le serveur de conversation permanente répond par un nouveau message SIP INFO qui contient la liste des salles dont l’utilisateur est membre. Le client de conversation permanente répète la commande pour récupérer la liste des salles dont l’utilisateur est un responsable.

  5. Le client de conversation permanente obtient la liste des salles suivies à partir du document de « présence », où chaque salle suivie est représentée par une catégorie « roomSetting ». Toutes les salles suivies sont jointes par un seul message SIP INFO qui contient la commande Bjoin XCCOS qui contient la liste des URI de salle. Étant donné que la liste des salles suivies est conservée sur le serveur, tout client sur n’importe quel ordinateur a la même liste de salles suivies pour l’URI utilisateur spécifié. Le client de conversation permanente conserve également la liste des salles ouvertes (si cette option est activée par l’utilisateur) dans le registre d’ordinateurs local et joint chacune de ces salles lors de la connexion en envoyant un message SIP INFO qui contient la commande de jointure XCCOS pour chaque salle ouverte. Étant donné que cette liste est conservée dans le Registre, elle peut être différente sur deux clients de conversation permanente s’exécutant sur des ordinateurs différents.

  6. Pour chaque salle jointe, le client conversation permanente envoie un message SIP INFO qui contient la commande bccontext XCCOS. Le serveur de conversation permanente répond avec un nouveau message INFO SIP qui contient le message de conversation le plus récent dans la salle.

  7. Le client de conversation permanente envoie un message SIP INFO qui contient une commande getinv XCCOS (autrement dit, obtenir une invitation) pour demander toutes les nouvelles invitations de salle que le client n’a pas encore vues. Dans un message INFO SIP distinct, le serveur de conversation permanente retourne une liste de ces salles.

S’abonner à une salle et publier un message

Le diagramme de flux d’appels et les étapes suivants décrivent un scénario classique d’abonnement à la salle et de publication de messages.

Abonnement à la salle de conversation permanente et flux d’appel de publication de messages

Scénario d’abonnement à la salle et de publication de messages.

  1. À partir du client de conversation permanente, User1 clique sur Rejoindre une salle de conversation, clique sur Rechercher, puis entre certains critères de recherche. Le client de conversation permanente envoie un message INFO SIP qui contient la commande chansrch XCCOS (recherche dans la salle), ainsi que les critères de recherche. Le serveur de conversation permanente interroge la base de données principale et répond dans un nouveau message SIP INFO qui contient une liste des salles disponibles qui répondent aux critères de recherche.

  2. User1 sélectionne la salle de conversation qu’il souhaite rejoindre, puis clique sur Suivre cette salle. Le client de conversation permanente envoie au serveur de conversation permanente un message SIP INFO qui contient la commande de jointure XCCOS et l’ID de salle de conversation sélectionné par l’utilisateur. Le serveur de conversation permanente répond avec un message SIP INFO qui contient les données d’approvisionnement.

  3. Le client de conversation permanente envoie au serveur de conversation permanente un message SIP INFO qui contient la commande bccontext XCCOS (contexte de conversation inverse). Le serveur de conversation permanente récupère l’historique des conversations et le retourne au client de conversation permanente dans un message INFO SIP distinct. À ce stade, l’utilisateur entre dans la salle de conversation et est prêt à participer.

  4. User1 entre un nouveau message, puis clique sur Envoyer. Le client de conversation permanente publie le message dans la salle de conversation dans une commande SIP INFO XCCOS grpchat . Le serveur de conversation permanente stocke une copie de ce nouveau message dans la base de données principale de conversation permanente.

  5. Le serveur de conversation permanente envoie une copie distincte du message grpchat SIP INFO XCCOS à User2, qui est déjà entré dans la salle de conversation.

Flux d’appels de conformité de conversation permanente

Le serveur de conversation permanente utilise Message Queuing (également appelé MSMQ) et une base de données de conformité supplémentaire (mgccomp) pour traiter les données de conformité. Comme exemple de traitement des événements de conformité, la séquence d’événements suivante décrit comment un événement de publication de message est traité.

  1. Un utilisateur publie un message dans une salle.

  2. Le serveur de conversation permanente place les informations relatives à l’événement dans une file d’attente Message Queuing privée.

  3. Le serveur de conformité de conversation permanente lit cet événement à partir de la file d’attente et le place dans la base de données mgccomp pour traitement ultérieurement.

  4. Régulièrement, le serveur de conformité de conversation permanente traite un ensemble d’événements dans la base de données et les envoie à l’adaptateur de conformité de conversation permanente pour traitement.

  5. Si l’adaptateur traite correctement les données, le serveur de conformité de conversation permanente supprime les événements de la base de données mgccomp.