Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Deine Kunden sehen mal die Zentrale, mal die Durchwahl, mal gar nichts? Wir bringen Policy, SBC und Provider auf eine Linie. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Caller ID Policies, SIP-Header und SBC-Regeln verstehen und selbst prüfen wollen. › Schulung Teams-Telefonie

 

Die Rufnummer ist die Visitenkarte am Telefon. Bei Teams-Telefonie mit Direct Routing ist sie allerdings eine Visitenkarte, die auf dem Weg zum Empfänger durch fünf Hände geht, und jede davon darf sie umschreiben, überkleben oder in den Papierkorb werfen. Am Ende sieht der Kunde die Zentrale, die Durchwahl vom Kollegen am Nachbartisch oder ein schlichtes „Unbekannt“. Letzteres hat den Vorteil, dass niemand zurückruft. Für den Vertrieb ist das allerdings ein eher schwacher Trost.

Wenn bei dir die teams rufnummernanzeige falsch ist, liegt die Ursache fast immer an einer von wenigen Stellen: an der Caller ID Policy im Tenant, an der Nummer eines Ressourcenkontos, an den Einstellungen des Gateways in Teams, an Regeln im Session Border Controller oder am Screening deines SIP-Providers, Stichwort CLIP no screening. Dieser Beitrag geht vom Symptom aus, erklärt die Kette nur so weit, wie du sie für die Fehlersuche brauchst, und führt dich mit lesenden PowerShell-Befehlen zur verantwortlichen Station. Die Grundlagen zu Direct Routing, SBC und Routing findest du auf der Seite Teams-Telefonie.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Standorten in Frankfurt, Köln, Berlin, Hamburg und München. Die Zentrale in Frankfurt hat die Rufnummer +49 69 555 0100, der Rufnummernblock reicht von +49 69 555 0100 bis +49 69 555 0199. Haupt-SBC ist sbc1.contoso.com. Die Benutzerin anna.berger@contoso.com hat die Durchwahl +49 69 555 0142. Die Vertriebs-Hotline läuft über eine Warteschlange mit dem Ressourcenkonto cq-vertrieb@contoso.com und der Nummer +49 69 555 0150. 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: „Der Kunde sagt, ich hätte anonym angerufen“

Fehler bei der Rufnummernanzeige haben eine Eigenart: Der Anrufer merkt sie nie selbst. Er sieht in seinem Teams-Client seine eigene Nummer, alles wirkt korrekt. Das Problem erfährt er erst vom Angerufenen, meist in einem Ton, der zwischen Belustigung und Misstrauen liegt. Im Helpdesk kommt es dann so an:

„Meine Kunden sehen immer die Zentrale und landen beim Rückruf in der Telefonzentrale.“

„Der Kunde hat zurückgerufen und Herrn Schmidt erreicht. Ich heiße nicht Schmidt.“

„Bei mir steht beim Angerufenen nur ‚Unbekannt‘. Den Anruf nimmt keiner mehr an.“

„Seit dem Providerwechsel zeigen alle Anrufe die Stammnummer.“

„Die Hotline-Nummer erscheint bei allen, auch bei der Geschäftsführung.“

„Wenn ich weiterleite, sieht mein Handy die Zentrale und nicht den Kunden.“

Die Symptome lassen sich in drei Gruppen ordnen, und jede Gruppe zeigt in eine andere Richtung. Das ist die gute Nachricht: Die Art des Fehlers verrät schon, wo du zuerst suchen solltest.

Der Angerufene sieht …	Typischer Helpdesk-Satz	Zuerst verdächtig
die Stammnummer oder Zentrale (+49 69 555 0100)	„Alle sehen nur die Zentrale.“	Caller ID Policy mit Ressourcenkonto, Übersetzungsregel, SBC-Regel, Screening beim Provider
eine falsche Durchwahl (+49 69 555 0143)	„Der Kunde hat jemand anderen erreicht.“	Nummer am Benutzer, Anruf im Namen einer Warteschlange, Regex oder SBC-Tabelle
„Unbekannt“ oder „Anonym“	„Ich rufe angeblich mit unterdrückter Nummer an.“	Caller ID Policy Anonymous, Benutzer-Override, ForwardPai mit unpassender SBC-Regel, Provider
die richtige Nummer, aber falschen Namen	„Da stand der Firmenname, nicht mein Name.“	Calling Party Name (CompanyName) in der Policy, Telefonbuch des Angerufenen

 

WICHTIG · Erst klären: Geht der Anruf überhaupt raus? Dieser Beitrag setzt voraus, dass der Anruf ankommt und nur die Anzeige nicht stimmt. Scheitert der Anruf ganz, prüfst du zuerst den Rufweg mit Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen. Lehnt der Provider den Anruf mit einem 403 ab, kann die Ursache allerdings dieselbe sein wie hier: eine Nummer, die er nicht als deine akzeptiert. Mehr dazu in SIP-Fehlercodes in Teams Direct Routing verstehen.

 

