Einseitiges Audio oder kein Ton bei Teams Direct Routing

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Eine Seite hört nichts, und Firewall, SBC und Provider zeigen aufeinander? Wir gehen den Medienweg gemeinsam mit dir durch. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die SDP, NAT und Medienpfade selbst lesen und Mitschnitte am SBC sicher auswerten wollen. › Schulung Teams-Telefonie

 

Es gibt Telefonate, die sind kurz und schmerzlos. Und es gibt die, bei denen der Anrufer dreimal „Hallo?“ sagt, dann ein etwas lauteres „Hallo-o?“, dann ein resigniertes „Na toll“ und auflegt. Auf der anderen Seite sitzt deine Kollegin in Frankfurt, hört jedes Wort, antwortet freundlich und fragt sich, warum der Kunde so unhöflich ist. Willkommen beim einseitigen Audio, dem Fehler, der beide Seiten für unfreundlich hält.

Das Gemeine daran: Technisch ist der Anruf ein Erfolg. Es hat geklingelt, jemand hat angenommen, der SBC meldet 200 OK, der Bericht im Teams Admin Center zeigt einen ganz normalen Anruf mit Gesprächsdauer. Nur die Sprache hat einen anderen Weg genommen als die Signalisierung, und auf diesem Weg steht irgendwo eine Tür, die nur in eine Richtung aufgeht.

In diesem Beitrag gehst du genau diesen Weg ab: Medienpfad mit und ohne Media Bypass, NAT und öffentliche IP-Adresse am SBC, Medienport-Bereiche, Firewall-Regeln. Du lernst, einseitiges Audio sauber von reinen Qualitätsproblemen zu trennen, bekommst lesende PowerShell-Befehle für die Diagnose und konkrete Schritte zur Behebung mit Rollback. Die Grundlagen von Direct Routing setze ich voraus, sie stehen in Teams Direct Routing einrichten. Den Gesamtüberblick über das Thema 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. Session Border Controller sbc1.contoso.com und sbc2.contoso.com, Rufnummern im Muster +49 69 555 0100. Öffentliche IP-Adressen stammen aus dem Dokumentationsbereich 203.0.113.0/24, interne aus 10.0.0.0/8. Ports, Adressbereiche und Verhalten stammen aus der Microsoft-Dokumentation auf Microsoft Learn, Stand November 2026, für die Umgebung Microsoft 365 (nicht GCC High oder DoD).

 

Das Symptom: Der Anruf steht, aber einer redet ins Leere

Was Anwender sagen

Einseitiges Audio kommt beim Helpdesk selten unter diesem Namen an. Es kommt als Geschichte:

„Die Kunden legen einfach auf, sobald ich rangehe.“ Der Teams-Benutzer hört den Anrufer, der Anrufer hört nichts. Das häufigste Bild, und fast immer ein Problem auf dem Weg vom SBC zurück ins Netz.

„Ich höre nur Stille, aber der Anruf läuft.“ Der Teams-Benutzer hört nichts, der Anrufer hört ihn. Die Gegenrichtung, gleiche Familie.

„Am Anfang ging es, nach dem Weiterverbinden war Ruhe.“ Der Medienweg hat mitten im Gespräch gewechselt, etwa weil eine Warteschlange oder eine Konferenz einen Media Processor in den Weg gestellt hat.

„Im Büro klappt alles, im Homeoffice hört mich keiner.“ Ein Hinweis auf Media Bypass und den Transport Relay, oder auf ein VPN, das die Medien durch den Tunnel zwingt.

„Seit dem Firewall-Tausch am Wochenende …“ Der Satz, bei dem du nicht mehr weiter zuhören musst. Die Ursache steht im Änderungsprotokoll, du musst sie nur noch finden.

Was Admins sehen

Und hier wird es zäh: Die üblichen Werkzeuge zeigen nichts Auffälliges. Der SBC ist im Integritätsdashboard unter Sprache › Direct Routing grün, die TLS-Verbindung steht, die SIP-Optionen kommen. Im PSTN-Nutzungsbericht unter Analysen und Berichte steht der Anruf mit Endgrund 200 und einer plausiblen Dauer, meist auffällig kurz, weil der Anrufer nach zwanzig Sekunden aufgibt. Kein SIP-Fehlercode, kein rotes Lämpchen.

Das ist der wichtigste Satz dieses Kapitels: Einseitiges Audio ist kein Signalisierungsfehler. Deshalb findest du es auch nicht mit den Werkzeugen für Signalisierungsfehler. Ein SIP 488 oder ein SIP 503 gehören in SIP-Fehlercodes in Teams Direct Routing verstehen. Wenn der Anruf dagegen zustande kommt und die Sprache fehlt, suchst du auf einer anderen Ebene.

Kein Ton ist nicht schlechter Ton

