Notruf in Teams sicher testen

von

Table of Contents
2
3

Notruf in Teams sicher testen

Fehler im Trockenen finden, 112 nur nach Absprache

Notruf in Teams testen, ohne die Leitstelle zu verärgern

Gegenüberstellung: Links 'Im Trockenen prüfen' (Wählplan, ECRP, PSTN Usage, Provider-Testverfahren), rechts 'Erst dann: abges

WISSEN

Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort.

› Teams-Telefonie

BERATUNG

Du willst Notruf-Routing, Wählpläne und den Abnahmetest mit Provider und Leitstelle sauber planen? Wir gehen das mit dir durch.

› Beratung zur Teams-Telefonie

SCHULUNG

Für Admins, die Rufwege lesen, simulieren und Notrufrichtlinien selbst sicher pflegen wollen.

› Schulung Teams-Telefonie

 

Irgendwann kommt in jedem Teams-Projekt die Frage, vor der sich alle ein bisschen drücken: „Haben wir eigentlich mal den Notruf getestet?“ Die ehrliche Antwort lautet oft: „Na ja, also, jemand hat mal die 112 gewählt und sofort aufgelegt. Es hat geklingelt.“ Herzlichen Glückwunsch. Du hast gerade eine Notrufleitung belegt, einen Disponenten aus einer möglicherweise echten Lage gerissen und dabei fast nichts gelernt. Ob die Rufnummer stimmte, ob der Anruf über den richtigen SBC lief, ob der Sicherheitsdienst benachrichtigt wurde und ob 0112 auch funktioniert hätte, weißt du nämlich immer noch nicht.

Dieser Beitrag zeigt, wie du teams notruf testen kannst, ohne dass in der Leitstelle jemand deinen Namen auf eine Liste schreibt. Der Kern: Fast alles, was beim Notruf schiefgehen kann, findest du im Trockenen, also mit lesenden PowerShell-Befehlen, einer Simulation des Rufwegs und einem Blick in den SBC. Der echte Anruf bei 112 oder 110 ist die Abnahme am Ende, nicht das Werkzeug zur Fehlersuche, und er findet nur mit Absprache statt. Wie du den Notruf grundsätzlich einrichtest, steht in Notruf in Microsoft Teams konfigurieren; der Beitrag gehört zur Serie rund um die Teams-Telefonie.

WARNUNG · Bevor du irgendetwas wählst

Wähle 110 oder 112 nicht zum Testen, solange du keinen Termin mit der zuständigen Leitstelle hast. Jeder unangekündigte Testanruf belegt eine Leitung, die in diesem Moment jemand mit einem echten Notfall brauchen könnte. Der vorsätzliche Missbrauch von Notrufen ist nach § 145 StGB strafbar; ein abgesprochener Test ist das nicht, ein „ich wollte nur mal sehen“ kann es werden.

Rutscht dir trotzdem ein Notruf heraus: Leg nicht auf. Bleib dran, sag, dass es ein Versehen bei einem Test war und kein Notfall vorliegt. Ein stummer Anruf mit Auflegen ist für die Leitstelle das schlechteste Signal, das du senden kannst.

 

FAKTEN · Das Beispiel in diesem Beitrag

Erfundener Tenant Contoso (contoso.com) mit Zentrale in Frankfurt und Standorten in Köln, Berlin, Hamburg und München. Direct Routing über sbc1.contoso.com und sbc2.contoso.com, Rufnummern im Muster +49 69 555 0100. Wählpläne mit Amtsholung 0, weil die Belegschaft das von der alten Anlage so kennt. Notruf-Routingrichtlinie ECRP-Frankfurt mit der PSTN Usage DE-Notruf-Frankfurt.

 

Das Symptom: Niemand weiß, ob der Notruf geht, und alle hoffen

So klingt es im Helpdesk und im Projekt

Beim Notruf ist das Symptom selten ein kaputter Anruf. Meist ist es Unsicherheit, und die äußert sich in Sätzen wie diesen:

„Die Revision will einen Nachweis, dass der Notruf aus allen Standorten funktioniert. Bis Freitag.“

„Ich hab aus Gewohnheit 0112 gewählt, und es kam eine Ansage. Wäre das im Ernstfall auch so?“

„Der Sicherheitsdienst sagt, er bekommt bei Notrufen gar keine Teams-Nachricht. Woher weiß er das eigentlich?“

„Wir haben den SBC getauscht. Müssen wir jetzt alle Standorte einmal 112 anrufen lassen?“

„Der Provider sagt, Testanrufe nur nach Absprache. Mit wem denn?“

Admins erleben dazu das klassische Dilemma: Die Konfiguration ist an fünf Stellen verteilt (Notruf-Routingrichtlinie, Notrufrichtlinie, Netzwerkstandorte, Voice Routes, SBC), jede Stelle kann einzeln falsch sein, und der naheliegende Test ist ausgerechnet der, den man nicht einfach so machen darf. Also wird entweder gar nicht getestet, oder es wird einmal pro Standort „schnell“ angerufen. Beides ist falsch, nur auf unterschiedliche Art.

