Teams Realtime Telemetry

Wer im Oktober 2021 aufgepasst hat, hat sofort einen neuen Eintrag beim Benutzer im Teams Admin Center sehen können. Auf der Karteikarte "Meetings & Calls" gibt es mittlerweile einen "Recent Meetings"-Bereich, wenn der Anwender gerade in einer Besprechung ist. Dies ist die Sicht des Administrators, denn Endanwender konnten schon länger im Teams Client bei Bedarf ähnliche Werte anzeigen lassen (Siehe Teams Client Anrufstatistik).

Entgegen erster Ankündigungen wird für die Nutzung der Realtime Telemetrie keine Teams Advanced Communications SKU erforderlich sein.

Admin Portal - Benutzer

Der Einstiegspunkt für einen Teams Administrator ist der Benutzer. Unter "Users - Manage Users" suche ich den fraglichen Anwender und klicke dann auf "Meetings und Calls". Wenn der Anwender gerade in einen Meeting ist, dann wird mir das angezeigt:

In dem Beispiel bin ich in einem Meeting und für das vorherige Meeting habe ich mir auch die Echtzeitstatistiken angeschaut.

Einschränkungen

Damit kommen wir auch gleich zu den Einschränkungen.

  • Nur nach Aktivierung
    Nach meiner Beobachtung protokolliert Teams hier nicht alle Anrufe permanent, sondern nur erst, wenn ein Administrator sich ein Meeting anzeigen lässt. Erst dann triggert dies eine Erfassung auf den Clients die Statistiken zu liefern.
  • Nur Meeting
    Ich habe bislang nur Besprechungen (Meetings) gesehen. Ein Echtzeitstatus für PSTN-Anrufe oder 1:1 Voice/Video-Anrufe werden nicht erfasst
  • Letzte 24h
    Die gelieferten Daten werden von Microsoft maximal 24h vorgehalten. Eine Analyse eines älteren Meetings ist damit nicht möglich. Für ein akutes Troubleshooting ist das ausreichend aber die Details werden wohl nicht in den CQD/CA-Datenbanken überführt.
  • 3h maximale Dauer
    Anscheinend stoppt die Detailaufzeichnung nach drei Stunden automatisch. Längere Meetings sind damit nicht komplett enthalten
  • Kompatible Clients
    Nicht alle Endpunkte können auch die gewünschten Daten liefern. Aktuell sind dies "Teams Windows Client", Team Mac, Teams Android, Teams IOS, Teams Linux, Surface Hub 2S, Teams Room System, Levono ThinkSmart View. Ggfls. müssen Sie ein Update des Clients machen.
    Noch nicht kompatibel sind Teams im Webbrowser, VDI und CVI-Client (Terminal Server/Citrix),
  • Externe Teilnehmer sind anonym
    Zum Schutz der Privatsphäre werden externe Teilnehmer aus anderen Tenants im Echtzeitstatus leider als "unavailable" angezeigt. Das finde ich sehr unglücklich, da ein Admin damit die problematische Verbindung nicht ermitteln kann. Microsoft hätte wenigstens z.B. die ersten drei Anfangsbuchstaben anzeigen können. Im späteren Report kann ich, abhängig von den Einstellungen im Tenant, dann doch wieder alle Teilnehmer sehen.
  • Admin Rollen
    Der Zugriff auf die Echtzeitdaten ist auf Personen beschränkt, die mindestens eine der folgenden Rollen innehaben: Teams Administrator, Teams Communications Support Specialist or Teams Communications Support Engineer.

Die Funktion ist also primäre ein Troubleshooting auf Zuruf ab dem Moment, an dem ein Teams Administrator die Aufzeichnung startet.

Einzelne Streams

Die Details zu einem Meeting können Sie über zwei Einsprung-Adressen anzeigen lassen:

  • Klick auf die Meeting ID
    Dann sehen sie direkt die Details des zu den Streams des aktuell ausgewählten Benutzers. Wenn Sie damit genau den Anwender haben, der auch über Probleme klagt, dann ist das der schnelle Weg.
  • Klick auf die Teilnehmer
    Das ist aus meiner Sicht der wichtigere Einstieg, da ich damit dann alle Teilnehmer und Streams sehe.

Hier sehe ich direkt z.B.: die "Audio Inbound Paket Loss" und die "Audio Outgoing Roundtrip"-Zeiten, die ein guter Indikator für die jeweilige Verbindung sind:

Hier ist es die eine Verbindung, die negativ auffällt.

