Freigeben über

Schema für Anrufdiagnoseprotokolle

  • Artikel

Anrufdiagnoseprotokolle liefern wichtige Informationen zu den Endpunkten und den Medienübertragungen für die einzelnen Teilnehmer. Außerdem stellen sie Messungen bereit, die dabei helfen, Qualitätsprobleme zu verstehen.

Für jede EndpointId innerhalb eines Anrufs (einschließlich des Servers) wird von Azure Communication Services ein eigenes Anrufdiagnoseprotokoll für den jeweiligen Mediendatenstrom (z. B. Audio oder Video) zwischen Endpunkten erstellt. Bei einem P2P-Anruf enthält jedes Protokoll Daten, die sich auf jeden der ausgehenden Datenströme beziehen, die den einzelnen Endpunkten zugeordnet sind. In Gruppenanrufen dient participantId als Schlüsselbezeichner, um die zugehörigen ausgehenden Protokolle in einer eindeutigen Teilnehmerverbindung zu verknüpfen. Anrufdiagnoseprotokolle bleiben unverändert und sind unabhängig vom Teilnehmermandanten identisch.

Verwenden von Anrufprotokollen

Es wird empfohlen, alle verfügbaren Anrufprotokolle in einer Protokollanalyseressource zu erfassen, damit Sie Ihre Anrufnutzung überwachen, die Anrufqualität verbessern und neue Protokolle von Azure Communication Services erhalten können, wenn sie veröffentlicht werden.

Es gibt zwei Haupttools, mit denen Sie Ihre Anrufe überwachen und die Anrufqualität verbessern können.

Es wird empfohlen, die Dashboards für Einblicke in Sprache und Video zu verwenden, um qualitätsbezogene Untersuchungen zu starten, und bei Bedarf die Anrufdiagnose zu verwenden, um einzelne Anrufe zu untersuchen, wenn Sie präzise Details benötigen.

Datenkonzepte

Wichtig

Sie müssen Protokolle erfassen, wenn Sie sie analysieren möchten. Weitere Informationen finden Sie unter: Wie speichere ich Protokolle?

Azure speichert Ihre Anruflistendaten nur, wenn Sie diese spezifischen Diagnoseeinstellungen aktivieren. Ihre Anrufdaten sind nicht rückwirkend verfügbar. Sie erfassen die Daten, nachdem Sie die Diagnoseeinstellungen erstellt haben.

Datendefinitionen

Schema für Anrufdiagnoseprotokolle

In dieser Tabelle werden die einzelnen Eigenschaften beschrieben.

Eigenschaft Beschreibung
operationName Der mit der Protokollaufzeichnung verbundene Vorgang
operationVersion Der api-version-Wert, der dem Vorgang zugeordnet wird, wenn der operationName-Vorgang über eine API durchgeführt wurde. Wenn keine API für diesen Vorgang vorhanden ist, entspricht die Version der Version des Vorgangs (für den Fall, dass sich die dem Vorgang zugeordneten Eigenschaften in Zukunft ändern).
category Die Protokollkategorie des Ereignisses. Diese Eigenschaft ist die Granularität, mit der Sie Protokolle für eine Ressource aktivieren oder deaktivieren können. Die Eigenschaften, die im properties-Blob eines Ereignisses angezeigt werden, sind innerhalb einer Protokollkategorie und eines Ressourcentyps identisch.
correlationId Die eindeutige ID für einen Anruf. Sie kennzeichnet korrelierte Ereignisse aller Teilnehmer bzw. Teilnehmerinnen und Endpunkte, die während eines einzelnen Anrufs eine Verbindung herstellen. Falls Sie einmal eine Supportanfrage für Microsoft erstellen müssen, können Sie den correlationId-Wert verwenden, um den Anruf zu identifizieren, für den Sie die Problembehandlung durchführen.
participantId Diese ID wird generiert, um die bidirektionale Verbindung zwischen einem "Participant"-Endpunkt (endpointType = "Server") und dem Server darzustellen. Bei callType = "P2P" besteht eine direkte Verbindung zwischen zwei Endpunkten, und es wird kein participantId-Wert generiert.
identifier Die eindeutige ID für den Benutzer Die Identität kann ein Azure Communications Services-Benutzer bzw. eine Azure Communication Services-Benutzerin, eine Microsoft Entra-Benutzer-ID, eine Teams-Objekt-ID oder eine Teams-Bot-ID sein. Sie können diese ID verwenden, um Benutzerereignisse in Protokollen zu korrelieren.
endpointId Die eindeutige ID, die die einzelnen, mit dem Anruf verbundenen Endpunkte darstellt, wobei endpointType den Endpunkttyp definiert. Wenn der Wert null lautet, ist die verbundene Entität der Communication Services-Server. Bei nativen Clients kann EndpointId für den gleichen Benutzer bzw. für die gleiche Benutzerin über mehrere Anrufe (correlationId) hinweg bestehen bleiben. Wenn es sich bei dem Client um einen Webbrowser handelt, ist der Wert jedoch für jeden Anruf eindeutig.
endpointType Beschreibt die Eigenschaften der einzelnen endpointId-Instanzen. Er kann "Server", "VOIP", "PSTN", "BOT", "Voicemail", "Anonymous" oder "Unknown" enthalten.
mediaType Dieser Zeichenfolgenwert beschreibt die Art der Medien, die innerhalb der einzelnen Datenströme zwischen den Endpunkten übertragen werden. Mögliche Werte sind "Audio", "Video", "VBSS" (Bildschirmfreigabe) und "AppSharing" (Datenkanal).
streamId Nicht eindeutige ganze Zahl, die zusammen mit mediaType zur eindeutigen Identifizierung von Datenströmen mit dem gleichen participantId-Wert verwendet werden kann.
transportType Der Zeichenfolgenwert, der das Netzwerktransportprotokoll für die einzelnen participantId-Werte beschreibt. Er kann "UDP", "TCP" oder "Unrecognized" enthalten. "Unrecognized" gibt an, dass das System nicht feststellen konnte, ob es sich beim Transporttyp um TCP oder UDP handelt.
roundTripTimeAvg Die durchschnittliche Zeit, die benötigt wird, um ein IP-Paket innerhalb eines participantDuration-Zeitraums zwischen zwei Endpunkten zu übertragen. Diese Verzögerung bei der Netzwerkweitergabe hängt mit der physischen Entfernung zwischen den beiden Punkten, der Lichtgeschwindigkeit und ggf. anfallendem Zusatzaufwand zusammen, der von den verschiedenen Routern dazwischen verursacht wird.

