Hairpinning in Teams: wenn Anrufe Umwege über andere Standorte nehmen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Zentral oder standortnah ausleiten, Media Bypass oder Local Media Optimization? Wir rechnen deine Standorte gemeinsam mit dir durch. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Rufwege, Netzwerkstandorte und Medienpfade selbst lesen und sauber konfigurieren wollen. › Schulung Teams-Telefonie

 

Offenbach und Frankfurt trennt ein Fluss, eine jahrhundertealte Rivalität und gut acht Kilometer. Ein Teams-Anruf aus der Offenbacher Außenstelle zum Kunden zwei Straßen weiter überbrückt davon gelegentlich deutlich mehr: über das WAN nach Frankfurt, durch die Firewall ins Internet, in ein Microsoft-Rechenzentrum, wieder zurück durch dieselbe Firewall und erst dann zum SBC, der zufällig im selben Keller steht wie die Firewall. Das nennt man Hairpinning. Die Offenbacher nennen es vermutlich anders.

Hairpinning heißt im Netzwerkjargon: Der Verkehr macht eine Haarnadelkurve. Er läuft zu einem Punkt, kehrt dort um und läuft fast denselben Weg zurück. Bei Teams-Telefonie passiert das an zwei Stellen. Erstens beim Rufweg, wenn eine Voice Route einen Anruf zum SBC eines anderen Standorts schickt. Zweitens beim Medienweg, wenn die Sprache nicht direkt zum SBC findet, sondern über die öffentliche Adresse, eine Firewall oder die Microsoft-Cloud wieder zurückkommt. Das Erste ist oft gewollt. Das Zweite fast nie.

Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie und ist problemorientiert. Du bekommst das Symptom, die technische Kette dahinter, eine Diagnose mit lesenden PowerShell-Befehlen, konkrete Behebungsschritte mit Rollback und ein paar Regeln, damit der Umweg nicht zurückkommt. Wie Media Bypass und Local Media Optimization grundsätzlich funktionieren, steht ausführlich in Teams Media Bypass und Local Media Optimization; hier geht es um den Fehlerfall.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com). Zentrale in Frankfurt mit dem einzigen Internetausgang (öffentlich 203.0.113.10) und dem SBC sbc1.contoso.com (intern 10.10.0.5). Außenstelle Offenbach mit dem Subnetz 10.20.0.0/16, per WAN an Frankfurt angebunden, ohne eigenen Internetausgang und ohne eigenen SBC. Weitere Standorte in Köln, Berlin, Hamburg (sbc2.contoso.com) und München. Rufnummern im Muster +49 69 555 0100. Alle Namen, Adressen und Nummern sind erfunden.

 

Das Symptom: Offenbach klingt nach Übersee

So klingt es im Helpdesk

Hairpinning meldet sich nie mit seinem Namen. Es meldet sich über Nebenwirkungen, und die Helpdesk-Tickets sind dabei erstaunlich treffsicher, wenn man sie richtig übersetzt:

„In Offenbach reden wir ständig gleichzeitig, in Frankfurt nicht.“ Mehr Laufzeit. Die Gesprächspartner fallen sich ins Wort, weil die Pause zu lang wird.

„Immer wenn in der Zentrale das Backup läuft, knistert es bei uns.“ Die Sprache teilt sich eine Leitung mit Dingen, die keine Echtzeit brauchen.

„Seit Teams ist die WAN-Leitung nach Frankfurt voll.“ Jeder externe Anruf aus Offenbach läuft durch die Zentrale, im schlimmsten Fall durchs Internet hin und zurück.

„Bei mir im Homeoffice klingt es besser als im Büro.“ Zu Hause geht der Client direkt ins Internet. Im Büro nimmt er die Panoramastrecke.

„Die ersten Sekunden nach dem Annehmen hört man nichts.“ Kann ein Medienpfad sein, der erst über Umwege ausgehandelt wird.

„Seit dem Firewall-Tausch klingen nur die Außenstellen schlecht.“ Der neue Kasten dreht Verkehr auf die eigene öffentliche Adresse anders um als der alte.

So sieht es für Admins aus

Aus Sicht der Konfiguration ist alles grün. Der SBC ist im Teams Admin Center aktiv, die Anrufe kommen zustande, es gibt keine SIP-Fehlercodes und keine auffälligen Abbrüche. Erst die Qualitätsdaten verraten den Umweg: Der Roundtrip der Offenbacher Clients liegt deutlich über dem der Frankfurter, obwohl die Leitung zwischen beiden Standorten kurz ist. Im Direct-Routing-Bericht steht bei Media Bypass ein „Nein“, oder die Offenbacher öffentliche Adresse ist dieselbe wie die der Zentrale, und das Subnetz 10.20.0.0/16 taucht in keiner Netzwerktopologie auf.

Der Fehler ist zäh, weil er nichts kaputt macht. Er macht nur alles ein bisschen schlechter. Und „ein bisschen schlechter“ ist die Ticketkategorie, die erst dann jemand bearbeitet, wenn die Geschäftsführung in Offenbach zu Besuch war und dort telefonieren musste.

Wie der Umweg technisch zustande kommt

Rufweg und Medienweg sind zwei verschiedene Dinge

