Teams-Anruf bricht nach einigen Minuten ab

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Anrufe sterben nach 30 Minuten, und SBC, Firewall und Provider zeigen aufeinander? Wir lesen die Mitschnitte gemeinsam mit dir. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die SIP-Dialoge, Session-Timer und Anrufprotokolle selbst lesen und auswerten wollen. › Schulung Teams-Telefonie

 

Es gibt diese Telefonate, bei denen man nach einer halben Stunde ohnehin gern auflegen würde. Das Projektmeeting mit dem Lieferanten, das Jahresgespräch mit dem Steuerberater, die dritte Runde mit dem Support. Wenn Teams dir diese Arbeit abnimmt, ist das trotzdem kein Feature. Vor allem dann nicht, wenn es pünktlich nach 30:00 Minuten passiert, jeden Tag, bei jedem Kollegen, und zuverlässiger ist als die S-Bahn.

Ein Anruf, der mitten im Gespräch abbricht, ist für Anwender eines der ärgerlichsten Telefonieprobleme, weil es keinen Fehler auf dem Bildschirm gibt. Für dich als Admin ist es eines der dankbarsten, sofern du die richtige Frage zuerst stellst: Bricht der Anruf nach einer festen Zeit ab oder zu zufälligen Zeiten? Die erste Antwort führt fast immer zu Session-Timer, re-INVITE, Firewall-Zuständen oder SIP-ALG. Die zweite führt ins Netz, ins WLAN und zu Leuten, die beim Telefonieren durchs Gebäude spazieren.

Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie und ist bewusst problemorientiert. Du bekommst die typischen Symptome, die technische Kette dahinter, eine Diagnose mit Anrufprotokollen, Abbruchgründen und lesenden PowerShell-Befehlen sowie konkrete Schritte zur Behebung mit Rollback. Die Einrichtung von Direct Routing setze ich voraus, sie steht in Teams Direct Routing einrichten.

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. Alle Namen, Adressen und Nummern sind erfunden. Die meisten Ursachen gelten für Direct Routing; die Netzursachen treffen Calling Plan und Operator Connect genauso.

 

Das Symptom: mitten im Satz ist Ruhe

So klingt es im Helpdesk

Abbrüche kommen selten als präzise Störungsmeldung an. Sie kommen als Seufzer, und die Wortwahl ist dabei erstaunlich aufschlussreich. Hör genau hin, denn die Sätze sortieren die Ursachen schon vor:

„Immer genau nach einer halben Stunde fliegt der Kunde raus.“ Klingt nach Uhr. Session-Timer, Gesprächslimit oder ein Zustand, der irgendwo abläuft.

„Nach einer Viertelstunde knackt es kurz, und nach einer halben ist er weg.“ Klingt nach einer misslungenen Auffrischung zur Halbzeit.

„Nur bei externen Anrufen, intern telefonieren wir stundenlang.“ Klingt nach Direct Routing, also SBC, Firewall oder Provider.

„Mal nach drei Minuten, mal nach zwanzig, und nur bei mir.“ Klingt nach Netz, Gerät oder Arbeitsplatz.

„Immer wenn ich vom Büro in die Kaffeeküche gehe.“ Klingt nach WLAN-Roaming. Und nach einem Ehrlichkeitspreis.

„Seit dem Firewall-Tausch am Wochenende.“ Klingt nach dem Satz, den du eigentlich zuerst hören wolltest.

So sieht es für Admins aus

Für dich ist das Bild zunächst enttäuschend unspektakulär. Der SBC ist im Teams Admin Center aktiv, die OPTIONS-Pings laufen, ausgehende und eingehende Anrufe kommen zustande. Im Direct-Routing-Bericht sind die abgebrochenen Gespräche oft als erfolgreiche Anrufe verbucht, denn ein Anruf, der nach 30 Minuten mit BYE endet, ist aus Sicht der Signalisierung ordentlich beendet. Microsoft beschreibt genau diesen Fall: Ein laufender Anruf bricht nach 10 bis 60 Minuten ab, ohne einen Fehlercode zu liefern.

Genau deshalb ist dieser Fehler so zäh. Er versteckt sich zwischen Tausenden normal beendeter Gespräche. Du findest ihn nicht über die Fehlercodes, sondern über die Gesprächsdauer.

FAKTEN · Was Microsoft zu Abbrüchen nach festen Zeiten dokumentiert Abbruch nach etwa vier Sekunden: meist Verbindungs- oder Kommunikationsproblem zwischen SBC und SIP-Proxy, zum Beispiel weil das 100 Trying blockiert wird oder der SBC eine Nachricht nicht mit ACK bestätigt. Abbruch nach etwa 10 bis 20 Sekunden ohne Ton: keine Medieninformationen oder fehlgeschlagene ICE-Verbindungsprüfungen, Teams beendet dann den Anruf. Abbruch nach mehreren Minuten, typischerweise 10 bis 60, ohne Fehlercode: Problem mit Session-Timer oder Session-Refresh, gesteuert über den Header Session-Expires. Session-Timer-Probleme können auch weiter hinten entstehen, etwa beim PSTN-Provider. Dann kommt das BYE vom Provider über den SBC zum SIP-Proxy.

 