Die typischen Fehlerbilder auf einen Blick

Was du erlebst

Wahrscheinliche Ursache

Wo du zuerst schaust

0112 landet bei einer Ansage oder scheitert

Maske 0112 fehlt in der ECRP, Wählplan macht aus 0112 eine Ortsnummer

Get-CsTeamsEmergencyCallRoutingPolicy, Test-CsEffectiveTenantDialPlan

112 scheitert ganz

keine Voice Route in der Notruf-Usage, Muster erwartet +112, SBC inaktiv

Get-CsOnlineVoiceRoute, Get-CsOnlinePSTNGateway

Notruf läuft, Sicherheitsdienst merkt nichts

keine ECRP zugewiesen, daher kein Notruf im Teams-Sinn; oder Notrufrichtlinie ohne Benachrichtigung

Get-CsUserPolicyAssignment, Get-CsTeamsEmergencyCallingPolicy

Hamburg ruft über Frankfurt an

ECRP am Netzwerkstandort fehlt, Route zeigt auf falschen SBC

Get-CsTenantNetworkSite, Get-CsOnlineVoiceRoute

Leitstelle sieht falsche Nummer oder Adresse

SBC setzt Stammnummer der Zentrale, Anschluss beim Provider falsch hinterlegt

SBC-Trace, Provider-Vertrag

Nach SBC-Tausch Unsicherheit

Gateway-Liste der Notrufroute nicht angepasst

Get-CsOnlineVoiceRoute, Get-CsOnlinePSTNGateway

 

TIPP · Die gute Nachricht

Jede Zeile dieser Tabelle lässt sich ohne einen einzigen Anruf bei 112 finden. Der echte Testanruf beantwortet am Ende nur noch die Fragen, die du im Tenant nicht sehen kannst: Was macht der Provider mit dem Anruf, und was kommt in der Leitstelle an?

 

Wie ein Notruf technisch seinen Weg nimmt

Für einen normalen Anruf gilt bei Direct Routing die bekannte Kette Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Die Details stehen in Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen. Ein Notruf zweigt davon früh ab, und genau diese Abzweigung musst du beim Testen verstehen. Sonst prüfst du sorgfältig einen Weg, den der Notruf gar nicht nimmt.

Ablaufdiagramm des Notrufs bei Direct Routing: Eingabe 112 prüft ECRP, bei Treffer Maske 0112 zu 112, PSTN Usage, Voice Route

Benutzer › Notruf-Routingrichtlinie › PSTN Usage › Voice Route › SBC › Provider

Die Notruf-Routingrichtlinie (Emergency Call Routing Policy, kurz ECRP) gilt nur für Direct Routing. Sie enthält eine Liste von Notrufnummern. Jede Nummer besteht laut Microsoft aus drei Teilen: der Wählzeichenfolge (Emergency Dial String), null oder mehr Wählmasken (Emergency Dial Mask) und einer PSTN Usage, über die der Notruf geroutet wird. Eine Maske ist eine alternative Eingabe, die in die Wählzeichenfolge übersetzt wird. Mehrere Masken trennst du mit Semikolon. Innerhalb einer Richtlinie darf jede Wählzeichenfolge und jede Maske nur einmal vorkommen.

Wählt jemand eine Nummer, die einer Wählzeichenfolge oder Maske entspricht, behandelt Teams den Anruf als Notruf. Er läuft dann über die PSTN Usage aus der ECRP und nicht über die Usages der Voice Routing Policy des Benutzers. Microsoft weist ausdrücklich darauf hin, dass Teams-Clients Notrufe bei Direct Routing ohne vorangestelltes + senden. Das Muster der Voice Route muss also 112 treffen, nicht +112. Ein bewährtes Muster für Deutschland ist ^(110|112)$.

Die ECRP kannst du Benutzern und Netzwerkstandorten zuweisen. Ist ein Benutzer an einem Netzwerkstandort mit eigener ECRP, gewinnt die Richtlinie des Standorts. So schickst du den Notruf eines Hamburger Gastes in Hamburg über den Hamburger Anschluss und nicht über den seiner Heimatzentrale. Wie die Standortzuordnung funktioniert und warum sie scheitert, steht in Dynamischer Notruf in Teams funktioniert nicht.

FAKTEN · Zwei Richtlinien, zwei Aufgaben

Emergency Call Routing Policy: nur Direct Routing. Legt Notrufnummern, Masken und den Weg fest. Calling-Plan-, Operator-Connect- und Teams-Phone-Mobile-Benutzer bekommen die Notrufnummern ihres Landes laut Microsoft automatisch; eine ECRP hat dort keine Wirkung.

