Journaux pour les appels vocaux et vidéo Azure Communication Services
Azure Communication Services offre des fonctionnalités de journalisation que vous pouvez utiliser pour superviser et déboguer votre solution Communication Services. Vous pouvez configurer 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.
Concepts de données
Les descriptions générales suivantes des concepts de données sont spécifiques aux appels vocaux et aux appels 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 decorrelationId
sont uniques pour chaque appel et limitées dans le temps parcallStartTime
etcallDuration
.Participant : Cette entité 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 : Il s’agit de l’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 valeurendpointType
est"Server"
, aucun ID unique n’est affecté au point de terminaison. Vous pouvez analyserendpointType
et le nombre de valeursendpointId
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 valeurendpointId
pour chaque nouvel appel.Flux : Il s’agit de l’entité la plus affinée. Il existe un flux pour chaque direction (entrante ou sortante) et une valeur
mediaType
(par exemple,Audio
ouVideo
).
Définitions des données
Schéma du journal d’utilisation
Propriété | Description |
---|---|
Timestamp |
Horodatage (UTC) de la génération du journal. |
Operation Name |
Opération associée à l’enregistrement de journal. |
Operation Version |
Valeur api-version associée à l’opération, si l’opération Operation Name 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. La catégorie 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. |
Correlation ID |
ID des événements corrélés. Vous pouvez l’utiliser pour identifier les événements corrélés entre plusieurs tables. |
Properties |
Autres données qui sont applicables aux différents modes de Communication Services. |
Record ID |
ID unique d’un enregistrement d’utilisation. |
Usage Type |
Mode d’utilisation (par exemple, Conversation, RTC ou NAT). |
Unit Type |
Type d’unité sur lequel l’utilisation est basée pour un mode d’utilisation (par exemple, minutes, mégaoctets ou messages). |
Quantity |
Nombre d’unités utilisées ou consommées pour cet enregistrement. |
Schéma du journal de résumé d’appel
Le journal de résumé d’appel contient des données vous permettant d’identifier les propriétés clés de tous les appels. Un journal de résumé d’appel différent est créé pour chaque valeur participantId
(endpointId
dans le cas d’appels P2P) de l’appel.
Important
Les informations du participant dans le journal de résumé d’appel varient selon le locataire du participant. La version du SDK et la version du système d’exploitation ne sont pas visibles si le participant n’est pas dans le même locataire (également appelé inter-locataires ou « cross-tenant ») que la ressource Communication Services. Les participants inter-locataires sont classés en tant qu’utilisateurs externes invités par un locataire de ressource à rejoindre l’appel et à collaborer.
Propriété | Description |
---|---|
time |
Horodatage (UTC) de la génération du journal. |
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, et vous pouvez l’utiliser pour joindre les données de différents journaux. 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. |
identifier |
L’ID unique de l’utilisateur. L’identité peut être un utilisateur Azure Communication Services, un identifiant utilisateur Microsoft Entra, un identifiant utilisateur anonyme Teams ou un identifiant de bot Teams. Vous pouvez utiliser cet identifiant pour mettre en corrélation les événements utilisateur dans les journaux. |
callStartTime |
Horodatage pour le début de l’appel, sur la base de la première tentative de connexion à partir de n’importe quel point de terminaison. |
callDuration |
Durée de l’appel, exprimée en secondes. Elle est basée sur la première tentative de connexion et sur la fin de la dernière connexion entre deux points de terminaison. |
callType |
Type de l’appel. Il contient "P2P" ou "Group" . Un appel "P2P" est une connexion 1:1 directe entre seulement deux points de terminaison non-serveur. Un appel "Group" est un appel qui a plus de deux points de terminaison ou qui est créé en tant qu’appel "Group" avant la connexion. |
teamsThreadId |
ID de conversation Teams. Cet ID est pertinent uniquement lorsque l’appel est organisé en tant que réunion Teams. Il représente alors le cas d’usage de l’interopérabilité entre Microsoft Teams et Azure Communication Services. Cet ID est exposé dans les journaux opérationnels. Vous pouvez également vous procurer cet ID via les API de conversation. |
participantId |
ID qui est 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. |
participantStartTime |
Horodatage pour le début de la première tentative de connexion du participant. |
participantDuration |
Durée de chaque connexion de participant, en secondes, du participantStartTime à l’horodatage de la fin de la connexion. |
participantEndReason |
Raison de la fin d’une connexion de participant. Elle contient les codes d’erreur du SDK Calling qu’émet le SDK (le cas échéant) pour chaque valeur participantId . |
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 (endpointType = "Server" ). La valeur endpointId peut parfois persister pour le même utilisateur sur plusieurs appels (correlationId ) pour les clients natifs. Le nombre de valeurs endpointId détermine le nombre de journaux de résumé d’appel. Un journal de résumé distinct est créé pour chaque valeur endpointId . |
endpointType |
Cette valeur décrit les propriétés de chaque point de terminaison connecté à l’appel. Elle peut contenir "Server" , "VOIP" , "PSTN" , "BOT" ou "Unknown" . |
sdkVersion |
Chaîne de version pour la version du SDK Calling Communication Services que chaque point de terminaison approprié utilise (par exemple, "1.1.00.20212500" ). |
osVersion |
Chaîne qui représente le système d’exploitation et la version de chaque appareil de point de terminaison. |
participantTenantId |
ID du locataire Microsoft associé à l’identité du participant. Le locataire peut être le locataire Azure qui possède la ressource Azure Communication Services ou le locataire Microsoft d’une identité M365. Ce champ est utilisé pour guider l’édition interlocataire. |
participantType |
Description du participant en tant que combinaison de son client (Azure Communication Services ou Teams) et de son identité (Azure Communication Services ou Microsoft 365). Les valeurs possibles sont les suivantes : Azure Communication Services (identité Azure Communication Services et SDK Azure Communication Services), Teams (identité Teams et client Teams), Azure Communication Services en tant qu’utilisateur externe Teams (identité Azure Communication Services et SDK Azure Communication Services dans un appel ou une réunion Teams), Azure Communication Services en tant qu’utilisateur Microsoft 365 (identité M365 et client Azure Communication Services) et Applications vocales Teams. |
pstnPartcipantCallType |
Représente le type et la direction des participants RTC, notamment les appels d’urgence, le routage direct, le transfert manuel, le transfert automatique, etc. |
Schéma des journaux de diagnostic d’appel
Les journaux de diagnostic d’appel fournissent des informations importantes sur les points de terminaison et les transferts d’appareils multimédias pour chaque participant. Ils fournissent également des mesures qui vous aident à comprendre les problèmes qualité.
Pour chaque point de terminaison d’un appel, un journal de diagnostic d’appel distinct est créé pour les flux multimédias sortants (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.
Remarque
Dans cet article, les appels P2P et de groupe se trouvent par défaut dans le même locataire pour tous les scénarios d’appel qui sont inter-locataires. Ils sont spécifiés en tant que tels tout au long de l’article.
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 qui est 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 qui est 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 comprennent "Audio" , "Video" , "VBSS" (partage d’écran vidéo) et "AppSharing" . |
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 pour un délai jitterAvg supérieur à 30 ms environ, un impact négatif sur la qualité est susceptible de se produire. 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 SDK web, ce « JitterBufferSizeAvg » est la valeur moyenne de la « jitterBufferDelay » pendant l’appel, tandis que le « jitterBufferDelay » est la durée d’un échantillon audio ou d’une image vidéo qui reste dans la mémoire tampon de la gigue. Normalement, lorsque la valeur « JitterBufferSizeAvg » est supérieure à 200 ms, elle entraîne 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, lorsque cette valeur est supérieure à 200 ms, elle entraîne un impact négatif sur la qualité. |
HealedDataRatioAvg |
Pourcentage moyen de paquets de données perdus ou endommagés qui sont 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 cela 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. |
Schéma du journal des opérations du client d’appel
Important
Les fonctionnalités décrites dans cet article sont actuellement en préversion publique. Cette préversion est fournie sans contrat de niveau de service et n’est pas recommandée pour les charges de travail de production. Certaines fonctionnalités peuvent être limitées ou non prises en charge. Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.
Le journal des opérations du client d’appel fournit des informations côté client sur les points de terminaison d’appel et les participants impliqués dans un appel. Ces journaux sont actuellement en préversion et affichent les événements du client qui se sont produits dans un appel et quelles actions le client a peut-être effectuées pendant un appel.
Ce journal fournit des informations détaillées sur les actions effectuées pendant un appel et peut être utilisé pour visualiser les problèmes d’appel et investiguer à l’aide de Diagnostics d’appel pour votre ressource Azure Communication Services. En savoir plus sur Diagnostics d’appel
Propriété | Description |
---|---|
CallClientTimeStamp |
Horodatage de l’opération sur le SDK en heure UTC. |
OperationName |
Nom de l’opération déclenchée sur le SDK Calling. |
CallId |
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, et vous pouvez l’utiliser pour joindre les données de différents journaux. Il est similaire au correlationId dans le journal de résumé des appels et le journal de diagnostic des appels. |
ParticipantId |
Identificateur unique pour chaque signal d’appel (dans les appels de groupe) ou participant d’appel (dans les appels pair à pair). Cet ID est le point de corrélation principal entre les journaux CallSummary, CallDiagnostic, CallClientOperations et CallClientMediaStats. |
OperationType |
Opération du client d’appel. |
OperationId |
GGUID unique identifiant une opération du SDK. |
DurationMs |
Durée que prend une opération du SDK appelant pour échouer ou réussir. |
ResultType |
Champ décrivant la réussite ou l’échec d’une opération. |
ResultSignature |
HTTP comme échec ou code de réussite (200, 500). |
SdkVersion |
Version du SDK Calling en cours d’utilisation. |
UserAgent |
La chaîne de l’agent utilisateur standard basée sur le navigateur ou le SDK Calling de la plateforme est utilisée. |
ClientInstanceId |
GGUID unique identifiant l’objet CallClient. |
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 nulle, l’entité connectée est le serveur Communication Services (endpointType = "Server"). La valeur endpointId peut parfois être conservée pour le même utilisateur sur plusieurs appels (correlationId) pour les clients natifs. Le nombre de valeurs endpointId détermine le nombre de journaux de résumé des appels. Un journal de résumé distinct est créé pour chaque valeur endpointId. |
OperationPayload |
Charge utile dynamique qui varie en fonction de l’opération et qui fournit davantage de détails spécifiques à l’opération. |
Appels P2P ou appels de groupe
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
etparticipantDuration
.
Structure journal
Azure Communication Services crée quatre types de journaux :
Journaux de résumé d’appel : contiennent des informations de base sur l’appel, notamment tous les informations pertinentes sur les ID, les horodatages, les points de terminaison et le SDK. Pour chaque participant à un appel, Communication Services crée un journal de résumé d’appel distinct.
Si quelqu’un rejoint un appel, ce participant a la même valeur
EndpointId
, mais une valeurParticipantId
différente. Ce point de terminaison peut alors avoir deux journaux de résumé d’appel.Journaux de diagnostic d’appel : contiennent des informations sur le flux, ainsi qu’un ensemble de métriques qui indiquent la qualité des mesures de l’expérience. 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.Journaux des opérations du client d’appel : contiennent des événements du client d’appel détaillés. 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.
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ésumé d’appel (un pour chaque valeur participantID
) et quatre journaux de diagnostic d’appel (un pour chaque flux multimédia).
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 diagnostic d’appel : un pour chaque flux multimédia par participantId
.
Pour les participants du client d’appel Azure Communication Services (ACS), les journaux des opérations du client d’appel sont identiques aux appels P2P. Pour chaque participant utilisant le SDK Calling, il y a une série de journaux des opérations 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 diagnostic d’appel (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 diagnostic d’appel relatifs à chaque valeur participantId
(un pour chaque flux multimédia).
Remarque
Cette version prend uniquement en charge les journaux de diagnostic 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.
Exemple de données
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": "8d1a8374-344d-4502-b54b-ba2d6daaf0ae",
Journaux de résumé d’appel
Les journaux de résumé d’appel contiennent des informations en commun sur les opérations et les catégories :
"operationName": "CallSummary",
"operationVersion": "1.0",
"category": "CallSummary",
Voici le résumé d’un appel pour l’utilisateur VoIP 1 :
"properties": {
"identifier": "acs:61fddbe3-0003-4066-97bc-6aaf143bbb84_0000000b-4fee-66cf-ac00-343a0d003158",
"callStartTime": "2021-07-19T17:54:05.113Z",
"callDuration": 6,
"callType": "P2P",
"teamsThreadId": "null",
"participantId": "null",
"participantStartTime": "2021-07-19T17:54:06.758Z",
"participantDuration": "5",
"participantEndReason": "0",
"endpointId": "570ea078-74e9-4430-9c67-464ba1fa5859",
"endpointType": "VoIP",
"sdkVersion": "1.0.1.0",
"osVersion": "Windows 10.0.17763 Arch: x64"
}
Voici le résumé d’un appel pour l’utilisateur VoIP 2 :
"properties": {
"identifier": "acs:7af14122-9ac7-4b81-80a8-4bf3582b42d0_06f9276d-8efe-4bdd-8c22-ebc5434903f0",
"callStartTime": "2021-07-19T17:54:05.335Z",
"callDuration": 6,
"callType": "P2P",
"teamsThreadId": "null",
"participantId": "null",
"participantStartTime": "2021-07-19T17:54:06.335Z",
"participantDuration": "5",
"participantEndReason": "0",
"endpointId": "a5bd82f9-ac38-4f4a-a0fa-bb3467cdcc64",
"endpointType": "VoIP",
"sdkVersion": "1.1.0.0",
"osVersion": "null"
}
Voici un journal de résumé d’appel inter-locataires pour l’utilisateur VoIP 1 :
"properties": {
"identifier": "1e4c59e1-r1rr-49bc-893d-990dsds8f9f5",
"callStartTime": "2022-08-14T06:18:27.010Z",
"callDuration": 520,
"callType": "P2P",
"teamsThreadId": "null",
"participantId": "null",
"participantTenantId": "02cbdb3c-155a-4b95-b829-6d56a45787ca",
"participantStartTime": "2022-08-14T06:18:27.010Z",
"participantDuration": "520",
"participantEndReason": "0",
"endpointId": "02cbdb3c-155a-4d98-b829-aaaaa61d44ea",
"endpointType": "VoIP",
"sdkVersion": "Redacted",
"osVersion": "Redacted"
}
Voici le résumé d’un appel pour un appel RTC :
Remarque
Les journaux d’appels P2P ou de groupe ont les versions du système d’exploitation et du SDK supprimées, qu’il s’agisse du locataire du participant ou du locataire du bot.
"properties": {
"identifier": "b1999c3e-bbbb-4650-9b23-9999bdabab47",
"callStartTime": "2022-08-07T13:53:12Z",
"callDuration": 1470,
"callType": "Group",
"teamsThreadId": "19:36ec5177126fff000aaa521670c804a3@thread.v2",
"participantId": " b25cf111-73df-4e0a-a888-640000abe34d",
"participantStartTime": "2022-08-07T13:56:45Z",
"participantDuration": 960,
"participantEndReason": "0",
"endpointId": "8731d003-6c1e-4808-8159-effff000aaa2",
"endpointType": "PSTN",
"sdkVersion": "Redacted",
"osVersion": "Redacted"
}
Journaux de diagnostic d’appel
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": "341acde7-8aa5-445b-a3da-2ddadca47d22",
Journaux de résumé d’appel
Les journaux de résumé d’appel contiennent des informations en commun sur les opérations et les catégories :
"operationName": "CallSummary",
"operationVersion": "1.0",
"category": "CallSummary",
Voici le résumé d’un appel pour le point de terminaison VoIP 1 :
"properties": {
"identifier": "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-729f-ac00-343a0d00d975",
"callStartTime": "2021-07-05T06:16:40.240Z",
"callDuration": 87,
"callType": "Group",
"teamsThreadId": "19:meeting_MjZiOTAyN2YtZWU1Yi00ZTZiLT77777OOOOO99999jgxOTkw@thread.v2",
"participantId": "04cc26f5-a86d-481c-b9f9-7a40be4d6fba",
"participantStartTime": "2021-07-05T06:16:44.235Z",
"participantDuration": "82",
"participantEndReason": "0",
"endpointId": "5ebd55df-ffff-ffff-89e6-4f3f0453b1a6",
"endpointType": "VoIP",
"sdkVersion": "1.0.0.3",
"osVersion": "Darwin Kernel Version 18.7.0: Mon Nov 9 15:07:15 PST 2020; root:xnu-4903.272.3~3/RELEASE_ARM64_S5L8960X"
}
Voici le résumé d’un appel pour le point de terminaison VoIP 3 :
"properties": {
"identifier": "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-57c6-ac00-343a0d00d972",
"callStartTime": "2021-07-05T06:16:40.240Z",
"callDuration": 87,
"callType": "Group",
"teamsThreadId": "19:meeting_MjZiOTAyN2YtZWU1Yi00ZTZiLTk2ZDUtYTZlM2I2ZjgxOTkw@thread.v2",
"participantId": "1a9cb3d1-7898-4063-b3d2-26c1630ecf03",
"participantStartTime": "2021-07-05T06:16:40.240Z",
"participantDuration": "87",
"participantEndReason": "0",
"endpointId": "5ebd55df-ffff-ffff-ab89-19ff584890b7",
"endpointType": "VoIP",
"sdkVersion": "1.0.0.3",
"osVersion": "Android 11.0; Manufacturer: Google; Product: redfin; Model: Pixel 5; Hardware: redfin"
}
Voici le résumé d’un appel pour le point de terminaison RTC 2 :
"properties": {
"identifier": "null",
"callStartTime": "2021-07-05T06:16:40.240Z",
"callDuration": 87,
"callType": "Group",
"teamsThreadId": "19:meeting_MjZiOTAyN2YtZWU1Yi00ZTZiLT77777OOOOO99999jgxOTkw@thread.v2",
"participantId": "515650f7-8204-4079-ac9d-d8f4bf07b04c",
"participantStartTime": "2021-07-05T06:17:10.447Z",
"participantDuration": "52",
"participantEndReason": "0",
"endpointId": "46387150-692a-47be-8c9d-1237efe6c48b",
"endpointType": "PSTN",
"sdkVersion": "null",
"osVersion": "null"
}
Voici un journal de résumé d’appel inter-locataires :
"properties": {
"identifier": "1e4c59e1-r1rr-49bc-893d-990dsds8f9f5",
"callStartTime": "2022-08-14T06:18:27.010Z",
"callDuration": 912,
"callType": "Group",
"teamsThreadId": "19:meeting_MjZiOTAyN2YtZWU1Yi00ZTZiLT77777OOOOO99999jgxOTkw@thread.v2",
"participantId": "aa1dd7da-5922-4bb1-a4fa-e350a111fd9c",
"participantTenantId": "02cbdb3c-155a-4b95-b829-6d56a45787ca",
"participantStartTime": "2022-08-14T06:18:27.010Z",
"participantDuration": "902",
"participantEndReason": "0",
"endpointId": "02cbdb3c-155a-4d98-b829-aaaaa61d44ea",
"endpointType": "VoIP",
"sdkVersion": "Redacted",
"osVersion": "Redacted"
}
Voici un journal de résumé d’appel inter-locataires avec un bot en tant que participant :
"properties": {
"identifier": "b1902c3e-b9f7-4650-9b23-9999bdabab47",
"callStartTime": "2022-08-09T16:00:32Z",
"callDuration": 1470,
"callType": "Group",
"teamsThreadId": "19:meeting_MmQwZDcwYTQtZ000HWE6NzI4LTg1YTAtNXXXXX99999ZZZZZ@thread.v2",
"participantId": "66e9d9a7-a434-4663-d91d-fb1ea73ff31e",
"participantStartTime": "2022-08-09T16:14:18Z",
"participantDuration": 644,
"participantEndReason": "0",
"endpointId": "69680ec2-5ac0-4a3c-9574-eaaa77720b82",
"endpointType": "Bot",
"sdkVersion": "Redacted",
"osVersion": "Redacted"
}
Journaux de diagnostic d’appel
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",
Journaux des opérations du client d’appel pour les appels P2P et les appels de groupe
Pour le journal des opérations du client d’appel, il n’existe aucune différence entre les scénarios d’appel P2P et de groupe et le nombre de journaux dépend des opérations du SDK et de la durée des appels. Voici quelques exemples génériques qui montrent le schéma de ces journaux.
Journal des opérations du client d’appel
Voici un journal des opérations du client d’appel pour l’opération « CreateView » :
"properties": {
"TenantId": "4e7403f8-515a-4df5-8e13-59f0e2b76e3a",
"TimeGenerated": "2024-01-09T17:06:50.3Z",
"CallClientTimeStamp": "2024-01-09T15:07:56.066Z",
"OperationName": "CreateView" ,
"CallId": "92d800c4-abde-40be-91e9-3814ee786b19",
"ParticipantId": "2656fd6c-6d4a-451d-a1a5-ce1baefc4d5c",
"OperationType": "client-api-request",
"OperationId": "0d987336-37e0-4acc-aba3-e48741d88103",
"DurationMs": "577",
"ResultType": "Succeeded",
"ResultSignature": "200",
"SdkVersion": "1.19.2.2_beta",
"UserAgent": "azure-communication-services/1.3.1-beta.1 azsdk-js-communication-calling/1.19.2-beta.2 (javascript_calling_sdk;#clientTag:904f667c-5f25-4729-9ee8-6968b0eaa40b). Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"ClientInstanceId": "d08a3d05-db90-415f-88a7-87ae74edc1dd",
"OperationPayload": "{"StreamType":"Video","StreamId":"2.0","Source":"remote","RemoteParticipantId":"remote"}",
"Type": "ACSCallClientOperations"
}
Chaque participant peut avoir de nombreuses métriques différentes pour un appel. La requête suivante peut être exécutée dans Log Analytics dans le portail Azure pour lister toutes les opérations possibles dans le journal des opérations du client d’appel :
ACSCallClientOperations | distinct OperationName
Codes d’erreur
La propriété participantEndReason
contient une valeur de l’ensemble des codes d’erreur du SDK Calling. Vous pouvez consulter ces codes pour résoudre les problèmes lors de l’appel, pour chaque point de terminaison. Consultez Résolution des problèmes dans Azure Communication Services.
Étapes suivantes
Découvrez le tableau de bord Insights pour surveiller les métriques et les journaux d’appel vocal et d’appel vidéo.
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 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