Wie die falsche Nummer entsteht

Für einen abgehenden Anruf kennst du die Kette Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Sie bestimmt, wohin der Anruf geht. Für die Rufnummernanzeige gibt es eine zweite, parallele Kette, die bestimmt, als wer der Anruf ankommt: Benutzer › Caller ID Policy › Direct Routing (SIP-Header) › Übersetzungsregeln am Gateway › SBC › SIP-Provider › Angerufener. Jede Station darf die Nummer verändern, und die Anzeige ist das Ergebnis der letzten Station, die das getan hat.

Station 1 und 2: Benutzernummer und Caller ID Policy

Ausgangspunkt ist die Nummer, die dem Benutzer zugewiesen ist. Stimmt sie nicht, stimmt auch alles Weitere nicht. Das klingt banal, ist aber nach Umzügen, Namenswechseln und dem berühmten „Wir geben die Nummer vom Vorgänger weiter“ erstaunlich häufig die Lösung. Wenn dieselbe Nummer zusätzlich noch an anderer Stelle hängt, hilft Rufnummer in Teams doppelt vergeben.

Danach entscheidet die Caller ID Policy (PowerShell: CallingLineIdentity), was Teams als Anrufernummer verwendet. Microsoft dokumentiert drei Varianten: die Nummer des Benutzers (Standard), Anonymous oder die Nummer eines Ressourcenkontos, das von einer automatischen Telefonzentrale oder einer Warteschlange genutzt wird. Die frühere Variante „Service“ ist laut Microsoft abgekündigt; bestehende Richtlinien mit diesem Wert werden nicht mehr berücksichtigt, du sollst stattdessen „Resource“ verwenden. Falls du also eine sehr alte Policy mit Service-Nummer im Tenant hast, die plötzlich nicht mehr wirkt: Sie wirkt tatsächlich nicht mehr.

Einstellung im Teams Admin Center	PowerShell-Parameter	Standard	Wirkung
Replace the caller ID with	CallingIDSubstitute (LineUri, Anonymous, Resource)	LineUri	Bestimmt die gesendete Nummer: eigene, anonym oder die des Ressourcenkontos
Replace the caller ID with this resource account	ResourceAccount (ObjectId)	leer	Pflicht bei Resource. Es muss ein Ressourcenkonto mit zugewiesener Nummer sein
Override the caller ID policy	EnableUserOverride	aus	Benutzer kann in Teams seine Nummer selbst unterdrücken; hat Vorrang vor der Policy, außer bei Anonymous
Calling Party Name	CompanyName	leer	Name, der mitgeschickt wird (bis 200 Zeichen); ob er ankommt, hängt von den Netzen ab
Block incoming caller ID	BlockIncomingPstnCallerID	aus	Betrifft eingehende Anrufe: Der Teams-Benutzer sieht den Anrufer als Anonymous

 

Zwei Feinheiten verursachen besonders viele Tickets. Erstens gilt die Caller ID Policy wie jede andere Richtlinie über die Vorrangregel: direkte Zuweisung vor Gruppe vor Global. Wer die globale Caller ID Policy auf das Ressourcenkonto der Hotline stellt, schickt damit jeden Benutzer ohne eigene Zuweisung als Hotline auf die Reise. Wie dieser Rückfall funktioniert, steht ausführlich in Teams-Benutzer fällt auf die globale Richtlinie zurück. Zweitens hat der Benutzer-Override Vorrang: Ist er erlaubt und hat der Benutzer in den Teams-Einstellungen unter Anrufe die Option zum Verbergen seiner Nummer aktiviert, geht der Anruf anonym raus, egal was die Policy sonst vorsieht. Laut Microsoft dauert es nach dem Umschalten einige Minuten, bis die Änderung bei neuen Anrufen greift.

FAKTEN · Was Microsoft über die Ersatznummer festlegt Als Ersatznummer sind nur Nummern zulässig, die einem Ressourcenkonto einer automatischen Telefonzentrale oder einer Warteschlange zugewiesen sind. Bei Direct Routing und Operator Connect genügt die Zuweisung an das Ressourcenkonto; bei Calling Plans muss es eine Service- oder gebührenfreie Nummer aus dem Calling-Plan-Bestand sein. Nicht zulässig sind Direct-Routing-Nummern, die einem Benutzer zugewiesen sind, sowie Calling-Plan- und Operator-Connect-Nummern vom Typ User. Die Durchwahl der Kollegin taugt also nicht als Ersatz. Ruft jemand im Namen eines anderen Kontos an, etwa für eine Warteschlange, als Stellvertretung oder über Shared Calling, ersetzt die für dieses Konto konfigurierte Anrufer-ID die des Benutzers. Notrufe senden laut Microsoft immer die Nummer des Benutzers an die Notrufabfragestelle, unabhängig von der Caller ID Policy.

 