Die Wartezeit wird für die unidirektionale Strecke bzw. für die Roundtripdauer (Round Trip Time, RTT) gemessen. Der Wert wird in Millisekunden ausgedrückt. Ein RTT größer 500 ms wirkt sich negativ auf die Anrufqualität aus.
roundTripTimeMax Der maximal gemessene RTT (in Millisekunden) für die einzelnen Mediendatenströme während eines participantDuration-Zeitraums (Gruppenanruf) oder während eines callDuration-Zeitraums (P2P-Anruf).
jitterAvg Dies ist die durchschnittliche Änderung der Verzögerung zwischen aufeinanderfolgenden Paketen. In Azure Communication Services kann ein gewisser Grad an Jitter durch eine Pufferung ausgeglichen werden. Wenn der Jitter die Pufferung übersteigt, was ungefähr bei einer jitterAvg-Zeit von mehr als 30 ms der Fall ist, ist eine negative Auswirkung auf die Qualität wahrscheinlich. Die Pakete, die mit unterschiedlicher Geschwindigkeit eintreffen, bewirken, dass die Stimme des Sprechers roboterhaft klingt.

Diese Metrik wird für jeden Mediendatenstrom über den participantDuration-Zeitraum (Gruppenanruf) oder über den callDuration-Zeitraum (P2P-Anruf) gemessen.
jitterMax Der maximale Jitterwert, der zwischen Paketen für die einzelnen Mediendatenströme gemessen wird. Bursts bei Netzwerkbedingungen können Probleme beim Audio-/Videodatenverkehr verursachen.
packetLossRateAvg Der durchschnittliche Prozentsatz an Paketen, die verloren gehen. Paketverluste wirken sich direkt auf die Audioqualität aus. Der Verlust kleiner, einzelner Pakete hat nahezu keine Auswirkungen. Direkt aufeinanderfolgende Burstverluste können dagegen zu vollständigen Audioausfällen führen. Die Pakete, die verworfen werden und nicht an ihrem Ziel ankommen, verursachen Lücken in den Medien. Dies führt zu fehlenden Silben und Wörtern sowie zu abgehackten Videos und Freigaben.

Eine Paketverlustrate von mehr als zehn Prozent (0,1) hat wahrscheinlich negative Auswirkungen auf die Qualität. Diese Metrik wird für jeden Mediendatenstrom über den participantDuration-Zeitraum (Gruppenanruf) oder über den callDuration-Zeitraum (P2P-Anruf) gemessen.
packetLossRateMax Dieser Wert stellt die maximale Paketverlustrate (Prozentsatz) für die einzelnen Mediendatenströme über den participantDuration-Zeitraum (Gruppenanruf) oder über den callDuration-Zeitraum (P2P-Anruf) dar. Bursts bei Netzwerkbedingungen können Probleme beim Audio-/Videodatenverkehr verursachen.
JitterBufferSizeAvg Die durchschnittliche Größe des Jitterpuffers über die Dauer der einzelnen Mediendatenströme. Ein Jitterpuffer ist ein gemeinsam genutzter Datenbereich, in dem VoIP-Pakete gesammelt, gespeichert und in gleichmäßigen Intervallen an den VoIP-Prozessor gesendet werden können. Ein Jitterpuffer ist eine Maßnahme gegen die Auswirkungen von Jitter.

