Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Notruf, Sprachqualität und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Dein Routing ist über Jahre gewachsen und keiner traut sich mehr ran? Wir räumen es gemeinsam mit dir auf. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Policies, Usages und Routen selbst bauen, lesen und sicher ändern wollen. › Schulung Teams-Telefonie

 

Es gibt in der Teams-Telefonie einen Moment, den fast jeder Admin einmal erlebt: Die Route ist angelegt, das Muster stimmt, der SBC ist grün, der Regex-Tester sagt „Match“. Und trotzdem geht der Anruf woanders hin. Oder gar nicht. Der Fehler sitzt dann selten in einem einzelnen Objekt, sondern in der Beziehung zwischen dreien: Voice Routing Policy, PSTN Usage und Voice Route. Ein Dreieck, das auf dem Papier harmlos aussieht und in der Praxis zuverlässig Wochenenden frisst.

In diesem Beitrag geht es genau um dieses Zusammenspiel von voice routing policy pstn usage und Route: wer wen enthält, in welcher Reihenfolge Teams prüft und was „erste passende Route“ im Detail heißt. Danach findest du Schritt für Schritt heraus, welchen Weg ein Anruf bei einem bestimmten Benutzer tatsächlich nimmt, wie du eine falsche Reihenfolge korrigierst, ohne den Notruf mitzureißen, und wie du verhinderst, dass dir das in einem halben Jahr wieder passiert.

Die Grundlagen zu Direct Routing und SBC wiederholen wir hier nur so weit wie nötig. Den Gesamtüberblick findest du auf der Seite Teams-Telefonie, die Einrichtung von Anfang an in Teams Direct Routing einrichten.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit den Standorten Frankfurt und München. Frankfurt hat den Rufnummernblock +49 69 555 0xxx und telefoniert über sbc1.contoso.com, München hat +49 89 555 0xxx und den SBC sbc2.contoso.com. Beide SBCs sind sich gegenseitig Ersatzweg für nationale Gespräche. Es gibt zwei Voice Routing Policies (VRP-FRA und VRP-MUC), vier PSTN Usages (FRA-Lokal, MUC-Lokal, DE-National, International) und sieben Voice Routes. Alle Diagnosebefehle sind lesend (Get- und Test-Cmdlets aus dem Modul MicrosoftTeams). Geschrieben wird erst im Abschnitt zur Behebung, mit Sicherung und Rückweg.

 

Das Symptom: „Die Route ist doch da!“

Fehler in der Reihenfolge haben eine unangenehme Eigenschaft: Sie produzieren selten eine saubere Fehlermeldung. Der Anruf geht ja meistens raus. Nur eben über den falschen SBC, mit der falschen Rufnummernanzeige, zur falschen Leitstelle oder mit einem Umweg über einen anderen Standort. Gemeldet wird das im Helpdesk in Sätzen, die zunächst nichts miteinander zu tun haben.

Was der Helpdesk hört	Was technisch passiert	Wahrscheinliche Ursache
„Seit gestern gehen unsere Münchner Anrufe über Frankfurt.“	Eine Route einer anderen Usage gewinnt, bevor die lokale geprüft wird	Usage-Reihenfolge in der Policy falsch
„Der Ersatz-SBC springt nicht ein, obwohl er läuft.“	Der Ersatz liegt in einer späteren Usage, die nie ausgewertet wird	Failover über Usages statt über Prioritäten gebaut
„Die neue Route für 0800 greift einfach nicht.“	Eine allgemeinere Route mit kleinerer Prioritätszahl passt zuerst	Priorität innerhalb der Usage falsch
„Bei Kollege A geht es, bei Kollegin B nicht.“	Unterschiedliche Policies oder Rückfall auf Global	Zuweisung fehlt oder falsche Policy
„Ins Ausland geht nichts mehr, Inland schon.“	Keine Route in keiner Usage passt	Usage fehlt in der Policy oder Route hängt an keiner Usage
„Der Notruf aus München kam in Frankfurt an.“	Ein Sammelmuster wie .* fängt auch 110 und 112	Sammel-Usage vor der lokalen Usage

 

Gemeinsam ist allen Fällen: Jedes Objekt für sich ist korrekt. Die Route existiert, das Muster ist gültig, der SBC ist erreichbar. Falsch ist die Stelle, an der das Objekt in der Prüfreihenfolge steht. Deshalb hilft es auch so wenig, eine Route im Teams Admin Center anzuschauen. Du siehst dort nur eine Ecke des Dreiecks.