Station 3: Was Direct Routing in den SIP-Header schreibt

Bei Direct Routing schickt Teams die Ersatznummer und den Calling Party Name im From-Header des INVITE an deinen SBC. Ob zusätzlich ein P-Asserted-Identity-Header (PAI) mit der echten Identität des Anrufers mitkommt, steuert die Einstellung ForwardPai am Gateway, also an der Konfiguration des SBC in Teams. Standard ist $false. Microsoft beschreibt den Zweck so: Ist die Anzeige anonym oder auf eine allgemeine Firmennummer gesetzt, braucht man für die Abrechnung trotzdem die echte Identität. Die Cmdlet-Hilfe ergänzt, dass der From-Header bei aktiviertem ForwardPai im Sinne von RFC 3325 und RFC 5379 anonym dargestellt werden kann. Ob und wie das bei dir zutrifft, siehst du nur im Trace, und genau deshalb muss dein SBC wissen, welchen Header er Richtung Provider wofür verwendet.

SIP-Header	Bedeutung	Wer ihn setzt
From	Nummer und Name, die angezeigt werden sollen	Direct Routing nach Caller ID Policy, danach gegebenenfalls Übersetzungsregel und SBC
P-Asserted-Identity (PAI)	Geprüfte Identität des Anrufers im vertrauenswürdigen Netz, Grundlage für Abrechnung und Notruf	Direct Routing nur mit ForwardPai, sonst der SBC
Privacy	Wunsch nach Unterdrückung, etwa Privacy: id	Direct Routing bei anonymen Anrufen, SBC nach eigener Regel
History-Info, Referred-By	Weiterleitungsverlauf und weiterleitende Partei	Direct Routing mit ForwardCallHistory

 

Station 4 und 5: Übersetzungsregeln am Gateway und der SBC

Direct Routing kann Nummern auf dem Weg zum SBC umschreiben. Für die Rufnummernanzeige zuständig ist der Parameter OutboundTeamsNumberTranslationRules am Gateway: Er wirkt bei abgehenden Anrufen auf die Nummer des Teams-Benutzers im From-Header. OutboundPstnNumberTranslationRules dagegen wirkt auf die gewählte Zielnummer. Die Regeln werden in der Reihenfolge angewendet, in der sie am Gateway stehen; laut Microsoft sind insgesamt bis zu 400 Übersetzungsregeln möglich. Eine harmlose und korrekte Regel wandelt E.164 in das nationale Format um, falls dein Provider das verlangt:

# Regel (nur lesen): E.164 der Absendernummer in nationales Format Name: From-E164-zu-National Pattern: ^\+49(\d+)$ Translation: 0$1   +49695550142 › 0695550142

 

Gefährlich wird es, wenn eine Regel mehr fasst als gedacht. Ein Klassiker: Jemand möchte, dass das alte Faxgerät +49 69 555 0199 als Zentrale erscheint, und schreibt eine Regel für den ganzen Block:

# Falsch: fasst jede Frankfurter Nummer aus dem Block 555 xxxx Pattern: ^\+4969555\d{4}$ Translation: +49695550100   # Richtig: genau die eine Nummer Pattern: ^\+49695550199$ Translation: +49695550100

 

Der SBC ist die letzte Station, die du selbst kontrollierst. Hier entscheidet sich, welche Nummer im From steht, welche im PAI, ob ein Privacy-Header gesetzt wird und ob die Nummern im Format deines Providers ankommen. Tabellen, die Benutzer auf Nummern abbilden, feste Ersatznummern für bestimmte Trunks und Regeln, die nur den From-Header, aber nicht den PAI anpassen, sind die üblichen Verdächtigen. Grundlagen zu Aufbau und Aufgaben des SBC findest du in Teams SBC Grundlagen: der Session Border Controller.

Station 6: Screening beim Provider und CLIP no screening

Bei der Übermittlung der Rufnummer unterscheiden die Netze zwischen einer vom Netz geprüften Nummer und einer vom Anwender gelieferten Nummer. Die geprüfte Nummer muss zu deinem Anschluss gehören, sie steckt bei SIP-Trunks üblicherweise im PAI. Die vom Anwender gelieferte Nummer steckt im From und wird nur dann angezeigt, wenn der Provider das zulässt. Dieses Leistungsmerkmal heißt in Deutschland meist CLIP no screening. Ohne dieses Merkmal zeigt der Provider die geprüfte Nummer an oder ersetzt eine unpassende Nummer durch die Stammnummer des Anschlusses. Manche Provider lehnen den Anruf in diesem Fall auch ab.

