Can Microsoft Teams call 911?

In jedem Teams Voice Projekt kommt man mit dem Kunden an den Punkt, dass man über ein Konzept für Notrufe sprechen muss. Unsere generelle Empfehlung ist, die Mitarbeiter anzuweisen, Notrufe vom Mobiltelefon aus zu tätigen. Dies ist jedoch nicht bei allen Kunden möglich. Daher muss auch dieses Szenario mit den Möglichkeiten der Teams Voice Plattform abgedeckt werden. Grundsätzlich gibt uns die Notrufkonfiguration in Teams zwei Optionen, die ineinandergreifen:

• Korrektes Routing von Notrufen anhand einer ELIN Nummer
• Realisierung der Rückrufmöglichkeit, falls der Notruf vorzeitig getrennt wird

Notrufe werden bei den meisten deutschen Carriern anhand des P-Asserted Identity Headers (PAI) in der SIP Message an den nächstgelegenen Public Safety Answering Point (PSAP) geroutet. Um genau das zu gewährleisten, ist die Konfiguration von folgenden Punkten in Teams notwendig:

• Konfiguration der Public Trusted IP’s
• Anlegen von privaten Subnets und Locations
• Bereitstellung einer Emergency Addresse
• Vorhalten einer ELIN Rufnummer

Teams prüft für die Zuordnung einer Emergency Adresse zunächst die Trusted IP. Hierbei handelt es sich um die öffentliche IP-Adresse des Standorts, von dem aus sich der Client anmeldet. Es ist essenziell, dass alle genutzten öffentlichen IP-Adressen von potenziellen Standorten im Teams Admin Center (TAC) hinterlegt werden. Dazu gehören auch eventuell verwendete IPv6-Adressen!

Im TAC sieht die Konfiguration basierend auf dem obigen Beispiel wie folgt aus:

Es ist zu beachten, dass die öffentlichen IP-Adressen eine Network Range benötigen. Diese sollten so gewählt werden, dass die Range alle vom Standort verwendeten Adressen enthält.

Als ersten Schritt aktivieren wir die PIDF/LO Option Option auf dem Session Border Controller (SBC) im TAC. Das sorgt dafür, dass die genauen Lokationsdaten als XML in den SIP Messages an die Notfalleinsatzleitzentrale übermittelt werden können.

Als nächstes wird eine Network Site angelegt. Die Site bildet hierbei einen logischen Standort mit allen dort enthaltenen Subnetzen ab, ist aber für die Übermittlung der Emergency Addresse nicht zwingend erforderlich. Die Network Site wird für dynamisches Emergency Routing verwendet, da an eine Site eine Emergency Call Routing Policy assoziiert werden kann. Somit ist an jedem Standort des Unternehmens sichergestellt, dass Notrufe über die korrekte Nummer und das korrekte PSTN Gateway geroutet werden.

Alle Sites müssen Mitglied einer Network Region sein. Standorte in Deutschland werden z.B. in einer Region „Germany“ aggregiert. Die Region fungiert hierbei, ähnlich den PSTN Usages, nur als Container.

Weiter geht es mit der Erstellung von Emergency Addresses. Diese stellen den zentralen Punkt der Konfiguration dar und sind der wichtigste Schritt für das Routing der Notrufe. Die erfassten Emergency Adresses werden relativ schnell nach dem Anlegen verifiziert und können danach nicht mehr geändert werden! Wenn beispielsweise die Straße, Hausnummer oder ELIN-Telefonnummer nachträglich geändert werden soll, muss die komplette Emergency Address gelöscht und neu angelegt werden.

Über das TAC kann die Adresse des Standorts im jeweiligen Land angegeben werden. Die Adresse sollte dabei nach Möglichkeit nicht manuell eingegeben werden. Eine manuelle Eingabe erfordert zwingend die Angabe von Längen- und Breitengrad ausserhalb der USA, da ansonsten keine Zuordnung zur Clientlocation stattfinden kann.