Emergency Calling Policy: gilt für alle Anschlussarten. Legt fest, wer bei einem Notruf benachrichtigt wird (Chat-Nachricht, stumm zugeschaltet, mit Sprechrecht zugeschaltet) und ob Benutzer außerhalb des Firmennetzes ihre Adresse selbst eintragen dürfen.

Beide lassen sich Benutzern und Netzwerkstandorten zuweisen. Am Standort schlägt die Richtlinie des Standorts die des Benutzers.

 

Warum 0112 eine eigene Prüfung verdient

Wer jahrelang an einer Anlage mit Amtsholung telefoniert hat, wählt im Stress die 0 vorweg. Das ist keine Dummheit, das ist Muskelgedächtnis. Hat dein Wählplan Amtsholung 0, wie in Wählplan mit Amtsholung 0 in Teams richtig bauen beschrieben, entscheidet die ECRP, was mit 0112 passiert. Steht 0112 dort als Maske für 112, ist es ein Notruf. Steht es dort nicht, greift der Wählplan, und der macht daraus das, was seine Regeln hergeben.

Vergleich ohne und mit Maske 0112 in der ECRP: Ohne Maske wird 0112 zu +4969112 normaler Anruf, mit Maske zu 112 und Notruf.

Ein Beispiel: Eine Ortsnetzregel für Frankfurt mit dem Muster ^0([1-9]\d+)$ und der Übersetzung +4969$1 macht aus 0112 die Nummer +4969112. Das ist keine Notrufnummer, sondern eine Frankfurter Ortsnummer, die es vermutlich nicht gibt. Was der Provider damit anstellt, ist offen. Sicher ist nur: Teams behandelt den Anruf nicht als Notruf, der Sicherheitsdienst erfährt nichts, und du hast es erst gemerkt, als jemand Hilfe brauchte. Dieselbe Logik gilt für 0110.

WICHTIG · Nicht über den Wählplan „reparieren“

Man könnte versucht sein, im Wählplan eine Regel ^0(110|112)$ › $1 anzulegen. Das liefert zwar wieder 112, aber als normalen Anruf über die Voice Routing Policy, ohne Notrufkennzeichnung, ohne Benachrichtigung und ohne die Standortlogik der ECRP. Der richtige Ort für 0110 und 0112 ist die Maske in der ECRP.

Wie Normalisierungsregeln sonst danebengehen, steht in Normalisierungsregeln in Teams: typische Fehler und wie du sie findest.

 

Was du im Tenant nicht sehen kannst

Hinter dem SBC endet deine Sicht. Ab dort entscheiden Provider und Netz: in welchem Format der Provider die 112 erwartet (mit oder ohne Präfix, mit welcher Absenderrufnummer), wie er sie der zuständigen Leitstelle zuordnet und welche Standortdaten dort ankommen. In Deutschland bekommt die Leitstelle Standortinformationen bei Festnetzanschlüssen in der Regel über den Anschluss beim Netzbetreiber, also über die übermittelte Rufnummer und die dazu hinterlegten Daten. Was genau dein Provider übermittelt, regelt dein Vertrag; frag nach, bevor du es annimmst. Für die Auswahl des Anschlusses lohnt ein Blick in SIP-Trunk-Auswahl für Teams Direct Routing.

Genau deshalb gehört die Absenderrufnummer zum Test. Setzt der SBC für alle Standorte die Stammnummer der Zentrale, landet der Notruf aus Hamburg womöglich mit Frankfurter Daten in der Leitstelle. Wie Rufnummernanzeige und SBC-Manipulation zusammenhängen, steht in Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC.

Diagnose im Trockenen: Schritt für Schritt ohne einen einzigen Notruf

Die folgende Reihenfolge prüft die Kette von vorne nach hinten. Alle Befehle stammen aus dem Modul MicrosoftTeams und lesen nur. Du kannst sie also an einem Dienstagvormittag mit Kaffee ausführen, ohne dass irgendwo ein Telefon klingelt. Als Beispiel dient Julia Wagner aus Frankfurt (julia.wagner@contoso.com).

Pyramide mit fünf Teststufen von unten nach oben: Konfiguration lesen, Rufweg simulieren, SBC-Trace ohne Amt, Testverfahren d

Schritt 1: Welche Richtlinien gelten für den Benutzer?

Get-CsOnlineUser zeigt nur direkte Zuweisungen. Ein leeres Feld heißt: Hier gilt die globale Richtlinie, oder eine Gruppenzuweisung. Get-CsUserPolicyAssignment zeigt auch Gruppenzuweisungen. Warum leere Felder tückisch sind, steht in Teams-Benutzer fällt auf die globale Richtlinie zurück.

$u = 'julia.wagner@contoso.com'

Get-CsOnlineUser -Identity $u |