Welche Nummern du als Anzeige übermitteln darfst, ist in Deutschland geregelt, und die Einzelheiten stehen in der Leistungsbeschreibung deines Providers. Sinngemäß gilt: Es muss eine Nummer sein, die dir zugeteilt ist oder deren Nutzung dir erlaubt wurde. Wenn du Anrufe von Teams auf Mobiltelefone weiterleitest und dabei die Nummer des ursprünglichen Anrufers sehen möchtest, ist CLIP no screening in aller Regel Voraussetzung, weil diese Nummer ja gerade nicht zu deinem Anschluss gehört. Bei der Wahl des Trunks lohnt es sich, danach ausdrücklich zu fragen; worauf du sonst achten solltest, beschreibt SIP-Trunk-Auswahl für Teams Direct Routing.

WARNUNG · Notruf nie anonymisieren Microsoft garantiert, dass Teams bei Notrufen die Nummer des Benutzers sendet. Das hilft nur, wenn dein SBC sie nicht anschließend wieder entfernt. Regeln, die Privacy-Header setzen, den PAI löschen oder pauschal die Zentrale eintragen, müssen die Notrufnummern 110 und 112 ausnehmen. Prüfe das bei jeder Änderung an Anzeigeregeln mit, am besten mit einer eigenen SBC-Route für ^(110|112)$, die vor allen Anzeigeregeln greift. Wie Teams Notrufe insgesamt behandelt, steht in Notruf in Microsoft Teams konfigurieren.

 

Diagnose Schritt für Schritt

Die Diagnose folgt der Kette von vorne nach hinten. Erst prüfst du mit lesenden Befehlen, was der Tenant sendet. Danach schaust du in den Trace des SBC, und erst wenn beides stimmt, schreibst du dem Provider. Diese Reihenfolge spart Zeit, weil die meisten Fehler in den ersten beiden Stationen liegen und der Provider ohnehin zuerst nach einem Trace fragt.

Schritt 1: Welche Nummer hat der Benutzer wirklich?

Connect-MicrosoftTeams   Get-CsPhoneNumberAssignment -AssignedPstnTargetId anna.berger@contoso.com | Select-Object TelephoneNumber, NumberType, PstnAssignmentStatus   Get-CsOnlineUser -Identity anna.berger@contoso.com | Select-Object DisplayName, LineUri, EnterpriseVoiceEnabled

 

Erwartet wird TelephoneNumber +49695550142 mit NumberType DirectRouting. Steht dort eine andere Nummer, ist der Fall erledigt, bevor er spannend wurde. Im Teams Admin Center findest du dieselbe Angabe unter Benutzer › Benutzer verwalten › Anna Berger.

Schritt 2: Welche Caller ID Policy wirkt?