Jitterpuffer können statisch oder dynamisch sein. Statische Jitterpuffer werden auf eine feste Größe festgelegt. Bei dynamischen Jitterpuffern kann die Größe dagegen basierend auf Netzwerkbedingungen angepasst werden. Ziel des Jitterpuffers ist es, einen reibungslosen und unterbrechungsfreien Audio- und Videodatenstrom für Benutzer bzw. Benutzerinnen bereitzustellen.

Im Web-SDK ist JitterBufferSizeAvg der Durchschnittswert von jitterBufferDelay während des Anrufs. jitterBufferDelay ist die Dauer eines Audiobeispiels oder eines Videoframes, der im Jitterpuffer verbleibt.

Normalerweise wirkt sich der Wert negativ auf die Qualität aus, wenn der Wert JitterBufferSizeAvg größer als 200 ms ist.
JitterBufferSizeMax Die maximale Jitterpuffergröße, die während der Dauer der einzelnen Mediendatenströme gemessen wird.

Normalerweise wirkt sich dieser Wert negativ auf die Qualität aus, wenn dieser Wert größer als 200 ms ist.
HealedDataRatioAvg Der durchschnittliche Prozentsatz verlorener oder beschädigter Datenpakete, die während der gesamten Dauer des Audiodatenstroms erfolgreich durch die Korrektur rekonstruiert oder wiederhergestellt werden. Der Anteil korrigierter Daten ist ein Maß für die Wirksamkeit von Fehlerkorrekturtechniken, die in VoIP-Systemen verwendet werden.

Ist dieser Wert größer als 0,1 (zehn Prozent), gilt die Qualität des Datenstroms als schlecht.
HealedDataRatioMax Der maximale Anteil korrigierter Daten, der während der Dauer der einzelnen Mediendatenströme gemessen wird.

Ist dieser Wert größer als 0,1 (zehn Prozent), gilt die Qualität des Datenstroms als schlecht.
VideoFrameRateAvg Die durchschnittliche Anzahl von Videoframes, die während eines Video-/Bildschirmfreigabeanrufs pro Sekunde übertragen werden. Die Bildfrequenz von Videos kann sich auf die Qualität und Ruckelfreiheit des Videodatenstroms auswirken. Höhere Bildfrequenzen führen in der Regel zu ruckelfreieren und flüssigeren Bewegungen. Die Standardbildfrequenz für WebRTC-Video liegt in der Regel bei 30 Frames pro Sekunde (FPS). Die Bildfrequenz kann allerdings abhängig von der spezifischen Implementierung und den Netzwerkbedingungen variieren.

Die Datenstromqualität gilt als schlecht, wenn dieser Wert kleiner als „7“ (Videodatenstrom) bzw. kleiner als „1“ (Bildschirmfreigabe) ist.
RecvResolutionHeight Die durchschnittliche vertikale Größe des eingehenden Videodatenstroms, der während eines Video-/Bildschirmfreigabeanrufs übertragen wird. Dies wird in Pixel gemessen und ist einer der Faktoren, die die Gesamtauflösung und -qualität des Videodatenstroms bestimmen. Die verwendete spezifische Auflösung hängt ggf. von den Funktionen der Geräte und von den Netzwerkbedingungen in Verbindung mit dem Anruf ab.

Die Datenstromqualität gilt als schlecht, wenn dieser Wert kleiner als „240“ (Videodatenstrom) bzw. kleiner als „768“ (Bildschirmfreigabe) ist.
RecvFreezeDurationPerMinuteInMs Die durchschnittliche Dauer des Einfrierens in Millisekunden pro Minute für eingehende Datenströme (Video bzw. Bildschirmfreigabe). Einfrieren ist in der Regel auf eine schlechte Netzwerkbedingung zurückzuführen und kann die Datenstromqualität beeinträchtigen.

Die Datenstromqualität gilt als schlecht, wenn dieser Wert größer als 6.000 ms (Videodatenstrom) bzw. größer als 25.000 ms (Bildschirmfreigabe) ist.
PacketUtilization Die Pakete, die für einen bestimmten Mediendatenstrom gesendet oder empfangen wurden.

Je länger der Aufruf ist, desto höher ist der Wert. Wenn dieser Wert null ist, könnte es darauf hindeuten, dass Medien nicht fließen.
VideoBitRateAvg Die durchschnittliche Bitrate (Bit pro Sekunde) für einen Video- oder Bildschirmfreigabedatenstrom.

