Teams LiveEvent/Townhall Meeting im Netzwerk

Diese Seite beschäftigt sich mit der Netzwerkkommunikation von Teams LiveEvent und Teams Townhall Meetings, die sich von klassischen Meetings doch an vielen Stellen unterscheidet.

Beachten Sie bei Recherche im Internet, dass Live Events früher auf der "Microsoft Streams"-Basis. Daher gibt es unterschiedliche Aussagen zu Bandbreiten, Protokollen und Endpunkten. Ich versuche hier die aktuelle Konfiguration zu beschrieben und bin für Hinweise auf Veränderungen dankbar.

Beachten Sie dazu auch die Seite Teams AV-Proxycaching

Umgebung

Der Kundenkreis für Live Events ist überschaubar, denn klassische Teams Meetings können mittlerweile bis zu 1000 aktive Teilnehmer haben und bis 10.000 kommen neue Teilnehmer dann mit einer "Read Only"-Experience dazu, d.h. sehen und hören alles in Echtzeit aber können selbst kein Audio/Video senden oder am Chat teilnehmen. Live Events haben Zielgruppen bis 20.000 Teilnehmer, die ab 31. Dez 2023 bis zu 16h (früher 4h) dauern können.

Im Unterbau ändert sich aber das Verhalten, denn wenn Sie so viele Teilnehmer mit Audio/Video versorgen wollen, dann sind das hohe Bandbreiten. Live Events übertragen Videos zwar maximal 720p aber bei Screensharing mit 1080p sind Bitraten von 1,5MBit-4MBit zu erwarten. Wenn Sie dann auch nur 1.000 Teilnehmer in der Firmenzentrale als Teilnehmer erwarten, sind 1,5-4 GBit zu erwarten. Dies gilt aber auch für normale Teams-Meetings. Bei Live Events könnten Sie aber z.B. ein CDN einsetzen.

Während für Teams Meetings idealerweise aber UDP-Port 3478-3481 zu den Microsoft Media Relays durch den Firewall-Admin zugelassen werden, arbeiten Live Events etwas anders. Der Content wird durch einen "Producer" zum Cloud-Service übertragen, welcher dann diesen Stream über das Microsoft Content Delivery Netzwerk auf verschiedene Auflösungen umsetzt, weltweit verteilt und per TCP-HTTPS an die Clients ausliefert.


Quelle: Live Events in Microsoft Teams https://youtu.be/0pnfFsUtaDQ?t=1441

Die Video-Quellen kommen aus einem Teams Meeting über das bekannte RTP-Protokoll oder von externen Encodern über RTMP. Genau genommen sind die Verbindungen natürlich verschlüsselt, d.h. SRTP und RTMPS. Die Teilnehmer aber sehen den Live Event über TCP. Die Aussage ist nicht falsch aber genau genommen ist es eine "Websockets"-Verbindung, die sogar Proxy-tauglich ist. Teams Live Events nutzt TCP statt UDP, weil damit Netzwerkprobleme wie höhere Latenzzeiten, Jitter oder sogar Paketverluste durch den TCP/IP-Stack abgefangen werden. Ein Live Event ist ja keine "Echtzeit"-Übertragung sondern nur "Neartime". Durch die Zeitverzögerung von mehreren Sekunden kann der Empfänger den Stream puffern.

YouTube nutzt übrigens auch TCP/IP. Betrachten Sie ein Video und trennen Sie dabei die Netzwerkverbindung. Das Video läuft noch einige Sekunden weiter. Über das Context-Menü können Sie in YouTube dies sogar anzeigen:

Übrigens können Sie auch ohne Live Events solche Streamings über YouTube LinkedIn, Twitch u.a. aufsetzen. Ein Teams-Client kann das Meeting per RTMP/RTMPS an einen konfigurierbaren RTMP/RTMPS-Server senden. Das kann auch ein interner Server sein.

CDN Adressen

