Voice over IP (VoIP) Grundlagen

Management Summary

Voice over IP (VoIP) spielt in der modernen Unternehmenskommunikation eine zentrale Rolle – zunehmend auch in Form von cloudbasierten Lösungen wie Microsoft Teams. Dieser Fachartikel bietet einen praxisorientierten Leitfaden für den Einsatz von Microsoft Teams als VoIP-Client in Unternehmen.

Im Fokus stehen technische Grundlagen von VoIP (Signalisierung vs. Medienübertragung), die Architektur und Implementierungsvarianten von Microsoft-Teams-Telefonie, die korrekte Rufnummernübermittlung (CLIP/CLIR inklusive „CLIP no screening“) sowie Netzwerk- und QoS-Anforderungen für hohe Sprachqualität. Zudem werden Sicherheits- und Compliance-Aspekte (z. B. Verschlüsselung und Notrufkonzepte) beleuchtet sowie Best Practices für Betrieb, Monitoring und Migration vorgestellt. IT-Entscheider, Netzwerkarchitekten und Betriebsverantwortliche erhalten konkrete Empfehlungen, Grenzwerte und Checklisten, um einen reibungslosen Übergang zur VoIP-Telefonie mit Teams zu planen, umzusetzen und langfristig stabil zu betreiben.

Grundlagen von VoIP im Unternehmensnetz

VoIP überträgt Sprache digital über IP-Netzwerke und trennt dabei Call Signaling (Verbindungssteuerung) vom eigentlichen Medienstrom (Audio-/Video-Daten). Für die Signalisierung hat sich das Session Initiation Protocol (SIP) etabliert: Es handelt sich um ein textbasiertes Protokoll, mit dem Telefonate aufgebaut, gehalten und beendet werden. Im SIP-Dialog werden Teilnehmeradressen ausgetauscht und mittels Session Description Protocol (SDP) die Medienparameter (z. B. Codecs, IP-Adressen und Ports für den Audiostrom) verhandelt. Der Sprachinhalt selbst fließt getrennt vom SIP-Signal über das Real-Time Transport Protocol (RTP). RTP überträgt die Audiodaten paketbasiert und in Echtzeit, typischerweise über UDP für minimale Latenz. In Unternehmensumgebungen ist durchgängig verschlüsselte Übertragung üblich: SIP-Signalisierung erfolgt über TLS, und der Audiostrom über Secure RTP (SRTP), um Abhören und Manipulation zu verhindern.

Jede VoIP-Übertragung nutzt einen Audiocodec zur Digitalisierung und Komprimierung der Sprache. Gängige Codecs unterscheiden sich in Bandbreitenbedarf und Sprachqualität. Traditionelle Telefonie verwendet häufig G.711 (64 kbit/s, unkomprimiert, „Narrowband“ mit 8 kHz Abtastrate), während für HD-Telefonie G.722 (ebenfalls 64 kbit/s, aber „Wideband“ mit 16 kHz) verbreitet ist. Kompressionscodecs wie G.729 reduzieren den Bitstrom auf etwa 8 kbit/s (auf Kosten von Qualität, da nur Schmalband 8 kHz). Moderne VoIP-Lösungen setzen verstärkt auf adaptive Wideband-Codecs: Skype for Business führte SILK ein (variabel, ca. 14 kbit/s bei Wideband 16 kHz), und Microsoft Teams nutzt inzwischen den KI-optimierten Codec Satin. Satin erreicht Super-Wideband-Audio (32 kHz) mit dynamischen Bitraten zwischen ca. 6 und 36 kbit/s und bietet selbst bei Paketverlusten robuste Sprachqualität. Die folgende Tabelle vergleicht einige Codecs hinsichtlich Paketierung und Bandbreitenbedarf:

Tabelle 1: Codecs & Bandbreiten (Paketisierungsintervall, Netto-/Bruttodatenrate pro Sprachstrom)

Erläuterung: Die „Brutto“-Bandbreite beinhaltet typischen Protokoll-Overhead (IP/UDP/RTP pro Paket). Längere Paketisierungsintervalle (z. B. 30 ms statt 20 ms) verringern den Overhead pro Sekunde, steigern jedoch die Latenz und das Verlustrisiko pro Paket.

Sprachqualität in VoIP wird von mehreren Faktoren bestimmt: Latenz, Jitter und Paketverluste. Damit Gespräche natürlich wirken, sollte die Ende-zu-Ende-Verzögerung (inklusive Codec- und Netzlaufzeit) idealerweise unter 150 ms liegen. Schwankende Paketlaufzeiten (Jitter) werden durch Jitter-Puffer in den Endgeräten ausgeglichen: ein adaptiver Buffer speichert eingehende RTP-Pakete kurzfristig zwischen, um Verzögerungsunterschiede zu glätten. Ist der Jitter jedoch zu hoch (über z. B. 30 ms Schwankung), oder gehen zu viele Pakete verloren, kommt es zu Aussetzern. Moderne Codecs wie Satin verfügen über integrierte Packet Loss Concealment – Verfahren, die fehlende Sprachfragmente auf Basis vorheriger Audioframes interpolieren, um moderate Verluste (einige Prozent) unhörbar zu machen. Dennoch sollten Paketverluste im Netz möglichst unter 1 % gehalten werden, da gehäufte Verluste (Burst Loss) zu deutlich verständigungsbeeinträchtigenden Lücken führen.

Ein weiteres Qualitätsproblem klassischer Telefonie, das VoIP adressiert, ist Echo. Echo entsteht, wenn das eigene Sprachsignal mit Verzögerung zurückkommt (z. B. durch akustische Rückkopplung am Gegenende oder Latenzen in analogen Leitungen). VoIP-Endgeräte und Softclients integrieren daher Echo-Kompensation bzw. -Unterdrückung, die solche Echosignale aus dem Audiopfad filtrieren. In Unternehmens-Headsets und Freisprecheinrichtungen ist diese akustische Echounterdrückung (AEC) ein Muss, um doppelt gehörte Sprache zu vermeiden.

Schließlich erfordert VoIP eine Lösung für die Durchdringung von Firewalls und NAT im Unternehmensnetz. Da IP-Telefonie End-to-End-Medienströme zwischen Clients (oder zwischen Client und Server/SBC) aufbaut, müssen Clients ihre erreichbare IP-Adresse/Ports kennen und Firewalls entsprechend passieren können. Hier kommt das ICE-Verfahren (Interactive Connectivity Establishment) zum Einsatz, das mit STUN und TURN arbeitet: Zunächst ermittelt ein Client via STUN-Server seine öffentliche IP/Port (NAT-Mapping). Kann keine direkte UDP-Verbindung zwischen den Endpunkten aufgebaut werden (etwa bei symmetrischem NAT oder strikten Firewalls), wird ein Medien-Relay über einen TURN-Server in der Cloud genutzt. Microsoft Teams verwendet ICE mit eigenen global verteilten Transport-Relay-Servern, um auch in komplexen Netzwerkumgebungen eine Sprachverbindung zu ermöglichen. Für die Praxis bedeutet dies, dass entsprechende UDP-Ports (z. B. 3478) und Protokolle in der Firewall geöffnet sein müssen – Details dazu folgen im Abschnitt Netzwerk & QoS. Insgesamt bilden die genannten Mechanismen die Grundlage, damit VoIP in Unternehmensnetzen zuverlässig und qualitativ hochwertig funktioniert.

Microsoft Teams als VoIP-Client

Microsoft Teams verbindet Kollaboration mit Telefonie und kann in der Unternehmensumgebung eine klassische Telefonanlage ersetzen. Als VoIP-Client bietet Teams Anwendern die gewohnten Telefoniefunktionen (Anrufe an Festnetz/Mobil, Durchwahlen, Halten, Weiterleiten, Voicemail), integriert in die Microsoft-365-Plattform. Im Folgenden werden die verschiedenen Telefonieoptionen mit Teams, die technische Architektur sowie Endgeräte und Voraussetzungen beleuchtet.

Telefonievarianten: Calling Plans, Operator Connect, Direct Routing

Microsoft Teams Phone unterstützt mehrere Anbindungsmodelle für das öffentliche Telefonnetz (PSTN):

• Calling Plans (Microsoft Anrufpläne): Hier fungiert Microsoft selbst als Telefonnetzbetreiber. Unternehmen erwerben pro Benutzer einen Anrufplan (national oder international), der ein Minutenkontingent umfasst. Rufnummern werden direkt von Microsoft bereitgestellt (portiert) und den Benutzern zugewiesen. Diese Option ist am einfachsten zu administrieren – besonders für kleinere Unternehmen ohne bestehende Telefonie-Infrastruktur. Allerdings sind Calling Plans nur in ausgewählten Ländern verfügbar (im DACH-Raum z. B. in Deutschland, Stand 2025) und bieten begrenzte Flexibilität bei speziellen Anforderungen oder Tarifen. Einsatzszenario: eher kleinere und mittelständische Unternehmen, die Telefonie „aus der Cloud“ beziehen möchten, ohne eigene Hardware.
• Operator Connect: Bei Operator Connect kooperiert Microsoft mit zertifizierten Telekommunikationsanbietern. Das Unternehmen schließt einen Vertrag mit einem dieser Operator-Connect-Partner (z. B. Deutsche Telekom, Orange etc.) ab, behält aber die Verwaltung in der Teams-Adminoberfläche. Rufnummern und Leitungen werden vom gewählten Carrier bereitgestellt, der Carrier verbindet seine Systeme über definierte Schnittstellen direkt mit Microsofts Cloud. Für den Administrator reduziert sich der Aufwand: keine lokale Telefonanlage oder SBC, einfaches Zuweisen von vom Betreiber gelieferten Nummern in Teams. Gleichzeitig hat man oft mehr Landesabdeckung und Tarifwahl als bei Calling Plans. Einsatzszenario: Organisationen mit mehreren Standorten in abgedeckten Ländern, die keine eigene Infrastruktur betreiben wollen, aber Wert auf einen etablierten lokalen Carrier legen. Die Einrichtung erfolgt weitgehend per Konfiguration – der Partner kümmert sich um die eigentliche Verbindung zu Teams.
• Direct Routing (Direktanbindung per SBC): Diese Variante bietet die maximale Flexibilität. Über Direct Routing bindet das Unternehmen einen eigenen Session Border Controller (SBC) an Microsoft Teams an, der als Gateway zum gewählten Telefonanbieter oder zur bestehenden TK-Anlage dient. Teams kommuniziert via SIP/TLS mit dem SBC, der wiederum klassische SIP-Trunks von Carriern terminieren oder ein On-Premises-PBX anschließen kann. Direct Routing erfordert anfänglich mehr Aufwand (Bereitstellung eines zertifizierten SBC, Konfiguration von SIP-Routen), bietet aber volle Kontrolle: Man kann praktisch jeden Telefonieanbieter weltweit einbinden, bestehende Rufnummern ohne Portierung weiterverwenden und sogar Hybrid-Szenarien mit einer vorhandenen Telefonanlage realisieren. Dieses Modell eignet sich für größere Unternehmen oder komplexe Anforderungen – etwa verteilte Standorte in verschiedenen Ländern, Integration von Drittanbieter-Systemen (Callcenter, DECT) oder wenn spezielle Routing-Logik gewünscht ist. Auch in regulierten Umgebungen, wo bestimmte Netzkopplungen vorgeschrieben sind, ist Direct Routing oft gesetzt. Kurz gesagt übernimmt hier das Unternehmen (oder sein Integrator) die Verantwortung für den PSTN-Zugang über einen eigenen SBC.

Jede dieser Varianten integriert sich in Teams Phone System und ermöglicht externes Telefonieren, unterscheidet sich jedoch in Verantwortlichkeiten, Kostenstruktur und verfügbaren Ländern. Unternehmen sollten die Option wählen, die zur eigenen Größe, zu ihrem geografischen Footprint und zu ihrem Wunsch nach Kontrolle passt. Oft kommen auch Kombinationen vor – z. B. Direct Routing für das Heimatland mit spezieller Anlagenkopplung und Operator Connect für Auslandsstandorte, um dort schnell lokale Rufnummern bereitzustellen.

Architektur, Medienpfade und Lizenzbausteine

Architektur: Unabhängig vom gewählten PSTN-Integrationsweg basiert Microsoft Teams Telefonie auf einer Cloud-Architektur. Im Kern befindet sich der Teams-Tenant in Microsoft 365, in dem Telefoniefunktionen über das Phone System (Cloud-Telefonanlagenfunktion) bereitgestellt werden. Alle Benutzer mit Telefonie benötigen eine entsprechende Lizenz (dazu unten mehr). Die Anrufsteuerung (Signalisierung) läuft immer über die Microsoft-Cloud: Wenn ein Teams-Nutzer eine externe Nummer anruft, signalisiert der Teams-Client den Verbindungsaufbau an den Teams Phone System-Dienst in Microsofts Rechenzentrum. Von dort wird – je nach Telefonievariante – die Verbindung ins PSTN hergestellt:

• Bei Calling Plans direkt über Microsofts Infrastruktur.
• Bei Operator Connect via direkter SIP-Anbindung zum Netz des Partner-Carriers.
• Bei Direct Routing über den registrierten Session Border Controller des Unternehmens.

Die Medienpfade (Audio-/Video-Daten) werden so optimiert, dass sie möglichst direkt fließen. Bei zwei Teams-Benutzern in einem Gespräch versucht Teams zunächst eine direkte Ende-zu-Ende-Verbindung (Peer-to-Peer) zwischen den Clients (mittels ICE/STUN, siehe VoIP-Grundlagen). Ist dies nicht möglich, werden Microsofts Transport Relays zwischengeschaltet – weltweit verteilte Medien-Relay-Server, die als Knoten fungieren. Im Falle eines PSTN-Anrufs läuft der Medienstrom in der Regel vom Teams-Client zum nächstgelegenen Media Processor in Microsofts Cloud und von dort zum SBC bzw. zum Carrier – es sei denn, es wird Media Bypass verwendet (im Direct-Routing-Szenario). Media Bypass bedeutet, dass der SBC dem Teams-Client seine eigene IP-Adresse als Medienendpunkt anbietet, sodass Audio direkt zwischen Client und SBC fließen kann, ohne Umweg über die Microsoft-Transport-Relays. Dies reduziert Latenz und potenzielle Paketverluste, insbesondere wenn Client und SBC geografisch nahe sind (z. B. im selben Firmennetz oder Land). Voraussetzung für Media Bypass ist allerdings, dass der Client den SBC direkt erreichen kann (Firewall/NAT entsprechend offen). Andernfalls wird der Medienverkehr über Microsofts Cloud weitergeleitet. Insgesamt ist die Architektur so ausgelegt, dass Signalisierung über die zuverlässigen Cloud-Dienste läuft (die auch Leistungsmerkmale wie Anrufrouting, Warteschlangen, Aufzeichnung steuern), während die zeitkritischen Audiodaten den effizientesten Pfad nehmen.

Sprachrouting und Dial-Plans: In der Teams-Administration lassen sich fein granulare Regeln definieren, wie Anrufe geroutet werden. Über Voice Routing Policies und Voice Routes wird festgelegt, welche externen Rufnummern über welche Verbindung geführt werden. Beispielsweise kann konfiguriert werden, dass Anrufe ins Ausland über einen zentralen SIP-Trunk laufen, während lokale Ortsgespräche am jeweiligen Standort über einen lokalen SBC vor Ort gehen. Daneben erlauben Wählpläne (Dial Plans) die Definition von Rufnummernformaten und Kurzwahlen: Benutzer können z. B. interne Durchwahlen oder Ortsvorwahlen ohne +49 eintippen, und der Dial Plan normalisiert dies automatisch in das international einheitliche E.164-Format (mit + Ländervorwahl), das Teams intern verwendet. Der gesamte Kosmos aus Routing- und Wählplan-Regeln bildet gewissermaßen die „Regelwerke“ der Cloud-PBX. Wichtig ist, diese sorgfältig zu planen, damit Notrufe und Sondernummern immer auf dem richtigen Weg rausgehen (Details zu Notrufen folgen später) und um sicherzustellen, dass bei Ausfall eines Pfades ein Backup vorhanden ist (z. B. Fallback auf zweiten SBC).

Lizenzbausteine: Um Teams als Telefonanlage zu nutzen, müssen die richtigen Microsoft-365-Lizenzen zugewiesen sein. Zentral ist die Teams Phone-Lizenz (früher „Phone System“ genannt). Sie aktiviert die PSTN-Telefonie-Funktionalität für einen Benutzer. In Microsoft 365 E5-Plänen ist Teams Phone bereits enthalten; bei E3 (oder E1, A3 etc.) muss es als Add-On pro Benutzer hinzugebucht werden. Neben Teams Phone benötigen einige Szenarien zusätzliche Lizenzen:

• Audiokonferenzen (Audio Conferencing): Diese Lizenz ermöglicht es, sich per Einwahl-Telefonnummer in Teams-Besprechungen einzuklinken. Für reine Telefonie-Benutzer ist das optional, aber oft wünscht man für Meetings eine Dial-in-Option. In vielen Enterprise-Abos ist Audio Conferencing inzwischen enthalten (z. B. E5) oder kann separat lizenziert werden.
• Calling-Plan-Minutenpakete: Falls Microsoft Calling Plans genutzt werden, kauft man für jeden Benutzer ein Minutenpaket (Inlandsflat, International etc.). Diese werden als eigenständige Lizenzen in der 365-Administration zugewiesen.
• Operator Connect/Direct Routing: Hier sind keine zusätzlichen Microsoft-Lizenzen erforderlich (außer Teams Phone), jedoch fallen vom Carrier ggf. Gebühren oder ein Vertrag an. Microsoft berechnet bei Direct Routing keine PSTN-Minuten, das läuft komplett über den externen Anbieter.
• Ressourcenkonten: Für Automatische Telefonzentralen (Auto Attendants) oder Anrufwarteschleifen (Call Queues) verwendet Teams sog. Ressourcenkonten, denen Rufnummern zugewiesen werden (z. B. eine zentrale Hotline). Solche Konten benötigen eine kostenlose „Virtual User“-Lizenz und ggf. eine Phone-System-Lizenz (bzw. eine spezielle Virtual-User-Phone-Lizenz), sofern sie PSTN-Anrufe annehmen oder tätigen sollen.

In der Praxis bedeutet das: Jeder Mitarbeiter, der extern telefonieren soll, braucht eine Teams-Phone-Berechtigung. Zusätzlich ist zu entscheiden, ob Microsoft oder ein Operator-Connect-Partner die Telefonie liefert (→ entsprechende Verträge/Lizenzen einplanen). Bei der Implementierung sollten diese Lizenzaspekte früh geklärt werden, um sicherzustellen, dass alle benötigten Funktionen (Voicemail, Konferenz-Einwahl etc.) für die Anwender bereitstehen, ohne Über- oder Unterlizenzierung.

Endgeräte und Anforderungen

Die beste VoIP-Plattform nützt wenig ohne geeignete Endgeräte, die eine gute Audioqualität und Nutzererfahrung sicherstellen. Microsoft Teams unterstützt ein breites Spektrum an Geräten für die Sprachkommunikation:

• Headsets: In einer Microsoft-Teams-Telefonieumgebung sind PC-Softphones und Laptops mit Headset eine häufige Arbeitsplatzlösung. Hochwertige USB- oder Bluetooth-Headsets, idealerweise Teams-zertifiziert, bieten Noise-Cancelling-Mikrofone, Echounterdrückung und oft integrierte Anrufsteuerungstasten (Mute, Lautstärke, Annehmen/Auflegen). Für Wissensarbeiter im Büro oder Home-Office ist ein gutes Stereo-Headset oft die erste Wahl. Wichtig: Unternehmen sollten auf Kompatibilität achten – Teams-zertifizierte Modelle gewährleisten z. B., dass das Drücken der Annehmen-Taste am Headset tatsächlich den Teams-Anruf annimmt, und dass Echo und Hintergrundgeräusche effektiv gefiltert werden. Ein einfacher Consumer-Ohrhörer ohne DSP kann hier deutlich schlechter abschneiden. Auch sollten IT-Abteilungen Mindestanforderungen definieren (z. B. beidseitige Hörer, breite Frequenzbandunterstützung für HD-Voice), um eine konsistente Audioqualität sicherzustellen.
• Tischtelefone (Teams Phones): Für Nutzer, die ein klassisches Telefon bevorzugen oder spezielle Funktionen am Gerät benötigen (z. B. Empfangsmitarbeiter, Konferenzräume), gibt es dedizierte Teams-Telefone. Dies sind IP-Telefone von Herstellern wie Yealink, Poly, Audiocodes u. a., die das Microsoft-Teams-Interface oder einen abgespeckten Teams-Client direkt auf dem Gerät ausführen. Sie sind in der Regel mit Touchscreen und manchmal Kameras (für Videotelefonie) ausgestattet. Diese Geräte melden sich mit dem Benutzerkonto bei Teams an und verhalten sich wie ein weiterer Teams-Client. Vorteil: Gewohnte Haptik eines Telefons, oft mit Hörer, Freisprecher in hoher Qualität und Hardware-Tasten (z. B. Halten, Transfer). Zudem bieten einige Modelle kleine Besetztlampenfelder oder Support für mehrere Leitungen, was bei Chef/Sekretariat- oder Hotline-Szenarien wichtig ist. Zu beachten ist, dass klassische SIP-Telefone (ohne Teams-App) nicht nativ an Teams funktionieren – Microsoft unterstützt aber einen SIP Gateway, über den bestimmte vorhandene SIP-Telefone als Nebenstelle in Teams eingebunden werden können. In der Regel ist jedoch die Empfehlung, auf echte Teams-zertifizierte Telefone zu setzen, um volle Funktionalität zu erhalten.
• Konferenz- und Raumgeräte: Für Besprechungsräume, Huddle Rooms oder Team-Meetings gibt es Konferenzlautsprecher und spezielle Teams-Rooms-Systeme. Konferenztelefone (z. B. Poly Trio, Yealink CP-Serie) sind runde Freisprecheinrichtungen mit 360°-Mikrofonen, die sich für Telefonkonferenzen in Gruppen eignen. Sie können als eigenständige Teams-Geräte fungieren und eine Rufnummer haben, oder in einen Teams-Besprechungsraum integriert werden. Microsoft Teams Rooms wiederum sind Komplettsysteme (Touch-Konsole, Kamera, Compute-Unit) für Meetingräume, die ebenfalls PSTN-Anbindung erlauben (z. B. um Teilnehmer per Telefon einzuwählen oder rauszurufen). Diese Geräte erhöhen die Qualität von Gruppenanrufen enorm durch Beamforming-Mikrofone, Lautsprecher mit DSP und Kameras, die Sprecher verfolgen.
• DECT-Mobilteile und Analogtelefone: Viele Unternehmen haben Bereiche (Lager, Produktion, Gesundheitswesen), in denen schnurlose Telefone oder spezielle Telefone (z. B. an Maschinen, Aufzügen) gebraucht werden. Teams unterstützt kein DECT-Protokoll direkt, aber man kann vorhandene DECT-Systeme über Gateways einbinden. Eine übliche Lösung: Die DECT-Basisstation wird an einen Session Border Controller oder einen Analog-Telefon-Adapter angeschlossen, der als SIP-Endpunkt in Teams (über Direct Routing) registriert ist. So kann ein DECT-Mobilteil quasi als Teams-Benutzer agieren, bekommt eine Durchwahl und kann intern/extern telefonieren. Alternativ gibt es professionelle Anbieter, die DECT-over-SIP mit Teams-Integration ermöglichen (z. B. via Cloud-SBC). Für analoge Geräte wie Fax oder Türsprechanlagen gilt Ähnliches – diese können über Mediengateways oder ATAs mit dem Teams-Telefonsystem verbunden werden. Planungshinweis: Prüfen, welche Legacy-Geräte weiter unterstützt werden müssen, und früh eine Integrationsstrategie definieren (oft läuft es auf einen hybriden Betrieb mit dem SBC hinaus, siehe Abschnitt Migration & Sonderfälle).

Anforderungen an Netzwerk und Umgebung: Alle genannten Endgeräte – ob Software-Client oder IP-Telefon – stellen in puncto Netzwerk dieselben Anforderungen: Sie brauchen eine stabile IP-Verbindung mit ausreichend Bandbreite und geringer Latenz (die genauen Werte siehe Abschnitt Netzwerk & QoS). Wenn möglich, sollten Geräte per Kabel (Gigabit-Ethernet mit Power over Ethernet für Tischtelefone) angebunden sein; bei WLAN-Nutzung ist auf hochwertigen Empfang (5 GHz) und ausreichende Access-Point-Kapazität zu achten. Die Geräte sollten VLAN/QoS-Einstellungen unterstützen (Teams-Tischtelefone markieren z. B. Sprachtraffic direkt mit DSCP 46). Auch Software-Clients auf PCs profitieren von QoS: Hier kann per Gruppenrichtlinie festgelegt werden, dass z. B. Teams-Audioverkehr mit DSCP 46 gesendet wird. Außerdem sind regelmäßige Firmware-Updates der Geräte wichtig (z. B. liefern Hersteller von Teams-Telefonen Updates für Stabilität und Sicherheit, oft zentral ausrollbar via Teams Admin Center).

Schließlich spielt die Arbeitsumgebung der Nutzer eine Rolle: In Großraumbüros oder Home-Offices mit Hintergrundgeräuschen sind Geräte mit guter Geräuschunterdrückung (Headsets, Konferenzlautsprecher mit Noise Reduction) essenziell. Führungskräften und Vieltelefonierern sollte man qualitativ hochwertige Endgeräte bereitstellen, da dies die Nutzungsakzeptanz erhöht. Insgesamt gilt: Ein durchdachtes Device-Konzept (inkl. Testen verschiedener Modelle, Schulung der Nutzer in der Handhabung) ist ein wichtiger Erfolgsfaktor beim Umstieg auf VoIP mit Teams.

Rufnummernübermittlung: CLIP, CLIR, CLIP no screening

In der Telefonie werden verschiedene Verfahren zur Übermittlung oder Unterdrückung der Rufnummer des Anrufers eingesetzt. Im Unternehmensumfeld ist die Calling Line Identification Presentation (CLIP) standardmäßig aktiviert – der Angerufene sieht also die Rufnummer des Anrufers. Calling Line Identification Restriction (CLIR) hingegen sorgt dafür, dass die eigene Nummer nicht übermittelt wird (anonymes Anrufen). Eine Sonderrolle spielt CLIP no screening, bei dem eine vom Anschlussinhaber frei wählbare (nicht vom Netz verifizierte) Absendernummer übertragen wird. Im Folgenden werden die technischen Hintergründe dieser Funktionen beleuchtet und wie sie in Microsoft-Teams-Umgebungen umgesetzt und gesteuert werden.

Technik und SIP-Header

CLIP – normale Rufnummernanzeige: Bei einem gewöhnlichen VoIP-Anruf enthält die SIP-Signalisierung die Rufnummer des Anrufers, damit diese dem Angerufenen angezeigt werden kann. Technisch befindet sich die Nummer typischerweise im From-Header der SIP INVITE-Nachricht als Teil der URI (z. B. From: „Max Meier“ <sip:+49221123456@…>). Da dieser Absender aber vom anrufenden System gesetzt werden kann, vertrauen PSTN-Netze oft eher auf einen P-Asserted-Identity (PAI)-Header. PAI wird in vertrauenswürdigen Netzen genutzt, um die authentische Anruferidentität zu übermitteln – im Beispiel würde der SBC einen Header P-Asserted-Identity: <sip:+49221123456@telco.net> einfügen. Der Telefonnetzbetreiber (Carrier) nimmt diese Nummer und liefert sie als Caller ID an den Empfänger. Remote-Party-ID (RPID) ist ein älterer, ähnlicher Header, der teils in Legacy-Systemen noch vorkommt, aber PAI hat ihn weitgehend abgelöst. Im Normalfall entspricht die übermittelte Nummer der dem Nutzer zugewiesenen Durchwahl bzw. der Amtsnummer des Anschlusses. Der Netzbetreiber „screened“ (überprüft) diese Nummer: stimmt sie nicht mit der vom Anschluss erwarteten Nummer überein (oder mit erlaubten zusätzlichen Nummern, siehe unten), wird sie entweder durch die korrekte Nummer ersetzt oder der Anruf abgewiesen. Somit stellt CLIP sicher, dass der Angerufene eine gültige, rückrufbare Nummer sieht – z. B. die Durchwahl des Mitarbeiters oder eine zentralisierte Absendernummer.

CLIR – unterdrückte Nummer: Will ein Anrufer seine Nummer nicht anzeigen lassen, greift CLIR. Im SIP-Protokoll gibt es dafür zwei Mechanismen:

• Das Setzen eines Privacy-Headers auf „id“ (Identity) in Kombination mit PAI. Konkret könnte der SBC Privacy: id hinzufügen und dennoch den P-Asserted-Identity-Header mit der echten Nummer mitschicken. Der Carrier erkennt daran, dass die Nummer zwar übermittelt wurde (für Netz- und Abrechnungszwecke), aber beim Zielanschluss nicht angezeigt werden soll. Das Telefon des Angerufenen bekommt dann die Information „anonym“ oder „Nummer unterdrückt“.
• Alternativ oder ergänzend kann im From-Header anstelle der Rufnummer ein generischer Wert stehen, z. B. From: „Anonymous“ <sip:anonymous@…>. Auch dies signalisiert dem entgegennehmenden System, dass die Identität verborgen ist.