Ein niedriger Bitratewert könnte auf ein schlechtes Netzwerkproblem hinweisen. Die erforderliche Mindestbitrate (Bandbreite) finden Sie hier: Netzwerkbandbreite.
VideoBitRateMax Die maximale Bitrate (Bit pro Sekunde) für einen Video- oder Bildschirmfreigabedatenstrom.

Ein niedriger Bitratewert könnte auf ein schlechtes Netzwerkproblem hinweisen. Die erforderliche Mindestbitrate (Bandbreite) finden Sie hier: Netzwerkbandbreite.
StreamDirection Die Richtung des Mediendatenstroms. Ist entweder Inbound oder Outbound.
CodecName Der Name des Codecs, der für die Verarbeitung von Mediendatenströmen verwendet wird. Kann OPUS, G722, H264S, SATIN usw. sein.

Beispieldaten für verschiedene Anruftypen

Hinweis

In diesem Artikel befinden sich P2P- und Gruppenanrufe standardmäßig im gleichen Mandanten. Auf Anrufszenarien, die mandantenübergreifend sind, wird im gesamten Artikel entsprechend hingewiesen.

P2P-Anruf

Hier finden Sie gemeinsam genutzte Felder für alle Protokolle bei einem P2P-Anruf:

"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",

Anrufdiagnoseprotokolle

Anrufdiagnoseprotokolle geben Vorgangsinformationen frei:

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

Diagnoseprotokoll für einen Audiodatenstrom von VoIP-Endpunkt 1 zu VoIP-Endpunkt 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"
}

Diagnoseprotokoll für einen Audiodatenstrom von VoIP-Endpunkt 2 zu VoIP-Endpunkt 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"
}

Diagnoseprotokoll für einen Videodatenstrom von VoIP-Endpunkt 1 zu VoIP-Endpunkt 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"
}

Gruppenanruf

Daten für einen Gruppenanruf werden in drei Anrufzusammenfassungsprotokollen und sechs Anrufdiagnoseprotokollen generiert. Gemeinsame Felder für alle Protokolle des Anrufs:

"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",

Anrufdiagnoseprotokolle

Anrufdiagnoseprotokolle geben Vorgangsinformationen frei:

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

Diagnoseprotokoll für einen Audiodatenstrom von VoIP-Endpunkt 1 zu einem Serverendpunkt:

"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"
}

Diagnoseprotokoll für einen Audiodatenstrom von einem Serverendpunkt zu VoIP-Endpunkt 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"
}

Diagnoseprotokoll für einen Audiodatenstrom von VoIP-Endpunkt 3 zu einem Serverendpunkt:

"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"
}

Diagnoseprotokoll für einen Audiodatenstrom von einem Serverendpunkt zu VoIP-Endpunkt 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",

Häufig gestellte Fragen

Wie speichere ich Protokolle?

Im folgenden Abschnitt werden diese Anforderungen erläutert.

Azure Communication Services-Protokolle werden standardmäßig nicht in Ihrem Azure-Konto gespeichert, daher müssen Sie mit der Speicherung beginnen, damit Tools wie das „Einblicke in Sprache und Video“-Dashboard und Anrufdiagnose funktionieren. Um diese Anruflisten zu sammeln, müssen Sie eine Diagnoseeinstellung aktivieren, die die Anrufdaten an einen Log Analytics-Arbeitsbereich leitet.

Daten werden nicht rückwirkend gespeichert, sodass Sie erst nach der Konfiguration der Diagnoseeinstellung mit der Erfassung von Anruflisten beginnen.

Folgen Sie den Anweisungen zum Hinzufügen von Diagnoseeinstellungen für Ihre Ressource unter Aktivieren von Protokollen über die Diagnoseeinstellungen in Azure Monitor. Es wird empfohlen, zunächst alle Protokolle zu erfassen. Nachdem Sie die Funktionen in Azure Monitor verstanden haben, bestimmen Sie, welche Protokolle Sie aufbewahren möchten und wie lange. Wenn Sie Ihre Diagnoseeinstellung hinzufügen, werden Sie aufgefordert, Protokolle auszuwählen. Um alle Protokolle zu erfassen, wählen Sie allLogs aus.

Ihr Datenvolumen, Ihre Aufbewahrung und Ihre Nutzung in Log Analytics in Azure Monitor wird über vorhandene Azure-Datenzähler abgerechnet. Aus Kostengründen wird empfohlen, ggf. Ihre Datennutzungs- und Aufbewahrungsrichtlinien zu überwachen. Weitere Informationen finden Sie unter Verwalten der Kosten.

Wenn Sie über mehrere Azure Communications Services-Ressourcen-IDs verfügen, müssen Sie diese Einstellungen für jede Ressourcen-ID aktivieren.

Nächste Schritte