WICHTIG · Erst prüfen, ob überhaupt das Routing schuld ist Wenn ein Anruf gar nicht rausgeht, liegt die Ursache oft schon vor dem Dreieck: fehlende Lizenz, kein Enterprise Voice, ein Wählplan, der die Nummer nicht nach E.164 übersetzt. Den kompletten Rufweg von vorne prüfst du mit der Anleitung in Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen. Dieser Beitrag setzt voraus, dass die Nummer bereits sauber normalisiert ist, zum Beispiel als +49895550142 oder 112.

 

Wie Teams wirklich routet: das Dreieck

Wo das Dreieck in der Kette sitzt

Ein abgehender Anruf läuft in Teams durch eine feste Kette: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Wählplan und Normalisierung machen aus dem, was der Benutzer tippt, eine Nummer, idealerweise im Format E.164. Ab der Voice Routing Policy wird nur noch mit dieser normalisierten Nummer gearbeitet. Die Muster der Routen sehen also nie „089 555 0142“, sondern „+49895550142“. Wer das vergisst, baut Routen für Nummern, die es an dieser Stelle gar nicht mehr gibt. Mehr dazu in Normalisierungsregeln in Teams: typische Fehler und wie du sie findest.

Eine Besonderheit nennt Microsoft ausdrücklich: Enthält die gewählte Nummer eine Durchwahl im Format ;ext=, wird das Muster nur gegen die Nummer ohne diesen Zusatz geprüft.

Wer enthält wen?

Die drei Objekte sind keine Hierarchie im Sinne von Ordnern, sondern eine Verknüpfung über Namen. Das ist der Grund, warum sie so leicht durcheinandergeraten.

Objekt	Was es enthält	Wer bestimmt die Reihenfolge	Lesendes Cmdlet
Voice Routing Policy	Geordnete Liste von PSTN Usages (OnlinePstnUsages); wird Benutzern zugewiesen	Die Position in der Liste	Get-CsOnlineVoiceRoutingPolicy
PSTN Usage	Nur einen Namen. Welche Routen dazugehören, steht in den Routen selbst	Keine eigene Reihenfolge	Get-CsOnlinePstnUsage
Voice Route	Muster (NumberPattern), Priorität, Liste von Usages, Liste von Gateways	Die Priorität, kleinste Zahl zuerst	Get-CsOnlineVoiceRoute
Gateway (SBC)	Verbindung zum SBC samt Einstellungen	Zufällig innerhalb einer Route	Get-CsOnlinePSTNGateway

 

Zwei Dinge sind daran wichtig. Erstens: Die PSTN Usage ist nur ein Etikett. Es gibt eine einzige, globale Liste aller Usage-Namen im Tenant. Eine Route „gehört“ zu einer Usage, weil der Name der Usage in der Route eingetragen ist, und eine Policy „enthält“ eine Usage, weil ihr Name in der Policy steht. Dieselbe Usage kann in beliebig vielen Policies stecken, dieselbe Route an mehreren Usages hängen. Zweitens: Die Priorität ist eine Eigenschaft der Route, nicht der Verbindung zwischen Route und Usage. Hängt eine Route an zwei Usages, hat sie in beiden dieselbe Priorität.

Was „erste passende Route“ genau bedeutet

Die Formel „Teams nimmt die erste passende Route“ ist richtig, aber unvollständig. Erste in welcher Liste? Es sind zwei Ebenen, und die äußere schlägt die innere.

Ebene 1, die Usages: Teams geht die Usages der Policy in der eingetragenen Reihenfolge durch. Microsoft formuliert es unmissverständlich: Wird in der ersten Usage ein Treffer gefunden, werden die übrigen Usages nie ausgewertet.

Ebene 2, die Routen: Innerhalb der Usage, die gerade dran ist, betrachtet Teams alle Routen, deren Muster zur Nummer passen, und probiert sie nach Priorität. Die kleinste Zahl kommt zuerst.

Ebene 3, die Gateways: Innerhalb einer Route versucht Teams die eingetragenen SBCs laut Microsoft in zufälliger Reihenfolge. Die Reihenfolge, in der du sie einträgst, ist also keine Rangfolge.

Ersatzweg: Ist keiner der SBCs der ersten passenden Route verfügbar, nimmt Teams die nächste passende Route derselben Usage. Sind alle durch, scheitert der Anruf.

