Partager via

Schéma du journal de mise à jour des diagnostics d’appel

  • Article

La seule différence entre les propriétés du schéma du journal de mise à jour des diagnostics d’appel et le schéma du journal de diagnostic d’appel est la propriété CallUpdatesVersion supplémentaire. La propriété CallUpdatesVersion indique l’ancienneté du journal. Le schéma du journal de mise à jour des diagnostics d’appel a une latence inférieure à celle du schéma du journal de diagnostic d’appel, il obtient cette faible latence en envoyant les propriétés du schéma dès que possible. En revanche, le schéma du journal de diagnostic d’appel ne vous envoie pas de schéma de journal tant que le schéma de journal n’a pas entièrement été créé en interne par Microsoft.

Les journaux de mise à jour des diagnostics d’appel fournissent des informations importantes sur les points de terminaison et les transferts multimédias pour chaque participant. Ils fournissent également des mesures qui vous aident à comprendre les problèmes qualité.

Pour chaque EndpointId dans un appel (y compris le serveur), Azure Communication Services crée un journal de mise à jour des diagnostics d’appel distinct pour chaque flux multimédia (audio ou vidéo, par exemple) entre les points de terminaison. Dans un appel P2P, chaque journal contient des données relatives à chacun des flux sortants associés à chaque point de terminaison. Dans les appels de groupe, participantId sert d’identificateur clé pour joindre les journaux de flux sortants associés dans une connexion de participant distincte. Les journaux de mise à jour des diagnostics d’appel restent intacts et sont identiques, quel que soit le locataire du participant.

Comment utiliser les journaux d’appels

Nous vous recommandons de collecter tous les journaux d’appels disponibles dans une ressource Log Analytics afin de pouvoir monitorer 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 qu’ils sont publiés.

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

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

Concepts de données

Important

Vous devez collecter les journaux si vous souhaitez les analyser. Pour plus d’informations, consultez 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’appel ne sont pas disponibles rétroactivement. Vous accumulez des données une fois les paramètres de diagnostic créés.

Quand vous utilisez le schéma de journal de mise à jour des diagnostics d’appel, consultez toujours le numéro CallUpdatesVersion le plus élevé pour vérifier que vous avez les informations les plus récentes. Chaque fois que les données d’appel sont mises à jour, une nouvelle version du journal est créée avec les informations les plus récentes. Par exemple, plus le nombre CallUpdatesVersion est élevé, plus la mise à jour est récente. Cela signifie que la version 3 est plus récente et inclut des changements plus récents par rapport à la version 1.

En savoir plus sur les versions de journal et la latence des données

Une fois l’appel terminé, une version initiale (version 1) du journal est envoyée aux tables CallSummaryUpdates et CallDiagnosticUpdates. Les versions initiales peuvent contenir des valeurs null, si d’autres informations sont disponibles, des versions mises à jour des journaux sont créées avec des informations plus complètes. Par exemple, les données client peuvent être retardées en raison de problèmes de connectivité réseau entre l’ordinateur client et nos serveurs, ou, plus simplement, parce qu’un utilisateur a fermé son ordinateur portable après l’appel et avant que ses données client n’aient été envoyées, et qu’il l’a rouvert des heures (ou des jours) plus tard.

En raison de ces variations de collecte, vous pouvez voir arriver les versions incrémentielles des heures ou des jours plus tard. Vous pouvez utiliser des versions pour comprendre plus vite votre ressource d’appel, au lieu d’attendre que toutes les données client du SDK appelant soit reçues. Le meilleur scénario est quand tous les participants terminent leurs appels et que le SDK appelant peut envoyer les données au serveur.

Définitions des données

Schéma du journal de mise à jour des diagnostics d’appel

Ce tableau décrit chaque propriété.