Select-Object DisplayName, LineURI, EnterpriseVoiceEnabled, TenantDialPlan,

OnlineVoiceRoutingPolicy, TeamsEmergencyCallRoutingPolicy,

TeamsEmergencyCallingPolicy

 

Get-CsUserPolicyAssignment -Identity $u -PolicyType TeamsEmergencyCallRoutingPolicy

Get-CsUserPolicyAssignment -Identity $u -PolicyType TeamsEmergencyCallingPolicy

 

Im Teams Admin Center findest du dasselbe unter Benutzer › Benutzer verwalten › Benutzer › Richtlinien. Notiere dir die effektiven Namen. Wenn dort für die Notruf-Routingrichtlinie Global steht, schau dir die globale Richtlinie genauso genau an wie eine eigene, denn dann trägt sie die ganze Last.

Schritt 2: Was steht in der Notruf-Routingrichtlinie?

Get-CsTeamsEmergencyCallRoutingPolicy |

Select-Object Identity, AllowEnhancedEmergencyServices -ExpandProperty EmergencyNumbers |

Format-Table Identity, EmergencyDialString, EmergencyDialMask, OnlinePSTNUsage

 

Für einen deutschen Standort mit Amtsholung erwartest du zwei Einträge: Wählzeichenfolge 112 mit Maske 0112 und Wählzeichenfolge 110 mit Maske 0110, beide mit einer PSTN Usage, die es tatsächlich gibt. Fehlt die Maske, hast du die 0112-Falle gefunden. Steht als Usage ein Name mit Tippfehler, hast du die nächste. Im Teams Admin Center liegt das unter Sprache › Notfallrichtlinien.

Wählzeichenfolge

Maske

PSTN Usage

Zweck

112

0112

DE-Notruf-Frankfurt

Feuerwehr und Rettungsdienst, auch mit Amtsholung

110

0110

DE-Notruf-Frankfurt

Polizei, auch mit Amtsholung

 

Schritt 3: Welche ECRP gilt am Netzwerkstandort?

Get-CsTenantNetworkSite |

Select-Object Identity, NetworkRegionID, EmergencyCallRoutingPolicy, EmergencyCallingPolicy

 

Hat der Standort Hamburg eine eigene ECRP, gilt sie für alle, die dort sitzen, auch für den Besuch aus Frankfurt. Hat er keine, gilt die Richtlinie des Benutzers. Beides kann richtig sein. Falsch ist nur, wenn du es nicht weißt.

Schritt 4: Was würde der Wählplan aus 0112 machen?

Test-CsEffectiveTenantDialPlan wendet die Normalisierungsregeln des effektiven Wählplans auf eine Eingabe an. Die ECRP berücksichtigt das Cmdlet nicht. Genau das macht es hier nützlich: Es zeigt dir, was mit 0112 passiert, wenn keine Maske greift.

'110','112','0110','0112' | ForEach-Object {

$r = Test-CsEffectiveTenantDialPlan -Identity $u -DialedNumber $_

[pscustomobject]@{ Eingabe = $_; Ergebnis = $r.TranslatedNumber; Regel = $r.MatchingRule }

}

 

Liefert 0112 eine Ortsnummer wie +4969112, ist das kein Fehler des Wählplans. Es ist der Beweis, dass die Maske in der ECRP zwingend ist. Bleibt 110 oder 112 unverändert, ist das in Ordnung; die ECRP übernimmt. Je nach Modulversion kann die Ausgabe etwas anders strukturiert sein; schau dir dann das ganze Objekt mit Format-List an.

Schritt 5: Gibt es eine Route für die Notruf-Usage, und trifft ihr Muster?

Get-CsOnlinePstnUsages | Select-Object -ExpandProperty Usage

 

Get-CsOnlineVoiceRoute | Where-Object { $_.OnlinePstnUsages -contains 'DE-Notruf-Frankfurt' } |

Select-Object Identity, NumberPattern, Priority, OnlinePstnGatewayList

 

# Muster lokal gegen die Wählzeichenfolgen testen (.NET-Regex wie im Dienst)

'110','112','+112' | ForEach-Object { '{0,-5} {1}' -f $_, ($_ -match '^(110|112)$') }

 

Erwartet: 110 und 112 ergeben True, +112 ergibt False. Das ist richtig so, weil Teams die Wählzeichenfolge ohne + sendet. Findet die Abfrage gar keine Route, scheitert der Notruf, bevor er den SBC sieht. Steht in OnlinePstnGatewayList nur ein SBC, hast du für den Notruf keinen Failover. Wie sich Routen gegenseitig überdecken, steht in Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen.

Schritt 6: Sind die SBCs bereit?

Get-CsOnlinePSTNGateway |

Select-Object Identity, Enabled, SendSipOptions, PidfloSupported, MaxConcurrentSessions

 

