Vue d’ensemble des journaux des appels Azure Communication Services

Azure Communication Services propose des fonctionnalités de journalisation que vous pouvez utiliser pour surveiller et déboguer votre solution Communication Services. Configurez ces fonctionnalités dans le Portail Azure.

Le contenu de cet article fait référence aux journaux activés par le biais d’Azure Monitor (voir aussi le FAQ). Pour activer ces journaux pour Communication Services, consultez Activer la journalisation dans les paramètres de diagnostic.

Important

Vous devez collecter les journaux si vous souhaitez les analyser. Pour plus d’informations, veuillez consulter la rubrique Comment stocker les journaux ?

Azure ne stocke pas les données de vos journaux d’appels, sauf si vous activez ces paramètres de diagnostic spécifiques. Vos données d’appels ne sont pas disponibles rétroactivement. Vous accumulez des données une fois les paramètres de diagnostics créés.

Comment utiliser les journaux des appels

Nous vous recommandons de collecter tous les journaux des appels disponibles dans une ressource d’analytique des journaux d’activité afin de pouvoir surveiller votre utilisation des appels et d’améliorer la qualité des appels, et pour pouvoir recevoir de nouveaux journaux d’Azure Communication Services dès que nous les publions.

Vous pouvez utiliser deux outils principaux pour surveiller vos appels et améliorer leur qualité.

• Tableau de bord des insights vocaux et vidéo
• Diagnostics d’appels

Nous vous recommandons d’utiliser les tableaux de bord des insights vocaux et vidéo pour démarrer des investigations de qualité et d’utiliser les diagnostics d’appels si nécessaire pour explorer des appels individuels quand vous avez besoin de détails précis.

Journaux disponibles

Azure Communication Services crée huit journaux des appels :

Journaux de mises à jour de la synthèse de l’appel :

Ces données de journal arrivent dans Azure Monitor plus rapidement que les journaux de synthèse de l’appel. Nous vous recommandons d’utiliser ces journaux au lieu du schéma du journal de synthèse de l’appel. Ce journal contient des informations de base sur l’appel, notamment toutes les informations pertinentes sur les ID, les horodatages, les points de terminaison et le Kit de développement logiciel (SDK).

Pour plus d’informations, veuillez consulter la rubrique Schéma du journal des mises à jour de la synthèse de l’appel

Journaux de synthèse de l’appel :

Ce journal est un sous-ensemble du schéma du journal des mises à jour de la synthèse de l’appel. Il contient des informations de base sur l’appel, notamment toutes les informations pertinentes sur les ID, les horodatages, les points de terminaison et le Kit de développement logiciel (SDK). Pour accélérer la latence des journaux, utilisez plutôt les journaux des mises à jour de la synthèse de l’appel.

Pour plus d’informations, veuillez consulter la rubrique Schéma du journal de synthèse de l’appel

Journaux de mises à jour des diagnostics d’appel :

Ces données de journal arrivent dans Azure Monitor plus rapidement que les journaux de diagnostics des appels. Nous vous recommandons d’utiliser ces journaux au lieu du schéma du journal de diagnostics des appels. Ce journal contient des informations sur le flux du média d’appel d’un participant, ainsi qu’un ensemble de métriques qui indiquent la qualité des mesures de l’expérience.

Pour plus d’informations, veuillez consulter la rubrique Schéma du journal des mises à jour de diagnostics des appels

Journaux de diagnostics des appels :

Ce journal est un sous-ensemble du schéma du journal des mises à jour de diagnostics des appels. Il contient des informations sur le flux, ainsi qu’un ensemble de métriques qui indiquent la qualité des mesures de l’expérience. Pour accélérer la latence des journaux, utilisez plutôt les journaux des mises à jour de la synthèse de l’appel.

Pour plus d’informations, veuillez consulter la rubrique Schéma du journal de diagnostics des appels

Journaux des opérations du client d’appel :

Contiennent des événements détaillés du client d’appel. Ces événements de journal sont générés pour chaque EndpointId dans un appel et le nombre de journaux d’événements générés dépend des opérations effectuées par le participant pendant l’appel.

Pour en savoir plus, veuillez consulter la rubrique Schéma du journal des opérations du client d’appel

Journaux des statistiques des médias clients d’appels :

Contiennent des valeurs détaillées de flux multimédia. Ces journaux sont générés pour chaque flux multimédia dans un appel. Pour chaque EndpointId dans un appel (y compris le serveur), Azure Communication Services crée un journal de diagnostic d’appel distinct pour chaque flux multimédia (audio ou vidéo, par exemple) entre les points de terminaison. Le volume de données générées dans chaque journal dépend de la durée de l’appel et du nombre de flux multimédias dans l’appel.