Bevor du suchst, sortiere ein. Ein Qualitätsproblem bedeutet: Es kommen Pakete an, aber zu spät, zu unregelmäßig oder lückenhaft. Ein Pfadproblem bedeutet: In mindestens einer Richtung kommt gar nichts an. Die beiden haben verschiedene Ursachen, verschiedene Werkzeuge und verschiedene Zuständige. Wer bei einem Pfadproblem anfängt, QoS-Markierungen zu optimieren, poliert die Scheiben eines Autos ohne Motor.

Merkmal	Einseitiges Audio oder kein Ton	Qualitätsproblem
Hörbild	Stille in einer oder beiden Richtungen, oft vom ersten Moment an	Abgehackt, Roboterstimme, Echo, Verzögerung, Aussetzer
Zeitverlauf	Reproduzierbar, bei jedem Anruf über denselben Weg	Schwankend, abhängig von Tageszeit, Last, WLAN
Typische Ursachen	NAT, falsche Adresse im SDP, Firewall, fehlende Ports, Medienweg-Wechsel	Jitter, Paketverlust, hoher Roundtrip, Medien über TCP, überlastete Leitung
Anrufanalyse	Für die betroffene Richtung keine oder unplausible Stream-Werte	Streams vorhanden, Werte für Jitter, Verlust oder Roundtrip schlecht
SIP-Ebene	Unauffällig, Anruf endet normal	Unauffällig, Anruf endet normal
Zuständig	Firewall, SBC-Konfiguration, Provider	Netzwerk, WLAN, Client, Internetanbindung
Weiterlesen	Dieser Beitrag	Sprachqualität, Jitter und Paketverlust

 

Landest du bei Frage 2, bist du hier falsch und in Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip richtig. Klingt es nicht schlecht, sondern bricht die Verbindung nach ein paar Minuten ganz ab, hilft Teams-Anruf bricht nach einigen Minuten ab. Für die Grundlagen von QoS und Call Quality Dashboard gibt es Sprachqualität in Teams: QoS, CQD und Troubleshooting.

Wie der Fehler technisch zustande kommt

Zwei Wege: Signalisierung und Medien

Bei einem Anruf über Direct Routing laufen zwei völlig getrennte Gespräche. Das erste ist die Signalisierung: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC, technisch SIP über TLS zwischen dem SBC und dem SIP-Proxy von Microsoft. Hier wird verhandelt, wer wen anruft, mit welchem Codec, mit welchem Schlüssel und an welche IP-Adresse und welchen Port die Sprache gehen soll. Diese Kette prüfst du, wenn ein Anruf gar nicht erst rausgeht, dazu gibt es Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen.

Das zweite Gespräch ist die Sprache selbst, SRTP über UDP. Sie folgt nicht dem SIP-Proxy, sondern geht ohne Media Bypass zwischen Teams-Client und einem Media Processor in der Microsoft-Cloud und von dort zum SBC. Der SIP-Proxy ist also nur der Vermittler, der die Adressen austauscht. Ob die Pakete dann tatsächlich an diesen Adressen ankommen, interessiert ihn nicht.

Jede Richtung ist ein eigener Datenstrom. Der SBC schickt Pakete zum Media Processor, der Media Processor schickt Pakete zum SBC. Wenn eine dieser beiden Richtungen blockiert ist, hast du einseitiges Audio. Wenn beide blockiert sind, hast du ein Telefonat in kompletter Stille, das trotzdem korrekt abgerechnet wird. Schwarzer Humor der Telefonie: Das Netz merkt es nicht, nur die Menschen.

FAKTEN · Medienports laut Microsoft-Dokumentation Ohne Media Bypass: UDP/SRTP zwischen SBC und Media Processor in beide Richtungen, auf Microsoft-Seite Ports 3478 bis 3481 und 49152 bis 53247. Den Port-Bereich auf dem SBC legst du selbst fest. Adressbereiche der Media Processors für Microsoft 365: 52.112.0.0/14 und 52.120.0.0/14. Microsoft empfiehlt, auf dem SBC mindestens zwei Medienports pro gleichzeitigem Anruf vorzusehen. Medientransport: SRTP, der SBC muss die Cipher-Suite AES_CM_128_HMAC_SHA1_80 mit SDES anbieten. Codecs zwischen Teams und SBC: SILK, G.711, G.722, G.729, AMR-WB nur ohne Media Bypass.

 

Ursache 1: Die falsche Adresse im SDP

In der SIP-Signalisierung steckt das SDP, die Session Description. Darin steht in der Zeile c= die IP-Adresse und in der Zeile m=audio der Port, an den die Gegenseite ihre Sprache schicken soll. Microsoft verlangt für Direct Routing eine öffentliche IP-Adresse, die von Teams aus erreichbar ist. Steht der SBC in einer DMZ hinter NAT, kennt er selbst aber nur seine interne Adresse. Wenn ihm niemand gesagt hat, welche öffentliche Adresse die Firewall für ihn benutzt, schreibt er brav 10.10.1.10 ins SDP.

Was dann passiert, ist reine Logik: Der SBC sendet seine Pakete zum Media Processor. Die Firewall übersetzt die Absenderadresse, die Pakete kommen an, der Teams-Benutzer hört den Anrufer. Der Media Processor schickt seine Pakete an die Adresse aus dem SDP, also an 10.10.1.10. Diese Adresse gibt es im Internet nicht, die Pakete landen im Nirgendwo, der Anrufer hört nichts.