Enabled muss True sein. PidfloSupported steuert, ob Teams Standortdaten im INVITE an den SBC mitschickt; Microsoft beschreibt das vor allem im Zusammenhang mit Notruf-Routingdiensten in den USA und Kanada. Für Deutschland klärst du mit dem Provider, ob er damit etwas anfangen kann. Den Verbindungsstatus siehst du im Teams Admin Center unter Sprache › Direct Routing. Wie du prüfst, ob der zweite SBC im Ernstfall wirklich übernimmt, steht in SBC-Failover in Teams funktioniert nicht.

Schritt 7: Wer wird benachrichtigt?

Get-CsTeamsEmergencyCallingPolicy |

Select-Object Identity, NotificationGroup, NotificationMode, NotificationDialOutNumber,

ExternalLocationLookupMode

 

Steht keine Benachrichtigungsgruppe drin, erfährt der Sicherheitsdienst nichts, egal wie gut der Rest funktioniert. Prüfe außerdem, ob die Empfänger noch existieren. Eine Verteilerliste, die seit der letzten Umstrukturierung leer ist, benachrichtigt sehr zuverlässig niemanden.

Schritt 8: SBC-Trace ohne Amt

Der letzte trockene Schritt passiert am SBC. Die meisten SBCs können eine Route so einstellen, dass Anrufe nicht zum Provider gehen, sondern auf ein internes Ziel, etwa eine Ansage oder ein Labortelefon. In einem Wartungsfenster, mit einem Testbenutzer und einer eigenen Test-Route am SBC siehst du im Trace, ob der INVITE ankommt, welche Zielnummer drinsteht und welche Absenderrufnummer der SBC Richtung Provider setzen würde. Wichtig: Die Umleitung gehört an eine Stelle, die nur deinen Testbenutzer betrifft, und sie wird danach nachweislich zurückgebaut.

AUS DER PRAXIS · Aus dem eigenen Labor

Uli betreibt für seine eigene Umgebung einen anynode-SBC. Bei jeder Änderung an Wählplan oder Routing schaut er sich im Trace an, in welcher Form 110 und 112 ankommen, bevor irgendjemand über einen echten Test nachdenkt. Der Blick dauert zwei Minuten und hat schon mehr als einmal gezeigt, dass eine scheinbar harmlose Änderung an anderer Stelle den Notrufweg mitverändert hätte. Die Leitstelle hat davon nie etwas mitbekommen. So soll es sein.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker

Der Rufweg-Simulator spielt für einen Benutzer eine Eingabe wie 0112 durch die Kette aus Wählplan, Normalisierung, PSTN Usage, Voice Route und Gateway durch und zeigt, an welcher Station sie hängen bleibt, ohne einen Anruf auszulösen. Im Benutzer-Steckbrief stehen Notrufstandort und effektive Richtlinien nebeneinander, einschließlich der Angabe, ob sie von der globalen Richtlinie geerbt sind.

Befunde mit Prüffall weisen auf fehlende oder unvollständige Notrufkonfiguration hin; die Ampel zeigt, in welchem Bereich sie liegen. Der Routing-Assistent meldet vor dem Anwenden, wenn eine Notrufroute mit gleichem Muster bereits existiert oder ein SBC deaktiviert ist.

Mehr dazu auf der Produktseite Teams-Telefonie Diagnostiker. 15 Tage kostenlos testen.

 

Rufweg-Simulator zeigt einen Auslandsanruf, der scheitert, weil keine Voice Route der Policy VRP-Berlin passt.
So siehst du im Rufweg-Simulator, an welcher Station ein Anruf scheitert, ohne ihn zu wählen (Demo-Daten).

Behebung und der abgestimmte Testanruf

Maske ergänzen, mit Rollback-Plan

Fehlen die Masken, ergänzt du sie in der ECRP. Sichere vorher den Ist-Stand, denn Set-CsTeamsEmergencyCallRoutingPolicy ersetzt mit -EmergencyNumbers die komplette Liste. Wer nur die neue Nummer übergibt, hat danach nur noch die neue Nummer.

# 1. Ist-Stand sichern

$stamp = Get-Date -Format 'yyyyMMdd-HHmm'

Get-CsTeamsEmergencyCallRoutingPolicy -Identity 'ECRP-Frankfurt' |

ConvertTo-Json -Depth 5 | Out-File "ecrp-frankfurt-$stamp.json" -Encoding utf8

 

# 2. Neue Liste vollständig aufbauen (New-CsTeamsEmergencyNumber erzeugt nur ein Objekt im Speicher)

$n112 = New-CsTeamsEmergencyNumber -EmergencyDialString '112' -EmergencyDialMask '0112' `

-OnlinePSTNUsage 'DE-Notruf-Frankfurt'

$n110 = New-CsTeamsEmergencyNumber -EmergencyDialString '110' -EmergencyDialMask '0110' `