Die ersten beiden Fälle sind eigentlich Aufbauprobleme und gehören eher in Einseitiges Audio oder kein Ton bei Teams Direct Routing und SIP-Fehlercodes in Teams Direct Routing verstehen. In diesem Beitrag geht es um den dritten Fall und um seinen unberechenbaren Bruder, den Abbruch zur Unzeit.

Wie der Abbruch technisch zustande kommt

Zwei Familien: Uhr und Zufall

Ein Telefonat besteht bei Direct Routing aus zwei Dingen, die getrennt leben: der Signalisierung (SIP über TLS zwischen SBC und Microsoft SIP-Proxy, SIP zum Provider) und den Medien (SRTP über UDP, im Idealfall). Beide können ein Gespräch beenden. Die Signalisierung tut es mit einem BYE, und zwar oft nach Plan. Die Medien tun es, indem sie einfach nicht mehr ankommen, und zwar nach Lust und Laune des Netzes.

Daraus ergibt sich die wichtigste Unterscheidung des ganzen Beitrags. Abbrüche nach festen Zeiten haben eine Uhr als Ursache: einen Timer, der abläuft, eine Auffrischung, die scheitert, einen Zustand in der Firewall, der verfällt. Abbrüche zu zufälligen Zeiten haben ein Ereignis als Ursache: ein Access Point, der wechselt, ein VPN, das sich neu verbindet, ein Laptop, der Strom spart.

Abbruchmuster	Wahrscheinliche Ursache	Wo du suchst
Nach wenigen Sekunden, etwa vier	Signalisierung zwischen SBC und SIP-Proxy gestört, 100 Trying oder ACK fehlt	Firewall für SIP-Signalisierung, SBC-Trace
Nach 10 bis 20 Sekunden, ohne Ton	Keine Medien oder ICE-Prüfung gescheitert	Medienports, ICE-Kandidaten im SDP
Nach rund 32 Sekunden nach dem Annehmen	Bestätigung (ACK) auf das 200 OK kommt nicht an; nach RFC 3261 gibt die Gegenseite nach 64 × T1, also 32 Sekunden, auf	NAT, Contact-Header, Firewall und ALG auf dem Rückweg
Exakt zur halben Session-Dauer	Die Auffrischung selbst wird abgelehnt, etwa mit 4xx, und eine Seite beendet daraufhin	re-INVITE oder UPDATE und die Antwort darauf im Trace
Exakt nach der vollen Session-Dauer, oft 15, 30 oder 60 Minuten	Session-Timer abgelaufen, weil niemand auffrischt oder die Auffrischung nicht ankommt	Session-Expires, refresher, SBC-Profil zu Teams und zum Provider
Feste Zeit, nur bei Weiterleitung oder Halten	re-INVITE beim Wechsel der Medien scheitert, etwa mit 488	Trace rund um Halten, Übergabe, Warteschlange
Feste Zeit nach Stille, etwa bei Stummschaltung oder Halten	Medien-Inaktivitätstimer am SBC oder UDP-Zustand in der Firewall läuft ab	Medien-Timeout am SBC, UDP-Timeouts der Firewall
Feste, lange Zeit, zum Beispiel nach Stunden	Gesprächslimit beim Provider oder am SBC	Trunk-Vertrag, SBC-Profil, BYE-Absender
Zufällig, einzelne Personen	WLAN, Roaming, Energiesparen, Gerät, VPN	Anrufanalyse je Benutzer, WLAN-Controller
Zufällig, ganzer Standort	Internetanschluss, Paketverlust, Routing, TCP statt UDP	Anrufqualität je Standort, Netzwerkstandorte
Alle zugleich, kurz vor dem Abbruch Störgeräusche	SBC-Neustart, Failover, Provider- oder Dienststörung	SBC-Status, Microsoft-Dienststatus, Provider

 

Session-Timer und re-INVITE: die eingebaute Eieruhr

SIP hat ein Problem: Ein BYE kann verloren gehen. Wenn ein Endpunkt abstürzt, bleibt am anderen Ende eine Sitzung offen, die niemand mehr beendet. Damit solche Zombies nicht ewig Kanäle belegen, gibt es den Session-Timer nach RFC 4028. Wer ein INVITE schickt, schlägt im Header Session-Expires eine Lebensdauer vor und legt mit dem Parameter refresher fest, wer die Sitzung regelmäßig auffrischen muss. Die Auffrischung ist ein re-INVITE oder ein UPDATE. Bleibt sie aus, gilt die Sitzung als tot, und eine Seite sendet BYE.

Microsoft beschreibt das Verhalten so: Der SIP-Proxy bietet den Session-Timer bei Anrufen ohne Media Bypass immer an, bei Anrufen mit Media Bypass bietet er ihn nicht an. Der SBC muss ihn nicht verwenden. Steht im Header etwa Session-Expires: 1800;refresher=uac, endet die Sitzung nach 1800 Sekunden, also 30 Minuten, wenn sie nicht vorher aufgefrischt wird. Bei uac frischt die Seite auf, die das INVITE gesendet hat, bei uas die Seite, die es empfangen hat. Üblicherweise kommt die Auffrischung zur Halbzeit.