Schon Teams Meetings mit wenigen hundert Teilnehmern können Netzwerkadministratoren an größeren Standorten in Verlegenheit bringen. Live Events haben oft viel größere Auditorien, die nur dann von der Cloud profitieren, wenn Sie im Home-Office oder verteilten Standorten mit lokalen Breakouts sitzen. Je mehr Teilnehmer sich aber an einem Standort tummeln und die gleiche Internetanbindung nutzen, desto kritischer wird die erforderliche Bandbreite. Zuerst müssen wir betrachten, wie die Live Events Clients denn das Netzwerk nutzen und vor allem welche CDN-Services wie angesprochen werden. Die Quellen dazu sind für Microsoft Teams Meetings gut beschrieben aber eine eigene Seite oder eindeutige Aussagen zu Teams Live Events habe ich nicht gefunden. Verschiedene Quellen steuern etwas bei:

Live events from Stream (Classic) and External app or device live events from Yammer/Teams as well as on-demand videos will automatically use Azure CDN.
..
If several people from the same organization within the same geographic location are streaming the same video(s), CDNs will store a copy of these videos in a location closer to that geographic region. With the video stored, or cached at the closest location, each person streams the video from the location closest to them instead of a location further away. Stream (Classic) uses Azure Media Services to manage what is cached in the Azure CDNs, and for how long. Azure Media Services can use any of the Azure CDN locations to cache video fragments and manifests for a few days. If people in your organization continue to watch the cached videos, they'll stay in the cache. If no one accesses the video for several days, the video will eventually be dropped from the cache. The next time someone attempts to watch the video it’s once again cached at the nearest CDN location.
Quelle: https://learn.microsoft.com/en-us/stream/network-overview#cdn-used-for-video-playback

Eine weitere Quelle ist:

Playback of live event videos uses adaptive bitrate streaming (ABR) but it's a unicast stream, meaning every viewer is getting their own video stream from the internet. For live events or videos sent out to large portions of your organization, there could be a significant amount of internet bandwidth consumed by viewers. For organizations that want to reduce this internet traffic for live events, Microsoft offers a first-party solution, Microsoft eCDN (enterprise content delivery network).
Quelle: https://learn.microsoft.com/en-us/microsoftteams/teams-live-events/set-up-for-teams-live-events#step-4-set-up-a-video-distribution-solution-for-live-events-in-teams

Aus der Dokumentation zum eCDN erfahren wir mehr über die verwendeten Protokolle:

All peers are connected to Microsoft eCDN's network and coordinator (tracker). Microsoft eCDN builds a map of the network and understands which peers are located next to each other (from a network perspective) and decides how to build the peering network.
Quelle: https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#how-do-user-devices-discover-each-other

Q: What are the protocols used by Microsoft eCDN? (e.g. What protocol is used for signaling?)
A: WebSocket is used to connect to the backend, ICE for signaling and SCTP for peer-to-peer communications.
Quelle: https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#what-are-the-protocols-used-by-microsoft-ecdn-eg-what-protocol-is-used-for-signaling

Q: How is the WebSocket traffic secured?
A: It's TLS encryption 1.2 or 1.3 depending on the client.
https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#how-is-the-websocket-traffic-secured-is-it-encrypted-what-type-of-encryption

Q: Does SSL inspection need to be bypassed as well as proxies for connectivity to *.ecdn.teams.microsoft.com?
A: The Microsoft eCDN team has never tested what happens in that case, but it's projected that it will not behave well with WebSocket. As such, we recommend disabling SSL inspection for *.ecdn.teams.microsoft.com.
https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#does-ssl-inspection-need-to-be-bypassed-as-well-as-proxies-for-connectivity-to-ecdnteamsmicrosoftcom 

In the network requirements, opening 1025-65535 ports for UDP on the internal LAN for P2P connections
This port range is only for internal communication inside sites within a corporate network - this traffic shouldn't traverse any firewalls, hence usually it's not blocked by default. If it's blocked in a given network, and the admins don't wish to open so many ports, there's a way to limit the operational ports for WebRTC by using managed browsers.
https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#in-the-network-requirements-opening-1025-65535-ports-for-udp-on-the-internal-lan-for-p2p-connections-which-is-almost-the-entire-range-of-ports-from-microsoft-ecdns-perspective-what-is-the-operational-impact-on-the-performance-of-the-solution


Networking requirements https://learn.microsoft.com/en-us/ecdn/technical-documentation/network-requirements

Die früher von Microsoft genutzte "Microsoft Stream"-Plattform wurde auch für Live Events genutzt aber ist nicht mehr relevant.