Bei klassischen SIP-Trunks über ungesichertes SIP hat manche Firewall mit einer SIP-ALG versucht, solche Fehler im Vorbeigehen zu reparieren. Bei Direct Routing geht das nicht, denn die Signalisierung ist per TLS verschlüsselt. Die Firewall sieht das SDP gar nicht. Der SBC muss die öffentliche Adresse selbst ins SDP schreiben, bei den gängigen SBCs heißt die Einstellung je nach Hersteller NAT-Adresse, externe Medienadresse oder öffentliche IP der Schnittstelle.

WARNUNG · Die SIP-ALG auf der Providerseite Auf der anderen Seite des SBC, zum SIP-Trunk des Providers, läuft die Signalisierung oft unverschlüsselt über UDP oder TCP 5060. Dort kann eine aktive SIP-ALG in der Firewall das SDP umschreiben, und zwar nicht immer richtig. Wenn das einseitige Audio nur auf dem Bein zum Provider entsteht, prüfe als Erstes, ob die Firewall dort SIP inspiziert. Bei einem SBC, der NAT selbst korrekt behandelt, ist eine SIP-ALG in der Regel überflüssig und stört eher.

 

Ursache 2: Die Firewall lässt nur eine Richtung durch

Die zweite große Gruppe sind Firewall-Regeln, die nur halb fertig sind. Typische Varianten:

Eingehend fehlt. Die Firewall lässt ausgehende UDP-Pakete vom SBC zu, aber keine eingehenden von 52.112.0.0/14 und 52.120.0.0/14 auf den Medienport-Bereich des SBC. Manchmal funktioniert es trotzdem, weil eine zustandsbehaftete Firewall die Antworten als Rückverkehr erkennt, und manchmal nicht, je nach Timing. Das ist der Ursprung des Satzes „geht nur manchmal“.

Nur ein Teil der Adressbereiche. Die Regel enthält nur die IP-Adressen, die gerade aus DNS aufgelöst wurden, oder nur einen der beiden Bereiche. Microsoft weist ausdrücklich darauf hin, alle Teams-Adressbereiche freizuschalten, nicht nur die Ergebnisse einer DNS-Abfrage.

Port-Bereich passt nicht. Der SBC verwendet 40000 bis 41999, die Firewall leitet aber nur 40000 bis 40999 weiter. Bei wenig Last klappt alles, unter Last landen Anrufe auf Ports außerhalb der Regel. Das Ergebnis ist einseitiges Audio, das nur montags um zehn auftritt.

Ausgehend gefiltert. Restriktive Umgebungen lassen vom SBC nur bestimmte Zielports zu und vergessen 3478 bis 3481 oder 49152 bis 53247. Dann hört der Teams-Benutzer nichts.

Richtung	Von	Nach	Ports	Wenn sie fehlt
SBC › Microsoft	SBC, eigener Port-Bereich	52.112.0.0/14, 52.120.0.0/14	UDP 3478-3481, 49152-53247	Teams-Benutzer hört den Anrufer nicht
Microsoft › SBC	52.112.0.0/14, 52.120.0.0/14	Öffentliche IP des SBC	UDP Port-Bereich des SBC	Anrufer hört den Teams-Benutzer nicht
SBC › Provider	SBC	Medien-IP des Providers	laut Provider	Anrufer hört den Teams-Benutzer nicht
Provider › SBC	Medien-IP des Providers	SBC, Provider-Schnittstelle	laut Provider	Teams-Benutzer hört den Anrufer nicht

 

Die Tabelle zeigt, warum Raten so wenig bringt: Dasselbe Hörbild kann auf beiden Beinen des SBC entstehen. „Der Anrufer hört nichts“ heißt entweder, dass die Pakete von Microsoft nicht am SBC ankommen, oder dass der SBC sie nicht zum Provider bekommt. Die Antwort liefert nur ein Mitschnitt. Wie die SIP-Trunk-Seite grundsätzlich aussehen sollte, beschreibt SIP-Trunk-Auswahl für Teams Direct Routing.

Ursache 3: Media Bypass und die drei Medienwege

Mit Media Bypass schickt der Teams-Client die Sprache direkt an den SBC, statt sie über den Media Processor zu leiten. Das spart Umwege, macht die Sache für die Firewall aber komplizierter. Teams-Client und SBC handeln den Weg per ICE aus, der Client mit vollem ICE, der SBC mit ICE Lite. Was Media Bypass grundsätzlich bringt und wann es sich lohnt, steht in Teams Media Bypass und Local Media Optimization.

