Microsoft Teams-Anrufflüsse
Tipp
Sehen Sie sich diese Sitzung an, um zu erfahren, wie Teams Ihr Netzwerk nutzt und wie Sie eine optimale Netzwerkkonnektivität planen: Teams-Netzwerkplanung.
Übersicht
In diesem Artikel wird beschrieben, wie Teams Microsoft 365-Anrufflows in verschiedenen Topologien verwendet. Darüber hinaus werden eindeutige Teams-Flows beschrieben, die für die Peer-to-Peer-Medienkommunikation verwendet werden. Das Dokument beschreibt diese Flows, ihren Zweck sowie ihren Ursprung und ihre Beendigung im Netzwerk. Gehen Sie für die Zwecke dieses Artikels von Folgendem aus:
Flow X wird vom lokalen Client verwendet, um mit dem Microsoft 365-Dienst in der Cloud zu kommunizieren. Er stammt aus dem Kundennetzwerk und endet als Endpunkt in Microsoft 365.
Flow Y wird vom lokalen Client verwendet, um mit einem Dienst im Internet zu kommunizieren, von dem Microsoft 365 abhängig ist. Er stammt aus dem Kundennetzwerk und endet als Endpunkt im Internet.
In diesem Artikel werden die folgenden Informationen behandelt:
Hintergrund. Stellt Hintergrundinformationen bereit, z. B. Netzwerke, die die Flows durchlaufen können, Arten von Datenverkehr und Konnektivitätsleitfaden vom Kundennetzwerk zu Microsoft 365-Dienstendpunkten. Außerdem werden die Interoperabilität mit Komponenten von Drittanbietern und Prinzipien beschrieben, die von Teams zum Auswählen von Medienflüssen verwendet werden.
Aufrufflows in verschiedenen Topologien. Veranschaulicht die Verwendung von Aufrufflüssen in verschiedenen Topologien. Für jede Topologie listet der Abschnitt alle unterstützten Flows auf und veranschaulicht, wie diese Flows in mehreren Anwendungsfällen verwendet werden. Für jeden Anwendungsfall wird die Reihenfolge und Auswahl der Datenflüsse mithilfe eines Flussdiagramms beschrieben.
Teams mit ExpressRoute-Optimierung. Beschreibt, wie diese Flows verwendet werden, wenn Express Route zur Optimierung bereitgestellt wird. Dies wird mithilfe einer einfachen Topologie veranschaulicht.
Hintergrund
Netzwerksegmente
Kundennetzwerk. Das Netzwerksegment, das Sie steuern und verwalten. Dieses Segment umfasst alle Kundenverbindungen innerhalb von Kundenbüros, ob kabelgebunden oder drahtlos, Verbindungen zwischen Bürogebäuden, Verbindungen mit lokalen Rechenzentren und Ihre Verbindungen mit Internetanbietern, ExpressRoute oder einem anderen privaten Peering.
In der Regel verfügt ein Kundennetzwerk über mehrere Netzwerkperimeter mit Firewalls und/oder Proxyservern, die die Sicherheitsrichtlinien Ihrer organization erzwingen und nur bestimmten Netzwerkdatenverkehr zulassen, den Sie einrichten und konfigurieren. Da Sie dieses Netzwerk verwalten, haben Sie direkte Kontrolle über die Leistung des Netzwerks. Es wird empfohlen, Netzwerkbewertungen durchzuführen, um die Leistung sowohl an Standorten in Ihrem Netzwerk als auch von Ihrem Netzwerk bis zum Microsoft 365-Netzwerk zu überprüfen.
Internet. Das Netzwerksegment, das Teil Ihres Gesamtnetzwerks ist und von Benutzern verwendet wird, die von außerhalb des Kundennetzwerks eine Verbindung mit Microsoft 365 herstellen. Dieses Segment wird auch von einigem Datenverkehr aus dem Kundennetzwerk zu Microsoft 365 verwendet.
Besuchtes oder privates Gastnetzwerk. Das Netzwerksegment außerhalb Ihres Kundennetzwerks, aber nicht im öffentlichen Internet, das Ihre Benutzer und deren Gäste besuchen können. Beispielsweise ein privates Privates Netzwerk oder ein privates Unternehmensnetzwerk, das Teams nicht bereitstellt, in dem sich Ihre Benutzer und ihre Kunden befinden können, die mit Teams-Diensten interagieren.
Hinweis
Die Konnektivität mit Microsoft 365 gilt auch für diese Netzwerke.
Microsoft 365. Das Netzwerksegment, das Microsoft 365-Dienste unterstützt. Es wird weltweit mit Edges in der Nähe des Kundennetzwerks an den meisten Standorten verteilt. Zu den Funktionen gehören Transport Relay, Konferenzserver und Medienprozessor.
ExpressRoute (optional). Das Netzwerksegment, das Teil Ihres gesamten Netzwerks ist und Ihnen eine dedizierte, private Verbindung mit dem Microsoft 365-Netzwerk bietet.
Arten von Datenverkehr
Echtzeitmedien. Daten, die im Echtzeit-Transportprotokoll (Real-time Transport Protocol, RTP) gekapselt sind, das Audio-, Video- und Bildschirmfreigabeworkloads unterstützt. Im Allgemeinen ist der Mediendatenverkehr sehr latenzempfindlich. Sie möchten, dass dieser Datenverkehr den direktesten Pfad einnimmt und UDP im Vergleich zu TCP als Transportschichtprotokoll verwendet, was aus Qualitätssicht der beste Transport für interaktive Echtzeitmedien ist. (Beachten Sie, dass Medien als letztes Mittel TCP/IP verwenden und auch innerhalb des HTTP-Protokolls getunnelt werden können, dies wird jedoch aufgrund von Auswirkungen auf schlechte Qualität nicht empfohlen.) Der RTP-Fluss wird mithilfe von SRTP gesichert, bei dem nur die Nutzlast verschlüsselt wird.
Signalisierung. Die Kommunikationsverbindung zwischen Client und Server oder anderen Clients, die zum Steuern von Aktivitäten verwendet werden (z. B. wenn ein Anruf initiiert wird) und Chatnachrichten zu übermitteln. Der meiste Signaldatenverkehr verwendet die HTTPS-basierten REST-Schnittstellen, obwohl in einigen Szenarien (z. B. bei der Verbindung zwischen Microsoft 365 und einem Session Border Controller) das SIP-Protokoll verwendet wird. Es ist wichtig zu verstehen, dass dieser Datenverkehr viel weniger latenzempfindlich ist, aber zu Dienstausfällen oder Anruftimeouts führen kann, wenn die Latenz zwischen den Endpunkten mehrere Sekunden überschreitet.
Konnektivität mit Microsoft 365
Teams erfordert eine Verbindung mit dem Internet. Teams-Endpunkt-URLs und IP-Adressbereiche sind unter Office 365 URLs und IP-Adressbereiche aufgeführt. Eine offene Verbindung mit den TCP-Ports 80 und 443 sowie zu den UDP-Ports 3478 (STUN), 3479 (Audio), 3480 (Video) und 3481 (Freigabe/VBSS) ist erforderlich.
Die Konnektivität von Teams-Medienflüssen wird mithilfe von IETF Interactive Connectivity Establishment (ICE)-Standardverfahren implementiert.
Interoperabilitätseinschränkungen
Medienrelays von Drittanbietern. Ein Teams-Medienfluss (d. h. einer der Medienendpunkte ist Teams) kann nur Teams oder Skype for Business nativen Medienrelays durchlaufen. Die Interoperabilität mit einem Medienrelay eines Drittanbieters wird nicht unterstützt. (Ein Drittanbieter-SBC an der Grenze zu PSTN muss den RTP/RTCP-Stream beenden, der mit SRTP gesichert ist, und ihn nicht an den nächsten Hop weiterleiten.)
SIP-Proxyserver von Drittanbietern. Ein Teams-SIGNAL-SIP-Dialog mit einem SBC und/oder Gateway eines Drittanbieters kann Teams oder Skype for Business nativen SIP-Proxys durchlaufen. Die Interoperabilität mit einem SIP-Proxy eines Drittanbieters wird nicht unterstützt.
B2BUA (oder SBC) eines Drittanbieters. Ein Teams-Medienfluss zum und vom PSTN wird von einem SBC eines Drittanbieters beendet. Die Interoperabilität mit einem Drittanbieter-SBC innerhalb des Teams-Netzwerks (bei dem ein SBC eines Drittanbieters zwei Teams- oder Skype for Business-Endpunkte vermittelt) wird jedoch nicht unterstützt.
Technologien, die für Microsoft Teams nicht empfohlen werden
VPN-Netzwerk. Dies wird nicht für Mediendatenverkehr (oder Flow 2' empfohlen). Der VPN-Client sollte geteiltes Tunneling verwenden und Teams-Mediendatenverkehr wie alle externen Nicht-VPN-Benutzer weiterleiten, wie in Aktivieren von Lync-Medien zum Umgehen eines VPN-Tunnels angegeben.
Hinweis
Obwohl der Titel Lync angibt, gilt er auch für Teams.
Paketformer. Jede Art von Paketsnipper, Paketüberprüfung oder Paket-Shaper-Geräten wird für Den Teams-Mediendatenverkehr nicht empfohlen und kann die Qualität erheblich beeinträchtigen.
Grundsätze
Es gibt vier allgemeine Prinzipien, die Ihnen helfen, Anrufabläufe für Microsoft Teams zu verstehen:
Eine Microsoft Teams-Konferenz wird von Microsoft 365 in derselben Region gehostet, in der der erste Teilnehmer beigetreten ist. (Wenn in einigen Topologien Ausnahmen von dieser Regel vorhanden sind, werden diese in diesem Dokument beschrieben und durch einen entsprechenden Aufruffluss veranschaulicht.)
Ein Teams-Medienendpunkt in Microsoft 365 wird basierend auf den Anforderungen an die Medienverarbeitung und nicht basierend auf der Anrufart verwendet. (Beispielsweise kann ein Punkt-zu-Punkt-Anruf einen Medienendpunkt in der Cloud verwenden, um Medien für die Transkription oder Aufzeichnung zu verarbeiten, während eine Konferenz mit zwei Teilnehmern keinen Medienendpunkt in der Cloud verwenden darf.) Die meisten Konferenzen verwenden jedoch einen Medienendpunkt zum Mischen und Routing, der an dem Ort zugeordnet ist, an dem die Konferenz gehostet wird. Der Mediendatenverkehr, der von einem Client an den Medienendpunkt gesendet wird, kann direkt weitergeleitet werden oder ein Transport Relay in Microsoft 365 verwenden, wenn dies aufgrund von Netzwerkfirewalleinschränkungen des Kunden erforderlich ist.
Der Mediendatenverkehr für Peer-to-Peer-Anrufe nimmt die direkteste verfügbare Route an, vorausgesetzt, der Anruf erfordert keinen Medienendpunkt in der Cloud (siehe vorheriges Prinzip). Die bevorzugte Route ist direkt an den Remotepeer (Client), aber wenn diese Route nicht verfügbar ist, leitet mindestens ein Transportrelay den Datenverkehr weiter. Es wird empfohlen, dass der Mediendatenverkehr keine Server wie Paket-Shaper, VPN-Server usw. durchquert, da sich dies auf die Medienqualität auswirkt.
Der Signalisierungsverkehr wird immer an den Server gesendet, der dem Benutzer am nächsten ist.
Weitere Informationen zu den Details zum ausgewählten Medienpfad finden Sie unter Grundlegendes zu Medienflüssen in Microsoft Teams – BRK4016.
Aufrufflows in verschiedenen Topologien
Teams-Topologie
Diese Topologie wird von Kunden verwendet, die Teams-Dienste aus der Cloud ohne lokale Bereitstellung nutzen, z. B. Skype for Business Server oder Telefonsystem direct Routing. Darüber hinaus erfolgt die Schnittstelle zu Microsoft 365 über das Internet ohne Azure Express Route.
Abbildung 1: Teams-Topologie
Berücksichtigen Sie dabei Folgendes:
- Die Richtung der Pfeile im Diagramm spiegelt die Initiierungsrichtung der Kommunikation wider, die sich auf die Konnektivität in den Unternehmensperimetern auswirkt. Für UDP für Medien können die ersten Pakete in umgekehrter Richtung fließen, aber diese Pakete können blockiert werden, bis Pakete in der anderen Richtung fließen.
- Teams wird parallel zu Skype for Business Online bereitgestellt, sodass Clients als "Teams/SFB-Benutzer" angezeigt werden.
Weitere Informationen zu den folgenden optionalen Topologien finden Sie weiter unten in diesem Artikel:
- Skype for Business lokale Bereitstellung wird unter Teams-Hybridtopologie beschrieben.
- Telefonsystem Direct Routing (für PSTN-Konnektivität) wird unter Teams mit Direct Routing-Topologie beschrieben.
- ExpressRoute wird in Teams mit ExpressRoute-Optimierung beschrieben.
Flussbeschreibungen:
- Flow 2 – Stellt einen Von einem Benutzer im Kundennetzwerk initiierten Flow zum Internet als Teil der Teams-Erfahrung des Benutzers dar. Beispiele für diese Flows sind DNS- und Peer-to-Peer-Medien.
- Flow 2' – Stellt einen Flow dar, der von einem mobilen Teams-Remotebenutzer mit VPN zum Kundennetzwerk initiiert wurde.
- Flow 3 : Stellt einen Flow dar, der von einem mobilen Teams-Remotebenutzer zu Microsoft 365 Teams-Endpunkten initiiert wurde.
- Flow 4 : Stellt einen von einem Benutzer im Kundennetzwerk initiierten Flow zu Microsoft 365 Teams-Endpunkten dar.
- Flow 5 – Stellt einen Peer-to-Peer-Medienfluss zwischen einem Teams-Benutzer und einem anderen Teams- oder Skype for Business-Benutzer innerhalb des Kundennetzwerks dar.
- Flow 6 – Stellt einen Peer-to-Peer-Medienfluss zwischen einem mobilen Teams-Remotebenutzer und einem anderen mobilen Teams- oder Skype for Business-Benutzer über das Internet dar.
Anwendungsfall: 1:1
1:1-Anrufe verwenden ein allgemeines Modell, bei dem der Aufrufer eine Reihe von Kandidaten erhält, die aus IP-Adressen/Ports bestehen, einschließlich lokaler, Relay- und reflexiver Kandidaten (öffentliche IP-Adresse des Clients, wie vom Relay gesehen). Der Anrufer sendet diese Kandidaten an die angerufene Partei; die angerufene Partei erhält auch eine ähnliche Gruppe von Kandidaten und sendet sie an den Anrufer. StuN-Konnektivitätsüberprüfungsmeldungen werden verwendet, um zu ermitteln, welche Aufrufer-/Aufgerufenen-Medienpfade funktionieren, und der beste Arbeitspfad wird ausgewählt. Medien (d. h. RTP/RTCP-Pakete, die mit SRTP gesichert sind) werden dann mithilfe des ausgewählten Kandidatenpaars gesendet. Das Transportrelay wird als Teil von Microsoft 365 bereitgestellt.
Wenn die lokalen IP-Adress-/Portkandidaten oder die reflexiven Kandidaten über Konnektivität verfügen, wird der direkte Pfad zwischen den Clients (oder der Verwendung einer NAT) für Medien ausgewählt. Wenn sich beide Clients im Kundennetzwerk befinden, sollte der direkte Pfad ausgewählt werden. Dies erfordert direkte UDP-Konnektivität innerhalb des Kundennetzwerks. Wenn die Clients beide nomadische Cloudbenutzer sind, können Medien je nach NAT/Firewall direkte Konnektivität verwenden.
Wenn sich ein Client intern im Kundennetzwerk befindet und ein Client extern ist (z. B. ein Benutzer der mobilen Cloud), ist es unwahrscheinlich, dass die direkte Konnektivität zwischen den lokalen oder reflexiven Kandidaten funktioniert. In diesem Fall besteht eine Option darin, einen der Transport relay-Kandidaten von beiden Clients zu verwenden (z. B. hat der interne Client einen Relaykandidaten vom Transportrelay in Microsoft 365 abgerufen; der externe Client muss in der Lage sein, STUN/RTP/RTCP-Pakete an das Transportrelay zu senden). Eine weitere Option ist der interne Client, der an den Relaykandidaten sendet, der vom mobilen Cloudclient abgerufen wurde. Obwohl UDP-Konnektivität für Medien dringend empfohlen wird, wird TCP unterstützt.
Allgemeine Schritte:
- Teams-Benutzer A löst den URL-Domänennamen (DNS) mithilfe von Flow 2 auf.
- Teams-Benutzer A weist mithilfe von Flow 4 einen Medienrelayport auf Teams-Transportrelay zu.
- Teams-Benutzer A sendet "Einladung" mit ICE-Kandidaten mithilfe von Flow 4 an Microsoft 365.
- Microsoft 365 sendet mithilfe von Flow 4 Benachrichtigungen an Teams-Benutzer B.
- Teams-Benutzer B weist mithilfe von Flow 4 einen Medienrelayport auf Teams-Transportrelay zu.
- Teams-Benutzer B sendet "Antwort" mit ICE-Kandidaten mithilfe von Flow 4, der mithilfe von Flow 4 zurück an Teams-Benutzer A weitergeleitet wird.
- Teams-Benutzer A und Teams-Benutzer B rufen ICE-Konnektivitätstests auf, und der beste verfügbare Medienpfad ist ausgewählt (siehe die folgenden Diagramme für verschiedene Anwendungsfälle).
- Teams-Benutzer senden Telemetriedaten mithilfe von Flow 4 an Microsoft 365.
Innerhalb des Kundennetzwerks:
Abbildung 2 : Innerhalb des Kundennetzwerks
In Schritt 7 ist Peer-to-Peer-Medienfluss 5 ausgewählt.
Medien sind bidirektional. Die Richtung von Flow 5 gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert, die mit allen Flows in diesem Dokument konsistent ist. In diesem Fall spielt es keine Rolle, welche Richtung verwendet wird, da sich beide Endpunkte innerhalb des Kundennetzwerks befinden.
Kundennetzwerk für externe Benutzer (Medien, die von Teams Transport Relay weitergeleitet werden):
Abbildung 3: Kundennetzwerk zu externen Benutzern (Medien, die von Teams Transport Relay weitergeleitet werden)
In Schritt 7 werden Flow 4 vom Kundennetzwerk zu Microsoft 365 und Flow 3 vom mobilen Teams-Remotebenutzer zu Microsoft 365 ausgewählt. Diese Flows werden von Teams Transport Relay in Microsoft 365 weitergeleitet.
Medien sind bidirektional, wobei die Richtung angibt, welche Seite die Kommunikation aus Konnektivitätsperspektive initiiert. In diesem Fall werden diese Flows für Signalisierung und Medien mit unterschiedlichen Transportprotokollen und Adressen verwendet.
Kundennetzwerk zu externem Benutzer (direkte Medien):
Abbildung 4: Kundennetzwerk zu externem Benutzer (direkte Medien)
In Schritt 7 ist Flow 2 vom Kundennetzwerk zum Internet (Peer des Clients) ausgewählt.
Direkte Medien mit mobilen Remotebenutzern (nicht über Microsoft 365 weitergeleitet) sind optional. Anders ausgedrückt: Der Kunde kann diesen Pfad blockieren, um einen Medienpfad über Transport Relay in Microsoft 365 zu erzwingen.
Medien sind bidirektional. Die Richtung von Flow 2 für mobile Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.
VPN-Benutzer zu internem Benutzer (Medien, die von Teams-Transportrelay weitergeleitet werden)
Abbildung 5: VPN-Benutzer zu internem Benutzer (Medien, die von Teams Transport Relay weitergeleitet werden)
Für die Signalisierung zwischen dem VPN und dem Kundennetzwerk wird Flow 2' verwendet. Für die Signalisierung zwischen dem Kundennetzwerk und Microsoft 365 wird Flow 4 verwendet. Medien umgehen jedoch das VPN und werden mithilfe der Flows 3 und 4 über das Teams-Medienrelay in Microsoft 365 weitergeleitet.
VPN-Benutzer zu internem Benutzer (direkte Medien)
Abbildung 6: VPN-Benutzer zu internem Benutzer (direkte Medien)
Für die Signalisierung zwischen dem VPN und dem Kundennetzwerk wird Flow 2' verwendet. Für die Signalisierung zwischen dem Kundennetzwerk und Microsoft 365 wird Flow 4 verwendet. Medien umgehen jedoch das VPN und werden mithilfe von Flow 2 vom Kundennetzwerk an das Internet weitergeleitet.
Medien sind bidirektional. Die Richtung von Flow 2 an den mobilen Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.
VPN-Benutzer zu externem Benutzer (direkte Medien)
Abbildung 7: VPN-Benutzer zu externem Benutzer (direkte Medien)
Die Signalisierung zwischen dem VPN-Benutzer an das Kundennetzwerk erfolgt mithilfe von Flow 2' und mithilfe von Flow 4 an Microsoft 365. Medien umgehen jedoch VPN und werden mithilfe von Flow 6 weitergeleitet.
Medien sind bidirektional. Die Richtung von Flow 6 an den mobilen Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.
Anwendungsfall: Teams zu PSTN über Microsoft 365 Trunk
Microsoft 365 verfügt über ein Telefonsystem, das das Tätigen und Empfangen von Anrufen aus dem PstN (Public Switched Telephone Network) ermöglicht. Wenn der PSTN-Trunk über den Telefonsystemanrufplan verbunden ist, gibt es für diesen Anwendungsfall keine besonderen Konnektivitätsanforderungen. (Wenn Sie Ihren eigenen lokalen PSTN-Trunk mit Microsoft 365 verbinden möchten, können Sie Direct Routing des Telefonsystems verwenden.)
Abbildung 8: Teams zu PSTN über Microsoft 365 Trunk
Anwendungsfall: Teams-Besprechung
Der VBSS-Konferenzserver (Audio/Video/Bildschirmfreigabe) ist Teil von Microsoft 365. Es verfügt über eine öffentliche IP-Adresse, die über das Kundennetzwerk erreichbar sein muss und über einen Nomadic Cloud-Client erreichbar sein muss. Jeder Client/Endpunkt muss in der Lage sein, eine Verbindung mit dem Konferenzserver herzustellen.
Interne Clients erhalten lokale, reflexive und Relaykandidaten auf die gleiche Weise wie für 1:1-Anrufe beschrieben. Die Clients senden diese Kandidaten in einer Einladung an den Konferenzserver. Der Konferenzserver verwendet kein Relay, da er über eine öffentlich erreichbare IP-Adresse verfügt, sodass er mit seinem lokalen IP-Adresskandidaten antwortet. Der Client und der Konferenzserver überprüfen die Konnektivität auf die gleiche Weise, die für 1:1-Anrufe beschrieben wird.
Berücksichtigen Sie dabei Folgendes:
Teams-Clients können nicht an Skype for Business Besprechungen teilnehmen, und Skype for Business Clients können nicht an Teams-Besprechungen teilnehmen.
Ein PSTN-Benutzer, der je nach Bereitstellung des Organisators von PSTN-Anrufen und/oder Konferenzen der Besprechung optional "Dials IN" oder "Dialed OUT" ist.
Ein Gast oder ein Kunde kann über ein privates Gastnetzwerk beitreten, das mit FW/NAT mit strengen Regeln geschützt ist.
Abbildung 9: Teams-Besprechung
Anwendungsfall: Verbund mit Skype for Business lokal
Medien, die von Teams Transport Relay in Microsoft 365 weitergeleitet werden
Abbildung 10: Medienübertragung durch Teams Transport Relay in Microsoft 365
Berücksichtigen Sie dabei Folgendes:
Der Verbund ist per Definition eine Kommunikation zwischen zwei Mandanten. In diesem Fall wird Mandant A, der Teams verwendet, mit Mandant B verbunden, der Skype for Business lokal verwendet. Wenn Mandant B auch Microsoft 365 verwendet, hätte der Skype for Business Client Flow 3 verwendet, um eine Verbindung mit Microsoft 365 herzustellen.
Signalisierung und Medien vom Skype for Business-Verbundclient an lokale Skype for Business Server werden in diesem Dokument nicht behandelt. Es wird jedoch hier aus Gründen der Übersichtlichkeit veranschaulicht.
Die Signalisierung zwischen Teams und Skype for Business wird durch ein Gateway überbrückt.
Medien werden in diesem Fall von Teams Transport Relay mithilfe von Flow 4 an das Kundennetzwerk und remote Skype for Business Client weitergeleitet.
Medien, die von Skype for Business Media Relay im Verbundmandanten weitergeleitet werden
Abbildung 11: Medien, die von Skype for Business Media Relay im Verbundmandanten weitergeleitet werden
Beachten Sie Folgendes:
Signalisierung und Medien vom Skype for Business-Verbundclient an eine lokale Skype for Business Server werden in diesem Dokument nicht behandelt. Es wird jedoch hier aus Gründen der Übersichtlichkeit veranschaulicht.
Die Signalisierung zwischen Teams und Skype for Business wird durch ein Gateway überbrückt.
Medien werden in diesem Fall von Skype for Business lokalen Media Relay mithilfe von Flow 2 an das Kundennetzwerk weitergeleitet. (Beachten Sie, dass Datenverkehr vom Teams-Benutzer zum Remote-Media Relay im Verbundkundennetzwerk zunächst vom Media Relay blockiert wird, bis der Datenverkehr in umgekehrter Richtung fließt. Der bidirektionale Fluss öffnet jedoch die Konnektivität in beide Richtungen.)
Direkt (Peer-to-Peer)
Abbildung 12 : Direkt (Peer-to-Peer)
Teams-Hybridtopologie
Diese Topologie umfasst Teams mit einer Skype for Business lokalen Bereitstellung.
Abbildung 13 : Teams-Hybridtopologie
Die Richtung der Pfeile im obigen Diagramm spiegelt die Initiierungsrichtung der Kommunikation wider, die sich auf die Konnektivität in den Unternehmensperimetern auswirkt. Im Fall von UDP für Medien können die ersten Pakete in umgekehrter Richtung fließen, aber diese Pakete können blockiert werden, bis Pakete in die andere Richtung fließen.
Teams wird parallel zu Skype for Business Online bereitgestellt, sodass Clients als "Teams/SFB-Benutzer" angezeigt werden.
Zusätzlicher Flow (zusätzlich zur Teams-Topologie):
- Flow 5A: Stellt einen Peer-to-Peer-Medienfluss zwischen einem Teams-Benutzer innerhalb des Kundennetzwerks und einem Skype for Business lokalen Medienrelays am Edge des Kundennetzwerks dar.
Anwendungsfall: Teams Skype for Business 1:1
Hybrid innerhalb des Kundennetzwerks
Abbildung 14 : Hybrid innerhalb des Kundennetzwerks
Die Signalisierung zwischen Teams und Skype for Business wird durch ein Gateway überbrückt. Medien werden jedoch mithilfe von Flow 5 direkt peer-to-peer innerhalb des Kundennetzwerks weitergeleitet.
Hybrides Kundennetzwerk mit externem Skype for Business Benutzer – weitergeleitet von Microsoft 365
Abbildung 15: Hybrides Kundennetzwerk mit externem Skype for Business Benutzer – weitergeleitet von Microsoft 365
Beachten Sie Folgendes:
Die Signalisierung und Medien vom Skype for Business Client an eine lokale Skype for Business Server liegt außerhalb des Geltungsbereichs dieses Dokuments. Es wird jedoch hier der Übersichtlichkeit halber veranschaulicht.
Die Signalisierung zwischen Teams und Skype for Business wird durch ein Gateway überbrückt.
Medien werden über Das Teams-Transportrelay über Flow 4 an das Kundennetzwerk weitergeleitet.
Hybrides Kundennetzwerk mit externem Skype for Business Benutzer – relayed by on-premises Edge
Abbildung 16: Hybrides Kundennetzwerk mit externem Skype for Business-Benutzer – relayed by on-premises Edge
Beachten Sie Folgendes:
Die Signalisierung und Medien von Skype for Business Client an eine lokale Skype for Business Server werden in diesem Dokument nicht behandelt. Es wird jedoch hier der Übersichtlichkeit halber veranschaulicht.
Die Signalisierung wird durch ein Gateway überbrückt.
Medien werden von Skype for Business Media Relay innerhalb Skype for Business lokalen Edges mithilfe des Medienflusses 5A an teams-Benutzer innerhalb des Kundennetzwerks weitergeleitet.
Teams mit Telefonsystem-Direct Routing-Topologie
Diese Topologie umfasst Teams mit Telefonsystem Direct Routing.
Mit Direct Routing können Sie einen PstN-Dienstanbieter (Public Switched Telephone Network) eines Drittanbieters verwenden, indem Sie ein unterstütztes, kundeneigenes SBC-Hardwaregerät (Session Border Controller) mit Microsoft 365 koppeln und dann den Telefonie-Trunk mit diesem Gerät verbinden.
Zur Unterstützung dieses Szenarios muss der Kunde einen zertifizierten SBC für Direct Routing von einem der zertifizierten Microsoft-Partner bereitstellen. Der SBC muss wie vom Anbieter empfohlen konfiguriert werden und von Microsoft 365 für direkten UDP-Datenverkehr routingfähig sein. Die Medien können direkt von Teams und/oder dem Skype for Business Client an den SBC fließen (um das Teams-Gateway umgehen) oder das Teams-Gateway durchlaufen. Die Konnektivität mit dem SBC basiert, wenn der Trunk für die Umgehung des Teams-Gateways konfiguriert ist, auf ICE, wobei SBC ICE-Lite unterstützt, während der Teams/Skype for Business-Medienendpunkt ICE Full Form unterstützt.
*Abbildung 17 – Teams mit Telefonsystem-Direct Routing-Topologie
Beachten Sie Folgendes:
Die Richtung der Pfeile im obigen Diagramm spiegelt die Initiierungsrichtung der Kommunikation wider, die sich auf die Konnektivität in den Unternehmensperimetern auswirkt. Im Fall von UDP für Medien können die ersten Pakete in umgekehrter Richtung fließen, aber diese Pakete können blockiert werden, bis Pakete in die andere Richtung fließen.
Teams wird parallel zu Skype for Business Online bereitgestellt, sodass Clients als "Teams/SFB-Benutzer" angezeigt werden.
Zusätzliche Flows (zusätzlich zur Teams-Onlinetopologie):
- Flow 4' – Stellt einen Flow von Microsoft 365 zum Kundennetzwerk dar, der verwendet wird, um eine Verbindung zwischen dem Teams-Medienserver in der Cloud und dem lokalen SBC herzustellen.
- Flow 5B : Stellt einen Medienfluss zwischen dem Teams-Benutzer innerhalb des Kundennetzwerks mit dem Direct Routing-SBC im Umgehungsmodus dar.
- Flow 5C : Stellt einen Medienfluss zwischen dem Direct Routing SBC zu einem anderen Direct Routing SBC in einem PSTN-Anrufumgehungsmodus dar.
Interner Benutzer mit Direct Routing (Medien relayed by Teams Transport Relay)
Abbildung 18: Interner Benutzer mit Direct Routing (Medienweiterleitung durch Teams-Transportrelay)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 routingfähig ist.
Signalisierung und Medien vom SBC an Microsoft 365 und umgekehrt verwenden Flow 4 und/oder Flow 4'.
Signalisierung und Medien vom Client innerhalb des Kundennetzwerks an Microsoft 365 verwenden Flow 4.
Remotebenutzer mit Direct Routing (Medien werden über einen Medienserver (MP) weitergeleitet)
Abbildung 19: Remotebenutzer mit Direct Routing (Medien werden über einen Medienserver (MP) weitergeleitet)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 routingfähig ist.
Signalisierung und Medien vom SBC an Microsoft 365 und umgekehrt verwenden Flow 4 und/oder Flow 4'.
Signalisierung und Medien vom Client im Internet an Microsoft 365 verwenden Flow 3.
Internes Benutzer-Direct Routing (Medienumgehung)
Abbildung 20: Internes Benutzer-Direct Routing (Medienumgehung)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 routingfähig ist.
Für die Signalisierung von SBC zu Microsoft 365 und umgekehrt wird Flow 4 und/oder Flow 4 verwendet.
Für die Signalisierung vom Client innerhalb des Kundennetzwerks an Microsoft 365 wird Flow 4 verwendet.
Medien vom Client innerhalb des Kundennetzwerks zu SBC innerhalb des Kundennetzwerks verwenden Flow 5B.
Remotebenutzer mit Direct Routing (Medienumgehung, die von Teams-Transportrelay weitergeleitet wird)
Abbildung 21: Remotebenutzer mit Direct Routing (Medienumgehung durch Teams Transport Relay)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 und dem Internet routingfähig ist.
Die Signalisierung vom SBC an Microsoft 365 und umgekehrt verwendet Flow 4 und/oder Flow 4'.
Für die Signalisierung vom Client im Internet an Microsoft 365 wird Flow 3 verwendet.
Medien vom Client im Internet an den SBC innerhalb des Kundennetzwerks verwenden die Datenflüsse 3 und 4, die von Teams Transport Relay weitergeleitet werden.
Direct Routing für Remotebenutzer (Direkte Medienumgehung)
Abbildung 22: Direktes Remotebenutzerrouting (direkte Medienumgehung)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 und dem Internet routingfähig ist.
Die Signalisierung vom SBC an Microsoft 365 und umgekehrt verwendet Flow 4 und/oder Flow 4'.
Für die Signalisierung vom Client im Internet an Microsoft 365 wird Flow 3 verwendet.
Medien vom Client im Internet an den SBC innerhalb des Kundennetzwerks verwenden Flow 2.
Direct Routing (Medienumgehung) – PSTN-Haarnadelanruf (aufgrund von Anrufweiterleitung/-übertragung)
Abbildung 23: Direct Routing (Medienumgehung) – PSTN-Haarnadelanruf (aufgrund von Anrufweiterleitung/-übertragung)
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 routingfähig ist.
Die Signalisierung vom SBC an Microsoft 365 und umgekehrt verwendet Flow 4 und/oder Flow 4'.
Der Client befindet sich außerhalb der Signal- und Medienschleife, nachdem der Anruf von PSTN zu PSTN gepinnt wurde.
Medien von SBC instance A innerhalb des Kundennetzwerks zu SBC instance B innerhalb des Kundennetzwerks (wobei A und B die gleichen instance sein können) verwenden Flow 5C.
Direct Routing (Medien über Microsoft 365) – PSTN-Anruf über zwei Mandanten hinweg
Abbildung 24: Direktes Routing (Medien über Microsoft 365) – PSTN-Frisuranruf über zwei Mandanten hinweg
Beachten Sie Folgendes:
Der SBC muss über eine öffentliche IP-Adresse verfügen, die von Microsoft 365 routingfähig ist.
Die Signalisierung vom SBC an Microsoft 365 und umgekehrt verwendet Flow 4 und/oder Flow 4'.
Der Client befindet sich außerhalb der Signal- und Medienschleife, nachdem der Anruf von PSTN zu PSTN gepinnt wurde.
Medien von SBC instance A innerhalb des Kundennetzwerks X an SBC instance B müssen über den Microsoft 365 Media Server weitergeleitet werden und können den Umgehungsmodus nicht verwenden.
Teams mit ExpressRoute-Optimierung
Abbildung 25 – Teams mit ExpressRoute-Optimierung
Für den Fall, dass ExpressRoute gerechtfertigt und bereitgestellt wird, können Teams-Flows von Flow 4 zu Flow 1 und von Flow 4' zu Flow 1' umgeleitet werden. Die Teams-Anwendung hat jedoch eine feste Abhängigkeit von anderen Microsoft 365-Datenflüssen über das Internet mithilfe von Flows 4 und 4'; daher dürfen diese Datenflüsse nicht blockiert werden.
Beachten Sie, dass Skype for Business Hybrid-Edge-Datenverkehr an das Internet und nicht an Express Route weitergeleitet wird, um mit externen Benutzern zu kommunizieren und einen Verbund mit anderen Mandanten zu erstellen.
Um asymmetrische Datenflüsse zu verhindern, muss das erneute Routing in beide Richtungen erfolgen. Anders ausgedrückt: Eine Adresse innerhalb des Kundennetzwerks ist entweder über das Internet oder ExpressRoute routingfähig, basierend auf der Optimierung, aber nicht über beides.
Kundennetzwerk für externe Benutzer (Medien, die von Teams Transport Relay weitergeleitet werden):
Abbildung 26: Kundennetzwerk zu einem externen Benutzer (Medien, die von Teams Transport Relay weitergeleitet werden)
Allgemeine Schritte:
- Der Teams-Benutzer innerhalb des Kundennetzwerks löst den URL-Domänennamen (DNS) mithilfe von flow2 auf.
- Der Teams-Benutzer innerhalb des Kundennetzwerks ordnet mithilfe von Flow 1 einen Medienrelayport auf Teams-Transportrelay zu.
- Der Teams-Benutzer innerhalb des Kundennetzwerks sendet "Invite" mit ICE-Kandidaten mithilfe von Flow 1 an Microsoft 365.
- Microsoft 365 sendet mithilfe von Flow 3 Benachrichtigungen an externe Teams-Benutzer.
- Ein externer Teams-Benutzer weist mithilfe von Flow 3 einen Medienrelayport auf Teams-Transportrelay zu.
- Externer Teams-Benutzer sendet "Antwort" mit ICE-Kandidaten mithilfe von Flow 3, der mithilfe von Flow 1 zurück an Teams-Benutzer A weitergeleitet wird.
- Teams-Benutzer A und Teams-Benutzer B rufen ICE-Konnektivitätstests auf und wählen die Flows 1 und 3 aus, die von Teams Transport Relay weitergeleitet werden.
- Teams-Benutzer senden Telemetriedaten mithilfe der Flows 1 und 3 an Microsoft 365.
Hinweis
Flow 4 muss aktiviert sein, um Abhängigkeiten der Teams-Anwendung von anderen Microdiensten zu unterstützen, die Flow 4 vorschreibt.