https://learn.microsoft.com/en-us/stream/live-event-overview

Die Referenz für Microsoft 365 Endpunkte in der Cloud werden unter der bekannten URL (https://aka.ms/o365ips) veröffentlicht und für Microsoft Streams sind hier einige URLs hinterlegt.


https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-365-common-and-office-online

Interessant ist, dass die hier nicht die Adresse "*.ecdn.teams.microsoft.com" auftaucht.

Die Adressen haben alle einen "*" und eine Namensauflösung ist erst möglich, wenn wir tatsächlich einen Stream starten. Mehrere Dinge fallen auf:

  • keine RTMP Ports
    Anders als bei Teams nutzen diese Dienste ausschließlich TCP/443. Das ist der kompatibelste Weg, da HTTPS auch über Proxy-Server übertragen werden kann und keine explizite Freigaben durch einen Netzwerkadministrator erforderlich sind. Allerdings wissen wir, dass Audio/Video über TCP oder HTTP im Vergleich zu UDP natürlich empfindlicher auf Paketverlust o.ä. reagiert. Allerdings nutzen auch YouTube und andere Plattformen einfach HTTPS und Puffern die Inhalte. Das ist auch ein Grund für die verzögerte Wiedergabe auf dem Client
  • Hostnamen statt IP-Range
    Anders als bei Teams mit ICE, RTP und VoIP gibt es auch keine IP-Adressrange, sondern nur Hostnamen. Genau genommen sind es sogar nur Domainamen. Microsoft könnte quasi mit Wildcard-Zertifikaten ganz viele physikalische Server oder virtuelle Services bereitstellen. Denkbar wären sogar dynamische Namen wie "<StreamGUID>.microsoftstream.com".

Dennoch sind die Hostnamen natürlich eine elegante und einfache Möglichkeit, diesem Verkehr am Proxy vorbeizuleiten und eine SSL-Inspection zu umgehen. Der Proxy "sieht" ja den SSL-Connect mit dem Hostheader und kann die Daten entsprechend schneller verarbeiten.

Presenter/Producer

Beim Live Event kippt vorne der Producer bzw. Presenter den Videostrom ein und hinten betrachten sehr viele Teilnehmer die Bilder. Sie haben natürlich kaum eine Kontrolle über die Orte und Netzwerkqualität der Betrachter aber eines muss ihnen klar sein:

Wenn die Audio/Video-Daten vom Presenter eine schlechte Qualität (Kamera, Mikrofon aber auch Netzwerk) haben, können die Teilnehmer nur noch schlechter werden.

Es ist also aus Sicht des Netzwerks essentiell, dass der Presenter eine sehr gute Verbindung nutzt. Bei einem Teams Live Event geht es nicht um ein kleines Abteilungsmeeting sondern sie bespielen im schlimmsten Fall tausende Teilnehmer mit einet schlechten Qualität.

Um nun etwas Licht ins Dunkel zu bringen, habe ich ein Live Event geplant und mich als Presenter eingetragen. Den Link zum Event habe ich später bei verschiedenen Teilnehmern verwendet. Schon bei der Planung und späteren Nutzung als  "Producer" muss ich vorgeben, ob ich den Inhalt mit "Teams" oder mit einem externen Encoder erstellen möchte. Bei einem externen Decoder liefere ich selbst einen kompatiblen Stream per TCP. Microsoft schreibt dazu:

External app or device produced live events (formerly external encoder) - RMTP ingest endpoints To get a video feed for an External app or device produced live event sent to Microsoft Stream from your encoder you'll need the following IP ranges and ports open in your network's firewall or proxy: Domains:
*.channel.media.azure.net Ports: 1935/2935/1936/2936 (for RTMP and RTMPS)
...
When producing/streaming a live event via RTMP(S), it’s possible that the internet upload bandwidth at the site pushing the live stream might not be enough. Low upload bandwidth might result in dropped frames or issues in the live video itself which may result in playback issues for viewers.
Quelle: https://support.microsoft.com/en-us/office/troubleshoot-live-events-4f833bfb-0bbb-4a9f-8367-1c0cf2e250c8

Die Ports erscheinen allerdings nicht in den Office 365 IP-Ranges (https://aka.ms/o365ips). Auf ein Setup mit externen Encodern habe hier hier erst einmal verzichtet und nutze Teams selbst als Producer. Ich gehe davon aus, dass dies für viele Firmen auch der erste Start sein wird. Wobei die Anforderungen ans Netzwerk mit einem externen Encoder zumindest hinsichtlich der Ports und des Protokolls "RTMP" gut beschrieben sind.

Single bitrate RTMPS or RTMP
Video format:
  Codec: H.264
  Profile: High (Level 4.0)
  Bitrate: Up to 5 Mbps (5000 kbps)
  Strict Constant Bitrate (CBR)
  Keyframe/GOP: 2 seconds, There must be an IDR frame at the beginning of each GOP
  Frame Rate: 29.97 fps or 30 fps
  Resolution: 1280 x 720 (720P)
  Interlace Mode: Progressive
Audio format
´ Codec: AAC (LC)
  Bitrate: 192 kbps
  Sample Rate: 48 kHz or 44.1 kHz (recommend 48 kHz)

Quelle: Recommended encoder settings https://learn.microsoft.com/en-us/microsoftteams/teams-encoder-configuration#recommended-encoder-settings

Damit kann die Bandbreite mit "bis zu 5 MBit + 192kbit" angegeben werden.

Diese Bandbreite und Erreichbarkeit der Cloud über RTP/UDP ist natürlich nur für den "Presenter" erforderlich.

Teilnehmer

Die Teilnehmer eines LiveEvent/Townhall Meetings bekommen quasi alle den gleichen "Join-Link", der relativ sprechend aufgebaut ist. Die Parameter sind durch URLEncoding (%ea = ":") oder "%22%2C%22 = "," getrennt.

https://teams.microsoft.com/l/meetup-join/19%3ameeting_<BASE64GUIDs>NTc5%40thread.v2/0?
  context=%7B%22Tid%22%3A
  %22<tenantGUID>%22%2C
  %22Oid%22%3A
  %22b39bb717-ea64-46cd-ab57-00186effe82c%22%2C
  %22IsBroadcastMeeting%22%3Atrue%2C
  %22role%22%3A
  %22a%22%7D
  &btype=a
  &role=a

Der Link verweist zwar auf "https://teams.microsoft.com", weil Teams die Plattform ist aber anhand der URL liefert Microsoft dann einen anderen Client aus.

Die relevanten Audio/Video-Daten werden aber per HTTPS übertragen.


Quelle: https://learn.microsoft.com/en-us/microsoftteams/teams-stream-troubleshooting#preparing-your-network-for-many-concurrent-viewers

Interessanterweise ist der Host "bmc.cdn.office.net" nicht auflösbar sondern liefert nur "office.net" als SOA Record.

Also habe ich einen Browser genutzt, um dem Start des Clients und insbesondere des Video-Streams mit dem Chromium-Debugger auf die Finger zu schauen:

Man kann ein "negotiate" erkennen, wo sich der Client mit dem Server über ein Protokoll verständigen und es kommen auch Websocket-Verbindungen zum Einsatz. Wenn dann aber das Liveevent/Townhall Meeting startet, dann sehe ich auf diesem einzelnen Client sehr viele HTTP-GET-Anfragen, die anscheinend lauter kleine Audio/Video-Fragmente laden.

In den Details ist der Request und die Antwort recht gut zu sehen:

Ich habe mir einen Request dann einmal geschnappt und über die PowerShell aufgerufen (zur Lesbarkeit umgebrochen und aufgeteilt).

Invoke-Webrequest `
   -URI ("https://endpoint1-s00prddencompsvc.prd.bmc.cdn.office.net/" `
        +"b1080223-6624-401c-816d-c79e9cbcc912" `
        +"/9fe43086-dcaf-4e4d-bdbb-0bcdcb7598f7.ism" `
        +"/QualityLevels(96000)/Fragments(audio=10848337280,format=mpd-time-csf)")

Der Aufruf wird mit einem "200OK" und ca. 22kByte Nutzdaten quittiert, die ich natürlich nicht interpretieren kann.

Hinweis:
Das Meeting habe ich im September 2023 geplant und abgehalten. Aber selbst ende Dezember 2023 war die URL noch weiterhin aufrufbar.

Die Funktionsweise passt genau auf die Beschreibung von Microsoft hinsichtlich HTTP-Unicast.


Quelle: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/introducing-microsoft-ecdn-for-a-new-era-of-communications/ba-p/3615306

Damit stellt sich natürlich die Frage, ob ein HTTP-Proxy hier auch unterstützen kann. Darauf gehe ich auf der Seite Teams AV-Proxycaching weiter ein.

All peers are connected to Microsoft eCDN's network and coordinator (tracker). Microsoft eCDN builds a map of the network and understands which peers are located next to each other (from a network perspective) and decides how to build the peering network.
Quelle: How do user devices discover each other? https://learn.microsoft.com/en-us/ecdn/troubleshooting/faq#how-do-user-devices-discover-each-other

ECND Teilnehmer

Für Live Events und Townhall Meetings gibt es von Microsoft gegen Einwurf zusätzlicher Münzen eine ECDN-Lizenz. Damit soll das Problem der hohen Bandbreite an Firmenstandorten elegant über ein P2P-Verbundnetzwerk zwischen Clients gelöst werden: 


Quelle: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/introducing-microsoft-ecdn-for-a-new-era-of-communications/ba-p/3615306

Um die Funktion zu testen, stellt Microsoft extra einen ECDN-Tester im Browser unter folgender URL bereit

ECND Tester
https://aka.ms/ecdn/tester

Sie müssen den Links auf mindestens zwei Browsern starten. Auf dem gleichen Computer geht dies auch aber sinnvoll ist es natürlich auf mehreren Clients in ihrem Netzwerk. Der ECDN-Tester spielt dann ein das Video "Big Buck Bunny" (https://peach.blender.org/download/) ab, welches 2008 die Fähigkeiten der Software "Blender" demonstriert und als "Peach open movie project" unter der "Creative Commons Attribution 3.0 license" lizenziert wird.

Interessant ist hier zu sehen, ob das Microsoft eCDN in ihrem Netzwerk funktioniert und die Clients miteinander eine Verbindung aufbauen und Daten quasi "quer" übertragen können. Auch hier werden per HTTPS mit der Cloud diverse Verwaltungsinformationen ausgetauscht:

Die Details zeigen aber nicht viel verwertbare Informationen:

Interessanter wird die Anzeige der WebRTC Internals über die entsprechende Diagnoseseite

chrome://webrtc-internals

Hier sehen Sie dann die verschiedenen Kandidaten des RTP-Clients und statistische Werte:

Leider ist hier nicht zu erkennen, woran Microsoft z.B. erkennt, welche Clients im gleichen LAN sind. Auf der einen Seite könnte Microsoft natürlich die "Public-IP" der verschiedenen Clients bewerten. Alle Clients im gleichen Standorte werden vermutlich über die gleiche öffentliche IP-Adresse nach extern kommunizieren. Wobei größere Standorte auch gerne mal mehrere IP-Adressen oder unterschiedliche redundante Provider verwenden. Zudem gibt es immer noch Firmen, bei denen Niederlassungen keinen eigenen Breakout haben oder Cloud-Proxy-Server (Zscaler, Umbrella etc.) verwenden.

Letztlich müssen wir darauf vertrauen, dass Microsoft eCDN irgendwie ausreichen zuverlässig herausfindet, welche Clients als Gruppe ein eCDN bilden können.

Sie können übrigens hier natürlich eingreifen, indem Sie die direkte Verbindung zwischen Clients unterbinden oder reglementieren. Speziell in sensiblen Bereichen (Medizin, Finanzen, Banken, Versicherungen, Rüstung) habe ich es auch erlebt, dass P2P-Verkehr generell unterbunden ist oder nur für bestimmte Prozesse erlaubt wird.

Andere Lösungen

Vielleicht müssen sie ja gar nicht mit den Teams-Bordmitteln arbeiten. Mittlerweile können Sie über NDI und andere Optionen ihre Besprechung zwar klassisch in Microsoft Teams abhalten aber den Audio/Video-Stream relativ problemlos per RTMP z.B. an LinkedIn, YouTube oder andere Stream-Plattformen weiter geben. Sie könnten sogar in ihrem eigenen LAN einen entsprechenden RTMP-Service betreiben und damit zumindest alle internen Mitarbeiter über diesen Weg mit Bild und Ton versorgen.

Weitere Links