Stream-Details

Wenn ich dann aber auf den einzelnen Teilnehmer zurück komme, dann sehe ich sehr genau auch dessen individuellen Werte. Es dauert erst einmal ca. 10 Sekunden, bis die Daten ankommen. Ich vermute, dass das Backend dem Client mitteilt, dass nun Details geliefert werden sollen und diese dann beinahe in Echtzeit angezeigt werden:

Hier am Beispiel des Clients, der gerade seinen Bildschirm freigibt. Folgende Daten werden erfasst (Okt 2021)

Service Richtung Kennzahl Beschreibung

Application Sharing

Outbound

Round Trip Time (RTT)

Die Round Trip Time bezeichnet die Zeit, die ein Paket zur Gegenstelle und wieder zurück unterwegs ist. Laut Microsoft sollte diese Zeit immer unter 100ms (Client) liegen oder unter 60ms von der Firmenfirewall (Edge) zur Cloud.

Application Sharing

Outbound

Bitrate

Hiermit können Sie abschätzen, wie viel Bandbreite der Client beim Sharing des Bildschirms gerade benötigt. Die Datenmenge finden Sie bei den anderen Teilnehmern dann bei "Inbound". In der Regel sind das 50kBit-2 MBit, je nach "Aktivität" auf dem BIldschirm.

Application Sharing

Outbound

Frame Rate

Teams sendet kein RPD mehr wie erste Versionen von Lync oder Skype for Business sondern sendet das Bild als "Video". Eine höhere Framerade bedeutet fließendere Animationen und eingebettete Videos aber auch mehr Bandbreite. Teams passt dies an die Bandbreite (gemessen durch RTT) und Content an.

Application Sharing

Inbound

Paket Loss

Interessanterweise misst die Echtzeit Telemetrie von Teams wohl nur eingehend den Paketverlust. Dieser Wert sollte möglichst gering, idealerweise 0% sein.

Application Sharing

Inbound

Bitrate

Genutzte Bandbreite des Empfängers zur Anzeige des Inhalts

Application Sharing

Inbound

Frame Rate

Genutzte Framerate  des Empfängers zur Anzeige des Inhalts.

Audio Stream

Outbound

Round Trip Time

Siehe RTT bei Application Sharing. Hier gilt erst recht die 60ms/100ms Grenze. Audio ist deutlich empfindlicher als eine vielleicht etwas verspätete PowerPoint-Animation.

Audio Stream

Outbound

Bitrate

Siehe Bitrate bei Application Sharing, Ein aktiver Sprecher sendet in der Regel ca. 100kbit Audio/Sek

Audio Stream

Inbound

Paket Loss

Siehe Paket Loss bei Application Sharing

Audio Stream

Inbound

Jitter

Bei Application Sharing ist Jitter kaum ein Thema, da die Bilder auch etwas verspätet kommen können. Bei Audio wird ein zu spät ankommendes Paket einfach nicht mehr wiedergegeben. Das verschlechtert die Qualität durch fehlende Wortfetzen. Daher sollte der Jitter unter 30ms liegen

Video Stream

Outbound

Round trip time

Siehe RTT bei Application Sharing. Wenn die RTT höher ist, dann laufen Bild und Ton auseinander oder Teilbilder fehlen oder das Bild friert kurz ein.

Video Stream

Outbound

Bitrate

Genutzte Bandbreite des Senders zur Übertragung des Video

Video Stream

Outbound

Frame Rate

Genutzte Framerate, mit der das Bild gesendet wird. Eine höhere Framerate macht das Bild "flüssiger" aber kostet auch mehr Bandbreite. 

Video Stream

Inbound

Keine Daten

Leider habe ich noch keine Statistik für eingehendes Video gesehen. Hier würde ich mir zumindest die Bitrate und natürlich Paket Loss wünschen, um Anzeigefehler bei einem Teilnehmer aufspüren zu können.

Sie sehen schon einen Unterschied zwischen "Iinbound" und "Outbound" aus Sicht des Teilnehmers. So wird die "Roundtriptime" nur in Senderichtung erfasst. Dafür habe ich noch Verständnis aber der interessanter Wert für "Paket Loss" wird nur eingehend ermittelt, z.B. vom Teams Backend zum Client. Ich fände auch die Gegenrichtung interessant, da gerade der Upstream einer DSL-Verbindung oft viel niedriger ist als der Downsteam. Technisch sollte die MCU dem Sender über RTCP schon ein Feedback geben, welches der Client ebenfalls melden könnte. Bei einem "ruckeligen Video" können Sie dann nur eine Aufzeichnung starten und wenn es dort auch ruckelt, dann liegt es beim Sender. Interessanterweise gibt es bei Video auch keine "Inbound"-Daten", so dass Sie hier auch keine Ursache ermitteln könnten.