FAKTEN · Session-Timer bei Direct Routing in Kürze Ohne Media Bypass bietet der Microsoft SIP-Proxy den Session-Timer immer an, mit Media Bypass nicht. Für den SBC ist die Nutzung nicht verpflichtend. Session-Expires nennt die Lebensdauer in Sekunden, refresher=uac oder refresher=uas legt fest, wer auffrischt. Microsoft nennt als Beispiel 1800 Sekunden. Die Auffrischung erfolgt üblicherweise zur Halbzeit. Bei 1800 Sekunden also nach 15 Minuten. Das Bein zwischen SBC und Provider ist ein eigener SIP-Dialog mit eigenem Session-Timer. Ein Abbruch dort sieht in Teams genauso aus.

 

Wo kann das schiefgehen? An erstaunlich vielen Stellen. Der SBC hält sich für den Auffrischer, sendet aber nichts, weil die Funktion im Profil abgeschaltet ist. Der SBC gibt die Rolle beim Weiterreichen an den Provider falsch weiter, und am Ende glauben beide Seiten, die andere kümmere sich. Die Auffrischung wird gesendet, aber mit einem Inhalt beantwortet, der nicht passt, zum Beispiel 488 wegen eines nicht akzeptierten Medienangebots oder 422, weil das vorgeschlagene Intervall der Gegenseite zu kurz ist. Oder sie geht auf dem Weg verloren, weil eine Firewall sie nicht mehr durchlässt.

Der Sonderfall Media Bypass lohnt einen zweiten Blick. Weil Microsoft dort keinen Session-Timer anbietet, fällt das Teams-Bein als Ursache weitgehend weg. Bricht ein Bypass-Anruf trotzdem nach exakt 30 Minuten ab, sitzt die Uhr fast sicher zwischen SBC und Provider. Mehr zu den Bypass-Pfaden steht in Teams Media Bypass und Local Media Optimization.

Firewall, UDP-Zustände und SIP-ALG

Firewalls haben ein kurzes Gedächtnis. Für jede Verbindung merken sie sich einen Zustand, und der verfällt nach einer Leerlaufzeit. Bei TCP ist das meist großzügig, bei UDP oft knapp bemessen. Solange Sprache fließt, ist das kein Problem, weil ständig Pakete laufen. Kritisch wird es in Pausen: Halten, Stummschaltung, Warteschleifen ohne Musik, oder Endpunkte, die in Sprechpausen kaum Pakete senden. Wenn der Zustand für den Medienstrom oder für die SIP-Signalisierung zum Provider dann verfällt, kommt die nächste Nachricht nicht mehr durch. Hat die Firewall die Port-Zuordnung beim Wiederaufleben auch noch geändert, weiß der SBC nicht mehr, wohin.

Die zweite Spezialität ist die SIP-ALG, je nach Hersteller auch SIP-Helper oder SIP-Fixup genannt. Sie liest unverschlüsselte SIP-Nachrichten mit und schreibt Adressen um, um NAT zu helfen. Das hilft in der Theorie Telefonen ohne eigene NAT-Behandlung. In der Praxis schreibt sie bei einem SBC, der NAT selbst korrekt behandelt, Dinge um, die niemand umgeschrieben haben wollte. Besonders gern trifft es Nachrichten mitten im Gespräch, also genau die Auffrischungen. Auf dem Teams-Bein kann die ALG nichts anrichten, weil die Signalisierung per TLS verschlüsselt ist. Auf dem Provider-Bein läuft SIP aber häufig unverschlüsselt über UDP, und dort hat die ALG freie Bahn.

WARNUNG · Die doppelte NAT-Behandlung Wenn der SBC NAT selbst behandelt und die Firewall per SIP-ALG zusätzlich korrigiert, wird zweimal umgeschrieben. Der Aufbau funktioniert oft trotzdem, weil die erste Nachricht noch passt. Die Auffrischung nach 15 Minuten trifft dann eine Adresse, die es so nie gab. Ergebnis: Abbruch nach 30 Minuten, und alle Beteiligten schwören, an ihrer Stelle sei alles korrekt.

 

Netz, WLAN-Roaming und VPN: der Zufall

Abbrüche ohne festen Zeitpunkt entstehen meist am anderen Ende der Kette, beim Client. Ein Teams-Client überlebt kurze Aussetzer, versucht die Verbindung wiederherzustellen und holt den Ton zurück. Dauert die Unterbrechung zu lange oder ändert sich die Netzadresse des Clients so, dass der Medienweg neu gefunden werden muss und das nicht gelingt, endet der Anruf.

WLAN-Roaming: Der Laptop wechselt beim Gang durchs Gebäude den Access Point. Ist das Roaming langsam, landet der Client kurz in einem anderen Netz oder bekommt eine neue Adresse, reißt der Medienstrom ab.

Energiesparen: Netzwerkkarten und WLAN-Adapter mit aggressiven Stromsparoptionen schlafen gern zwischendurch ein. Im Akkubetrieb häufiger als am Netzteil.