Dans un appel P2P, chaque journal contient des données relatives à chacun des flux sortants associés à chaque point de terminaison. Dans un appel de groupe, chaque flux associé à endpointType = "Server" crée un journal qui contient des données pour les flux entrants. Tous les autres flux créent des journaux qui contiennent des données pour les flux sortants pour tous les points de terminaison non serveur. Dans les appels de groupe, utilisez la valeur participantId comme clé pour joindre les journaux entrants/sortants associés dans une connexion de participant distincte.

Pour en savoir plus, veuillez consulter la rubrique Schéma du journal des séries chronologiques des statistiques des médias clients d’appels

Journaux d’enquête de fin d’appel :

Ces journaux sont renseignés lorsque le client d’appel web envoie une enquête à la fin de l’appel. Vous pouvez utiliser ces journaux pour découvrir la perception subjective de votre qualité d’appel par vos utilisateurs.

Pour en savoir plus, veuillez consulter la rubrique Vue d’ensemble de l’enquête de fin d’appel

Journaux des métriques d’appel :

Ces journaux contiennent des métriques d’appel agrégées dans des emplacements quotidiens en fonction d’attributs tels que la version du Kit de développement logiciel (SDK), le nom du système d’exploitation et le sous-code d’erreur. Ces journaux d’activité sont utilisés dans le tableau de bord des insights vocaux et vidéo pour visualiser des graphiques à long terme de fiabilité, de qualité et de performances en fonction du nombre d’appels réussis et ayant échoué d’API du Kit de développement logiciel (SDK) appelant, appels de diverses opérations.

Pour plus d’informations, veuillez consulter la rubrique Schéma du journal de métriques des appels

Concepts de données

Les descriptions de haut niveau suivantes des concepts de données sont spécifiques aux appels vocaux et vidéo. Ces concepts sont importants à connaître, car ils vous permettent de comprendre la signification des données capturées dans les journaux.

Entités et ID

Familiarisez-vous avec les termes suivants :

• Appel : tel qu’il apparaît dans les données, un appel est une abstraction représentée par correlationId. Les valeurs de correlationId sont uniques pour chaque appel et limitées dans le temps en fonction de callStartTime et callDuration.

• Participant : représente la connexion entre un point de terminaison et le serveur. Les participants (participantId) sont présents uniquement lorsque l’appel est un appel de groupe.

• Point de terminaison : entité la plus unique, représentée par endpointId. Chaque appel est un événement qui contient des données de deux points de terminaison ou plus. Les points de terminaison représentent les participants dans l’appel.

  EndpointType vous indique si le point de terminaison représente un utilisateur humain (RTC ou VoIP), un bot ou le serveur qui gère plusieurs participants dans un appel. Lorsqu’une valeur endpointType est "Server", aucun ID unique n’est affecté au point de terminaison. Vous pouvez analyser endpointType et le nombre de valeurs endpointId pour déterminer le nombre d’utilisateurs et d’autres participants non humains (bots et serveurs) qui rejoignent un appel.

  Les kits SDK natifs pour Android et iOS réutilisent la même valeur endpointId pour un utilisateur sur plusieurs appels afin de vous permettre de comprendre les expériences entre les sessions. Ce processus diffère des points de terminaison web, qui génèrent toujours une nouvelle valeur endpointId pour chaque nouvel appel.

• Flux : entité la plus granulaire. Il existe un flux pour chaque direction (entrante ou sortante) et une valeur mediaType (par exemple, Audio ou Video).

Appels P2P ou appels de groupe

Remarque

Dans cet article, les appels P2P et de groupe sont par défaut dans le même tenant. Tous les scénarios d’appel qui sont entre tenants sont spécifiés en conséquence dans l’article.

Il existe deux types d’appels tels que représentés par callType :

• Appel P2P (Peer to Peer) : connexion entre seulement deux points de terminaison, sans point de terminaison de serveur. Les appels P2P sont initiés en tant qu’appel entre ces points de terminaison et ne sont pas créés en tant qu’événement d’appel de groupe avant la connexion.

  

• Appel de groupe : tout appel avec plus de deux points de terminaison connectés. Les appels de groupe comprennent un point de terminaison de serveur et la connexion entre chaque point de terminaison et le serveur. Les appels P2P qui ajoutent un autre point de terminaison pendant l’appel cessent d’être P2P pour devenir un appel de groupe. Vous pouvez déterminer la chronologie où chaque point de terminaison a rejoint l’appel en utilisant les métriques participantStartTime et participantDuration.

  

Exemples de plusieurs types d’appels

Remarque

Dans cet article, les appels P2P et de groupe sont par défaut dans le même tenant. Tous les scénarios d’appel qui sont entre tenants sont spécifiés en conséquence dans l’article.

Exemple : Appel P2P