-OnlinePSTNUsage 'DE-Notruf-Frankfurt'

 

# 3. Anwenden

Set-CsTeamsEmergencyCallRoutingPolicy -Identity 'ECRP-Frankfurt' -EmergencyNumbers $n112, $n110

 

Rollback: Aus der gesicherten JSON-Datei baust du die alte Liste mit New-CsTeamsEmergencyNumber wieder auf und setzt sie mit demselben Befehl zurück. Danach wiederholst du die Schritte 2 bis 5 der Diagnose. Erst wenn die trockene Prüfung grün ist, denkst du über den nächsten Schritt nach. Änderungen an Richtlinien brauchen erfahrungsgemäß eine Weile, bis sie beim Client ankommen; plane das ein, bevor du ein Ergebnis bewertest.

WARNUNG · Keine Notrufroute ohne Backup

Ändere Notrufrouten und Gateway-Listen nicht im laufenden Betrieb ohne Sicherung. Ein Tippfehler in der PSTN Usage oder ein Muster mit + vor der 112 lässt alle Notrufe des Standorts scheitern, und das merkst du im Alltag nicht. Prüfe direkt nach jeder Änderung mit den Befehlen aus Schritt 2 und 5.

 

Routing-Assistent der Teams-Telefonie-Diagnostik mit Konfliktanzeige: kritischer Hinweis auf deaktivierten SBC und niedriger
So erkennst du vor dem Anwenden, wenn eine Notrufroute mit dem Muster ^(110 112)$ schon existiert oder der gewählte SBC deaktiviert ist (Demo-Daten).

Testnummern und Testverfahren der Provider

Microsoft beschreibt eine echte Testnummer nur für Nordamerika: Calling-Plan-, Operator-Connect- und Teams-Phone-Mobile-Benutzer in den USA und Kanada können 933 wählen und bekommen von einem Bot Rufnummer und Adresse zurückgespielt. Direct-Routing-Kunden in den USA sollen sich laut Microsoft mit ihrem Notruf-Routingdienst über einen Testdienst abstimmen. Für Deutschland gibt es kein vergleichbares, von Microsoft beschriebenes Angebot. Und nein, 933 wählst du in Frankfurt bitte auch nicht, nur um zu sehen, was passiert.

Was es gibt, hängt vom Provider ab. Manche Anbieter von SIP-Trunks haben ein Verfahren für Notruftests, etwa ein Testfenster, eine Prüfung der Zuordnung des Anschlusses zur Leitstelle oder eine Bestätigung, in welchem Format sie Notrufe erwarten. Andere sagen schlicht: Testen nur nach Rücksprache mit der Leitstelle. Erfinde hier nichts und verlass dich nicht auf Foren. Frag schriftlich und lass dir die Antwort schriftlich geben.

Frage an den Provider

Warum sie wichtig ist

Gibt es ein Testverfahren oder eine Testnummer für Notrufe?

Wenn ja, ersetzt es oft den Anruf bei der Leitstelle oder bereitet ihn vor.

In welchem Format erwartet ihr 110 und 112 vom SBC?

Der SBC muss die Zielnummer passend zum Trunk umschreiben; Teams sendet 112 ohne +.

Welche Absenderrufnummer muss ein Notruf tragen?

Davon hängt ab, welcher Anschluss und welche Adresse der Leitstelle zugeordnet werden.

Welche Standortdaten übermittelt ihr an die Leitstelle?

Klärt, ob die hinterlegte Anschlussadresse zu jedem Standort passt.

Wie läuft ein abgestimmter Testanruf bei euch ab?

Manche Provider wollen vorab informiert werden oder nennen Ansprechpartner.

 

Abstimmung mit der Leitstelle

Für 112 ist in der Regel die Leitstelle für Feuerwehr und Rettungsdienst des Landkreises oder der kreisfreien Stadt zuständig, für 110 die Polizei. Pro Standort kann das eine andere Leitstelle sein; Frankfurt, Köln, Berlin, Hamburg und München haben jeweils ihre eigene. Den Kontakt suchst du über die Verwaltung oder eine allgemeine Dienstnummer, niemals über die Notrufnummer selbst. Ein Anruf bei 112 mit der Frage, ob man mal 112 testen dürfe, ist der Klassiker, den die Disponenten auf Weihnachtsfeiern erzählen.

Zeitleiste eines Notruftests in sechs Etappen: Provider fragen (T-14), Leitstelle anfragen (T-10), Trockenübung (T-3), intern

Was du anfragst, sollte kurz und konkret sein:

Zweck: Abnahme eines neuen Telefonieanschlusses für Notrufe, kein Lasttest.

Zeitfenster: ein Termin, den die Leitstelle vorschlägt; außerhalb absehbarer Spitzenzeiten.

Umfang: wie viele Anrufe von welchen Absenderrufnummern und Standorten, zum Beispiel einer aus Frankfurt mit +49 69 555 0100.