VPN: Ein Full-Tunnel-VPN, das sich neu verbindet, schneidet den Medienstrom ab. Läuft Teams-Medien überhaupt durch den Tunnel, ist schon die Grundlage falsch. Dazu

Mobilfunk: Wechsel zwischen WLAN und Mobilfunk oder Funklöcher im Zug. Hier ist der Abbruch eher Physik als Konfiguration.

Standortnetz: Paketverlust, überlastete Leitungen oder Medien über TCP statt UDP machen Gespräche instabil, bevor sie abbrechen. Siehe

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Beschwerden über abgebrochene Anrufe kamen aus allen Standorten, die Telefonie stand schon unter Generalverdacht. Die Auswertung der Gesprächsdauern zeigte zwei völlig verschiedene Bilder: An einem Standort brachen externe Gespräche nach exakt 30 Minuten ab, die SIP-ALG der neuen Firewall auf dem Provider-Bein war schuld. In der Konstruktion an einem anderen Standort brachen Gespräche zufällig ab, aber nur bei Laptops, die vom Schreibtisch in die Halle getragen wurden. Ein Problem, zwei Ursachen, zwei Teams, die jeweils recht hatten, dass es bei ihnen nicht liegt. Nur eben nicht für beide Fälle.

 

Diagnose Schritt für Schritt

Die Diagnose folgt einer strengen Reihenfolge: erst das Muster aus den Anrufprotokollen, dann der Absender des BYE, dann die Konfiguration, zuletzt der Mitschnitt. Wer mit dem Mitschnitt anfängt, hat am Ende sehr viel Text und keine Hypothese.

Schritt 1: Das Muster in den Anrufprotokollen finden

Im Teams Admin Center findest du unter Analysen und Berichte › Nutzungsberichte den Bericht PSTN- und SMS-Nutzung mit dem Reiter Direct Routing. Wähle 7 oder 28 Tage, lass den Bericht laufen und exportiere die Tabelle nach Excel. Microsoft nennt eine typische Verzögerung von 24 bis 48 Stunden, der Bericht ist also nichts für den Live-Betrieb, aber genau richtig für Muster.

Interessant sind diese Spalten: Startzeit, Endzeit, Dauer in Sekunden, Erfolg, SBC-FQDN, Media Bypass, Final SIP code, Final Microsoft subcode und Final SIP Phrase. Sortiere nach Dauer und bilde Klassen nach Minuten. Wenn auffällig viele Gespräche bei 1799 bis 1810 Sekunden enden, hast du deine Uhr gefunden. Liegen die Abbrüche gleichmäßig verteilt, filtere nach Benutzer und SBC.

TIPP · Die Dauer richtig lesen Die Dauer im Direct-Routing-Bericht zählt laut Microsoft vom INVITE bis zum Ende, nicht ab dem Annehmen. Bei einem 30-Minuten-Timer siehst du deshalb 30 Minuten plus Klingelzeit. Rechne mit Startzeit und Endzeit, wenn du es genau willst. Die Startzeit ist bei ausgehenden Anrufen der Moment, in dem der SIP-Proxy das 200 OK vom SBC erhalten hat.

 

Für regelmäßige Auswertungen gibt es dieselben Daten auch über Microsoft Graph. Die Funktion getDirectRoutingCalls liefert die Zeilen mit Feldern wie duration, finalSipCode, finalSipCodePhrase, callEndSubReason und trunkFullyQualifiedDomainName. Sie verlangt eine App-Registrierung mit der Anwendungsberechtigung CallRecords.Read.All; delegierte Berechtigungen werden nicht unterstützt. Lesend sieht das in PowerShell mit dem Graph-Modul etwa so aus:

# Anmeldung als App mit CallRecords.Read.All (Zertifikat), nur lesend Connect-MgGraph -ClientId $AppId -TenantId $TenantId -CertificateThumbprint $Thumb   $uri = "https://graph.microsoft.com/v1.0/communications/callRecords/" + "getDirectRoutingCalls(fromDateTime=2026-10-01,toDateTime=2026-11-01)" $rows = @() do { $r = Invoke-MgGraphRequest -Method GET -Uri $uri $rows += $r.value $uri = $r.'@odata.nextLink' } while ($uri)   # Abbrüche nach Minuten klassieren $rows | Where-Object { $_.successfulCall } | Group-Object { [math]::Floor($_.duration / 60) } | Sort-Object Count -Descending | Select-Object -First 10 Name, Count

 

Wichtig für die Auswertung: Ein Anruf, der durch einen abgelaufenen Session-Timer endet, erscheint dort häufig als erfolgreicher Anruf mit einem BYE als Abschluss. Wer nur nach fehlgeschlagenen Anrufen filtert, findet ihn nie. Wie du die Protokolle grundsätzlich auswertest, beschreibt Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl. Daten sind in Deutschland für Direct Routing laut Microsoft 150 Tage verfügbar; das reicht, um ein Vorher und Nachher zu vergleichen.

Schritt 2: Wer hat das BYE geschickt?