Kein Treffer: Passt in keiner Usage irgendeine Route, scheitert der Anruf. Ausnahme: Benutzer mit Calling Plan, bei denen der Calling Plan als automatischer letzter Weg dient.

FAKTEN · Was Microsoft dokumentiert Die Reihenfolge der PSTN Usages in einer Voice Routing Policy ist entscheidend: Die Usages werden der Reihe nach angewendet, und wird in der ersten ein Treffer gefunden, werden die weiteren nie ausgewertet. Die Priorität einer Route legt fest, in welcher Reihenfolge mehrere passende Routen angewendet werden. Die niedrigste Zahl zuerst, dann aufsteigend. Die SBCs innerhalb einer Route werden in zufälliger Reihenfolge versucht, auch wenn die Routen selbst Prioritäten haben. Bei weitergeleiteten oder vermittelten eingehenden Anrufen wird der SBC, über den der Anruf hereinkam, bevorzugt, wenn er auch als Ausgang in Frage kommt. Seine Priorität wird dann ignoriert. Hat ein Benutzer mit Calling Plan zusätzlich eine Voice Routing Policy, prüft Teams zuerst deren Muster. Passt keines, geht der Anruf über den Calling Plan.

 

Der dritte Spiegelstrich der Skizze ist der, an dem die meisten Failover-Konzepte scheitern. Wer den Ersatz-SBC in eine eigene Usage „DE-National-Backup“ hinter „DE-National“ legt, hat keinen Ersatzweg gebaut, sondern Dekoration. Die Backup-Usage wird nie erreicht, solange in DE-National irgendeine Route passt, ganz egal, ob deren SBC gerade brennt. Der Ersatzweg gehört als zweite Route mit demselben Muster und höherer Prioritätszahl in dieselbe Usage. Genau so zeigt es auch Microsoft in der Dokumentation. Vertiefung dazu in SBC-Failover in Teams funktioniert nicht.

Das Beispiel Frankfurt und München

So sieht ein sauber gebautes Dreieck für zwei Standorte aus. Die lokalen Usages enthalten Notruf und Ortsnetz und hängen nur an der Policy ihres Standorts. DE-National und International werden von beiden Policies geteilt.

Policy	Usage	Route	Muster	Prio	Gateways
VRP-FRA	FRA-Lokal	FRA-Notruf	^(110|112)$	1	sbc1.contoso.com
VRP-FRA	FRA-Lokal	FRA-Ortsnetz	^\+4969\d+$	2	sbc1.contoso.com
VRP-MUC	MUC-Lokal	MUC-Notruf	^(110|112)$	3	sbc2.contoso.com
VRP-MUC	MUC-Lokal	MUC-Ortsnetz	^\+4989\d+$	4	sbc2.contoso.com
beide	DE-National	DE-National-1	^\+49\d+$	5	sbc1.contoso.com
beide	DE-National	DE-National-2	^\+49\d+$	6	sbc2.contoso.com
beide	International	Welt	^\+(?!49)\d+$	9	sbc1, sbc2

 

Zur Lesart der Muster: ^ und $ verankern Anfang und Ende, \+ ist das maskierte Pluszeichen, \d+ steht für eine oder mehrere Ziffern. ^\+4989\d+$ trifft also jede Münchner Nummer im Format E.164, und ^\+(?!49)\d+$ trifft jede Nummer mit +, die nicht mit 49 weitergeht. Die Notrufnummern stehen ohne +49, weil ein korrekter Wählplan 110 und 112 unverändert lässt. Spielen wir drei Anrufe durch:

Wer ruft	Normalisierte Nummer	Gewinnende Usage	Route	SBC
Benutzer in Frankfurt (VRP-FRA)	+49695550100	FRA-Lokal (1)	FRA-Ortsnetz	sbc1
Benutzer in München (VRP-MUC)	+49695550100	DE-National (2)	DE-National-1, sonst -2	sbc1, sonst sbc2
Benutzer in München (VRP-MUC)	112	MUC-Lokal (1)	MUC-Notruf	sbc2
Benutzer in Frankfurt (VRP-FRA)	+441632960000	International (3)	Welt	sbc1 oder sbc2

 