Get-CsUserPolicyAssignment -Identity anna.berger@contoso.com ` -PolicyType CallingLineIdentity | Select-Object -ExpandProperty PolicySource   # Keine Ausgabe: wirksam ist die globale Caller ID Policy   Get-CsCallingLineIdentity | Select-Object Identity, CallingIDSubstitute, ResourceAccount, EnableUserOverride, CompanyName, BlockIncomingPstnCallerID

 

Achte besonders auf die Zeile Global. Steht dort CallingIDSubstitute Resource oder Anonymous, betrifft das alle Benutzer ohne eigene Zuweisung. Ist EnableUserOverride bei der wirksamen Policy aktiv, frage den Benutzer, ob er in den Teams-Einstellungen unter Anrufe die Nummer verborgen hat. Diese Frage klärt mehr „Unbekannt“-Tickets als jeder Trace. Im Teams Admin Center findest du die Richtlinien unter Sprache › Anrufer-ID-Richtlinien (englische Oberfläche: Voice › Caller ID policies).

Schritt 3: Wem gehört die Ersatznummer?

# ObjectId aus ResourceAccount der Policy einsetzen Get-CsOnlineApplicationInstance -Identity <ObjectId> | Select-Object DisplayName, UserPrincipalName, PhoneNumber   # Anrufe im Namen einer Warteschlange Get-CsCallQueue -NameFilter "Vertrieb" | Select-Object Name, OboResourceAccountIds

 

Zeigt die Policy auf cq-vertrieb@contoso.com, sendet jeder Benutzer mit dieser Policy die Hotline-Nummer +49 69 555 0150. Das ist richtig für die Hotline-Agenten und falsch für alle anderen. OboResourceAccountIds zeigt, welche Ressourcenkonten den Agenten einer Warteschlange für ausgehende Anrufe in deren Namen zur Verfügung stehen. Ruft eine Agentin bewusst im Namen der Warteschlange an, ist die Hotline-Nummer beim Kunden kein Fehler, sondern Absicht. Mehr zur Konfiguration von Warteschlangen steht in Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen.

Schritt 4: Was macht das Gateway mit der Nummer?

Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, ForwardPai, ForwardCallHistory, OutboundTeamsNumberTranslationRules, OutboundPstnNumberTranslationRules   Get-CsTeamsTranslationRule | Select-Object Identity, Pattern, Translation   Test-CsTeamsTranslationRule -PhoneNumber "+49695550142"

 

Test-CsTeamsTranslationRule prüft eine Nummer gegen die im Tenant angelegten Regeln und meldet die erste passende Regel mit dem Ergebnis. Wichtig: Das Cmdlet prüft gegen alle Regeln, nicht nur gegen die eines bestimmten Gateways. Ob die gefundene Regel tatsächlich an sbc1.contoso.com unter OutboundTeamsNumberTranslationRules hängt, liest du aus der Gateway-Abfrage ab. Findet keine Regel, meldet das Cmdlet „No number translation rule matched“, und das ist für die Anzeige eine gute Nachricht. Die Muster selbst prüfst du genauso sorgfältig wie Normalisierungsregeln; typische Regex-Fallen beschreibt Normalisierungsregeln in Teams: typische Fehler und wie du sie findest.

Schritt 5: Trace am SBC lesen

Jetzt verlässt du PowerShell. Im Trace deines SBC vergleichst du für einen Testanruf zwei Nachrichten: den INVITE, der von Teams beim SBC ankommt, und den INVITE, den der SBC an den Provider schickt. In beiden interessieren dich dieselben vier Zeilen: From, P-Asserted-Identity, Privacy und gegebenenfalls Remote-Party-ID, falls dein Provider diesen älteren Header noch auswertet.

Befund im Trace	Bedeutung	Nächster Schritt
Teams › SBC: From schon falsch	Die Ursache liegt im Tenant	Schritte 1 bis 4 wiederholen, Policy und Übersetzungsregel prüfen
Teams › SBC richtig, SBC › Provider falsch	Der SBC schreibt um	Regeln und Tabellen am SBC prüfen
SBC › Provider richtig, Anzeige trotzdem falsch	Provider ersetzt oder unterdrückt	Screening und CLIP no screening mit dem Provider klären
SBC › Provider ohne PAI	Provider kann die Netznummer nicht prüfen	PAI am SBC aus dem Rufnummernblock setzen
Privacy: id ohne Absicht	Anruf wird anonym angezeigt	Herkunft klären: Policy, Override, SBC-Regel

 

Ein Hinweis aus eigener Erfahrung: Auf meinem eigenen anynode-SBC sah nach einem Providerwechsel jeder Kunde nur noch die Stammnummer. Der alte Provider hatte die Nummer aus dem From-Header genommen, der neue erwartete eine Nummer aus dem Block im PAI und ersetzte alles andere stillschweigend. Teams hat korrekt gesendet, der SBC hat korrekt weitergereicht, und trotzdem war es falsch. Die Lösung war eine Regel am SBC, die den PAI Richtung Provider mit der Durchwahl aus dem Block füllt. Die Moral: Ein Trace zeigt dir, was du sendest. Was der Provider daraus macht, steht in seiner Leistungsbeschreibung, und die liest man leider meist erst hinterher.

Schritt 6: Den Provider gezielt fragen

Wenn der SBC nachweislich das Richtige sendet, schreibst du dem Provider mit Trace, Uhrzeit, Absender- und Zielnummer. Stelle drei konkrete Fragen: Welche Nummernblöcke sind für den Trunk hinterlegt? Ist CLIP no screening freigeschaltet? In welchem Header erwartet ihr die geprüfte und in welchem die angezeigte Nummer? Wer nur „die Rufnummer stimmt nicht“ schreibt, bekommt erfahrungsgemäß die Antwort „bei uns ist alles in Ordnung“. Damit hat er sogar recht, nur hilft es dir nicht.

Ergänzend lohnt der Blick in die Anrufdaten: Im Teams Admin Center zeigt der Bericht zur PSTN-Nutzung für Direct Routing je Anruf unter anderem Anrufer- und Zielnummer. Wie du solche Daten systematisch auswertest, steht in Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl.

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Benutzer-Steckbrief fasst die Telefonie-Konfiguration eines einzelnen Benutzers auf einer Seite zusammen, darunter Rufnummer und wirksame Richtlinien. Damit siehst du ohne die Schritte 1 bis 3 einzeln auszuführen, ob bei Anna eine andere Caller ID Policy wirkt als bei ihrem Kollegen. Die Drift-Erkennung zeigt Abweichungen gegenüber einem früheren Stand der Konfiguration. Das hilft bei der Frage, die bei Anzeigefehlern fast immer kommt: „Seit wann ist das so, und hat jemand etwas geändert?“ Die Ergebnisse lassen sich als Bericht zusammenfassen und an Provider oder Kollegen weitergeben. Der Diagnostiker arbeitet im Nur-Lese-Modus; den SBC-Trace und die Klärung mit dem Provider ersetzt er nicht. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung: an der richtigen Stelle korrigieren

Die wichtigste Regel bei der Behebung: Korrigiere an der Station, an der der Fehler entsteht, nicht an der letzten, die du erreichst. Wer eine falsche Caller ID Policy am SBC „wegregelt“, hat zwei Fehler, die sich gegenseitig aufheben, bis einer davon jemand anderem auffällt. Die folgende Tabelle ordnet jeder Ursache die passende Stelle zu.

Ursache	Stelle der Korrektur	Rückweg
Falsche Nummer am Benutzer	Teams: Nummer neu zuweisen (Set-CsPhoneNumberAssignment)	Alte Nummer notieren und zurückweisen
Globale Caller ID Policy auf Ressourcenkonto oder Anonymous	Teams: Global auf Nummer des Benutzers, Sonderfälle als eigene Policy	Alte Werte aus der Sicherung mit Set-CsCallingLineIdentity setzen
Falsche Policy über Gruppe oder direkt	Teams: Zuweisung korrigieren (Grant-CsCallingLineIdentity, Gruppenzuweisung)	Vorherige Zuweisung wiederherstellen
Benutzer-Override unerwünscht	Teams: EnableUserOverride in der Policy aus	Wert wieder auf $true
Ressourcenkonto ohne oder mit falscher Nummer	Teams: Nummer am Ressourcenkonto prüfen und zuweisen	Vorherige Nummer zurückweisen
Übersetzungsregel fasst zu viel	Teams: Pattern der Regel enger fassen oder Regel vom Gateway lösen	Altes Pattern mit Set-CsTeamsTranslationRule zurücksetzen
ForwardPai passt nicht zur SBC-Regel	Teams-Gateway oder SBC: eine Seite anpassen, nicht beide gleichzeitig	ForwardPai auf alten Wert
SBC setzt feste Nummer oder vergisst PAI	SBC: Regel bzw. Tabelle korrigieren, PAI aus dem Block setzen	SBC-Konfigurationssicherung einspielen
Provider ersetzt durch Stammnummer	Provider: Blöcke hinterlegen lassen, CLIP no screening beauftragen	Keiner nötig, aber schriftliche Bestätigung einholen
Falscher Name statt Nummer	Teams: CompanyName in der Policy; beim Angerufenen Telefonbuch	Alten CompanyName setzen

 

Erst sichern, dann ändern

Bevor du schreibst, sicherst du den Ist-Zustand. Das dauert eine Minute und erspart dir die Rekonstruktion aus dem Gedächtnis, wenn die Änderung mehr trifft als gedacht:

$stamp = Get-Date -Format yyyyMMdd-HHmm Get-CsCallingLineIdentity | Export-Clixml ".\cid-policies-$stamp.xml" Get-CsOnlinePSTNGateway | Export-Clixml ".\gateways-$stamp.xml" Get-CsTeamsTranslationRule | Export-Clixml ".\translation-$stamp.xml"

 

Danach ändert man gezielt. Zwei typische Beispiele: Die globale Policy wird auf die Nummer des Benutzers zurückgesetzt, und die Hotline-Agenten bekommen eine eigene Policy mit dem Ressourcenkonto über ihre Gruppe:

# Global wieder auf die eigene Nummer Set-CsCallingLineIdentity -Identity Global -CallingIDSubstitute LineUri   # Eigene Policy für die Hotline-Agenten $ra = (Get-CsOnlineApplicationInstance -Identity cq-vertrieb@contoso.com).ObjectId New-CsCallingLineIdentity -Identity CID-Vertrieb-Hotline ` -CallingIDSubstitute Resource -ResourceAccount $ra ` -EnableUserOverride $false -CompanyName "Contoso Vertrieb"   # Rückweg für eine direkte Zuweisung Grant-CsCallingLineIdentity -Identity anna.berger@contoso.com -PolicyName $null

 

TIPP · Immer nur eine Station gleichzeitig ändern Änderst du Policy, Gateway und SBC am selben Nachmittag, weißt du hinterher nicht, welche Änderung geholfen hat, und beim nächsten Fehler auch nicht, welche du zurücknehmen musst. Eine Station ändern, Testanruf auf ein Mobiltelefon, Anzeige notieren, dann die nächste. Teste dabei mindestens drei Fälle: normaler Benutzer, Benutzer mit Ersatznummer, Benutzer mit anonymer Anzeige. Und teste den Notruf nicht nebenbei, sondern nach Absprache; wie das geht, ohne die Leitstelle zu verärgern, ist ein eigenes Thema.

 

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Der Vertrieb wollte, dass Rückrufe auf der Hotline landen. Die passende Policy war schnell gebaut. Zugewiesen wurde sie dann allerdings nicht der Gruppe „Vertrieb Innendienst“, sondern versehentlich der Gruppe „Alle Standorte“, und zwar mit Rang 1. Drei Tage lang rief die gesamte Belegschaft als Hotline an, inklusive Personalabteilung und Geschäftsführung. Die Hotline erhielt in dieser Zeit Rückrufe zu Bewerbungsgesprächen, Lieferterminen und einer Kündigung. Gefunden wurde der Fehler nicht im Monitoring, sondern weil eine Hotline-Kollegin fragte, warum sie plötzlich Gehaltsfragen beantworten soll. Seitdem gibt es dort eine Regel: Policies mit Ersatznummer werden nur Gruppen zugewiesen, deren Name die Funktion enthält, und jede Änderung an Caller ID Policies geht durch eine kurze Freigabe.

 

Der umgekehrte Fall: Teams zeigt eingehende Anrufer falsch an

Manchmal ist es nicht der Kunde, der Unsinn sieht, sondern der Teams-Benutzer. Auch dafür gibt es eine kurze Liste. Ist BlockIncomingPstnCallerID in der wirksamen Policy aktiv, erscheint jeder externe Anrufer als Anonymous. Liefert der SBC die Nummer des Anrufers im From ohne führendes Plus, funktioniert laut Microsoft weder der Abgleich mit Kontakten noch die Prüfung gegen gesperrte Nummern; abhelfen kannst du mit einer Regel unter InboundPstnNumberTranslationRules am Gateway oder einer Regel am SBC. Und wenn Teams einen Namen statt der Nummer zeigt, stammt er aus einer festen Reihenfolge: zuerst die persönlichen Kontakte des Benutzers, dann Outlook- und Entra-ID-Kontakte, dann der mitgeschickte Name, zuletzt die Nummer. Ein Kontakt „Contoso Zentrale“ mit falscher Nummer kann so bei jedem Anruf von dort für Verwirrung sorgen. Kommen eingehende Anrufe gar nicht erst an, hilft Eingehende Anrufe kommen in Teams nicht an.

Vorbeugung: eine Anzeige, die man erklären kann

Global bleibt neutral. Die globale Caller ID Policy sendet die Nummer des Benutzers, ohne Ersatznummer, ohne Anonymisierung. Alles andere ist eine bewusste Ausnahme über eine eigene Policy.

Ersatznummern nur über Funktionsgruppen. Policies mit Ressourcenkonto werden nur Gruppen zugewiesen, deren Zweck eindeutig ist, etwa „Hotline-Agenten Vertrieb“.

Override bewusst entscheiden. Wer EnableUserOverride erlaubt, muss im Helpdesk damit rechnen, dass „Unbekannt“ eine Benutzereinstellung ist und kein Fehler.

Ein Ort für Nummernmanipulation. Entscheide, ob Formatumwandlungen in Teams-Übersetzungsregeln oder am SBC stattfinden, und dokumentiere das. Beide gleichzeitig führt zu doppelter Umwandlung.

PAI immer aus dem Block. Der SBC setzt Richtung Provider einen PAI mit einer Nummer aus deinem Rufnummernblock, auch bei Ersatznummer und anonymen Anrufen.

Notruf ausnehmen. Jede Anzeigeregel am SBC wird gegen 110 und 112 geprüft.

Provider-Eigenschaften dokumentieren. Hinterlegte Blöcke, CLIP no screening und erwartete Header gehören in die Betriebsdokumentation, nicht ins Gedächtnis einer einzelnen Person.

Änderungen beobachten. Wer an Global, Gateways oder Übersetzungsregeln dreht, ändert die Anzeige für viele Benutzer auf einmal. Das gehört in eine Freigabe und in eine Abweichungskontrolle.

Zum letzten Punkt passen zwei Vertiefungen: Konfigurationsdrift in der Teams-Telefonie erkennen zeigt, wie du ungeplante Änderungen erkennst, und Microsoft Teams Telefonie-Governance regelt, wer Caller ID Policies und Gateway-Einstellungen überhaupt ändern darf. Wenn bei dir Policies, SBC-Regeln und Provider über Jahre auseinandergelaufen sind und du sie auf eine gemeinsame Linie bringen willst, ist das ein gutes Thema für eine Beratung zur Teams-Telefonie. Wer SIP-Header, Screening und Caller ID Policies einmal in Ruhe durcharbeiten möchte statt im Störungsfall, ist in der Schulung Teams-Telefonie richtig. Und falls du Direct Routing gerade erst aufbaust: Teams Direct Routing einrichten zeigt, wo die Weichen gestellt werden.

WEITERLESEN · Passend dazu › Teams-Benutzer fällt auf die globale Richtlinie zurück › Teams SBC Grundlagen: der Session Border Controller › SIP-Trunk-Auswahl für Teams Direct Routing › SIP-Fehlercodes in Teams Direct Routing verstehen › Notrufadresse fehlt in Teams: was bei 112 wirklich passiert

 

FAQ

Warum sieht der Angerufene die Zentrale statt meiner Durchwahl?

Meist aus einem von drei Gründen: Deine wirksame Caller ID Policy setzt die Nummer eines Ressourcenkontos ein, eine Übersetzungsregel oder SBC-Regel ersetzt die Nummer, oder der Provider akzeptiert die übermittelte Nummer nicht und setzt die Stammnummer ein. Prüfe in dieser Reihenfolge: Get-CsUserPolicyAssignment, Test-CsTeamsTranslationRule, Trace am SBC, Provider.

Kann ich eine beliebige Nummer als Anrufer-ID verwenden?

Nein. Die Caller ID Policy erlaubt nur die Nummer des Benutzers, Anonymous oder die Nummer eines Ressourcenkontos, das von einer automatischen Telefonzentrale oder Warteschlange genutzt wird. Die Durchwahl eines anderen Benutzers ist ausdrücklich nicht zulässig. Was der Provider darüber hinaus anzeigt, regelt sein Screening.

Was ist CLIP no screening?

Ein Leistungsmerkmal des Providers, bei dem eine von dir gelieferte Nummer ungeprüft angezeigt wird, während die geprüfte Nummer deines Anschlusses für Abrechnung und Notruf erhalten bleibt. Ohne dieses Merkmal sieht der Angerufene die geprüfte Nummer oder die Stammnummer. Welche Nummern du übermitteln darfst, steht in der Leistungsbeschreibung deines Providers.

Was bewirkt ForwardPai am Gateway?

Mit ForwardPai $true schickt Direct Routing im P-Asserted-Identity-Header die echte Identität des Anrufers an den SBC, auch wenn die Anzeige auf ein Ressourcenkonto oder anonym gesetzt ist. Standard ist $false. Dein SBC muss dann wissen, welchen Header er Richtung Provider als Anzeige und welchen als Netznummer verwendet.

Warum zeigt mein Anruf „Unbekannt“, obwohl die Policy die eigene Nummer vorsieht?

Prüfe zuerst, ob EnableUserOverride erlaubt ist und der Benutzer in den Teams-Einstellungen seine Nummer verborgen hat. Der Override hat Vorrang vor der Policy. Danach suchst du im Trace nach einem Privacy-Header und klärst, ob der SBC oder der Provider ihn setzt oder eine ungeprüfte Nummer verwirft.

Gilt die anonyme Anzeige auch für Notrufe?

Nein. Laut Microsoft senden Notrufe aus Teams immer die Nummer des Benutzers an die Notrufabfragestelle. Damit das so bleibt, dürfen Regeln am SBC 110 und 112 nicht anonymisieren.

Ich nutze noch eine Policy mit CallingIDSubstitute Service. Warum wirkt sie nicht?

Microsoft hat den Wert Service abgekündigt. Neue Policies damit lassen sich nicht mehr anlegen, und bestehende werden nicht mehr berücksichtigt. Stelle auf Resource mit einem Ressourcenkonto um.

Wie lange dauert es, bis eine geänderte Caller ID Policy wirkt?

Für die Benutzereinstellung zum Verbergen der Nummer nennt Microsoft einige Minuten. Bei Gruppenzuweisungen kann die Verteilung deutlich länger dauern, bei großen Gruppen auch Stunden. Teste deshalb nicht direkt nach dem Speichern und erkläre den Fehler voreilig für unbehoben.

Fazit: Die Anzeige hat immer recht, nur nicht die, die du erwartest

Eine falsche Rufnummernanzeige ist kein Zufall und selten ein Bug. Sie ist das ehrliche Ergebnis einer Kette, in der Caller ID Policy, Direct Routing, Übersetzungsregeln, SBC und Provider jeweils genau das tun, was man ihnen gesagt hat. Das Problem ist nur, dass man ihnen an verschiedenen Tagen verschiedene Dinge gesagt hat. Wer die Kette von vorne nach hinten prüft, erst im Tenant, dann im Trace, zuletzt beim Provider, findet die verantwortliche Station meist innerhalb einer Stunde.

Dauerhaft hilft nur Ordnung: eine neutrale globale Policy, Ersatznummern nur für klar benannte Gruppen, ein einziger Ort für Nummernmanipulation, ein PAI aus dem eigenen Block und ein Provider, dessen Screening du kennst. Dann sieht der Kunde die Durchwahl, wenn er sie sehen soll, die Hotline, wenn das gewollt ist, und „Unbekannt“ nur noch bei denen, die es ausdrücklich so wollen. Und die Hotline beantwortet wieder Fragen zu Produkten statt zu Gehaltsabrechnungen.