Hast du einen Kandidaten, öffnest du im Direct-Routing-Bericht den SIP-Anrufablauf. Du kommst über die Schaltfläche SIP call flow oder über einen Klick auf den Final SIP code der Zeile hin. Die Ansicht zeigt als Leiterdiagramm jede SIP-Nachricht zwischen SBC und SIP-Proxy in zeitlicher Reihenfolge, mit Details zu jeder Nachricht. Microsoft nennt bis zu 30 Minuten Verarbeitungszeit, Anrufe älter als 30 Tage sind in dieser Ansicht nicht mehr verfügbar.

Drei Fragen beantwortest du hier:

Kommt das BYE vom SBC oder vom SIP-Proxy? Kommt es vom SBC, hat er es entweder selbst ausgelöst oder vom Provider weitergereicht. Kommt es vom SIP-Proxy, ist das Teams-Bein die Spur.

Welcher Session-Timer steht im ersten INVITE und im 200 OK? Lies Session-Expires und refresher. Rechne die Halbzeit aus und vergleiche sie mit dem Zeitstempel der Auffrischung.

Gab es zur Halbzeit einen re-INVITE oder ein UPDATE, und wie wurde geantwortet? Fehlt er ganz, frischt niemand auf. Steht da eine 4xx-Antwort, wurde aufgefrischt, aber abgelehnt.

Schritt 3: Konfiguration lesend prüfen

Die Teams-Seite des Trunks hat keinen Parameter für den Session-Timer, das regelt der SBC. Trotzdem lohnt der Blick auf das Gateway, denn Media Bypass verändert das Verhalten, und ein zweiter SBC im Routing kann erklären, warum nur ein Teil der Anrufe betroffen ist. Alle Befehle aus dem MicrosoftTeams-Modul sind rein lesend:

Connect-MicrosoftTeams   # Gateways: aktiv, Media Bypass, Port, OPTIONS Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, MediaBypass, SipSignalingPort, SendSipOptions, ForwardCallHistory, ForwardPai   # Welche Routen nutzen welchen SBC? Get-CsOnlineVoiceRoute | Select-Object Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList   # Welche Richtlinie hat der betroffene Benutzer? Get-CsOnlineUser -Identity anna.becker@contoso.com | Select-Object DisplayName, LineUri, EnterpriseVoiceEnabled, OnlineVoiceRoutingPolicy   # Netzwerkstandorte und Subnetze, falls Media Bypass oder LMO im Spiel ist Get-CsTenantNetworkSite | Select-Object Identity, NetworkRegionID Get-CsTenantNetworkSubnet | Select-Object SubnetID, MaskBits, NetworkSiteID

 

Zeigt die Auswertung aus Schritt 1, dass nur Anrufe über sbc1.contoso.com betroffen sind, und die Routen verteilen Köln auf sbc2.contoso.com, hast du schon eine Erklärung, warum Köln zufrieden ist. Hier geht es nicht darum, ob der Anruf rausgeht, sondern wie lange er durchhält. Die Grundlagen zum Gateway selbst stehen in Teams SBC Grundlagen: der Session Border Controller.

Schritt 4: Mitschnitt am SBC, beide Beine

Der SIP-Anrufablauf im Teams Admin Center zeigt nur das Teams-Bein. Das Provider-Bein siehst du nur am SBC. Starte einen Testanruf, der länger dauert als die verdächtige Zeit plus ein paar Minuten, und schneide beide Beine mit. Wenn der Fehler bei 30 Minuten zuschlägt, telefonierst du eben 35 Minuten mit der Zeitansage. Das ist die meditativste Viertelstunde in deinem Admin-Leben.

Prüfpunkt im Trace	Gut	Verdächtig
Session-Expires im INVITE und im 200 OK, je Bein	Werte und Auffrischer sind auf beiden Seiten eindeutig	Unterschiedliche Auffrischer, Wert im 200 OK fehlt
Auffrischung zur Halbzeit	re-INVITE oder UPDATE kommt pünktlich, Antwort 200 OK	Keine Auffrischung, oder Antwort 4xx wie 422 oder 488
Absender des BYE	Teilnehmer legt auf, BYE kommt vom Endgerät	BYE genau nach Ablauf der Session-Dauer, ohne Benutzeraktion
Adressen in Via, Contact und SDP auf dem Provider-Bein	Unverändert so, wie der SBC sie sendet	Vom Provider empfangene Adressen weichen ab, Hinweis auf ALG
Medien vor dem Abbruch	RTP läuft bis zum BYE in beide Richtungen	RTP endet Sekunden vor dem BYE, Hinweis auf Medien-Timeout

 

AUS DER PRAXIS · Uli und sein anynode-SBC Ich stelle solche Fälle gern in meinem eigenen Labor nach, mit einem anynode-SBC zwischen Teams und einem SIP-Trunk. Der Trick ist simpel: den Session-Timer auf dem Provider-Bein testweise auf einen kurzen Wert setzen, die Auffrischung abschalten und mitschneiden. Nach ein paar Minuten liegt das Muster auf dem Tisch, und du siehst im Trace genau, wie ein abgelaufener Timer aussieht. Wer das einmal im Labor gesehen hat, erkennt es im Produktivsystem in Sekunden. Danach die Einstellungen natürlich zurückdrehen, sonst baust du dir den Fehler, den du gerade verstanden hast.

 

