Notruf in Teams sicher testen
Fehler im Trockenen finden, 112 nur nach AbspracheNotruf in Teams testen, ohne die Leitstelle zu verärgern

|
WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. |
BERATUNG Du willst Notruf-Routing, Wählpläne und den Abnahmetest mit Provider und Leitstelle sauber planen? Wir gehen das mit dir durch. |
SCHULUNG Für Admins, die Rufwege lesen, simulieren und Notrufrichtlinien selbst sicher pflegen wollen. |
|---|
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.

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.

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).

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. |
|---|

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. |
|---|

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.

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.
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