Bei Direct Routing laufen zwei Ströme nebeneinander her, und beide können einen Umweg nehmen. Die Signalisierung läuft immer zwischen dem Microsoft SIP-Proxy und dem SBC, der Teams-Client spricht dabei mit der Teams-Cloud. Welcher SBC gewählt wird, bestimmt die Kette:

Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC

Die Medien, also die eigentliche Sprache, folgen einer zweiten Kette, die mit Routing gar nichts zu tun hat:

Client › Subnetz › Netzwerkstandort › vertrauenswürdige IP › Media Bypass und BypassMode am SBC › Medienpfad

Ein Umweg in der ersten Kette heißt: Der Anruf geht über den falschen oder einen weit entfernten SBC raus. Ein Umweg in der zweiten Kette heißt: Der richtige SBC ist zwar gewählt, aber die Sprache findet nicht direkt zu ihm. Die meisten Probleme stecken in der zweiten Kette, die meisten Diskussionen drehen sich um die erste. Wie die erste Kette im Detail ausgewertet wird, steht in Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen.

Art des Umwegs	Was passiert	Typische Ursache
Rufweg über fremden Standort	Anrufe aus Offenbach verlassen Contoso über sbc2.contoso.com in Hamburg	Kopierte oder falsch zugewiesene Voice Routing Policy, Rückfall auf die globale Richtlinie
Medien über die Cloud	Sprache läuft vom Client zum Media Processor bei Microsoft und von dort zum SBC	Media Bypass am SBC ausgeschaltet
Medien über die öffentliche Adresse	Client im LAN spricht die öffentliche Adresse des eigenen SBC an, die Firewall dreht um	Media Bypass an, aber keine Local Media Optimization
Medien über die Zentrale	Alle Außenstellen erreichen Microsoft und SBC nur über das WAN und den Internetausgang in Frankfurt	Zentraler Internetausgang, VPN, Proxy
Trunk-Hairpin	Ein externer Anruf wird nach extern weitergeleitet und belegt zwei Kanäle am selben SBC	Rufumleitung, Weiterleitung aus Warteschlangen

 

Drei Wege für dieselbe Sprache

Die Skizze zeigt, was mit dem Gespräch von Jonas Weber in Offenbach passiert, wenn seine Voice Route korrekt auf sbc1.contoso.com in Frankfurt zeigt. Der Rufweg ist in allen drei Fällen derselbe. Der Medienweg nicht.

Weg A: ohne Media Bypass. Die Sprache läuft vom Client über das WAN nach Frankfurt, durch die Firewall ins Internet zum Media Processor von Microsoft und von dort zurück durch dieselbe Firewall zum SBC. Die Internetleitung in Frankfurt trägt jedes Gespräch zweimal, einmal für den Client und einmal für den SBC.

Weg B: Media Bypass ohne Local Media Optimization. Der Client soll direkt mit dem SBC sprechen, bekommt aber nur dessen öffentliche Adresse. Er schickt seine Pakete also an 203.0.113.20 und landet an der Firewall, die das Paket per Hairpin-NAT umdrehen und wieder nach innen schicken muss. Manche Firewalls können das gut, manche schlecht, manche dürfen es laut Regelwerk nicht. Klappt der direkte Weg nicht, finden die ICE-Verbindungsprüfungen einen Umweg über ein Relay in der Microsoft-Cloud, und du bist im Prinzip wieder bei Weg A.

Weg C: Local Media Optimization. Teams erkennt den Client als intern und am Standort Offenbach. Der SBC bietet seine interne Adresse 10.10.0.5 an, die Sprache läuft über das WAN direkt dorthin. Kein Internet, keine Haarnadel.

FAKTEN · Was Microsoft zu Local Media Optimization dokumentiert Local Media Optimization hält Medien innerhalb der Unternehmenssubnetze und erlaubt Medienströme zwischen Client und SBC auch dann, wenn der SBC hinter der Firewall nur eine private Adresse hat. Voraussetzung am SBC-Objekt: MediaBypass muss $true sein. Ohne gesetzten BypassMode sendet Direct Routing die X-MS-Header nicht, der SBC erfährt also nicht, ob der Benutzer intern oder extern ist. Es gibt zwei Modi: Always (interne Benutzer sprechen immer mit der internen Adresse des Ziel-SBC, empfohlen bei guter Verbindung zwischen den Standorten) und OnlyForLocalUsers (direkt nur Benutzer am Standort des SBC, alle anderen über den Proxy-SBC). Ein Client gilt nur dann als intern, wenn seine öffentliche Adresse in den vertrauenswürdigen IPs steht und sein Subnetz einem Netzwerkstandort zugeordnet ist. Für interne Benutzer ist die Verbindung zur internen Adresse des SBC Pflicht. Einen Rückfall auf öffentliche Transport Relays gibt es dann nicht. Standort-IDs wie GatewaySiteID sind case-sensitiv: „Offenbach“ und „offenbach“ sind zwei Standorte. Die vollständige Beschreibung steht bei Microsoft unter Local Media Optimization für Direct Routing.

 

Welcher Weg wird es? Der Entscheidungsweg

Ob ein Gespräch Weg A, B oder C nimmt, entscheidet sich in vier Fragen. Jede Frage hat eine Stelle in der Konfiguration, an der du sie beantworten kannst, und genau daran hängt später die Diagnose.