Schritt 5: Zufällige Abbrüche einkreisen

Gibt es keine feste Zeit, wechselst du die Datenquelle. Die Anrufanalyse im Teams Admin Center zeigt für einen einzelnen Benutzer unter Benutzer › Benutzer verwalten › Name › Besprechungen und Anrufe jedes Gespräch mit Gerät, Netzwerktyp, WLAN-Informationen und Qualitätswerten. Achte auf drei Dinge: Wechselt der Netzwerktyp, etwa von WLAN zu kabelgebunden? Ändert sich die lokale Adresse oder der Access Point im Lauf des Gesprächs? Und steigen Paketverlust und Roundtrip kurz vor dem Ende sprunghaft?

Für das Gesamtbild nimmst du das Call Quality Dashboard. Dort gibt es den Messwert für abgebrochene Streams, also aufgebaute Medienströme, die nicht normal beendet wurden. Schneide ihn nach Gebäude, Subnetz, Netzwerkverbindungstyp und Client auf. Damit das funktioniert, müssen deine Subnetze im CQD und als Netzwerkstandorte gepflegt sein, sonst landet alles in einem anonymen Topf. Wie das geht, zeigt Netzwerkstandorte und Subnetze in Teams richtig pflegen, die Grundlagen zum CQD stehen in Sprachqualität in Teams: QoS, CQD und Troubleshooting.

Wo du suchst	Was du dort findest	Gut für
Direct-Routing-Bericht im Teams Admin Center	Dauer, Erfolg, Final SIP code, SBC, Media Bypass, Export	Muster über viele Anrufe
SIP-Anrufablauf (SIP call flow)	Leiterdiagramm SBC und SIP-Proxy, Nachrichtendetails	Absender des BYE, Session-Expires, re-INVITE
Graph getDirectRoutingCalls	Dieselben Daten maschinell, mit callEndSubReason	Regelmäßige Auswertung, Vorher und Nachher
SBC-Trace	Beide Beine, Medienstatistik	Provider-Seite, ALG, Medien-Timeout
Anrufanalyse je Benutzer	Gerät, Netz, WLAN, Qualität pro Gespräch	Zufällige Abbrüche einzelner Personen
Call Quality Dashboard	Abgebrochene Streams nach Gebäude, Subnetz, Verbindungstyp	Zufällige Abbrüche an Standorten

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Abbrüche nach festen Zeiten erzeugen oft keinen Fehlercode, Abbrüche zu zufälligen Zeiten hinterlassen Spuren in der Qualität. Der Teams-Telefonie Diagnostiker setzt an beiden Stellen an. Die Ansicht SIP-Fehlercodes je Gateway zeigt für jeden SBC die Erfolgsquote und die SIP-Ergebnisse der letzten 7 Tage und des Gesamtzeitraums. Häufen sich auf einem Gateway Codes wie 488, ist das ein Hinweis auf gescheiterte Medienverhandlungen, wie sie auch bei Auffrischungen vorkommen. Die Anrufqualität stellt je Standort den Anteil schlechter Audiostreams und den Anteil von Medien über TCP statt UDP dar, mit Paketverlust, Jitter und Roundtrip. Damit grenzt du zufällige Abbrüche auf Standorte und Subnetze ein. Die Befunde mit Prüffall beschreiben, was auffällig ist und wie du es nachprüfst, 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: die Uhr richtig stellen

Die Behebung hängt am Ergebnis der Diagnose. Ändere immer nur einen Parameter pro Schritt, notiere den Ausgangswert und belege die Wirkung mit einem Testanruf, der länger dauert als die kritische Zeit. Alles andere ist Würfeln mit Produktionsdaten.

Session-Timer am SBC zum Teams-Bein

Rolle klären: Lies im Trace, welcher Auffrischer vereinbart ist. Microsoft formuliert die Lösung nüchtern: Die richtige Seite muss rechtzeitig vor Ablauf einen re-INVITE senden.

Auffrischung aktivieren: Ist der SBC Auffrischer, muss die Session-Timer-Unterstützung im Teams-Profil aktiv sein. Bei vielen Herstellern ist das Teil der Teams-Vorlage; vergleiche dein Profil mit der aktuellen Vorlage deines Herstellers.

Antworten prüfen: Lehnt eine Seite die Auffrischung mit 488 ab, stimmt das Medienangebot im re-INVITE nicht, zum Beispiel weil sich Codec oder Krypto-Parameter geändert haben. Bei 422 ist das angebotene Intervall zu kurz für die Gegenseite.

Testen: Testanruf über die volle Session-Dauer, Trace prüfen: Auffrischung zur Halbzeit, Antwort 200 OK, kein BYE zur vollen Zeit.

Provider-Bein und Gesprächslimits

Kommt das BYE vom Provider, liegt der Ball dort, aber du kannst ihn vorbereiten. Frag nach dem erwarteten Session-Timer, nach dem Auffrischer und nach eventuellen Gesprächslimits. Gleiche das Profil am SBC an diese Werte an. Viele SBCs behandeln die Session-Timer beider Beine getrennt; das ist gut so, denn dann muss die Auffrischung nicht quer durch beide Dialoge gereicht werden. Bei der Auswahl eines neuen Trunks gehört die Frage nach Session-Timern ins Pflichtenheft, siehe SIP-Trunk-Auswahl für Teams Direct Routing.

