Planen der Optimierung lokaler Medien für Direct Routing
PSTN-VoIP (Public Switched Telephone Network) gilt als unternehmenskritische Anwendung mit hohen Erwartungen an die Sprachqualität. Mit Direct Routing für Microsoft Teams Telefon können Sie Mediendatenverkehrsflüsse steuern, um eine Vielzahl von Netzwerktopologien und lokalen Telefonie-Setups für verschiedene Unternehmen auf der ganzen Welt zu ermöglichen.
Mit der Optimierung lokaler Medien für Direct Routing können Sie die Sprachqualität wie folgt verwalten:
Steuern des Mediendatenverkehrs zwischen den Teams-Clients und den Session Border Controllern (SBCs) des Kunden.
Lokales Halten von Medien innerhalb der Grenzen von Unternehmensnetzwerksubnetzen.
Medienstreams zwischen den Teams-Clients und den SBCs zulassen, auch wenn sich die SBCs hinter Unternehmensfirewalls mit privaten IP-Adressen befinden und für Microsoft nicht direkt sichtbar sind.
Die Optimierung lokaler Medien unterstützt zwei Szenarien:
Zentralisierung aller lokalen Trunks über einen zentralisierten SBC, der mit dem SIP-Trunk (Session Initiation Protocol) Standard verbunden ist. Dieses Szenario bietet Telefoniedienste für alle lokalen Zweigstellen des Unternehmens.
Eine virtuelle Netzwerktopologie von SBCs. In diesem Szenario sind die SBCs in den lokalen Zweigstellen mit einem zentralisierten Proxy-SBC verbunden, der für Teams Telefon über seine externe IP-Adresse sichtbar ist und mit ihm kommuniziert. In einer virtuellen Netzwerktopologie kommunizieren Downstream-SBCs über interne IP-Adressen und sind für Teams Telefon nicht direkt sichtbar.
In diesem Artikel werden funktionen sowie Kundenszenarien und -lösungen beschrieben. Ausführliche Informationen zur Konfiguration finden Sie unter Konfigurieren der Optimierung lokaler Medien.
Hinweis
Wenn Sie Medien lokal innerhalb der Grenzen Ihres Intranets beibehalten möchten, wird die Lokale Medienoptimierung empfohlen. Wenn Sie jedoch bereits über die Medienumgehung verfügen und nur die öffentlichen IP-Adressen Ihrer SBCs verwenden, müssen Sie nicht zur lokalen Medienoptimierung wechseln. Sie können die Medienumgehung weiterhin verwenden. Weitere Informationen finden Sie unter Planen der Medienumgehung.
Informationen dazu, welche SBC-Anbieter die Optimierung lokaler Medien unterstützen, finden Sie unter Session Border Controller Certified for Direct Routing ( Session Border Controller Certified for Direct Routing).
Unterstützte Kundenszenarien
Gehen Sie für diese Diskussion davon aus, dass Contoso mehrere Unternehmen auf der ganzen Welt wie folgt betreibt. (Beachten Sie, dass die Regionen Europa und APAC nur als Beispiele verwendet werden. Ein Unternehmen kann über mehrere unterschiedliche Regionen mit ähnlichen Anforderungen verfügen.)
In Europa verfügt Contoso über Niederlassungen in rund 30 Ländern/Regionen. Jedes Büro verfügt über eine eigene Nebenstellenanlage (Private Branch Exchange, PBX).
Contoso wurde die Option angeboten, die Trunks für alle 30 europäischen Niederlassungen an einem Einzigen Ort zu zentralisieren – Amsterdam. Contoso hat den SBC in Amsterdam bereitgestellt, genügend Bandbreite für anrufe am zentralen Standort bereitgestellt, einen zentralen SIP-Trunk mit dem zentralen Standort verbunden und alle europäischen Standorte von Amsterdam aus bedient.
In der APAC-Region verfügt Contoso über mehrere Niederlassungen in verschiedenen Ländern/Regionen.
In vielen Ländern/Regionen verfügt das Unternehmen noch über TDM-Trunks (Time Division Multiplexing) in lokalen Niederlassungen. Die Zentralisierung der TDM-Trunks ist in der APAC-Region keine Option, sodass ein Wechsel zu SIP nicht möglich ist. Angenommen, es gibt mehr als 50 Niederlassungen von Contoso in der APAC-Region mit Hunderten von Gateways (SBCs). In diesem Szenario ist es nicht möglich, alle Gateways mit der Direct Routing-Schnittstelle zu koppeln, da es keine öffentlichen IP-Adressen und/oder lokalen Internet-Breakouts gibt. Darüber hinaus erzwingen einige Länder/Regionen gesetzliche Anforderungen, die ohne lokale PSTN-Netzwerkkonnektivität nicht erfüllt werden können.
Basierend auf den geschäftlichen Anforderungen implementierte Contoso zwei Lösungen mit lokaler Medienoptimierung für Direct Routing:
In Europa sind alle Trunks zentralisiert, und die Medien fließen zwischen dem zentralen SBC und den Benutzern, basierend auf dem Benutzerstandort.
Wenn ein Benutzer mit dem lokalen Subnetz eines Unternehmensnetzwerks verbunden ist (d. h. der Benutzer intern ist), fließt die Medien zwischen der internen IP-Adresse des zentralen SBC und dem Teams-Client des Benutzers.
Wenn sich ein Benutzer außerhalb der Grenzen des Unternehmensnetzwerks befindet , z. B. wenn der Benutzer eine öffentliche drahtlose Internetverbindung verwendet, wird der Benutzer als extern betrachtet. In diesem Fall fließen die Medien zwischen der externen IP-Adresse des zentralen SBC und dem Teams-Client.
In der APAC-Region wird ein zentralisierter Proxy-SBC mit Microsoft Direct Routing gekoppelt, der Medien zwischen der Direct Routing-Schnittstelle und den nachgeschalteten SBCs in lokalen Zweigstellen weiterleitet.
Die nachgeschalteten SBCs in den lokalen Zweigstellen sind für Direct Routing in APAC nicht direkt sichtbar, aber sie werden mithilfe des Cmdlets Set-CSOnlinePSTNGateway gekoppelt, um eine virtuelle Netzwerktopologie in Teams Telefon zu erstellen. Medien bleiben nach Möglichkeit immer lokal. Externe Benutzer verfügen über Medien, die zwischen dem Teams-Client und der öffentlichen IP-Adresse des Proxy-SBC fließen.
Zentraler SBC mit zentralisierten Trunks
Um eine Lösung zu erstellen, bei der PSTN-Dienste für alle lokalen Zweigstellen über einen einzelnen zentralen SBC mit einem verbundenen zentralisierten SIP-Trunk bereitgestellt werden, koppelt der Contoso-Mandantenadministrator einen SBC (centralsbc.contoso.com) mit dem Dienst. Der SBC ist mit einem zentralisierten SIP-Trunk verbunden.
Wenn sich ein Benutzer im internen Netzwerk des Unternehmens befindet, stellt der SBC die interne IP-Adresse des SBC für Medien bereit.
Wenn sich ein Benutzer außerhalb des Unternehmensnetzwerks befindet, stellt der SBC die externe (öffentliche) IP-Adresse des SBC bereit.
Hinweis
Alle Werte in Beispielen, Tabellen oder Diagrammen werden nur zu Veranschaulichungszwecken dargestellt.
Tabelle 1. Beispielnetzwerkparameter für SBCs
Ort | SBC-FQDN | Internes Subnetz | Externe NAT (vertrauenswürdige IP) | Externe SBC-IP-Adresse | Interne SBC-IP-Adresse |
---|---|---|---|---|---|
Amsterdam | centralsbc.contoso.com | 192.168.5.0/24 | 172.16.76.73 | 172.16.76.71 | 192.168.5.5 |
Deutschland | Nicht bereitgestellt | 192.168.6.0/24 | 172.16.76.74 | Nicht bereitgestellt | Nicht bereitgestellt |
Frankreich | Nicht bereitgestellt | 192.168.7.0/24 | 172.16.76.75 | Nicht bereitgestellt | Nicht bereitgestellt |
Interner Benutzer
Das folgende Diagramm zeigt den Datenverkehrsfluss, wenn ein Benutzer mit dem Unternehmensnetzwerk in der Heimniederlassung oder am Standort des Benutzers verbunden ist.
Während der Lokalen Umgebung wird der Benutzer der lokalen Niederlassung in Deutschland zugewiesen. Der Benutzer führt einen Direct Routing-Telefonanruf über Teams.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API, aber die während des Aufrufs generierten Medien fließen an die interne IP-Adresse des zentralen SBC.
Der SBC leitet den Flow an Teams Telefon und das verbundene PSTN-Netzwerk um.
Der zentrale SBC ist nur über die externe IP-Adresse für Teams Telefon sichtbar.
Diagramm 1. Datenverkehrsfluss, wenn sich der Benutzer am "Home"-Standort mit einem zentralisierten SBC und einem verbundenen zentralisierten SIP-Trunk befindet
Externer Benutzer
Das folgende Diagramm zeigt den Datenverkehrsfluss, wenn sich ein Benutzer nicht lokal befindet und nicht mit dem Unternehmensnetzwerk verbunden ist (das Gerät des Benutzers ist also über ein mobiles Gerät oder ein öffentliches WLAN mit dem Internet verbunden). Der Benutzer führt einen Direct Routing-Telefonanruf über Teams aus:
Der Teams-Client des Benutzers kommuniziert direkt über die REST-API mit Teams Telefon, aber in diesem Fall fließen die während des Aufrufs generierten Medien an die externe IP-Adresse des zentralen SBC.
Der SBC leitet den Flow an Teams Telefon und das verbundene PSTN-Netzwerk um.
Der zentrale SBC ist nur über die externe IP-Adresse für Teams Telefon sichtbar.
In diesem Fall ist das Verhalten ähnlich, unabhängig davon, ob der Benutzer in der Niederlassung in Deutschland oder einer anderen Filiale vor Ort ist. Der Benutzer gilt als extern, da er sich außerhalb der Grenzen des Unternehmensnetzwerks befindet.
Diagramm 2. Datenverkehrsfluss, wenn der Benutzer mit einem zentralisierten SBC und einem verbundenen zentralisierten SIP-Trunk extern ist
Proxy-SBC mit verbundenen downstream-SBCs
Um eine Lösung zu erstellen, bei der PSTN-Dienste in allen lokalen Zweigstellen in der APAC-Region bereitgestellt werden, in der die Zentralisierung der TDM-Trunks nicht möglich ist, koppelt der Contoso-Administrator einen SBC (proxysbc.contoso.com), auch Proxy-SBC genannt, mit dem Direct Routing-Dienst.
Anschließend fügt der Contoso-Administrator einige Downstream-SBCs hinzu, die angeben, dass sie über den Proxy-SBC-proxysbc.contoso.com erreicht werden können. Downstream-SBCs verfügen über keine öffentlichen IP-Adressen. sie können jedoch Sprachrouten zugewiesen werden. Die folgende Tabelle zeigt Beispielnetzwerkparameter und -konfigurationen.
Wenn sich ein Benutzer in der lokalen Zweigstelle befindet, in der sich der nachgeschaltete SBC befindet, fließt der Mediendatenverkehr direkt zwischen dem Benutzer und dem lokalen Downstream-SBC. Wenn sich ein Benutzer außerhalb des Büros befindet (in einem öffentlichen Internet), fließen die Medien vom Benutzer an die öffentliche IP-Adresse des Proxy-SBC, die sie an die relevanten Downstream-SBC(s) weitergibt.
Tabelle 2. Beispielinformationen zum SBC-Netzwerk
Ort | SBC-FQDN | Internes Subnetz | Externe NAT (vertrauenswürdige IP) | Externe SBC-IP-Adresse | Interne SBC-IP-Adresse |
---|---|---|---|---|---|
Vietnam | VNsbc.contoso.com | 192.168.1.0/24 | 172.16.240.110 | Keine | 192.168.1.5 |
Indonesien | IDsbc.contoso.com | 192.168.2.0/24 | 172.16.240.120 | Keine | 192.168.2.5 |
Singapur | proxysbc.contoso.com | 192.168.3.0/24 | 172.16.240.130 | 172.16.240.133 | 192.168.3.5 |
Interner Benutzer
Das folgende Diagramm zeigt den allgemeinen Datenverkehrsfluss für das Szenario, in dem sich ein Benutzer im Büro in der APAC-Region befindet. Der Benutzer, der einer lokalen Niederlassung in Vietnam zugewiesen ist und sich vor Ort befindet, führt einen Direct Routing-Telefonanruf über Teams.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API, aber während des Aufrufs generierte Medien fließen an die interne IP-Adresse des lokalen SBC.
Der lokale SBC leitet den Flow an den Proxy-SBC in Singapur und an das verbundene lokale PSTN-Netzwerk um.
Der Proxy-SBC ist für Teams Telefon nur über die externe IP-Adresse sichtbar und leitet den Flow vom Downstream-SBC (in diesem Fall dem lokalen SBC in Vietnam) an Teams Telefon weiter.
Der Downstream-SBC in der lokalen Filiale ist für Teams Telefon nicht direkt sichtbar, ist aber innerhalb der virtuellen Netzwerktopologie zugeordnet, die vom Contoso-Administrator beim Einrichten der lokalen Medienoptimierung definiert wird.
Hinweis
Das Verhalten für lokale Benutzer und nicht lokale Benutzer kann je nach konfiguriertem Modus zur Optimierung lokaler Medien unterschiedlich sein.
Weitere Informationen zu möglichen Modi und relevantem Verhalten finden Sie unter Konfigurieren der Optimierung lokaler Medien.
Diagramm 3. Datenverkehrsfluss, wenn sich der Benutzer im "Home"-Netzwerk mit einem Proxy-SBC und mit verbundenen Downstream-SBCs befindet
Externer Benutzer
Das folgende Diagramm zeigt den Datenverkehrsfluss, wenn sich ein Benutzer außerhalb der Unternehmensnetzwerkgrenzen befindet. Der Benutzer ist nicht lokal (befindet sich nicht innerhalb der Grenzen des Unternehmensnetzwerks). Der Benutzer führt einen Direct Routing-Telefonanruf über Teams an eine Telefonnummer in Vietnam.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API, aber die während des Aufrufs generierten Medien fließen zuerst an die externe IP-Adresse des Proxy-SBC in Singapur.
Basierend auf Konfigurations- und Sprachrichtlinien (siehe Konfigurieren der Optimierung lokaler Medien) leitet der Proxy-SBC den Flow an den downstream-SBC in Vietnam um.
Der Downstream-SBC in Vietnam leitet den Datenfluss an das verbundene lokale PSTN-Netzwerk um.
Der Proxy-SBC ist nur über die externe IP-Adresse für Teams Telefon sichtbar.
Der Downstream-SBC in der lokalen Filiale ist für Teams Telefon nicht direkt sichtbar, wird aber innerhalb der virtuellen Netzwerktopologie zugeordnet, die vom Contoso-Administrator beim Einrichten der lokalen Medienoptimierung definiert wird. Im Beispiel gilt der Benutzer als extern, da er sich außerhalb der Grenzen des Unternehmensnetzwerks befindet.
Diagramm 4. Datenverkehrsfluss, wenn der Benutzer mit einem Proxy-SBC und verbundenen Downstream-SBCs extern ist
Optimierungsmodi für lokale Medien
Die Optimierung lokaler Medien unterstützt zwei Modi:
Modus 1: Immer umgehen. Wenn der Benutzer in diesem Fall intern ist, fließt das Medium über die interne IP-Adresse des lokalen Downstream-SBC, unabhängig vom tatsächlichen Standort des internen Benutzers; Beispielsweise innerhalb derselben Filiale, in der sich der nachgeschaltete SBC befindet, oder in einer anderen Filiale.
Modus 2: Nur für lokale Benutzer. In diesem Modus fließen Medien nur dann direkt an die interne IP-Adresse des lokalen Downstream-SBC, wenn sie vom internen Benutzer generiert werden, der sich in derselben Filiale wie der downstream-SBC befindet.
Um zwischen lokalen Medienoptimierungsmodi zu unterscheiden, muss der Mandantenadministrator den Parameter -BypassMode für jeden SBC mithilfe des Cmdlets Set-CSonlinePSTNGateway auf "Always" oder "OnlyForLocalUsers" festlegen. Weitere Informationen finden Sie unter Konfigurieren der Optimierung lokaler Medien.
Hinweis
Wenn Benutzer intern sind, ist eine Medienkonnektivität zwischen dem Benutzer und dem SBC über die interne IP-Adresse erforderlich. In diesem Fall gibt es kein Fallback auf Relays für öffentliche Verkehrsmittel für Medien, da der SBC eine interne IP-Adresse für die Medienkonnektivität bereitstellt.
Modus 1: Immer umgehen
Wenn Sie über eine gute Verbindung zwischen Zweigstellen verfügen, wird der empfohlene Modus Immer umgehen verwendet.
Angenommen, ein Unternehmen verfügt über einen zentralisierten SIP-Trunk in Amsterdam, der 30 Länder/Regionen bedient und über eine gute Konnektivität zwischen allen 30 Standorten und lokalen Benutzern verfügt. Es gibt auch eine Niederlassung in Deutschland, in der ein lokaler SBC bereitgestellt wird.
Der SBC in Deutschland kann im Modus "Immer umgangen" konfiguriert werden. Benutzer stellen unabhängig von ihrem Standort direkt über die interne IP-Adresse des SBC eine Verbindung mit dem SBC her; beispielsweise von Frankreich nach Deutschland. Weitere Informationen finden Sie im folgenden Diagramm.
Im Folgenden werden zwei Szenarien beschrieben:
Szenario 1. Der Benutzer befindet sich am selben Speicherort wie der SBC, der in der Online-VoIP-Routingrichtlinie definiert ist.
Szenario 2. Benutzer und Gateways befinden sich an unterschiedlichen Standorten.
Szenario 1. Der Benutzer befindet sich am gleichen Ort wie der SBC, der in der Online-VoIP-Routingrichtlinie definiert ist.
Der SBC in Amsterdam ist als Proxy-SBC für einen lokalen Downstream-SBC in Deutschland konfiguriert. Der Benutzer befindet sich in Deutschland innerhalb desselben Subnetzes wie das Unternehmensnetzwerk des lokalen SBC. Beide SBCs (Proxy und Downstream) sind für den Always Bypass-Modus konfiguriert. Online-VoIP-Routingrichtlinien legen fest, dass Anrufe innerhalb Deutschlands (mit Vorwahl +49) an den lokalen SBC in Deutschland weitergeleitet werden sollen. Alle anderen Anrufe sollten an den Proxy-SBC in Amsterdam weitergeleitet werden. Wenn der SBC in Deutschland jedoch fehlschlägt, sollten Anrufe in Deutschland auch an den Proxy-SBC in Amsterdam weitergeleitet werden. In der folgenden Tabelle wird die Beispielkonfiguration zusammengefasst.
Tabelle 3. Beispielkonfiguration für Szenario 1
Physischer Standort des Benutzers | Der Benutzer ruft eine Nummer an. | Online-VoIP-Routingrichtlinie | Für SBC konfigurierter Modus | Medienfluss |
---|---|---|---|---|
Deutschland | +49 1 437 2800 | Priorität 1: ^+49(\d{8})$ -DEsbc.contoso.com Priorität 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com – Immer umgehen proxysbc.contoso.com – Immer umgehen |
Teams-Benutzer <–> DEsbc.contoso.com |
Das folgende Diagramm zeigt den allgemeinen Datenverkehrsfluss für den internen Benutzer in Deutschland, der einen Direct Routing-Telefonanruf über Teams an die Nummer in Deutschland durchführt.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API.
Die während des Anrufs generierten Medien werden an die interne IP-Adresse des lokalen SBC übertragen.
Der lokale SBC leitet den Datenfluss an den Proxy-SBC in Amsterdam und an das verbundene lokale PSTN-Netzwerk um.
Der Proxy-SBC ist für Teams Telefon nur über die externe IP-Adresse sichtbar und leitet den Flow vom Downstream-SBC (in diesem Fall dem lokalen SBC in Deutschland) an Teams Telefon weiter.
Der Downstream-SBC in der lokalen Filiale ist für Teams Telefon nicht direkt sichtbar, ist aber innerhalb der virtuellen Netzwerktopologie zugeordnet, die vom Contoso-Administrator beim Einrichten der lokalen Medienoptimierung definiert wird.
Diagramm 5. Datenverkehrsfluss im Modus "Immer umgehen", und der Benutzer befindet sich auf der "Home"-Website.
.
Szenario 2: Benutzer und Gateways befinden sich an unterschiedlichen Standorten
Der SBC in Amsterdam ist als Proxy-SBC für einen lokalen Downstream-SBC in Deutschland konfiguriert. Beide SBCs (Proxy und Downstream) sind für den Always Bypass-Modus konfiguriert. Der interne Benutzer in Frankreich, der sich in der lokalen Filiale befindet, nimmt einen Direct Routing-Anruf nach Deutschland vor. Online-VoIP-Routingrichtlinien legen fest, dass Anrufe nach Deutschland (mit Vorwahl +49) an den lokalen SBC in Deutschland weitergeleitet werden sollen. Alle anderen Anrufe sollten an den Proxy-SBC in Amsterdam weitergeleitet werden. Wenn der SBC in Deutschland jedoch fehlschlägt, sollten alle Anrufe in Deutschland an den Proxy-SBC in Amsterdam weitergeleitet werden. In der folgenden Tabelle wird die Beispielkonfiguration zusammengefasst.
Tabelle 4. Beispielkonfiguration für Szenario 2
Physischer Standort des Benutzers | Der Benutzer ruft eine Nummer an. | Online-VoIP-Routingrichtlinie | Für SBC konfigurierter Modus | Medienfluss |
---|---|---|---|---|
Frankreich | +49 1 437 2800 | Priorität 1: ^+49(\d{8})$ -DEsbc.contoso.com Priorität 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com – proxysbc.contoso.com immer umgehen – immer umgehen | Teams-Benutzer <– > DEsbc.contoso.com |
Das folgende Diagramm zeigt den allgemeinen Datenverkehrsfluss, wenn der interne deutsche Benutzer mit Sitz in Frankreich einen Direct Routing-Telefonanruf über Teams an die Nummer in Deutschland führt.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API.
Die während des Anrufs erzeugten Medien fließen direkt an den SBC in der internen IP-Adresse deutschlands.
Der SBC in Deutschland leitet den Datenfluss an den Proxy-SBC in Amsterdam und an das verbundene lokale PSTN-Netzwerk um.
Diagramm 6. Datenverkehrsfluss im Modus "Immer umgehen", und der Benutzer befindet sich nicht am "Home"-Standort, sondern im internen Netzwerk.
.
Modus 2: Nur für lokale Benutzer
Wenn es schlechte Verbindungen zwischen lokalen Filialen, aber gute Verbindungen zwischen jeder lokalen Filiale und regionalen Niederlassung gibt, ist der empfohlene Modus "Nur für lokale Benutzer".
Angenommen, Contoso verfügt in der Region APAC über mehrere Niederlassungen in verschiedenen Ländern/Regionen. In vielen Ländern/Regionen ist der Umstieg auf SIP nicht möglich, da das Unternehmen noch TDM-Trunks in vielen lokalen Filialen hat. Die Zentralisierung der TDM-Trunks ist in der APAC-Region keine Option. Darüber hinaus gibt es mehr als 50 Contoso-Niederlassungen in der APAC-Region mit Hunderten von Gateways (SBCs).
Um eine Lösung zu erstellen, bei der PSTN-Dienste in allen lokalen Zweigstellen in der APAC-Region bereitgestellt werden, in der die Zentralisierung der TDM-Trunks nicht möglich ist, koppelt der Contoso-Administrator einen regionalen SBC in Singapur als Proxy-SBC mit dem Direct Routing-Dienst. Die direkte Verbindung zwischen den lokalen Filialen ist nicht gut, aber es gibt eine gute Verbindung zwischen jeder lokalen Filiale und der regionalen SBC in Singapur. Für den regionalen SBC wählt der Administrator den Modus "Immer umgehen" aus. Für die lokalen Downstream-SBCs wählt der Administrator den Modus "Nur für lokale Benutzer" aus.
Im Folgenden werden zwei Szenarien beschrieben:
Szenario 1. Der Benutzer befindet sich am gleichen Ort wie der SBC, der in der Online-VoIP-Routingrichtlinie definiert ist.
Szenario 2. Der Benutzer und die Gateways befinden sich an verschiedenen Standorten.
Szenario 1. Der Benutzer befindet sich am gleichen Ort wie der SBC, der in der Online-VoIP-Routingrichtlinie definiert ist.
Angenommen, der SBC in Singapur ist als Proxy-SBC für die lokalen Downstream-SBCs in Vietnam und Indonesien konfiguriert. Der Benutzer befindet sich in Vietnam am gleichen Standort wie der lokale SBC. Online-VoIP-Routingrichtlinien legen fest, dass Anrufe in Vietnam (mit Vorwahl +84) an den lokalen SBC in Vietnam weitergeleitet werden sollen. Alle anderen Aufrufe sollten an den Proxy-SBC in Singapur weitergeleitet werden. Wenn der SBC in Vietnam jedoch fehlschlägt, sollten Anrufe in Vietnam an den Proxy-SBC in Singapur weitergeleitet werden. In der folgenden Tabelle wird die Beispielkonfiguration zusammengefasst.
Tabelle 5. Beispielkonfiguration für den Modus "Nur für lokale Benutzer" Szenario 1
Physischer Standort des Benutzers | Der Benutzer ruft eine Nummer an. | Online-VoIP-Routingrichtlinie | Für SBC konfigurierter Modus | Medienfluss |
---|---|---|---|---|
Vietnam | +84 4 3926 3000 | Priorität 1: ^+84(\d{9})$ -VNsbc.contoso.com Priorität 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com – nur für lokale Benutzer proxysbc.contoso.com – Immer umgehen |
Teams-Benutzer <–> VNsbc.contoso.com |
Im folgenden Diagramm führt ein Benutzer, der der lokalen Filiale in Vietnam zugewiesen ist, einen Direct Routing-Telefonanruf über Teams.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API.
Während des Anrufs generierte Medien fließen an die interne IP-Adresse des lokalen SBC.
Der lokale SBC leitet den Flow an den Proxy-SBC in Singapur und an das verbundene lokale PSTN-Netzwerk um.
Der Proxy-SBC ist für Teams Telefon nur über die externe IP-Adresse sichtbar und leitet den Flow vom Downstream-SBC (in diesem Fall der lokale SBC in Vietnam) an Teams Telefon weiter.
Der Downstream-SBC in der lokalen Filiale ist für Teams Telefon nicht direkt sichtbar, ist aber innerhalb der Topologie des virtuellen Netzwerks zugeordnet.
Diagramm 7. Datenverkehrsfluss im Modus "Nur für lokale Benutzer", und der Benutzer befindet sich auf der "Home"-Website
Szenario 2. Der Benutzer und die Gateways befinden sich an verschiedenen Standorten.
Angenommen, der SBC in Singapur ist als Proxy-SBC für die lokalen Downstream-SBCs in Vietnam und Indonesien konfiguriert. Der interne Benutzer in Indonesien, der sich in der lokalen Filiale befindet, macht einen Direct Routing-Anruf nach Vietnam. Online-VoIP-Routingrichtlinien legen fest, dass Anrufe nach Vietnam (mit Vorwahl +84) an den lokalen SBC in Vietnam weitergeleitet werden sollen. Alle anderen Aufrufe sollten an den Proxy-SBC in Singapur weitergeleitet werden. Wenn der SBC in Vietnam jedoch fehlschlägt, sollten Anrufe nach Vietnam an den Proxy-SBC in Singapur weitergeleitet werden. Der Proxy-SBC in Singapur ist auf den Modus "Immer umgehen" und der lokale SBC in Vietnam auf den Modus "Nur für lokale Benutzer" festgelegt. In der folgenden Tabelle wird die Beispielkonfiguration zusammengefasst.
Tabelle 6. Benutzerkonfiguration
Physischer Standort des Benutzers | Der Benutzer ruft eine Nummer an. | Online-VoIP-Routingrichtlinie | Für SBC konfigurierter Modus | Medienfluss |
---|---|---|---|---|
Indonesien | +84 4 3926 3000 | Priorität 1: ^+84(\d{9})$ -VNsbc.contoso.com Priorität 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com – nur für lokale Benutzer proxysbc.contoso.com – Immer umgehen |
Teams-Benutzer <–> proxysbc.contoso.com <–> VNsbc.contoso.com |
Im folgenden Diagramm führt der interne Benutzer, der sich lokal in der indonesischen Niederlassung befindet, einen Direct Routing-Telefonanruf über Teams an eine Nummer in Vietnam.
Der Teams-Client des Benutzers kommuniziert mit Teams Telefon direkt über die REST-API.
Medien, die während des Anrufs generiert werden, fließen zuerst an die interne IP-Adresse von SBC.
Der Proxy-SBC in Singapur leitet den Flow an die interne IP-Adresse des Downstream-SBC in Vietnam und an Teams Telefon um.
Der Downstream-SBC in Vietnam leitet den Datenfluss an das verbundene lokale PSTN-Netzwerk weiter.
Der Proxy-SBC ist nur über die externe IP-Adresse für Teams Telefon sichtbar.
Die nachgeschalteten SBCs in lokalen Zweigstellen sind für Teams Telefon nicht direkt sichtbar, werden aber innerhalb der Topologie des virtuellen Netzwerks zugeordnet.
Diagramm 8. Datenverkehrsfluss im Modus "Nur für lokale Benutzer", und der Benutzer befindet sich nicht am "Home"-Standort, sondern im internen Netzwerk.
.
Bekannte Verhaltensweisen
Im Folgenden finden Sie eine Liste der Verhaltensweisen, die bei der Verwendung der Optimierung lokaler Medien beobachtet werden können.
Produktverhalten | Hinweise |
---|---|
Der Teams-Client wird nicht als intern identifiziert, wenn die öffentliche IP-Adresse des Teams-Clients mit der Liste der vertrauenswürdigen IP-Adressen des Kunden übereinstimmt, aber nicht mit dem Netzwerkstandort übereinstimmt. | Die Optimierung lokaler Medien erfordert einen übereinstimmenden Netzwerkstandort für jede Verbindung, die über eine aufgeführte vertrauenswürdige IP-Adresse hergestellt wird. |
Der Teams-Benutzer legt den Anruf in die Sperre. Musik wird am PSTN-Ende wiedergegeben, und die Lokale Medienoptimierung funktioniert. Der Teams-Benutzer setzt den Anruf fort. Der Anruf an das PSTN wird fortgesetzt, aber die Optimierung lokaler Medien funktioniert nicht, und der Anruf wird über central (Proxy) SBC fortgesetzt. | Wenn ein Benutzer einen Anruf einparkt, um Musik im Warteschleifen (MoH) zu initiieren, wird er vom Anrufcontroller von 1:1 zu einem Anruf mit mehreren Teilnehmern eskaliert, um Mediencontroller und Medienprozessor (als AVMCU-Mixer) aufzurufen, über den MoH einen Benutzer erreicht, der in die Warteschleife versetzt wurde. Die Deeskalation zu einem 1:1-Anruf, nachdem der Anruf fortgesetzt wurde, erfolgt nie gemäß dem Entwurf. |
Während ein Anruf eingerichtet wird, kann der Benutzer für einige Sekunden Stille hören. | Dies kann in einigen Fällen aufgrund der Komplexität der Architektur der lokalen Medienoptimierung auftreten. |
Sprach-Apps (z. B. automatische Telefonzentrale und Anrufwarteschleife). | Voice-Apps können in einer Umgebung bereitgestellt werden, in der LMO konfiguriert ist. Anrufe mit Sprach-Apps werden jedoch nicht für die Optimierung lokaler Medien optimiert. Sie werden stattdessen über den Proxy-SBC übertragen, mit Ausnahme von Übertragungen von der automatischen Telefonzentrale an Benutzer der lokalen Medienoptimierung. In solchen Fällen folgt der Anruf dem optimierten Pfad der lokalen Medienoptimierung, da es sich um einen direkten 1:1-Aufruf handelt. Informationen zu Location-Based Routingszenarien finden Sie unter Sprach-Apps (automatische Telefonzentrale oder Anrufwarteschleife). |