Laut Microsoft gibt es drei Fälle. Ein Client, der die öffentliche IP-Adresse des SBC erreicht, schickt die Medien direkt dorthin, auch aus dem internen Netz. Auf der Client-Seite nutzt Teams dabei die UDP-Ports 50000 bis 50019. Ein Client, der die öffentliche Adresse nicht erreicht, etwa im Homeoffice, wenn du den SBC nur für Microsoft öffnest, läuft über einen Teams Transport Relay. Dafür müssen zwischen Relay und SBC die Ports 50000 bis 59999 offen sein, vom SBC zum Relay zusätzlich 3478 bis 3481, weil Microsoft zwei Versionen des Relays betreibt. Und schließlich gibt es Anrufe, bei denen immer ein Media Processor im Weg steht, Bypass hin oder her.

WICHTIG · Wann der Media Processor trotz Bypass im Weg steht Laut Microsoft immer bei Sprachanwendungen wie Warteschlange, automatischer Telefonzentrale und Parken, bei Web-Clients im Browser, wenn ein Zweiergespräch zur Gruppe erweitert wird, bei Anrufen zu einem Teams-Benutzer einer anderen Organisation und bei Weiterleitung an Skype for Business. Das heißt: Auch mit Media Bypass brauchst du die Firewall-Regeln für die Media Processors. Wer sie beim Umstieg auf Bypass gelöscht hat, weil ja jetzt alles direkt läuft, baut sich genau das Fehlerbild „nach dem Weiterverbinden war Ruhe“.

 

Daraus folgen die typischen Bypass-Fehler. Interne Clients erreichen die öffentliche Adresse des SBC nicht, weil die Firewall kein NAT-Hairpinning macht, also Pakete von innen an die eigene öffentliche Adresse nicht zurück nach innen schickt. Microsoft nennt Hairpinning auf dem NAT-Gerät ausdrücklich als Möglichkeit, damit der Verkehr das Firmennetz nicht verlässt. Oder ein Gerät übersetzt die Quellports des Clients, und die übersetzten Ports sind nicht freigegeben, auch darauf weist die Dokumentation hin. Oder die Relay-Ports fehlen, und alles außerhalb des Büros ist stumm.

Läuft der Client über ein VPN, das Teams-Medien durch den Tunnel schickt, sieht der Weg noch einmal anders aus. Das ist ein eigenes Thema, siehe Teams-Telefonie über VPN: Split Tunneling richtig einrichten. Und wenn du Media Bypass nur für Clients am selben Standort wie den SBC nutzen willst, kommt Local Media Optimization mit Netzwerkstandorten, Subnetzen und vertrauenswürdigen IP-Adressen ins Spiel. Wie du die pflegst, steht in Netzwerkstandorte und Subnetze in Teams richtig pflegen.

Ursache 4: SBC-Verhalten bei ICE, SRTP und Medienwechsel

Seltener, aber hartnäckig sind Fälle, in denen Netz und Firewall stimmen und der SBC selbst den Ton verliert. Microsoft beschreibt in den Anforderungen für Media Bypass einige Regeln, deren Verletzung genau so aussieht:

Nur ein Kandidat, nur IPv4. Der SBC darf im Bypass-Fall nur einen ICE-Kandidaten anbieten, derzeit nur IPv4.

Keine Änderung zwischen 183 und 200. Schickt der SBC eine vorläufige Antwort 183, darf er ICE-Kandidaten, Passwort und ufrag bis zum 200 OK nicht mehr ändern. Sonst passen die abgeschlossenen Prüfungen nicht mehr zum Gespräch.

Forking verkraften. Klingelt ein Benutzer auf Desktop und Handy gleichzeitig, prüfen beide Endgeräte die Verbindung zum SBC. Der SBC muss mit allen umgehen und sich nach dem 200 OK auf den richtigen Gegenüber einstellen.

Video ablehnen statt ignorieren. Wird ein Teams-Videoanruf ins Telefonnetz weitergeleitet, kann das SDP neben m=audio auch m=video enthalten. Mit Media Bypass muss der SBC diese Zeilen mit Port 0 beantworten.

Solche Fehler beseitigst du nicht in der Firewall, sondern mit einer aktuellen Firmware und der Konfigurationsvorlage des SBC-Herstellers für Teams. Microsoft unterstützt Direct Routing nur mit zertifizierten SBCs und verweist bei Problemen zuerst an den Hersteller. Was SBC und Provider jeweils leisten, beschreibt Teams SBC Grundlagen: der Session Border Controller.

AUS DER PRAXIS · Ulis eigener anynode-SBC Bei mir im Labor steht ein anynode als SBC hinter einer ganz normalen Firewall mit NAT. Eines Abends, nach einem Wechsel des Internetanschlusses, klingelte alles wunderbar, nur hörte mich am anderen Ende niemand. Integritätsdashboard grün, OPTIONS sauber, Anrufe im Bericht mit 200 OK. Die Ursache: Im anynode stand in der Netzwerkkonfiguration für die Teams-Seite noch die alte öffentliche IP-Adresse als NAT-Adresse. Der DNS-Eintrag für den SBC war längst angepasst, also funktionierte die Signalisierung. Das SDP aber nannte Microsoft eine Adresse, die mir nicht mehr gehörte. Fünf Minuten Korrektur, eine Stunde Suche. Seitdem steht die öffentliche Adresse des SBC auf meiner Checkliste für jeden Anschlusswechsel, direkt neben dem DNS-Eintrag.

 