Le diagramme suivant représente deux points de terminaison connectés directement dans un appel P2P. Dans cet exemple, Communication Services crée deux journaux de récapitulatif de l’appel (un pour chaque valeur participantID) et quatre journaux de diagnostics d’appels (un pour chaque flux multimédia).

Pour les participants du client d’appel Azure Communication Services, il y a également une série de journaux d’opérations du client d’appel et de journaux des séries chronologiques des statistiques multimédias du client d’appel. Le nombre exact de ces journaux dépend du type d’opérations du SDK qui sont appelées et de la durée d’appel.

Exemple : Appel de groupe

Le diagramme suivant représente un exemple d’appel de groupe avec trois valeurs participantId (ce qui signifie trois participants) et un point de terminaison de serveur. Plusieurs valeurs pour endpointId peuvent potentiellement apparaître dans plusieurs participants, par exemple lorsqu’ils rejoignent un appel à partir du même appareil. Communication Services crée un journal de résumé d’appel pour chaque valeur participantId. Il crée quatre journaux de diagnostics d’appels : un pour chaque flux multimédia par participantId.

Pour les participants du client d’appel Azure Communication Services, les journaux des opérations du client d’appel sont identiques aux appels P2P. Pour chaque participant utilisant le SDK Calling, il existe une série de journaux des opérations du client d’appel.

Pour les participants du client d’appel Azure Communication Services, les journaux des opérations du client d’appel et les journaux des séries chronologiques des statistiques multimédias du client d’appel sont identiques aux appels P2P. Pour chaque participant utilisant le SDK Calling, il existe une série de journaux des opérations du client d’appel et des journaux des séries chronologiques des statistiques multimédias du client d’appel.

Exemple : Appel P2P inter-locataires

Le diagramme suivant représente deux participants sur plusieurs locataires qui sont connectés directement dans un appel P2P. Dans cet exemple, Communication Services crée un journal de résumé d’appel (un pour chaque participant) avec les versions du système d’exploitation et du SDK supprimées. Communication Services crée aussi quatre journaux de diagnostics d’appels (un pour chaque flux multimédia). Chaque journal contient des données relatives au flux sortant de participantID.

Exemple : Appel de groupe inter-locataires

Le diagramme suivant représente un exemple d’appel de groupe avec trois valeurs participantId sur plusieurs locataires. Communication Services crée un journal de résumé d’appel pour chaque participant avec les versions du système d’exploitation et du SDK supprimées. Communication Services crée aussi quatre journaux de diagnostics d’appels relatifs à chaque valeur participantId (un pour chaque flux multimédia).

Remarque

Cette version prend uniquement en charge les journaux de diagnostics de trafic sortant. Les versions du système d’exploitation et du SDK associées au bot et au participant peuvent être supprimées, car Communication Services traite les identités des participants et des bots de la même façon.

Forum aux questions

Comment stocker les journaux ?

La section suivante décrit cette exigence.

Les journaux Azure Communication Services ne sont pas stockés dans votre compte Azure par défaut. Vous devez donc commencer à les stocker pour que les outils comme le tableau de bord des insights vocaux et vidéo et les diagnostics d’appels fonctionnent. Pour collecter les journaux des appels, vous devez activer un paramètre de diagnostic qui dirige les données d’appel vers un espace de travail Log Analytics.

Les données ne sont pas stockées rétroactivement, par conséquent vous commencez à capturer les journaux des appels uniquement après avoir configuré le paramètre de diagnostic.

Pour ajouter des paramètres de diagnostic à votre ressource, suivez les instructions de Activer les journaux via des paramètres de diagnostic dans Azure Monitor. Nous vous recommandons de collecter tous les journaux initialement. Une fois que vous avez compris les fonctionnalités d’Azure Monitor, déterminez les journaux que vous voulez conserver et pendant combien de temps. Quand vous ajoutez votre paramètre de diagnostic, vous êtes invité à sélectionner des journaux. Pour collecter tous les journaux, sélectionnez allLogs.

Le volume de vos données, leur conservation et leur utilisation dans Log Analytics au sein d’Azure Monitor sont facturés via les compteurs de données Azure existants. Nous vous recommandons d’analyser vos stratégies d’utilisation et de conservation des données pour des considérations de coût si nécessaire. Pour plus d’informations, consultez Contrôler les coûts.

Si vous avez plusieurs ID de ressource Azure Communications Services, vous devez activer ces paramètres pour chaque ID de ressource.

Étapes suivantes

• Découvrez les bonnes pratiques pour gérer la qualité et la fiabilité de vos appels dans : Améliorer et gérer la qualité des appels

• Découvrez le tableau de bord des insights pour surveiller les journaux d’appels vocaux et d’appels vidéo.

• Découvrez comment utiliser les journaux d’appel pour diagnostiquer les problèmes de qualité et de fiabilité des appels avec Diagnostics d’appel dans : Diagnostics d’appel