Firewall und SIP-ALG

SIP-ALG abschalten für den Verkehr zwischen SBC und Provider, wenn der SBC NAT selbst behandelt. Für das Teams-Bein spielt sie wegen TLS keine Rolle.

Leerlaufzeiten erhöhen für die Zustände der SIP-Signalisierung zum Provider und für den Medienport-Bereich des SBC, gezielt für diese Regeln und nicht global.

Port-Zuordnung stabil halten: Für den SBC eine feste NAT-Zuordnung verwenden, damit sich Adresse und Port im Gespräch nicht ändern.

Medien-Inaktivität am SBC prüfen: Ist der Timer kürzer als eine realistische Halte- oder Stummschaltpause, verlängern oder Musik in der Warteschleife verwenden.

Netz, WLAN und VPN

WLAN-Roaming mit dem Netzwerkteam prüfen, Funkausleuchtung in Fluren und Hallen, schnelle Übergabe zwischen Access Points.

Energiesparoptionen der Netzwerkadapter auf Telefonie-Arbeitsplätzen entschärfen.

Teams-Medien am VPN vorbeiführen, wie in den Microsoft-Empfehlungen für Split Tunneling beschrieben.

Netzwerkstandorte und Subnetze pflegen, damit du Abbrüche Standorten zuordnen kannst.

Bei häufigen Abbrüchen einzelner Personen das Endgerät tauschen, bevor du das Netz neu baust.

WICHTIG · Rollback, bevor du anfängst Sichere vor jeder Änderung die SBC-Konfiguration als Datei und exportiere die betroffenen Firewall-Regeln. Notiere Session-Timer, Auffrischer, Medien-Timeout und ALG-Status als Ausgangswerte. Wird es schlechter, spielst du die Sicherung zurück und hast in fünf Minuten den alten Zustand. Ohne Sicherung hast du in fünf Minuten nur eine längere Nacht. Teste nach Änderungen an Profilen auch den Notruf. Ein Gespräch mit 110 oder 112, das nach 15 Minuten abbricht, ist kein Schönheitsfehler. Teste aber bitte nach Absprache und nicht durch spontanes Wählen.

 

Wie du den Notruf testest, ohne die Leitstelle zu blockieren, beschreibt Notruf in Teams testen, ohne die Leitstelle zu verärgern.

Maßnahme	Wirkung	Rollback
Session-Timer am Teams-Profil aktivieren	Auffrischung zur Halbzeit, kein Ablauf	Profil aus Sicherung zurückspielen
Auffrischer anpassen	Eindeutige Zuständigkeit je Bein	Ausgangswert wieder setzen
SIP-ALG auf dem Provider-Bein abschalten	Keine Umschreibung von Auffrischungen	ALG wieder einschalten, Regelsatz zurückspielen
UDP-Leerlaufzeit für SBC-Regeln erhöhen	Zustände überleben Pausen	Alte Werte setzen
Medien-Inaktivität am SBC verlängern	Halten und Stummschalten beenden das Gespräch nicht	Ausgangswert wieder setzen
Teams-Medien am VPN vorbei	Kein Abbruch bei Tunnel-Neuaufbau	VPN-Profil zurückverteilen

 

Wenn Firewall, SBC und Provider seit Wochen einander die Schuld geben, lohnt ein Blick von außen. In der Beratung zur Teams-Telefonie lesen wir die Mitschnitte gemeinsam und trennen Uhr von Zufall, bevor jemand an drei Stellen gleichzeitig dreht.

Vorbeugung: damit die halbe Stunde kein Limit ist

Abbrüche nach festen Zeiten entstehen fast immer durch eine Änderung, bei der niemand lange genug getestet hat. Fünf Minuten Testanruf nach dem Firewall-Tausch finden keinen 30-Minuten-Timer. Das ist keine Nachlässigkeit, das ist Mathematik.

Maßnahme	Was du konkret tust	Warum
Langer Testanruf	Nach jeder Änderung an SBC, Firewall oder Trunk ein Gespräch über mindestens 35 Minuten, eingehend und ausgehend	Nur so siehst du Timer, die erst nach einer halben Stunde zuschlagen
Dauer-Monitoring	Monatlich die Verteilung der Gesprächsdauern je SBC auswerten	Eine Häufung bei einer festen Zeit fällt sofort auf
Dokumentierte Ausgangswerte	Session-Timer, Auffrischer, Medien-Timeout, ALG-Status, UDP-Leerlaufzeiten an einer Stelle	Bei der nächsten Änderung weißt du, was vorher galt
Änderungsprozess	Telefonie als Prüfschritt bei jeder Firewall- und Internetänderung	Die meisten Fälle beginnen mit „seit dem Wochenende“
Herstellervorlage	SBC-Profil regelmäßig mit der aktuellen Teams-Vorlage vergleichen	Session-Timer und re-INVITE-Verhalten sind Sache des SBC
WLAN und Arbeitsplatz	Roaming testen, Energiesparoptionen standardisieren, Netzwerkstandorte pflegen	Zufällige Abbrüche werden selten, und die übrigen zuordenbar

 