Diagnose Schritt für Schritt

Die Diagnose folgt einer einfachen Idee: Erst herausfinden, welcher Medienweg überhaupt genutzt wird, dann für genau diesen Weg prüfen, in welcher Richtung die Pakete verschwinden. Alle Befehle in diesem Abschnitt sind lesend. Du brauchst das PowerShell-Modul MicrosoftTeams und eine Rolle mit Leserechten für die Telefonie-Konfiguration.

Schritt 1: Das Hörbild genau aufnehmen

Klingt banal, spart aber Stunden. Notiere für zwei, drei konkrete Fälle: Wer hört wen nicht? Eingehend, ausgehend oder beides? Vom ersten Moment an oder erst nach Halten, Weiterleiten, Warteschlange? Welcher Client: Desktop, Mobil, Browser, Tischtelefon? Wo saß der Benutzer: Büro, Homeoffice, VPN? Mit Uhrzeit und beiden Rufnummern. Mehr brauchst du für den Rest nicht, weniger reicht nicht.

Schritt 2: Welcher SBC trägt den Anruf, und wie ist er eingestellt?

Über welchen SBC ein ausgehender Anruf läuft, ergibt sich aus der Voice Routing Policy des Benutzers und den Voice Routes. Für die Medien interessieren dich dann die Gateway-Einstellungen.

Connect-MicrosoftTeams   # Welche Richtlinie und Rufnummer hat der Benutzer? Get-CsOnlineUser -Identity anna.becker@contoso.com | Select-Object DisplayName, LineUri, OnlineVoiceRoutingPolicy   # Welche Routen zeigen auf welche Gateways? Get-CsOnlineVoiceRoute | Select-Object Identity, NumberPattern, Priority, OnlinePstnUsages, OnlinePstnGatewayList   # Medienrelevante Einstellungen des Gateways Get-CsOnlinePSTNGateway -Identity sbc1.contoso.com | Select-Object Identity, Enabled, SipSignalingPort, MediaBypass, BypassMode, MediaRelayRoutingLocationOverride, ProxySbc, GatewaySiteId

 

Ein leeres Feld OnlineVoiceRoutingPolicy bedeutet, dass die globale Richtlinie greift. Ob das gewollt ist, klärt Teams-Benutzer fällt auf die globale Richtlinie zurück. Für dieses Thema ist vor allem MediaBypass entscheidend: Bei False läuft jeder Anruf über einen Media Processor, du prüfst nur die Strecke SBC und Microsoft. Bei True kommen Client-Ports, Transport Relay und gegebenenfalls Hairpinning hinzu. Ein gesetzter ProxySbc oder eine GatewaySiteId deuten auf Local Media Optimization hin. Dann gehören die Netzwerkstandorte mit in die Prüfung:

Get-CsTenantNetworkSite | Select-Object Identity, NetworkRegionID, EnableLocationBasedRouting Get-CsTenantNetworkSubnet | Select-Object Identity, MaskBits, NetworkSiteID Get-CsTenantTrustedIPAddress | Select-Object Identity, MaskBits

 

Eine fehlende oder veraltete vertrauenswürdige IP-Adresse führt dazu, dass Teams einen Client im Büro für extern hält. Dann wählt er den Weg über den Relay, und wenn dessen Ports fehlen, hörst du genau das, was du nicht hören willst: nichts.

Schritt 3: Öffentliche Adresse und DNS abgleichen

Die nächste Frage ist schlicht: Ist die Adresse, auf die der Name des SBC auflöst, dieselbe, die die Firewall als NAT-Adresse für den SBC verwendet, und dieselbe, die der SBC ins SDP schreibt?

# Wohin zeigt der öffentliche DNS-Eintrag? Resolve-DnsName -Name sbc1.contoso.com -Type A   # Vergleiche das Ergebnis mit: # – der NAT-Regel der Firewall für den SBC # – der c=-Zeile im SDP eines aktuellen Anrufs im SBC-Log

 

Drei Adressen, die übereinstimmen müssen. Sind es zwei verschiedene, hast du deine Ursache wahrscheinlich schon gefunden. Hinweis: Die Signalisierung funktioniert auch dann, wenn nur der DNS-Eintrag stimmt. Das SDP kann trotzdem falsch sein, siehe Ulis Labor.

Schritt 4: Den Anruf in der Anrufanalyse ansehen

Im Teams Admin Center findest du unter Benutzer › Benutzer verwalten beim betroffenen Benutzer den Reiter für Anrufverlauf und Anrufanalyse. Dort siehst du je Anruf die Teilnehmer, die Netzwerkinformationen und die Audiostreams mit Jitter, Paketverlust und Roundtrip. Für dieses Thema ist die zentrale Frage: Gibt es für beide Richtungen sinnvolle Werte? Ein Qualitätsproblem zeigt schlechte Werte. Ein Pfadproblem zeigt in einer Richtung keine oder unplausible Werte, während die andere sauber aussieht.