Ablauf: Eröffnung mit „angemeldeter Testanruf, kein Notfall“, Bestätigung von angezeigter Nummer und Adresse, sofortiges Ende.

Ansprechpartner: eine Person mit Rückrufnummer, die während des Fensters erreichbar ist.

WICHTIG · Die Leitstelle hat Vorrang

Bittet dich die Leitstelle, aufzulegen oder später anzurufen, legst du auf. Lehnt sie einen Test ab, akzeptierst du das und bleibst bei den Stufen 1 bis 4. Ein abgelehnter Test ist kein Grund, es „einfach so“ zu probieren.

 

Die Checkliste für den Notruftest

Nr.

Prüfpunkt

Wie

Stufe

1

Effektive ECRP und Notrufrichtlinie je Testbenutzer bekannt

Get-CsOnlineUser, Get-CsUserPolicyAssignment

trocken

2

112 und 110 als Wählzeichenfolge, 0112 und 0110 als Maske

Get-CsTeamsEmergencyCallRoutingPolicy

trocken

3

PSTN Usage der ECRP existiert

Get-CsOnlinePstnUsages

trocken

4

Voice Route mit ^(110|112)$, zwei Gateways

Get-CsOnlineVoiceRoute, lokaler Regex-Test

trocken

5

Wählplan macht aus 0112 nichts Gefährliches, oder Maske fängt es ab

Test-CsEffectiveTenantDialPlan

trocken

6

ECRP und Notrufrichtlinie an den Netzwerkstandorten

Get-CsTenantNetworkSite

trocken

7

SBCs aktiv, Failover vorhanden

Get-CsOnlinePSTNGateway, Teams Admin Center

trocken

8

Benachrichtigungsgruppe existiert und ist besetzt

Get-CsTeamsEmergencyCallingPolicy

trocken

9

Zielnummer und Absenderrufnummer am SBC korrekt

SBC-Trace mit Test-Route auf internes Ziel

Labor

10

Format, Standortdaten und Testverfahren mit dem Provider geklärt

schriftliche Anfrage

Provider

11

Termin, Umfang und Ablauf mit der Leitstelle abgestimmt

Verwaltungs- oder Dienstnummer

Leitstelle

12

Sicherheitsdienst und Empfang vorab informiert

Mail, Ticket

intern

13

Testanruf: angemeldet, kurz, Nummer und Adresse bestätigt

nur im vereinbarten Fenster

abgestimmt

14

Protokoll mit Datum, Uhrzeit, Ergebnis, Abweichungen

Ticket oder Abnahmedokument

Nachbereitung

 

TIPP · Benachrichtigung ohne Notruf üben

Ob der Sicherheitsdienst mit einer Teams-Benachrichtigung etwas anfangen kann, ist auch eine Frage der Organisation: Wer liest den Chat, wer geht hin, wer öffnet die Tür für den Rettungsdienst? Das lässt sich als Tischübung mit dem Sicherheitsdienst durchspielen, ganz ohne Anruf. Die Technik prüfst du dann einmal im Rahmen des abgestimmten Tests mit.

 

Vorbeugung: damit der nächste Test langweilig wird

Der beste Notruftest ist einer, bei dem nichts Neues herauskommt. Das erreichst du, wenn die trockenen Prüfungen nicht einmal im Projekt laufen, sondern regelmäßig und nach jeder Änderung.

Notruf als Pflichtpunkt im Change: Jede Änderung an Wählplan, Voice Routes, PSTN Usages oder SBC endet mit den Schritten 2, 4 und 5 aus der Diagnose.

Ist-Stand regelmäßig sichern: ECRP, Notrufrichtlinien, Routen und Netzwerkstandorte als JSON exportieren und vergleichen. Unbemerkte Änderungen findest du so, bevor sie wehtun.

Neue Standorte mit Abnahme: Kein Standort geht live, bevor die Checkliste bis Punkt 10 grün ist. Den abgestimmten Anruf planst du für die Inbetriebnahme gleich mit ein.

SBC-Tausch und Provider-Wechsel: Beides ist ein neuer Notrufweg. Behandle es so, mit Trockenübung und, wenn der Provider es verlangt, abgestimmtem Test.

Verantwortung festlegen: Wer pflegt ECRP und Benachrichtigungsgruppen, wer spricht mit Provider und Leitstelle? Ohne Namen bleibt es liegen.

Unbemerkte Änderungen zwischen zwei Prüfungen findest du mit einem regelmäßigen Vergleich, wie in Konfigurationsdrift in der Teams-Telefonie erkennen beschrieben. Wer die Zuständigkeiten für Notrufdaten zwischen Telefonie-, Netzwerk- und Sicherheitsteam sauber regeln will, findet Ansätze in Microsoft Teams Telefonie-Governance. Wenn du den Notrufweg für mehrere Standorte samt Abnahme mit Provider und Leitstelle planen willst, hilft dir die Beratung zur Teams-Telefonie. In der Schulung Teams-Telefonie übt dein Team, Rufwege selbst zu lesen und zu simulieren.

