Partager via

Schéma des journaux de diagnostic d’appel

  • Article

Les journaux de diagnostic d’appel fournissent des informations importantes sur les points de terminaison et les transferts de média 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 diagnostic 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 diagnostic 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 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 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.

Définitions des données

Schéma des journaux de diagnostic 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. Cela est mesuré 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.

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 diagnostic des appels

Les journaux de diagnostic d’appel partagent des informations sur les opérations :

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

Voici un journal de diagnostic pour un flux audio du point de terminaison VoIP 1 vers 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"
}

Voici un journal de diagnostic pour un flux audio du point de terminaison VoIP 2 vers 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"
}

Voici un journal de diagnostic pour un flux vidéo du point de terminaison VoIP 1 vers 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"
}

Appel de groupe

Les données pour un appel de groupe sont générées dans trois journaux de résumé d’appel et six journaux de diagnostic 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 diagnostic des appels

Les journaux de diagnostic d’appel partagent des informations sur les opérations :

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

Voici un journal de diagnostic pour un flux audio du point de terminaison VoIP 1 vers un point de terminaison de 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"
}

Voici un journal de diagnostic pour un flux audio d’un point de terminaison de serveur vers un 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"
}

Voici un journal de diagnostic pour un flux audio du point de terminaison VoIP 3 vers un point de terminaison de 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"
}

Voici un journal de diagnostic pour un flux audio d’un point de terminaison de serveur vers un 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",

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