Achte außerdem darauf, welcher Medienweg verwendet wurde und ob der Client über UDP oder TCP verbunden war. Medien über TCP sind kein Grund für Stille, aber ein Zeichen, dass UDP irgendwo geblockt wird, und dieselbe Sperre trifft oft auch den SBC. Dazu mehr in Teams-Telefonie über TCP statt UDP: warum das schlecht klingt.

Schritt 5: Mitschnitt am SBC an beiden Beinen

Jetzt kommt der Teil, der das Rätsel tatsächlich löst. Jeder zertifizierte SBC kann Anrufe mitschneiden oder zumindest RTP-Statistiken je Gespräch zeigen: gesendete und empfangene Pakete, je Richtung und je Bein. Mach einen Testanruf mit der Kombination, die nicht funktioniert, und schau an vier Stellen nach.

SDP lesen. Welche Adresse und welchen Port nennt der SBC Microsoft in der c=- und m=audio-Zeile? Ist das eine öffentliche Adresse? Liegt der Port im Bereich, den die Firewall weiterleitet?

Gegen-SDP lesen. Welche Adresse nennt Microsoft? Ohne Bypass liegt sie in 52.112.0.0/14 oder 52.120.0.0/14, mit Bypass kann es die Adresse des Clients oder eines Relays sein.

Pakete zählen. Kommen am SBC RTP-Pakete von Microsoft an? Gehen welche raus? Dasselbe auf der Providerseite. Die Stelle, an der die Zahl auf null fällt, ist dein Abschnitt.

Firewall-Log dazu. Mit Uhrzeit und Ports aus dem SDP suchst du im Firewall-Log nach verworfenen UDP-Paketen. Ein „deny“ zur richtigen Sekunde beendet jede Diskussion.

TIPP · Zwei Testanrufe sind besser als einer Mache denselben Anruf einmal vom Teams-Client im Büro und einmal von einem Teams-Client im Browser. Der Browser zwingt laut Microsoft den Media Processor in den Weg, auch bei aktivem Media Bypass. Funktioniert der Browser und der Desktop-Client nicht, liegt das Problem im Bypass-Weg. Funktioniert keiner von beiden, liegt es zwischen SBC und Microsoft oder auf der Providerseite.

 

Schritt 6: Die Providerseite nicht vergessen

Stimmt die Teams-Seite, lohnt der Blick nach links. Viele Provider senden Medien von anderen Adressen als die Signalisierung, manche aus größeren Bereichen. Steht in der Firewall nur die Adresse des SIP-Servers des Providers, ist das Audio vom Provider einseitig. Frag deinen Provider nach der vollständigen Liste der Medienadressen und Ports und gleiche sie mit der Firewall ab. Wenn du den Trunk noch auswählst, ist das eine gute Frage für die Ausschreibung.

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Einseitiges Audio hinterlässt keinen SIP-Fehlercode, deshalb hilft der Teams-Telefonie Diagnostiker vor allem beim Eingrenzen. Die Ansicht SIP-Fehlercodes je Gateway zeigt für jeden SBC die Erfolgsquote und die Fehlercodes. Sieht sie für ein Gateway sauber aus, während die Beschwerden kommen, liegt das Problem nicht in der Signalisierung, sondern auf dem Medienweg. Die Anrufqualität stellt je Standort den Anteil schlechter Audiostreams und den Anteil von Medien über TCP statt UDP dar, mit Paketverlust, Jitter, Roundtrip und öffentlicher IP. Damit trennst du Qualitätsprobleme eines Standorts von einem Pfadproblem und erkennst Subnetze ohne Netzwerkstandort. Der Benutzer-Steckbrief zeigt, welche Richtlinie und welche Route ein Benutzer tatsächlich bekommt, die Routing-Landkarte, welche SBCs dahinter stehen. Die Drift-Erkennung meldet geänderte Gateway-Einstellungen, etwa ein umgeschaltetes Media Bypass. Mehr zur Funktionsweise auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung mit Rollback

Vor jeder Änderung gilt: Sichere die aktuelle Konfiguration. Exportiere die Konfiguration des SBC, notiere die betroffenen Firewall-Regeln mit Nummer und Stand und halte die Gateway-Einstellungen aus Teams fest. Der Export ist eine Zeile:

Get-CsOnlinePSTNGateway | Export-Clixml -Path .\pstngateways-vorher.xml

 

Öffentliche Adresse im SBC eintragen

In der Konfiguration des SBC für die Schnittstelle oder das Medienprofil zur Teams-Seite die öffentliche NAT-Adresse eintragen, im Beispiel 203.0.113.10. Die genaue Bezeichnung findest du in der Teams-Vorlage deines SBC-Herstellers.

Prüfen, dass die Adresse zum DNS-Eintrag von sbc1.contoso.com passt.

Testanruf in beide Richtungen, im SDP-Log die c=-Zeile kontrollieren.

Rollback: alte Einstellung aus dem Konfigurationsexport des SBC zurückspielen.

Firewall-Regeln vervollständigen