Damit Firewall-Team, Netzwerkteam und Telefonieteam nicht aneinander vorbeiarbeiten, braucht es klare Zuständigkeiten. Das Gerüst dafür findest du in Microsoft Teams Telefonie-Governance. Dass sich Einstellungen still ändern, ohne dass es jemand dokumentiert, behandelt Konfigurationsdrift in der Teams-Telefonie erkennen. Und wenn dein Team SIP-Dialoge und Session-Timer selbst sicher lesen will, ist die Schulung Teams-Telefonie der passende Einstieg.

WEITERLESEN · Passend dazu › Teams-Telefonie Probleme: die zehn häufigsten Ursachen › SIP-Fehlercodes in Teams Direct Routing verstehen › Einseitiges Audio oder kein Ton bei Teams Direct Routing › SBC-Failover in Teams funktioniert nicht › Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen › Teams Media Bypass und Local Media Optimization › Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip › Teams-Telefonie über TCP statt UDP: warum das schlecht klingt › Teams-Telefonie über VPN: Split Tunneling richtig einrichten › Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl › Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen

 

FAQ

Warum bricht mein Teams-Anruf immer nach genau 30 Minuten ab?

Meist läuft ein Session-Timer ab, weil die Auffrischung zur Halbzeit fehlt, abgelehnt wird oder unterwegs verloren geht. Microsoft nennt 1800 Sekunden als Beispielwert im Header Session-Expires. Prüfe im SIP-Anrufablauf und im SBC-Trace, wer auffrischen soll und ob es passiert.

Warum steht beim abgebrochenen Anruf kein Fehlercode im Bericht?

Weil das Gespräch mit einem regulären BYE endet. Für die Signalisierung ist das ein normales Ende. Du findest diese Fälle über die Gesprächsdauer, nicht über Fehlercodes.

Gilt der Session-Timer auch bei Media Bypass?

Laut Microsoft bietet der SIP-Proxy den Session-Timer nur bei Anrufen ohne Media Bypass an. Bricht ein Bypass-Anruf nach fester Zeit ab, liegt die Ursache meist auf dem Bein zwischen SBC und Provider oder in der Firewall.

Kann ich den Session-Timer im Teams Admin Center einstellen?

Nein. Die Teams-Seite des Trunks hat keinen solchen Parameter. Session-Timer und Auffrischung konfigurierst du am SBC, für jedes Bein getrennt.

Was bedeutet ein Abbruch nach etwa 32 Sekunden?

Typischerweise kommt das ACK auf das 200 OK nicht an. Nach dem SIP-Standard wiederholt die angerufene Seite ihr 200 OK bis zu 32 Sekunden lang und beendet dann. Die Ursache liegt meist bei NAT, Contact-Header oder Firewall auf dem Rückweg.

Ist eine SIP-ALG bei Teams Direct Routing sinnvoll?

Auf dem Teams-Bein wirkungslos, weil die Signalisierung per TLS verschlüsselt ist. Auf dem Provider-Bein richtet sie eher Schaden an, wenn der SBC NAT selbst behandelt. Abschalten ist in diesem Fall die übliche Empfehlung.

Warum brechen nur Anrufe ab, wenn ich durchs Gebäude laufe?

Weil dein Laptop oder Handy zwischen Access Points wechselt. Ist das Roaming langsam oder bekommt das Gerät eine neue Adresse, reißt der Medienstrom ab. Das ist ein WLAN-Thema, kein Teams-Thema.

Wie lange kann ich Direct-Routing-Anrufe zurückverfolgen?

Für Benutzer in Deutschland nennt Microsoft 150 Tage für Direct-Routing-Daten im Bericht und über Graph. Der SIP-Anrufablauf ist nur für Anrufe der letzten 30 Tage verfügbar.

Bricht ein Gespräch ab, wenn der SBC ausfällt?

Ja, laufende Gespräche über diesen SBC enden. Ein Failover schützt neue Anrufe, nicht die bestehenden. Mehr dazu in SBC-Failover in Teams funktioniert nicht.

Fazit: erst die Uhr lesen, dann schrauben

Ein Teams-Anruf, der nach einigen Minuten abbricht, ist selten ein Mysterium. Er ist entweder pünktlich oder unpünktlich, und das sagt dir, wo du suchen musst. Pünktliche Abbrüche gehören Session-Timer, re-INVITE, Firewall-Zuständen und SIP-ALG. Unpünktliche gehören Netz, WLAN und VPN. Die Gesprächsdauer im Direct-Routing-Bericht trennt beide Familien in wenigen Minuten, der SIP-Anrufablauf und der Trace am SBC zeigen dir den Absender des BYE.

Der Rest ist Handwerk: einen Parameter ändern, eine Sicherung haben, einen Testanruf führen, der länger dauert als die kritische Zeit. Danach dürfen deine Kollegen wieder selbst entscheiden, wann das Gespräch mit dem Steuerberater vorbei ist. Auch wenn sie sich insgeheim manchmal den alten 30-Minuten-Timer zurückwünschen.