In öffentlichen Netzen wird CLIR meist an der Quelle durch einen Merkmalcode ausgelöst (klassisch z. B. 31# vor der Rufnummer im Mobilfunk oder eine Einstellung am Endgerät). Bei Teams-Telefonie steuert in der Regel die Administrator-Policy, ob ein Anrufer anonym gesendet wird (siehe Umsetzung unten). Wichtig: Notrufe sind von CLIR ausgenommen* – bei einem Anruf zu 112/110 etc. wird auch bei aktivierter Unterdrückung im Hintergrund die Nummer an die Leitstelle übermittelt (gesetzliche Vorgaben stellen sicher, dass Hilfeleistungsorganisationen rückrufen können). Ansonsten bietet CLIR dem Anrufer Privatsphäre, z. B. um die eigene Durchwahl nicht preiszugeben, und ist in vielen Branchen üblich (etwa wenn Ärzte Patienten anrufen). Technisch muss der SIP-Trunk des Unternehmens CLIR unterstützen: Der Carrier darf die Nummer dann nicht zum Teilnehmer übertragen. In SIP/ISDN-Netzen gibt es dafür Kennzeichnungen im Setup, die der SBC entsprechend setzen muss.

CLIP no screening – frei wählbare Absendernummer: Bei CLIP no screening kann das Quellsystem eine beliebige Rufnummer als Absenderkennung übermitteln, ohne dass der Provider sie auf Richtigkeit prüft („no screening“ bedeutet keine Überprüfung durch das Netz). Dies wird z. B. benötigt, wenn ein Anruf im Auftrag eines Dritten erfolgen soll. Typischer Anwendungsfall: Ein Unternehmen mit verteilten Standorten möchte bei ausgehenden Anrufen stets die zentrale Hauptnummer anzeigen, statt der individuellen Durchwahl des Mitarbeiters. Oder bei Anrufweiterleitung: Ein externer Anrufer A ruft einen Teams-Benutzer B an, der einen Weiterleitungsregel zu C (extern) hat – idealerweise sieht C die Nummer von A (dem ursprünglichen Caller), nicht die von B. Solche Szenarien erfordern, dass der SBC eine abweichende Nummer in den PAI/From-Header setzen darf, die nicht der eigenen Anschlussnummer entspricht. Ohne CLIP no screening würde der Carrier diese „fremde“ Nummer verwerfen oder überschreiben.

Technisch übermittelt der SBC im P-Asserted-Identity-Header die gewünschte abweichende Nummer und kennzeichnet ggf. mittels Originating Line Information (OLI) oder spezifischer SIP-Tags, dass dies user-provided ist. Manche Carrier erwarten auch einen Diversion-Header oder History-Info, um die Weiterleitung korrekt abzubilden. Im klassischen ISDN-Umfeld wurde zwischen „user provided, not screened“ und „network provided“ Caller ID unterschieden – diese Logik setzt sich bei SIP-Trunks fort. Das heißt, CLIP no screening muss beim Provider explizit freigeschaltet sein. In der Regel begrenzt der Netzbetreiber dabei, welche Rufnummern übertragen werden dürfen: oft nur solche, die dem Kunden zugeteilt sind oder nachweislich in seinem Besitz (z. B. zusätzliche Standortrufnummern, Mobilnummern des Unternehmens). Die Verantwortung liegt beim Kunden, diese Option nicht zum Missbrauch zu verwenden.

Missbrauchsschutz und Verantwortung: Da die Absendernummer die primäre Identifikation eines Anrufs ist, gibt es strenge Regeln: Das Fälschen von Rufnummern, um sich als jemand anders auszugeben (Spoofing), ist in vielen Ländern strafbar, insbesondere wenn Täuschungsabsicht besteht. Carrier implementieren Schutzmechanismen – ohne gebuchte „no screening“-Option ersetzen sie unerwartete Absendernummern durch die Stammnummer des Anschlusses. Selbst mit no screening aktiv monitoren viele Anbieter die ausgehenden CLI; ungewöhnliche Muster (z. B. Anrufe mit wechselnden, fremden Nummern) können auffallen. Letztlich obliegt es dem Anschlussinhaber (Unternehmen), nur erlaubte Nummern zu signalisieren. Dazu zählt auch, keine behördlichen Notrufnummern, Premium-Dienste oder sonstige geschützte Nummern als Absender zu setzen. Zusammengefasst stellen folgende SIP-Header die Weichen für CLIP/CLIR:

• From: Enthält die angezeigte Identität (Name und URI). Kann anonymisiert sein.
• P-Asserted-Identity: Enthält die tatsächliche Rufnummer des Anrufers für netzinterne Authentifizierung. Bei CLIP no screening kann hier die alternative Nummer stehen.
• Remote-Party-ID: Veraltet, ähnlich PAI, teils noch bei älteren SIP-Implementierungen.
• Privacy: Indikator für Anonymität (bei Wert „id“ wird die Identität vom nachfolgenden Netz verborgen).

Die richtige Kombination dieser Header entscheidet darüber, was der Angerufene sieht. Der SIP-Trunk-Anbieter übersetzt die erhaltenen SIP-Informationen ins öffentliche Netzsignal (z. B. ISUP oder ISDN UUI) und sorgt so für die gewünschte Anzeige oder Unterdrückung beim Ziel.

Tabelle 2: CLIP/CLIR/CLIP no screening – Technik & Verantwortung

Umsetzung in Teams: Policies, Voice Routes, SBC-Manipulation

In Microsoft Teams Phone wird die Anruferkennung pro Benutzer standardmäßig auf dessen zugewiesene Rufnummer gesetzt. Jeder ausgehende PSTN-Anruf trägt also zunächst die persönliche Durchwahl des Anrufers als CLI. Anpassungen – etwa Anzeigen einer anderen Nummer oder Unterdrückung – lassen sich über Teams-Richtlinien oder Konfigurationen am SBC vornehmen:

• Anonymisieren (CLIR) in Teams: Administratoren können bestimmten Benutzern oder Anruftypen eine Calling ID Policy zuweisen, die die ausgehende Nummer unterdrückt. Beispielsweise gibt es eine Einstellung „Anonymous“ als abgehende Anruferkennung. Ist diese aktiv, initiiert Teams den Anruf ohne übermittelte Benutzer-ID – im SIP wird dann der Privacy-Header gesetzt und ggf. kein PAI mitgegeben. Der angeschlossene SBC/Provider erkennt dies und behandelt den Anruf als anonym. Aus Anwendersicht gibt es (derzeit) keine einfache Option, einen einzelnen Anruf spontan anonym zu machen (wie *31# im Mobilfunk); es ist eher eine feste Einstellung pro Account oder Rufnummer. In der Praxis könnte man alternativ einen zweiten, anonymen Service-Account nutzen, doch üblich ist die Policy-Lösung. Unternehmen sollten definieren, wer dauerhaft anonym senden darf/muss (z. B. im sensiblen Bereich wie Personalabteilung oder externe Hotline) und dies via Teams-Admincenter oder PowerShell setzen. Wichtig ist dann, Tests durchzuführen: Ein Testanruf auf ein Handy oder externes Telefon sollte “Unbekannt” anzeigen. Auch sollte dokumentiert sein, welche Anschlüsse auf CLIR geschaltet sind, um Verwechslungen vorzubeugen (siehe Governance).
• Alternative Absendernummer (CLIP no screening) via Teams-Policy: Microsoft Teams erlaubt es, einen Ersatz-Absenderrufnummer zu konfigurieren. Über die Caller-ID-Policies kann man für Nutzer festlegen, dass statt ihrer eigenen Nummer eine andere angezeigt wird. Diese muss allerdings eine dem Tenant zugeordnete Service-Nummer sein (z. B. die Nummer einer zentralen Auto Attendant oder Call Queue im Office-365-Tenant). Beispiel: Alle Support-Mitarbeiter sollen bei ausgehenden Anrufen die allgemeine Hotline-Nummer +49 40 12345-0 anzeigen. Man weist ihrer Benutzergruppe eine Policy zu, die als “Alternate Caller ID” die Hotline-Rufnummer setzt (diese Nummer muss zuvor als Resource Account im Teams-System existieren). Fortan übergibt Teams bei deren Anrufen die -0 im PAI/From an den SBC. Der Vorteil dieser Methode ist, dass sie vollständig innerhalb von Teams administriert wird und Compliance-konform nur eigene Nummern aus dem Tenant zur Auswahl stehen. Der SBC muss in diesem Fall nichts Besonderes tun außer die von Teams kommende Nummer durchzulassen.
• CLIP no screening durch SBC-Manipulation: Falls komplexere Anforderungen bestehen (z. B. Anzeige externer Nummern, die nicht im Tenant liegen, oder dynamisches Umschreiben bei Weiterleitungen), kann der SBC eingreifen. Session Border Controller verfügen über Manipulationsregeln für SIP-Header. So kann ein SBC z. B. alle ausgehenden Anrufe einer bestimmten Abteilung auf die Hauptnummer umschreiben – ungeachtet dessen, was Teams sendet. Ebenso kann er bei einem weitergeleiteten Anruf (der in Teams eventuell als Zweitanruf an den SBC kommt) den ursprünglichen Caller A in den From-Header setzen und B als weiterleitende Instanz in den Diversion-Header packen. Diese Logik erfordert genaue Abstimmung mit dem Carrier: der Anbieter muss das Format verstehen und akzeptieren (z. B. erwarten einige Carrier die Originalnummer im PAI und die umgeleitete in „Diversion:“). Der Vorteil einer SBC-basierten Lösung ist Flexibilität – man ist nicht auf die im Teams-Admincenter auswählbaren Nummern beschränkt. Der Nachteil: erhöhte Komplexität und die Gefahr von Diskrepanzen (Teams denkt z. B., Nutzer B schicke seine eigene Nummer – durch SBC-Regel wird aber Hauptnummer gesendet; daher sollte man so etwas möglichst mit Teams-Policy im Einklang halten).
• Weiterleitungs- und Delegationsszenarien: Bei Teams können Benutzer Anrufe an externe Ziele weiterleiten oder Sekretariate im Auftrag telefonieren. Hier ist es besonders wichtig, CLIP richtig zu handhaben. Beispiel Weiterleitung: Mitarbeiter B leitet auf sein Handy weiter. Ohne CLIP no screening würde sein Handy die Bürodurchwahl B sehen (oder gar nichts, falls anonym), was ungünstig ist, denn eigentlich ruft Person A an. Mit korrekt eingerichtetem CLIP no screening kann der SBC so gestalten, dass A’s Nummer am Handy angezeigt wird und evtl. ein Zusatz („über B“) intern verarbeitet wird. Diese Funktion sollte man gemeinsam mit dem Carrier testen, da es von dessen Plattform abhängt, wie Weiterleitungen gehandhabt werden (Stichwort: „Redirecting Number“ bzw. Diversion im ISDN). Bei Team-Delegation (Assistent telefoniert für Vorgesetzten) sollte idealerweise die Nummer des Vorgesetzten angezeigt werden – auch das ließe sich entweder über eine feste Policy (Assistent nutzt immer Chefs Nummer als Alternate Caller ID) oder über SBC-Regeln lösen.

Tests und Abnahme: Änderungen an der Rufnummernübermittlung gehören vor Produktionsstart gründlich getestet. In dieser Phase unbedingt gründliche CLIP/CLIR-Tests durchführen. Eine mögliche Checkliste:

• Ausgehend Festnetz: Ein Teams-Benutzer ruft eine externe Festnetznummer an → am Ziel muss die erwartete Caller ID erscheinen (Normalfall: persönliche Durchwahl oder zentrale Nummer laut Policy).
• Ausgehend Mobil: Testanruf an ein Mobiltelefon durchführen → auf dem Handy wird die richtige Nummer angezeigt bzw. „Anonym“ (bei CLIR-Fall).
• Anonyme Anrufe: Von einem CLIR-aktivierten Anschluss aus nach extern telefonieren → sicherstellen, dass wirklich keine Nummer übermittelt wird.
• Weiterleitungsszenario: Externer Anrufer A → Teams-Nutzer B (weitergeleitet zu externer C). Erwartung: C sieht entweder A’s Nummer (bei CLIP-no-screening-Berechtigung) oder B’s Stammnummer – je nach Konfiguration. Prüfen und mit Provider abstimmen.
• Sonder-IDs (Call Queues, Auto Attendants): Wenn Funktionskonten (Hotline, Zentrale) nach extern anrufen, kontrollieren, dass deren Service-Nummer als Absender erscheint.
• Dokumentation & Freigabe: Testergebnisse protokollieren. Bei Nutzung von CLIP no screening schriftliche Bestätigung des Providers einholen, dass die verwendeten abweichenden Nummern zulässig sind und korrekt durchgestellt werden.

Rechtliche Aspekte und Best Practices im DACH-Raum

In Deutschland, Österreich und der Schweiz gelten regulatorische Vorgaben für die Rufnummernübermittlung, die Unternehmen unbedingt einhalten müssen. Einige wichtige Punkte:

• Zulässige Absendernummern: Es darf grundsätzlich nur eine Rufnummer übermittelt werden, die dem Anrufer zugeordnet ist. In Deutschland schreibt das Telekommunikationsgesetz vor, dass der Inhaber des Anschlusses für die Richtigkeit der übermittelten Rufnummer verantwortlich ist. Nummern, die dem Kunden nicht gehören, dürfen nicht angezeigt werden (Ausnahme: Fälle wie Weiterleitungen, wo die ursprüngliche Nummer im Auftrag übermittelt wird – dafür gibt es aber definierte Verfahren). Ähnliches gilt in der Schweiz (Fernmeldegesetz) und in Österreich (TKG). Praktisch heißt das: Unternehmen sollten nur solche CLI senden, die entweder Teil ihres Rufnummernblocks sind oder für die sie vom Nummernbesitzer autorisiert wurden. Beispiel: Eine Hotline im Auftrag einer anderen Firma darf deren Nummer nur anzeigen, wenn vertraglich geregelt und beim Carrier hinterlegt.
• Missbrauch und Spoofing: Das vorsätzliche Verschleiern oder Fälschen von Rufnummern, um z. B. Vertrauen zu erschleichen (Enkeltrick-Maschen, falsche Amtsanrufer), ist strafbar. Unternehmen sind zwar meist Opfer solcher Spoofing-Anrufe, könnten aber theoretisch auch zur Haftung gezogen werden, wenn ihr Anschluss für Missbrauch genutzt wird. Daher ist es empfehlenswert, CLIP no screening nur restriktiv einzusetzen und ggf. Monitoring einzubauen. Best Practice: Protokollierung auf dem SBC aller ausgehenden Anrufe mit angezeigter und tatsächlicher Nummer, sodass im Zweifel nachvollziehbar ist, wer wann welche Caller ID genutzt hat.
• Dokumentation und Provider-Absprachen: Wenn ein Carrier für einen SIP-Trunk CLIP no screening aktiviert, wird er häufig eine Liste der erlaubten Absendernummern verlangen. Diese Liste sollte im Unternehmen gepflegt und aktuell gehalten werden (z. B. wenn neue Durchwahlen hinzukommen oder alte abgegeben werden). Ebenso sollten Ansprechpartner definiert sein, falls der Provider Auffälligkeiten meldet. Alles, was konfiguriert wurde (Policies, SBC-Regeln), ist schriftlich festzuhalten. Beim Onboarding eines neuen Carriers im DACH-Raum sind auch lokale Eigenheiten zu beachten – z. B. lässt die Bundesnetzagentur in DE Auslandsnummern als Absender nur unter bestimmten Bedingungen zu oder blockiert offensichtliche Fehlnummern. Eine enge Abstimmung mit dem Telekombetreiber im Vorfeld verhindert hier Probleme beim Go-Live.
• Anzeigen von geografischen Rufnummern: In Deutschland dürfen sog. geografische Festnetznummern als Absender nur benutzt werden, wenn der Anruf tatsächlich aus dem entsprechenden Ortsnetz stammt. Bei VoIP ist das verschwommen, aber die Regel zielt darauf ab, dass z. B. kein Callcenter aus dem Ausland mit einer deutschen Ortsvorwahl vorgibt, lokal zu sein. Unternehmen mit verteilten Standorten sollten also darauf achten, dass nur passende Ortsnummern verwendet werden (z. B. ein Münchner Büro soll keine Hamburger Vorwahl als CLI setzen, außer die Firma hat dort offiziell einen Sitz). In der Schweiz gibt es vergleichbare Bestimmungen durch die BAKOM.
• Verantwortlichkeit im Unternehmen: Es empfiehlt sich, interne Policies zur Rufnummernübermittlung zu definieren. Beispielsweise: „Mitarbeiter senden primär ihre persönliche Durchwahl, außer in folgenden Fällen …“, „Vertrieb darf Nummer unterdrücken, wenn vorher vereinbart“ oder „Alle ausgehenden Anrufe zeigen die Zentrale, um einheitliches Auftreten zu gewährleisten“. Solche Entscheidungen müssen mit Datenschutzbeauftragten und der Geschäftsleitung abgestimmt sein. Gerade Datenschutz ist ein Thema: Die Anzeige persönlicher Durchwahlen kann als personenbezogenes Datum gelten – manche Unternehmen bevorzugen daher, nach außen nur Funktionsnummern zu präsentieren. Andererseits erwarten Geschäftspartner oft direkte Erreichbarkeit. Hier gilt es, einen Ausgleich zu finden und transparent zu kommunizieren.
• Notruf und Rückverfolgbarkeit: Rechtsrahmen fordern, dass im Notfall ein Rückruf möglich ist. In DE muss jeder Notruf eine Rückrufnummer beim PSAP hinterlassen, unter der der Anrufer erreichbar ist. Bei Anlagenanschlüssen kann das eine Leitstellen-Nummer der Firma sein (siehe Abschnitt Notruf). Wichtig ist: Niemals darf ein Notruf komplett anonym gesendet werden – dies verhindern aber ohnehin die Netze. Dennoch sollte man testen, welche Nummer beim Notruf übermittelt wird (bei Direct Routing meist die Stammnummer des Trunks oder eine definierte ELIN – dazu später mehr). Diese Nummer muss ständig besetzt sein.

Fazit Best Practices: Unternehmen im DACH-Raum sollten sehr bewusst mit CLIP/CLIR umgehen. Must-haves sind: nur erlaubte Nummern signalisieren, sensible Anschlüsse vor Missbrauch schützen, klare interne Regeln und Benutzer-Schulungen (z. B. dass Mitarbeiter nicht versuchen, via Dritt-Apps ihre Nummer zu fälschen). Nice-to-have sind Tools zur Überwachung und automatische Alerts, wenn ungewöhnliche Caller IDs rausgehen. Durch eine vorausschauende Governance der Rufnummernübermittlung lässt sich Compliance gewährleisten und zugleich den Bedürfnissen nach Flexibilität (z. B. zentrale Nummer anzeigen) Rechnung tragen.

Netzwerk & QoS

Eine zuverlässige Sprachkommunikation mit VoIP hängt stark von der Netzqualität ab. Sprachpakete reagieren empfindlich auf Verzögerungen, Schwankungen und Verluste. In diesem Abschnitt werden Zielwerte für Netzparameter und Quality-of-Service (QoS) Maßnahmen beschrieben sowie Anforderungen an Firewalls, Proxys und WLAN-Umgebungen erläutert.

Zielwerte für Bandbreite, Latenz und Verluste; QoS-Klassen (DSCP); SD-WAN

Bandbreite pro Sprachstrom: Ein einzelnes VoIP-Gespräch benötigt typischerweise rund 80–100 kbit/s pro Richtung bei Verwendung eines Breitband-Codecs (wie G.711 oder G.722 mit ca. 64 kbit/s Nutzdaten + Protokoll-Overhead). Kompressionscodecs verringern dies (G.729 z. B. ~24 kbit/s gesamt), während moderne adaptive Codecs (SILK, Satin) je nach Netz minimal 10–20 kbit/s nutzen können, bei guter Verbindung aber auch höher gehen, um Qualität zu steigern. Planungsrichtwert im LAN/WAN ist trotzdem etwa 100 kbit/s pro gleichzeitigem Audiogespräch. Für Unternehmen heißt das: bei 100 parallelen Gesprächen sollten ca. 10 Mbit/s reserviert sein, zzgl. Reserve. Videoanrufe benötigen deutlich mehr (ein 720p Video-Stream liegt bei 1–1,5 Mbit/s, 1080p bis ~4 Mbit/s), werden hier aber nachrangig behandelt, da Fokus auf Sprachqualität liegt – dennoch sollte man Video in QoS-Konzepten mit einbeziehen, um Konferenzqualität zu sichern.

Latenz, Jitter, Packet Loss: Für Sprache gelten strenge Latenzanforderungen. Die ITU-T G.114-Empfehlung sieht bis ~150 ms One-Way-Verzögerung als unauffällig an; bis 400 ms ist grenzwertig, darüber wird Kommunikation schwierig. Microsoft empfiehlt für Teams-Verbindungen eine Round-Trip-Time < 300 ms (entspricht < 150 ms pro Strecke) und idealerweise unter 100 ms RTT innerhalb des eigenen Netzes. Jitter (Laufzeitschwankung) sollte im Mittel < 30 ms liegen, damit die Jitter-Buffer der Endgeräte Schwankungen ausgleichen können, ohne große zusätzliche Verzögerung. Alles über 30 ms Jitter wird als „Poor“ Qualität klassifiziert. Paketverlust sollte möglichst nahe 0 % liegen. Einzelne verlorene Pakete (< 1 %) können durch Packet Loss Concealment kaschiert werden, aber bereits 5 % Verlust führen zu hörbaren Aussetzern; jenseits 10 % wird Sprache stark beeinträchtigt. Netzplaner sollten diese Grenzwerte als Service Level intern ansetzen. Im SD-WAN oder MPLS-Vertrag sollten entsprechende Voice-Class SLAs vereinbart werden (z. B. < 0,1 % Loss, < 20 ms Jitter auf der Sprachklasse).

QoS und DSCP-Markierungen: Um Sprachtraffic gegenüber anderem Datenverkehr zu priorisieren, wird Quality of Service eingesetzt. Endgeräte oder Netzwerkknoten markieren VoIP-Pakete mit DSCP (Differentiated Services Code Point) Werten. Die gängige Klassifizierung für Echtzeitmedien lautet:

• Audio: DSCP 46 (Klassierung EF, Expedited Forwarding). EF-Pakete erhalten höchste Priorität im Netz (Low-Latency-Queue).
• Video: DSCP 34 (Klassierung AF41, Assured Forwarding Klasse 4, Stufe 1). Wichtig, aber nach Audio gereiht.
• Bildschirmfreigabe/Anwendungssharing: DSCP 18 (AF21). Noch weniger kritisch als Video, daher mittlere Priorität.
• Signalisierung: Wird teils mit DSCP 24 (CS3) oder 26 (AF31) markiert, um sie über Best Effort (0) zu heben. Bei Teams-Clients geschieht dies jedoch oft nicht, da Signalisierung über HTTPS läuft.

Microsoft Teams Desktop-Clients auf Windows können über eine lokale Richtlinie so konfiguriert werden, dass sie diese DSCP-Werte setzen (basiert auf Portbereichen: Standard 50.000–50.019 UDP für Audio, 50.020–50.039 für Video etc.). Mobile und Mac-Clients nutzen fixierte Werte (Audio EF, Video und App Sharing AF41 zusammen). Wo das Endgerät keine QoS-Markierung vornimmt, kann das Netzwerk per Traffic Classifier nachhelfen – etwa ein Switch, der RTP-Pakete auf UDP-Port 50.000–50.019 erkennt und DSCP 46 setzt. In jedem Fall sollte die Sprachklasse am höchsten priorisiert durchs Netz gehen: auf Switches und Routern eine dedizierte Priority Queue mit ausreichend Bandbreite. Warteschlangen-Management (Queuing) z. B. nach dem LLQ-Prinzip (Low-Latency-Queue für EF, getrennt von Daten) verhindert, dass große Datenpakete in Ausgabepuffern die kleinen VoIP-Pakete verzögern.

Trust Boundary: Ein Netzdesign-Aspekt ist, wo man DSCP-Markierungen vertraut. Da ein Endbenutzer theoretisch seinen Traffic als EF tarnen könnte, vertraut man im Campus oft nur den Telefonen oder Softclients, die per Gruppenrichtlinie konfiguriert wurden. Alternativ setzt der Access-Switch am Port alle eingehenden Pakete auf 0 und markiert nur bekannten VoIP-Traffic neu. Welcher Ansatz gewählt wird, hängt von der Kontrolle über die Endpoints ab. In einer rein Microsoft-Teams-Welt mit gemanagten Clients kann man den Clients das Markieren überlassen (sie sind ja Firmen-Software). Bei BYOD oder offenen LANs sollte das Netzwerk die Markierung erzwingen.

SD-WAN und WAN-Priorisierung: Für standortübergreifende Verbindungen und Internet empfiehlt es sich, Voice-Traffic auch dort explizit zu priorisieren. Moderne SD-WAN-Appliances erkennen Teams-Verkehr (oft sogar per integrierter App-Signaturen) und können diesen auf der optimalen WAN-Strecke senden. Must-have ist die Priorisierung auf jedem Engpass-Link: beispielsweise sollte auf einer 100-Mbit/s-MPLS-Leitung die Voice-Queue immer vor anderen Klassen bedient werden. Bandwidth Management: Reservieren Sie genügend Bandbreite für die EF-Klasse (z. B. 20 % der Linkbandbreite oder gemäß gleichzeitiger Calls + 20 % Puffer). Bei SD-WAN mit Internet-VPNs muss man DSCP auch über Tunnel erhalten – viele Lösungen mappen DSCP standardmäßig durch, aber das sollte geprüft werden. Zudem empfiehlt sich eine Dynamic Path Selection: Falls eine VPN-Strecke plötzlich hohe Latenz hat, kann SD-WAN automatisch auf eine Backup-Leitung umschwenken, speziell für Echtzeitverkehr. Auch Microsoft bietet mit Azure ExpressRoute eine QoS-fähige dedizierte Anbindung an O365/Teams an – diese ist jedoch nur bei sehr strengen Anforderungen nötig (die meisten setzen auf verschlüsselten Internetverkehr). Wichtig ist vor allem, lokales Internet-Breakout zu nutzen, damit Teams-Datenverkehr nicht erst durch entfernte Hubs oder zentrale Firewalls geroutet wird (siehe unten VPN/Proxy).

Zur Orientierung fasst die folgende Tabelle die empfohlenen QoS-Mappings zusammen:

Tabelle 3: QoS-Mapping für Microsoft Teams Medienverkehr

In obiger Tabelle erkennt man: Audio-Pakete sollen praktisch immer sofort durchgereicht werden („Expedited“), während Video zwar priorisiert wird, aber nicht auf Kosten der Sprachpakete. Screen-Sharing ordnet man oft der normalen Datenklasse zu oder knapp darüber, da eine kurzzeitige Verzögerung hier nicht gesprächskritisch ist. Eine korrekte QoS-Umsetzung ist ein Muss in größeren Netzen: Sie dient als Versicherung, falls trotz ausreichender Bandbreite Traffic-Spitzen auftreten – dann werden zumindest die wichtigen Sprachpakete nicht verworfen.

Firewall- und Proxy-Einstellungen; WLAN-Optimierung

Ports und Protokolle: Microsoft Teams nutzt eine Reihe von Ports und Zieldomains, die in der Firewall freigegeben sein müssen. Eine Kernanforderung ist, dass UDP für die Medien fließen kann – ohne funktionierendes UDP fällt Teams auf TCP zurück, was deutlich schlechtere Qualität bedeutet. Folgende Tabelle gibt einen Überblick relevanter Ports/Dienste:

Tabelle 4: Wichtige Ports & Dienste für Teams-Telefonie

Anmerkung: Die IP-Adressbereiche hinter *.teams.microsoft.com und dem PSTN-Hub ändern sich; Microsoft publiziert aktuelle Listen (für EU meistens 52.112.0.0/14, 52.120.0.0/14 u. a.). Am sichersten ist es, den ausgehenden Traffic zu Microsoft 365/Teams nicht unnötig einzuschränken. Eingehend muss nur bei Direct Routing etwas geöffnet werden: Der SBC benötigt eine öffentliche IP/FQDN, auf dem er TLS 5061 von Microsoft akzeptiert.

Firewall-Optimierungen: Neben den reinen Öffnungen sollten bestimmte Funktionen auf Firewalls deaktiviert werden. Insbesondere SIP-ALG (Application Layer Gateway) auf NAT-Routern ist bekannt dafür, VoIP zu stören. Da Teams-Traffic meist verschlüsselt ist, greift ALG hier zwar selten, aber es kann z. B. bei unverschlüsselten SIP-Verbindungen (anderen Geräten im Netz) zu Fehlern führen, wenn die Firewall versucht, SIP-Pakete umzuschreiben. Empfehlung: SIP-ALG generell abschalten, da moderne Systeme eigene NAT-Traversal-Methoden (ICE) nutzen. Stateful Inspection von UDP sollte auf ausreichend lange Timeouts eingestellt sein (mind. 30–60 Sekunden), damit die kurzen RTP-Pakete nicht als Sessionende fehlgedeutet werden. Außerdem ist auf TLS-Inspektion zu achten: Falls eine Firewall oder ein Proxy versucht, HTTPS-Verbindungen aufzubrechen (Deep Packet Inspection), kann das Teams-Verkehr beeinträchtigen. Viele Teams-Dienste nutzen Zertifikats-Pinning; eine dazwischengeschaltete SSL-Inspection würde Verbindungen blockieren. Daher: Teams- und generell Office-365-Domains von jeglicher SSL-Intercept ausnehmen. Gleiches gilt für Proxy-Server: Medienstreams lassen sich nicht über HTTP-Proxys tunneln. Microsoft empfiehlt dringend, Teams-Datenverkehr direkt ins Internet auszuleiten (Direct Internet Breakout), statt ihn durch zentrale Proxys oder VPN-Tunnel zu zwängen. Wo ein Proxy für Webtraffic Pflicht ist, sollte man Ausnahmen konfigurieren („Proxy Bypass“) für alle Teams- und STUN/TURN-Ziele. Ideal ist, wenn Clients ohne Umwege die UDP-Ports erreichen – z. B. indem man in der PAC-Datei bestimmte FQDNs direkt routen lässt.

VPN und Remote Work: In Zeiten von Home-Office relevant: Nutzer, die über VPN ins Firmennetz gehen, sollten möglichst nicht den Echtzeitverkehr durch den VPN-Tunnel schicken. Viele VPNs unterstützen kein UDP oder erhöhen Latenz durch Verschlüsselung/Umwege. Die Empfehlung ist, Split Tunneling zu aktivieren: Teams erkennt man gut über die Ziel-URLs/IPs, diese sollten direkt ins Internet gehen. So vermeidet man „Hairpinning“ (User in München schickt Sprachpakete erst nach Berlin zum VPN-Concentrator, der sie dann zurück ins Internet schickt – unnötige Hunderte km Umweg). Unternehmen, die aus Sicherheitsgründen alles tunneln, müssen sich bewusst sein, dass das die Sprachqualität beeinträchtigen kann – hier eventuell über spezielle Lösungen nachdenken oder QoS im VPN priorisieren, falls technisch möglich.

WLAN-Aspekte: Immer mehr Gespräche laufen über Wi-Fi – sei es via Laptop, Smartphone oder dedizierte WLAN-Telefone. WLAN ist jedoch ein Shared Medium mit besonderen Tücken für VoIP:

• Frequenzband: Nutzung des 5-GHz-Bands ist quasi Pflicht für Sprachgeräte. 2,4 GHz ist überlaufen (Bluetooth, Mikrowellen, Nachbar-WLANs) und bietet nur 3 nicht-überlappende Kanäle. 5 GHz hat mehr Kanäle und weniger Störungen. Noch besser, falls verfügbar, ist 6 GHz (Wi-Fi 6E), das exklusiv neuen Geräten vorbehalten ist und sehr saubere Übertragungen ermöglicht. Praktisch sollten Firmen-WLANs Voice-Geräte bevorzugt ins 5 GHz steuern (Stichwort Band-Steering).
• WLAN-QoS (WMM): Wi-Fi nutzt den Wireless Multimedia (WMM)-Standard, um Traffic in vier Zugangskategorien (Voice, Video, Best Effort, Background) zu priorisieren. Stellen Sie sicher, dass WMM auf allen Access Points aktiviert ist. APs mappen DSCP 46 in der Regel auf die höchste WLAN-Klasse (Voice AC). Dadurch bekommen Sprachpakete kürzere Backoff-Timer und haben eher Sendevortritt. Ohne WMM werden Voice und Bulk-Daten gleich behandelt, was zu hohem Jitter führen kann.
• Roaming-Fähigkeit: Telefongespräche dürfen beim Teilnehmer nicht abbrechen, nur weil dieser sich bewegt. Ein nahtloses Roaming zwischen Access Points ist daher essenziell. Technologien wie 802.11r (Fast Roaming) reduzieren die Umschaltzeit beim AP-Wechsel auf < 50 ms, sodass keine Audiodropouts entstehen. Netzwerkadmins sollten diese Funktionen testen – z. B. mit einem laufenden Teams-Call durchs Gebäude gehen und prüfen, ob es beim AP-Wechsel hörbare Aussetzer gibt. Wichtig ist auch eine genügend dichte AP-Abdeckung: In Büros sollte der WLAN-Empfang überall stabil sein; „Randzonen“ mit schwachem Signal führen zu Paketverlusten. Planungsvorgabe: eher mehr kleinere Zellen mit Überschneidung, als wenige APs auf voller Leistung.
• Kapazität und Störquellen: Ein AP hat nur begrenzte parallele Sendezeit. Viele gleichzeitige Calls auf einem AP können die Kapazität erschöpfen, was Latenz und Loss hochtreibt. Daher: Große Besprechungsräume vielleicht mit eigenem AP ausstatten; ggf. Nutzer auf 5/6 GHz verteilen. Eliminieren Sie Störquellen – DECT-Telefone auf 1,9 GHz stören nicht, aber 2,4-GHz-Funkkameras oder alte WLAN-Geräte mit 802.11b sollten vom Gelände verbannt werden.
• Monitoring: Es empfiehlt sich, die WLAN-Performance im Auge zu behalten – z. B. via Call Quality Dashboard gefiltert nach „Wireless“ als Konnektivität. Wenn dort gehäuft schlechte MOS-Werte auftauchen, muss man evtl. Kanäle neu planen oder APs aufrüsten.

In Summe kann WLAN sehr gut für VoIP funktionieren, wenn es professionell optimiert wurde. Gerade mobil arbeitende Mitarbeiter erwarten heute, dass sie auch im Konferenzraum per Laptop/Teams ohne Aussetzer telefonieren können. Daher sind die oben genannten Punkte – richtiges Band, QoS aktivieren, Roaming und Coverage – Must-haves in einer UC-ready WLAN-Architektur.

Zum Abschluss dieses Abschnitts eine Checkliste mit Netzwerk-Maßnahmen, die vor dem Go-Live von Teams-Telefonie erledigt sein sollten:

• Bandbreitenplanung überprüft: Sind genug Reserven für die erwartete Anzahl gleichzeitiger Anrufe vorhanden (inkl. Puffer für Spitzen)?
• Latenz/Jitter-Messungen durchgeführt: Per Monitoring oder Test-Tool (z. B. Microsoft 365 Network Assessment) Latenz, Jitter, Packet Loss zwischen Standorten und Microsoft-Cloud gemessen und im grünen Bereich.
• QoS Ende-zu-Ende eingerichtet: DSCP-Markierung an Clients (Policy) oder Switches aktiviert; Queue-Konfiguration auf allen Routern/SD-WAN-Geräten durchgeführt (Voice als höchste Klasse mit ausreichend Bandbreite).
• WAN-Priorisierung: Falls MPLS: stimmt die Class-of-Service-Konfiguration mit den DSCP-Werten überein (EF wird vom Provider nicht etwa runtergestuft)? Falls Internet/SD-WAN: sind Regeln definiert, die Sprachverkehr bevorzugen und ggf. bei Paketverlust alternative Pfade nutzen?
• Firewall-Freigaben gesetzt: Alle erforderlichen Ports/FQDNs laut Microsoft-Dokumentation offen. Test mit Microsoft-Connectivity-Tools positiv (z. B. UDP 3478 erreichbar).
• ALG/Inspection angepasst: SIP-ALG auf Firewalls deaktiviert; SSL-Inspection/Proxy-Ausnahmen für Teams konfiguriert. NAT-Timeouts für UDP erhöht.
• NAT/PAT-Kapazität geprüft: Genug öffentliche Ports/IPs vorhanden, um auch bei vielen gleichzeitigen Calls keine Portkollisionen zu riskieren (Faustregel: pro 500 gleichzeitige Verbindungen eine eigene öffentliche IP einplanen).
• VPN/Proxy-Bypass eingerichtet: Teams/Medien-Datenverkehr wird nicht unnötig durch VPN-Tunnel oder HTTP-Proxy geleitet – Split-Tunnel aktiviert, Proxy-PAC entsprechend konfiguriert.
• WLAN optimiert: 5 GHz überall verfügbar, WMM aktiviert, Roaming getestet. QoS-Mappings im WLAN-Controller geprüft (DSCP → WMM).
• Lasttest/Probe-Call durchgeführt: Beispiel: 20 Testanrufe parallel durchgeführt (skriptbasiert oder mit Mitarbeitern), um zu verifizieren, dass keine Engpässe oder Qualitätsprobleme auftreten.

Diese Netz-Checkliste stellt sicher, dass die Infrastruktur auf VoIP-Telefonie mit Microsoft Teams vorbereitet ist. Ein großer Teil von Sprachqualitätsproblemen lässt sich proaktiv vermeiden, wenn obige Punkte beachtet wurden – und damit steigt die Zufriedenheit der Endbenutzer beim späteren Betrieb deutlich.

SBC & Trunking (Direct Routing)

Beim Direct Routing verbindet ein Session Border Controller (SBC) die Microsoft-Teams-Cloud mit dem Telefonnetz oder anderen Kommunikationssystemen. Der SBC fungiert als Übersetzer, Firewall und Router für Sprachdaten – ein zentrales Element, wenn Unternehmen ihre eigenen SIP-Trunks oder PBX-Anlagen anbinden. Im Folgenden werden wichtige Aspekte der SBC-Integration beleuchtet: Zertifikate und Sicherheit, Hochverfügbarkeit, Interoperabilität mit Providern sowie spezielle Anforderungen wie Notrufrouting.

Zertifikate und mTLS-Sicherheit: Für die Kopplung mit Microsoft Teams muss der SBC über ein öffentlich vertrauenswürdiges TLS-Zertifikat verfügen. Dieses Zertifikat identifiziert den SBC via FQDN (Fully Qualified Domain Name). Microsoft verlangt, dass der CN/SAN des Zertifikats genau mit dem im Tenant konfigurierten SBC-FQDN übereinstimmt (z. B. sbc01.firma.de). Das Zertifikat muss von einer anerkannten öffentlichen Zertifizierungsstelle stammen (alle CAs im Microsoft Trusted Root Programm werden akzeptiert, z. B. DigiCert). Selbstsignierte oder interne PKI-Zertifikate funktionieren nicht, da Microsofts Server diese nicht als vertrauenswürdig einstufen. Die SIP-Verbindung zwischen Teams und SBC läuft über mutual TLS (mTLS) – das heißt, nicht nur der Client überprüft das Zertifikat des Servers, sondern beide Seiten authentifizieren sich gegenseitig. Damit das klappt, muss der SBC seinerseits Microsofts Zertifikate als vertrauenswürdig anerkennen. Konkret: Auf dem SBC sollte die Root-CA von Microsofts Zertifikaten importiert sein (derzeit DigiCert Global Root G2). Zusätzlich prüft der SBC beim eingehenden TLS-Handschlag, ob im Zertifikat des Gegenübers der Eintrag sip.pstnhub.microsoft.com im SAN steht – so wird sichergestellt, dass er wirklich mit der Microsoft-Plattform spricht. Dank mTLS ist die Verbindung hochgradig abgesichert: Unbefugte können sich nicht als SBC oder Teams-Server ausgeben.

FQDN-Design und DNS: Unternehmen sollten früh festlegen, unter welchen Namen ihre SBCs erreichbar sein sollen. Jeder SBC benötigt einen eindeutigen FQDN, der im Office-365-Tenant eingetragen wird. Üblich ist, Subdomain-Namen der eigenen Domain zu verwenden (z. B. sbc.eu.contoso.com für Europa, sbc.us.contoso.com für USA, oder nach Standort sbc-berlin.firma.de). Die Namensgebung sollte konsistent und aussagekräftig sein, da man im Admin Center und in Logs später mit diesen FQDNs arbeitet. Die entsprechende Domain muss in Office 365 verifiziert sein (meist nutzt man die bestehende Firmen-Online-Domain). DNS muss so konfiguriert werden, dass der FQDN auf die öffentliche IP des SBC zeigt. Wichtig: Der SBC initiiert zwar ausgehende Verbindungen, aber Microsoft kann auch eingehend (vom Cloud-Server) den TLS-Connect aufbauen – das Modell ist peer-to-peer. Daher muss die Firewall eingehende TLS auf Port 5061 an den SBC erlauben, für alle IPs in Microsofts SIP-Netz (genannte IP-Ranges). Microsoft nutzt DNS-Lookups (sip.pstnhub.microsoft.com etc.), um intern auf bestimmte regional nächstgelegene Server zu routen – der SBC selbst muss diese FQDNs auflösen können und über den offenen Port 5061 erreichen.

Hochverfügbarkeit und Failover: Telefonie ist kritisch, daher sollte ein SPOF vermieden werden. Unternehmen realisieren meist zwei SBC-Instanzen für Redundanz. Möglichkeiten:

• Aktiv/Passiv-Cluster: Zwei SBCs (physisch oder virtuell) arbeiten im Verbund; einer ist aktiv, der andere übernimmt bei Ausfall (Heartbeat-Verbindung dazwischen). Sie teilen eine virtuelle IP oder es wird via DNS-Failover umgeschwenkt.
• Aktiv/Aktiv mit Lastverteilung: Beide SBCs sind produktiv und vom Tenant aus adressierbar. Microsoft erlaubt, in einer Voice Route mehrere SBC-FQDNs anzugeben. Anrufe werden primär an den ersten gesendet, bei Nichterreichbarkeit automatisch den zweiten. Eingehend können Carrier oft beide SBC parallel ansteuern (je nach Konfiguration).
• Geo-redundant: SBCs an unterschiedlichen Standorten (z. B. einer pro Rechenzentrum). So ist selbst bei Ausfall eines gesamten Standorts noch ein Gateway verfügbar. Dann muss das Routing so gestaltet sein, dass Nutzer im Notfall auch über den anderen SBC rausgehen können (z. B. sekundäre Voice Route). Teams selbst steuert das Failover zwischen konfigurierten SBCs innerhalb von Sekunden, jedoch sollte man die zustandslose Natur beachten: Laufende Anrufe gehen bei SBC-Neustart verloren; es gibt kein transparentes Mid-Call-Failover. Dennoch kann der nächste Anwahlversuch sofort über den zweiten SBC erfolgen. Daher: Redundante SBCs ausreichend dimensioniert betreiben und regelmäßige Failover-Tests (z. B. einen SBC gezielt herunterfahren) durchführen, um zu prüfen, ob Calls zuverlässig über den anderen laufen.

Lastverteilung und Dimensionierung: Bei vielen gleichzeitigen Gesprächen muss der SBC entsprechend ausgestattet sein (CPU, DSP-Kanäle, Session-Lizenzen). Eventuell wird Last auf zwei Geräte verteilt (aktiv/aktiv). Beachten, dass cloudseitig pro SBC-FQDN bestimmte Raten gelten (Microsoft drosselt z. B. Signalisierung, wenn zu viele Calls pro Sekunde eingehen – bei normaler Nutzung unkritisch). Besser mehrere SBCs einplanen ab einigen Tausend Usern oder verteilt auf Regionen, als einen monolithischen. Auch SBCs in der Azure-Cloud (virtuell) sind denkbar, was geografische Redundanz erleichtern kann, sofern lokale Breakouts nicht benötigt werden.

Interoperabilität mit Carriern: Ein großer Vorteil eines eigenen SBC ist die Möglichkeit, beliebige SIP-Trunks von Providern anzuschließen. Allerdings unterscheiden sich Carrier-SIP-Implementierungen leicht – der SBC muss häufig angepasst werden, um 100 % Kompatibilität zu erzielen. Beispiele:

• SIP-Header und Nummernformat: Einige Anbieter erwarten die Rufnummer im Request-URI im nationalen Format, andere im internationalen mit +. Der SBC kann mittels Manipulationsregeln z. B. das +49… ins Format 0… umschreiben oder umgekehrt. Gleiches gilt für ausgehende Anrufe: Teams sendet im Regelfall E.164 (+Ländervorwahl…), der SBC konvertiert nötigenfalls. Wichtig ist, E.164 intern durchgängig zu nutzen, um Konsistenz zu haben.
• Codec-Verhandlungen: Der SBC fungiert als Media Terminator – er handelt Codecs mit Teams und dem Carrier separat aus. Falls der Carrier z. B. kein G.722 akzeptiert oder nur G.711 unterstützt, kann der SBC die hochqualitativen Codecs aus dem Offer nehmen oder transkodieren. Transkodierung (z. B. SILK ↔ G.711) benötigt CPU-Leistung auf dem SBC; wo möglich, sollte man es vermeiden durch passende Offer-Filter (oft reicht G.711 und evtl. G.729 auf Trunkseite).
• DTMF & Fax: Der SBC übersetzt unterschiedlich signalisierte DTMF-Töne. Teams nutzt out-of-band (RFC 2833) für DTMF – das muss der SBC Richtung Provider beibehalten oder ggf. konvertieren (manche alten Strecken senden DTMF inband, was mit G.711 ginge). Ebenso sollte T.38-Fax auf dem SBC aktiviert sein, falls der Provider Fax unterstützt, da Teams/SBC bei einem Fax automatisch auf T.38 umschalten könnten.
• SIP Session Timers: Carrier verlangen manchmal regelmäßige Re-INVITEs oder UPDATEs als Keepalive. SBCs können solche Timer auslösen, auch wenn Teams das nicht nativ täte (Teams Phone System unterstützt Session Timer gem. RFC 4028). Im Test mit dem Provider auf Signalisierungsebene (SIP Ladder) prüft man, ob BYE/ACK sauber fließen, ob Refer (bei Transfer) akzeptiert wird etc.
• Register vs. IP-Trunk: Einige Carrier authentifizieren Trunks per Registrierung (SIP-REGISTER). Ein SBC kann zugleich als registrierender SIP-Client fungieren, das ist aber in Direct-Routing-Szenarien seltener, da meist feste IP-Interconnects genutzt werden. Wenn doch (z. B. ITSP im KMU-Umfeld), muss der SBC die Registrierungen handhaben und eingehende Anrufe dem Teams-Routing übergeben.
• Sonderzeichen und Header: Mitunter schicken Carrier proprietäre Header (X-Header) oder erwarten bestimmte Felder. Der SBC kann unnötige Header entfernen oder notwendige ergänzen. Auch die P-Asserted-Identity von Teams muss eventuell in From übersetzt werden, falls der Carrier kein PAI auswertet. Hier hilft oft ein vom SBC-Hersteller bereitgestelltes SIP-Trunk-Profil für den jeweiligen Provider, das Best Practices enthält.

Die Interoperabilitätsphase erfordert oft intensive Tests mit dem Carrier und dem SBC: Testanrufe in beide Richtungen, Prüfung von CLIP-no-screening-Funktion, Halten/Fortsetzen, Makeln, Konferenz, Fax, DTMF (insb. für Voicemail-PIN-Eingabe) etc. Es empfiehlt sich, vorab Carrier-Dokumentationen einzuholen, welche Nummernformate, Codecs und Features unterstützt werden, um den SBC richtig einzustellen.

Notruf-Routing und SBC: Ein essenzielles Thema ist, wie Notrufe (z. B. 112) behandelt werden. Mit Direct Routing hat das Unternehmen hier Gestaltungspflicht: Standardmäßig würde Teams einen Notruf wie jeden anderen über das definierte Routing schicken. Man sollte aber sicherstellen, dass ein Notruf immer an einem passenden lokalen Gateway landet:

• Hat man Standorte in verschiedenen Ländern, muss 112 je nach Standort des Anrufers an das örtliche PSTN gehen (damit die richtige Leitstelle erreicht wird). Teams bietet dafür Emergency Call Routing Policies, wo man je nach Netzwerkstandort eine andere Route definieren kann (z. B. Benutzer in Wien → sende Notruf an SBC_AT, Benutzer in Berlin → SBC_DE). Der SBC wählt dann vor Ort die 112.
• Falls nur ein zentraler SBC existiert, sollte mit dem Carrier abgestimmt sein, dass Notrufe mit übermittelter Adresse und Absendernummer geroutet werden. In Deutschland z. B. melden Firmen Anschlüsse bei der örtlichen Leitstelle an, inkl. Adresse – ruft dann jemand von der VoIP-Anlage 112, sieht die Leitstelle die hinterlegte Firmenadresse passend zur Absendernummer. Bei verteilten Standorten mit zentralem Trunk wird das schwierig, daher lieber lokale Gateways pro Standort.
• Ein SBC kann bei Notruf spezielle Manipulation vornehmen: etwa eine feste Ortskennziffer einfügen oder eine sogenannte ELIN (Emergency Location Identification Number) als Absender setzen. ELINs sind fest hinterlegte Telefonnummern, die einer physischen Adresse zugeordnet sind. Beispiel: Ein Unternehmen hat pro Niederlassung eine ELIN. Wenn nun ein Mitarbeiter dort den Notruf wählt, überschreibt der SBC die ausgehende CLI mit der ELIN dieser Niederlassung. Die Leitstelle erhält so eine Nummer, der die Adresse hinterlegt ist. Gleichzeitig kann der SBC die echte Durchwahl in einem Zusatzheader (z. B. Call-Info) übermitteln oder intern loggen.
• Redundanz im Notfall: Es muss gewährleistet sein, dass Notrufe auch bei Ausfall einzelner Komponenten möglich sind. Daher z. B.: Wenn ein SBC down ist, sollte Teams den Notruf über einen anderen SBC versuchen (z. B. sekundäre Route). Wenn die gesamte Internetverbindung oder Cloud-Connectivity weg ist, ist VoIP faktisch offline – hier greifen Notfallpläne außerhalb von Teams (z. B. Mobiltelefone als Backup für 112 oder ein analoger Notfallapparat). Für Standorte ohne Mobilfunkempfang könnte eine Survivable Branch Appliance (SBA) implementiert werden: Einige SBCs bieten einen SBA-Modus, der bei WAN-Ausfall lokale Telefonie und Notrufe weiterhin ermöglicht (die Geräte registrieren sich dann temporär am SBA statt in der Cloud). Solche Szenarien sollten im Risikomanagement betrachtet werden.

FQDN- und Zertifikatskonzept bei mehreren SBCs: Hat man mehrere SBCs, kann man entweder für jeden ein eigenes Zertifikat nutzen oder ein Wildcard-Zertifikat. Microsoft unterstützt Wildcards (z. B. *.voice.firma.de), allerdings nur auf einer Ebene (z. B. nicht *.*.firma.de). Für Übersichtlichkeit und Sicherheit bevorzugt man meist individuelle Zertifikate pro SBC-FQDN – so kann man einen SBC tauschen, ohne alle zu erneuern. Wichtig ist, intern nachzuhalten, wann Zertifikate ablaufen, um rechtzeitig zu erneuern – denn ein abgelaufenes Zert auf dem SBC kappt sofort die Verbindung zu Teams (die Cloud lehnt es ab).

High-Level-Failover-Strategien: Neben der SBC-Ebene kann man auch auf Routingebene fallbacken: Beispiel – Ein Unternehmen hat Direct Routing als primäre Telefonie, aber für den absoluten Notfall noch Microsoft-Calling-Plan-Lizenzen für ein paar User oder eine Weiterleitung von der TK-Anlage. Sollte der eigene SBC länger ausfallen, könnte man temporär auf Operator Connect umschwenken, sofern vorbereitet. Diese Hybrid-Backup-Konzepte erfordern aber doppelte Infrastrukturkosten und sind eher etwas für sehr kritische Umgebungen.

Monitoring und Management: Ein SBC will betrieben werden: Firmware-Updates (für Security und Teams-Kompatibilität, z. B. neue Cipher oder Protokolländerungen) sind regelmäßig einzuspielen. Die meisten zertifizierten SBC-Hersteller (AudioCodes, Ribbon, Oracle, Cisco u. a.) veröffentlichen Referenzkonfigurationen für Teams – man sollte sich daran halten und in Foren/Support bleiben. Zudem ist ein proaktives Monitoring ratsam: via SNMP oder REST können Alarme generiert werden (z. B. Trunk zum Provider down oder Zertifikat läuft ab). Microsofts Admin Center zeigt ebenfalls die SBC-Status an (Online/Offline, Latenz, Packet Loss pro SBC), was genutzt werden sollte, um schnell auf Probleme zu reagieren.

Zusammengefasst ist die Einführung von Direct Routing mit SBC ein Muss für Szenarien mit eigener Telefonieinfrastruktur oder speziellen Anforderungen. Mit sorgfältigem Design (Zertifikate, FQDN, Redundanz) und ausgiebigen Interop-Tests mit den Carriern lässt sich eine robuste Anbindung realisieren, die den Anwendern nahtlose Gespräche ermöglicht – oft merkt der Nutzer gar nicht, ob sein Gespräch über einen Microsoft-Calling-Plan oder den eigenen SBC läuft. Im Hintergrund aber gewährleistet die SBC-Schicht Flexibilität und Kontrolle über die Schnittstelle zum Telefonnetz.

Notruf & Standortmodelle

Die Abwicklung von Notrufen (Notfallnummern wie 112 oder 110) in einer VoIP-Umgebung erfordert besondere Sorgfalt. Gesetzliche Vorgaben verlangen, dass Notrufe zuverlässig zur zuständigen Rettungsleitstelle gelangen und mit ausreichenden Standortinformationen versehen sind. Mit Microsoft Teams als Telefonielösung müssen Unternehmen entsprechende Vorkehrungen treffen, insbesondere wenn Mitarbeiter mobil oder an verschiedenen Standorten arbeiten. Hier betrachten wir, wie dynamisches Notruf-Routing in Teams funktioniert, wie Standorte zugeordnet werden können und welche Konzepte (z. B. ELIN) und Pflichten im DACH-Raum relevant sind.

Dynamisches Notruf-Routing in Teams: Microsoft Teams bietet die Möglichkeit, Notrufe abhängig vom Standort des Anrufers unterschiedlich zu routen. Im Teams Admin Center kann man Notfall-Richtlinien (Emergency Policies) definieren. Kernstück ist die Zuweisung von Netzwerkstandorten (Locations): Administratoren legen im Voraus Standorte mit Adresse (Land, Stadt, Straße, Gebäude, Etage etc.) an und verknüpfen diese mit Netzwerkparametern – typischerweise IP-Subnetzen, WLAN-SSID/BSSIDs oder Switch-Standorten. Befindet sich ein Teams-Client im Firmen-LAN mit einer bekannten IP (z. B. 10.1.2.0/24, zugeordnet zum Büro München, Elisenstraße 3), erkennt Teams beim Notruf: Dieser User ist am Standort München. Entsprechend kann Teams den Anruf über einen bestimmten SBC routen (z. B. den deutschen SBC, der Münchener Leitstelle am besten erreicht). Noch wichtiger: Teams kann die Standortinfo an die Leitstelle übermitteln. In den USA etwa übergibt Teams bei 911-Anrufen eine genaue Adresse (via PIDF-LO-Datensatz oder über einen spezialisierten E911-Provider). In Europa ist die Schnittstelle komplexer, hier läuft es oft indirekt über die Absendernummer (dazu später). Dennoch kann das System intern den Standort feststellen – das ist die Grundlage für gezielte Routing-Entscheidungen.

Standortzuordnung (Location Identification): Damit dynamisches Routing funktioniert, muss die Umgebung der Nutzer kartiert sein:

• Netzwerk-IDs: Administratoren hinterlegen alle relevanten Subnetze der Organisation in Teams (im Bereich „Standorte & Notruf“ oder via PowerShell). Auch WLAN-Zugangspunkte können einzeln definiert werden (z. B. AP-Lobby-1 entspricht Empfangsgebäude EG). Teams-Clients ermitteln im Betrieb ihre lokale IP und WLAN-BSSID; wenn ein User den Notruf wählt, versucht der Dienst die IP/BSSID einem bekannten Standort zuzuordnen.
• Zugewiesene Notfall-Adresse: Jedem definierten Standort ist eine physische Adresse zugewiesen. Diese Adresse sollte so detailliert wie möglich sein, inkl. PLZ, und idealerweise auch intern präzise (Stockwerk, Raum). In manchen Ländern können solche Angaben im Notrufdatensatz übermittelt werden (in Deutschland traditionell nicht automatisch – hier wird eher per Sprachverbindung erfragt – aber mit VoIP-Anlagen in Firmen ist es komplex, also muss man vorab Regeln schaffen).
• Benutzer-basierte Adresszuweisung: Für Mitarbeiter im Home-Office oder unterwegs greift obiges Mapping nicht, da sie über externe Netze kommen. In einigen Ländern (z. B. USA, UK) fordert Microsoft Teams den Nutzer beim ersten 911-Anruf auf, seine Adresse manuell einzugeben, falls keine automatische Lokalisierung möglich ist. Im DACH-Raum gibt es noch keine solche Pop-up-Funktion, aber Administratoren können dennoch statische Notfalladressen pro Benutzer festlegen (z. B. via Azure-AD-Feld „Büro-Standort“ oder direkt im Teams Admin). So würde ein Mitarbeiter, der immer von einer kleineren Außenstelle aus arbeitet, diese Adresse als Standortinfo mitgeben.

ELIN-Konzept: Wie bereits im SBC-Abschnitt angerissen, wurde für klassische TK-Anlagen das Konzept der Emergency Location Identification Number (ELIN) entwickelt. Dabei wird für jeden physischen Standort oder Gebäudebereich eine spezielle Rufnummer (ELIN) reserviert, die bei Notrufen als Absendernummer übertragen wird. Die Leitstelle hat diese Nummern in ihrer Datenbank mit Adresse hinterlegt. Ruft also jemand aus dem Firmengebäude 2. OG Ost an, sieht die Leitstelle z. B. „089 12345 112“ – und erkennt daran: das ist die ELIN für „Firma XYZ, München, Elisenstr. 3, 2. Stock Ost“. In Microsoft-Teams-Direct-Routing kann man dieses Prinzip umsetzen, indem man pro Netzwerkstandort den SBC veranlasst, eine bestimmte Nummer als CLI für Notrufe zu setzen (unabhängig von der eigentlichen Durchwahl). Das erfordert natürlich, dass das Unternehmen solche Nummern besitzt und vorgängig bei den Notrufstellen registriert hat. In Deutschland kann man z. B. über den Provider sogenannte „Notrufstandort-Rufnummern“ vereinbaren. Alternativ wird oft einfach die zentrale Stammnummer der Niederlassung genommen – die Leitstelle sieht dann zumindest die Stadt/Adresse der Firma, wenn auch nicht den genauen Raum.

Interne Notruf-Benachrichtigung: Best Practice (und in einigen Ländern Vorschrift, z. B. USA Kari’s Law) ist, dass interne Sicherheitspersonen informiert werden, wenn ein Notruf abgesetzt wird. Teams ermöglicht es, pro Standort oder generell Benachrichtigungen einzurichten: z. B. kann definiert werden, dass bei jedem Notruf ein oder mehrere Benutzer/Verteiler einen Hinweis erhalten (Pop-up und/oder E-Mail). Ein Unternehmen kann etwa festlegen, dass die Empfangszentrale oder der Werkschutz eine Kopie des Notrufs bekommt (in Form eines parallelen Teams-Anrufs oder einer Chat-Mitteilung mit Standort). So können Firmenhelfer den Rettungskräften die Orientierung erleichtern (und z. B. Aufzüge freischalten, Tor öffnen etc.). In DACH ist das bisher keine gesetzliche Pflicht, aber aus Arbeitsschutzsicht sinnvoll.

Regulatorische Pflichten (DACH): Die deutschen und österreichischen Regeln verlangen vom Telefoniebetreiber, dass bei Notrufen zumindest eine zutreffende Anschrift und Erreichbarkeit sichergestellt ist. Für Unternehmen mit VoIP-Anlagen bedeutet das:

• Sie müssen für jeden Standort eine Rufnummer bereitstellen, die im Notfall der Rettungsleitstelle übermittelt wird und unter der nachalarmiert werden kann. Das ist meist die Hauptnummer des Standorts oder eine spezielle Durchwahl bei der Empfangszentrale. Diese Information muss dem Provider bekannt sein. In DE etwa melden Unternehmen, die SIP-Trunks nutzen, beim Einrichten dem Carrier: „Für Rufnummernblock X, Standort Y ist die Notrufadresse soundso“. Der Carrier hinterlegt das in seinen Systemen.
• Bei nomadischer Nutzung (Mitarbeiter können prinzipiell von überall anrufen, z. B. via VPN oder mobil) entsteht ein Problem: Die Notrufnummer ist an eine Ortsvorwahl gebunden, die Person könnte aber woanders sein. Der Gesetzgeber erwartet hier von Firmen, dass sie organisatorische Maßnahmen treffen. Beispielsweise: in internen Richtlinien kann festgehalten sein, dass mobile Mitarbeiter im Home-Office nach Möglichkeit ein Handy für Notrufe nutzen sollen, da das näherungsweise den Standort übermittelt (Handymasten) – oder der Firma ihren aktuellen Aufenthaltsort mitteilen, falls über die Cloud telefoniert wird. Vollautomatische Lösungen sind technisch im Kommen (Stichwort AML – Advanced Mobile Location, was aber eher mobilfunkbezogen ist). Für IP-Anlagen gibt es in Deutschland bisher keine Pflicht zu „Dynamic E911“ wie in den USA, aber die Verantwortung, dass Mitarbeiter im Notfall Hilfe erhalten, liegt natürlich beim Arbeitgeber mit.
• Dokumentationspflicht: In Branchen mit Sicherheitsaudit (z. B. kritische Infrastruktur) wird erwartet, dass die Erreichbarkeit der Notdienste regelmäßig getestet und dokumentiert wird. Unternehmen sollten daher mindestens einmal zum Projektende und danach periodisch einen Test-Notruf je Standort durchführen. Vorgehen: vorher bei der zuständigen Leitstelle anrufen (über Nicht-Notfallnummer) und einen Testzeitpunkt vereinbaren, dann z. B. früh morgens kurz 112 vom Teams-Apparat wählen und bestätigen lassen, welche Adresse angezeigt wurde. Die Ergebnisse dieser Tests (Datum, von welcher Nummer, Ergebnis, Ansprechpartner bei Leitstelle) gehören ins Betriebsdokument. In der Schweiz ist der Test empfohlen, in AT/DE ebenso – es stellt sicher, dass im Ernstfall keine bösen Überraschungen auftreten.
• Notruf-Fallback: Eine weitere Pflicht (indirekt aus Fürsorge) ist, alternative Wege parat zu haben. Sollte die Cloud-Telefonie ausfallen, müssen Mitarbeiter instruiert sein, wie sie dennoch einen Notruf absetzen können (klassischer Telefonapparat, Mobiltelefon, analoger Anschluss). Manche Unternehmen halten an jedem Empfang einen Notfall-Festnetzapparat vor, der unabhängig von der IT läuft. Dies sollte in Notfallkonzepten berücksichtigt und kommuniziert sein.

Insgesamt ist zu empfehlen, das Thema Notruf in der Planungsphase prominent mitzubehandeln. Must-have ist die Abstimmung mit dem SIP-Provider über Notrufabwicklung pro Standort und die Konfiguration der Teams-Umgebung, sodass ein Notruf den korrekten Weg nimmt. Nice-to-have sind fortgeschrittene Features wie dynamische Standortauflösung und interne Alarmierung, die aber die Sicherheit erheblich erhöhen. Letztlich möchte man sicherstellen, dass ein Mitarbeiter – egal ob im Hauptsitz, in einer Außenstelle oder im Home-Office – beim Wählen von 112 so schnell wie möglich die richtige Hilfe erreicht und dass alle Beteiligten (externe Rettung, interne Helfer) die nötigen Informationen haben.

Betrieb, Monitoring & Troubleshooting

Nachdem die Teams-Telefonie produktiv geschaltet ist, verlagert sich der Fokus auf den stabilen Betrieb und die kontinuierliche Überwachung der Qualität. Hierfür stellt Microsoft verschiedene Tools bereit, und auch der SBC sowie das Netzwerkmonitoring spielen eine Rolle. Ebenfalls wichtig ist ein erprobter Prozess zum Troubleshooting, um im Störungsfall schnell die Ursache einzugrenzen.

Wichtige KPIs und Monitoring-Tools

Im laufenden Betrieb sollten bestimmte Key Performance Indicators (KPIs) für die Sprachqualität und Systemverfügbarkeit beobachtet werden. Dazu zählen:

• Mean Opinion Score (MOS): ein von 1 (schlecht) bis 5 (sehr gut) bewerteter Qualitätswert pro Anruf, der aus technischen Messwerten berechnet wird. Ein MOS > 4 gilt als gut, < 3,5 als kritisch.
• Paketverlust-Rate: ideal < 1 %, alles über 5 % in einer Verbindung wird problematisch.
• Jitter: Varianz der Latenz, sollte im Schnitt < 15–20 ms bleiben.
• Round-Trip-Zeit: Gesamtlatenz hin und zurück; intern < 100 ms, weltweit < 300 ms angestrebt.
• Signalisierungsverfügbarkeit: Erreichbarkeit der SBCs (Up/Down-Status, Latenz zum Microsoft Edge in ms).
• Anruf-Erfolgsquote: Verhältnis erfolgreicher Verbindungen zu Fehlversuchen (Call Drops, Busy etc.).

Microsoft Teams stellt zwei Hauptwerkzeuge für Qualitätsmonitoring bereit:

• Das Call Quality Dashboard (CQD): ein webbasiertes Reporting-Tool im Admin Center, das aggregierte Telemetriedaten aller Anrufe auswertet. Hier kann man z. B. filtern nach Standort, Verbindungstyp (WLAN vs. LAN), Gerätetyp etc., um Muster zu erkennen. Beispiel: CQD zeigt womöglich, dass im Standort X 10 % der Anrufe eine schlechte Qualität hatten – dann kann man tiefer nachschauen, ob dort vielleicht WLAN das Problem war (CQD bietet Dimensionen wie „WiFi Signal Strength“ oder „Subnet“ an). Im Betrieb sollte man regelmäßig (monatlich, wöchentlich) CQD-Berichte prüfen, um Trends zu sehen – steigt die Fehlerquote? Gibt es Peaks zu gewissen Zeiten? Microsoft liefert PowerBI-Vorlagen, um CQD-Daten benutzerfreundlich aufzubereiten.
• Call Analytics: Für die individuelle Fehlerbehebung einzelner Benutzeranrufe gibt es im Teams Admin Center die Anrufanalyse. Der Helpdesk kann einen Benutzer auswählen und die letzten Anrufe einsehen. Für jeden Anruf listet das Tool detaillierte Metriken: verwendetes Gerät, Audio-/Video-Bitrate, Paketverluste, max. Jitter, Roundtrip, sowie die IP-Adressen und das WLAN oder LAN (SSID, BSSID, Adapter) des Benutzers. So lässt sich oft direkt erkennen, warum Herr Müller gestern um 15 Uhr ein Problem hatte – vielleicht war er auf WLAN mit nur 1 Balken und hatte 8 % Loss, MOS 2,8. Diese Detaildaten sind nahezu in Echtzeit abrufbar und essenziell für den Einzel-Support.

Auf SBC-Seite sollte ebenfalls Logging aktiviert sein. Die meisten SBCs bieten Call Detail Records (CDR) für jeden Call (Zeit, Dauer, Ziel/Quellnummer, Erfolgsstatus, QoS falls gemessen). Diese CDRs kann man ins Monitoring einspeisen oder bei Bedarf auswerten (z. B. für Traffic-Analysen, Missbrauchserkennung oder um bei einer Störungsmeldung festzustellen, ob der Anruf überhaupt beim SBC ankam). Auch SIP-Traces lassen sich oft gezielt einschalten: Im Fehlerfall (z. B. Anrufe brechen sofort ab) kann man am SBC einen Trace der SIP-Nachrichten erstellen, um die Signalisierung zu prüfen.

Netzwerkseitig lohnt es sich, verfügbare Monitoring-Systeme (z. B. SNMP auf Router/Switches) zu nutzen, um Parameter wie Interface-Auslastung, Queue-Drops oder WLAN-Statistiken im Auge zu behalten. Abnormalitäten dort spiegeln sich meist in der Sprachqualität wider.

Troubleshooting: Vorgehen und typische Probleme

Wenn trotz aller Prävention Störungen auftreten, ist systematisches Vorgehen gefragt. Einige typische Problemfelder und Gegenmaßnahmen:

• Allgemeine Sprachqualitätsprobleme (hohe Latenz, Jitter, Aussetzer): Hier deutet vieles aufs Netzwerk hin. Prüfung: Sind mehrere Nutzer betroffen, evtl. standortübergreifend zur gleichen Zeit? Dann eventuell WAN-Engpass oder ein Ausfall auf einer Route (z. B. primärer Internetlink überlastet). Maßnahme: QoS-Implementierung überprüfen (werden DSCP evtl. unterwegs gelöscht?), aktuelle Traffic-Loads analysieren (läuft z. B. gerade ein Backup, das jitter verursacht?). Bei individuellen Fällen: War der Nutzer per WLAN? Vielleicht sind einfach Wi-Fi-Signal oder lokale Verhältnisse schlecht – Test via Kabelverbindung machen. Tools: Call Analytics zeigt Jitter/Verlust pro Richtung – man sieht, ob das Problem auf Benutzerseite (Uplink) oder in Richtung Teams-Server (Downlink) auftrat. So kann man z. B. feststellen „User-Upload hatte 10 % Loss – also sein WLAN-Upstream war schlecht“ vs. „Backbone-Jitter hoch – ggf. Internetrouting-Thema“. Gegenmaßnahmen richten sich dann danach: Access Point versetzen, Kanal wechseln oder ISP kontaktieren, ob es Routing-Probleme gab.
• One-Way-Audio: Ein häufiger VoIP-Klassiker – eine Richtung des Gesprächs ist stumm. Ursache fast immer: Firewall/NAT blockiert RTP in eine Richtung. Z. B. kann der Client zum SBC streamen, aber SBC → Client wird gedroppt. Das kann passieren, wenn z. B. auf dem NAT die UDP-Portsession abgelaufen ist oder die falsche IP genutzt wurde. Troubleshooting: Im SIP-SDP der Anrufsignalisierung schauen, welche IP/Ports für RTP vereinbart wurden. Dann testen (z. B. per Wireshark oder SBC-Media-Stats), ob an diesen Ports etwas ankommt. Oft hilft es, SIP-ALG und jegliche NAT-Manipulation zu eliminieren. In Teams Direct Routing kann One-Way-Audio auch auftreten, wenn Media Bypass an ist, aber Firewall-Regeln zwischen Client und SBC fehlen. Lösung: Firewall-Regeln ergänzen (Client ↔ SBC UDP auf Medienports erlauben). Bei rein cloudbasierten Calls mit One-Way-Audio ist es meist ein temporäres NAT-Problem beim Teilnehmer – Neustart des Clients oder Routers kann helfen; langfristig STUN/TURN-Konfiguration prüfen.
• Anrufaufbau schlägt fehl (keine Verbindung): Hier erst unterscheiden: Betrifft es alle Ziele oder bestimmte Rufnummern? Bei allen externen Zielen schaut man zuerst, ob der SBC und Trunk online sind – evtl. ist der SIP-Trunk zum Provider down (SBC-Alarm prüfen) oder das Zertifikat abgelaufen (kommt am SBC ein TLS-Fehler?). Wenn nur bestimmte Rufnummerngassen nicht gehen (z. B. internationale oder Sondernummern), liegt es oft an den Voice-Routing-Policies oder Normalisierungsregeln: Möglicherweise wurde z. B. vergessen, 00 (international) in + umzuwandeln, oder der Carrier sperrt Premium-Nummern. Troubleshooting: In Teams Admin die Routingregeln überprüfen (Nummerntest per PowerShell Test-CsEffectiveRoute), auf dem SBC schauen, ob der Call ankommt. Falls ja, was macht der Carrier? Der SBC-Log oder ein SIP-Tracer zeigt evtl. einen SIP-Fehlercode vom Provider (z. B. „403 Forbidden“ oder „488 Not acceptable here“). Daraus ableiten: 403 könnte „Nummer nicht im Vertrag“ bedeuten, 488 „Codec passt nicht“. Lösung je nach Befund: Regel ergänzen, Carrier-Option buchen, Codec-Liste anpassen.
• Abbrüche nach bestimmter Zeit (z. B. genau 15 Minuten): Das deutet auf Session Timer oder NAT-Timeout hin. Viele VoIP-Endpunkte nutzen alle 15 Minuten eine SIP-Refresh (Re-INVITE) zur Sitzungsverlängerung. Wenn hier ein Protokollfehler vorliegt (vielleicht versteht der Carrier den Re-INVITE von Teams nicht oder umgekehrt), kann es zum Drop kommen. NAT-Geräte haben manchmal 15-min-UDP-Timouts – wenn kein Traffic (z. B. Pause im Gespräch) und keine Keepalives, kappt NAT die Verbindung. Abhilfe: Session Timers auf dem SBC aktivieren und korrekt konfigurieren (damit regelmäßig UPDATE/Re-INVITE gesendet werden und Carrier und SBC synchron bleiben). Zudem Keep-Alive-Pakete einschalten (die meisten SBCs senden alle 20 s ein leeres UDP-Paket im Strom, um NAT wach zu halten). Wenn dennoch Abbrüche vorkommen, Wireshark der SIP-Session ansehen – wer sendet BYE und warum.
• Echo oder schlechte Audioqualität trotz gutem Netz: Echo hört meistens die Gegenseite. D. h. wenn User A Echo hört, entsteht es bei User B. Meist hat B ein akustisches Problem – z. B. Lautsprechermodus, Mikro nimmt das Lautsprechersignal wieder auf. Bei guter Hardware regelt das AEC das, aber es gibt Grenzen (z. B. sehr laute Umgebung). Troubleshooting: Falls ein bestimmter Teilnehmer oft Echo meldet, dessen Gegenüber fragen, was für ein Gerät genutzt wurde. Oft hilft ein Headset statt Laptop-Mikro oder Herunterdrehen der Lautstärke. Geräte-Logs: Teams gibt in Call Analytics Hinweise, wenn ein Gerät problematisch war (z. B. „Nicht zertifiziertes Gerät“ oder „hoher Echo Return Loss“). Ggf. Nutzerhardware austauschen. Netzseitig kann man gegen Echo nichts tun außer Latenz niedrig halten, denn hohe Latenzen verstärken das Echoempfinden.
• SBC/Trunk spezifische Probleme: Z. B. alle Anrufe über SBC2 haben schlechtere Qualität als über SBC1 → eventuell unterschiedliche Pfade (SBC2 an anderem Standort mit schwächerer Internetanbindung). Oder ein SBC verarbeitet ein SIP-UPDATE falsch und stört Hold/Resume – dann Firmware-Update einspielen. Hier hilft oft der Hersteller-Support des SBC weiter.

Systematische Eingrenzung: Bei Störungsmeldungen bietet es sich an, zunächst zu kategorisieren: Betrifft es einen Benutzer oder mehrere? Nur ausgehend oder ankommend? Nur bestimmte Nummern? Solche Fragen helfen, den Bereich einzugrenzen (Client/Server, SBC/Provider, Netzwerk). Danach: verfügbare Daten sichten – Teams Call Analytics für spezifische Anrufe (auch die Gegenstelle wird dort mit erfasst, z. B. PSTN-IP, falls im Netz Quali-Daten gesendet wurden), SBC-CDRs für Fehlercodes, eventuell Wireshark-Mitschnitt an relevantem Punkt.

Rückgriff auf Anbieter: Manchmal kommt man intern nicht weiter – etwa wenn vermutet wird, dass im öffentlichen Netz etwas schiefgeht. Dann sollte man den Carrier einbeziehen (Ticket mit Datum/Uhrzeit der problematischen Calls, SIP-Fehlercodes etc.) oder Microsoft Support (bei rein internen Teams-Anrufproblemen). Dafür ist es gut, wenn man bereits möglichst viele Vorinformationen gesammelt hat (dann geht die Fehlersuche schneller).

Proaktive Fehlervermeidung: Im Betrieb sollte man aus den anfänglichen Problemen lernen und seine Dokumentation ergänzen. Beispielsweise kann man eine Troubleshooting-Wissensdatenbank führen: typische Fälle und Lösungen (wie obige Beispiele). So kann der IT-Support bei erneuten ähnlichen Meldungen schneller reagieren. Auch Schulungen der Nutzer tragen bei – etwa ein Leitfaden „Was tun bei schlechter Call-Qualität?“ (z. B. „erst WLAN zu LAN wechseln, dann neuen Call versuchen, dann Helpdesk anrufen“) kann helfen, triviale Probleme schnell zu lösen.

KPI-Reporting und Continuous Improvement: Es empfiehlt sich, monatlich einen kleinen Qualitätsbericht zu erstellen (MOS-Durchschnitt, % problematische Anrufe, Top 5 Problemquellen). Das schafft Bewusstsein und erlaubt, gezielt Verbesserungen anzugehen (z. B. wenn auffällt, dass an Standort A regelmäßig Packet-Loss-Spitzen auftreten – dann mit Netzbetrieb klären und dort eventuell Bandbreite erhöhen oder QoS anpassen).

Im Betrieb einer Teams-Telefonielösung gehören sowohl technisches Monitoring via Tools als auch ein klarer Prozess, wie Störungen eskaliert und behoben werden. Must-have ist die Überwachung von Qualitätsmetriken (um schwerwiegende Probleme früh zu erkennen) und ein eingespieltes Support-Team, das die verschiedenen Komponenten (Client, Netzwerk, SBC, Provider, Microsoft-Cloud) versteht. Nice-to-have sind Automatisierungen wie Alerts bei hoher Paketverlust-Rate oder integrative Dashboards, die Daten aus CQD, SBC und Netzwerkmonitoring zusammenführen. Damit kann die Betriebsmannschaft die VoIP-Plattform proaktiv managen und dem Management gegenüber Servicequalität belegen.

Migration, Sonderfälle & Legacy-Integration

Die Umstellung auf Microsoft Teams Telefonie erfordert eine sorgfältige Migrationsplanung, insbesondere wenn bislang eine klassische PBX im Einsatz war. Zudem gibt es oft Sonderfälle – Faxgeräte, Modems, Alarmleitungen, Türsprechstellen – die nicht ohne Weiteres in die neue VoIP-Welt passen. In diesem Abschnitt werden Strategien für die Migration und Koexistenz mit einer bestehenden Telefonanlage sowie der Umgang mit Legacy-Themen erläutert.

Rufnummernportierung und Parallelbetrieb mit PBX

Rufnummernportierung: Ein zentraler Schritt beim Wechsel des Telefoniesystems ist meist die Portierung der Rufnummern vom alten Anbieter zur neuen Lösung. Je nach gewähltem Modell bedeutet das:

• Bei Calling Plans: Rufnummern müssen von der bisherigen Telefongesellschaft zu Microsoft portiert werden. Das erfolgt über ein Portierungsformular im Admin Center. Wichtig ist, genügend Vorlauf einzuplanen (im DACH-Raum ca. 10 Werktage+). Die Portierung kann blockweise erfolgen, um Risiken zu verteilen – z. B. erst 10 Pilot-DIDs portieren und testen, dann den Rest.
• Bei Operator Connect: Hier übernimmt der neue Carrier die Rufnummern – in der Regel portiert man von Altanbieter zu Operator-Connect-Provider. Die Verwaltung in Teams erfolgt dann automatisch.
• Bei Direct Routing mit neuem SIP-Trunk: Wenn man zu einem neuen SIP-Trunk-Anbieter wechselt, müssen Nummern ebenfalls portiert werden. Bleibt man beim gleichen Anbieter (nur Wechsel von ISDN zu SIP), entfällt eine physische Portierung – der Carrier konfiguriert lediglich die Routen neu.

Während der Portierung sollte ein Parallelbetrieb geplant werden: Oft richtet man in Teams temporär Platzhalternummern ein, um Funktionen zu testen, und schaltet erst am Portierungstag die echten Nummern um. Es ist ratsam, an diesem Tag eine erhöhte Bereitschaft im IT-Team zu haben. Sobald die Portierung aktiviert ist (meist früh morgens), müssen die Nummern im Teams-Tenant final zugewiesen sein, damit keine Anrufe ins Leere gehen. Testen Sie unmittelbar nach Portierung eingehend und ausgehend. Auch die Erreichbarkeit von Notruf nach Portierung (über den neuen Weg) sollte sofort geprüft werden.

Koexistenz mit bestehender PBX: Viele mittlere und große Unternehmen wählen keinen Big Bang, sondern einen stufenweisen Umstieg. Das kann bedeuten, dass für eine Übergangszeit Teams und die alte Telefonanlage nebeneinander betrieben werden. Damit interne Gespräche dennoch möglich sind, richtet man eine Kopplung zwischen den Systemen ein:

• Der SBC kann parallel zum PSTN-Trunk auch einen Trunk zur alten PBX bekommen (z. B. via SIP-Q oder QSIG bei ISDN). So können Anrufe von Teams-Benutzern an eine interne Nummer der Altanlage über den SBC zur PBX geroutet werden und umgekehrt.
• Alternativ kann die PBX alle ausgehenden internen Rufe, die sie nicht kennt (z. B. Nummern neuer Teams-Nutzer), zum SBC schicken („Default Route“ zum SBC). Dieser leitet sie an Teams weiter. Damit muss man nicht ständig die PBX-Datenbank pflegen, wer wohin gehört.
• Wichtig ist ein konsistenter Nummerierungsplan: In der Übergangsphase teilen sich PBX und Teams den Nummernraum. Man könnte z. B. definieren: alle Durchwahlen 1000–1499 bleiben auf der PBX, 1500–1999 sind schon auf Teams. Dann konfiguriert man entsprechend Routingregeln. Oder man nutzt Präfixe: ein PBX-User wählt z. B. 88 + Nebenstelle, um zu Teams zu gelangen, während Teams per Voice Routing unbekannte interne Ziele an die PBX mit einem bestimmten Präfix sendet.
• Doppelte Zuordnung vermeiden: Idealerweise sollte jede Telefonnummer zu einem Zeitpunkt nur auf einer Plattform aktiv sein. Wenn z. B. der Vertrieb schon auf Teams ist, wird deren Durchwahlbereich vollständig portiert, und die PBX kennt diese Durchwahlen nicht mehr (außer ggf. für Routingzwecke). Das verhindert Konfusion und garantiert, dass ein eingehender Anruf auch nur auf einem System klingelt.

Phasenweiser Rollout: Ein bewährtes Vorgehen ist es, erst einen Pilotbetrieb mit einer kleinen Benutzergruppe zu starten. Diese Pilotnutzer (z. B. IT oder innovationsfreudige Kollegen in einer Abteilung) erhalten parallel zur bestehenden Telefonie Teams-Phone-Funktionen. Ihnen kann man entweder temporäre neue Nummern zuweisen oder ihnen zwecks Test eine Rufumleitung von ihrer alten Nummer auf Teams schalten. Das Pilotfeedback fließt in die Optimierung ein (z. B. Schulungsbedarf, Anpassung von Richtlinien). Anschließend rollt man standortweise oder abteilungsweise aus. Dabei empfiehlt es sich, zuerst weniger kritische Bereiche umzustellen (z. B. interne Verwaltung), dann geschäftskritische Teams wie Kundenservice. Nach jedem Schub kann ein kurzer „Stabilisierungspuffer“ eingelegt werden. Kommunikationsseitig sollte jeder betroffene Mitarbeiter vorab informiert und geschult werden: Wie melde ich mich in Teams an? Wie funktioniert das Telefonieren? Wo finde ich Hilfe bei Problemen? Ein gut vorbereitetes Adoption-Team kann hier viel leisten.

Parallelbetrieb während Migration: In der Übergangszeit haben manche Benutzer eventuell zwei Telefone auf dem Tisch – das alte und Teams (z. B. auf dem PC oder ein neues Teams-Telefon). Das ist zwar kurzzeitig hinnehmbar, sollte aber nicht zu lange dauern, um Verwirrung zu vermeiden. Daher klare Migrations-Cutover pro Nutzer definieren: Ab Tag X nutzt Herr Y nur noch Teams, sein Tischapparat wird eingezogen oder auf „nur Empfang“ konfiguriert. Oft bewährt es sich, Alt und Neu nicht beliebig zu mischen, sondern definierte Gruppen vollständig umzustellen, damit nicht jeder mit zwei Systemen hantieren muss.

Nach der Umstellung: Die alte Telefonanlage sollte erst außer Betrieb gehen, wenn alle Funktionen auf Teams abgebildet sind und letzte Sondergeräte migriert wurden. Man behält ggf. eine Übergangsfrist, in der die PBX noch als Fallback existiert (z. B. falls man ganz zurück müsste – was selten passiert, aber im Change-Management manchmal als Beruhigung dient). Danach: geordnete Außerbetriebnahme (Trunk kündigen, PBX abschalten, aber Konfiguration archivieren).

Integration von Fax, Modem & Co.

Die Digitalisierung hat vieles ersetzt, aber Faxgeräte und ähnliche analog gebundene Systeme sind in manchen Firmen noch Realität. Diese funktionieren über VoIP nur eingeschränkt:

• Fax (G3): Faxe analog über IP zu senden ist fehleranfällig wegen der Echtzeitanforderungen. Wenn Fax weiterhin benötigt wird, gibt es Optionen:
• T.38 Fax-Relay: T.38 ist ein Protokoll speziell für Fax-over-IP, das Aussetzer besser kompensiert. Viele SBCs und Provider unterstützen T.38. Man kann das Faxgerät über einen Analog-Telefon-Adapter (ATA) an den SBC anschließen. Der SBC wandelt Faxsignale in T.38-Datenpakete für den Provider. Voraussetzung: Der SIP-Trunk-Anbieter muss T.38 erlauben. Diese Lösung kann klassische Faxgeräte weiternutzen, erfordert aber gründliche Tests – manche Faxgeräte sind wählerisch.
• Fallback G.711 Passthrough: Falls T.38 nicht geht, kann man Fax über den normalen Audio-Codec G.711 übertragen. Das kann für einzelne Seiten klappen, ist aber bei längeren Faxen störanfällig (schon 1 % Packet Loss kann die Faxübertragung abbrechen). Hier müsste das IP-Netz absolut stabil sein.
• Alternative: Faxdienste oder Scan-to-Mail: Strategisch überlegen, ob man eingehende Faxe auf einen Fax-zu-E-Mail-Dienst umstellt (Cloud-Fax-Service) und ausgehende Faxe per Web/API versendet. Das umgeht die Echtzeitproblematik. Viele Firmen entscheiden sich im Zuge der Telefonieumstellung gleich, Fax abzuschaffen oder zu digitalisieren.
• Beibehaltung analoger Leitung: In Sonderfällen behält man schlicht einen Analoganschluss des Festnetzanbieters nur fürs Fax, parallel zum VoIP (Keep-it-simple-Prinzip).
• Modems und Datenübertragungen: Analoge Modems (z. B. in Alarmanlagen, EC-Cash-Geräten, Aufzügen) sind noch heikler. Die Töne eines Modems tolerieren fast keinen Jitter. Über VoIP-Verbindungen – vor allem mit Kompressionscodecs – brechen Modemverbindungen fast immer ab. Empfehlungen:
• Kein VoIP für Modems: Wenn möglich, diese Geräte nicht über die Teams-Telefonie schicken. Besser: Für Alarmanlagen etc. auf IP-gestützte Meldegeräte umrüsten (viele Hersteller bieten mittlerweile LAN/GSM-Module an) oder einen separaten analogen Telefonanschluss behalten.
• EC-Terminals: Viele moderne EC-Geräte nutzen IP oder Mobilfunk. Legacy-Modelle, die nur Wählleitung können, sollte man austauschen – die Banken bieten hier i. d. R. Lösungen an.
• Ferndiagnose-Modems: Wenn etwa Techniker via Modem auf Maschinen zugreifen – hier eventuell den Weg über LTE-Router oder VPN suchen, statt über VoIP.
• Alarmserver und Notfallleitungen: Einrichtungen wie Brandmeldeanlagen, Aufzugnotruftelefone oder Notfallsprechstellen sind oft per analoger Leitung direkt mit Hilfsdiensten verbunden. Hier ist zu prüfen, ob eine Migration zulässig ist:
• Manche Vorschriften schreiben vor, dass z. B. Brandmelder eine direkte Leitung zur Leitstelle haben müssen (keine Internet-Abhängigkeit). Hier wäre VoIP nicht zulässig als Ersatz. Solche Leitungen behält man dann traditionell (z. B. über einen ISDN-Analog-Wandler, der weiter am Amt hängt, oder neuerdings oft über GSM-Module).
• Falls eine Integration in Teams gewünscht ist (eher selten, z. B. wenn das Notruftelefon im Aufzug intern jemanden anruft): dann wie bei Fax ein ATA an den SBC, aber unbedingt Robustheit prüfen und notfalls USV (Stromausfall-Szenario bedenken) bereitstellen.
• Für interne Alarmserver (z. B. Personal-Notsignal-Systeme im Betrieb), die Wählleitungen nutzen, gilt Ähnliches – im Zweifel separat halten oder dedizierte SIP-Verbindungen nutzen, aber nicht über die Standard-Telefonielösung laufen lassen, damit ein Ausfall nicht gleich Alarme beeinträchtigt.
• Türsprechstellen und Gegensprechanlagen: Viele Gebäude haben Türtelefone, die früher auf analoge Nebenstellen liefen. Hier kann man:
• SIP-fähige Türsprechstelle einsetzen: Am Markt gibt es IP-Türtelefone, die als SIP-Client fungieren (z. B. von Baudisch, Algo etc.). Über den SBC kann man so ein Gerät als eigenständige „Nebenstelle“ in Teams anmelden (entweder via Direct Routing als Kontaktobjekt oder evtl. via das Microsoft SIP Gateway, sofern kompatibel). Dann kann die Türstation z. B. beim Klingeln eine Teams-Besetzgruppe (Empfang) anrufen.
• Analog über ATA: Bestehende Türsprecher lassen sich oft über einen ATA anbinden, ähnlich wie Fax. Der ATA registriert als User in Teams (über SBC). Allerdings muss man die Steuerfunktionen (Tür öffnen per DTMF) sicherstellen – DTMF passthrough konfigurieren. Tests sind nötig, ob z. B. die Sprachübertragung (Hall gegenhören) klar verständlich ist.
• Für Türöffner-Funktion (meist DTMF wie „*“): Der SBC/ATA sollte DTMF sauber an die Türanlage durchreichen. Eventuell muss man im SBC konfigurieren, dass DTMF als Inband an den ATA geschickt wird, falls die analoge Streckenlogik es braucht.
• Insgesamt gelingt die Integration von Türsprechstellen in vielen Fällen – aber man sollte dies rechtzeitig planen und nicht am Tag der Abschaltung merken, dass das Tor-Intercom nicht mehr geht.
• Sonderrufnummern und Dienste: Stellen Sie sicher, dass sämtliche benötigten externen Sondernummern erreichbar sind:
• Kostenfreie Nummern (0800, 00800) und Service-Nummern (0900, 0180x): Diese erfordern manchmal besondere Freischaltungen beim Provider oder spezielle Wahlformate. Testen Sie diese im Voraus. Beispiel: Manche Carrier erwarten 0800-Nummern im internationalen Format +49800…, andere im nationalen Format 0800… (ohne +49). Passen Sie Dial-Plans entsprechend an.
• Behördliche Kurzwahlen: In einigen Ländern gibt es dreistellige Nummern (z. B. 110 Polizei, 112 Rettung – die sind klar –, aber auch 116117 ärztlicher Notdienst, 115 Behördennummer in DE). Viele davon sollten automatisch funktionieren, dennoch prüfen und ggf. im Dial-Plan normalisieren. Teams kennt 112/110 als Notruf per Default in entsprechenden Regionen. Für 116117 könnte man z. B. eine Regel anlegen, die das in +493… überführt, falls nötig, oder man testet, ob es direkt vom Provider geroutet wird.
• Interne Kurzwahlen/Paging: Falls die alte Anlage interne Kurzwahlen (z. B. „9“ für Amt, „0“ für Zentrale, „*11“ für Lagerdurchsage) hatte, müssen diese im neuen System nachgebildet oder bewusst abgeschafft werden. Häufig wird „0“ als Amtskopf entfallen (weil man in Teams direkt voll wählt). „0“ als Zentrale kann man aber beibehalten, indem man im Dial Plan „0“ -> Hauptnummer +…0 normalisiert. Paging-Funktionen (Durchsage) sind in Teams nicht nativ vorgesehen, könnten aber ggf. über ein SIP-Lautsprecher-System neu implementiert werden.
• Parallelbetrieb für Sonderdienste: Manche Firmen entscheiden, die alte Anlage minimal weiterzubetreiben, um einige Spezialapparate dran zu lassen (sogenannter „Island Mode“). Zum Beispiel bleibt eine kleine ISDN-Anlage mit 2–3 analogen Ports für Fax/Tür etc. und diese wird via SBC ans Teams angebunden. Damit sind diese Geräte aus Teams erreichbar, ohne dass sie direkt in die Cloud müssen. Das vereinfacht die Legacy-Integration, sollte aber gut dokumentiert sein, da so eine Restanlage natürlich auch gewartet sein will.

Rollout-Strategie und Abschluss: Die Migration endet offiziell, wenn alle Benutzer migriert, alle Nummern portiert und alle Altlasten geklärt sind. Zum Abschluss sollten:

• Alle Prozesse auf Teams umgestellt sein (Voicemail, Hotline, Ansagen, Notruf).
• Ein Betriebshandbuch erstellt sein, das die neue Landschaft beschreibt (dazu im nächsten Abschnitt mehr).
• Die alte Anlage sauber stillgelegt und Verträge gekündigt sein.
• Ein Resümee gezogen werden: Haben wir alle Sonderfälle erwischt? (Lieber eine Checkliste zu viel als zu wenig – z. B. „Hausnotruf im Aufzug – ja, über GSM-Modul gelöst am 1.9.2025, getestet“).

Insgesamt ist Migration ein Projekt im Projekt. Must-have ist hier ein strukturierter Plan mit Meilensteinen (Pilot, Teil-Rollouts, Vollbetrieb) und ein Fallback-Konzept für kritische Phasen (z. B. bei Portierung). Nice-to-have ist, wenn man im Zuge dessen gleich veraltete Technologien wie Fax/Modem modernisieren kann, sodass die neue Teams-Umgebung „sauber“ und zukunftsfähig bleibt.

Sicherheit & Compliance

Telefonie berührt immer auch sensible Daten – sei es gesprochener Gesprächsinhalt, Metadaten über Verbindungsaufbau oder personenbezogene Rufnummern. Daher muss eine VoIP-Lösung wie Microsoft Teams Phone so betrieben werden, dass Vertraulichkeit, Integrität und gesetzliche Vorgaben eingehalten werden. Dieser Abschnitt behandelt die Sicherheitsmechanismen (Verschlüsselung, Zugriffsschutz), das Identitäts- und Berechtigungsmanagement, Protokollierungs- und Aufzeichnungsanforderungen sowie Aspekte des Datenschutzes im DACH-Raum.

Ende-zu-Ende-Verschlüsselung: Microsoft Teams setzt durchgehend moderne Verschlüsselung ein. Alle Signalisierungsdaten laufen über TLS 1.2+ (mit starken Cipher-Suites), und die Medienströme (Audio, Video, Desktop-Sharing) werden per SRTP verschlüsselt (Secure RTP mit AES-256). Damit sind Gespräche gegen Abhören im IP-Netz geschützt – nur die kommunizierenden Endpunkte (bzw. bei PSTN-Anrufen der Microsoft-Medienserver und der SBC) können den Traffic entschlüsseln. Für Unternehmen heißt das: Der Transport ist sicher by Design, es muss dafür nichts zusätzlich lizenziert oder konfiguriert werden. Wichtig ist aber, an Schnittstellen keine „Lücken“ zu lassen: z. B. sollte der SIP-Trunk vom SBC zum Carrier wenn möglich ebenfalls verschlüsselt (TLS/SRTP) betrieben werden. Viele Provider bieten SIP-TLS als Option an, was unbedingt genutzt werden sollte, um auch ab SBC bis Vermittlungsstelle Abhörsicherheit zu haben. Falls ein Carrier nur unverschlüsseltes SIP/RTP erlaubt, sollte dieser Traffic zumindest über eine private Leitung oder VPN geführt werden (z. B. MPLS oder IPsec-Tunnel), damit er nicht offen im Internet steht.

Zugriffsschutz und Rollen: In der Cloud-VoIP liegt viel in der Konfiguration – entsprechend sensibel sind Admin-Zugriffe. Unternehmen sollten ein Rollenkonzept für Teams Phone aufsetzen:

• Wer darf Änderungen an Voice-Routing, Nummernzuteilung und Policies vornehmen? (In großen Firmen evtl. eine kleine Gruppe von UC-Admins.)
• Wer darf Support-Daten einsehen (z. B. Call Analytics mit möglicherweise personenbezogenen Qualitätsdaten)?
• Microsoft 365 bietet vordefinierte Rollen wie Teams Service Administrator oder granularer Teams Communications Administrator – diese Rollen sollte man statt Global Admins für die Telefonieverwaltung nutzen. So beschränkt man den Kreis der Berechtigten.
• Alle Admin-Konten müssen mit Multi-Faktor-Authentifizierung (MFA) geschützt sein, um Accountübernahmen zu verhindern. Gerade, weil über die Telefonie z. B. auch Gebührenmissbrauch begangen werden könnte (Stichwort Toll Fraud: Angreifer kapern Account und telefonieren auf teure Servicenummern).
• Auf der Benutzerebene sollte die Identität ebenfalls bestmöglich geschützt sein (MFA für Benutzerzugriff aufs M365-Konto), um unautorisierten Zugriff auf Voicemail oder gar das Führen von Anrufen in fremdem Namen zu unterbinden.
• Es kann sinnvoll sein, geobasierte Conditional Access einzusetzen – z. B. zu verhindern, dass sich ein Teams-Phone-Benutzerkonto aus Ländern anmeldet, in denen die Firma gar nicht tätig ist. Das würde auffällige Betrugsfälle sofort blockieren (z. B. Login aus Übersee, der massenhaft Anrufe tätigt).
• Für externe Zugriffe (Gast-Accounts in Teams etc.) sollte man regeln, ob diese auf Telefoniefunktionen zugreifen dürfen. Standardmäßig können Gäste keine PSTN-Anrufe initiieren.

Protokollierung und Auditing: Ein wichtiger Teil von Compliance ist die Nachvollziehbarkeit von Aktionen und Gesprächen:

• Microsoft 365 führt ein Audit Log, in dem auch Änderungen an Telefonie-Einstellungen protokolliert werden (z. B. wer hat wann eine Policy geändert). Dieses Log sollte aktiviert sein und regelmäßig gesichtet oder via SIEM ausgewertet werden, um unautorisierte Änderungen zu erkennen.
• Für Gespräche selbst speichert Teams umfangreiche Metadaten (Zeit, beteiligte Accounts, Dauer, technische Qualität). Diese sind im Call Quality Dashboard aggregiert oder über die Graph-API abrufbar. Für Abrechnungs- oder Kontrollzwecke kann man die PSTN-Nutzungsberichte im Teams Admin Center verwenden – sie zeigen pro Nutzer, welche externen Nummern wann angewählt wurden und wie lange. Diese Daten werden aus Compliance-Sicht mindestens einige Monate vorgehalten. Unternehmen sollten definieren, wer Zugriff darauf haben darf (z. B. nur Administratoren oder auf Anfrage).
• SBC-Logs: Der SBC sollte so konfiguriert sein, dass er Systemereignisse (Anmeldeversuche, Fehler) an ein zentrales Logging sendet (z. B. Syslog-Server). So können sicherheitsrelevante Ereignisse wie gehäufte Fehlanrufversuche (vielleicht Port-Scanning oder Anwahl nicht existenter Durchwahlen als Fraud-Indikator) erkannt werden.
• Manche Branchen erfordern die Aufbewahrung von Verbindungsdaten für eine gewisse Frist (z. B. im Finanzbereich). Hier sollte rechtzeitig geklärt werden, ob Call-Detail-Records für X Jahre archiviert werden müssen. Teams selbst bietet nicht so langfristige Speicherung out-of-the-box, aber man könnte z. B. regelmäßig die Berichte exportieren und verschlüsselt ablegen.

Anrufaufzeichnung (Compliance Recording): Wenn gesetzliche Vorgaben vorschreiben, dass Gespräche aufgezeichnet werden (z. B. Kundengespräche im Wertpapierhandel, Hotline-Qualitätssicherung), muss eine entsprechende Lösung implementiert werden. Microsoft Teams unterstützt Compliance Recording über zertifizierte Partnerlösungen. Dabei agiert eine spezielle Recording-Software als „Teams-Bot“, der sich lautlos in Gespräche schaltet und diese mitschneidet, ohne dass der Benutzer es verhindern kann – das ist wichtig für Rechtskonformität in regulierten Umfeldern, wo kein Opt-out erlaubt sein darf. Solche Lösungen (z. B. Verint, ASC, NICE) müssen in die Teams-Umgebung integriert und entsprechend konfiguriert werden (welche Nutzer aufgezeichnet, wie Daten gespeichert). Unternehmen müssen hier sehr genau auf den Datenschutz schauen: In Deutschland z. B. dürfen Gespräche nur unter strengen Bedingungen ohne aktive Zustimmung aller Beteiligten aufgenommen werden. Für regulierte Branchen gibt es Ausnahmen, aber meist mit Auflagen (Info an Gesprächspartner, spezielle Zweckbindung der Aufzeichnung, strenge Zugriffskontrolle). Wenn also Compliance Recording eingesetzt wird, sollte es klar dokumentiert und mit dem Betriebsrat abgestimmt sein. Teams bietet zudem eine einfachere Benutzeraufzeichnung (User drückt „Aufzeichnen“ im Gespräch, alle Teilnehmer werden informiert). Diese, nicht zu Compliance-Zwecken gedachte Funktion, ist freiwillig und speichert die Aufnahme im OneDrive/SharePoint des Initiators. Firmen können per Policy das Aufzeichnen durch Benutzer deaktivieren, wenn dies unerwünscht ist (z. B. aus Datenschutzgründen in internen Meetings).

Datenschutz und Aufbewahrung: Im DACH-Raum gelten strenge Datenschutzgesetze (EU-DSGVO, BDSG usw.). Sprachkommunikation wird dabei teilweise wie der Inhalt von E-Mails behandelt. Wichtige Punkte:

• Verbindungsdaten als personenbezogene Daten: Die Liste, wann welcher Mitarbeiter welche Nummer angerufen hat, gilt als personenbezogenes Datum (Rufnummern können Rückschlüsse auf Geschäftskontakte zulassen). Eine Verarbeitung ist nur erlaubt, wenn sie zur Aufgabenerfüllung nötig ist oder gesetzlich vorgeschrieben. Daher sollten Unternehmen definieren, wer diese Daten sehen darf. Z. B. darf ein Vorgesetzter routinemäßig die Anruflisten seiner Mitarbeiter einsehen? Eher nicht ohne Zustimmung/Betriebsvereinbarung. Meist werden solche Daten nur im Anlassfall ausgewertet (z. B. bei Missbrauchsverdacht oder Rechnungsklärung) durch befugte Stellen (Datenschutzbeauftragter, Compliance Officer).
• Aufbewahrungsfristen: Standardmäßig speichert Teams Anrufprotokolle in den Benutzerkonten (Anrufverlauf in der App) und die genannten Admin-Reports. Unternehmen sollten entscheiden, ob sie diese Daten nach einer gewissen Zeit löschen oder anonymisieren. Ein Beispiel: Ein Unternehmen könnte per Richtlinie festlegen, dass detaillierte Verbindungsdaten nach 6 Monaten gelöscht werden, außer sie werden für Abrechnung benötigt. Technisch müsste man dafür einen Prozess schaffen (z. B. regelmäßiger Export und dann Löschung via Graph-API), da Microsoft nicht alles automatisiert entfernt. Voicemails (Sprachnachrichten) liegen in Exchange-Online-Postfächern und unterliegen daher den dortigen Löschfristen/Retention Policies – hier sollte man prüfen, ob z. B. Voicemails nach 30 Tagen gelöscht werden sollen, analog zu E-Mail-Vorgaben.
• Transkriptionen und KI-Funktionen: Teams bietet Features wie Voicemail-Transkription (schriftliche Umwandlung der Anrufbeantworter-Nachricht) oder in Meetings Live-Untertitel. Diese Funktionen verarbeiten Sprachinhalt und könnten datenschutzrelevant sein. In hochsensiblen Bereichen kann man erwägen, Voicemail-Transkription zu deaktivieren (Admin Setting), wenn Bedenken bestehen, dass Sprachdaten zu Microsoft für KI-Verarbeitung gesendet werden. Microsoft versichert zwar DSGVO-Konformität und keine unautorisierte Nutzung von Kundendaten, doch in einigen Unternehmen will man solche Funktionen bewusst abschalten.
• Zugriffsschutz auf Gesprächsinhalte: Abseits von Aufzeichnungen sind „normale“ Gespräche in Teams flüchtig – es wird nichts gespeichert, außer die Diagnosedaten. Allerdings können Teilnehmer Notizen machen, Screenshots etc. Schulung und klare Policies (z. B. „keine vertraulichen Inhalte über ungesicherte Leitungen“ – hier aber moot, da Teams gesichert ist) können helfen, Awareness zu schaffen.
• Betriebsrat und Mitbestimmung: Der Wechsel auf Teams-Telefonie sollte – falls ein Betriebsrat vorhanden ist – mit diesem abgestimmt werden. Aspekte wie Leistungskontrolle sind zu beachten: Tools wie CQD könnten theoretisch genutzt werden, um z. B. die Anzahl der Anrufe pro Mitarbeiter zu sehen. Solche Nutzungen sind in Deutschland mitbestimmungspflichtig. Daher ist oft der Abschluss einer Betriebsvereinbarung sinnvoll, die festlegt, welche Monitoring-Daten erhoben und wie verwendet werden (typisch: nur zur technischen Qualitätsüberwachung, nicht zur Verhaltenskontrolle). Ebenso sollte geregelt sein, wer Zugriff auf Ruflistendaten hat und dass Aufzeichnungen ohne Zustimmung unzulässig sind, außer gesetzlich vorgeschrieben.

Zusammenfassung Sicherheit & Compliance: Microsoft Teams liefert eine robuste Basis: Netzverschlüsselung, integrierte Authentifizierung mit Azure AD und rollenbasierte Administration. Unternehmen müssen darauf aufbauend eigene Regeln implementieren, um Missbrauch vorzubeugen (z. B. MFA, Zugriffsbegrenzung) und gesetzlichen Pflichten zu genügen (z. B. Notruf-Logging, Löschkonzepte). Ein Must-have ist die konsequente Nutzung der Sicherheitsfeatures (verschlüsselte Trunks, starke Passwörter/MFA, regelmäßige Updates des SBC und der Clients, um Sicherheitslücken zu schließen). Ebenso Pflicht sind Datenschutzmaßnahmen wie Datensparsamkeit und transparente Kommunikation an Mitarbeiter, welche Daten im Rahmen der Telefonie erfasst werden. Nice-to-have sind fortgeschrittene Tools wie DLP (Data Loss Prevention) auf Sprachinhalte – aktuell schwer umsetzbar – oder automatische Anomalieerkennung (z. B. ein SIEM, das Alarm schlägt, wenn ein User plötzlich 100 Auslandsgespräche führt). Für die meisten Organisationen genügen aber klare Prozesse: Security- und Compliance-Teams sollten in das Projekt involviert sein, die Dokumentation (Sicherheitskonzept, Datenschutz-Folgenabschätzung) ergänzen und nach Go-Live regelmäßig prüfen, ob alle Richtlinien eingehalten werden.

Praxisleitfaden für Einführung (30/60/90 Tage)

Zum Abschluss fassen wir einen beispielhaften Fahrplan für die Einführung von Microsoft Teams Telefonie zusammen. Dieser 30/60/90-Tage-Plan geht von einem mittleren Unternehmen aus und dient als Orientierung, welche Schritte in den ersten drei Monaten vom Projektstart bis zum produktiven Betrieb durchlaufen werden sollten. Ebenso werden Schlüsselelemente wie Abnahmekriterien und Inhalte des Betriebshandbuchs skizziert.

Erste 30 Tage: Planung und Proof of Concept

Tag 1–10: Projektinitialisierung und Anforderungsaufnahme – Bilden Sie ein Kern-Projektteam (UC-Experte, Netzwerk, Security, ggf. externe Partner). Halten Sie einen Kick-off mit allen Stakeholdern (IT-Leiter, Betriebsrat, Compliance). Sammeln Sie Anforderungen: Wie viele Nutzer und Standorte? Welche Funktionen (Callcenter, IVR, Notfallhotline)? Gibt es Einschränkungen (z. B. Aufzeichnungspflicht, bestehende Verträge)? Erfassen Sie alle bestehenden Rufnummern und Durchwahlen, Verträge mit Carriern, besondere Geräte. Definieren Sie Erfolgskriterien (z. B. „90 % der Nutzer sollen bis Tag 90 mit Teams telefonieren, MOS >= 4“).

Tag 11–20: Design und Lab-Aufbau – Entwerfen Sie die Zielarchitektur (Direct Routing vs. Operator Connect, SBC on-prem vs. Azure, Netzwerkintegration). Führen Sie eine Netzwerkanalyse durch (Bandwidth/Port-Check, QoS-Fähigkeit, Firewall-Freigaben – vieles kann man simuliert testen). Richten Sie dann eine Proof-of-Concept-Umgebung ein: z. B. einen Test-SBC (oder zunächst nur Telefonie via Microsoft-Testnummern). Buchen Sie ggf. Testlizenzen (z. B. Teams Phone Trial) und konfigurieren Sie im Microsoft 365 Admin Center erste Einstellungen (Zuweisung einer Test-Rufnummer zu einem Teams-Benutzer, Einrichten eines Dial Plans für interne Durchwahlen). Verbinden Sie den SBC im Lab mit einem Trial-SIP-Trunk oder nutzen Sie 1–2 vom Anbieter bereitgestellte Testnummern. Ziel: Innerhalb der ersten 3 Wochen sollte ein Testtelefonat von Teams nach extern und zurück möglich sein – zunächst mit minimalem Setup.

Tag 21–30: PoC-Test und Planverfeinerung – Führen Sie umfangreiche Tests in der Lab-Umgebung durch: Audioqualität intern/ausgehend/eingehend prüfen; Basisfunktionen (Halten, Weiterleiten, Voicemail) testen; verschiedene Codecs und kleine Belastungstests (z. B. 5 gleichzeitige Anrufe) durchführen. Nutzen Sie die Ergebnisse, um das Design anzupassen (z. B. wenn Audio über VPN schlecht war, Plan für Split-Tunnel aufnehmen). Parallel: erstellen Sie einen Migrationsplan (Wellen der Nutzerumstellung, Zeitplan Portierungen). Klären Sie mit dem Carrier die Portierungstermine und Technik (Formulare einreichen, Wunschtermin abstimmen). Schließen Sie ggf. Verträge ab (für SIP-Trunk, Operator Connect oder Calling-Plan-Lizenzen kaufen). Bestellen Sie nötige Hardware frühzeitig (Headsets, Teams-Telefone, SBC-Appliance oder VM-Infra). Halten Sie regelmäßig Projektrunden, um alle auf Stand zu halten.

Tag 31–60: Pilotbetrieb und Vorbereitungen zum Rollout

Tag 31–45: Pilotgruppe umstellen – Wählen Sie eine Pilotgruppe von vielleicht 5–10 Nutzern (idealerweise IT-affin oder ein gemischtes Team). Weisen Sie ihnen Teams-Phone-Lizenzen und echte Rufnummern zu (ggf. vor Portierung noch temporäre Nummern, oder richten Sie Parallelruf von der alten Nummer ein). Schulen Sie diese Pilotanwender im Umgang mit Teams-Anrufen, klären Sie Anfangsschwierigkeiten (z. B. Audiogerät einstellen, Anrufweiterleitung). Sammeln Sie Feedback: Verständigungsqualität, Benutzerfreundlichkeit, fehlende Funktionen. Setzen Sie Supportwege auf – z. B. ein direkter Chat-Kanal zum Projektteam für Pilotrückmeldungen. In dieser Phase können Sie noch unentdeckte Probleme erkennen (z. B. „Konferenztelefon XY hat Aussetzer“ → evtl. Firmware-Update nötig). Starten Sie auch mit dem Teams-Calling-Feature für interne Meetings, damit man ein Gefühl für parallele Nutzung (gleichzeitig chatten, präsentieren und telefonieren) bekommt.

Tag 46–55: Infrastruktur finalisieren – Basierend auf Pilot-Erkenntnissen nehmen Sie Feineinstellungen vor: z. B. Dial-Plan-Regeln anpassen (vielleicht wollten Pilotteilnehmer Kurzwahl „0“ für die Zentrale nutzen – fügen Sie das hinzu), erforderliche Teams-Policies definieren (z. B. wer darf aufzeichnen, wer darf anonym anrufen, Call-Queue-Timeouts). Stellen Sie nun die produktive SBC-Umgebung fertig: Falls bislang ein Test-SBC genutzt wurde, installieren/konfigurieren Sie jetzt die hochverfügbare SBC-Plattform, importieren Sie das endgültige Zertifikat und verbinden Sie den SBC mit dem offiziellen Trunk im Testmodus. Testen Sie die Failover-Szenarien (SBC1 down – übernimmt SBC2? Netz weg – was passiert mit Calls?). Implementieren Sie endgültig QoS im Netzwerk (Switch-Config ausrollen, WAN-Router anpassen). Jetzt ist auch Zeit, die Security-Checks abzuhaken: Stellschrauben wie MFA für Admins prüfen, Notfallkonzept (z. B. analoges Notfalltelefon am Empfang bereitstellen) finalisieren.

Tag 56–60: Schulung & Change Management – Während die Technik nun einsatzbereit ist, kümmern Sie sich intensiv um die Endbenutzer-Vorbereitung: Erstellen Sie Benutzerhandbücher oder Quick-Reference-Cards (z. B. „Wie tätige ich einen Anruf? Wie halte ich? Wie übergebe ich?“ mit Teams-Screenshots). Veranstalten Sie Webinare oder Präsenzschulungen für die ersten Abteilungen, die umgestellt werden. Kommunizieren Sie klar die Vorteile der neuen Lösung (Ortsunabhängigkeit, Integration mit Kalender/Chat, modernes Headset statt altes Telefon) – aber auch, was sich ändert (ggf. neue Durchwahlsystematik, Wegfall von physischen Telefonapparaten). Richten Sie für den Go-Live eine Hotline ein (der Service Desk ist informiert und hat interne Eskalationspfade). Stimmen Sie mit der Geschäftsleitung den Umstellungszeitplan ab und informieren Sie alle Bereichsverantwortlichen.

Tag 61–90: Rollout und Übergabe in den Betrieb

Tag 61–75: Schrittweiser Rollout – Beginnen Sie mit der großflächigen Migration. Zum Beispiel: Woche 9 Hauptverwaltung (100 Nutzer), Woche 10 Standort A (50 Nutzer), Woche 11 Standort B (50 Nutzer) usw. Vor jedem Teil-Rollout: Prüfen Sie, ob die Portierungstermine bestätigt sind und alle Nutzer ihr Equipment erhalten haben (Headsets verteilt, Teams-App auf neuestem Stand). Führen Sie die Umstellung möglichst außerhalb der Kernarbeitszeit durch (z. B. Freitag Spätnachmittag), insbesondere wenn Rufnummernportierungen involviert sind – Anbieter portieren meist frühmorgens, das sollte man begleiten. Nach jeder Gruppe: direkt Smoke-Tests machen – können alle neuen User extern telefonieren, kommen Anrufe an? Gibt es Beschwerden? Halten Sie engen Kontakt zu den Key-Usern in jeder Abteilung, damit Probleme schnell adressiert werden. Mögliche anfängliche Stolpersteine: Einzelne Nutzer haben noch keine Lizenz (zuweisen nachholen); ein VLAN im Lager-Switch war falsch – QoS nachjustieren; oder Nutzer melden „mein WLAN ist zu schwach“ – hier ggf. temporär LTE-Stick als Ausweichlösung anbieten, bis Netz ausgebaut ist.

Tag 76–85: Nacharbeiten und alte Anlage abschalten – Sobald alle Mitarbeiter migriert sind und die neue Lösung stabil läuft, kümmern Sie sich um die Dekonstruktion der Altumgebung. Sichern Sie die Konfiguration der alten PBX (für alle Fälle) und fahren Sie sie herunter. Kündigen Sie alte Telefonleitungen, um Kosten zu sparen – achten Sie auf Vertragslaufzeiten, damit nicht weiter Gebühren für ungenutzte Anschlüsse laufen. Entfernen Sie alte Telefone von den Schreibtischen (nachdem sichergestellt ist, dass niemand mehr darauf angewiesen ist). Gleichzeitig finalisieren Sie das Betriebskonzept für die neue Lösung: Dazu gehört, dass jetzt alle Monitoring-Alerts aktiv sind, dass Verantwortlichkeiten geklärt sind (siehe RACI unten) und dass das Helpdesk-Personal letzte offene Fragen geklärt hat.

Tag 86–90: Abnahme und Projektabschluss – Führen Sie einen Abnahmetest gegen die eingangs definierten Kriterien durch:

• Sprachqualität: Überprüfen Sie z. B. via CQD, ob die durchschnittlichen Qualitätswerte im grünen Bereich liegen und keine signifikanten Problemzonen mehr offen sind. Falls doch (z. B. ein bestimmter Standort hat anhaltend schlechte Werte), entscheiden Sie, ob das noch ein Showstopper ist oder ins „Operations-Improvement“ übergeben wird.
• Stabilität: Die Lösung sollte mindestens einige Wochen störungsfrei gelaufen sein. Alle wichtigen Komponenten (SBCs, Netz, Microsoft-Cloud) zeigten keine kritischen Ausfälle. Ein geplantes Failover wurde getestet.
• Notrufe: Machen Sie einen letzten Testanruf pro Standort zur 112, um sicher zu sein, dass diese wirklich korrekt rausgehen (und loggen Sie diese Tests).
• CLIP/CLIR: Überprüfen Sie stichprobenartig, ob die gewünschten Einstellungen greifen – z. B. ruft ein „anonymer“ Anschluss an und die Gegenstelle sieht „Unbekannt“; ein Hotline-Agent ruft extern an und die Gegenstelle sieht die Hauptnummer.
• Benutzerakzeptanz: Holen Sie Feedback ein, z. B. via kurze Umfrage. Ziel: Die Mehrheit der Nutzer kommt zurecht und Probleme wurden behoben oder sind adressiert.

Wenn alle Kriterien erfüllt sind, lässt die Projektleitung die Abnahme durch den Auftraggeber (oft IT-Leiter oder Sponsor) erklären. Das Projekt geht damit formal in den Produktivbetrieb über und die Betriebsverantwortung wird vollständig an das Operations-Team übergeben.

Rollen und Verantwortlichkeiten (RACI): Abschließend ein Überblick, wer im Laufe des Projekts und im Betrieb welche Verantwortung trägt:

Tabelle 5: RACI-Matrix für Einführung und Betrieb

Legende: R = ausführend verantwortlich (Responsible), A = gesamthaft verantwortlich (Accountable), C = konsultiert (Consulted), I = zu informieren (Informed). Man sieht z. B., dass während des Projekts der Projektleiter federführend (A) ist, während im Betrieb viele Aufgaben an den UC-Admin und das Service Desk übergehen.

Betriebshandbuch und Abnahmekriterien

Vor dem Abschluss sollte ein Betriebshandbuch erstellt werden, das alle wichtigen Informationen für den laufenden Betrieb zusammenfasst. Typische Inhalte:

• Systemübersicht: Diagramm der neuen Telefonie-Topologie (Teams-Tenant, SBC-Standorte, Trunk, Netzwerkanbindung), Auflistung aller Komponenten (SBC-Server, Zertifikate mit Gültigkeit, verwendete Domains/FQDNs).
• Konfigurationseinstellungen: Dokumentation der eingerichteten Voice-Routing-Policies, Dial Plans (inkl. aller Normalisierungsregeln), Resource Accounts (Auto Attendants, Call Queues) mit Beschreibung ihrer Funktion, zugewiesene Rufnummern etc. Ebenso ggf. Screenshots der Teams-Einstellungen, damit im Fehlerfall nachvollziehbar ist, was eingestellt war.
• Nummernplan: Übersicht aller Rufnummern im Unternehmen, welche davon in Teams aktiv sind, zu welchem Standort sie gehören und ggf. Besonderheiten (ELINs, Faxnummern, Sonderdurchwahlen). Auch eine Liste portierter Nummern und deren früherer Provider ist hilfreich.
• Betriebsprozesse: Schritt-für-Schritt-Anleitungen für häufige Aufgaben:
• Benutzer einrichten: z. B. „Neuer Mitarbeiter → E5-Lizenz + Phone-Lizenz zuweisen, freie Durchwahl aus Liste nehmen, in Teams Admin dem User als LineURI +E.164 eintragen, Nutzer ggf. Gruppen zuweisen (Call Queue etc.)“.
• Nummern portieren/hinzufügen: Prozess, wie neue Rufnummern beim Carrier bestellt, portiert und im Teams Tenant eingepflegt werden. Verantwortlichkeiten und Vorlaufzeiten angeben.
• Änderung von Dial Plan/Policy: Wer darf das anstoßen, Freigabeprozess (z. B. Compliance muss abnicken, wenn CLIR für jemanden aktiviert wird).
• SBC-Wartung: z. B. „Quartalsweise SBC-Software-Update einspielen (Change-Prozess XY folgen), Zertifikaterneuerung jährlich im April – Anleitung beiligend“.
• Störungsbehebung: z. B. „Bei Anrufstörung zuerst Teams-Dienststatus im Admin Center prüfen, dann SBC-Status (WebGUI oder Ping). Wenn SBC down, Neustartskript ausführen; wenn Trunk gestört, bei Provider Ticket eröffnen unter Angabe Kundennr. …“ – solche Playbooks helfen im Ernstfall.
• Notfallkonzept: Was tun bei Komplettausfall? (z. B. „Wenn Microsoft Teams Cloud down: Geschäftsleitung informiert Nutzer, in dringenden Fällen Firmenhandys nutzen, in 1 h erneut Lage prüfen“; oder „Wenn SBC ausfällt: Provider routet eingehende Anrufe auf Mobilnummer X um“ – solche Arrangements, falls vorhanden, sollten hier beschrieben werden).
• Kontakte & Verträge: Liste wichtiger Ansprechpartner (Provider-NOC-Hotline, Microsoft Premier Support ID, SBC-Hersteller-Support mit Kundennummer, interne 2nd-Level-Kontakte). Dazu die Laufzeiten der Carrier-Verträge, damit man rechtzeitig verlängert oder kündigt.
• Compliance & Policies: Kopie oder Verweis auf die geltende Betriebsvereinbarung/Policy zur Telefonienutzung (wann darf was aufgezeichnet werden, welche Daten werden geloggt, etc.), damit der Betrieb dies mit berücksichtigt.
• Änderungshistorie: Versionierung des Handbuchs und Protokoll, wann größere Änderungen an der Konfiguration vorgenommen wurden (z. B. „Okt 2025: neue Dial-Plan-Regel für 5-stellige Durchwahlen hinzugefügt“).

Abnahmekriterien: Diese wurden im Planungsstadium festgelegt und sollten am Projektende überprüft werden. Typische Kriterien:

• Funktional: „100 % der bisherigen PBX-Funktionen abgebildet oder bewusst außer Betrieb genommen“ – d. h. niemand vermisst eine Kernfunktion. Notrufe funktionieren nachweislich, Gruppenrufe, Vermitteln etc. laut Testkatalog.
• Qualität: „Sprachqualität im Mittel besser oder gleich wie vorher“ – subjektiv via Mitarbeiterbefragung oder objektiv via MOS-Werte. Keine systematischen Aussetzer.
• Zuverlässigkeit: „Keine gravierenden Ausfälle über X Wochen; Redundanz erfolgreich erprobt“.
• User-Zufriedenheit: „> 90 % der Nutzer kommen mit dem neuen System klar“ (evtl. gemessen über Umfrage oder anhand weniger Supporttickets nach 4 Wochen).
• Projektziele erreicht: z. B. Kosteneinsparungen realisiert (wenn das ein Ziel war, etwa Wegfall PBX-Wartungskosten), oder verbesserte Mobilität erreicht (Home-Office-Nutzer sind voll angebunden, was vorher Problem war).
• Compliance-Einhaltung: Audit durch Datenschutzbeauftragten ohne Beanstandung; alle Policies implementiert.

Sind diese Punkte erfüllt, kann das Projekt als Erfolg gewertet werden. Wichtig ist, die wenigen offenen To-dos (es gibt immer Kleinigkeiten) in den Regelbetrieb zu übergeben – mit klarer Zuständigkeit. Damit endet die Einführungsphase – nun gilt es, den kontinuierlichen Betrieb sicherzustellen und das System bei Bedarf weiter zu optimieren. Die hier zusammengestellten Checklisten und Tabellen dienen dem operativen Team als Nachschlagewerk, um auch zukünftig den hohen Standard an Verfügbarkeit und Qualität zu halten.

Glossar

Zum Abschluss noch ein Glossar wichtiger Fachbegriffe und Abkürzungen:

Damit ist das Glossar und unser umfassender Leitfaden abgeschlossen. Mit diesem Wissen und den strukturierten Hilfsmitteln (Tabellen, Checklisten) ist Ihr Unternehmen gut gerüstet, Microsoft Teams erfolgreich als VoIP-Lösung im Enterprise-Umfeld einzuführen und zu betreiben. Viel Erfolg dabei!

Weitere Beiträge zum Thema SharePoint und Teams