WICHTIG · Manche Anrufe nehmen den Umweg mit Absicht Laut Microsoft werden Anrufe über Warteschlangen und Auto Attendants nicht per Local Media Optimization optimiert, sie laufen über den Proxy-SBC. Ausnahme: die Weitergabe vom Auto Attendant an einen Benutzer, weil daraus ein normaler 1:1-Anruf wird. Legt ein Benutzer einen Anruf mit Wartemusik auf Halten, wird daraus ein Mehrparteien-Anruf über den Media Processor. Nach dem Zurückholen läuft er weiter über den zentralen bzw. Proxy-SBC, eine Rückstufung auf 1:1 ist nicht vorgesehen. Das ist kein Fehler deiner Konfiguration, sondern dokumentiertes Verhalten.

 

Zentrale oder standortnahe Ausleitung

Bevor du Hairpinning als Fehler bekämpfst, kläre, ob der Rufweg über einen anderen Standort nicht genau so geplant war. Zentrale Ausleitung ist bei Direct Routing eher die Regel als die Ausnahme, und Microsoft beschreibt sie selbst als unterstütztes Szenario: ein zentraler SBC mit einem zentralen SIP-Trunk für alle Niederlassungen. Problematisch ist nicht der zentrale Rufweg, sondern ein Medienweg, der dabei unnötig durchs Internet läuft.

Kriterium	Zentrale Ausleitung	Standortnahe Ausleitung
Geräte und Verträge	Ein SBC-Paar, ein Trunk	SBC und Trunk je Standort oder Region
Laufzeit der Sprache	Länger für entfernte Standorte, mit LMO meist unkritisch	Kurz, Sprache bleibt in der Region
WAN-Bandbreite	Jeder externe Anruf belegt das WAN zur Zentrale	WAN bleibt frei
Ausfallsicherheit	Fällt die Zentrale aus, telefoniert niemand mehr extern	Ausfall bleibt lokal, Ersatzroute über einen anderen Standort möglich
Rufnummern und Ortsnetze	Rufnummern aller Ortsnetze auf einem Trunk, sofern dein Provider das anbietet	Rufnummern bleiben im jeweiligen Ortsnetz beim lokalen Trunk
Notruf	Provider muss den Standort des Anrufers kennen, nicht den des SBC	Standortbezug ergibt sich leichter, Notrufroute je Standort nötig
Betrieb	Wenige Routen, einfach zu überblicken	Mehr Routen, Usages und Zertifikate

 

Für Contoso ist die Antwort für Offenbach einfach. Offenbach liegt im Ortsnetz 069 wie Frankfurt, ein eigener Trunk bringt dort weder Rufnummern noch Tarifvorteile. Die richtige Lösung ist zentrale Ausleitung über sbc1.contoso.com mit lokalem Medienweg. Bei München mit eigenem Ortsnetz, eigener Internetleitung und vielen Arbeitsplätzen kann die Rechnung anders aussehen. Welche Kriterien bei der Wahl des Trunks noch mitspielen, steht in SIP-Trunk-Auswahl für Teams Direct Routing.

WARNUNG · Zentrale Ausleitung und Notruf Wenn alle Standorte über Frankfurt ausleiten, muss ein Notruf an 110 oder 112 aus Offenbach trotzdem bei der für Offenbach zuständigen Stelle ankommen. Wie dein Provider den Standort des Anrufers ermittelt, ob über die übermittelte Rufnummer, eine Standortkennung oder Standortdaten aus Teams, legt er fest, nicht du. Kläre das ausdrücklich und schriftlich, bevor du zentralisierst. Hintergrund und Konfiguration findest du in Notruf in Microsoft Teams konfigurieren und Dynamischer Notruf in Teams funktioniert nicht.

 

Was der Umweg kostet: Laufzeit und Bandbreite

Gesprächsgebühren kostet ein Medienumweg in der Regel nicht, denn die Sprache verlässt Contoso am Ende trotzdem über denselben Trunk. Bezahlt wird mit Laufzeit, Bandbreite und Fehlertoleranz. Jeder zusätzliche Abschnitt bringt eigene Warteschlangen mit, jede zusätzliche Firewall-Passage eine weitere Stelle, an der Pakete verloren gehen oder QoS-Markierungen verschwinden. Microsoft empfiehlt in der QoS-Dokumentation ausdrücklich den kürzesten Weg zu Microsoft 365 und rät von Hindernissen wie Proxys auf dem Weg ab.

Zur Bandbreite eine grobe Rechnung: Microsoft nennt für Audio im Einzelgespräch 58 kbit/s je Richtung als empfohlenen Wert. Telefonieren in Offenbach 40 Leute gleichzeitig nach extern und läuft das über Weg A, trägt die Internetleitung in Frankfurt jedes Gespräch zweimal. Das sind rund 2 × 40 × 58 kbit/s, also etwa 4,6 Mbit/s je Richtung, nur für Offenbach. Bei Weg C taucht davon auf der Internetleitung nichts auf, das WAN trägt die Gespräche in beiden Fällen.