Propriété Description
operationName Opération associée à l’enregistrement de journal.
operationVersion Valeur api-version associée à l’opération, si l’opération operationName a été effectuée via une API. Si aucune API ne correspond à cette opération, la version représente la version de l’opération si les propriétés associées à l’opération viennent à changer.
category Catégorie de journal de l’événement. Cette propriété est la précision avec laquelle vous pouvez activer ou désactiver les journaux sur une ressource. Les propriétés qui apparaissent dans le blob properties d’un événement sont les mêmes au sein d’une catégorie de journal et d’un type de ressource.
correlationId ID unique pour un appel. Il identifie les événements corrélés de tous les participants et points de terminaison qui se connectent pendant un appel. Si vous devez ouvrir un dossier de support auprès de Microsoft, vous pouvez utiliser la valeur correlationId pour identifier facilement l’appel que vous dépannez.
participantId ID généré pour représenter la connexion bidirectionnelle entre un point de terminaison "Participant" (endpointType = "Server") et le serveur. Quand callType = "P2P", il y a une connexion directe entre les deux points de terminaison et aucune valeur participantId n’est générée.
identifier L’ID unique de l’utilisateur. L’identité peut être un utilisateur Azure Communication Services, un identifiant utilisateur Microsoft Entra, un identifiant d’objet Teams ou un identifiant de bot Teams. Vous pouvez utiliser cet identifiant pour mettre en corrélation les événements utilisateur dans les journaux.
endpointId ID unique qui représente chaque point de terminaison connecté à l’appel, où endpointType définit le type de point de terminaison. Lorsque la valeur est null, l’entité connectée est le serveur Communication Services. EndpointId peut être conservé pour le même utilisateur sur plusieurs appels (correlationId) pour les clients natifs, mais il est unique pour chaque appel lorsque le client est un navigateur web.
endpointType Valeur qui décrit les propriétés de chaque instance endpointId. Elle peut contenir "Server", "VOIP", "PSTN", "BOT", "Voicemail", "Anonymous" ou "Unknown".
mediaType Valeur de chaîne qui décrit le type d’élément multimédia transmis entre les points de terminaison au sein de chaque flux. Les valeurs possibles sont "Audio", "Video", "VBSS" (partage d'écran) et "AppSharing" (canal de données).
streamId Entier non unique qui, avec mediaType, peut être utilisé pour identifier de manière unique les flux de la même valeur participantId.
transportType Valeur de chaîne qui décrit le protocole de transport réseau pour chaque valeur participantId. Elle peut contenir "UDP", "TCP" ou "Unrecognized". "Unrecognized" indique que le système n’a pas pu déterminer si le type de transport était TCP ou UDP.
roundTripTimeAvg Durée moyenne nécessaire pour obtenir un paquet IP d’un point de terminaison à un autre dans une période participantDuration. Ce délai de propagation du réseau est lié à la distance physique entre les deux points, à la vitesse de la lumière et à toute charge supplémentaire que les différents routeurs prennent entre les deux.

Le délai de la latence est mesuré en aller simple ou en aller-retour (RTT, round-trip time). Sa valeur est exprimée en millisecondes. Un délai RTT supérieur à 500 ms affecte la qualité des appels.
roundTripTimeMax Délai RTT maximal (en millisecondes) mesuré pour chaque flux multimédia pendant une période participantDuration dans un appel de groupe ou pendant une période callDuration dans un appel P2P.
jitterAvg Variation moyenne du délai entre des paquets successifs. Azure Communication Services peut s’adapter à certains niveaux de gigue par le biais de la mise en mémoire tampon. Lorsque la gigue dépasse la mise en mémoire tampon, c’est-à-dire à un délai jitterAvg supérieur à 30 ms environ, la qualité peut s’en trouver altérée. Les paquets arrivant à des vitesses différentes, la voix du locuteur peut sembler robotique.

Cette métrique est mesurée pour chaque flux multimédia sur la période participantDuration dans un appel de groupe ou sur la période callDuration dans un appel P2P.
jitterMax Valeur maximale de gigue mesurée entre les paquets pour chaque flux multimédia. Des rafales dans les conditions d’un réseau peuvent causer des problèmes dans le flux du trafic audio/vidéo.
packetLossRateAvg Pourcentage moyen de paquets perdus. La perte de paquets affecte directement la qualité audio. La perte de petits paquets individuels n’a presque aucun impact, tandis que les pertes de transmission en rafale consécutives entraînent une coupure audio complète. Les paquets abandonnés qui n’arrivent pas à leur destination prévue provoquent des interruptions dans le flux multimédia. Le résultat se traduit par des syllabes et des mots coupés, et des vidéos et des partages hachés.

Un taux de perte de paquets supérieur à 10 % (0,1) est susceptible d’avoir un impact négatif sur la qualité. Cette métrique est mesurée pour chaque flux multimédia sur la période participantDuration dans un appel de groupe ou sur la période callDuration dans un appel P2P.
packetLossRateMax Cette valeur représente le taux maximum de perte de paquets (pourcentage) pour chaque flux multimédia sur la période participantDuration dans un appel de groupe ou sur la période callDuration dans un appel P2P. Des rafales dans les conditions d’un réseau peuvent causer des problèmes dans le flux du trafic audio/vidéo.
JitterBufferSizeAvg Taille moyenne de la mémoire tampon de la gigue pendant la durée de chaque flux multimédia. La mémoire tampon d’une gigue est une zone de données partagée où les paquets vocaux peuvent être collectés, stockés et envoyés au processeur vocal dans des intervalles uniformément espacés. La mémoire tampon d’une gigue est utilisée pour contrer les effets de la gigue.

Les mémoires tampon de gigue peuvent être statiques ou dynamiques. Les mémoires tampon de gigue statiques sont définies sur une taille fixe, tandis que les mémoires tampon de gigue dynamiques peuvent ajuster leur taille en fonction des conditions réseau. L’objectif de la mémoire tampon d’une gigue est de fournir un flux fluide et ininterrompu de données audio et vidéo à l’utilisateur.

Dans le Kit de développement logiciel (SDK) web, cette valeur JitterBufferSizeAvg est la moyenne du jitterBufferDelay pendant l’appel. La valeur jitterBufferDelay est la durée d’un échantillon audio ou d’une trame vidéo qui reste dans la mémoire tampon de gigue.

Normalement, si la valeur JitterBufferSizeAvg est supérieure à 200 ms, elle a un impact négatif sur la qualité.
JitterBufferSizeMax Taille maximale de la mémoire tampon de la gigue mesurée pendant la durée de chaque flux multimédia.

Normalement, si cette valeur est supérieure à 200 ms, elle a un impact négatif sur la qualité.
HealedDataRatioAvg Pourcentage moyen de paquets de données perdus ou endommagés correctement reconstruits ou récupérés par le mécanisme de réparation (« healer ») pendant la durée du flux audio. Le ratio de données réparées est une mesure de l’efficacité des techniques de correction des erreurs utilisées dans les systèmes VoIP.

Lorsque cette valeur est supérieure à 0,1 (10 %), nous considérons le flux comme de mauvaise qualité.
HealedDataRatioMax Ratio maximal de données réparées mesuré pendant la durée de chaque flux multimédia.

Lorsque cette valeur est supérieure à 0,1 (10 %), nous considérons le flux comme de mauvaise qualité.
VideoFrameRateAvg Nombre moyen d’images vidéo transmises par seconde lors d’un appel vidéo/de partage d’écran. La fréquence d’images vidéo peut avoir un impact sur la qualité et la fluidité du flux vidéo. Les fréquences d’images plus élevées donnent généralement un mouvement plus fluide et plus homogène. La fréquence d’images standard pour les vidéos WebRTC est généralement de 30 images par seconde, même si cette fréquence d’images peut varier en fonction des conditions d’implémentation et de réseau spécifiques.

La qualité du flux est considérée comme médiocre lorsque cette valeur est inférieure à 7 pour le flux vidéo, ou inférieure à 1 pour le flux de partage d’écran.
RecvResolutionHeight Moyenne de la taille verticale du flux vidéo entrant transmis pendant un appel de partage vidéo/de partage d’écran. Elle est mesurée en pixels et constitue l’un des facteurs qui déterminent la résolution globale et la qualité du flux vidéo. La résolution spécifique utilisée peut dépendre des capacités des appareils et des conditions réseau impliquées dans l’appel.

La qualité du flux est considérée comme médiocre lorsque cette valeur est inférieure à 240 pour le flux vidéo, ou inférieure à 768 pour le flux de partage d’écran.
RecvFreezeDurationPerMinuteInMs Durée moyenne d’arrêt sur image en millisecondes par minute pour le flux vidéo/de partage d’écran entrant. Les arrêts sur image sont généralement dus à une mauvaise condition réseau et peuvent dégrader la qualité du flux.

La qualité du flux est considérée comme médiocre lorsque cette valeur est supérieure à 6 000 ms pour le flux vidéo, ou supérieure à 25 000 ms pour le flux de partage d’écran.
PacketUtilization Paquets envoyés ou reçus pour un flux média donné.

En général, plus l’appel est long, plus la valeur est élevée. Si cette valeur est égale à zéro, cela peut indiquer que le média ne circule pas.
VideoBitRateAvg Débit moyen (en bits par seconde) pour un flux vidéo ou de partage d’écran.

Une valeur à débit faible peut indiquer un problème de réseau médiocre. La vitesse de transmission (bande passante) minimale requise est disponible ici : Bande passante réseau.
VideoBitRateMax Débit maximal (en bits par seconde) pour un flux vidéo ou de partage d’écran.

Une valeur à débit faible peut indiquer un problème de réseau médiocre. La vitesse de transmission (bande passante) minimale requise est disponible ici : Bande passante réseau.
StreamDirection La direction du flux multimédia. Il s’agit d’un trafic entrant ou sortant.
CodecName Nom du codec utilisé pour le traitement des flux média. Il peut s’agir d’OPUS, G722, H264S, SATIN, etc.
CallUpdatesVersion Représente la version du journal, les nombres plus élevés indiquant la dernière version publiée.

Exemples de données pour différents types d’appel

Remarque

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

Appel P2P

Voici les champs communs à tous les journaux d’un appel P2P :

"time":                     "2021-07-19T18:46:50.188Z",
"resourceId":               "SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/ACS-TEST-RG/PROVIDERS/MICROSOFT.COMMUNICATION/COMMUNICATIONSERVICES/ACS-PROD-CCTS-TESTS",
"correlationId":            "aaaa0000-bb11-2222-33cc-444444dddddd",

Journaux de mise à jour des diagnostics d’appel

Les journaux de mise à jour des diagnostics d’appel partagent des informations sur les opérations :

"operationName":            "CallDiagnostics",
"operationVersion":         "1.0",
"category":                 "CallDiagnostics",

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison VoIP 1 et le point de terminaison VoIP 2 :

"properties": {
    "identifier":           "acs:61fddbe3-0003-4066-97bc-6aaf143bbb84_0000000b-4fee-66cf-ac00-343a0d003158",
    "participantId":        "null",
    "endpointId":           "570ea078-74e9-4430-9c67-464ba1fa5859",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "1000",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "82",
    "roundTripTimeMax":     "88",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison VoIP 2 et le point de terminaison VoIP 1 :

"properties": {
    "identifier":           "acs:7af14122-9ac7-4b81-80a8-4bf3582b42d0_06f9276d-8efe-4bdd-8c22-ebc5434903f0",
    "participantId":        "null",
    "endpointId":           "a5bd82f9-ac38-4f4a-a0fa-bb3467cdcc64",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "1363841599",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "78",
    "roundTripTimeMax":     "84",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

Voici un journal de mise à jour de diagnostics pour un flux vidéo entre le point de terminaison VoIP 1 et le point de terminaison VoIP 2 :

"properties": {
    "identifier":           "acs:61fddbe3-0003-4066-97bc-6aaf143bbb84_0000000b-4fee-66cf-ac00-343a0d003158",
    "participantId":        "null",
    "endpointId":           "570ea078-74e9-4430-9c67-464ba1fa5859",
    "endpointType":         "VoIP",
    "mediaType":            "Video",
    "streamId":             "2804",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "103",
    "roundTripTimeMax":     "143",
    "jitterAvg":            "0",
    "jitterMax":            "4",
    "packetLossRateAvg":    "3.146336E-05",
    "packetLossRateMax":    "0.001769911"
    "callupdatesversion":   "2"
}

Appel de groupe

Les données d’un appel de groupe sont générées dans trois journaux de synthèse d’appel et six journaux de mise à jour de diagnostics d’appel. Voici les champs communs à tous les journaux de l’appel :

"time":                     "2021-07-05T06:30:06.402Z",
"resourceId":               "SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/ACS-TEST-RG/PROVIDERS/MICROSOFT.COMMUNICATION/COMMUNICATIONSERVICES/ACS-PROD-CCTS-TESTS",
"correlationId":            "bbbb1111-cc22-3333-44dd-555555eeeeee",

Journaux de mise à jour des diagnostics d’appel

Les journaux de mise à jour des diagnostics d’appel partagent des informations sur les opérations :

"operationName":            "CallDiagnostics",
"operationVersion":         "1.0",
"category":                 "CallDiagnostics",

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison VoIP 1 et le point de terminaison d’un serveur :

"properties": {
    "identifier":           "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-729f-ac00-343a0d00d975",
    "participantId":        "04cc26f5-a86d-481c-b9f9-7a40be4d6fba",
    "endpointId":           "5ebd55df-ffff-ffff-89e6-4f3f0453b1a6",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "14884",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "46",
    "roundTripTimeMax":     "48",
    "jitterAvg":            "0",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison d’un serveur et le point de terminaison VoIP 1 :

"properties": {
    "identifier":           null,
    "participantId":        "04cc26f5-a86d-481c-b9f9-7a40be4d6fba",
    "endpointId":           null,
    "endpointType":         "Server",
    "mediaType":            "Audio",
    "streamId":             "2001",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "42",
    "roundTripTimeMax":     "44",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison VoIP 3 et le point de terminaison d’un serveur :

"properties": {
    "identifier":           "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-57c6-ac00-343a0d00d972",
    "participantId":        "1a9cb3d1-7898-4063-b3d2-26c1630ecf03",
    "endpointId":           "5ebd55df-ffff-ffff-ab89-19ff584890b7",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "13783",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "45",
    "roundTripTimeMax":     "46",
    "jitterAvg":            "1",
    "jitterMax":            "2",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

Voici un journal de mise à jour de diagnostics pour un flux audio entre le point de terminaison d’un serveur et le point de terminaison VoIP 3 :

"properties": {
    "identifier":           "null",
    "participantId":        "1a9cb3d1-7898-4063-b3d2-26c1630ecf03",
    "endpointId":           null,
    "endpointType":         "Server"    
    "mediaType":            "Audio",
    "streamId":             "1000",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "45",
    "roundTripTimeMax":     "46",
    "jitterAvg":            "1",
    "jitterMax":            "4",
    "packetLossRateAvg":    "0",
    "callupdatesversion":   "2"
}

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’appel 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