Eingehend: UDP von 52.112.0.0/14 und 52.120.0.0/14 auf die öffentliche Adresse des SBC, kompletter Medienport-Bereich des SBC, weitergeleitet auf die interne Adresse mit demselben Port.

Ausgehend: UDP vom SBC zu 52.112.0.0/14 und 52.120.0.0/14, Ports 3478 bis 3481 und 49152 bis 53247.

Bei Media Bypass zusätzlich: Client-Ports 50000 bis 50019 zum SBC aus den internen Netzen, Relay-Ports 50000 bis 59999 in beide Richtungen und vom SBC zum Relay 3478 bis 3481. Für interne Clients Hairpinning auf dem NAT-Gerät oder einen internen Weg zur öffentlichen Adresse einrichten.

Providerseite: alle Medienadressen und Ports laut Provider, SIP-ALG für diesen Verkehr abschalten, wenn der SBC NAT selbst behandelt.

Rollback: neue Regeln deaktivieren statt löschen, bis die Tests eine Woche sauber laufen.

Media Bypass als Diagnose abschalten, nicht als Lösung

Vermutest du den Bypass-Weg, kannst du für einen SBC testweise auf den Weg über den Media Processor zurückgehen. Das ändert das Verhalten für alle Benutzer dieses Gateways, also lieber in einem ruhigen Moment:

# Änderung (schreibend) – vorher Export anlegen Set-CsOnlinePSTNGateway -Identity sbc1.contoso.com -MediaBypass $false   # Rollback Set-CsOnlinePSTNGateway -Identity sbc1.contoso.com -MediaBypass $true

 

Ist der Ton danach in beide Richtungen da, liegt das Problem im Bypass-Weg, also bei Client-Ports, Relay-Ports, Hairpinning oder ICE am SBC. Dauerhaft ohne Bypass zu fahren, ist legitim, aber dann bitte als Entscheidung, nicht als vergessener Test. Eleganter ist der Weg, den Microsoft für den Umstieg beschreibt: ein zweites Gateway mit eigenem FQDN, etwa sbc2.contoso.com, das auf denselben SBC zeigt, mit Media Bypass, eigenem TLS-Signalisierungsport und denselben Medienports. Eine eigene Voice Routing Policy führt nur eine Testgruppe darüber. Das Zertifikat muss dann beide Namen abdecken.

WARNUNG · Nicht im laufenden Betrieb am Port-Bereich schrauben Wer den Medienport-Bereich des SBC verkleinert oder verschiebt, ohne die Firewall gleichzeitig anzupassen, erzeugt genau das Fehlerbild, das er beheben wollte. Ändere beides im selben Wartungsfenster, und plane laut Microsoft mindestens zwei Ports pro gleichzeitigem Anruf ein, lieber mit Reserve.

 

Einen Hinweis für Notrufe will ich hier nicht auslassen: Einseitiges Audio trifft auch Anrufe an 110 und 112. Eine Leitstelle, die dich nicht hört, kann dir nicht helfen. Teste nach jeder Änderung am Medienweg auch den Notruf, aber bitte nach Absprache und nicht durch spontanes Wählen. Wie das geht, beschreibt Notruf in Teams testen, ohne die Leitstelle zu verärgern.

Vorbeugung: damit das Hallo ankommt

Einseitiges Audio ist fast nie eine Laune der Natur. Es ist die Folge einer Änderung, bei der jemand die Medien vergessen hat. Firewall-Tausch, neuer Internetanschluss, neue Firmware, Umstieg auf Media Bypass, neuer Provider. Deshalb ist Vorbeugung vor allem Prozess.

Maßnahme	Was du konkret tust	Warum
Testmatrix	Nach jeder Änderung: eingehend und ausgehend, Büro und Homeoffice, Desktop, Mobil und Browser, Weiterleitung in eine Warteschlange, Halten und Zurückholen	Deckt alle drei Medienwege ab, nicht nur den bequemsten
Adressdokumentation	Öffentliche IP, DNS-Eintrag, NAT-Regel und SBC-Einstellung an einer Stelle	Drei Adressen, die sich nicht auseinanderentwickeln dürfen
Firewall-Regeln nach Bereichen	Adressbereiche statt einzelner Adressen aus DNS	Microsoft verlangt alle Bereiche, nicht nur aktuelle Auflösungen
Änderungsprozess	Telefonie als Prüfschritt bei jeder Firewall- und Internetänderung	Die meisten Fälle beginnen mit „seit dem Wochenende“
Monitoring	Kurze Anrufe mit normalem Ende und Beschwerden beobachten, Anrufqualität je Standort	Einseitiges Audio erzeugt keine Fehlercodes
Firmware und Vorlagen	SBC aktuell halten, Teams-Vorlage des Herstellers nutzen	ICE- und SRTP-Verhalten ist Sache des SBC

 