Interessant ist die zweite Zeile: Der Münchner Anruf nach Frankfurt passt nicht zu MUC-Lokal, also geht es in DE-National weiter. Dort passen beide Routen; DE-National-1 hat die kleinere Zahl und schickt den Anruf über sbc1 in Frankfurt. Das ist hier gewollt. Wäre es nicht gewollt, wäre es Hairpinning mit Ansage.

Die typischen Fehlerbilder

Und jetzt die Version, die es in echten Tenants gibt. Jemand hat VRP-MUC im Teams Admin Center angelegt und die Usages in der Reihenfolge angeklickt, in der sie ihm einfielen. International kam zuerst. In International hängt außerdem noch eine Uralt-Route „Alles“ mit dem Muster .* aus der Testphase, die damals jeden Anruf an sbc1 schickte. Microsoft zeigt .* in der Dokumentation selbst als Muster für „alles an einen SBC“. Es ist also kein exotischer Fehler, sondern ein sehr naheliegender.

Das Ergebnis: Ein Notruf aus München trifft in Usage 1 auf .*, Treffer, Ende der Prüfung. MUC-Lokal mit der korrekten Notrufroute wird nie angeschaut. Der Anruf verlässt Teams über den Frankfurter SBC. Ob er bei der richtigen Leitstelle ankommt, hängt dann davon ab, was der Provider mit der Herkunft des Anrufs macht, und „hängt davon ab“ ist beim Notruf die falsche Antwort.

Fehlerbild	Erkennungszeichen	Wo du es siehst
Sammel-Usage vor der lokalen Usage	Lokale Routen werden nie benutzt, alles läuft über einen SBC	Reihenfolge in OnlinePstnUsages der Policy
Backup als eigene Usage	Fällt der Haupt-SBC aus, scheitern Anrufe, statt umzuleiten	Zwei Usages mit gleichen Mustern hintereinander
Allgemeine Route mit kleinerer Prioritätszahl	Spezielle Route greift nie	Priorität im Vergleich zu überlappenden Mustern
Route hängt an keiner Usage	Muster passt, wird aber nie gefunden	OnlinePstnUsages der Route leer
Usage in keiner Policy	Routen sind verwaist	Usage-Name taucht in keiner Policy auf
Benutzer ohne eigene Policy	Benutzer telefoniert mit Global	OnlineVoiceRoutingPolicy leer

 

Wie Muster sich gegenseitig überdecken und welche Regex-Fehler dabei typisch sind, behandelt Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen ausführlich. Hier bleibt es bei der Reihenfolge.

Diagnose Schritt für Schritt

Für die Diagnose brauchst du das Modul MicrosoftTeams und eine Rolle, die Telefonie-Einstellungen lesen darf. Alle Befehle in diesem Abschnitt ändern nichts. Du kannst sie also auch am Freitagnachmittag ausführen, ohne dass jemand nervös wird.

Schritt 1: Welche Policy hat der Benutzer wirklich?

Connect-MicrosoftTeams $upn = "anna.berger@contoso.com" Get-CsOnlineUser -Identity $upn | Select-Object DisplayName, LineUri, OnlineVoiceRoutingPolicy, TenantDialPlan, UsageLocation Get-CsUserPolicyAssignment -Identity $upn -PolicyType OnlineVoiceRoutingPolicy

 

Ist OnlineVoiceRoutingPolicy leer, greift die globale Policy. Das ist nicht automatisch falsch, aber selten Absicht. Get-CsUserPolicyAssignment zeigt zusätzlich, ob die Policy direkt oder über eine Gruppe zugewiesen ist. Wenn der Benutzer auf Global zurückfällt, obwohl er das nicht sollte, lies weiter in Teams-Benutzer fällt auf die globale Richtlinie zurück.

Schritt 2: Welche Nummer kommt aus dem Wählplan?

Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "0895550142" Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "112"

 

Das Feld TranslatedNumber ist die Nummer, mit der die Routen arbeiten. Steht dort nicht +49895550142, sondern etwas ohne Pluszeichen, ist das Dreieck unschuldig und der Wählplan dran.

Schritt 3: Die Usages der Policy in Reihenfolge

(Get-CsOnlineVoiceRoutingPolicy -Identity "Tag:VRP-MUC").OnlinePstnUsages (Get-CsOnlineVoiceRoutingPolicy -Identity "Global").OnlinePstnUsages (Get-CsOnlinePstnUsage).Usage

 