Weg	WAN Offenbach–Frankfurt	Internetleitung Frankfurt	Firewall-Passagen	Risiko
A ohne Bypass	1 × je Gespräch	2 × je Gespräch	2	Mehr Laufzeit, Last auf der Internetleitung
B Bypass ohne LMO	1 × je Gespräch	0 bis 2 ×, je nach Firewall und Relay	1 bis 2	Hängt am Hairpin-NAT der Firewall
C mit LMO	1 × je Gespräch	0	keine, sofern intern geroutet	Keine Ausweichroute für interne Clients

 

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Ein Maschinenbauer mit zwölf Standorten hatte alles richtig gemacht, fand er: ein zentrales SBC-Paar, Media Bypass eingeschaltet, saubere Routen. Nur klangen die Außenstellen schlechter als die Homeoffices. Die Ursache war Weg B. Die neue Firewall in der Zentrale drehte Verkehr auf die eigene öffentliche Adresse nicht mehr um, also landete jedes interne Gespräch auf einem Relay in der Cloud. Eine Netzwerktopologie mit Subnetzen gab es nicht, für Teams waren alle Clients extern. Nach dem Einrichten von Local Media Optimization lief die Sprache intern direkt zum SBC, und die Beschwerden hörten nach ein paar Tagen auf. Die Firewall durfte bleiben, der Firewall-Admin auch.

 

Diagnose Schritt für Schritt

Die Diagnose folgt den beiden Ketten. Erst prüfst du, welchen SBC der Anruf nimmt. Dann prüfst du, wie die Medien zu ihm finden. Alle Befehle in diesem Abschnitt lesen nur, sie ändern nichts. Du brauchst das PowerShell-Modul MicrosoftTeams und eine Rolle mit Leserechten auf die Telefoniekonfiguration.

Schritt 1: Welchen SBC nimmt der Anruf?

Fang beim Benutzer an. Welche Voice Routing Policy hat Jonas, welchen Wählplan, und was macht der Wählplan aus der gewählten Nummer?

Connect-MicrosoftTeams $upn = "jonas.weber@contoso.com" Get-CsOnlineUser -Identity $upn | Select-Object DisplayName, LineUri, OnlineVoiceRoutingPolicy, TenantDialPlan   # Was macht der Wählplan aus der gewählten Nummer? Get-CsEffectiveTenantDialPlan -Identity $upn | Test-CsEffectiveTenantDialPlan -DialedNumber "0695550199" | Select-Object TranslatedNumber, MatchingRule

 

Ist OnlineVoiceRoutingPolicy leer, gilt die globale Richtlinie. Das ist eine der häufigsten Ursachen für Rufwege über fremde Standorte, weil die globale Richtlinie oft auf die Zentrale oder den ersten Standort des Projekts zeigt. Mehr dazu in Teams-Benutzer fällt auf die globale Richtlinie zurück. Mit der normalisierten Nummer suchst du dann die passenden Voice Routes:

$pol = "$((Get-CsOnlineUser -Identity $upn).OnlineVoiceRoutingPolicy)" if (-not $pol) { $pol = "Global" } $usages = (Get-CsOnlineVoiceRoutingPolicy -Identity $pol).OnlinePstnUsages $usages # Reihenfolge zählt $nummer = "+49695550199" Get-CsOnlineVoiceRoute | Where-Object { ($_.OnlinePstnUsages | Where-Object { $usages -contains $_ }) -and ($nummer -match $_.NumberPattern) } | Sort-Object Priority | Select-Object Name, NumberPattern, Priority, OnlinePstnUsages, OnlinePstnGatewayList

 

Steht in OnlinePstnGatewayList bei der greifenden Route sbc2.contoso.com, telefoniert Offenbach über Hamburg. Das ist der Routing-Umweg. Die Filterung oben ist eine Annäherung: Teams wertet zuerst die Usages in ihrer Reihenfolge aus und innerhalb einer Usage die Routen nach Priorität. Bei überdeckten Mustern hilft Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen weiter, den kompletten Rufweg zeigt Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen.

Schritt 2: Wie ist der SBC eingestellt?

Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, MediaBypass, BypassMode, GatewaySiteId, ProxySbc, GatewaySiteLbrEnabled

 

Befund	Bedeutung	Nächster Schritt
MediaBypass = False	Weg A, Medien über den Media Processor	Absichtlich? Dann bleibt es so, sonst Media Bypass planen
MediaBypass = True, BypassMode leer oder None	Weg B, Client bekommt die öffentliche Adresse	Firewall prüfen, Local Media Optimization erwägen
BypassMode gesetzt, GatewaySiteId leer	LMO unvollständig	Standort am SBC eintragen
GatewaySiteId passt nicht exakt zu einem Netzwerkstandort	Benutzer werden nie als lokal erkannt	Schreibweise inklusive Groß- und Kleinschreibung angleichen
ProxySbc auf einen anderen SBC gesetzt, obwohl es nur einen gibt	Unnötige oder ins Leere laufende Proxy-Strecke	Bei einem zentralen SBC ProxySbc auf $null oder den eigenen FQDN

 

Im Teams Admin Center findest du dieselben Werte im Bereich Sprache unter Direct Routing in den Einstellungen des jeweiligen SBC, darunter Media Bypass sowie die Angaben zu Standort, Bypass-Modus und Proxy-SBC.

Schritt 3: Kennt Teams deine Standorte?