Gerade "Paket Loss" finden Sie nur am Ende in "Call Analytics" und im "Call quality dashboard (CQD)". Allerdings dann nur den MAX und AVERAGE über den gesamten Call. Das reicht natürlich auch nicht wirklich weiter.

API?

Wenn mein Browser solche Daten aus der Cloud abfragt, dann ist es mit "F12-Debugging" oder Fiddler u.a. sehr einfach die API-Aufrufe zu zu betrachten. Vielleicht gibt es ja eine flexibel API, die man auch anderweitig nutzen könnte.

Die URLs und Hostnamen passen ja schon. Allerdings sind es keine direkt nutzbaren API vorhanden. Realtime Telemetrie nutzt z.B. kein Graph sondern eigene Services und die sind nicht offengelegt. Jeder Versuch darauf zuzugreifen kann vielleicht funktionieren aber auch wieder brechen. Es ist schon nett in die Payload zu schauen und zu sehen, was Teams alles meldet.

Was fehlt?

Die Funktion Teams Realtime Telemetry ist ein wichtiger Schritt in die richtige Richtung. Erstmals kann ein Administrator bei einem laufenden in die Kennzahlen schauen. Aber das System ist au jeden fall ausbaubar. Schon am Anfang habe ich einige Einschränkungen aufgeführt, die aktuell vorhanden sind. Aber aus den Daten könnte Microsoft noch viel mehr holen, z.B.

  • Kontinuierlich und nicht nur bei Aktivierung
    Aktuell protokolliert Teams am Ende eines Anrufs einen Summenbericht an CDQ/CA. Die Realtime-Funktion hält nur kurz die Daten für eine Analyse. Mich wäre mit einem Zwischenschritt besser geholfen, bei der ein Client z.B. die Werte jeder Minute zusammenfasst und automatisch speichert. Mit der Aktivierung erst beim Start durch den Administrator kann ich keine Analyse in die nahe Vergangenheit ausführen. Wie wahrscheinlich ist es, dass ein Meeting-Teilnehmer während des Meetings noch ein Ticket aufmacht und der Teams Admin noch während des Meetings dann nachschauen kann?
  • Aktivierung durch den Anwender
    Eine Mindestfunktion wäre, dass ein Administator ein "Rate a bad Call" schon während des Meetings auslösen kann und die Teilnehmer dann für diese Zeit z.B. +/- 5 Minuten ihre Daten als Schnappschuss berichten.
  • Nur Meetings
    Die Beschränkung auf Meetings macht aus meiner Sicht gar keinen Sinn. Auch ein 1:1 Teams Anruf oder PSTN-Anruf müsste ebenso "trackbar" sein
  • Keine Übersicht nach Site/Netzwerk/Location
    Solange Teams Realtime Telemetry erst durch den Administrator aktiv wird, kann ich auch keine Übersicht der "Bad Calls" sehen. Aber genau das wäre doch pfiffig, wenn die Clients jede Minute einen Sammelbericht senden, der dann eine "Übersicht" der Bad-Sites o.ä. erstellt. Der CQD-Report am Ende eines 2-4h Meetings liefert einfach nicht genug Daten.
  • Keine Übersicht nach "Problembenutzer"
    Wenn alle Clients automatisch entsprechende Zwischenberichte liefern könnten, dann wäre auch eine Übersicht aller "aktiven Clients" mit ihren Kennzahlen, sortiert nach einem Qualitätsindex eine wünschenswerte Ansicht
  • API für Monitoring
    Zuletzt wäre eine automatisierte Abfrage, wegen mir als Graph Webhook o.ä. hilfreich, um diese Daten in eine eigene Plattform zu überführen.

Für die meisten Wünsche reicht die aktuelle Funktion aber nicht aus bzw. wäre hier auch falsch einsortiert. Vielleicht baut Microsoft auch einmal eine weitere Plattform für ein "Neartime"-Reporting in eine eigene Datensenke.

Bis dahin nehmen wir aber gerne, was Microsoft bereitstellt. Ob aber alle Firmen für diese Funktion auch die 4€ zusätzlich für die  Teams Advanced Communications SKU ausgehen, werden wir später sehen.

Weitere Links