Die Eingabe im Feld „ELIN (optional)“ ist hier besonders wichtig. Das ist die dem Standort zugehörige Rufnummer, die später im PAI Header mitgesendet wird. Das Emergency Call Routing auf Seite der Carrier basiert auf der korrekten Eingabe der Nummer. Damit der Teams Client seinen Standort lokalisieren kann, müssen sogenannte Location Identifier an den Standort angefügt werden. Hierzu dienen Subnetze, Wireless Access Points, Switches und Switchports. Speziell bei den Subnetzen ist an dieser Stelle zu erwähnen, dass es sich hier nicht um die gleichen Objekte handelt, die bereits für die Network Site angelegt wurden. Um dies zu veranschaulichen, sehen wir uns kurz die PowerShell CMDlets an, die zum Erstellen von Location Identifier sowie Network Site Subnetze verwendet werden:

Set-CsOnlineLisSubnet -Subnet 192.168.178.0 -LocationId f037a9ad-4334-455a-a1c5-3838ec0f5d02 -Description "HomeOffice"

Hiermit wird das LIS Subnet 192.168.178.0 angelegt, das der Emergency Location mit der ID f037a9ad-4334-455a-a1c5-3838ec0f5d02 zugeordnet wird. LIS steht hierbei für Location Information Service und kommt aus der On-Premises Welt.

New-CsTenantNetworkSubnet -SubnetID "192.168.178.0" -MaskBits "24" -NetworkSiteID "HomeOffice"

Mit diesem CMDlet legen wir ein Subnet für eine zuvor erstelle Network Site „HomeOffice“ an. Wir können klar erkennen, dass hier zwei unterschiedliche Objekte angelegt werden, die miteinander auch nicht kombiniert werden können, da sie für unterschiedliche Einsatzzwecke erstellt wurden.

Für dieses Beispiel werden wir nun ein neues Subnetz anlegen und an den zuvor erstellten Notfallstandort anfügen.

Es gibt zwei Wege, eine neue Location im TAC anzulegen. Entweder man wählt die Emergency Address aus und fügt sie direkt hinzu oder aber man ergänzt sie unter „Networks & Locations“. Beide Wege führen im Backend das gleiche Doing aus. Sowohl Emergency Address als auch die Location Identifier sind zwei unabhängige Objekte, die miteinander verknüpft werden müssen.

Wichtige Information bzgl. Subnets

Eigentlich ist das Wording an dieser Stelle falsch. Da wir beim Anlegen keine Netzmaske mitgeben, kann es sich allein deshalb schon nicht um ein Subnet handeln. Korrekt ist nämlich, dass hier eine Netzadresse angegeben wird. Der Teams Client rechnet sich aus der IP Adresse selbstständig die zugehörige Netzadresse aus.

Die Beispiele aus dem Screenshot zeigen, welche Adressen im TAC als Location Identifier hinterlegt werden müssten.

Im letzten Schritt legen wir im TAC eine Emergency Call Routing Policy an und weisen sie unserem Testuser zu. Diese Policy legt fest, welche Nummer(n) als Notrufnummer deklariert wird / werden. Wir können die Nummer auch separat normalisieren und ins PSTN routen. Besonders der letzte Punkt kann essenziell sein. Wenn der Kunde mit sehr restriktiven Voice Routes und PSTN Usages arbeitet, kann es ratsam sein, eine gesonderte Route und PSTN Usage für Notrufe anzulegen und zuzuweisen.

In der obigen Konfiguration wurde die 115 als Notfallrufnummer hinterlegt, die 222 als Maskierung / Normalisierung. Alles wird über die Catch All Usage ins PSTN gesendet.

Der User kann direkt die 115 oder 222 in seinem Teams Client wählen, um einen Notruf abzusetzen. Die Zuweisung dieser Policy erfolgt entweder direkt an dem Benutzer im TAC oder über die zuvor erstelle Network Site. Die Network Site hat den Vorteil, dass alle Benutzer, die dort lokalisiert sind, die Policy automatisch zugewiesen bekommen. Eine gruppenbasierte Zuweisung der Emergency Call Routing Policys gibt es derzeit nicht.