Jetzt die zweite Kette. Damit ein Client als intern gilt, müssen seine öffentliche Adresse und sein Subnetz bekannt sein. Prüfe, ob Offenbach für Teams überhaupt existiert:

Get-CsTenantTrustedIPAddress | Select-Object IPAddress, MaskBits, Description Get-CsTenantNetworkRegion | Select-Object NetworkRegionID, Description Get-CsTenantNetworkSite | Select-Object NetworkSiteID, NetworkRegionID, Description Get-CsTenantNetworkSubnet | Sort-Object NetworkSiteID | Select-Object SubnetID, MaskBits, NetworkSiteID   # GatewaySiteId ohne exakt passenden Netzwerkstandort (case-sensitiv) $sites = (Get-CsTenantNetworkSite).NetworkSiteID Get-CsOnlinePSTNGateway | Where-Object { $_.GatewaySiteId -and ($sites -cnotcontains $_.GatewaySiteId) } | Select-Object Identity, GatewaySiteId

 

Fehlt 203.0.113.10 in den vertrauenswürdigen IPs oder 10.20.0.0/16 in den Subnetzen, ist jeder Offenbacher Client für Teams extern. Beachte: Diese Netzwerktopologie ist nicht dasselbe wie die Subnetze im Location Information Service für den Notruf. Wer dort sauber gepflegt hat, ist hier nicht automatisch fertig. Wie du beides konsistent hältst, beschreibt Netzwerkstandorte und Subnetze in Teams richtig pflegen. Im Teams Admin Center liegt die Topologie unter Standorte › Netzwerktopologie, mit eigenen Bereichen für Netzwerkstandorte und vertrauenswürdige IP-Adressen.

Schritt 4: Was zeigen die Anrufdaten?

Die Konfiguration sagt dir, was passieren sollte. Die Anrufdaten sagen dir, was passiert ist.

Direct-Routing-Bericht: Im Teams Admin Center unter Analysen und Berichte findest du im Bericht zur PSTN-Nutzung die Direct-Routing-Anrufe mit dem verwendeten SBC und der Angabe, ob Media Bypass genutzt wurde. Filtere auf die Offenbacher Benutzer und vergleiche mit Frankfurt.

Anrufanalyse je Benutzer: Unter Benutzer › Benutzer verwalten › Jonas Weber zeigt der Anrufverlauf für einzelne Gespräche Netzwerkdetails des Clients, darunter lokale und öffentliche Adresse. Steht dort als öffentliche Adresse 203.0.113.10, geht Offenbach über Frankfurt ins Internet.

Call Quality Dashboard: Werte Roundtrip, Jitter und Paketverlust nach Subnetz bzw. Gebäude aus. Liegt Offenbach deutlich über Frankfurt, obwohl beide denselben Internetausgang nutzen, ist ein Umweg im Medienpfad sehr wahrscheinlich.

Wie du die Qualitätsdaten im Detail liest, steht in Sprachqualität in Teams: QoS, CQD und Troubleshooting und Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip. Wer die Rohdaten lieber selbst auswertet, findet den Weg in Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl.

Schritt 5: Was sagt der SBC?

Am Ende schaut der SBC zu, wer bei ihm ankommt. Ist BypassMode gesetzt, schickt Direct Routing in INVITE und re-INVITE zusätzliche Header mit: X-MS-UserLocation mit internal oder external, X-MS-MediaPath mit der Reihenfolge der SBCs auf dem Medienpfad und X-MS-UserSite mit dem Netzwerkstandort des Benutzers. Steht bei einem Offenbacher Anruf im Büro external, kennt Teams den Standort nicht. Fehlen die Header komplett, ist BypassMode nicht gesetzt.

Zusätzlich lohnt der Blick ins SDP und in den Medienstrom: Von welcher Adresse kommen die Pakete? Eine interne Offenbacher Adresse ist Weg C, die öffentliche Adresse der eigenen Firewall ist Weg B, eine Microsoft-Adresse ist Weg A oder ein Relay.

AUS DER PRAXIS · Mein eigener anynode-SBC In meiner eigenen Umgebung steht ein anynode-SBC hinter der Bürofirewall, Media Bypass ist eingeschaltet. Nach einem Firewall-Update klangen Gespräche vom Schreibtisch aus plötzlich etwas verzögert, aus dem Homeoffice aber einwandfrei. Der Trace am SBC war eindeutig: Die Medien kamen nicht mehr von der Adresse meines Laptops, sondern von einer Microsoft-Adresse. Das Update hatte die Behandlung von Verkehr auf die eigene öffentliche Adresse verändert, der Client fand den SBC nur noch über ein Relay. Klassischer Fall von Weg B wird Weg A. Seitdem gehört ein Testanruf mit Blick in den Trace zu jedem Firewall-Update dazu.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Für den Rufweg zeigt die Routing-Landkarte, welche Voice Routing Policies über welche PSTN Usages und Voice Routes bei welchen SBCs ankommen. So erkennst du, ob die Benutzer in Offenbach auf sbc1.contoso.com in Frankfurt landen oder über eine kopierte Richtlinie auf sbc2.contoso.com in Hamburg. Eine konkrete Nummer für einen konkreten Benutzer spielst du mit dem Rufweg-Simulator durch. Für den Medienweg zeigt die Anrufqualität je Standort die Zahl der Audiostreams, den Anteil schlechter Streams, Roundtrip und öffentliche IP. Läuft ein Standort über die öffentliche Adresse eines anderen, steht das als Hinweis in der Tabelle, im Demo-Tenant etwa „Medien über Frankfurt (Hairpinning)“ bei Offenbach. Die Befunde mit Prüffall beschreiben, was auffällig ist und wie du es selbst nachprüfst. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung: den Umweg abbauen