Die Ausgabe der ersten Zeile ist die Prüfreihenfolge, von oben nach unten. Schreib sie dir ab. Die letzte Zeile liefert alle Usage-Namen des Tenants; was dort steht, aber in keiner Policy auftaucht, ist ein Kandidat für verwaiste Routen.

Schritt 4: Alle Routen mit Priorität, Muster und Gateways

Get-CsOnlineVoiceRoute | Sort-Object Priority | Format-Table Identity, Priority, NumberPattern, @{n="Usages";e={$_.OnlinePstnUsages -join ", "}}, @{n="Gateways";e={$_.OnlinePstnGatewayList -join ", "}} -AutoSize

 

Achte auf Routen mit leerer Spalte Usages oder Gateways und auf Muster wie .*, \d+ oder ^\+49, die weit mehr abdecken, als ihr Name vermuten lässt.

Schritt 5: Den Rufweg nachspielen

Ein lesendes Test-Cmdlet, das den kompletten Weg durch Policy, Usages und Routen für Teams online simuliert, gibt es im Modul MicrosoftTeams nicht. Die Logik ist aber einfach genug, um sie mit ein paar Zeilen nachzubauen. Das folgende Skript liest nur und verwendet die .NET-Regex-Engine, also dieselbe Syntax wie die Muster der Routen:

$nummer = "112" # TranslatedNumber aus Schritt 2 $vrp = (Get-CsOnlineUser -Identity $upn).OnlineVoiceRoutingPolicy $vrpId = if ([string]::IsNullOrEmpty("$vrp")) { "Global" } else { "Tag:$vrp" } $usages = (Get-CsOnlineVoiceRoutingPolicy -Identity $vrpId).OnlinePstnUsages $routen = Get-CsOnlineVoiceRoute | Sort-Object Priority $i = 0 foreach ($u in $usages) { $i++ $treffer = $routen | Where-Object { $_.OnlinePstnUsages -contains $u -and [regex]::IsMatch($nummer, $_.NumberPattern) } if ($treffer) { "Usage $i '$u' gewinnt. Weitere Usages werden nicht geprüft." $treffer | Format-Table Identity, Priority, NumberPattern, @{n="Gateways";e={$_.OnlinePstnGatewayList -join ", "}} break } "Usage $i '$u': kein Treffer" }

 

Im Fehlerfall aus der Skizze meldet das Skript für den Münchner Benutzer und die Nummer 112 sofort „Usage 1 'International' gewinnt“ und zeigt die Route Alles mit sbc1. Spätestens hier ist die Diskussion „aber die Notrufroute ist doch da“ beendet.

WARNUNG · Notruf hat bei Direct Routing manchmal einen eigenen Weg Ist dem Benutzer oder seinem Netzwerkstandort eine Notruf-Richtlinie für die Anrufweiterleitung zugeordnet, die für 112 eine eigene PSTN Usage vorgibt, wird der Notruf über diese Usage geroutet und nicht über die Reihenfolge der Voice Routing Policy. Das Skript oben bildet das nicht ab. Prüfe deshalb bei Notrufthemen zusätzlich die Notruf-Richtlinien mit Get-CsTeamsEmergencyCallRoutingPolicy. Wie Notruf in Teams insgesamt aufgebaut ist und wie du ihn testest, ohne eine echte Leitstelle zu belästigen, steht in Notruf in Microsoft Teams konfigurieren und Notruf in Teams testen, ohne die Leitstelle zu verärgern.

 

Schritt 6: Sind die Gateways der Gewinner-Route verfügbar?

Get-CsOnlinePSTNGateway | Format-Table Identity, Enabled, SendSipOptions, MaxConcurrentSessions

 

Ein deaktiviertes Gateway in der Gewinner-Route ist der Klassiker für „Anruf scheitert, obwohl der Backup-SBC läuft“. Ob ein aktiviertes Gateway auch tatsächlich antwortet, siehst du im Teams Admin Center im Zustand des SBC; die Hintergründe zum OPTIONS-Ping findest du in Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen.

Im Teams Admin Center