Nun folgt die abschließende Konfiguration auf Seiten des SBCs. Da wir primär mit Audiocodes zusammenarbeiten, werden wir in diesem Artikel auf die ELIN Konfiguration basierend auf Audiocodes eingehen.

ELIN ist bei Audiocodes eine separate Lizenz, die auf dem SBC benötigt wird. Diese muss also erst vorhanden und aktiviert sein, bevor man die vollständige ELIN Konfiguration testen kann.

Der erste Schritt der Konfiguration ist die Aktivierung des PSAP Mode auf der IP-Gruppe, die in Richtung des Carriers zeigt.

Als nächstes kann der E911 Callback Timeout angepasst werden. Dieser legt fest, wie lange die ELIN Nummer zusammen mit der abgehenden Nummer in der ELIN Tabelle des SBC’s gespeichert wird.

30 Minuten ist die Default Konfiguration und sollte auch für die meisten Szenarien ausreichend sein. Nachdem ein Notruf getätigt wurde, kann man über eine SSH Verbindung zum SBC und dem Befehl „show voip e911“ die ELIN Tabelle auslesen. Die vollständige Konfiguration funktioniert dann wie folgt:

• Der User wählt die in der Emergency Call Routing Policy hinterlegte oder maskierte Nummer
• Dadurch wird in Richtung SBC ein Notruf signalisiert und der SIP Header im Invite wird mit „priority: emergency“ ausgestattet und der PAI wird mit der im Emergency Standort hinterlegten ELIN Nummer getauscht
• Über die im SBC auf der IP-Gruppe Richtung Carrier aktivierten PSAP Option wird die Kombination aus „Call From“ und „PAI“ in der ELIN Tabelle des SBC für 30 Minuten gespeichert
• Im Fall, dass der Notruf vorzeitig unterbrochen wird, kann die Notfalleinsatzleitzentrale über die im PAI übermittelte Nummer einen Rückruf einleiten und wird an die Nebenstelle geroutet, die den Notruf initiiert hat

Im Syslog stellt sich der ausgehende Invite folgendermaßen dar:

Die beiden rot markierten Stellen sind die beiden Header, die eingefügt bzw. ersetzt werden (PAI). Weitere Daten werden über die Konfiguration der Emergency Adresse übertragen. Sie sind im PIDF/LO XML abgebildet. In Deutschland können sie noch nicht ausgewertet werden und sind Stand heute nur für E911 in den USA relevant. Mit dem hier beschriebenen Setup sind aber bereits alle wichtigen Module eingestellt, so dass im Falle einer Auswertung durch deutsche Notrufzentralen bereits alles korrekt übertragen wird.

Und schließlich die ELIN Tabelle aus dem Audiocodes SBC:

Hier ist gut zu erkennen, dass die in der ELIN Tabelle gespeicherte Nummer mit der ELIN Nummer des Standorts übereinstimmt und dem Call From zugeordnet ist.

Summary

Microsoft Teams bietet uns mittlerweile eine gute Lösung, um Notrufe von bekannten Standorten abzudecken und diese richtig zu routen. Voraussetzung ist, dass alle benötigten Network Identifier bekannt sind und im TAC fortlaufend gepflegt sind. Das bringt uns nicht nur ein sauberes Notrufrouting, sondern erlaubt uns auch, bei Problemen mit der Anrufqualität über das Call Quality Dashboard einfach und schnell potenzielle Störungen in bestimmten Netzwerksegmenten aufzudecken. Also definitiv eine Aufgabe, die man auf dem Radar haben sollte, wenn man Teams Voice einsetzt. Wir empfehlen nach wie vor, bei Notrufen so weit wie möglich Mobiltelefone zu nutzen. Moderne Kommunikationslösungen stoßen einfach an ihre Grenzen, vor allem wenn Anwender zunehmend von zu Hause aus arbeiten oder viel unterwegs sind.