Die Behebung hängt davon ab, in welcher Kette der Umweg steckt. Für jeden Fall gilt: erst den Ist-Zustand sichern, dann eine Änderung, dann ein Testanruf aus dem betroffenen Standort, dann die nächste Änderung. Telefonie-Konfiguration braucht in Microsoft 365 außerdem etwas Zeit, bis sie überall angekommen ist. Wer nach zwei Minuten den nächsten Hebel umlegt, testet am Ende drei Änderungen gleichzeitig und versteht keine davon.

Fall 1: Der Rufweg führt über einen fremden Standort

Die Offenbacher Benutzer haben die Voice Routing Policy von Hamburg oder gar keine und fallen auf eine globale Richtlinie zurück, die über sbc2.contoso.com ausleitet. Die Lösung ist die richtige Zuweisung, nicht eine neue Route.

# Sichern $upns = Get-Content .\offenbach-benutzer.txt $upns | ForEach-Object { Get-CsOnlineUser -Identity $_ } | Select-Object UserPrincipalName, OnlineVoiceRoutingPolicy | Export-Csv .\vrp-offenbach-vorher.csv -NoTypeInformation -Encoding UTF8   # Ändern (Beispiel für einen Benutzer) Grant-CsOnlineVoiceRoutingPolicy -Identity "jonas.weber@contoso.com" -PolicyName "VRP-DE-Frankfurt"

 

Für ganze Standorte ist die Zuweisung über eine Gruppe sauberer als die Zuweisung je Benutzer, weil neue Kolleginnen und Kollegen dann automatisch richtig landen. Rollback: Aus der CSV die alten Werte wieder zuweisen. War der alte Wert leer, entfernst du die direkte Zuweisung mit -PolicyName $null, dann gilt wieder die globale Richtlinie oder die Gruppenzuweisung.

Fall 2: Rufweg richtig, Medien laufen über Internet oder Cloud

Das ist der klassische Offenbach-Fall: zentrale Ausleitung gewollt, Medienumweg nicht. Die Lösung ist Local Media Optimization. Sie hat einen Teams-Teil und einen SBC-Teil, und beide müssen zusammenpassen. Den SBC-Teil beschreibt dein SBC-Hersteller; nicht jeder SBC unterstützt LMO, die Liste der zertifizierten SBCs bei Microsoft weist das aus. Den Teams-Teil zeigt das folgende Beispiel für Contoso.

# Sichern Get-CsOnlinePSTNGateway -Identity "sbc1.contoso.com" | Export-Clixml .\sbc1-vorher.xml Get-CsTenantNetworkSubnet | Export-Csv .\subnetze-vorher.csv -NoTypeInformation -Encoding UTF8   # Öffentliche Adresse, über die Frankfurt und Offenbach ins Internet gehen New-CsTenantTrustedIPAddress -IPAddress 203.0.113.10 -MaskBits 32 -Description "Contoso Frankfurt"   # Netzwerktopologie New-CsTenantNetworkRegion -NetworkRegionID "DE-Mitte" New-CsTenantNetworkSite -NetworkSiteID "Frankfurt" -NetworkRegionID "DE-Mitte" New-CsTenantNetworkSite -NetworkSiteID "Offenbach" -NetworkRegionID "DE-Mitte" New-CsTenantNetworkSubnet -SubnetID 10.10.0.0 -MaskBits 16 -NetworkSiteID "Frankfurt" New-CsTenantNetworkSubnet -SubnetID 10.20.0.0 -MaskBits 16 -NetworkSiteID "Offenbach"   # Virtuelle Topologie am SBC Set-CsOnlinePSTNGateway -Identity "sbc1.contoso.com" -GatewaySiteID "Frankfurt" ` -MediaBypass $true -BypassMode "Always" -ProxySbc $null

 

Was davon schon existiert, legst du natürlich nicht doppelt an; Schritt 3 der Diagnose hat dir gezeigt, was fehlt. Der Modus Always passt, weil es nur einen SBC gibt und Offenbach gut an Frankfurt angebunden ist. Mit mehreren SBCs und schwachen Verbindungen zwischen den Außenstellen kann OnlyForLocalUsers mit einem Proxy-SBC die bessere Wahl sein. Wenn du die Topologie lieber klickst, findest du im Teams Admin Center dieselben Objekte unter Standorte › Netzwerktopologie.

WARNUNG · Interne Clients haben kein Sicherheitsnetz Sobald ein Client als intern gilt, bietet der SBC seine interne Adresse an, und einen Rückfall auf ein Relay gibt es nicht. Ist die Firewall zwischen 10.20.0.0/16 und 10.10.0.5 für die Medienports des SBC zu, telefoniert Offenbach nach der Änderung nicht schlechter, sondern gar nicht mehr: Verbindung steht, Ton fehlt. Gib die Medienports vorher frei und teste erst mit einem Pilotbenutzer. Wie sich das anfühlt und wie du es eingrenzt, steht in Einseitiges Audio oder kein Ton bei Teams Direct Routing.

 