Wer lieber klickt: Unter Voice › Voice routing policies öffnest du die Policy und siehst die PSTN Usages in ihrer Reihenfolge. Unter Voice › Direct Routing findest du auf dem Reiter Voice routes alle Routen mit ihrer Priorität und über Manage PSTN usage records die Liste der Usages. Die deutsche Oberfläche benennt die Menüs sinngemäß übersetzt. Für den Blick auf das ganze Dreieck musst du allerdings zwischen drei Ansichten hin- und herwechseln, und genau dabei verliert man den Überblick. Für mehr als eine Handvoll Routen ist PowerShell die ehrlichere Ansicht.

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Die Routing-Landkarte stellt Voice Routing Policies, PSTN Usages, Voice Routes und Gateways in vier Spalten nebeneinander und verbindet sie mit Linien. So siehst du das ganze Dreieck auf einer Seite statt in drei Menüs. Kritische Elemente wie ein deaktiviertes Gateway oder eine Route, die nur darauf zeigt, sind rot markiert, auffällige wie eine Usage ohne Voice Route oder eine Usage, die in keiner Policy steckt, gelb. Eine Liste der auffälligen Elemente fasst die Meldungen zusammen. Für den einzelnen Anruf spielt der Rufweg-Simulator eine Nummer für einen Benutzer durch die Kette bis zum Gateway. Der Assistent für Routing zeigt beim Anlegen eines Standorts vorab, welche Usages und Routen entstehen und welche Konflikte es mit dem Bestand gibt. Der Teams-Telefonie Diagnostiker lässt sich 15 Tage kostenlos testen. › Teams-Telefonie Diagnostiker

 

Behebung: Reihenfolge korrigieren, ohne neue Löcher zu reißen

Vorher sichern

Bevor du an Policies oder Prioritäten drehst, sicherst du den Ist-Zustand. Das kostet zehn Sekunden und ist dein Rückweg:

$stamp = Get-Date -Format "yyyyMMdd-HHmm" Get-CsOnlineVoiceRoutingPolicy | Export-Clixml ".\vrp-$stamp.xml" Get-CsOnlineVoiceRoute | Export-Clixml ".\routes-$stamp.xml" Get-CsOnlinePstnUsage | Export-Clixml ".\usages-$stamp.xml"

 

Usage-Reihenfolge in der Policy korrigieren

Die Reihenfolge der Usages änderst du, indem du die Liste komplett ersetzt. Das ist auch der Weg, den Microsoft dokumentiert:

Set-CsOnlineVoiceRoutingPolicy -Identity "Tag:VRP-MUC" ` -OnlinePstnUsages @{Replace="MUC-Lokal","DE-National","International"}

 

Faustregel für die Reihenfolge: vom Speziellen zum Allgemeinen. Zuerst die Usage mit Notruf und lokalen Zielen, dann national, dann international, ganz am Ende alles, was Sammelmuster enthält. Im Teams Admin Center kannst du die Usages in der Policy ebenfalls nach oben und unten verschieben.

Priorität einer Route ändern

Greift innerhalb einer Usage die falsche Route, änderst du deren Priorität:

Set-CsOnlineVoiceRoute -Identity "MUC-Ortsnetz" -Priority 1 Get-CsOnlineVoiceRoute | Sort-Object Priority | Format-Table Identity, Priority, NumberPattern

 

Kontrolliere danach immer die komplette Liste. Die Priorität ist eine Zahl über alle Routen, und wenn du eine Route nach vorn holst, verschieben sich die anderen. Es kann also passieren, dass du ein Problem behebst und dabei die Reihenfolge einer Route in einer ganz anderen Usage veränderst.

Sammelmuster entschärfen

Die eleganteste Behebung ist oft nicht das Umsortieren, sondern ein Muster, das nur trifft, was es treffen soll. Statt .* für „alles ins Ausland“ verwendest du ^\+(?!49)\d+$. Das trifft jede E.164-Nummer, die nicht mit +49 beginnt, und lässt 110, 112 und deutsche Nummern in Ruhe. Die Route Alles aus dem Beispiel löschst du nicht sofort, sondern nimmst sie zuerst aus der Usage heraus und beobachtest eine Woche lang, ob jemand sie vermisst:

Set-CsOnlineVoiceRoute -Identity "Alles" -OnlinePstnUsages @{Remove="International"}

 

Wirksamkeit prüfen und Rollback

Änderungen an Routing-Objekten sind nicht in derselben Sekunde überall wirksam. Plane etwas Wartezeit ein, bevor du testest, und teste dann mit dem Skript aus Schritt 5 und einem echten Anruf auf eine unkritische Nummer. Für den Notruf gilt: Nicht 112 wählen, um zu sehen, ob es geht. Wenn etwas schiefgeht, holst du den alten Stand aus der Sicherung zurück:

$alt = Import-Clixml ".\vrp-$stamp.xml" | Where-Object Identity -eq "Tag:VRP-MUC" Set-CsOnlineVoiceRoutingPolicy -Identity "Tag:VRP-MUC" ` -OnlinePstnUsages @{Replace=[string[]]$alt.OnlinePstnUsages}   $r = Import-Clixml ".\routes-$stamp.xml" | Where-Object Identity -eq "Alles" Set-CsOnlineVoiceRoute -Identity "Alles" -Priority $r.Priority ` -OnlinePstnUsages @{Replace=[string[]]$r.OnlinePstnUsages}

 

TIPP · Erst im Kleinen, dann für alle Statt die produktive Policy umzubauen, legst du eine Kopie wie VRP-MUC-neu mit der korrigierten Reihenfolge an und weist sie zuerst zwei, drei Testbenutzern zu. Passt alles, bekommt der Standort die neue Policy. Der Rollback ist dann eine einzige Zuweisung zurück auf die alte Policy, und die alte Policy ist noch da.

 

AUS DER PRAXIS · Ulis eigener anynode-SBC In meinem eigenen Tenant läuft Direct Routing über einen anynode-SBC. Wenn ich dort einen zweiten Trunk oder eine neue Route ausprobiere, bekommt der Test eine eigene Policy, die nur mein Testkonto trägt. Die Abkürzung, eine Test-Usage mit einer .*-Route kurz an Position 1 der produktiven Policy zu schieben, ist verlockend, weil sie zwei Minuten spart. Bleibt sie dort stehen, läuft danach jeder Anruf über den Testweg, inklusive Notruf und mit der Rufnummernanzeige, die der Testtrunk eben mitbringt. Deshalb tragen Test-Objekte bei mir ein Ablaufdatum im Namen, und die Usage-Reihenfolge der produktiven Policies steht in der Dokumentation, damit ich sie mit dem Ist-Zustand vergleichen kann.

 

Vorbeugung: damit das Dreieck stabil bleibt

Vom Speziellen zum Allgemeinen. Jede Policy beginnt mit der lokalen Usage samt Notruf, danach national, danach international. Sammelmuster gehören ans Ende oder gar nicht ins Routing.

Failover über Prioritäten, nicht über Usages. Ersatzwege sind zweite Routen mit demselben Muster und höherer Prioritätszahl in derselben Usage.

Muster immer verankert. Jedes Muster mit ^ und $. Ein Muster ohne Anker trifft auch Nummern, die das Muster nur irgendwo enthalten.

Namen, die die Funktion verraten. FRA-Lokal, DE-National, International statt Usage1 und Test-neu. Wer den Namen liest, soll die Position in der Policy erraten können.

Keine Policy für Global, die keiner geplant hat. Die globale Policy erbt jeder Benutzer ohne eigene Zuweisung, laut Microsoft auch Benutzer mit Calling Plan oder Operator Connect, deren Anrufe dann unbeabsichtigt über Direct Routing laufen können.

Verwaiste Objekte regelmäßig aufräumen. Usages ohne Route, Routen ohne Usage, Usages in keiner Policy, Gateways, die in keiner Route stehen.

Prüftabelle je Policy. Eine feste Liste von Testnummern pro Standort, nach jeder Änderung mit dem Skript aus Schritt 5 durchgespielt, inklusive 110 und 112, ohne sie anzurufen.

Soll-Zustand dokumentieren und vergleichen. Die Reihenfolge der Usages je Policy und die Prioritäten aller Routen gehören in die Betriebsdokumentation, regelmäßig abgeglichen.

Zum letzten Punkt gibt es zwei Vertiefungen: Konfigurationsdrift in der Teams-Telefonie erkennen zeigt, wie du ungeplante Änderungen erkennst, und Microsoft Teams Telefonie-Governance regelt, wer überhaupt an Policies und Routen schrauben darf. Wenn dein Routing über Jahre und Standorte gewachsen ist und du es grundsätzlich neu ordnen willst, ist das ein gutes Thema für ein Festpreispaket Grobkonzept Teams-Telefonie oder eine Beratung zur Teams-Telefonie. Wer das Dreieck lieber einmal in Ruhe am Beispiel lernt als im Störungsfall, ist in der Schulung Teams-Telefonie richtig.

WEITERLESEN · Passend dazu › Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › SBC-Failover in Teams funktioniert nicht › Teams-Telefonie Probleme: die zehn häufigsten Ursachen

 

FAQ

Was ist der Unterschied zwischen Voice Routing Policy und PSTN Usage?

Die Voice Routing Policy wird dem Benutzer zugewiesen und enthält eine geordnete Liste von PSTN Usages. Die PSTN Usage ist nur ein Name, der Policies und Voice Routes miteinander verbindet. Die eigentliche Routing-Logik mit Muster, Priorität und Gateways steckt in der Voice Route.

Gilt die Priorität einer Route über alle Usages hinweg?

Die Priorität ist eine Eigenschaft der Route. Wirksam wird sie aber nur innerhalb der Usage, die gerade geprüft wird. Eine Route mit Priorität 1 in Usage 2 verliert gegen eine Route mit Priorität 50 in Usage 1, wenn beide passen.

Warum springt Teams nicht in die nächste Usage, wenn der SBC ausfällt?

Weil laut Microsoft die weiteren Usages nicht ausgewertet werden, sobald in einer Usage eine passende Route gefunden wurde. Ein Ersatzweg muss deshalb als weitere passende Route mit höherer Prioritätszahl in derselben Usage liegen.

In welcher Reihenfolge werden die SBCs einer Route benutzt?

In zufälliger Reihenfolge. Wenn du einen SBC klar bevorzugen willst, legst du zwei Routen mit demselben Muster an, die erste mit dem bevorzugten SBC und kleinerer Prioritätszahl, die zweite mit dem Ersatz.

Warum geht eine Weiterleitung über einen anderen SBC, als die Priorität vorgibt?

Bei weitergeleiteten oder vermittelten eingehenden Anrufen bevorzugt Teams den SBC, über den der Anruf hereinkam, sofern er in einer passenden Route steht. Seine Priorität wird in diesem Fall ignoriert. Das ist dokumentiertes Verhalten und kein Fehler.

Was passiert, wenn keine Route passt?

Dann scheitert der Anruf. Nur Benutzer mit Calling Plan haben einen automatischen letzten Weg über den Calling Plan. Bei reinen Direct-Routing-Benutzern ist eine fehlende Route also gleichbedeutend mit „dieses Ziel ist gesperrt“, ob gewollt oder nicht.

Kann ich Sonderrufnummern wie 0900 über das Routing sperren?

Ja, indem keine Route sie trifft. Eine Sperre im Sinne einer Verbotsregel gibt es im Routing nicht. Wenn deine nationale Route ^\+49\d+$ lautet, trifft sie auch +49900. Ein Muster wie ^\+49(?!900)\d+$ nimmt die 0900-Nummern aus. Prüfe aber jede Usage der Policy, denn eine Sammelroute in einer späteren Usage würde die Nummer trotzdem routen.

Wie ändere ich die Reihenfolge der Usages in einer bestehenden Policy?

Mit Set-CsOnlineVoiceRoutingPolicy und dem Parameter OnlinePstnUsages @{Replace=…}, in dem du die komplette Liste in der gewünschten Reihenfolge angibst, oder im Teams Admin Center in der Policy über das Verschieben der Einträge. Sichere vorher den alten Stand.

Fazit: Nicht die beste Route gewinnt, sondern die erste

Das Dreieck aus Voice Routing Policy, PSTN Usage und Voice Route ist schnell erklärt: Die Policy hängt am Benutzer und ordnet Usages, die Usage ist ein Name, die Route trägt Muster, Priorität und Gateways. Schwierig wird es nur, weil Teams in zwei Ebenen prüft und die äußere gewinnt. Erst die Reihenfolge der Usages, dann innerhalb der gewinnenden Usage die Priorität, dann zufällig unter den SBCs. Was in einer früheren Usage passt, beendet die Suche, egal wie schön die Route weiter unten gebaut ist.

Wer das einmal verinnerlicht hat, findet die meisten Routing-Fehler mit drei lesenden Befehlen und einem kleinen Skript: Policy des Benutzers, Reihenfolge ihrer Usages, Routen nach Priorität. Sortiere vom Speziellen zum Allgemeinen, baue Ersatzwege über Prioritäten statt über Usages, sichere vor jeder Änderung und teste den Notruf, ohne ihn zu wählen. Dann landet der Münchner Notruf in München, der Ersatz-SBC springt tatsächlich ein, und die Route, die „doch da ist“, ist es auch an der richtigen Stelle.