Wer die Telefonie organisatorisch absichern will, damit Firewall-Team, Netzwerkteam und Telefonieteam nicht aneinander vorbeiarbeiten, findet das Gerüst in Microsoft Teams Telefonie-Governance. Dass sich Gateway-Einstellungen still ändern, ohne dass es jemand dokumentiert, behandelt Konfigurationsdrift in der Teams-Telefonie erkennen. Und wenn ihr den Medienweg einmal von außen geprüft haben wollt, bevor die nächste Kundenbeschwerde kommt, hilft die Beratung zur Teams-Telefonie.

WEITERLESEN · Passend dazu › Teams Media Bypass und Local Media Optimization › Sprachqualität in Teams: QoS, CQD und Troubleshooting › Teams SBC Grundlagen: der Session Border Controller › Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip › Teams-Telefonie über TCP statt UDP: warum das schlecht klingt › SIP-Fehlercodes in Teams Direct Routing verstehen › Teams-Anruf bricht nach einigen Minuten ab › Teams-Telefonie Probleme: die zehn häufigsten Ursachen

 

FAQ

Warum hört mich der Anrufer nicht, obwohl ich ihn höre?

Meist kommen die Pakete von Microsoft nicht am SBC an oder der SBC bekommt sie nicht zum Provider. Häufigste Ursachen sind eine private Adresse im SDP des SBC, eine fehlende eingehende Firewall-Regel für den Medienport-Bereich oder eine SIP-ALG auf der Providerseite.

Ist einseitiges Audio ein Qualitätsproblem?

Nein. Bei einem Qualitätsproblem kommen Pakete an, aber gestört. Bei einseitigem Audio kommt in einer Richtung gar nichts an. Die Ursachen liegen bei NAT, Firewall und Medienweg, nicht bei Jitter oder Bandbreite.

Warum zeigt Teams keinen Fehler, wenn niemand etwas hört?

Weil die Signalisierung erfolgreich war. Der Anruf wurde angenommen und normal beendet, die Medien laufen auf einem anderen Weg und erzeugen keinen SIP-Fehlercode.

Welche Ports braucht der SBC für Medien ohne Media Bypass?

Laut Microsoft UDP zwischen dem SBC und 52.112.0.0/14 sowie 52.120.0.0/14, auf Microsoft-Seite Ports 3478 bis 3481 und 49152 bis 53247, in beide Richtungen. Den Port-Bereich am SBC legst du selbst fest, mit mindestens zwei Ports pro gleichzeitigem Anruf.

Darf der SBC hinter NAT stehen?

Ja, solange er über eine öffentliche IP-Adresse erreichbar ist, die öffentliche Adresse selbst ins SDP schreibt und die Firewall den Medienport-Bereich korrekt weiterleitet.

Warum ist der Ton nach dem Weiterleiten in die Warteschlange weg?

Bei Sprachanwendungen wie Warteschlangen steht laut Microsoft immer ein Media Processor im Weg, auch mit Media Bypass. Fehlen die Firewall-Regeln für die Media Processors, bricht der Ton beim Wechsel ab.

Im Büro geht es, im Homeoffice nicht. Woran liegt das?

Mit Media Bypass laufen externe Clients über einen Teams Transport Relay. Dafür müssen zwischen Relay und SBC die Ports 50000 bis 59999 offen sein, vom SBC zum Relay zusätzlich 3478 bis 3481. Auch ein VPN ohne Split Tunneling kann den Weg verbiegen.

Hilft es, Media Bypass abzuschalten?

Als Test ja, weil du damit den Bypass-Weg ausschließt. Als Dauerlösung nur, wenn du dich bewusst dafür entscheidest. Für einen sauberen Umstieg empfiehlt Microsoft ein zweites Gateway mit Bypass für eine Testgruppe.

Kann eine SIP-ALG in der Firewall das Problem lösen?

Auf der Teams-Seite nicht, denn die Signalisierung ist per TLS verschlüsselt. Auf der Providerseite verursacht eine SIP-ALG eher Probleme, als dass sie welche löst, wenn der SBC NAT selbst behandelt.

Fazit: Der Anruf ist nur so gut wie sein Rückweg

Einseitiges Audio bei Teams Direct Routing ist ein Fehler, der sich hinter einem erfolgreichen Anruf versteckt. Die Signalisierung meldet Erfolg, die Berichte sind grün, und trotzdem redet eine Seite ins Leere. Die Ursache liegt fast immer auf dem Medienweg: eine private Adresse im SDP, eine Firewall-Regel, die nur eine Richtung kennt, ein Port-Bereich, der nicht passt, oder ein Media-Bypass-Weg, an den beim Freischalten niemand gedacht hat.

Der Weg zur Lösung ist methodisch und nicht magisch: Hörbild aufnehmen, Medienweg bestimmen, Adressen abgleichen, an beiden Beinen des SBC mitschneiden, Firewall-Log danebenlegen. Wer das einmal sauber durchgezogen hat, findet den nächsten Fall in einer halben Stunde. Und der nächste Fall kommt bestimmt, spätestens nach dem nächsten Firewall-Tausch am Wochenende. Dann bist du derjenige, der als Erster „Hallo?“ sagt und auch eine Antwort bekommt.