WICHTIG · VPN und Local Media Optimization Microsoft weist auf einen Sonderfall hin: Wird ein Client im VPN mit Split Tunneling als extern erkannt, kann aber trotzdem die interne Adresse des SBC erreichen, kann das zu langen Rufaufbauzeiten und bei eingehenden Anrufen zu fehlendem Ton führen. Die Empfehlung lautet, den Zugriff von VPN-Benutzern auf die interne Schnittstelle des SBC zu sperren. Wie du Teams-Verkehr am VPN vorbeiführst, beschreibt Teams-Telefonie über VPN: Split Tunneling richtig einrichten.

 

Rollback: Die gesicherten SBC-Werte zurückschreiben, etwa mit $alt = Import-Clixml .\sbc1-vorher.xml und anschließend Set-CsOnlinePSTNGateway mit den alten Werten für MediaBypass, BypassMode, GatewaySiteID und ProxySbc. Neu angelegte Subnetze, Standorte und vertrauenswürdige IPs entfernst du mit den passenden Remove-Cmdlets, aber erst, nachdem du geprüft hast, dass sie nicht auch für Location-Based Routing oder andere Funktionen genutzt werden. Und am SBC die LMO-Einstellungen des Herstellers zurücknehmen, sonst wartet er auf Header, die nicht mehr kommen.

Fall 3: Ein Standort soll wirklich lokal ausleiten

Manchmal ist der Rufweg selbst der Umweg, etwa wenn München mit eigenem Ortsnetz und eigener Internetleitung jeden Anruf über Frankfurt schickt. Dann bekommt München einen eigenen SBC und eine eigene Usage mit Routen, die zuerst lokal ausleiten und im Fehlerfall über Frankfurt.

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DE-MUC"}   New-CsOnlineVoiceRoute -Identity "DE-MUC-National" -NumberPattern '^\+49\d+$' ` -OnlinePstnGatewayList "sbc3.contoso.com" -OnlinePstnUsages "DE-MUC" -Priority 1 New-CsOnlineVoiceRoute -Identity "DE-MUC-National-Ersatz" -NumberPattern '^\+49\d+$' ` -OnlinePstnGatewayList "sbc1.contoso.com" -OnlinePstnUsages "DE-MUC" -Priority 2

 

Zwei Routen mit unterschiedlicher Priorität bilden die Reihenfolge ab. Stünden beide SBCs in einer einzigen Route, würde Teams die Anrufe zwischen ihnen verteilen, und München telefonierte wieder zur Hälfte über Frankfurt. Vergiss die Notrufnummern nicht: 110 und 112 brauchen in der Münchener Usage eine eigene Route mit einem Muster wie ^(110|112)$, die ebenfalls zuerst auf sbc3.contoso.com zeigt. Wie Notrufe sauber geroutet und getestet werden, steht in Notruf in Microsoft Teams konfigurieren. Rollback: Die Usage aus der Voice Routing Policy der Münchener Benutzer nehmen bzw. die alte Policy zuweisen; die neuen Routen kannst du danach entfernen.

Fall 4: Weiterleitungen nach extern

Leitet jemand seine Teams-Rufnummer auf ein externes Handy um, kommt der Anruf über den SBC herein und geht über den SBC wieder hinaus. Das belegt zwei Sprachkanäle auf dem Trunk und ist kein Fehler, sondern Physik. Plane die Kanalzahl entsprechend, wenn Warteschlangen oder ganze Abteilungen nach extern weiterleiten. Welche Rufnummer der Angerufene dabei sieht, entscheiden SBC und Provider; mehr dazu in Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC. Was mit Anrufen passiert, die in Warteschlangen hängen bleiben, behandelt Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen.

Vorbeugung: damit der Umweg nicht wiederkommt

Hairpinning entsteht selten bei der Einführung. Es entsteht danach: mit dem neuen Standort, der kopierten Policy, dem neuen Subnetz, dem Firewall-Tausch. Vorbeugung heißt deshalb vor allem, diese Ereignisse mit der Telefonie zu verknüpfen.

Maßnahme	Was du konkret tust	Warum
Architekturentscheidung dokumentieren	Für jeden Standort festhalten: Ausleitung zentral oder lokal, Medienweg erwartet A, B oder C	Ohne Soll gibt es keine Abweichung
Subnetze im Änderungsprozess	Neue Subnetze gehen automatisch an die Teams-Netzwerktopologie und an den Notruf-LIS	Ein neues Subnetz ohne Standort ist sofort extern
Firewall-Änderungen mit Testanruf	Nach jedem Update ein Testanruf aus einer Außenstelle mit Blick auf den Medienpfad	Hairpin-NAT ändert sich gern still
Policies über Gruppen	Voice Routing Policies je Standort per Gruppenzuweisung	Keine Rückfälle auf die globale Richtlinie bei neuen Benutzern
Qualität je Standort beobachten	Monatlich Roundtrip und schlechte Streams je Standort vergleichen	Ein Umweg zeigt sich als Standort mit auffällig mehr Laufzeit
Konfiguration vergleichen	Regelmäßig SBC-Einstellungen und Topologie gegen den dokumentierten Stand prüfen	MediaBypass oder BypassMode verändern sich nicht von selbst, aber durch Menschen

 