WEITERLESEN · Passend zum Thema

› Notrufadresse fehlt in Teams: was bei 112 wirklich passiert

› Dynamischer Notruf in Teams funktioniert nicht

› Wählplan mit Amtsholung 0 in Teams richtig bauen

› Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen

 

FAQ: Notruf in Teams testen

Darf ich zum Testen einfach 112 anrufen?

Nein, nicht ohne Absprache. Ein unangekündigter Testanruf belegt eine Notrufleitung. Teste zuerst im Trockenen und vereinbare für einen echten Testanruf einen Termin mit der zuständigen Leitstelle, angefragt über deren Verwaltungs- oder Dienstnummer.

Gibt es in Deutschland eine Testnummer wie 933?

Die Testnummer 933 beschreibt Microsoft nur für Calling Plans, Operator Connect und Teams Phone Mobile in den USA und Kanada. Für Deutschland gibt es kein vergleichbares Angebot von Microsoft. Ob dein Provider ein Testverfahren anbietet, erfährst du nur bei ihm.

Warum muss ich 0112 extra prüfen?

Weil Benutzer mit Amtsholung aus Gewohnheit die 0 vorweg wählen. Ohne Maske 0112 in der Notruf-Routingrichtlinie greift der Wählplan und macht daraus je nach Regel eine Ortsnummer wie +4969112. Das ist dann kein Notruf mehr.

Muss das Muster der Notrufroute +112 oder 112 enthalten?

112. Laut Microsoft senden Teams-Clients Notrufe bei Direct Routing ohne + vor der Wählzeichenfolge. Ein Muster wie ^(110|112)$ trifft beide deutschen Notrufnummern.

Reicht es, den normalen Rufweg zu testen?

Nein. Ein Notruf nutzt die PSTN Usage aus der Notruf-Routingrichtlinie, nicht die aus der Voice Routing Policy. Ein funktionierender Ortsanruf sagt über den Notrufweg nichts aus.

Wie teste ich, ob der Sicherheitsdienst benachrichtigt wird?

Prüfe die Notrufrichtlinie mit Get-CsTeamsEmergencyCallingPolicy auf Benachrichtigungsgruppe und Modus und ob die Empfänger existieren. Den organisatorischen Ablauf übst du als Tischübung; die technische Benachrichtigung prüfst du beim abgestimmten Testanruf mit.

Was mache ich, wenn versehentlich ein Notruf rausgeht?

Nicht auflegen. Bleib in der Leitung, erkläre, dass es ein Versehen bei einem Test war und kein Notfall vorliegt, und beantworte die Rückfragen. Ein Auflegen ohne Erklärung führt eher zu Rückrufen oder einem Einsatz.

Wie oft sollte ich den Notruf testen?

Trocken nach jeder Änderung an Wählplan, Routing, SBC oder Richtlinien und zusätzlich regelmäßig, etwa quartalsweise. Einen echten, abgestimmten Testanruf brauchst du bei der Inbetriebnahme eines Standorts, nach einem Provider- oder SBC-Wechsel und wenn Provider oder Revision es verlangen.

Fazit: Teste trocken, ruf selten an, und dann richtig

Notruf in Teams zu testen heißt nicht, 112 zu wählen und zu lauschen. Es heißt, den Weg vom Benutzer über die Notruf-Routingrichtlinie, die PSTN Usage und die Voice Route bis zum SBC Station für Station zu prüfen, und zwar mit Befehlen, die nichts auslösen. 110, 112 und vor allem 0112 gehören dabei auf jede Liste. Was danach noch offen ist, klärst du mit dem Provider. Und ganz am Ende steht ein einziger, angemeldeter Anruf, bei dem die Leitstelle weiß, dass du kommst.

Das ist weniger aufregend als der „mal schnell“-Test. Aber die Aufregung hebst du dir für den Tag auf, an dem jemand wirklich Hilfe braucht. Dann soll wenigstens das Telefon funktionieren. Die Einzelheiten zu Notrufnummern, Masken und PSTN Usages dokumentiert Microsoft in Verwalten von Notrufroutingrichtlinien für Direct Routing.

Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/notruf-in-teams.pdf — © Ulrich B. Boddenberg · boddenberg.de

Noch Fragen? Frag Uli

Du hast eine Frage zu diesem Thema? Schreib sie einfach hier rein. Ich antworte persönlich, kurz und ohne Verkaufsgespräch.

Antwort innerhalb von 24 Stunden

Deine Mailadresse nutze ich nur, um dir zu antworten. Kein Newsletter, keine Weitergabe. Zur Datenschutzerklärung