Wer für Netz, Firewall und Telefonie zuständig ist und wer wen bei Änderungen informiert, gehört in ein Betriebskonzept; das Gerüst dafür steht in Microsoft Teams Telefonie-Governance. Dass sich Einstellungen unbemerkt verändern, behandelt Konfigurationsdrift in der Teams-Telefonie erkennen. Wenn du die Frage zentral oder standortnah für viele Standorte sauber entscheiden willst, ist das Festpreispaket Grobkonzept Teams-Telefonie der strukturierte Einstieg, für eine konkrete Störung die Beratung zur Teams-Telefonie.

WEITERLESEN · Passend dazu › Teams Media Bypass und Local Media Optimization › Netzwerkstandorte und Subnetze in Teams richtig pflegen › Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen › Teams-Benutzer fällt auf die globale Richtlinie zurück › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › Einseitiges Audio oder kein Ton bei Teams Direct Routing › Teams-Telefonie über VPN: Split Tunneling richtig einrichten › Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip › Sprachqualität in Teams: QoS, CQD und Troubleshooting › Teams-Telefonie Probleme: die zehn häufigsten Ursachen › Teams SBC Grundlagen: der Session Border Controller › Teams Direct Routing einrichten

 

FAQ

Was bedeutet Hairpinning bei Teams?

Ein Anruf oder seine Sprache nimmt einen Umweg und kehrt an einem Punkt um, statt direkt zum Ziel zu laufen. Typisch sind Medien, die von einem internen Client über die öffentliche Adresse oder die Microsoft-Cloud zum SBC im eigenen Haus laufen, und Rufwege über den SBC eines anderen Standorts.

Ist zentrale Ausleitung über einen SBC grundsätzlich schlecht?

Nein. Microsoft beschreibt einen zentralen SBC mit zentralem Trunk als unterstütztes Szenario. Entscheidend ist, dass der Medienweg kurz bleibt, etwa mit Local Media Optimization, und dass Notruf und Ausfallsicherheit geklärt sind.

Brauche ich Local Media Optimization, wenn ich schon Media Bypass nutze?

Nicht zwingend. Laut Microsoft kannst du bei Media Bypass bleiben, wenn du nur die öffentlichen Adressen deiner SBCs nutzt. Willst du die Medien innerhalb deines Netzes halten, ist LMO der empfohlene Weg.

Warum hören interne Benutzer nach dem Einschalten von LMO nichts mehr?

Weil interne Clients die interne Adresse des SBC erreichen müssen und es keinen Rückfall auf ein Relay gibt. Meist blockiert eine Firewall zwischen Standort und SBC die Medienports.

Werden Warteschlangen und Auto Attendants mit LMO optimiert?

Nein. Laut Microsoft laufen solche Anrufe über den Proxy-SBC. Nur die Weitergabe vom Auto Attendant an einen Benutzer folgt dem optimierten Weg.

Warum läuft ein Gespräch nach dem Halten plötzlich über den zentralen SBC?

Halten mit Wartemusik macht aus dem Gespräch einen Mehrparteien-Anruf über den Media Processor. Nach dem Zurückholen wird er nicht wieder zu einem 1:1-Anruf. Das ist dokumentiertes Verhalten.

Betrifft das auch Anrufe zwischen zwei Teams-Benutzern?

Nur indirekt. Anrufe zwischen Teams-Benutzern laufen nicht über deinen SBC. Ein zentraler Internetausgang oder ein VPN kann aber auch sie verlängern.

Kostet ein Umweg über einen anderen Standort zusätzliche Gesprächsgebühren?

Ein Medienumweg in der Regel nicht, weil der Anruf über denselben Trunk hinausgeht. Ein Rufweg über einen anderen Trunk kann andere Tarife haben, und Weiterleitungen nach extern belegen zwei Kanäle.

Spielt die Schreibweise der Standort-IDs eine Rolle?

Ja. Microsoft dokumentiert die Parameter als case-sensitiv. „Offenbach“ und „offenbach“ sind zwei verschiedene Standorte, und der SBC findet seine Benutzer nicht.

Fazit: kurzer Weg, kurze Leitung

Hairpinning in Teams ist selten ein Totalausfall und gerade deshalb lästig. Der Rufweg über einen zentralen SBC ist oft gewollt und völlig in Ordnung. Der Medienweg über Internet, Firewall und Microsoft-Cloud zurück ins eigene Haus ist es fast nie. Die Diagnose folgt zwei Ketten: Welche Policy, welche Usage, welche Route, welcher SBC? Und dann: Kennt Teams Subnetz, Standort und öffentliche Adresse, ist Media Bypass an, ist BypassMode gesetzt?

Wer beide Ketten sauber pflegt, telefoniert aus Offenbach so, wie es die Geografie nahelegt: über acht Kilometer und nicht über ein Rechenzentrum. Die Rivalität mit Frankfurt bleibt davon unberührt. Dafür ist Teams nicht zuständig.