Telefonie mit Microsoft Teams – Architektur, Umsetzung, Betrieb (mit anynode als SBC)

Management Summary

• Integrierte Kommunikation: Microsoft Teams-Telefonie ermöglicht die nahtlose Einbindung von Festnetztelefonie in die Kollaborationsplattform. Unternehmen profitieren von ortsunabhängiger Erreichbarkeit ihrer Mitarbeiter, vereinheitlichten Kommunikationswegen und einfacher Skalierbarkeit – ideal für Homeoffice und verteilte Teams.
• Verschiedene Anbindungsmodelle: Für den PSTN-Zugang stehen Microsoft Calling Plans, Operator Connect, Direct Routing und Teams Phone Mobile zur Auswahl. Jedes Modell hat spezifische Stärken: Calling Plans für schnellen Start (ohne eigene Infrastruktur), Operator Connect für carrier-geführten Service, Direct Routing für maximale Flexibilität mit eigenem SBC (z. B. anynode) und Teams Phone Mobile für die Integration mobiler Rufnummern in Teams.
• Rolle des SBC (z. B. anynode): Im Direct Routing fungiert ein Session Border Controller als Bindeglied zwischen Teams und Telefonnetz bzw. bestehender TK-Anlage. Der SBC sorgt für Protokollübersetzung, Sicherheit (verschlüsselte Verbindung, Firewall-Integration) und ermöglicht kundenspezifische Routing- und Integrationslogik. anynode als Software-SBC kann flexibel on-premises, im Rechenzentrum oder in der Cloud betrieben werden.
• Typische Architekturvarianten: Szenarien reichen vom Einzelstandort (SBC am Hauptsitz, alle Nutzer über diesen angebunden) bis zum verteilten Multisite-Betrieb (mehrere SBCs für D/A/CH-Standorte, Integration von Legacy-TK-Anlagen in Hybridumgebungen). Entwurf und Dimensionierung der Architektur richten sich nach Unternehmensgröße, Standorten, vorhandener Infrastruktur und Ausfalltoleranz-Anforderungen.
• Netzwerk- und Sicherheitsanforderungen: Teams-Telefonie setzt auf durchgängige Verschlüsselung – Signalisierung per mTLS (mutual TLS mit Zertifikaten) und Medien per SRTP. Firewalls müssen bestimmte FQDNs und Ports (z. B. SIP 5061/TLS, UDP 3478+ Medienports) erlauben. Aktuelle TLS-Versionen und sichere Cipher-Suiten sind vorgeschrieben. QoS-Konfiguration (DSCP-Markierungen für Audio/Video/Sharing) stellt sicher, dass Sprachverkehr Priorität hat. NAT-Funktionen wie SIP-ALG sind zu deaktivieren, um Signalstörungen zu vermeiden.
• Notrufkonzept und Sicherheit: Bei Telefonie über Teams sind rechtliche Notrufanforderungen zu erfüllen. Es braucht ein Konzept, das Standortinformationen zuverlässig übermittelt und gewährleistet, dass 112/110 jederzeit erreichbar sind – auch für nomadische Nutzer und im Homeoffice. Spezielle SBC-Konfigurationen (ELIN-Nummern) und Teams-Einstellungen (Netzwerk-Standortzuordnung) ermöglichen, dass ein Notruf stets beim örtlich zuständigen PSAP (Leitstelle) ankommt. Ergänzend sind organisatorische Maßnahmen (Mitarbeiterschulung, Notfalltelefone in Büros) erforderlich, um die Sicherheit zu erhöhen.
• Projektfahrplan: Die Einführung von Teams-Telefonie erfolgt idealerweise in Phasen. Zunächst werden Anforderungen erhoben und ein Zieldesign erstellt (inkl. Nummernplan und SBC-Topologie). Es folgt ein Pilotbetrieb mit ausgewählten Nutzern oder Standorten, um Einstellungen und Qualität zu verifizieren. Anschließend erfolgt die schrittweise Migration (Portierung von Rufnummern, Umschalten der Standorte), begleitet von Schulungen und Kommunikation. Ein strukturierter 30/60/90-Tage-Plan hilft, alle Aufgaben im Zeitplan zu halten.
• Betrieb und Support: Im laufenden Betrieb fallen Überwachungs- und Wartungsaufgaben an. Das Admin-Team nutzt Tools wie das Teams Admin Center, Call Quality Dashboard (CQD) sowie SBC-Monitoring (anynode-Dashboard, Logs) zur Qualitätssicherung. Typische KPIs (z. B. Paketverlust, Latenz, Auslastung) werden kontinuierlich überwacht. Bei Störungen kommen definierte Playbooks zum Einsatz, z. B. für Einweg-Audio, ausbleibende Rufsignalisierung oder Notruf-Probleme.
• Kostenblöcke: Bei der Wirtschaftlichkeitsbetrachtung zeigen sich mehrere Kostenkategorien: Microsoft-Lizenzen (insbesondere Teams Phone Lizenz pro Nutzer, ggf. Calling Plan Gebühren), SBC-Bereitstellung (Softwarelizenzen, VM-Hosting oder Appliance), Carrier-Kosten (SIP-Trunk Grundgebühren und Verbindungsentgelte) sowie Betriebskosten (Personalkapazität für Administration, ggf. Dienstleister-Support). Konkrete Preise variieren – entscheidend ist, dass Teams-Telefonie oft bestehende TK-Kosten ablöst und durch höhere Flexibilität sowie Zusammenführung der Kommunikation qualitativen Mehrwert bietet.
• Risiken und Gegenmaßnahmen: Mögliche Risiken bei Teams-Telefonie sind z. B. Sprachqualitätsprobleme (durch unzureichende Bandbreite oder QoS – Gegenmaßnahme: Netzwerkoptimierung, Monitoring), Ausfall der Internetverbindung (Gegenmaßnahme: Redundante Anbindung, Fallback auf Mobilnetz für Notrufe), Fehlkonfigurationen (Gegenmaßnahme: Change-Management mit Tests, vier-Augen-Prinzip) oder Regelverstöße bei Notrufen (Gegenmaßnahme: regelmäßige Notruftests, Schulung, klare Verantwortlichkeiten). Durch proaktives Risikomanagement und ein solides Architektur- und Betriebsdesign lassen sich diese Risiken minimieren.

Grundlagen: Teams-Telefonie im Überblick

Wichtige Begriffe und Technologien

• PSTN (Public Switched Telephone Network): Öffentliches Telefonnetz für klassische Festnetz- und Mobiltelefonie. Teams-Telefonie verbindet auf verschiedenen Wegen mit dem PSTN, um externe Rufnummern anzurufen oder erreichbar zu sein.
• SIP (Session Initiation Protocol): Standardprotokoll zur Steuerung von Telefonieverbindungen (Signalisierung). Teams verwendet SIP im Kern (speziell im Direct Routing) für die Kommunikation zwischen Microsoft-Cloud und dem SBC.
• RTP/SRTP (Real-Time Protocol / Secure RTP): Protokoll zur Übertragung von Audio- und Videodaten in Echtzeit. SRTP ist die verschlüsselte Variante (Secure RTP) und bei Teams verpflichtend, damit Gespräche abhörsicher über das Internet geführt werden.
• SBC (Session Border Controller): Netzwerkkomponente zur Kopplung von Telefoniesystemen. Ein SBC kontrolliert und sichert SIP/RTP-Verbindungen zwischen unterschiedlichen Netzen. In Teams Direct Routing stellt der SBC die Verbindung zwischen Microsoft Teams und dem PSTN oder lokalen Telefonanlagen her, übersetzt Protokolle und gewährleistet Sicherheit (z. B. Firewall-Funktion, Verschlüsselung).
• Direct Routing: Betriebsmodell, bei dem der Kunde einen eigenen SBC mit Microsoft Teams verbindet. Nutzer mit Teams Phone-Lizenz können so über einen beliebigen Telefonanbieter telefonieren oder bestehende TK-Anlagen anbinden. Bietet höchste Flexibilität (freie Carrier-Wahl, Integration von Dritt-Systemen), erfordert jedoch eigenes Know-how und Infrastruktur (z. B. anynode-SBC).
• Operator Connect: Betriebsmodell, bei dem ein zertifizierter Telefonie-Provider (Operator) die Anbindung an Teams in der Cloud bereitstellt. Ohne eigenen SBC erhalten Unternehmen PSTN-Zugänge direkt via Partner im Teams Admin Center. Dies reduziert administrativen Aufwand – der Operator verwaltet die SIP-Infrastruktur – bietet aber weniger individuelle Anpassungsmöglichkeiten als Direct Routing.
• Calling Plan (Microsoft Anrufpläne): Von Microsoft angebotene PSTN-Telefonie aus der Microsoft 365 Cloud. Hier übernimmt Microsoft selbst die Rolle des Telefonnetzbetreibers. Rufnummern und Gesprächsminuten werden direkt von Microsoft bereitgestellt. Dies eignet sich für einfache Anforderungen und schnelle Inbetriebnahme, ist aber geografisch auf bestimmte Länder beschränkt und weniger flexibel bei Sonderanforderungen.
• Teams Phone / Telefoniesystem: Lizenzkomponente in Microsoft 365, die Benutzer für Telefonie in Teams berechtigt. Früher als Phone System bekannt. Diese Funktionalität (in E5 enthalten oder als Add-on z. B. Teams Phone Standard lizenzierbar) ermöglicht erst das Durchführen und Empfangen von PSTN-Anrufen in Teams.
• Media Bypass (Medienumgehung): Option im Direct Routing, bei der Medienströme (Audio/Video) bei passenden Bedingungen direkt zwischen Teams-Client und SBC fließen, anstatt über Microsofts Media Relays geleitet zu werden. Ziel: geringere Latenz und Bandbreitenoptimierung, insbesondere wenn SBC und Client im selben Netzwerk oder nahe beieinander sind. Voraussetzung ist, dass der SBC für den Client öffentlich erreichbar ist (ICE-Verfahren) und die Netzwerktopologie passt.
• ICE, STUN, TURN: Mechanismen zur Medienverbindung in NAT-Umgebungen. ICE (Interactive Connectivity Establishment) versucht, die beste Direktverbindung zwischen Endpunkten auszuhandeln. STUN (Session Traversal Utilities for NAT) erlaubt einem Endgerät, seine public IP/Port herauszufinden, um eingehende Pakete zu empfangen. TURN (Traversal Using Relays) dient als Fallback, indem Medien über Relay-Server geschickt werden, falls direkte Verbindungen scheitern. Teams-Clients und SBCs nutzen ICE/STUN/TURN, um Audiostreams auch über komplexe Netzwerke hinweg aufzubauen.
• mTLS (mutual TLS): Beidseitig zertifikatsbasierte TLS-Verschlüsselung. Beim Direct Routing authentifizieren sich SBC und Microsoft Teams gegenseitig über TLS-Zertifikate. So wird sichergestellt, dass nur autorisierte SBCs mit dem Clouddienst verbunden sind. Der SBC benötigt hierfür ein öffentlich signiertes Zertifikat, das von Microsoft vertraut wird, und muss seinerseits Microsofts Zertifikate akzeptieren.
• SNI (Server Name Indication): TLS-Erweiterung, die es erlaubt, während des TLS-Handshakes den Zielhostnamen mitzuteilen. Im Kontext Teams Direct Routing bedeutet dies: Der SBC nennt beim Aufbau der TLS-Verbindung den Namen des Microsoft-Service (z. B. sip.pstnhub.microsoft.com). Microsoft kann so mehrere Dienste über dieselbe IP/Port unterscheiden. SNI ist für Direct Routing Verbindungen erforderlich, damit die Cloud die Anfragen dem richtigen Dienst (PSTN-Hub) zuordnet.

Betriebsmodelle für Teams-Telefonie

Microsoft Teams bietet mehrere Modelle, um Benutzer ans Telefonnetz anzubinden. Calling Plans, Operator Connect, Direct Routing und Teams Phone Mobile unterscheiden sich hinsichtlich Flexibilität, Aufwand und Anbieterrollen:

• Microsoft Calling Plans: Dabei wird Microsoft selbst zum Telefonie-Provider. Der einfachste Weg – Nummern und Flatrates werden im Microsoft 365 Admin Center gebucht, und Anrufe laufen vollständig über Microsofts Infrastruktur. Vorteile: kein SBC erforderlich, sehr schnelle Inbetriebnahme, Support aus einer Hand. Nachteile: nur in begrenzten Ländern verfügbar; eingeschränkte Tarifmodelle; keine Möglichkeit, Drittgeräte oder bestehende PBX einzubinden. Notrufe werden von Microsoft im jeweiligen Land gehandhabt (die hinterlegte Adresse der Nummer wird genutzt). Nummernportierung ist nur von/bis Microsoft möglich.
• Operator Connect: Hier schließt das Unternehmen einen Vertrag mit einem Operator-Connect-Partner (Telekommunikationsanbieter) und verknüpft diesen im Teams Admin Center. Der Anbieter stellt die Rufnummern bereit und routet Gespräche in die Microsoft-Cloud, ohne dass der Kunde eigene Telefonie-Hardware betreiben muss. Vorteile: weniger Administrationsaufwand (Provider kümmert sich um SIP-Trunks und SBCs), oft bessere Tarife oder lokale Präsenz als Microsoft; erweiterter Support (Provider + Microsoft). Nachteile: Abhängigkeit vom Partner (bei Entstörung, Änderungen); Integrationen (z. B. analoge Geräte, spezielle Routingregeln) nur innerhalb des vom Operator gebotenen Rahmens. Notrufe laufen über den Operator, der die Standortinformationen der bereitgestellten Nummer verwendet. Nummernportierung erfolgt zur/von der gewählten Telefongesellschaft.
• Direct Routing: Hier setzt das Unternehmen einen eigenen Session Border Controller ein (vor Ort, als virtuelle Maschine oder Cloud-Instanz), der via Internet mit Teams verbunden ist. Über diesen SBC können beliebige SIP-Trunks zu Telefonanbietern genutzt oder bestehende Telefonanlagen (z. B. eine lokale IP-PBX) angebunden werden. Vorteile: Maximale Flexibilität – freie Carrier-Wahl weltweit, Mischbetrieb verschiedener Provider, komplexe Routing-Szenarien (z. B. Least Cost Routing, Failover), Integration von Drittsystemen (Türsprechstellen, Analogadapter, Callcenter) und volle Kontrolle über Konfiguration. Zudem in Ländern nutzbar, wo Microsoft keine Calling Plans anbietet. Nachteile: Höherer Implementierungsaufwand – benötigt SBC-Infrastruktur, Fachwissen für Planung/Betrieb und eigenes Monitoring. Notrufe müssen eigenverantwortlich korrekt geroutet werden; der SBC kann Standort-bezogene Rufnummern präsentieren (z. B. via ELIN) – hierfür ist eine sorgfältige Planung erforderlich. Der Kunde ist selbst für Nummernportierung zu einem passenden SIP-Provider zuständig.
• Teams Phone Mobile (auch Operator Connect Mobile): Neuere Option, bei der mobilfunkbasierte Rufnummern direkt in Teams integriert werden. Ein Mobilfunkanbieter koppelt das Mobilfunknetz mit Microsoft Teams, sodass der Benutzer eine einzelne Mobilnummer hat, die sowohl im Handy-Netz als auch in Teams klingelt. Vorteile: Konvergenz von Mobilfunk und Teams – der Nutzer ist unter einer Nummer überall erreichbar, Anrufe können in Teams oder am Handy angenommen werden. Keine zusätzliche SIM-Karte nötig, Nutzung vorhandener Mobilverträge (bei unterstützten Providern). Kein eigener SBC nötig, da Provider die Kopplung übernimmt. Nachteile: Abhängig von einem Teams Phone Mobile Partner (verfügbare Carrier sind begrenzt), oft zunächst nur in bestimmten Ländern verfügbar. Weniger flexible Steuerungsmöglichkeiten (Carrier definiert vieles). Notrufe werden in der Regel über das Mobilfunknetz abgewickelt, was vorteilhaft für Standortinformationen ist – ruft man jedoch aus Teams mit der mobilen Nummer an, muss technisch sichergestellt sein, dass im Notfall der Mobilfunkkanal genutzt wird. Nummernportierung ist hier gleichbedeutend mit dem Mobilfunkvertrag.

Vergleich der Modelle

Nachstehende Tabelle stellt die vier Modelle gegenüber und beleuchtet Anwendungsfälle, Abhängigkeiten und weitere Kriterien:

Lizenzierung: Allen Modellen gemein ist, dass pro Benutzer eine Telefonielizenz notwendig ist (entweder in Form eines E5-Pakets oder als separater Teams Phone-Add-On bei E3/E1). Operator Connect und Direct Routing erfordern keine zusätzlichen Microsoft-Gesprächsminuten-Lizenzen, da die Gesprächskosten extern abgerechnet werden – im Gegensatz zu Calling Plans, wo man Minutenpakete von Microsoft erwirbt. Für Auto Attendants und Call Queues sind keine Extra-Lizenzen nötig, aber zugewiesene Service-Rufnummern können bei Direct Routing/Operator Connect vom Provider kommen oder bei Microsoft (gegen Gebühr) bezogen werden. Teams Phone Mobile benötigt ebenfalls die Telefonielizenz, zusätzlich natürlich einen entsprechenden Mobilfunktarif beim Partner. Audiokonferenz-Lizenzen werden separat betrachtet (für Einwahl in Meetings), spielen aber im reinen PSTN-Telefonie-Szenario keine Rolle, außer dass ohne Audiokonferenz-Lizenz abgehende Anrufe aus Meetings dann über Direct Routing laufen.

Lizenzbausteine auf Architekturebene

Im Gesamtzusammenhang einer Teams-Telefonie-Lösung sind verschiedene Lizenz-Bausteine relevant:

• Microsoft 365 Benutzerlizenzen: Grundlage ist pro Nutzer eine geeignete Microsoft 365 bzw. Office 365 Lizenz (z. B. E3/E5, Business Standard/Premium). E5 enthält bereits das „Telefoniesystem“, während z. B. E3, E1 oder F3 mit dem Zusatzlizenz Teams Phone Standard (vormals „Phone System“) erweitert werden müssen, um PSTN-Telefonie zu erlauben. Ohne diesen Baustein kann ein Nutzer in Teams nicht auf das PSTN routen.
• Sprachkanäle / Minutentarife: Bei Calling Plan-Nutzung benötigt man für jeden Benutzer oder gemeinsam einen entsprechenden Anrufplan (z. B. in Deutschland 120 Minuten pro User oder Flatrate). Bei Direct Routing und Operator Connect fallen stattdessen Vertragskosten beim Provider an (SIP-Trunk mit x gleichzeitigen Kanälen, Minutenpreise etc.). Teams Phone Mobile setzt einen Mobilfunkvertrag beim unterstützenden Anbieter voraus.
• SBC-Lizenzen: Im Direct Routing Szenario fallen Lizenzkosten für den SBC an. anynode z. B. wird nach Anzahl gleichzeitiger Sessions lizenziert. Die Lizenz sollte genügend Kanäle abdecken (typisch plant man ~10–15% der Nutzer als gleichzeitige Anrufe in Peak-Zeiten, je nach Telefonieverhalten). Neben Gesprächskanälen können Zusatzfeatures (Verschlüsselung, Failover, ELIN für Notruf etc.) entweder inklusive oder als separate Module lizenziert sein – bei anynode sind Grundfunktionen wie TLS/SRTP standardmäßig dabei, spezielle Funktionen wie ELIN (Notruf-Nummern-Mapping) erfordern eine zusätzliche Lizenzoption.
• Client-/Geräte-Lizenzen: Optional benötigen spezielle Geräte eigene Lizenzen: z. B. Common Area Phone Lizenzen für unbeaufsichtigte Telefone (Lobby-/Notfallapparate) oder Teams Rooms Lizenzen für Konferenzraumsysteme. Diese betreffen das Setup am Rande (für Notrufkonzepte mit Flurtelefonen sind Common-Area-Phone-Lizenzen relevant, wie im Notruf-Abschnitt beschrieben).
• Sonstige: Für die Nutzung von Voicemail (Cloud-Sprachnachrichten in Exchange) ist keine separate Lizenz nötig – es ist Teil der Telefonie-Funktion. Callqueues und Auto Attendants laufen ebenfalls lizenzfrei, erfordern aber Zuweisung von Rufnummern (bei Direct Routing über den SBC, ansonsten via Microsoft Service Numbers).

In der Architektur-Darstellung sollte klar sein, welcher Teil welche Lizenz voraussetzt: Benutzer benötigen M365 + Phone-System-Lizenz, der gewählte PSTN-Zugang kann zusätzliche Kosten verursachen (Microsoft oder Drittanbieter), und bei Direct Routing gehört der SBC (Hardware/VM + Softwarelizenz) zur Architektur.

Zielarchitekturen & Designprinzipien

Referenzarchitekturen von klein bis groß

Es gibt kein „one size fits all“ – je nach Unternehmensgröße und Anforderungen entstehen unterschiedliche Zielarchitekturen für Teams-Telefonie. Einige typische Referenzszenarien:

• Kleine Lösung (ein Standort, Cloud-PSTN): Für ein mittelständisches Unternehmen mit einem Hauptstandort und geringer Komplexität bietet sich entweder Calling Plan oder Operator Connect an. Architektur: rein Cloud-basiert, keine lokale Telefonanlage mehr. Netzwerkseitig sind nur eine gute Internetanbindung und Firewall-Konfiguration nötig. Diese Variante minimiert die Infrastruktur vor Ort (kein SBC nötig).
• Direct Routing für Einzelstandort: Wenn Calling Plans nicht verfügbar sind oder man einen vorhandenen Telefonanbieter weiter nutzen will, wird ein SBC on-premises am Hauptstandort platziert. Z. B. installiert die IT den anynode-SBC auf einem Windows-Server oder als VM. Der SBC hängt am Internet (für Teams) und parallel am SIP-Trunk des Providers oder an der alten TK-Anlage. Die Architektur bleibt übersichtlich: ein Standort – ein SBC – ein Trunk. Dieses Setup lässt sich auch in einer Cloud-VM realisieren (Azure/AWS), falls man keine lokale Serverhardware einsetzen möchte; wichtig ist in jedem Fall eine zuverlässige Netzwerkanbindung.
• Verteilte Standorte mit zentralem SBC: Unternehmen mit mehreren Niederlassungen (z. B. Filialen in verschiedenen Städten) können eine zentrale SBC-Instanz betreiben, über die alle Telefonie läuft. Beispielsweise wird anynode im zentralen Rechenzentrum gehostet; die Standorte verbinden sich über das WAN/Internet mit dem SBC (alle PSTN-Rufnummern liegen auf einem gemeinsamen Trunk oder auf mehreren Trunks am zentralen SBC). Vorteil: nur eine SBC-Plattform und Konfiguration, einfachere Wartung. Nachteil: Sprachverkehr der Außenstellen muss zum zentralen SBC geroutet werden – Bandbreite und Latenz des WAN müssen ausreichend sein. Auch Notrufe aus Zweigstellen erscheinen unter der zentralen Nummer, falls nicht speziell behandelt (hier könnte man für jeden Standort standort-spezifische Nummernblöcke über denselben SBC schicken, sofern der Provider das unterstützt).
• Verteilte SBCs pro Region/Land: In einer D/A/CH-Organisation mit hunderten von Mitarbeitern je Land ist es oft sinnvoll, pro Land eine eigene SBC-Instanz vorzusehen. Gründe: lokale Carrier-Anbindung (jede Landesgesellschaft behält ihren Telefonprovider), Notrufe mit lokalen Nummern, reduzierte Abhängigkeit vom WAN (jeder SBC bedient die lokalen User, Calls bleiben im Land). Die SBCs können logisch gekoppelt sein (z. B. gegenseitige Fallbacks), aber aus Teams-Sicht sind es separate PSTN-Gateways. So würden etwa ein anynode in Deutschland und ein anynode in der Schweiz betrieben, beide in der gleichen Tenant-Konfiguration registriert. Für die Benutzer wird anhand ihrer Nummern/Standorte die jeweils passende Route (deutscher oder schweizer Trunk) gewählt.
• Hybrid mit bestehender TK-Anlage: Viele größere Unternehmen migrieren schrittweise von einer On-Premises PBX zu Teams. In der Übergangszeit (oder dauerhaft bei bestimmten Funktionen) laufen Teams und die alte Telefonanlage parallel. Der SBC wird dann als Vermittler eingesetzt: Er verbindet auf einer Seite Teams (Cloud) und auf der anderen Seite die lokale PBX (z. B. via SIP oder ISDN). Anrufe zwischen einem Teams-Benutzer und einem noch auf der PBX befindlichen Apparat gehen über den SBC. Ebenso kann der SBC so eingerichtet werden, dass ausgehende PSTN-Anrufe teils noch über die PBX und deren Amtsleitungen gehen, und erst nach und nach alles Richtung Teams/Cloud umgestellt wird. Solche Hybrid-Architekturen erfordern sorgfältige Planung der Rufnummern und Routingregeln, sind aber durch Direct Routing gut unterstützt.

Diese Referenzarchitekturen sind Ausgangspunkte – real können Kombinationen entstehen (z. B. ein zentraler SBC plus kleine Survivability-Lösungen vor Ort). Designprinzipien wie KISS (Keep it simple) empfehlen, die Lösung so übersichtlich wie möglich zu halten: so wenige SBC-Instanzen wie nötig, klare Zuständigkeiten pro Standort, Standardisierung der Konfiguration über alle Regionen.

anynode als SBC – Rolle und Platzierung

Mit anynode als durchgängigem SBC-Beispiel lässt sich ein Großteil dieser Architekturen abbilden. anynode ist ein reiner Software-SBC, der auf Windows- oder Linux-Betriebssystemen läuft und offiziell für Microsoft Teams Direct Routing zertifiziert ist. Bei der Platzierung des SBC sind folgende Optionen gegeben:

• On-Premises (lokal im Unternehmen): anynode kann auf einem physischen Server oder einer VM im Unternehmensnetz installiert werden. Typisch wäre ein virtualisierter Windows-Server im Rechenzentrum des Unternehmens. Vorteile: volle Kontrolle, keine Abhängigkeit von Cloud-VMs, Voice bleibt lokal wenn möglich (Media Bypass im Standort). Anforderungen: Eine öffentliche IP-Adresse (oder NAT mit Port-Forwarding) und ein öffentlicher DNS-Name für den SBC sind nötig, damit Microsoft Teams ihn erreichen kann.
• In der Cloud (z. B. Azure VM): Alternativ wird anynode in einer Cloud-Umgebung betrieben. Ein Azure-VM-Image mit Windows oder Linux kann den SBC hosten; TE-Systems (Hersteller anynode) bietet sogar vorkonfigurierte Azure-Vorlagen an. Vorteil: hohe Verfügbarkeit der Infrastruktur, schnelle Skalierbarkeit, keine lokale Hardware. Die Cloud-VM sollte jedoch möglichst in der gleichen Region sein wie die Nutzer oder der Trunk, um Latenz zu minimieren (z. B. Azure Region EU West für einen europäischen Kunden). Achtung: Medienverkehr fließt dann vom Standort über Internet zum Cloud-SBC – QoS auf Internet ist begrenzt, also Bandbreite großzügig planen.
• Hybrid: mehrere SBCs verteilt: Man kann anynode-Instanzen kombinieren – z. B. einen on-prem SBC am Hauptsitz und einen in Azure als Redundanz. Microsoft Teams erlaubt die Konfiguration mehrerer SBCs im Tenant; die Routingregeln bestimmen, wann welcher genutzt wird (z. B. Primär/Fallback).

Wichtig für die Rolle des anynode-SBC in allen Platzierungen:

• Zertifikatsanforderungen: Der SBC benötigt ein öffentlich vertrauenswürdiges TLS-Zertifikat für seine FQDN (z. B. sbc.firma.de). Die Domain des SBC-FQDN muss in Office 365 als eigene Domain registriert sein. Das Zertifikat muss von einer CA stammen, die Microsoft akzeptiert (gängige CAs wie DigiCert, QuoVadis, GlobalSign etc.). anynode unterstützt die Verwendung von Zertifikaten aus dem Windows Zertifikatsspeicher oder per Dateien – in der Konfiguration wird das Zertifikat samt privatem Schlüssel eingebunden. Bei mehreren SBC-Instanzen kann man pro Instanz eigene FQDNs und Zertifikate verwenden oder ein Wildcard-Zertifikat (*.firma.de) nutzen, solange es den Anforderungen entspricht (Wildcard im SAN/CN wird unterstützt). Wichtig ist, dass der SBC bei TLS-Handshakes SNI präsentiert: anynode erlaubt die Konfiguration des TLS-SNI Namens, welcher mit dem Microsoft-Ziel (z. B. sip.pstnhub.microsoft.com) übereinstimmen muss.
• mTLS-Verbindung zu Microsoft: anynode kommuniziert mit dem Teams Direct Routing Service über mutual TLS auf Port 5061. Das heißt, nicht nur der SBC stellt ein Zertifikat bereit, sondern auch Microsoft – anynode muss die Microsoft-Seite als vertrauenswürdig anerkennen. Dazu bringt anynode standardmäßig die üblichen Root-Zertifikate mit, kann aber auch manuell mit den erforderlichen CA-Zertifikaten versorgt werden (z. B. wenn Microsoft die Zertifikatkette wechselt, muss der SBC ggf. aktualisiert werden).
• DNS und Namensauflösung: Der SBC benötigt zuverlässige DNS-Auflösung. anynode muss die Microsoft-Cloud-SIP-Domains (z. B. sip.pstnhub.microsoft.com) auflösen können, und umgekehrt muss der eigene SBC-FQDN im öffentlichen DNS auf die SBC-IP zeigen. In der Praxis empfiehlt sich ein Split-DNS Konzept: Intern kann der SBC sich selbst unter seinem Namen finden, extern zeigt der Name auf die Internet-IP. anynode selbst bietet keine integrierte DNS-Server-Funktion – er nutzt das OS. Daher: in Windows die richtigen DNS-Server eintragen (öffentliche Resolver oder firmeninterne mit Forwarding), bei Linux entsprechend.
• Signalisierung und Medienpfade: In Teams Direct Routing übernimmt Microsoft global verteilte SIP-Proxies und Medienprozessoren. anynode als SBC verbindet sich initial immer mit sip.pstnhub.microsoft.com (und Fallback auf sip2, sip3). Diese Namen werden über DNS zu regional nächsten IPs aufgelöst. Im SIP-Signalisierungsverkehr gilt: anynode öffnet einen TLS-Socket zu Microsoft und empfängt eingehende SIP-Requests von Microsoft ebenfalls über TLS. Medien (RTP/SRTP) fließen standardmäßig zwischen anynode und dem Teams Media Processor (ebenfalls in Microsofts Cloud, IP-Ranges vorgegeben). Bei aktiviertem Media Bypass kann der Medienpfad direkt zwischen anynode und dem Teams-Client erfolgen (dann sind ICE-Verhandlungen zwischen Client und SBC aktiv, und der SBC erhält Verbindungsversuche direkt von der Client-IP).
• Media Bypass mit anynode: anynode unterstützt Media Bypass vollständig. Dazu agiert anynode als ICE-lite Endpunkt – d. h. er antwortet auf STUN-Anfragen von Teams-Clients und versucht, eine direkte UDP-Verbindung aufzubauen. In der anynode-Konfiguration lässt sich je Trunk (hier der Microsoft-Teams-Trunk) einstellen, ob Media Bypass erlaubt ist. Voraussetzung: Der SBC ist öffentlich erreichbar auf seinen Medienports, und die Clients können diese Erreichbarkeit via Internet nutzen. In einer Standort-SBC-Situation (SBC und Clients im selben LAN) lässt sich mit Local Media Optimization arbeiten, damit der Medienstrom lokal bleibt. In cloud-gehosteten SBC-Szenarien bringt Media Bypass weniger Latenzvorteil, da Client und SBC meist nicht im selben LAN sind – hier kann man abwägen, ob man Bypass aktiviert.

Hochverfügbarkeit und Redundanz

Telefonie ist oft geschäftskritisch, daher müssen Architektur und SBC-Design Hochverfügbarkeitsanforderungen gerecht werden. Mehrere Ebenen der Redundanz sind zu beachten:

• SBC-Redundanz (High Availability): anynode selbst kann in Cluster-Konfigurationen betrieben werden. Gängig ist ein Hot-Standby-Verbund (aktiv/passiv): Zwei anynode-Instanzen werden identisch konfiguriert, eine übernimmt aktiv den Betrieb, die zweite steht bereit. Über eine Heartbeat-Verbindung überwachen sie sich gegenseitig. Fällt die primäre Instanz aus (Server-Ausfall, Dienst abgestürzt), übernimmt die sekundäre automatisch – optional mittels einer Floating IP, die im Ausfall auf den zweiten Knoten schwenkt. Aus Sicht von Microsoft Teams bleibt der SBC erreichbar (gleicher FQDN/IP), laufende Gespräche brechen allerdings ab bei Failover, aber neue Verbindungen gelingen sofort wieder. Alternativ lässt sich anynode auch aktiv/aktiv betreiben, indem man zwei getrennte SBC-Einträge in Teams anlegt (z. B. sbc1.firma.de und sbc2.firma.de) und die Last verteilt. Teams verteilt eingehende Anrufe auf alle registrierten SBCs (Round-Robin pro Anruf oder basierend auf Routenpriorität). Ausgehend kann per Voice-Routing-Policy ein Failover definiert werden (Liste von Gateways). Aktiv/aktiv erfordert mehr Planungsaufwand (Synchronisation der Konfigurationen auf beiden SBCs, ggf. manuelles Verschieben von Nutzern bei Teilausfall), bietet aber Lastverteilung und geo-redundante Platzierung. anynode erleichtert die Konfig-Synchronisierung via Export/Import-Profile; bei Hot-Standby erfolgt dies automatisch via Cluster-Service.
• Geo-Redundanz: In multinationalen Umgebungen möchte man Ausfallsicherheit auch bei Standortkatastrophen. Dies erreicht man durch physikalisch getrennte SBC-Standorte (z. B. ein SBC in Frankfurt, einer in Zürich). Diese könnten als getrennte Gateways im Tenant eingetragen werden; fällt einer aus (z. B. Frankfurt Rechenzentrum offline), ließe sich der andere als Fallback nutzen. Teams hat einen eigenen SIP-Failover-Mechanismus: Erkennt die Microsoft-Cloud, dass ein SBC nicht reagiert (z. B. auf OPTIONS-Pings), werden Anrufe dorthin nicht mehr versucht. Ebenso kann anynode bei ausgehenden Calls an Microsoft erkennen, wenn keine Antwort kommt, und auf einen anderen Proxy wechseln (dank FQDN sip.pstnhub gibt es bereits Drei-Fach-Redundanz global). Zwischen SBCs kann man Routing-Fallbacks einrichten: etwa hat der DE-SBC einen sekundären Routeintrag zum CH-SBC für bestimmte Nummern, falls er selbst den Trunk nicht nutzen kann.
• Trunk-Redundanz: Neben dem SBC selbst ist auch die Telefonnetz-Anbindung abzusichern. Idealerweise werden zwei SIP-Providern oder zwei getrennte Trunk-Instanzen vom gleichen Provider verwendet. anynode unterstützt das Load-Balancing und Failover zwischen mehreren Carriers: Eingehende Rufe können von mehreren Trunks angenommen werden; ausgehend kann eine Prioritätenliste konfiguriert werden. Wenn z. B. der primäre SIP-Trunk keine freie Leitung hat oder nicht erreichbar ist, versucht anynode automatisch den nächsten (er sendet bei trunkseitigem Fehler einen SIP-503 „Service Unavailable“ oder erhält ihn, und wechselt dann Route). Manche SIP-Provider arbeiten auch mit Redirects (SIP 302) auf alternative Gateways – anynode kann solche Weiterleitungs-Informationen auswerten und folgen.
• DNS-Strategien: Verfügbarkeit wird auch durch DNS unterstützt. Microsoft liefert für den Teams-Cloud-Part drei FQDNs (sip.pstnhub.com, sip2…, sip3…) – der SBC muss alle drei nacheinander probieren, um bei einem regionalen Ausfall weiterzukommen. Umgekehrt kann man den eigenen SBC-FQDN mit mehreren A-Records eintragen, die auf verschiedene SBC-IPs zeigen (Round-Robin DNS). Teams versucht dann ggf. abwechselnd die IPs. Allerdings reagieren Clients und die Cloud in Echtzeit eher auf SIP-Level-Fehler als auf DNS, daher werden häufig Options-Pings / Keep-Alives genutzt: Microsoft sendet regelmäßig SIP OPTIONS an den SBC, um die Verfügbarkeit zu prüfen. anynode beantwortet diese. Ebenso kann anynode zu konfigurierten Endpunkten (Trunks, andere SBCs) Options-Pakete senden, um deren Status zu überwachen. Diese Mechanismen ermöglichen schnelles Umschalten im Fehlerfall (<30s Erkennungszeit).

Zusammengefasst sollte das SBC-Design Single Points of Failure eliminieren: Redundante SBCs (Cluster oder getrennt), redundante SIP-Routen, Stromversorgung (USV für SBC-Server) und Netzwerk (zwei Internetleitungen, wenn möglich) sind Komponenten eines hochverfügbaren Gesamtsystems.

SBC-Designvarianten im Vergleich

In der folgenden Tabelle werden einige typische SBC-Architekturvarianten mit ihren Eigenschaften gegenübergestellt:

Anm.: Latenz-Zielwerte beziehen sich auf One-Way Verzögerung. Für klare Sprache gilt grob: ≤100 ms sehr gut, 100–200 ms akzeptabel, >200 ms deutlich verzögert – daher sollten interne Architekturlatenzen möglichst gering gehalten werden.

Netz- und Sicherheitsanforderungen

Netzwerk- und Sicherheitsgrundlagen

Damit Teams-Telefonie reibungslos funktioniert, müssen Netzwerk und Sicherheitseinstellungen sorgfältig aufgesetzt werden. Einige essenzielle Anforderungen:

• FQDNs und IP-Adressen: Microsoft Teams Direct Routing nutzt fest definierte Fully Qualified Domain Names als Kommunikationsendpunkte. Für den Signalisierungsverkehr müssen z. B. sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, sip3.pstnhub.microsoft.com erreichbar sein. Diese entsprechen global verteilten IP-Adressbereichen (in Europa z. B. 52.112.0.0/14 und 52.122.0.0/15 für Signalisierung). Zusätzlich nutzen die Medien (Audio/Video) eigene IP-Ranges (z. B. 52.112.0.0/14 und 52.120.0.0/14 für Medienprozessoren weltweit). Firewalls im Unternehmen müssen ausgehend und eingehend Verbindungen zu diesen Adressbereichen zulassen.
• Ports und Protokolle: Alle relevanten Ports sind zu öffnen. SIP-Signalisierung läuft über TLS auf Port 5061 (Standard für Teams-SBC-Kopplung). Auf Seiten des SBC ist 5061 typischerweise der Listening-Port; aus Teams-Sicht wird von zufälligen hohen Ports (1024–65535) nach 5061 des SBC gesendet. Umgekehrt schickt der SBC von einem beliebigen Port an 5061 der Microsoft SIP-Proxies. SRTP-Medienverkehr nutzt UDP-Ports im Bereich 3478–3481 sowie 49152–53247. Teams-Clients und -Server verwenden 3478–3481 UDP auch für STUN/TURN (ICE Verhandlungen). Der SBC sollte diese Ports auf Empfang offen haben, damit er Medien von der Cloud oder direkt von Clients empfangen kann. (Hinweis: Bei Media Bypass muss der SBC Medienverkehr potentiell von beliebigen externen Clients akzeptieren – somit sind seine RTP-Ports im Internet offen, was aber durch SRTP verschlüsselt und via ICE gesteuert wird. Eine Restriktion auf Microsoft-IP-Ranges ist dann nicht immer möglich, da Clients von überall kommen.)
• TLS-Versionen und Cipher Suites: Microsoft Teams verlangt TLS 1.2 als Mindeststandard für die SIP-Verbindung. Der SBC (anynode) muss also TLS 1.2 unterstützen (was er tut) und sollte möglichst auch TLS 1.3 beherrschen, sobald Microsoft dies unterstützt. In anynode lassen sich TLS-Profile konfigurieren – man sollte unsichere Ciphers (3DES, RC4 etc.) deaktivieren und nur starke Cipher Suites aktiv lassen (z. B. solche mit AES256 oder CHACHA20 und Perfect Forward Secrecy). Microsoft veröffentlicht die Liste der unterstützten Cipher; typischerweise Standard SChannel/OpenSSL-Defaults sind ausreichend.
• Zertifikatskette und Namensauflösung: Der Zertifikat-Trust ist kritisch: Das vom SBC präsentierte Zertifikat muss die gesamte gültige Kette (inkl. Intermediate CA) mitliefern. In anynode importiert man daher neben dem Serverzertifikat auch Zwischenzertifikate, damit der entfernte Partner (Microsoft) das Zertifikat bis zur Root-CA prüfen kann. Der SBC seinerseits muss Microsofts Zertifikate vertrauen – üblicherweise kein Problem, da Microsoft CA-Zertifikate im öffentlichen Trust-Store nutzt. Dennoch sollte man sicherstellen, dass die Windows- oder Linux-Truststore aktuell sind. Auch CRL/OCSP-Erreichbarkeit spielt eine Rolle: Firewalls dürfen Certificate Revocation Lists Abrufe nicht blockieren, sonst können TLS-Verbindungen verzögert starten.
• Zeit/NTP-Synchronisation: Sowohl für die Gültigkeit von Zertifikaten als auch für Log-Analyse ist es wichtig, dass der SBC und andere Komponenten die exakte Uhrzeit haben. Ein NTP-Zeitabgleich (z. B. mit pool.ntp.org oder internen Zeitservern) sollte auf allen Servern aktiviert sein. Abweichungen können zu Zertifikats-Validierungsfehlern führen (z. B. falls Systemzeit in die Zukunft geht, hält TLS das Zertifikat für noch nicht gültig oder abgelaufen).
• Authentifizierung und Zugriffssteuerung: Der Zugang zum SBC-Admin-Interface (z. B. anynode Manager oder WebGUI) muss abgesichert sein – am besten nur aus dem internen Netz oder via VPN zugänglich, mit starken Passwörtern. Teams selbst authentifiziert den SBC über das Zertifikat, eine separate Anmeldung gibt es hier nicht. Auf der Trunk-Seite (zum Carrier) kann es aber IP-Auth oder SIP-Registrierungen geben, die ebenso sicher verwahrt/konfiguriert sein müssen (Passwortverschlüsselung etc.).

NAT, Firewall und Quality of Service

Teams-Telefonie stellt auch spezielle Anforderungen an Firewalls und Router:

• NAT und SIP-ALG: Bei Einsatz von NAT (z. B. SBC in lokalem Netz hinter einer Firewall mit NAT) sollte keine SIP-ALG (Application Layer Gateway) aktiv sein. SIP-ALG versucht oft, SIP-Pakete zu „manipulieren“ (z. B. IP-Adressen in SIP-Headern anpassen), was mit den verschlüsselten TLS-Paketen von Teams gar nicht funktioniert und eher stört. Empfohlen ist, SIP-ALG auf Firewalls/Router zu deaktivieren, damit der TLS-Strom unbeeinflusst passiert. anynode selbst ist NAT-tauglich: man kann in der Konfiguration die externen IPs definieren, die er in SDP (Medienbeschreibung) melden soll, falls er hinter NAT ist.
• Firewall-Ports im Detail: Neben den SIP- und RTP-Ports muss man oft auch DNS (Port 53) öffnen, wenn der SBC externen DNS nutzt, sowie NTP (123 UDP) für Zeitsynchronisation. Wenn der SBC syslog/SNMP-Traps an ein zentrales Monitoring sendet, sind auch diese Protokolle freizugeben (typisch intern). Administrator-Zugriff (Remote Desktop, SSH oder anynode GUI) sollte auf definierte Management-Netze beschränkt werden.
• QoS – Priorisierung von Sprache: In lokalen Netzwerken (LAN/WAN) ist Quality of Service essentiell, damit Audio nicht unter Datei-Downloads & Co. leidet. Teams markiert ab Client ausgehende Pakete mit DSCP-Werten, sofern QoS aktiviert ist. Empfohlene Werte sind EF (46) für Audio, AF41 (34) für Video und AF21 (18) für Bildschirmfreigabe. Die Unternehmensswitches und -Router sollten diese DSCP-Tags respektieren und in entsprechende Prioritätswarteschlangen einsortieren. Auf dem Weg ins Internet gehen DSCP-Tags meist verloren, aber innerhalb der eigenen Umgebung – insbesondere zwischen Clients und SBC und zu einem MPLS-basierten SIP-Trunk – kann QoS enorm zur Stabilität beitragen. Praktisch heißt das: Netzwerkgeräte konfigurieren, dass DSCP 46 höchsten Vorrang erhält (Low-Latency-Queue), genügend Bandbreite reservieren (z. B. 30-40 kbps pro aktiver Audiostream, summiert mal Anzahl paralleler Calls plus Reserve).
• Bandwidth und Codec: Ein normaler G.711-Sprachkanal benötigt rund 80–100 kbps inkl. Overhead pro Richtung. Bei 50 gleichzeitigen Gesprächen sind also ~5 Mbps nur für Audio fällig – plus etwas Puffer. Video und Bildschirmfreigabe können je nach Nutzung mehr ziehen (ein 720p Video-Call kann 1-2 Mbps verbrauchen). Daher sollten Internet und WAN-Verbindungen hinreichend dimensioniert sein, um den gleichzeitigen Spitzenverkehr zu tragen. Für reine Telefonieprojekte rechnet man typischerweise mit 10% gleichzeitiger Call-Rate – bei 1000 Usern also ~100 gleichzeitige Anrufe, entsprechend ~10 Mbps Audio-Datenvolumen.
• Jitter und Paketverlust: Sprach ist sensitiv auf Jitter (Schwankungen in der Latenz) und Packet Loss. Idealerweise <30 ms Jitter und <1% Verlust. Der SBC und die Teams-Client haben Jitterpuffer, aber bei stark variierenden Laufzeiten gerät die Sprachwiedergabe ins Stottern. Netzwerkgeräte sollten so konfiguriert sein, dass Pufferüberläufe minimiert werden (QoS) und Pfade so kurz wie möglich sind. Packet Loss sollte im LAN/WAN praktisch 0% sein. Auf Internetstrecken können kleine Verluste auftreten, aber bereits 3-5% Verlust führen zu deutlich hörbaren Aussetzern. Monitoring (z. B. via CQD oder SBC-MOS-Werte) hilft, solche Werte im Blick zu behalten.
• Monitoring der Verbindungen: Es ist empfehlenswert, die Transportpfade aktiv zu überwachen. Z. B. kann man von der Firewall aus einen regelmäßigen Ping oder TLS-Handshake-Test zu den Microsoft SIP-FQDNs machen und die Latenz/Ausfälle loggen. Auch den SIP-Options-Heartbeat des SBC sollte man auswerten: anynode bietet Logging an, wenn Heartbeats ausbleiben. Zusätzlich sind Packet Captures ein Mittel zur Fehleranalyse – allerdings sind sie mit Vorsicht zu nutzen: Mitschnitte von RTP enthalten Sprachinhalte (personenbezogene Daten). Organisatorisch muss geregelt sein, in welchen Fällen und durch wen Pakete mitgehört werden dürfen. In der Regel werden PCAP-Mitschnitte nur im Rahmen des Supports und mit entsprechenden Freigaben gemacht. Tools wie Call Analytics liefern oft schon ausreichend Informationen (z. B. welche Seite Paketverlust hatte).

Zusammengefasst gilt: Sicherheit vorgehen, ohne die Telefonie zu beeinträchtigen. Verschlüsseln Sie konsequent (TLS/SRTP), erlauben Sie nur notwendige Zugriffe (Firewall-Regeln fein granuliert) und sorgen Sie parallel für die Qualität (QoS, genügend Bandbreite). So wird die Teams-Telefonie sicher und performant.

Firewall- und QoS-Anforderungen (Übersicht)

Eine tabellarische Übersicht wichtiger Freigaben und Einstellungen:

Hinweis: Die genauen IP-Adressbereiche sollten regelmäßig mit Microsofts Doku abgeglichen werden (s. „URLs/IP-Ranges für Office 365“), da Änderungen möglich sind. Ebenso liefern SIP-Provider ihre IP-Listen für die Firewall. Die QoS-Konfiguration betrifft primär interne Netzwerkausrüstung – im Internet kann man nicht auf DSCP vertrauen, aber interne Engpässe kann man so gut managen.

Checkliste: Security & Connectivity (für Planung und Prüfung)

• [ ] Zertifikate bereitgestellt: Ein gültiges, öffentliches Zertifikat (inkl. privatem Schlüssel) ist auf dem SBC installiert. Domain des Zertifikats stimmt mit SBC-FQDN überein; Zertifikatskette vollständig. Ablaufdatum geprüft (Reminder vor Ablauf).
• [ ] DNS-Auflösung gewährleistet: Der SBC kann die Microsoft- und Provider-FQDNs auflösen (DNS-Server erreichbar). Der SBC-FQDN ist extern im DNS auf die richtige IP eingetragen. Intern ggf. Split-DNS konfiguriert.
• [ ] Firewall-Regeln aktiv: Alle benötigten Ports und IP-Ranges sind in der Firewall freigeschaltet. Insbesondere Port 5061 TLS zu und von Microsoft Cloud, UDP-Medienports (3478, 50k+ Range) für SRTP. Keine unnötigen offenen Ports belassen.
• [ ] TLS-Sicherheit geprüft: TLS 1.2 ist auf dem SBC aktiviert, unsichere Protokolle deaktiviert. Cipher Suites entsprechen Best Practices. Der SBC vertraut Microsofts Root-CAs (aktuelle Zertifikatstore).
• [ ] NAT-Settings korrekt: Falls SBC hinter NAT, sind Portweiterleitungen eingerichtet (5061 auf SBC, UDP-RTP-Range auf SBC). SIP-ALG auf Router/Firewall ist ausgeschaltet. anynode „External IP“ Felder sind bei NAT korrekt befüllt, sodass SDP die Public IP enthält.
• [ ] QoS implementiert: DSCP-Markierung auf Clients via Teams-Richtlinie oder Gruppenrichtlinie aktiviert. Netzwerk-Switches und Router priorisieren DSCP 46 Traffic. Bandbreitenbudget reserviert (z. B. 20% des WAN für Voice). Monitoring (NetFlow/SNMP) eingerichtet, um Latenz/Jitter zu beobachten.
• [ ] Zeitserver & Sync: SBC-Server synchronisiert Zeit automatisch (NTP-Dienste laufen, Logs zeigen Erfolg). Zeitzone korrekt (Europe/Berlin oder Zürich etc.).
• [ ] Monitoring/Alerts aktiv: Regelmäßige Tests (Ping/Telnet auf 5061) von der Firewall/Monitoring-Server zu Microsoft-Endpunkten. anynode-Logging so konfiguriert, dass Verbindungsabbrüche oder Registrierungsprobleme Alarm schlagen (E-Mail/SNMP-Trap an Admin bei Ausfall).
• [ ] Dokumentation & Verantwortlichkeiten: Alle offenen Ports, freigegebenen IPs und Zertifikatsinfos sind dokumentiert. Security- und Netzwerkteams sind informiert, wer bei Änderungen (z. B. neue IP-Ranges von MS) verantwortlich ist, diese umzusetzen.

Nummernkonzept & Wählpläne

Rufnummernstrategie und Anzeige (Nummernkonzept)

Ein durchdachtes Nummernkonzept ist Kern einer erfolgreichen Telefonie-Migration. Es regelt, welche Rufnummern in Teams verwendet und wie sie dargestellt werden:

• E.164-Nummernformat: Intern verwendet Teams konsequent das internationale Format (+Ländervorwahl Rufnummer). Es empfiehlt sich, alle Benutzer-Telefonnummern im Tenant nach E.164 zu konfigurieren (z. B. +49 89 12345 678). Das erleichtert Routing und Integration. Wählpläne (Dial Plans) können dann Nutzereingaben wie „08912345678“ in +498912345678 normalisieren.
• Geordnete Rufnummernblöcke: Falls möglich, sollte man Rufnummernblöcke zusammenhängend strukturieren, z. B. pro Standort oder Abteilung. Beispiel: Berliner Standort hat +49 30 98765-0 (Zentrale) und Durchwahlen -100 bis -399 für Mitarbeiter. Züricher Standort: +41 44 668 5-xxx etc. Diese Struktur erleichtert es, Regeln aufzusetzen (z. B. eingehende DDI-Zuordnung, ausgehende Präsentation per Standortnummer) und hilft den Mitarbeitern, interne Nummern zu erkennen.
• CLIP no screening: Dieser Begriff bezeichnet die Fähigkeit, eine andere Rufnummer als Absender zu übertragen als die, über die der Anruf technisch rausgeht – ohne dass der Netzbetreiber sie ersetzt. Für Unternehmen wichtig, wenn z. B. ein Anruf einer Nebenstelle immer die Zentrale anzeigen soll oder wenn man mit einer Standortnummer auftreten will. Im SIP-Umfeld geschieht dies über P-Asserted-Identity oder Remote-Party-ID Header. Teams selbst erlaubt standardmäßig, dass der primäre LineURI des Users übertragen wird. Will man eine alternative Nummer senden (z. B. ein Callcenter-Agent soll die Servicehotline-Nummer anzeigen), muss man entweder den Benutzer-LineURI auf diese Nummer setzen oder – eleganter – im SBC per Regel den Absender manipulieren. anynode kann anhand von Kriterien (z. B. Anruf kommt von bestimmter Teams-Queue) den From: und PAI Header auf eine definierte Nummer ändern. Allerdings muss der Telefonanbieter CLIP no screening erlauben, sonst überschreibt er die Präsentation auf eine genehmigte Stammnummer. Viele SIP-Provider in DACH bieten CLIP no screening als Option an (teils nur für geprüfte Nummernblöcke, um Missbrauch zu verhindern). Im Nummernkonzept sollte klargelegt sein, welche Nummern nach außen gezeigt werden sollen: i.d.R. bei Mitarbeitern ihre Durchwahl, bei Hotlines eine allgemeine Nummer, bei externen Durchstellungen evtl. die Originalanrufernummer (Transparenz).
• P-Asserted-Identity (PAI) / Remote-Party-ID: Dies sind SIP-Headerfelder, die im Carrier-Netz genutzt werden, um die authentische Rufnummer des Anrufers mitzugeben. Teams sendet für ausgehende Anrufe standardmäßig im PAI die LineURI des Benutzers. anynode übernimmt dies und überträgt es an den Provider. Wenn CLIP no screening aktiv ist, nimmt der Provider diese PAI als anzuzeigende Nummer. Remote-Party-ID ist ein älterer Mechanismus, den manche Legacy-Systeme nutzen – anynode kann bei Bedarf PAI in RPID duplizieren oder umgekehrt, falls ein SIP-Trunk das verlangt. Für eingehende Anrufe können diese Header ebenfalls relevant sein, z. B. wenn eine Weiterleitung erfolgt (damit der ursprüngliche Anrufer ersichtlich bleibt). Das Nummernkonzept sollte definieren, dass Teams bei Weiterleitungen die Originalnummer im Display zeigt (was es per Default tut, falls in Voice Routing nicht blockiert) – und dass im externen Netz der Ursprungsrufer nicht fälschlich als Absender nach draußen geht außer gewünscht (Thema „CLIP no screening bei Redirect“).
• Anonymisierung (CLIR): Benutzer können in speziellen Fällen ihre Nummer unterdrücken (CLIR – Calling Line Identification Restriction). In Teams kann man pro Anruf „Als anonym festlegen“ wählen (wenn erlaubt) oder per Richtlinie generell einen Benutzer anonymisieren. Technisch setzt Teams dann einen Privacy-Header im SIP oder lässt PAI weg. anynode muss dies durchreichen: zum Provider sollte dann entweder kein Absenderrufnummern-Header gehen oder ein spezielles Kennzeichen (manche Provider erwarten z. B. From: Anonymous <sip:anonymous@anonymous.invalid> und Privacy: id). Im Nummernkonzept definiert man, welche Nutzer Anonym schalten dürfen (oft Vorstand etc.) und ob man eingehende anonyme Anrufe zulässt oder z. B. an interne Sonderziele leitet. Teams ermöglicht keine sehr granularen CLIR-Regeln – es ist eher on/off.

Wählpläne in Teams – Dial Plan und Normalisierung

Wählpläne (Dial Plans) in Teams legen fest, wie vom Benutzer gewählte Nummern interpretiert und in ein E.164-Format normalisiert werden. Da Benutzer häufig Gewohnheiten aus der alten Telefonanlage haben (z. B. Vorwahl „0“ für Amt, Durchwahlen ohne Vorwahl, Kurzwahlen), kann man mittels Tenant Dial Plans diese Eingaben auffangen und korrigieren.

Wichtige Aspekte bei Dial Plans:

• Normalize to E.164: Das Ziel jeder Normalisierungsregel ist, aus einer beliebigen Eingabe (sofern zulässig) eine +<Country><Number> zu machen. Beispielsweise „0041 44 6667777“ soll zu „+41446667777“ werden, oder „0117“ (CH Notruf Polizei) soll zu „117“ bleiben (Notrufnummern bewusst nicht auf + ergänzt).
• Lokale Gewohnheiten abbilden: In Deutschland wählen viele Nutzer „0“ vor externen Nummern (Amtsholung). In Teams ist das nicht erforderlich – man könnte die 0 schlicht ignorieren. Durch eine Regel ^0([1-9]\d+)$ -> +49$1 für einen deutschen Standort würde „089…“ zu „+4989…“. Alternativ kann man auch entscheiden, dass Nutzer direkt + oder 00 wählen sollen – aber für Nutzerakzeptanz ist es oft besser, gewohnte Muster zu unterstützen. Ebenso könnten firmeninterne Kurzwahlen (etwa 4-stellige Durchwahlen) im Dial Plan auf E.164 der entsprechenden Kollegen gemappt werden, falls die Leute interne Nummern noch so wählen möchten.
• Länderspezifische Dial Plans: Da Format und Gewohnheiten je Land verschieden sind (z. B. in CH keine „0“ für Fernamt, in UK manchmal „9“ als Amtsholung, in USA 7-stellige lokale Nummern etc.), kann man pro Land oder sogar pro Standort eigene Dial Plans definieren. Microsoft erlaubt einen Tenant Dial Plan zu erstellen und diesen per Voice Routing Policy den Benutzern zuzuweisen. Man könnte also z. B. einen Dial Plan „GermanyDP“ und „SwitzerlandDP“ haben. Alternativ lässt sich auch alles in einen globalen Dial Plan packen, aber getrennt ist übersichtlicher.
• Notruf-Ausnahmen: Wählpläne sollten sicherstellen, dass Notrufnummern nicht verändert oder blockiert werden. Konkret: Wenn ein Nutzer „112“ eintippt, soll Teams genau diese Ziffernfolge als Ziel behalten. Dafür definiert man eine Normalisierungsregel, die 112 -> 112 (identisch) liefert. Zusätzlich kann man in Teams Notruf-Richtlinien setzen, in denen Notrufnummern und ggf. interne Sicherheitsteams definiert sind – doch auf Dial-Plan-Ebene ist die korrekte Handhabung zentral. Auch länderspezifische Notrufnummern gilt es zu berücksichtigen: In D z. B. 112 und 110; in A 112, 133 (Polizei), 144 (Rettung), 122 (Feuerwehr); in CH 112, 117, 118, 144, etc. Entweder man nimmt nur 112 im Dial Plan (einheitlich EU-Notruf) und regelt alternative Nummern im SBC oder per Anwenderschulung – oder man hinterlegt mehrere. Bedenke: Es gibt Sonderfälle – z. B. „911“ (US-Notruf) könnte jemand versehentlich wählen; manche fügen auch das als Alias zu 112, um sicherzugehen.
• Sonderrufnummern: Je nach Land existieren Service- und Sondernummern (z. B. 0800 (Freecall), 0900 (Premium) in D/CH, 084x in CH für shared cost, 116xxx europaweite Dienste). Diese sollten im Dial Plan erfasst werden, damit sie nicht fälschlich als internationale Nummer interpretiert werden. Z. B. „0800xxxxxx“ –> +49800xxxxxx in DE (wenn man will, dass +49 800… gewählt wird). Allerdings sind viele Service-Nummern nicht international erreichbar; man könnte sie auch unnormalisiert lassen und direkt an den Trunk geben, sofern der Carrier national routet. Hier entscheidet man sich für eine konsistente Strategie: Entweder alle externen Nummern streng in +E.164 oder bestimmte Kurzformen direkt.
• Testen und iterieren: Jede Dial-Plan-Regel sollte mit Beispielnummern getestet werden (Teams bietet im Admin Center ein Dial Plan Tool, oder via PowerShell Test-CsEffectiveTenantDialPlan). Wichtig: Die Reihenfolge der Regeln wird beachtet – spezielle vor generellen. Z. B. die Regel für „0 (Amtsholung)“ sollte NICHT Notruf- oder Kurzwahl-Muster fälschlich mit abdecken. Oft definiert man zuerst Ausnahmen (Notruf, interne Kurzwahl), dann generelle (00->+, 0Z->+49 etc.).

Voice Routing: Policies, PSTN Usages, Routen

Neben dem Dial Plan (der nur die gewählte Nummer transformiert) steuert das Voice Routing in Teams, welcher Anruf wohin geht:

• Voice Routes und PSTN Usages: In Direct Routing werden Voice Routes definiert, die Nummern mit Regex-Mustern vergleichen und dann an eine oder mehrere PSTN Gateways (SBCs) senden. Jede Route ist einer oder mehreren PSTN Usages (Nutzungseinheiten) zugeordnet – diese sind einfach logische Labels, die in Voice Routing Policies referenziert werden. Eine Voice Routing Policy wird einem Benutzer zugewiesen und enthält eine geordnete Liste von PSTN Usages, die dieser nutzen darf. Daraus ergibt sich, welche Routen für ihn greifen.

Beispiel: Man hat PSTN Usage „International“ mit Route „^+[^49]“ (alle internationalen außer +49) über SBC1, und Usage „National“ mit Route „^+49“ über SBC1. Ein deutscher Mitarbeiter bekommt Policy mit beiden Usages. So gehen alle seine Anrufe über SBC1. Ein anderer Benutzer könnte eine Policy ohne „International“ haben – dann verweigert Teams Anrufe, die nur von einer Route mit Usage „International“ abgedeckt würden (typische Sperre für Privatnummern oder so). In der Praxis setzt man oft pro Land oder Standort eigene PSTN Usages/Routen auf, um z. B. Anrufe eines Schweizer Users automatisch über den CH-SBC zu leiten (Route: ^+41 -> SBC_CH, Usage=CH).

• Failover-Routing: Einer Voice Route kann eine Liste von SBCs zugeordnet werden. Die Reihenfolge ist Priorität. Wenn der erste SBC nicht erreichbar ist (Teams erkennt dies an fehlender Options Antwort oder einem SIP 503 Fehler), versucht Teams automatisch den nächsten in der Liste. So lässt sich ein Failover auf SBC-Backup realisieren. Beispiel: Route „+49“ hat primär SBC in Berlin, sekundär SBC in Zürich. Fällt Berlin-SBC aus, werden deutsche Anrufe via Zürich gesendet (Achtung: Notrufe in so einem Szenario problematisch, daher besser so nur für normale Calls).
• Lastverteilung: Teams verteilt eingehende Anrufe auf mehrere registrierte SBCs im Round-Robin, sofern eine Nummer auf mehreren SBCs gleichzeitig eingetragen ist (selten der Fall außer bei echten Multihoming). Für ausgehende Anrufe wird i. d. R. die erste funktionierende Route genutzt. Eine simple Lastverteilung kann man erreichen, indem man z. B. zwei parallele Routen mit gleichem Pattern hat, eine über SBC1, eine über SBC2, und die Usages so verteilt auf Benutzer, dass manche primär den einen, andere den anderen nutzen. Allerdings erhöht das Komplexität. Besser: SBC-seitig Lastverteilung (z. B. SBC verteilt auf zwei Trunks) oder an Provider delegieren.
• Sonderfall Notrufe: Hier greift eine Kombination: Ein Emergency Call Routing Policy kann in Teams definiert werden, um 112 etc. speziell zu behandeln (z. B. an einen spezifischen SBC oder an eine Sicherheitszentrale). In vielen Fällen aber routet man Notrufe einfach über die normalen Routen (die dann hoffentlich lokal sind). Es kann sinnvoll sein, im Routing eine eigene Route ganz oben zu haben: Pattern „^112$“ -> lokaler SBC (und kein anderer), damit Notruf immer lokal rausgeht, selbst wenn andere generische Routen was anderes sagen würden.

Zusammengefasst: Voice Routing ermöglicht ein fein granuliertes Verteilsystem für Anrufe basierend auf Nummern. Man sollte hier das Nummernkonzept spiegeln: Für jeden relevanten Nummernbereich (internat., national, Notruf, Service) klare Routen definieren und diese in Policies zuordnen. Dabei die Simplicity-Regel beachten – nicht zu viele unterschiedliche Policys ohne Grund, sonst wird es unübersichtlich.

Im Folgenden ein beispielhafter Entwurf eines Dial Plans und einiger Routen.

Rufnummern- und Dial-Plan-Entwurf (Beispiel)

(Obiges Beispiel geht von deutschem Standort mit Vorwahl 089 aus; für andere Länder würden entsprechende Regeln analog erstellt.)

In der Praxis würden die meisten „Standard (extern)“-Regeln zusammengefasst in einem Tenant Dial Plan definiert sein. Notrufe kommen entweder in den Tenant Dial Plan oder in eine separate Notruf-Richtlinie. Man beachte, dass Teams-Clients auch automatisch gewisse Muster erkennen (z. B. +49 am Anfang) – aber man sollte sich nicht darauf verlassen, sondern die Regeln explizit angeben, um Konsistenz zu gewährleisten.

Als nächstes ein kurzer Blick auf die PowerShell-Konfiguration solcher Regeln und Routen in Teams:

# Beispiel: Anlegen einer Voice Route für deutsche nationale Nummern (Pattern ^\+49)
# und Zuordnung zum SBC „sbc01.contoso.de“ mit PSTN Usage „DE-National“
New-CsOnlineVoiceRoute -Identity „DE_National“ -NumberPattern „^\+49(\d+)$“ `
    -OnlinePstnGatewayList sbc01.contoso.de `
    -OnlinePstnUsages „DE-National“

# Beispiel: Anlegen eines Dial Plans „GermanyDP“ mit Normalisierungsregeln
New-CsTenantDialPlan -Identity „GermanyDP“ -Description „Dial Plan Deutschland“ `
    -NormalizationRules @(
        New-CsVoiceNormalizationRule -Name „DE_Internat_00“ -Pattern ‚^00([1-9]\d+)$‘ -Translation ‚+$1‘ -Description „00->+ International“,
        New-CsVoiceNormalizationRule -Name „DE_National_0“ -Pattern ‚^0([1-9]\d+)$‘ -Translation ‚+49$1‘ -Description „0->+49 National“,
        New-CsVoiceNormalizationRule -Name „DE_Notruf_112“ -Pattern ‚^112$‘ -Translation ‚112‘ -Description „Notruf 112“,
        New-CsVoiceNormalizationRule -Name „DE_Notruf_110“ -Pattern ‚^110$‘ -Translation ‚110‘ -Description „Notruf 110“
    )
Grant-CsTenantDialPlan -Identity „user1@firma.de“ -TenantDialPlan „GermanyDP“

# Zuweisen einer Voice Routing Policy an Benutzer (enthält PSTN Usages)
New-CsOnlineVoiceRoutingPolicy -Identity „Policy_DE“ -OnlinePstnUsages @(„DE-National“,“DE-International“,“DE-Service“,“Emergency“)
Grant-CsOnlineVoiceRoutingPolicy -Identity „user1@firma.de“ -PolicyName „Policy_DE“

Die obigen Befehle zeigen typische Schritte: VoiceRoute erstellen, Dial Plan mit Regeln erstellen, Zuweisungen vornehmen. In einer echten Umgebung würde man natürlich mehr Patterns (z. B. 0800er Regeln etc.) ergänzen und für jedes Land eigene Sets erstellen. Wichtig: Änderungen an Dial Plans benötigen einige Minuten Replikationszeit und testen ist Pflicht.

Notrufkonzept (DACH) – Technik und Organisation

Ziele und Herausforderungen bei Notrufen

Notrufe (112 & Co.) zuverlässig zu ermöglichen ist ein zentrales Anliegen jeder Telefonie-Lösung – und bei Microsoft Teams ergeben sich durch die Ortsunabhängigkeit besondere Herausforderungen. Ziele des Notrufkonzepts:

• Zuverlässige Erreichbarkeit der Notdienste: Jeder Benutzer muss jederzeit in der Lage sein, die lokalen Notrufnummern (Polizei, Feuerwehr, Rettung) zu erreichen, egal ob er im Büro, im Homeoffice oder mobil arbeitet. Es darf keine Konfigurationslücke geben, die einen Notruf blockiert.
• Korrekte Zuordnung zum Standort: Wenn ein Notruf abgesetzt wird, soll er bei der örtlich zuständigen Leitstelle (PSAP) ankommen. In traditionellen TK-Anlagen war das durch die Telefonanschlussleitung implizit gegeben. In der Cloud-Telefonie kann ein Benutzer mit einer Nummer aus München theoretisch von Hamburg oder Wien aus anrufen – die Leitstelle würde aber anhand der Nummer nach München verbinden. Dieses Problem muss adressiert werden, damit kostbare Zeit nicht verloren geht.
• Rechtskonformität: In Deutschland, Österreich und der Schweiz existieren jeweils regulatorische Vorgaben für Telefonanlagen bzgl. Notrufen. Z. B. fordert die deutsche Notrufverordnung, dass der Standort eines Notrufers möglichst präzise ermittelt und übermittelt wird. Zwar gelten bestimmte Ausnahmen für nomadische Dienste, aber Unternehmen sollten im Rahmen des Arbeitsschutzes eine Lösung haben. Rechtliche Beratung gehört zwar separat, doch das Konzept sollte diese Pflichten zumindest soweit bekannt umsetzen.
• Testbarkeit: Ein Notrufkonzept ist nur gut, wenn man es auch gefahrlos testen kann. Es braucht also definierte Verfahren für Testanrufe (ggf. mit vorheriger Absprache der Leitstellen oder Nutzung interner Test-Identifikatoren, wenn vom Provider unterstützt). Regelmäßige Tests (z. B. alle 6 Monate) stellen sicher, dass Änderungen im Netzwerk oder Routing die Notruffunktion nicht beeinträchtigt haben.
• Dokumentation und Schulung: Neben der technischen Umsetzung ist die organisatorische Verankerung wesentlich. Mitarbeiter müssen wissen, wie sie einen Notruf tätigen (z. B. im Zweifel lieber Handy nutzen, wenn sie remote sind und Adresse unklar). Ebenso muss dokumentiert sein, wer intern Ansprechpartner für Notrufsysteme ist, wie Standorte im System gepflegt werden usw.

Standortmodell: statische vs. dynamische Adresszuordnung

Zwei Ansätze gibt es, um einem Notruf Standortinformationen zuzuweisen:

• Statische Adresszuordnung: Hier wird jedem Teams-Telefonanschluss eine feste Adresse hinterlegt. Beispielsweise im Teams Admin Center kann man pro Nummer oder Nutzer eine Notfalladresse definieren (Straße, Ort, Gebäude etc.). Diese wird dann im Notfall übertragen. Für Benutzer, die immer am gleichen Ort sind (z. B. festes Büro), ist das praktikabel. Bei mobilen Mitarbeitern (Laptop-User, wechselnde Büros) greift statisch hinterlegte Adresse oft nicht – man müsste ständig manuell ändern, was unpraktikabel ist. Statische Modelle werden oft gewählt, um zumindest pro Standort eine Grundadresse zu haben (z. B. Hauptadresse der Niederlassung).
• Dynamische Standortzuordnung: Microsoft Teams bietet die Möglichkeit, per Netzwerkinformationen (Subnetze, WLAN SSIDs, ggf. ortsbasierte Endpunkte) dynamisch den Standort zu ermitteln. In der Praxis legt man im Teams Admin Center Netzwerksites an: z. B. „Münster Büro“ mit zugehörigen Subnetzbereichen der internen LAN/WLAN. Dieser Site wird eine physische Adresse zugewiesen. Meldet sich ein Teams-Client im Firmen-LAN (und das Subnetz matcht), so weiß Teams „Benutzer ist in Münster Büro, Adresse X“ und kann diese Information im Notruf nutzen. Das Stichwort ist „Dynamic Emergency Calling“: Der Client ermittelt bei LAN/WLAN-Verbindung seine Standort-ID. Für externe Standorte (Homeoffice) kann der User in manchen Regionen manuell Adresse eingeben (in den USA z. B. Pflicht). In DACH ist die manuelle Adresseingabe im Client derzeit nicht von den Behörden vorgesehen, daher greift hier eher: unbekannter Standort = Standardadresse/Fallback.
• Fallback-Mechanismen: Was passiert, wenn ein Notruf von einem unbekannten Ort kommt? Z. B. Mitarbeiter mit Münchner Nummer sitzt auf Geschäftsreise in Paris und wählt 112 in Teams. In so einem Fall kann man entscheiden: Leitet man den Notruf dennoch über den deutschen Trunk (landet in München PSAP) und vertraut darauf, dass der Anrufer seinen Standort mündlich mitteilt? Oder blockiert man Notrufe aus dem Ausland via Teams und zeigt dem Nutzer eine Info „Bitte nutzen Sie lokale Telefonie“? – Letzteres könnte lebensgefährlich sein, deshalb blockieren sollte man nicht. Besser: Wenn Standort unbekannt, Rufnummernmanipulation auf eine zentrale Notruf-Nummer der Firma in DE, wo der Mitarbeiter dann zumindest auf Deutsch rauskommt. Oder Nutzung eines globalen Notruf-Providers (in US gibt es 911 Services, aber in EU weniger verbreitet). Oft wird im Notrufkonzept festgehalten: „Remote Users sollen nach Möglichkeit örtliche Telefone nutzen“, als organisatorische Maßnahme.

Microsoft betont bei Teams, dass Nomadic E911 (US-Konzept) unterstützt ist; in DACH ist man hier auf Eigenlösungen angewiesen.

Routing von Notrufen via SBC

Die Technik greift maßgeblich am SBC: Hier kann man Regeln implementieren, um Notrufe speziell zu behandeln:

• Spezielle Trunks/Carrier für Notruf: Einige Unternehmen entscheiden sich, Notrufe nicht über den Standard-SIP-Trunk zu schicken, sondern über einen lokalen Amtsanschluss oder einen spezialisierten Anbieter. Gründe: höhere Verlässlichkeit, garantiert örtliche Zuständigkeit. Beispielsweise könnte am Standort München noch ein Analog/ISDN-Anschluss nur für Notrufe existieren (über ein Gateway an anynode angebunden), der unabhängig vom Internet funktioniert. anynode kann dann Nummer „112“ priorisiert an diesen Gateway leiten. Alternativ bieten manche SIP-Provider an, Notrufe an lokale Leitstellen zu vermitteln, wenn man ihnen vorab die Adressen mitteilt.
• Priorisierung: Notrufe sollten in der SBC-Routingkonfiguration oberste Priorität haben. D. h. wenn ein Pattern „112“ erkannt wird, wird es sofort auf den dafür vorgesehenen Trunk geroutet – unabhängig von anderen Routing-Logiken. Bei Überlast im SBC oder Trunk sollte Notruf immer noch durchkommen (z. B. indem man auf dem SIP-Trunk Kanäle reserviert oder im Traffic Shaping Notrufpakete priorisiert).
• Alternative Routen (Failover): Fällt der primäre Notruf-Weg aus, muss ein Fallback definiert sein. Beispiel: Primär geht 112 über den deutschen SIP-Trunk A. Falls dieser trunk offline ist, versucht anynode als Fallback den SIP-Trunk B (bei anderem Anbieter, oder via Ausland – letzteres wie erwähnt kritisch, aber besser als nichts). Oder notfalls über einen mobilen GSM-Gateway. Solche Backups sind komplex (man will ja genau vermeiden, dass Notruf falsch ankommt), aber zumindest ein zweite Variante sollte gegeben sein.
• Sperrlogik für Fehlwahlen: Leider werden Notrufnummern gelegentlich versehentlich gewählt, z. B. jemand will eine Amtsnull wählen und tippt „0112…“ – was als 112 erkannt werden könnte. Im Dial Plan würde 0112 nach +49112 normalisiert (was man tunlichst verhindern sollte!). Durch saubere Dial-Plan-Regeln (z. B. 0[1-9]… vs. 0 gefolgt von Notruf) verhindert man einiges. Der SBC kann zusätzlich schützen: anynode könnte z. B. erkennen, wenn jemand extrem kurz nach Wahl wieder auflegt und 112 gewählt hatte – dann war es evtl. ein Irrtum, und die Leitung könnte getrennt werden. Aber hier ist Vorsicht: Besser nicht automatisiert blockieren. Was man jedoch machen kann: Geofence bei Notruf – d. h. wenn ein Nicht-Notruf-Muster aus Versehen 112 triggert, eine Zwischenschaltung („Drücken Sie 1 um wirklich Notruf zu wählen“). Solche IVRs sind aber in echten Notfällen hinderlich. In DACH empfehlen manche Administratoren, die 110 (Polizei in DE) nicht im Dial Plan aufzufangen, um versehentliche Anwahl zu reduzieren – sondern nur 112 (einheitlich) zuzulassen. Das hängt vom Sicherheitskonzept ab und sollte mit der Unternehmensleitung abgestimmt sein.
• ELIN-Implementierung: Eine fortgeschrittene Technik ist die Nutzung von ELINs (Emergency Location Identification Numbers). Man reserviert pro Standort oder Gebäudebereich spezielle Rufnummern, die zur Leitstelle führen. Wenn ein Mitarbeiter den Notruf wählt, ersetzt der SBC dessen Absenderrufnummer durch die ELIN des aktuellen Standorts. Dadurch sieht die Leitstelle z. B. „Notruf Firma XY, Standort Frankfurt, Tel 069-1234-999“ als Absender – was ortszugeordnet ist. anynode kann via Location Policies oder Script diese Substitution durchführen, basierend auf der vom Teams-Client gemeldeten Netzwerk-Site. Voraussetzung: anynode erhält die Info, wo der User ist – Microsoft übergibt im SIP-Invite tatsächlich bei Dynamic Emergency Calling einen Header mit Location und möglicherweise eine vorgeschlagene Callback-Nummer. anynode benötigt für ELIN eine Zusatzlizenz, wie erwähnt. Nach dem Gespräch sorgt der SBC dafür, dass diese ELIN-Nummer für Rückrufe noch eine Zeit lang dem Mitarbeiter zugeordnet bleibt (wenn Leitstelle zurückruft). Implementiert man ELIN, so muss man im Vorfeld entsprechende Nummernblöcke beim Provider besorgen und jede Nummer einer Adresse melden.

Zusammengefasst: Der SBC ist der Ort, an dem man Notrufe gezielt lenken kann – entweder simpel „alle 112 über lokalen Trunk“ oder komplex mit ELIN und dynamischer Anpassung. Wichtig ist eine umfassende Dokumentation dieser Routingregeln, damit in Notfallsituationen auch Vertretungen verstehen, was passiert.

Organisatorische Maßnahmen rund um Notruf

Technik alleine reicht nicht – organisatorische Vorkehrungen ergänzen das Notrufkonzept:

• Definierte Prozesse: Es sollte klar festgelegt sein, wer im Unternehmen für Notruf-Themen verantwortlich ist (z. B. Telecom-Admin in Zusammenarbeit mit Arbeitsschutz-Beauftragtem). Ein Prozess könnte sein: „Bei Standortumzügen oder neuen Büros informiert die Facility-Abteilung den Telefonie-Admin, damit dieser die Notfalladressen aktualisiert.“ Ebenso: „Nach jedem größeren Change an Dial Plan oder SBC wird ein Notruf-Test durchgeführt.“
• Mitarbeiterschulungen: Alle Nutzer müssen die Besonderheiten der Cloud-Telefonie kennen. Insbesondere: Homeoffice-Nutzer – sie sollten informiert werden, dass ihr Notruf über die Firmen-Telefonie ggf. an den Heimatort geroutet wird. Tipp: „Wenn Sie unterwegs oder zuhause sind, nutzen Sie nach Möglichkeit das Handy für Notrufe, da hier Standort automatisch übermittelt wird.“ Gleichzeitig muss keiner Angst haben, Teams-Notruf zu nutzen, falls kein anderes Telefon greifbar – dann aber unbedingt Ortsangabe machen.
• Notrufflyer / Infomaterial: In Büros kann man Notfallinformationen aushängen: z. B. an jedem Geschossplan ein Hinweis, wo Telefone für Notrufe sind (siehe nächster Punkt), welche Nummern (112) zu wählen sind, wer im Haus Ersthelfer ist etc. Auch im Intranet oder Begrüßungsschreiben für neue Mitarbeiter sollten Hinweise zur Notruffunktion der IT-Telefonie stehen.
• Physische Notfalltelefone (Common Area Phones): Wie im Beispiel von Ratiodata beschrieben, ist es sinnvoll in größeren Gebäuden fest installierte Telefone vorzusehen, die ohne Login einen Notruf absetzen können. In modernen Büroumgebungen haben viele nur Softphones am PC – nachts oder in Notfallsituationen kann das hinderlich sein (PC gesperrt, kein Handy dabei). „Notfallapparat“ pro Etage, evtl. neben Erste-Hilfe-Kasten und Feuerlöscher, stellt sicher: Jeder kann Hörer abnehmen und 112 wählen. In Teams realisiert man das mit einem günstigen Teams-Tischtelefon oder Smartphone im Kiosk-Modus mit Common Area Phone-Lizenz. Diese Telefone werden so konfiguriert, dass sie kein Benutzerlogin brauchen und immer ein Wählfeld zeigen. Von außen sind sie erreichbar (z. B. die Feuerwehr könnte zurückrufen). Das Unternehmen sollte diese Geräte regelmäßig überprüfen (funktionieren sie, sind sie erreichbar?).
• Interne Alarmierung: Zusätzlich zum externen Notruf rufen manche Organisationen interne Sicherheitsstellen oder Empfang mit an, wenn ein Notruf abgesetzt wird (z. B. paralleles Klingeln bei Werksschutz). Teams erlaubt in der Notruf-Richtlinie einen „Notification Hub“ – z. B. kann eine Gruppe in Teams oder eine bestimmte Person einen Hinweis bekommen („User X hat gerade 112 gewählt – Standort: München, 3.OG“). Hierfür muss man die Notruf-Policy in Teams konfigurieren. Organisatorisch muss dann auch klar sein, was der Benachrichtigte tun soll (z. B. zum Ort des Geschehens eilen, Rettung einweisen).
• Dokumentation & Ansprechpartner: Alle Standorte sollten mit ihren Notruf-bezogenen Daten dokumentiert sein (Adresse, zuständige PSAP, genutzter Trunk, ELIN-Nummern, etc.). Ein zentraler Plan sollte existieren, damit im Ernstfall oder bei Änderung jeder Engineer weiß, wo drehen. Außerdem wichtig: Kontakt zur Leitstelle – bei Notruf-Tests ruft man idealerweise vorher dort an um sich abzustimmen. Einige Leitstellen bieten Testfenster (z. B. bestimmte Uhrzeit), in denen man Testanrufe machen darf.
• Länderspezifisches Wissen: Der organisatorische Teil sollte auch Unterschiede in Ländern berücksichtigen: In der Schweiz z. B. empfiehlt es sich, Mitarbeiter drauf hinzuweisen, dass es separate Nummern (117,118,144) gibt – obwohl 112 auch geht. In Österreich ist 112 in Städten meist Polizei, während Rettung 144 ist – das sollte im Notfall auch dem Mitarbeiter bewusst sein. Aber als Firma kann man standardisieren: „Benutzt immer 112 – im Zweifel wird man verbunden“.
• Keine Rechtsberatung aber Sensibilisierung: Das Konzept selbst ist kein Ersatz für Rechtsberatung, aber es sollte grob angeben: „In Land X gilt aktuell folgende Vorschrift, daher setzen wir dies so um…“ und an Legal/Compliance weitergegeben werden zur Prüfung.

Länderspezifische Besonderheiten (Deutschland, Österreich, Schweiz)

Ohne zu tief juristisch zu gehen, hier einige landesspezifische Aspekte und Tipps:

• Deutschland: Neue Regelungen (TKG-Novelle 2021) verlangen von VoIP-Anbietern eine „mögl. genaue Standortübermittlung“. Für private nomadische Dienste ist das gelockert, aber für Unternehmensanschlüsse sollte pro Rufnummer ein Standort gemeldet sein. Hier greift man oft auf Firmen-Hauptadresse je Nummer zurück und ergänzt das intern durch dynamic routing. Wichtig: In DE existiert die Polizeinotrufnummer 110 parallel zu 112 – viele Bürger nutzen 110 bei Einbrüchen etc. Eine Teams-Telefonie sollte idealerweise beide unterstützen. Einige Unternehmen leiten 110 jedoch intern zur 112 um (Polizei-Notrufe werden in manchen Bundesländern mit Feuerwehr-Leitstellen verknüpft, aber das ist keine allgemeine Regel). Ferner sollten in DE Notruf-Rückrufe möglich sein: Leitstellen rufen oft zurück, wenn ein Notruf abbricht. Daher sollte keine Einstellung ausgehende unbekannte Anrufe blockieren. Und falls mit ELIN gearbeitet wird: Der Rückruf an die ELIN muss im Unternehmen ankommen (z. B. auf dem Notfallapparat oder beim Sicherheitsdienst).
• Österreich: Hier sind wichtige Nummern: 112 (EU-Notruf, meist zur Polizei), 133 (Polizei direkt), 122 (Feuerwehr), 144 (Rettung). Unternehmen sollten zumindest 112 und 144 zugänglich machen. 133/122 kann man auch aufnehmen. In AT gilt ebenso die Pflicht zur Standortinfo. Wenn ein Wiener Mitarbeiter mit Salzburger Nummer anruft, landet er in Salzburg – schlecht. Lösung ähnlich: standortabhängige Nummern oder Ansage. Die Leitstellen in AT können evtl. anhand von Ansagen oder Infos reagieren. Evtl. macht es Sinn, Notrufe von mobilen Teams-Nutzern intern an eine zentrale Stelle zu leiten, wo z. B. der Werkschutz dann selbst bei der richtigen Stadt Leitstelle anruft. Aber das verzögert ggf. Hilfen, daher fraglich.
• Schweiz: Notrufe: 112 (allg.), 117 (Polizei), 118 (Feuerwehr), 144 (Rettung), 1414 (Rega Luftrettung) etc. Schweiz hat das Besondere, dass Nummern nicht mehr streng geographisch gebunden sind (Ortsvorwahl, aber Nummer kann woanders genutzt werden). Dennoch erwarten die Notrufsysteme, dass man aus dem richtigen Ortsnetz kommt. Viele Schweizer Unternehmen lösen es so: Sie behalten pro Standort einen kleinen Telefonanschluss für Notfälle. In Teams kann man Notruf so konfigurieren, dass statt über die Cloud der Call local breakout über ein Gateway geht. Auch Swisscom & Co bieten speziellen Notruf-Service an, wenn man SIP nutzt.
• Homeoffice/International: In allen DACH-Ländern sollte man definieren: Mitarbeiter im Ausland – wie verhalten? Evtl. Info: „Teams-Notrufe im Ausland nicht möglich“ oder zumindest großen Warnhinweis. Rechtlich: Wenn z. B. ein DE Mitarbeiter in FR Notruf via DE-Nummer absetzt, ist es formal ein Notruf in DE getätigt – der frz. Kollege in der Leitstelle kann gar nicht helfen außer weiterverbinden. Besser, so was administrativ zu verhindern.

Rechtlicher Hinweis: Das Unternehmen sollte seine Mitarbeiter informieren, dass Notrufe über die Cloud erfolgen und was das bedeutet. Zudem intern festhalten, dass man keine Garantie für die Standortübermittlung geben kann, und daher die getroffenen Maßnahmen (z. B. ELIN, Schulung, Notfalltelefone) als Good Practice etabliert sind. Keine dieser Ausführungen stellt eine Rechtsberatung dar – im Zweifel also Anwälte hinzuziehen, um voll konform zu sein.

Notruf-Routingmatrix (Beispiel)

Ein Beispiel einer Routing-Matrix, wie Notrufe abhängig vom Standort geleitet werden:

Erläuterungen: Hier sieht man, dass z. B. München alle Notrufe über den lokalen Trunk schickt (Telekom hat Adresse der Rufnummern). Fällt der aus, gibt es noch eine ISDN-Leitung vor Ort (vielleicht an einem Patton-Gateway), die im Notfall genutzt wird. In Berlin gibt es primären SIP und falls der tot ist, geht’s über München (nicht ideal, aber als Reserve). Kennzeichnung ELIN bedeutet: Der SBC ersetzt z. B. die abgehende Nummer durch 08912345999, die bei der Leitstelle als „Musterfirma München“ registriert ist.

Kennzeichnung/Tagging kann auch bedeuten, dass im SIP-Header ein Priority: emergency Tag gesetzt wird (manche Systeme tun das), oder dass im anynode Log solche Calls markiert werden.

Standort-Datenerfassung

Eine Tabelle zur Standortdatenerfassung hilft, die Übersicht über alle relevanten physischen Standorte und ihre Zuordnung im System zu behalten:

In dieser Tabelle sieht man z. B., dass für Wien ein spezieller Mechanismus gilt (analog Pförtnertelefon mit Kurzwahl 5 an Pförtner, der Notruf übernimmt). Jede Zeile sollte den Pfad zeigen. „Pflegeprozess“ stellt sicher, dass z. B. bei Umzug des Berliner Büros neue Adressen und ggf. neue ELINs beschafft werden.

Checkliste: Notruf-Tests & Abnahmen

Regelmäßige Überprüfung des Notrufkonzepts – folgende Punkte sollten abgehakt werden:

• [ ] Techniktest – interner Dummy-Call: Führen Sie einen Testanruf innerhalb des Systems durch, der einen Notruf nachbildet (z. B. an eine interne Sicherheitsstelle statt 112). Prüfen: Wählt der Teams-Client korrekt (richtige Regel greift), landet der Call auf dem erwarteten Ausgang am SBC (im anynode-Log erkennbar), wird die Absendernummer gemäß Konzept gesetzt?
• [ ] Live-Test mit Leitstelle (abgestimmt): In Absprache mit der zuständigen Leitstelle einen echten Test-Notruf absetzen. Szenario: Mitarbeiter X wählt 112 vom Standort Y. Beim Abheben sofort klarstellen „Testcall“. Abfragen: Kam der Ruf bei der richtigen Leitstelle an? Welche Nummer/Adresse sieht die Leitstelle? Konnte ggf. direkt die korrekte Adresse übermittelt werden (z. B. Leitstelle liest vor „Sie rufen an aus Musterfirma, Marcel-Breuer-Str. 12?“)? Dokumentieren Sie das Ergebnis.
• [ ] Sprachverbindung & Ansage: Sicherstellen, dass der Notruf mit Ton aufgebaut wird. Hintergrund: Der Ruf sollte klingeln, kein Besetzt oder Silence. Hört der Anrufer die Halte/Meldeansage der Leitstelle? (z. B. „Feuerwehr und Rettungsdienst, wo befinden Sie sich?“). Falls nein, kann es sein, dass Early Media nicht durchkommt – SBC-Einstellung prüfen.
• [ ] Standortübermittlung geprüft: Wenn Ihr Konzept auf mündliche Standortangabe setzt, prüfen Sie mit einem Test im Team, ob die Mitarbeiter die Adresse parat haben (kleine Notfallübung: „Kollege, sag mir spontan die Adresse deines Homeoffices“ – erstaunlich, manche wissen die Postleitzahl nicht auswendig). Falls ELIN/dynamisch: Testen, ob bei Wechsel ins anderes Netzwerk die Location-ID richtig erkannt wird (in Teams Client unter Anrufeinstellungen sicht- oder per PowerShell Get-CsOnlineUser LocationPolicy checkbar).
• [ ] Protokollierung im SBC: Prüfen Sie, ob Notrufe im anynode/Logging deutlich markiert oder filterbar sind. Im Ernstfall will man nachvollziehen können, wer wann Notruf wählte. anynode kann z. B. CDRs (Call Detail Records) ausgeben – stellen Sie sicher, dass Notrufnummern dort sichtbar sind und nicht irrtümlich maskiert. Beachten: CDRs mit persönlichen Daten sind vertraulich – Zugriff beschränken.
• [ ] Wiederholung und Schulung: Legen Sie fest, in welchem Intervall der Notrufmechanismus neu getestet wird (empfohlen mindestens jährlich, besser halbjährlich, und nach größeren Änderungen sofort). Nach jedem Test analysieren und bessern Sie nach. Kommunizieren Sie an die Mitarbeiter, wenn z. B. neue Notruftelefone installiert wurden oder die Notrufwahl sich geändert hat.
• [ ] Fallback-Szenarien üben: Simulieren Sie Ausfälle: Was passiert, wenn Internet weg ist? (Antwort: Teams funktioniert gar nicht, also alternativ Handy nutzen – wurde das den Mitarbeitern klar gesagt?). Was passiert, wenn SIP-Trunk down ist? (Testen durch Trunk deaktivieren: geht der Notruf dann über Backup, bekommt der Nutzer überhaupt ein Freizeichen?). Haben Sie ein „Worst-Case“-Szenario definiert, z. B.: „Wenn Cloud und SBC tot, im Gebäude Alarmknopf drücken oder Feuerwehr per Handy anrufen“ – und wissen das alle? Wenn nein, definieren und kommunizieren.
• [ ] Abnahme durch Sicherheitsbeauftragte: Lassen Sie das finale Notrufkonzept vom zuständigen Arbeitsschutz/Sicherheitsbeauftragten des Unternehmens formal abnehmen. Dokumentieren Sie: „Am [Datum] wurden Notruf-Funktionstests durchgeführt, Herr/Frau [Name] (Sicherheitsbeauftragte/r) bestätigt die Funktionsfähigkeit gemäß den Anforderungen.“ So ist im Auditfall nachweisbar, dass das Unternehmen seiner Fürsorgepflicht nachkam.

SBC-Praxis mit anynode

Bereitstellung: Systemvoraussetzungen, Sizing und Installation

Die praktische Umsetzung beginnt mit der Bereitstellung des anynode-SBC:

• Systemanforderungen: anynode ist ressourcenschonend. Ein Windows Server (2016/2019/2022) oder Linux (beliebige gängige Distribution, x64) mit 4 GB RAM, 2 vCPU reicht für viele hundert gleichzeitige Calls. Die tatsächliche Dimensionierung hängt von Features (Transcoding benötigt mehr CPU) und Kanalzahl ab. Für ~30 gleichzeitige Gespräche sind oft <10% CPU einer modernen 2vCPU-VM belegt. Wichtig ist eine zuverlässige Netzwerkanbindung (virtueller Adapter mit geringer Latenz). Auch sollte die VM auf UTC-Zeit oder lokaler Zeitzone sauber eingestellt sein (Log-Zeiten!).
• VM-Parameter: Wenn in virtualisierter Umgebung (VMware, Hyper-V, Azure): CPU-Auslastung überwachen und ggf. Reservierungen setzen, damit Echtzeitverkehr nicht hungert. VMware z. B. hat Einstellungen für Latenz-Sensitivität. anynode selbst läuft als Dienst, der sehr schnell reagiert, aber wenn die VM stark ausgelastet wird, kann es zu Jitter kommen. Festplatte: anynode braucht wenige GB, aber Logs/Trace können wachsen – genügend Speicher (mind. 40–50 GB) einplanen, und regelmäßige Logrotation aktivieren.
• Installation: Unter Windows einfach das anynode-Setup ausführen, unter Linux gibt es Pakete. Danach startet der anynode Service. Die Verwaltung erfolgt über eine Windows-GUI (Anynode Manager), die entweder lokal installiert oder remote genutzt werden kann. Es gibt auch eine WebGUI-Option. Als erstes sollten die Lizenzen eingespielt werden (Trial oder gekaufte *.wlic-Datei), damit der SBC voll funktionsfähig ist (unlizenziert meist auf 2 Sessions limitiert).
• Zertifikate (mTLS): Vor der Teams-Integration muss das TLS-Zertifikat vorliegen. In Windows importiert man .pfx ins Zertifikatstore (Lokaler Computer\Persönlich) und wählt es dann in anynode aus. Unter Linux konvertiert man das Zertifikat in .pem. anynode benötigt neben Zert+Key auch die Chain (CA) – in Windows in „Intermediate Certification Authorities“ importieren oder als .pem Bündel angeben. In der anynode Konfig (TLS Context) legt man fest: Zertifikat X mit privatem Schlüssel Y, SNI für Teams-FQDN auf „sip.pstnhub.microsoft.com“. Auch Trusted Roots definieren: i.d.R. „Windows Trust Store“ oder manuell Root-CAs angeben, damit Microsofts Zertifikate akzeptiert werden.
• FQDN & DNS: Wie erwähnt braucht der SBC einen festen FQDN. Dieser wird später in Teams Online registriert. In anynode wird dieser Name z. B. in den SIP Signalisierungseinstellungen referenziert (z. B. als „Contact-Header Hostname“). Der Server sollte selber seinen FQDN kennen (Windows: System Properties – Full computer name kann man passend setzen, oder Hostname+DNS-Suffix, Linux: /etc/hostname und /etc/hosts anpassen). DNS-Eintrag extern muss auf SBC-IP zeigen.
• TLS-Profile: anynode erlaubt definierte Profile – z. B. ein Profile für Microsoft (TLS1.2 only, specific cipher set), ein anderes für einen älteren PBX (wo vielleicht TLS1.0 nötig, falls überhaupt). Für Teams Direct Routing am besten Standard TLS1.2 verwenden.
• SRTP aktivieren: In anynode ist die Unterstützung für SRTP in den Mediastream-Einstellungen wichtig. Für den Microsoft-Trunk muss SRTP (optional) eingestellt sein – Microsoft kann nur SRTP, aber anynode erlaubt Offloading, falls ein unsicherer Trunk es nicht kann (dann würde anynode intern decrypt/encrypt). Auch die SDES Schlüsselparametrisierung (Crypto-Suites) muss passen; anynode kommt aber mit den von Teams geforderten (AES_CM_128_HMAC_SHA1-80) klar.
• Codec-Einstellungen: Standardmäßig unterstützt anynode alle gängigen Codecs (G.711, G.722, OPUS, G.729 etc.). Für Teams Direct Routing sind G.711u/A und OPUS relevant, wobei Teams->SBC meistens G.711 benutzt für PSTN. Es ist ratsam, im Microsoft-Trunk die Codec Policy einzuschränken auf PCMU/PCMA 8kHz, da die meisten Telefonprovider ebenfalls G.711 nutzen und so kein Transcoding nötig ist. OPUS kann man anlassen für interne Calls oder Tests, aber PSTN braucht es nicht.

Zusammengefasst: anynode aufzusetzen ist in wenigen Stunden machbar – aber die Feinjustierung (TLS, Zertifikate, Codecs) ist wichtig, bevor man an die eigentliche Kopplung geht.

Konnektivität: Anbindung an Teams und an den Provider

Nach der Grundinstallation erfolgt die eigentliche Konnektivitätseinrichtung:

• Direct Routing Konfiguration (Microsoft-Seite): Zuerst registriert man den SBC in der Microsoft-Welt. Im Teams Admin Center unter „Sprachrouting > Direktrouting“ oder via PowerShell New-CsOnlinePSTNGateway legt man den FQDN an (sbc.firma.de), gibt an, ob TLS und SRTP verwendet werden (ja, immer), optional Media Bypass (kann aktiviert werden) und einen SIP-Signalisierungsport (wenn vom Standard 5061 abweichend). Der SBC-Eintrag bleibt zunächst nicht aktiv, bis anynode sich gemeldet hat.
• Teams-Seite in anynode: In anynode legt man eine SIP-Trunk-Registrierung für Microsoft an. Hierfür wählt man TLS auf Port 5061, als Remote Domain z. B. sip.pstnhub.microsoft.com. Manche Konfigurationsassistenten sind vorhanden (anynode hat ein Wizard für Lync/Skype, aber für Teams im Prinzip analog). Wichtig: im Contact und From Header muss der SBC-FQDN stehen – anynode macht das, wenn man die Domain des Trunks auf den eigenen FQDN setzt. SNI in TLS heißt, im TLS Context muss sip.pstnhub.microsoft.com drin sein. Then, anynode initiiert eine SIP OPTIONS zu Teams – bei Erfolg sieht man im Teams Admin Center den SBC als aktiv/online.
• Provider-Trunk in anynode: Als nächstes bindet man den Telefonieanbieter an. Je nach Provider: entweder registrierender Trunk (der SBC loggt sich mit Benutzer+Pass beim Provider-SBC ein) oder IP-authentifizierter Trunk (Provider akzeptiert Calls von unserer IP). Im ersteren Fall richtet man in anynode einen Registrar ein unter Verwendung der vom Provider gegebenen Daten (SIP-Server, Port, Credential). anynode unterstützt Digest Auth etc. Im zweiten Fall legt man lediglich einen SIP Peer mit Ziel-IP/Port an. Oft hat man mehrere Ziel-IPs (Provider cluster), dann kann man Round-Robin oder Prioritäten definieren.
• Routing zwischen Microsoft und Provider: anynode arbeitet oft regelbasiert: z. B. alle eingehenden Anrufe von Teams => Route zur Provider-SIP-Trunk, und alle eingehenden Anrufe vom Provider => Route zum Microsoft-Trunk. Hierbei müssen ggf. Übersetzungen definiert werden: z. B. ein aus Teams kommender Anruf hat im SIP From: +498912345678@firma.de (Benutzer-URI) und vielleicht im P-Asserted +498912345678. Der Provider erwartet evtl. das „+“ nicht (manche wollen 0049, manche akzeptieren +). anynode kann mit RegEx-Manipulationen im Ausgehend-Dialog das + entfernen oder in 00 wandeln. Ebenso eingehend: Der Provider schickt Rufnummern manchmal im nationalen Format (ohne +49). Dann fügt anynode für Teams das +49 hinzu, bevor er an Teams weiterleitet. Diese Übersetzungsregeln (Normalization/Denormalization) sind essenziell, damit die Nummern durchgängig stimmen. Idealerweise schickt der Provider direkt E.164, dann muss man wenig tun.
• Header-Übersetzungen: Neben den Nummernformaten lohnt ein Blick auf SIP-Header: Teams erwartet gewisse Header und ignoriert andere. anynode sollte z. B. sicherstellen, eingehende Diversion oder History-info Header (bei Weiterleitungen) so zu mappen, dass Teams im Anrufverlauf den richtigen Anzeigetext bringt. Oft Standard, aber bei komplexen Weiterleitungen (etwa über PBX) kann Feinjustierung nötig sein. Outbound sollte anynode den P-Asserted-Identity setzen, wenn vom User vorhanden – bei manchen Providern muss man zusätzlich Remote-Party-ID schicken, was anynode via Konfiguration ebenfalls kann.
• CLIP/CLIR Handling im SBC: Wie im Nummernkonzept erwähnt, übernimmt anynode teils die Aufgabe, Outbound Caller ID zu setzen. Praktisch richtet man z. B. ein: Wenn der From-User = Durchwahl eines Standortes, ersetze durch Hauptnummer. Oder bei anonymen Calls entferne alle personenbeziehbaren Absenderinfos und setze Anonymous. anynode bietet eine einfache Skriptsprache oder GUI-Regeln, um Header zu manipulieren. Beispiel: Matching Rule „wenn SIP From: User enthält 7100 (Chef) und Request-URI ist extern -> setze P-Asserted auf Sekretariat-Nummer“. Solche Regeln sollten sorgfältig getestet werden, damit keine falschen Nummern rausgehen.
• Notruf-Sonderregeln: Hier werden die in Notrufkonzept entwickelten Routings konkret: In anynode legt man ein Routing an: Condition „Rufnummer = 112 oder 110“ und „Source = Microsoft“ -> Route zu Notruf-Trunk. Dabei kann man auch definieren „Manipulation: setze Absenderrufnummer = ELIN-Nummer XY“. Weiter kann man Timer definieren: Wenn 112 gewählt, dann für 30 Minuten eingehende Anrufe an ELIN XY automatisch an jenen Teams-Benutzer leiten (Rückruf-Handling). anynode hat dafür ein ELIN Feature: Beim Auslösen der Outbound-Regel speichert er eine Zuordnung im Cache.
• Testcalls mit Provider: Nachdem alles konfiguriert ist, sollte man Testanrufe machen: aus Teams raus (ins Handy z. B.), vom PSTN rein (z. B. vom Handy die Durchwahl anrufen). Debugging mit anynode: im Monitor sieht man rote/grüne Pfeile für Signalisierung, man kann per Trace-Tool die SIP-Messages anschauen (im Zweifel Wireshark). Ziel: ausgehende Calls haben korrekte Rufnummer und klingeln durch, eingehende kommen zum richtigen Teams-Benutzer (oder in die Voicemail falls offline).

Medien-Handling: Codecs, DTMF, Early Media

Ein SBC muss neben Signalisierung auch die Media-Ebene korrekt handhaben:

• Codec-Profile: In Direct Routing will man idealerweise kein Transcoding (unnötige Qualitätsverluste und CPU-Last vermeiden). Daher sollte der SBC auf beiden Seiten einen gemeinsamen Codec aushandeln. Standard ist G.711 A-Law (PCMA) in Europa. Teams unterstützt PCMU und PCMA sowie OPUS. Viele Provider sprechen PCMA, manche PCMU (USA). anynode kann Codec-Reihenfolgen priorisieren: z. B. am Microsoft-Trunk PCMA als bevorzugt angeben, am Provider auch. So nehmen beide PCMA und gut. Falls der Provider nur G.729 bietet (selten heute), müsste anynode transkodieren – dann CPU-Bedarf beachten und entsprechende Lizenz (Transcoding erfordert Lizenz, aber anynode ist i.d.R. dafür freigeschaltet).
• DTMF-Handling: DTMF (Tonwahl, z. B. für Telefonmenüs) wird über verschiedene Methoden übertragen: Inband (Töne im Audiostream) oder Out-of-band per SIP INFO oder RFC2833/4733 RTP Events. Teams verwendet primär RTP Events (aus SRTP-Perspektive), also out-of-band im RTP-Stream. Die meisten SIP-Trunks auch. anynode sollte so konfiguriert sein, dass er DTMF von Teams empfängt (als RTP-Event) und transparent an den Carrier weitergibt, oder falls nötig in INFO umwandelt. In der anynode-Konfig pro Trunk stellt man den DTMF-Modus ein: z. B. RFC2833 on both sides. Im Optimalfall kann man bridging vermeiden – anynode lässt die RTP Events einfach durch. Problematisch wird’s, wenn ein angrenzendes System nur Inband versteht (z. B. analog Gateway fax/dtmf). Dann muss anynode das Inband-Signal demodulieren – dafür hat er eine Funktion, aber Qualität kann leiden.
• Early Media (frühe Medien): Early Media ist Audio, das übertragen wird, bevor der Anruf angenommen wurde (z. B. Klingelton vom Provider, Warteschleifenmusik, Ansage „Dieser Anschluss ist vorübergehend nicht erreichbar“). Teams-Clients erwarten je nach Fall diese Töne. Damit sie hörbar sind, muss anynode die 183 Session Progress + SDP vom Provider an Teams weitergeben und den Audiopfad schon aufmachen. Standardmäßig macht er das, solange kein Codec-Mismatch besteht. Wichtig: In Direct Routing muss man „Enable Forwarding of Early Media“ nicht explizit anschalten, es passiert nach SIP-Standard. Aber wenn man z. B. an der PBX-Seite Early Media blockiert (manche PBX reagieren erst bei 200 OK), kann es sein, dass der Anrufer Stille hört statt Besetztton. Also: Testen Sie Szenarien wie „besetzte externe Nummer“ oder Anruf auf Mobilbox – hört der Teams-Benutzer die Ansage? Wenn nein, am anynode prüfen, ob er evtl. 183 ignoriert.
• Media Bypass: Wenn Media Bypass aktiviert ist, schickt Teams-Client sein RTP direkt an anynode. anynode muss dann ICE-StUN Pakete vom Client beantworten. Das tut anynode, wenn Media Bypass=Yes im Gateway Setup und ICE unterstützt (er ist ICE-lite, d.h. er antwortet nur). Der Client wiederum versucht alle Kandidaten: direkt auf SBC public IP, ggf. über TURN. Überprüfen: Wenn User im gleichen LAN wie SBC, fließt Audio-Lokalschleife (optimal). Wenn über Internet, fließt es Client->SBC direct. Falls da Firewalls stören, kann es sein, dass fallback über Microsoft-Relay doch nötig ist. In anynode Monitoring sieht man, ob ein Call „via Relay“ oder „via Bypass“ kam.
• Quality Features: anynode sammelt MOS (Mean Opinion Score) per Call, wenn aktiviert. Das kann helfen, Problemstellen zu finden. Er hat Jitterbuffer-Einstellungen, normalerweise dynamisch. Man kann, falls notwendig, Paketreihenfolge und Verzögerung optimieren, aber Default reicht oft.

Hochverfügbarkeit im anynode-Betrieb

Für Redundanz im Betrieb bietet anynode verschiedene Möglichkeiten:

• Aktiv/Passiv (Hot Standby mit Floating IP): anynode unterstützt eine Hot-Standby-Konfiguration, in der zwei Instanzen miteinander verbunden sind. Man konfiguriert einen Standby-Host im anynode-Manager und definiert z. B. eine virtuelle IP-Adresse, die zwischen beiden Knoten wechselt. Der aktive Knoten sendet in regelmäßigen Abständen ein „Hello“ an die passive Instanz. Fällt er aus (kein Hello mehr, oder per Heartbeat TCP Verbindungsabbruch), übernimmt der passive Knoten die virtuelle IP durch ARP Announcement. Aus Sicht der Außenwelt (Teams, Provider) wechselt also nur die MAC, die IP bleibt. Diese Umschaltung dauert oft nur 5–10 Sekunden. Bestehende Anrufe sind in dem Moment leider weg (der neue Knoten kennt die Session nicht), aber neue Anrufe gehen sofort wieder. Admins sollten im HA-Fall alarmiert werden (anynode loggt Failover-Ereignis). Das Setup eines Hot-Standby-Paares erfordert, dass beide Knoten im gleichen Netzwerk/LAN-Segment operieren (für Floating IP und ARP). Bei Cloud VMs ist das tricky – dort eher DNS RoundRobin als Alternative.
• Aktiv/Aktiv (Load Sharing): anynode selbst hat kein stateful Active/Active Clustering (wo beide dieselbe IP teilen und Sessions synchron halten). Aber man kann zwei unabhängige anynodes parallel betreiben. In Teams würde man beide als separate PSTN Gateways eintragen oder mittels DNS SRV für denselben FQDN mehrere IPs ausliefern. Das bedingt aber, dass beide autark funktionieren, und kein Call failovern kann – er startet immer nur auf einem. Active/Active nützt vor allem bei Lastverteilung. Für echte Ausfallsicherheit plus Lastverteilung könnte man eine Region mit Active/Passive und global zwei Standorte Active/Passive fahren – recht aufwendig.
• Heartbeat und Überwachung: anynode’s Hot Standby Mechanismus ist im System implementiert. Darüber hinaus kann man mit externem Monitoring (z. B. ein PRTG Ping) die Erreichbarkeit checken. anynode reagiert auf SIP Options (auch Standby kann so tun als ob, je nach Konfig, um Teams nicht zu irritieren).
• State Synchronisation: anynode synchronisiert im HotStandby kritische Dinge wie die Registrations (z. B. bei SIP-Provider Login) und die dynamischen Daten (ELIN Mapping, laufende Transaktionen etc. nicht). D.h. nach Failover muss z. B. der Register am Provider neu gesendet werden, aber Credentials hat er. Wenn der Primär zurückkommt, kann man manuell oder automatisch failbacken.
• Split-Brain vermeiden: Bei HA immer daran denken, IP nur einer aktiv – anynode hat Mechanismen, dass Standby nicht übernimmt, solange er den Master noch „sieht“. Ein dediziertes Heartbeat-Netzwerk (z. B. Crossover-Kabel oder eigenes VLAN) zwischen den beiden Knoten ist ideal, damit sie nur sich austauschen und kein externer Traffic stört.
• Geo-Failover manuell: In Notfällen kann man auch händisch umschalten: z. B. Teams-Admin kann im Tenant eine Route auf den anderen SBC priorisieren, oder DNS A-Record auf andere IP ändern. Solche Notfallpläne sollten vorhanden sein und geübt (z. B. was tun wenn komplettes Rechenzentrum offline? – Plan: in Azure-VM Backup-SBC hochfahren, DNS umbiegen, hoffen TTL ist kurz).

Kurzum, anynode bietet solide HA-Optionen für lokale Redundanz. Darüberhinausgehende geo-Redundanz erfordert architektonische Planung (wie in Zielarchitektur-Teil beschrieben).

Betrieb: Monitoring, Logging, Backup und Update

Im laufenden Betrieb eines anynode-SBC gibt es wiederkehrende Aufgaben:

• Logging & CDRs: anynode protokolliert Ereignisse in verschiedenen Logs: System-Log (Dienststart, Lizenzinfos etc.), Call-Log (jeder Call Start/Ende, Dauer, wer rief wen) und optional detaillierte SIP Trace Logs. Für Routine reicht meist das Call Detail Record (CDR) Logging: Hier kann man Abfrage-Tools oder Syslog nutzen, um z. B. Gesprächsdaten an ein zentrales System zu schicken. Wichtig für Abrechnung und Analyse. Allerdings DSGVO beachten: CDRs enthalten Rufnummern und Zeit – Zugriff beschränken.
• Alarmierung: anynode kann SNMP-Traps oder E-Mails bei kritischen Events senden (Lizenz expire, Trunk unreachable etc.). Empfehlung: SNMPv3 einrichten Richtung Monitoring-System, damit Ausfälle sofort sichtbar sind. Zudem Teams admin center warnt bei SBC offline > 10min.
• Dashboard-Kennzahlen: Im anynode Dashboard sieht man aktuelle Calls, Registrations, Last etc. Diese Werte kann man auch via REST API von anynode ziehen, um sie in eigene Dashboards (Grafana etc.) zu integrieren. Typische Kennzahlen: Concurrent Calls, Calls per Hour, Packet Loss per Leg, CPU Usage, Memory, License usage. Werden Limits erreicht (z. B. 95% Lizenzkanäle genutzt), sollte man planen, zu erweitern.
• Backup & Restore: Nach dem Einrichten sollte die anynode-Konfiguration gesichert werden. anynode bietet Export in eine .anynode Datei (XML enthalten). Man kann diese Datei auf dem Backup-System einspielen. Automatisiert kann man per Script z. B. nightly Export machen und wegsichern. Daten wie Zertifikate sind oft nicht inbegriffen (bzw. verschlüsselt) – die muss man separat sichern. Auch Syslogs und CDRs archivieren nach einer Zeit, um Speicher frei zu halten.
• Update-Fenster: TE-Systems bringt regelmäßige Updates für anynode (Bugfixes, neue Features, Anpassungen an geänderte Teams-Schnittstellen). Im Enterprise-Einsatz sollte man einen Wartungsplan haben: z. B. alle 6-12 Monate prüfen, ob Update notwendig. Updates sind meist in-place: Service down, neue Version installiert, Service up – dauert wenige Minuten. Trotzdem sollte es in Nebenzeiten erfolgen, da aktive Calls unterbrochen werden. In Hot-Standby-Setups kann man erst Standby updaten, dann Failover forcieren und Primär updaten – so ist Downtime minimal (1x Failover).
• Rollback: Man behält idealerweise die vorherige Installationsdatei parat. Falls nach Update Probleme auftreten (z. B. ein neuer Codec-Bug), sollte man den alten Stand wiederherstellen können. In virtuellen Umgebungen bieten sich Snapshots vor Update an, um schnell rückgängig zu machen. anynode Config-Export vor dem Update ist auch sinnvoll, falls Format-Änderungen passieren.
• Kapazitätsanpassung: Betrieb heißt auch, vorausschauend Kapazitäten zu planen. Steigt Call-Volumen, kann man additional Kanäle lizenzieren. TE-Systems hat flexible Lizenzmodelle (permanent oder subscription). Eine Auswertung, wie oft Spitzen nahe Lizenzlimit kamen, gehört zum regelmäßigen Betrieb (z. B. quartalsweise Review).
• Security-Patching: Der SBC läuft auf OS-Ebene – also Windows Updates oder Linux Patches sind durchzuführen (TLS-Sicherheit!). Hier ist Plan gefragt: am besten in normalen Patchzyklus der Server aufnehmen. Reboot eines SBC-Servers aber nur, wenn kein Call läuft: entweder vorher in Wartung alle Calls raus oder in der Nacht. anynode selbst startet schnell (<1 min).
• Konfig-Änderungen: Kleinere Änderungen (neue Rufnummer, Routing tweak) kommen vor. In anynode werden Änderungen im laufenden Betrieb übernommen, sobald man auf „Apply“ klickt. Vorsicht: einige Änderungen (z. B. Netzwerkinterfaces) könnten Calls droppen. Daher möglichst Änderungen außerhalb Stoßzeiten. Und auch hier immer Export-Backup vorm Spiel.

anynode-Konfigurationsbausteine (typische Bereiche)

Die anynode-Konfiguration lässt sich in Bereiche gliedern – mit einigen typischen Einstellungen, Fehlern und Prüfschritten:

Diese Tabelle fasst zusammen: vom Trunk Setup über Routing/Manipulation bis zu HA und Logging – jeder Bereich hat seine Tücken. Durch ein systematisches Vorgehen (Plan – Do – Check – Act) stellt man sicher, dass der SBC stabil und korrekt läuft.

Checkliste: Go-Live mit anynode

Bevor der große Umschalt-Moment kommt, sollte folgende Punkte kontrolliert sein:

• [ ] Vorbedingungen erfüllt: Alle nötigen Microsoft-Lizenzen sind zugewiesen (User haben Phone System Lizenz, ggf. Calling Plan entfernt, damit Direct Routing greift). Die Domain firma.de ist in O365 verifiziert (für SBC-FQDN wichtig). Der SIP-Trunk vom Carrier ist bereit (Portierung abgeschlossen, Rufnummern aktiv).
• [ ] Zertifikate & DNS ok: SBC-Zertifikat getestet (z. B. mit Test-CsOnlinePSTNGateway oder OpenSSL verify). DNS-Einträge (SBC-FQDN) zeigen auf korrekte IP. Gültigkeit der Zertifikate deckt mindestens die geplante Laufzeit + Puffer ab.
• [ ] Trunks konfiguriert und registriert: anynode zeigt grünen Status für die Verbindung zu Microsoft (Options Response Received) und ggf. grünen Status beim Provider (Registered oder Link up). Keine Fehlermeldungen im anynode Dashboard ersichtlich.
• [ ] Nummern & Routing eingerichtet: Alle Benutzer haben korrekte LineURI (inkl +, keine Dopplungen). Voice Routing Policies sind den Usern zugewiesen wie geplant. Dial Plan Normalisierungen greifen (Stichproben mit Test-CsEffectiveTenantDialPlan gemacht). Im anynode sind alle Durchwahl-Range-Regeln implementiert. Sondernummern (Notruf, Firmen-Hotlines) sind in den Routen berücksichtigt.
• [ ] Probe-Anrufe durchgeführt: – Intern: Teams-zu-Teams Gespräche funktionieren weiterhin (zur Sicherheit). – Ausgehend extern: Testanrufe ins Festnetz und Mobilfunk: Gespräch kommt an, Qualität gut, eigene Nummer wird korrekt angezeigt (verschiedene User probieren, ggf. inkl. unterdrückter Nummer). – Eingehend extern: Von externen Handys Festnetznummern im neuen System anrufen: alle Durchwahlen erreichen den richtigen Teams-User oder die eingestellte Gruppe. CLIP der Anrufer erscheint beim Teams-Nutzer. – Notruf (trocken): Ohne tatsächlich 112 zu wählen, einen simulierten Test (z. B. Testnummer beim Provider, oder letzte 3 Ziffern 112 an internen Anschluss) durchführen, um zu sehen, ob anynode die Route greifen würde. Falls möglich mit Leitstelle Test abgesprochen (siehe Notruf-Tests Checkliste oben).
• [ ] Benutzerendgeräte bereit: Falls IP-Telefone eingesetzt werden (z. B. Konferenztelefone, Lobby-Phones), sind diese eingerichtet, angemeldet und getestet. Headsets der User funktionieren, Teams-App ist aktuell. Common Area Phones für Notfall sind angebracht und getestet (Wählt 112 -> hört Wählton, dann gleich wieder aufgelegt im Test).
• [ ] Monitoring scharf geschaltet: Kurz vor Go-Live die Monitoring-Tools final aktivieren: CQD für neue PSTN-Daten checken, anynode-SNMP an, eventuell einen Live-Dashboard (Calls in progress) im IT-Bereich aufstellen. Zuständiges Support-Team in Alarmierungs-E-Mails eingetragen.
• [ ] Fallback-Plan vorhanden: Für den Tag X definieren, was bei größeren Problemen passiert: z. B. „Zurück auf alte Anlage schalten“ – dafür muss evtl. eine Rufumleitung beim Provider parat sein. Notfallkontakte (Provider NOC, Microsoft Premier Support) sind griffbereit.
• [ ] Kommunikation & Support: Benutzer wurden informiert, ab wann die neue Telefonie gilt und wie sie Support erhalten (neue Kurzwahl oder Ticket). Das Helpdesk-Team ist gebrieft, typische Fragen (Voicemail PIN, Anruf-parken etc.) beantworten zu können. Eine erhöhte Unterstützungsbereitschaft (Hypercare) ist in den ersten Tagen organisiert.

Wenn all dies abgehakt ist, kann man mit Zuversicht den Schalter umlegen bzw. die Nummern portieren. Während des Go-Live sollte man in den ersten Stunden engmaschig kontrollieren (Testanrufe reihum), um sofort einzugreifen, falls etwas klemmt.

Funktionen & Integrationen

Wichtige Telefonie-Funktionen in Teams

Microsoft Teams Phone bietet eine Reihe von Telefonie- und PBX-Funktionen, die im Unternehmensalltag benötigt werden. Im Gegensatz zu traditionellen Anlagen muss man sich hier an teils neue Ansätze gewöhnen:

• Auto Attendants (Automatische Telefonzentralen): Das sind mehrstufige Sprachmenüs, die Anrufer begrüßen („Willkommen bei …, für Vertrieb drücken Sie 1…“) und dann je nach Eingabe weiterleiten. In Teams werden Auto Attendants cloudseitig konfiguriert (mit Geschäftszeiten, Ansagen etc.) und können per Service-Rufnummer erreichbar gemacht werden. Über Direct Routing kann anynode die DDI einer alten Zentrale (z. B. -0) auf die Teams-Service-Nummer routen. Der Vorteil: Menüs können zeitabhängig geschaltet werden, und auch mehrsprachige Optionen sind möglich.
• Call Queues (Anrufwarteschlangen): Dies sind Gruppen von Agents (z. B. Helpdesk-Team), die Anrufe in der Reihenfolge verteilen. Teams-Callqueues bieten Wartemusik, Verteilerstrategien (parallel, serial, Round Robin) und optional Voice Mail als Overflow. Agents können dynamisch ein-/austreten (via Teams-Client). In Direct Routing funktioniert das, indem man auch hier entweder Microsoft-Service-Nummern verwendet oder über den SBC an eine dummy User mit der Queue routet. Normalerweise bezieht man für AA und CQ sogenannte virtuelle Benutzerlizenzen (kostenlos), um die Dienste zu aktivieren.
• Voicemail: Teams hat Cloud-Voicemail (gehostet in Exchange Online). Jeder User mit Telefonie kann eine Voicemail nutzen. Wenn der Benutzer offline ist oder nicht abhebt, greift nach konfigurierter Klingeldauer (Standard 20s) die Voicemail. Diese nimmt eine Nachricht an und schickt eine Transkription per E-Mail an den User. Der Anwender kann die Nachrichten auch in Teams abspielen. Als Admin kann man via Richtlinie einstellen, ob Voicemail aktiv sein soll und ob z. B. Anrufer selbst eine Nummer drücken können, um andere Optionen (wie „weiter verbinden zu Sekretariat“) zu nutzen. Aus SBC-Sicht muss man nichts Besonderes tun – außer ggf. sicherstellen, dass Anrufernummern im E.164-Format bei der Voicemail ankommen, damit die Email die richtige Caller-ID zeigt.
• Delegation und Teamanruf: Viele Führungskräfte nutzen das Chef/Sekretärin-Prinzip – in Teams über Anrufdelegation abbildbar. Der Vorgesetzte trägt einen oder mehrere Stellvertreter ein, die seine Anrufe annehmen dürfen. Bei einem Anruf klingelt es dann gleichzeitig beim Delegierten. Dieser kann das Gespräch annehmen, übertragen etc. Aus technischer Sicht passiert dies alles in der Cloud – der SBC kriegt nur den normalen Anruf an den Chef, aber Teams entscheidet parallel zum Delegat zu schicken. Der SBC muss keine extra Funktion unterstützen (früher brauchte man BLF-Lampen etc., Teams verzichtet auf physische Lämpchen und löst es softwareseitig).
• Anruf parken: Diese Funktion erlaubt es, ein Gespräch in die „Warteschleife“ zu legen und an einem anderen Gerät wieder aufzunehmen. In Teams kann ein Benutzer im aktiven Call auf „Parken“ klicken, dann erhält er einen Code (z. B. 105). Eine andere Person gibt diesen Code ein und übernimmt den Call. Im Hintergrund agiert ein Dienst in der Cloud, der diesen geparkten Call hält. Der SBC ist beteiligt, weil der geparkte Call technisch weiter verbunden bleibt zur Cloud bis Abholung. Konfigurationseitig muss man Park-Orbits definieren (Bereiche für Codes). Im DACH-Raum wird Anrufparken eher selten noch genutzt – doch z. B. für Empfang lohnt es sich (wenn etwa jemand intern nicht rangeht, kann man den Kunden parken und Durchsage machen „Herr X bitte 105 wählen“).
• Busy-on-Busy und Besetztlampenfeld: Busy-on-Busy (Besetzt bei besetzt) kann via Richtlinie aktiviert werden: Dann hört ein zweiter Anrufer Besetztton, wenn man schon telefoniert, statt in Voicemail zu landen. Das simuliert das klassische Besetztgefühl. Ein echtes Besetztlampenfeld (BLF), wo ein Telefon zeigt, ob ein Kollege telefoniert, hat Teams so nicht. Alternativen: Teams zeigt Präsenz „Im Gespräch“ an, was ungefähr BLF ersetzt, aber auf einem Tischtelefon z. B. sieht man nur via Bildschirm, nicht via dedizierte Lampen. Für Empfang gibt es Teams Attendant Console Lösungen (Drittanbieter), die auf dem PC mit Anwesenheitslisten arbeiten. In der Planung muss man solche BLF-Wünsche entweder mit „in Teams nicht verfügbar, Workaround ist Präsenzanzeige“ beantworten oder auf Partnerprodukte verweisen.
• Teams-Telefone und Clients: Als Endgeräte können standard Teams-Clients auf PC und Smartphone fungieren. Zusätzlich gibt es Teams-zertifizierte Telefone (von Yealink, Poly, Audiocodes etc.). Diese laufen mit einem speziellen Teams-App als Firmware. Sie unterstützen Funktionen wie Halten, Transfer, Voicemailtaste etc., aber teils noch nicht alles was ein PC kann. Wichtig: Firmware aktuell halten – sie werden via Teams Admin Center gemanagt. Ein SBC-Einfluss besteht hier nicht. Konferenzraum-Systeme (Teams Rooms) können auch PSTN calls machen oder einnehmen, aber nur via Meeting dial-out oder sekundäre Telefonnummer.

Insgesamt bietet Teams also viele Standard-TK-Funktionen, aber manches ist „anders gelöst“. Die IT sollte Anwender schulen, wo die Funktionen zu finden sind (z. B. „Parken“ ist eine extra Schaltfläche, Delegation richtet man in Einstellungen ein etc.).

Integration von Sondergeräten und -Systemen

Viele Unternehmen haben Sondergeräte im Einsatz, die weiterhin funktional bleiben müssen, etwa Faxgeräte, Türsprechstellen, Alarmanlagen, analoge Telefone, DECT-Systeme. Die Integration solcher Geräte erfordert individuelle Lösungen, oft in Kombination mit dem SBC:

• Fax (T.38 / Passthrough): Fax über VoIP ist notorisch heikel, aber machbar. Grundsätzlich kann Teams nicht selbst faxen, aber man kann Faxe weiter auf traditionelle Faxempfänger routen. Zwei Ansätze:
• Analoges Faxgerät via ATA: Ein Analog-Telefon-Adapter (ATA) wird per SIP an den anynode angebunden (als eigener „kleiner SIP-Client“). Der ATA wandelt das Faxmodem-Signal in Audio um. anynode leitet es als normalen Call über den Provider – idealerweise mit T.38-Faxprotokoll Unterstützung. T.38 ist ein spezielles Protokoll, das Faxe paketiert (reduziert Fehler). anynode kann als Vermittler G.711 nach T.38 wandeln, wenn der Provider T.38 kann. Einige Provider unterstützen T.38 auf ihren SIP-Trunks, was die Erfolgsquote erhöht. Wenn nicht, läuft Fax im Audio-Passthrough (G.711) – leichte Verluste können Fax stören, oft hilft Umschalten auf Halbduplex und langsame Übertragungsraten. Wichtig: Fehlerkorrektur (ECM) am Fax abschalten bei VoIP.
• Fax-Server / Cloud-Fax: Alternativ kann man Faxe über einen Fax-Service abwickeln und auf E-Mail zustellen lassen. Integration dann: Rufnummer für Fax wird im SBC direkt auf den Fax-Service weitergeleitet (z. B. via DNS SRV an Cloudfax-Anbieter) oder man betreibt einen kleinen Fax-Server (z. B. mit XCAPI, FerrariFax etc.), der als SIP Endpoint am anynode hängt. In jedem Fall lieber getrennt vom Teams-Ökosystem halten, da Fax qualitativ nicht 100% in Teams passt.
• DECT-Systeme: In Umgebungen mit schnurlosen Telefonen (z. B. in Lagerhallen, Krankenhäusern) will man vielleicht nicht alle DECT gegen Smartphones tauschen. Integration: Moderne DECT-Systeme (z. B. von Spectralink, Ascom) unterstützen SIP – man kann diese wie eine eigene kleine PBX an den anynode koppeln. Man vergibt ihnen eine Nebenstellenrange (z. B. 3xx) und definiert im SBC: Anrufe zu 3xx -> an DECT-Server IP schicken; und umgekehrt, von DECT-Server kommende -> über Teams raustelefonieren oder an Team-User. So können DECT-Handsets weiterhin genutzt werden. Will man DECT-Nutzer in Teams anzeigen, kann man deren Nummern als Kontakte in Teams anlegen, aber Präsenz etc. geht nicht.
  Bestehende PBX mit DECT: Häufig belässt man sie und bindet PBX via SBC an (siehe Hybrid). Dann verbleiben DECT auf der PBX, Teams-Nutzer erreichen diese via PBX-Routing.
  Achten: Taktung, Notrufe – DECT-User in Teams-Umfeld sollten auch Notruf absetzen können, evtl. belässt man in DECT-Basis direkte Amtsleitung für Notruf falls Integration unsicher.
• IoT/Alarmserver: Fertigungsanlagen, Alarmsysteme oder Aufzüge haben oft Wählgeräte, die Alarmanrufe absetzen (z. B. Brandmeldeanlage ruft Wachschutz an). Solche Geräte sind oft analog (am klassischen Amtsanschluss) oder ISDN. Hier empfiehlt es sich, separate Gateways einzusetzen: Ein kleines VoIP-Gateway mit FXS/FXO oder ISDN-S0, das an anynode angeschlossen wird. Man gibt dem Gateway eine SIP-Identität, z. B. „Alarmserver“ mit eigener Rufnummer. anynode routet Anrufe dieser „Nebenstelle“ ins PSTN (z. B. zur Feuerwehr). Auch eingehend kann anynode Anrufe an diese Endpunkte leiten, falls benötigt (z. B. zentrale Leitstelle ruft zurück).
  Wichtig: Verfügbarkeit – Alarmserver sollten möglichst nicht vom Internet abhängig sein. Wenn sie absolut kritisch sind (Feuerwehrlauf über Telefon), könnte man statt über Teams immer noch einen Analoganschluss zusätzlich behalten. Wenn nicht, dann redundante Internetverbindung für den SBC einplanen oder Mobilfunk-Gateway als Backup.
• Türsprechstellen / Gegensprechanlagen: Moderne Türsprechstellen (z. B. von Baudisch, Siedle mit Adapter) können als SIP-Client agieren. Diese registriert man auf anynode als Endpunkt mit einer Kurzwahl (z. B. 400 für Haupteingang). Klingelt jemand, initiiert die Türsprechstelle einen Anruf an 400 -> anynode nimmt entgegen und routet z. B. zu einer Teams Call Queue „Empfang“, sodass es bei allen Empfangs-MAs klingelt. Die können per Teams mit dem Besucher sprechen. Soll auch die Tür geöffnet werden, muss das System einen DTMF-Code erwarten – hier Integration: Empfangs-MA drückt am Teams-Client #9 z. B., das wird als DTMF via anynode an die Tür weitergereicht und diese öffnet (das setzt voraus, DTMF passt, wie oben besprochen). anynode muss also erlauben, dass DTMF von Teams->Tür inband/in RTP ankommt, etc. Das sollte gehen, wenn Codecs ok. Manche Türsysteme erlauben auch HTTP triggers – aber gehen wir von DTMF aus. Test: Tür klingeln, in Teams abheben, Code drücken -> Tür sollte summen.
  Alte Türsprechanlagen (nur analog Zweidraht) kann man via ATA adaptieren – dann verhält es sich wie ein analoges Telefon, das anruft, und DTMF über FXS erkennt.
• Analoge Telefone / Geräte: Obwohl man versucht, analoges loszuwerden, gibt es vlt. doch Faxgerät im Chefzimmer, EC-Karten-Terminals, Modems für Heizung etc. Hier ist die pragmatische Lösung: Analogadapter (ATA) mit SIP-Anbindung wie bei Fax. Jedes analoge Gerät bekommt eine interne SIP-Kennung am anynode. Je nach Gerät muss man Feinheiten beachten:
• EC-Terminals: Viele funktionieren heute analog über VoIP schlecht (Latenz, kein echtes Modem über IP). Besser umstellen auf IP-Terminal. Wenn nicht, versuchen via ATA auf G.711, Echo Canceler aus, Jitter minimal – doch es kann fehlschlagen. Alternativ: analoges Anschaltgerät vom Provider weiter nutzen (z. B. die Telekom Digitalisierungsbox nur für Terminal).
• Modems/Remoteüberwachung: Ähnlich wie Fax sehr problematisch – wenn unabdingbar, vlt. separate analoge Leitung dafür belassen.
• Bestehende Contact Center oder IVR-Systeme: Manchmal hat man ein separates Kundenkontakt-Center (z. B. Genesys, Avaya) im Einsatz, das noch nicht ersetzt wird. Integration: Dieses System kann oft via SIP-Trunk an Teams angebunden werden. anynode kann dann als Gateway fungieren: Er bildet eine SIP-Verbindung zum Contact Center und eine nach Teams – so können Anrufe zwischen beiden Welten fließen. Wichtig ist, die Nebenstellen-/Rufnummernverteilung zu planen, damit keine Routingkonflikte auftreten (z. B. nutzt das CC vielleicht 5000er Nummern intern, also nicht im Teams Dial Plan als User-Nummern verwenden).
  Ähnliches gilt für Voicemail-Server, Sprachaufzeichnungssysteme etc.
• Teams-spezifische Integrationen: Teams als Plattform lässt sich auch via Graph API oder Bot Framework erweitern, z. B. ein Compliance Recording Bot, der alle Calls mithört. Diese Integrationen laufen aber eher in der Cloud und tangieren den SBC nicht direkt – man muss nur sicherstellen, dass solche Bots im Tenant autorisiert sind.

In allen Fällen sollte das Integrationsthema im Projekt früh erkannt werden: Inventarisierung aller Non-Teams-Geräte mit Telefon-Anbindung und Entscheidung, ob erhalten (-> integrieren) oder ablösen (z. B. analoges Telefon ersetzen durch Teams-Phone). Die Integration über anynode ist mächtig, aber jeder Spezialfall erhöht die Komplexität. Daher nur wo wirklich nötig einsetzen.

Integrations-Landkarte (Systeme und Anschlussarten)

Eine Übersichtstabelle möglicher Integrationen und Hinweise:

Die Tabelle macht klar: Der SBC spielt oft Vermittlerrolle bei Integrationen, aber es gibt immer Restrisiken. Testen und regelmäße Überwachung dieser Spezialfälle ist unerlässlich, da sie oft nur selten genutzt werden – Fehler fallen dann spät auf (z.B. Fax erst bemerkt, wenn es einmal im Monat jemand braucht).

Migration & Rollout

Planung, Inventarisierung und Parallelbetrieb

Ein erfolgreicher Rollout setzt akribische Planung voraus:

• Ist-Analyse & Inventar: Zu Beginn steht die Aufnahme des Ist-Zustands: Welche TK-Systeme, Leitungen, Rufnummern sind vorhanden? Liste aller Durchwahlen, Hauptnummern, Fax, Sonderanschlüsse, Verträge mit Carriern (Kündigungsfristen!). Ebenso: welche Nutzergruppen gibt es, wer hat evtl. spezielle Anforderungen (Chef mit Sekretariat, Hotline-Teams, Schichtbetrieb etc.). Erstellen Sie einen Migrationskatalog: z. B. „Zentrale +49 89 12345-0 -> wird Teams Auto Attendant; Durchwahl 100-399 -> werden Teams-User; Alarmleitung 112 -> bleibt analog“ etc.
• Zielbild und Architekturdesign: Basierend auf den Anforderungen definieren Sie das Zielbild: z. B. „Alle Benutzer auf Teams-Telefonie, PBX X wird abgelöst, anynode SBC in Azure mit SIP-Trunk von Provider Y, Notruf pro Standort via anynode ELIN“. Erstellen Sie ein High-Level-Design-Dokument, das auch Nicht-Techniker verstehen (Diagramme der alten vs neuen Lösung). So erreichen Sie Abgleich mit Stakeholdern (Management, Betriebsrat falls relevant, IT-Security für Freigaben etc.).
• Parallelbetrieb vs. Big Bang: Entscheiden Sie, ob ein Parallelbetrieb möglich/sinnvoll ist. Oft wird phasenweise migriert: Die alte Anlage bleibt zunächst angeschaltet, während erste Pilot-User auf Teams telefonieren (ihre Nummern werden zur Cloud geroutet). Parallelbetrieb erfordert: entweder Rufnummernblock-Teilportierung (schwierig wenn ein Block zusammenhängt) oder Umleitungen. Manche lösen es so: Pilotnutzer bekommen temporäre Cloud-Nummern für Tests, während alte Nummer auf PBX bleibt; oder man leitet vom PBX eingehend auf SBC->Teams (wenn PBX das kann). Ist Parallel schwierig, kann man einen Standort nach dem anderen umschalten – was in Summe ähnlichen Effekt hat (Teil der Firma neu, Teil alt, aber wenig interne Anrufe zwischen, wenn geographisch getrennt).
• Nummernportierung und -Übergabe: Falls Rufnummern zu neuem Provider oder zu Microsoft portiert werden müssen, sind die Zeitläufe und Verfahren zu beachten. In DACH dauert Portierung oft 1-2 Wochen nach Anmeldung, mit fixem Schalttermin. Planen Sie Puffer: Bestellen Sie neue SIP-Trunks rechtzeitig; portieren Sie im Zweifel erst nach erfolgreichem Pilot, nicht schon vor Rollout. Beachten Sie, dass während Portierung kurze Unterbrüche auftreten können. Tipp: Wenn möglich, gestaffelte Portierung – z. B. erst 10% der Nummern (Pilotgruppe) portieren, später den Rest – so kann man das in Etappen prüfen. Manche Carrier bieten „SIP-Trunk auf bestehendem ISDN“ als Test, um Übergang zu erleichtern.
• Pilotierung: Ein Pilot mit wohlwollenden Nutzern ist Gold wert. Wählen Sie z. B. die IT-Abteilung oder ein kleines Team pro Standort aus, um einige Wochen vor dem offiziellen Rollout Teams-Telefonie live zu testen. Geben Sie ihnen Schulung und einen Feedback-Kanal. Lassen Sie sie alle Funktionen austesten (auch Notruf Test intern!). Aus dem Pilot lernen Sie: Wo hakt die Bedienung? Welche technischen Issues tauchen auf (vielleicht ein bestimmter Telefonprovider, der DTMF anders braucht, etc.)? Passen Sie anhand des Feedbacks die Konfiguration an. Pilotuser sollten sowohl ins Festnetz telefonieren als auch angerufen werden – sorgen Sie also dafür, dass deren Nummern erreichbar sind (ggf. per Rufweiterleitung von alter Nummer).
• Koexistenz mit alter TK: In Übergangsphasen definieren Sie, wie interne Anrufe gehandhabt werden: Z. B. ein Teams-Nutzer will einen Kollegen erreichen, der noch auf alter PBX ist. Idealerweise richten Sie im SBC dafür Routing ein: Teams erkennt, dass diese Durchwahl noch nicht in Teams existiert, und sendet an SBC, der es an PBX weiterleitet. Oder Sie nutzen kurzzeitig Doppelnutzer: Mitarbeiter hat noch sein altes Telefon parallel zum Teams-Client, bis Migration durch ist (macht aber Anrufer unsicher, wo klingeln). Besser ist definierte Umschaltpunkte pro Abteilung.
• Schrittweise Umstellung (Wellen): Planen Sie Rollout-Wellen: Zum Beispiel Welle 1: IT und HR Abteilung in KW X; Welle 2: Standort A in KW Y; Welle 3: Standort B in KW Z. Jeweils mit ausreichend Puffer dazwischen, um Probleme der vorherigen Welle zu lösen. Ggf. lassen Sie jeweils 1–2 Wochen Stabilisierung bevor nächste Gruppe kommt. Kommunikation an Betroffene sollte detailliert sein (siehe später).
• Abschaltung Alt-System: Definieren Sie auch, wann das alte System endgültig abgeschaltet wird. Nicht dass es ewig parallel läuft und niemand fühlt sich zuständig. Nach dem finalen Portierungstag sollte man noch z. B. einen Monat drüber das alte System eingeschränkt (nur eingehend Umleitung) lassen, dann abbauen. Archivieren Sie Konfigurationen, damit bei Audit oder Nachfragen (z. B. Abrechnung alter Anlage) noch Daten da sind.

Change- & Release-Management, Kommunikation und Abnahme

Der Wechsel der Telefonie betrifft die ganze Organisation – Change-Management und Akzeptanz sind daher kritisch:

• Change-/Release-Management: Behandeln Sie die Telefonieeinführung wie ein IT-Großprojekt mit Change Management. D.h. jeder Änderungsschritt (Portierung, Routingänderung, Firmware-Update Telefone) sollte über das interne CAB (Change Advisory Board) laufen, mit Backout-Plan. Dadurch sind alle relevanten Bereiche (Netzwerk, Security, Helpdesk) informiert. Legen Sie Freeze-Phasen fest, in denen keine unnötigen anderen Änderungen im Netz passieren (z. B. kein Firewall-Firmwareupdate am Tag nach Telefoniemigration – Minimieren von Variablen).
• Kommunikationsplan: Erstellen Sie einen Kommunikationsplan für die Benutzer: Was erfahren sie wann? Beispielsweise: 4 Wochen vorher Ankündigung „Teams-Telefonie kommt – das ändert sich für Sie“, 1 Woche vorher Erinnerung + evtl. eine Kurzanleitung verteilen, am Umstellungstag Betriebsmitteilung „Heute Umstellung erfolgreich – bei Fragen hier melden“. Nutzen Sie vorhandene Kanäle: E-Mail vom Projektteam, Intranetartikel, vielleicht kurze Infoveranstaltungen oder Sprechstunden. Betonen Sie die Vorteile (eine Nummer weltweit erreichbar, moderne Devices etc.), aber auch Änderungen (z. B. „es gibt keine physischen Telefone mehr außer auf Wunsch“ oder „Voicemail kommt per Mail jetzt“). Gerade langjährige Mitarbeiter müssen eventuell die Nostalgie ans alte Telefonsystem ablegen – zeigen Sie Empathie und bieten Hilfestellung.
• Trainings und Schulungen: Für Endbenutzer sind Schulungen entscheidend. Bieten Sie Live-Sessions oder E-Learning an: Themen: „Wie telefoniere ich mit Teams?“, „Geräte und Audio einstellen“, „Weiterleiten, Halten, Konferenz – so geht’s“, „Voicemail personalisieren“. Auch spezifische: z. B. Empfangsmitarbeiter bekommen intensivere Schulung (Call Queues, evtl. Attendant Console), Führungskräfte und Assistenten müssen Delegation üben. Machen Sie ruhig Hands-on-Workshops. Gegebenenfalls richten Sie einen „Floorwalker“-Service ein: In den ersten Tagen nach Rollout gehen IT-Mitarbeiter durch die Büros und fragen, ob alles klappt (ähnlich wie man es bei neuen PC oder Software macht).
• Dokumentation und Self-Service: Stellen Sie Anleitungen bereit – z. B. ein PDF oder Wiki: „Telefonieren mit Teams – FAQ“. Darin: Häufige Fragen (Wie mache ich Makeln? Wo finde ich meine Voicemail?). Microsoft hat Benutzerdokus, die man adaptieren kann. Auch interne Besonderheiten dokumentieren: „Um externe Amtsleitung brauchst du keine 0 mehr vorwählen“ oder „Notruf in Homeoffice nur via Handy“.
• Betriebsrat und Compliance: Ein oft übersehener Punkt: neue Systeme wie Teams-Telefonie beinhalten oft Reporting-Funktionen (z. B. im Teams Admin Center kann man Benutzeranrufdaten sehen). Das kann Mitbestimmung auslösen. Informieren Sie früh den Betriebsrat, was erfasst wird (z. B. „Ziel/Quelle eines Gesprächs und Dauer, aber keine Gesprächsinhalte“) und wofür (Störungsanalyse, Qualitätsmanagement, keine Mitarbeiterüberwachung). Evtl. schließen Sie eine Betriebsvereinbarung zur Nutzung von Teams-Analytics. Involve compliance, falls Mitschnitte (Recording) vorgesehen sind.
• Abnahme und Erfolgskontrolle: Definieren Sie Abnahmekriterien: z. B. „Das Projekt gilt als erfolgreich abgeschlossen, wenn 95% der Nutzer telefonieren können, 0 kritische Fehler offen sind und alte Anlage abgeschaltet ist.“ Führen Sie nach Abschluss eine Abnahmeprüfung mit dem Auftraggeber durch (IT-Leiter oder so): Checklisten (wurden alle Standorte migriert? Wurden alle Tickets gelöst? Sind die Key User zufrieden?). Holen Sie ein Abnahmeprotokoll ein. Das ist wichtig, damit das Projekt offiziell endet und in den Normalbetrieb übergeht (und Projektressourcen frei werden).

Typische Stolpersteine und Vermeidungsstrategien

Aus vielen Telefonie-Migrationen ergeben sich immer wieder Pitfalls – hier einige und wie man sie vermeidet:

• Unklare Rufnummernportierung: Wenn z. B. Rufnummern in Blöcken portiert werden, aber einige Nummern aus dem Block bleiben beim alten Anbieter (z. B. Alarmleitung), kann es zu Chaos kommen. Vermeidung: Klare Abgrenzung – möglichst ganze Blöcke portieren. Falls Splits nötig, sprechen Sie mit beiden Anbietern, ob das Routing dann klappt (Stichwort: im alten Netz Dummy-Routing auf neu). Notfalls temporäre Umleitungen für isolierte Nummern einrichten.
• Unterschätzte Netzwerkanforderungen: Vielleicht hat die Standortanbindung in einem Office nur 10 Mbps, aber es werden 50 gleichzeitige Calls erwartet – das geht in die Hose. Vermeidung: Bandwidth-Assessment vorab (siehe Netz-Anforderungen). Ggf. Upgrades vor dem Rollout beauftragen. QoS nicht vergessen – viele Qualitätsprobleme kommen erst ans Licht, wenn Last auf dem Link.
• Gerätekompatibilität: Alte Headsets, die mit dem Cisco-Telefon toll gingen, machen am PC Probleme (falsche Buchse, kein Busylight). Lösung: rechtzeitig passende Teams-fähige Geräte beschaffen und testen. Lieber etwas mehr investieren in gute Freisprecher/Headsets für Vieltelefonierer – das erhöht Akzeptanz.
• Mangelnde Schulung führt zu Supportflut: Wenn Anwender am Tag X nicht wissen, wie sie telefonieren sollen („Wo ist meine Taste zum Durchstellen?“), wird der Helpdesk überrannt. Vermeidung: Proaktive Schulungen & FAQs bereitstellen, „Champion“-User ernennen, die Kollegen helfen können.
• Parallelbetrieb zu lange aufrechterhalten: Wenn man monatelang zwei Systeme hat, entsteht Konfusion („Soll ich Herr X auf Teams oder auf dem alten Apparat anrufen?“). Besser ein straffer Migrationszeitplan, notfalls mit externen Ressourcen, als ewig Hybrid.
• Notrufe nicht getestet: Den Fehler machen viele aus Angst, die 112 zu belästigen. Aber: das ist ein Muss. Sonst merkt man zu spät, dass z. B. alle Notrufe aus dem CH-Büro nach Deutschland gingen. Vermeidung: tests wie beschrieben, in Koordination, ruhig abends oder in Randzeit.
• Fehlende Zustimmung der Nutzer: Manchmal lehnen Mitarbeiter die neue Lösung ab („Das alte Telefon war doch gut“). Hier hilft es, Begeisterung zu schaffen: z. B. coole neue Features zeigen, schnurlose Freiheit mit Headset, Integration mit Outlook Kontakten etc. Early Adopter als Multiplikatoren nutzen. Wenn Führungskräfte es vorleben, ziehen andere nach.
• Integration vergessen: Gern übersehen: Aufzugnotruf hängt noch am alten ISDN, dann Anlage weg, oh Mist. Daher: gründliche Bestandsaufnahme. Lieber einmal Hausmeister fragen: „Gibt’s irgendwo noch ‘nen Notfallapparat?“
• Unklarer Supportprozess nachher: Wer behebt Telefonieprobleme nach der Migration? Das Helpdesk-Team braucht Know-how: schulen Sie sie in typischen Fehlern (z. B. „ich höre den anderen nicht“ -> Check Soundeinstellungen, NAT etc.). Legen Sie Zuständigkeiten fest (SBC-Admin, Netzteam, Providerkontakt) und dokumentieren Sie diese in den Betriebshandbüchern.

Um Stolpersteine zu vermeiden, hilft immer: Erfahrungen anderer nutzen (Austausch mit Firmen, die das getan haben), Pilotfeedback ernst nehmen, und ausreichend Tests vor Go-Live.

Checkliste: Vor der Migration

(Für die Planungsphase, Dinge, die vor Start erledigt sein müssen)

• [ ] Rufnummern- und Vertragsinventar komplett: Alle vorhandenen Telefonnummern (Geographisch, Service, Mobil, Sonder) sind erfasst in einer Liste. Zuweisung zu Personen/Abteilungen geklärt. Aktuelle Telefonieverträge (mit Kündigungsfristen) liegen vor. ggf. alte Verträge gekündigt mit genügend Vorlauf (aber nicht so, dass Nummern weg sind, immer in Abstimmung mit Portierung!).
• [ ] Netzwerk Readiness geprüft: Pro Standort wurde Bandbreite vs. Callvolumen geprüft, QoS eingerichtet, WLAN (falls Mobile Clients) auf Voice-Tauglichkeit getestet. VPN-Lösungen für Homeoffice können UDP/VoIP durchleiten (Stresstest). Firewall-Regeln gem. Liste implementiert.
• [ ] Security & Compliance Freigaben: IT-Security hat das Konzept abgenickt (Ports, Cloud-Dienste). Datenschutz hat evtl. gecheckt (Call-Daten in Microsoft-Cloud – DSB informiert?). Betriebsrat über Projekt informiert und evtl. BV abgeschlossen. Falls Aufzeichnung geplant, rechtliche Implikationen geklärt (Einwilligungen? Ansagen?).
• [ ] Notruf-Konzept abgesegnet: Geschäftsführung/Sicherheitsbeauftragter haben den Notfallplan genehmigt (inkl. wer pflegt Adressen, wie Schulung MA, wer kriegt interne Alerts). Lokale Besonderheiten je Land berücksichtigt. Alle Beteiligten (Empfang, Facility) über ihre Rolle informiert.
• [ ] Hardware/Software beschafft: anynode-Lizenz erworben (mit ausreichenden Sessions + evtl. SUS Support). Falls physische SBC-Appliance: Hardware steht bereit. Teams-Telefone/Headsets bestellt und geliefert, einsatzbereit.
• [ ] Testzugänge eingerichtet: Einen Test-Tenant oder im eigenen Tenant Test-User angelegt, zum Ausprobieren von Einstellungen ohne alle Mitarbeiter zu beeinflussen. Evtl. eine kleine Testnummer beschafft vom neuen Provider um vor Portierung zu spielen.
• [ ] Pilot-User identifiziert und vorbereitet: Wer macht Pilot? Zustimmung von deren Vorgesetzten eingeholt. Pilot-User haben ggf. parallel noch Festnetztelefon (für Backup) aber nutzen primär Teams. Feedback-Kanal (Chat oder wöchentlicher Jour fixe) eingerichtet, um Rückmeldungen zu sammeln.
• [ ] Fallback-Lösung definieren: Was ist Plan B, wenn gravierende Probleme auftreten? (z. B. „In dem Fall leiten wir alle eingehenden Anrufe zurück aufs alte System/Mobiltelefone“). Ein „Service Degradation“ Prozess definiert, falls Audioqualität schlecht, wer entscheidet Rückkehr.
• [ ] Abschluss Alt-System: Wenn Alt-Anlage Leasing etc.: Zeitplan für Rückgabe Hardware, oder interne Weiterverwendung, geklärt. Team für Ausbau der Telefone (oder bleiben sie als Deko?) organisiert.

Checkliste: Inbetriebnahme (während Implementierung/Testphase)

(Dinge, die während der technischen Einrichtung und Tests erledigt werden)

• [ ] SBC konfiguriert & getestet: anynode Installation fertig, Anbindung an Teams und Provider getestet (siehe SBC Go-Live Checkliste). Protokolle auf Fehler gecheckt (keine roten Alarme im Log). Zertifikate austausch mit MS erfolgreich (SBC als aktiv in Teams).
• [ ] Dial Plan & Voice Routing umgesetzt: Alle gewollten Normalisierungsregeln in Tenant Dial Plan abgebildet. Voice Routes angelegt gem. Migrationsplan (z. B. vorab Routen für jede Stadt, teils noch auf altes Gateway). PSTN Usages und Policies zugewiesen an Pilotnutzer. Test-User können lokal und international rauswählen, Blockierungen (z. B. 0900) greifen.
• [ ] Benutzer zu Teams migriert: Pilotnutzer bzw. erste Welle wurde in Teams „Enterprise Voice“ aktiviert. Bei Skype for Business Hybrid ggf. Move-CsUser gemacht. Lizenzen sind dran. Parallel in alter PBX diese Nutzer rausgenommen oder Umleitungen gesetzt, dass Doppelklingeln oder Konflikte vermieden werden.
• [ ] Endgeräte verteilt: Neue Telefone/Headsets an Piloten ausgehändigt, installiert. Funktionstest: Hören, Mikro, Klingeln funktionieren. Mobile Clients installiert (wenn gewünscht), MFA/Logins klappen.
• [ ] Schulung Pilot durchgeführt: Mit Pilotusern Kickoff gemacht: Tool vorgestellt, Notfallverhalten erklärt, Feedbackwege.
• [ ] Test-Szenarien durchgespielt: Alle in Testplan definierten Calls gemacht (intern, extern, mobil, Notruf intern etc.). Probleme dokumentiert und gelöst. Eventuelle Supporttickets bei Microsoft oder Provider frühzeitig erstellt wenn nötig.
• [ ] Datenübernahme: Falls aus altem System z.B. Telefonbücher oder Kontaktgruppen übernommen werden sollen – ins Teams übertragen (Outlook Kontakte, oder Teams Kurzwahl-Listen eingerichtet). Speed-Dial-Einträge für Empfang eingerichtet analog vorher.
• [ ] Documentation fertiggestellt: Betriebsdokumentation für neuen Zustand geschrieben (SBC Konfig, Tenant-Settings, Netzwerkplan, Notrufkonzept). Übergabe an Betriebsteam (falls anderes Team) begonnen, damit sie nächste Phase begleiten können.

Checkliste: Go-Live (Übergabe in den Regelbetrieb)

(Dinge rund um den eigentlichen Umschaltzeitpunkt und kurz danach)

• [ ] Portierungstermine bestätigt: Nochmal beim Carrier nachgefragt: „Portierung läuft am Datum X von 00:01 bis 06:00“ – alle relevanten wissen es. Keine anderen Changes an dem Tag. Team vor Ort/auf Abruf bereit.
• [ ] Monitoring aktiv überwachen: Am Umschalt-Tag sind Admins live am Monitor: SBC Logs auf Fehlalarme prüfen, Teams Admin Center Live-Dashboard offen (zeigt evtl. Fehler), Provider-Fall back Pläne griffbereit.
• [ ] Kommunikation an Endbenutzer: Am Stichtag kurzes Update raus: „Neue Telefonie ist jetzt aktiv – probieren Sie es aus. Bei Problemen kontaktieren Sie…“ So fühlen sich alle abgeholt.
• [ ] Support/Hypercare eingerichtet: In den ersten z.B. 2 Wochen nach Go-Live ist ein verstärkter Support gewährleistet: Das Projektteam oder extra Telefonie-Support sitzt bereit, um schnell auf Störungen zu reagieren. Eventuell täglicher Standup zu offenen Problemen. Alle Problemchen aufnehmen (auch z.B. „Feature XY vermisse ich“), klassifizieren (Workaround? später lösen? etc.).
• [ ] Altsystem schrittweise abschalten: Nach erfolgreicher Portierung: Alte Anlage ausgehend blockieren (damit keiner es versehentlich noch nutzt), ggf. Ansage „Diese Durchwahl ist nicht mehr aktiv“. Einige Tage redundante Erreichbarkeit belassen falls machbar (z. B. Umleitungsansage). Dann Hard-Cut: Alte PBX vom Netz trennen.
• [ ] Feintuning nach Go-Live: Oft zeigen sich nach ein paar Tagen Nutzungsdaten – z. B. merkt man, dass die Wartemusik zu laut/leise, oder dass man mehr Concurrent Calls braucht als gedacht. In Hypercare-Phase gleich Anpassungen machen (innerhalb vernünftiger Grenzen).
• [ ] Projektabschlussbericht: Nach ca. 1 Monat Stabilbetrieb kann man einen Abschlussbericht verfassen: Ziele erreicht? Nutzerzufriedenheit? Offene Punkte (die ins normale Release mgmt übergehen)? Lessons Learned? Diesen an Stakeholder verteilen.
• [ ] Übergabe an operatives Team: Die Verantwortung wechselt jetzt vom Projekt an den IT-Betrieb. Kickoff mit Betriebsteam: alle Dokumente übergeben, Monitoring auf deren Dashboard eingerichtet, evtl. letzte Schulung für Administratoren (z. B. wie neue User anlegen in Teams, SBC Routinechecks). Projektverteiler wird geschlossen, ab jetzt normale Ticketprozesse.
• [ ] Feiern! Nach so einem intensiven Rollout darf man auch den Erfolg feiern – ein kleines Team-Event mit den Beteiligten stärkt die Zusammenarbeit und schließt das Projekt positiv ab.

Betrieb, Monitoring & Fehleranalyse

Betrieb und Monitoring-Tools

Nach dem Rollout geht es in den Regelbetrieb. Dafür stellt Microsoft und der SBC verschiedene Tools und Metriken bereit:

• Teams Admin Center (TAC): Hierüber verwaltet man Benutzer (Telefonnummernzuweisung, Richtlinien) und hat Monitoring-Bereiche. Insbesondere der Bereich Anrufqualität und Zuverlässigkeit bietet Einblick: man sieht pro Benutzer oder insgesamt Statistiken zu Anrufen, Qualität (Jitter, Packet Loss, RoundTrip). Im Direktrouting-Bereich sieht man die registrierten SBCs und deren Status (Online/offline, letzter Heartbeat). Wichtig: TAC ist eher summarisch – detaillierte Live-Fehler sieht man dort begrenzt (man kann aber unter „Sitzungsdetails“ einzelne Call-Debugs anschauen, 30 min verzögert).
• Call Analytics: Für individuelle Problemfälle (z. B. User meldet: „Gestern 10 Uhr hatte ich ein schlechtes Gespräch“) kann man im TAC unter Benutzer -> Anrufverlauf den konkreten Call finden. Dort sieht man, wer Teilnehmer waren, welche Endpoint-IP, was Quali (MOS Score) war, ob Paketverlust in Up/Downlink etc. So kann man eingrenzen: War es das WLAN des Nutzers oder der SBC? Auch „Grund des Call-Endes“ (vom User aufgelegt oder Abbruch).
• Call Quality Dashboard (CQD): Das CQD ist ein mächtiges Tool für aggregierte Auswertung. Man kann z. B. Berichte fahren „% Paketverlust pro Woche“, oder „welche Standorte haben die schlechteste MOS“. Besonders relevant: Filter nach Sitzungstyp „PSTN-In/Out“ um nur die Direct-Routing Calls zu betrachten – man will ja die Qualität der PSTN-Telefonie tracken. CQD erlaubt auch Heatmaps und Trendanalysen. Damit kann man z. B. quartalsweise Berichte ans Management liefern, wie gut die Sprachqualität ist oder ob bestimmte Büros Probleme machen.
• SBC-Metriken: Auf anynode hat man laufend Kennzahlen: CPU, Calls in progress, Registrations ok. Man sollte ein Monitoring-Tool (z. B. PRTG, Zabbix) ansetzen, das via SNMP oder REST diese Metriken ausliest. Ein paar sinnvolle Schwellen: CPU > 80% (Alarm, evtl. Transcoding-Overload?), Memory > 80%, Calls > 90% des lizenzierten Limits (Kapazitätsgrenze naht). anynode liefert auch pro Call RTP-Statistiken (verlorene Pakete). Man könnte z. B. einen Alarm definieren, wenn im Durchschnitt der letzten 5 min mehr als 5% Packet Loss auf SBC-Seite gemessen wurde – Hinweis auf Netzproblem.
• Provider-KPIs: Manche SIP-Carrier bieten Webportale, wo man z. B. die Anzahl der laufenden Kanäle sieht, oder CDRs einsehen kann. Auch Auflistung der Fehlanrufe (z. B. falls Nummer falsch). Diese Infos können helfen, vor Ort Trends zu sehen (vielleicht ruft jemand oft eine falsche Nummer an und kriegt immer Busy – taucht im Carrier CDR als nicht verbunden, kann man ansprechen). Wenn Provider QoS-Daten liefert (eher selten), auch nutzen.
• Alerting & SLA: Für den Betrieb definieren Unternehmen oft SLAs – z. B. „Telefonie 99,9% Verfügbarkeit im Monat“. Um das einzuhalten, muss man proaktiv Alarme pflegen: ein Ausfall des SBC (auch nachts) sollte binnen Minuten gemeldet werden (Monitoring E-Mail/SMS). Dann per Incident Management so schnell wie möglich lösen. Zu Berichtszeiten dann SLA-Kontrolle: War es unterschritten? Falls ja, Problem-Management (Ursache ergründen, Abstellmaßn. definieren).
• Trendanalysen & Kapazität: Mindestens quartalsweise sollte man sich Kennzahlen anschauen: Wie ist das Callvolumen? Steigt es mit Mitarbeiterzahl? Wann ist Peak (ggf. Urlaubssaison weniger)? Diese Infos fließen in Kapazitätsplanung: z. B. bei 80% Trunk-Auslastung überlegen, vom Provider mehr Kanäle zu buchen. Oder bei wiederkehrenden hohen Latenzen in Region X – Netzwerk dort aufrüsten.
• Regular Checks: Ein Checkplan hilft: Täglich: Prüfen SBC status (grün in TAC?), stichprobenhaft in Monitoring ob alles normal. Wöchentlich: offene Supporttickets zur Telefonie durchgehen – gibt es Muster? („Alle im Büro A haben Echo“ -> dort mal Hardware check). Monatlich: Report generieren, an Stakeholder senden (IT-Leitung erfreut, wenn KPIs nach oben gehen). Jährlich: Notfall-Simulation (Notruf test, DR-Szenario: Was wenn SBC tot – War mal test: SBC offline und wie reagiert Team?).

Systematische Fehleranalyse

Trotz aller Vorsicht treten Störungen auf. Ein planvolles Vorgehen bei der Fehleranalyse spart Zeit:

1. Problembeschreibung genau erfassen: Wer hat Problem, wann, mit wem telefoniert, was war exakt (kein Ton? Einseitig? Falsch verbunden? Abbruch nach X Sekunden?). Oft sind Nutzerangaben vage, nachhaken und in eigene Worte fassen.
2. Abgrenzen – Signalisierung vs. Medien: Ist das Problem, dass der Call gar nicht zustande kommt (Signalisierung)? Oder kam der Call zustande aber Ton fehlte (Medien)? Beispielsweise: „Anruf kommt nicht durch“ -> eventuell SIP 404 oder Busy etc., vs „Ich hörte nichts“ -> Medienpfad Problem. Man unterscheidet so: Kein Klingeln = Signalisierung; Klingeln aber kein Ton = Medien.
3. Richtung & Gegenstelle: Fehler inbound (Anrufe vom PSTN -> Teams) oder outbound (Teams -> PSTN) oder intern? Das engt schon mal auf SBC oder Microsoft-Teil ein. Außerdem: Ist es zielabhängig? z. B. „Kann keine Handynummern anrufen“ (vielleicht Routing für Mobilnetz fehlt) vs. „kann speziell Nummer 030/12345 nicht erreichen“ (vllt im Dial Plan wird 030 als ortsintern gesehen und falsch normiert).
4. Wiederholbarkeit: Ist es permanent (jeder Anruf fällt aus) oder sporadisch (manchmal geht’s)? Permanente Fehler deuten auf Konfig (z.B. bestimmtes Pattern nicht abgedeckt). Sporadische eher auf Qualität/Netz (z. B. mal war Internet kurz weg, etc.).
5. Untersuche Logs/Tracing:
6. Teams Admin Center: nach betroffener Nummer suchen, Sitzungen checken. Sieht man einen Call-Attempt und Fehlermeldung? (Z.B. „User Busy“ oder „Network unreachable“).
7. anynode Logs: dort nach Zeitstempel filtern. Bei Signalisierungsproblem: SIP INVITE Weg verfolgen – ging es raus? kam was zurück? Falls anynode gar kein INVITE bekam (obwohl Teams es versucht hat), Problem auf Teams oder Netz. Falls Invite rausging an Provider und nichts kam zurück – Providerfehler oder Routing. anynode kann in Trace klar zeigen z. B. „received 404 from carrier“.
8. Wireshark falls nötig: manchmal muss man tiefer reinschauen (z. B. fehlerhafte SDP Negotiation). anynode kann PCAPs erstellen. In der Cloud könnte man auch „Media Relay logs“ via Microsoft Support anfordern, aber selten nötig.
9. Hypothesen bilden: Mit den Daten überlegt man plausible Ursachen. Z. B.: Fall „Keine Audio beidseitig“: Wahrscheinlich RTP blockiert (Firewall). Fall „Einseitiges Audio“: NAT Problem – typischerweise hört der externe Teilnehmer nix, interner hört – ergo RTP von extern wird geblockt (SBC sendet, aber empfängt nicht). Fall „Nummer nicht erreichbar“: Evtl. im SBC falsche Routingregel oder Nummer nicht auf SBC ankommend (Dial Plan trimmt was weg?).
10. Maßnahmen testen: Für jede Hypothese eine Prüfmaßnahme. Bsp. Einseitiges Audio ext->int fehlt: Hypothese NAT, also prüfen: hat SBC im SDP die korrekte Public IP gemeldet? anynode Log -> check offered IPs. Oder Testcall nochmal mit Wireshark on SBC: sind RTP von Teams-Client eingehend da? aber vom Provider an SBC nicht? etc. So verifiziert man, woran es liegt.
11. Änderung/Behebung: Wenn klar, was falsch, korrigieren: Z. B. in anynode NAT-Einstellung fixen, Firewall-Port öffnen, Dial Plan Regex anpassen, etc.
12. Wieder testen: Nach Fix denselben Anruf erneut probieren (oder mit Testuser nachstellen). Und fragen, ob User dann Problem behoben sieht.

Ein paar konkrete Fehlerszenarien mit Ursachen/Maßnahmen seien noch skizziert (Playbooks):

Playbook: Keine Audioverbindung (beidseitig)
– Mögliche Ursachen: Beide Gesprächspartner hören nichts. Signalisierung hat aber geklappt (Anruf wird als verbunden angezeigt). Ursache oft: SRTP-Schlüssel nicht ausgetauscht – d.h. Medienpfad kam nie zustande. Mögliche Gründe: Firewall blockiert UDP komplett; oder falsche IP im SDP (SBC gab falsche Medien-IP an, sodass Pakete ins Leere gehen); oder inkompatible Crypto (z. B. SBC auf „SRTP erforderlich“ aber Gegenüber nutzt Plain – hier aber unwahrscheinlich mit Teams, da immer SRTP).
– Prüfschritte: Im anynode Live-Monitor sehen, ob RTP-Pakete gezählt werden. Wenn 0 auf beiden Legs, fließt nix. Wireshark auf SBC: kommen vom Teams Media überhaupt UDP-Pakete rein? Wenn nein, blockiert upstream was (Firewall). Wenn ja, werden sie vielleicht an falschen Port weitergeleitet – check anynode Config External IP/Port Range. In Teams CQD kann man sehen „Device sent zero packets“ etc.
– Maßnahmen: Firewall-Adjust: UDP Ports freigeben, NAT richtig einrichten. anynode: in Location Profile korrekte External IP setzen (damit Teams weiß wohin). Notfalls temporär Media Bypass ausschalten um zu sehen, ob es dann über Relay geht – wenn ja, Problem liegt im direkten Pfad.

Playbook: Einseitiges Audio
– Mögliche Ursachen: Eine Seite hört, die andere nicht. Klassisch NAT: Meist hört der interne Teams-User den externen, aber der externe hört nichts zurück. Das würde bedeuten: Teams -> PSTN Audio geht, PSTN->Teams geht nicht. Warum? Oft weil der SBC Pakete vom Client nicht bekommt, oder Client von SBC nicht. Wenn Client hinter NAT und Bypass on, könnte es sein, SBC sendet an private IP (Fehler in ICE). Oder SBC hinter NAT und hat nur eine Richtung NAT geöffnet.
– Prüfschritte: Untersuchen, wer hört wen. Dann gezielt den Pfad debuggen: Falls PSTN-Partner nichts hört, bedeutet SBC bekommt vom Teams audio, aber PSTN kriegt nichts? Oder SBC bekommt nichts vom Teams? – Schauen anynode Stats: Packets in/out auf beiden Seiten. – Wenn z.B. inbound leg (Teams->SBC) = 0, outbound leg (SBC->carrier) = 0, aber inbound (carrier->SBC) >0, outbound (SBC->Teams) >0 -> SBC kriegt vom Teams nix, aber sendet zum Teams. D.h. der externe spricht, Teams hört (so rum?), umgekehrt tot. Andersherum wenn invertiert. – Oft sieht man: Teams leg sending fine, PSTN leg receiving fine (so der interne hört extern), aber PSTN leg sending fine, Teams leg receiving 0 (externer hört nichts). Das deutet auf NAT inbound to SBC.
– Maßnahmen: – Wenn SBC hinter NAT: Prüfen, ob NAT Port-Freigaben beidseitig eingerichtet. Evtl. Port Preservation Problem. – Bei Media Bypass: Ggf. in anynode ICE-Lite Konfig schauen – hat der Teams-Client vielleicht doch Relay gewählt? (Dann Problem evtl. bei Relay). – Notfalls Workaround: Media Bypass off (alle Medien über Microsoft, dann i.d.R. NAT sauber, aber Pfad länger). – Speziell bei einseitig extern->intern fehlt: oft Firewall am Kundennetz lässt ausgehenden RTP raus (daher extern hört), aber eingehenden RTP droppt (daher intern hört nichts). Lösung: Firewall inbound rule für RTP aufmachen.

Playbook: Fehlende CLIP-Anzeige (falsche Rufnummer)
– Mögliche Ursachen: Externe Teilnehmer sehen nicht die gewünschte Absendernummer. Entweder wird statt der Durchwahl immer die Zentrale angezeigt, oder „Unbekannt“. Gründe: Carrier könnte die vom SBC übermittelte Nummer überschreiben (falls CLIP no screening nicht erlaubt). Oder der SBC sendet gar nicht die Durchwahl, sondern vielleicht nur Stammnummer (Konfig-Fehler in P-Asserted). Oder Teams übergibt eine dienstliche Maskierungsnummer (es gibt eine Setting, um immer main number zu zeigen).
– Prüfschritte: In anynode SIP-Traces outbound sehen: Was steht im From: und P-Asserted-Identity? Entspricht das der Usernummer oder ist es was anderes? Dann checken, was Provider in sein Netz übernimmt – manchmal im 200 OK ruft er ne andere ID zurück. – Evtl. Test mit Wireshark am PSTN-Ausgang (falls ISDN Gateway hat man Q.931 etc., sonst schwer, aber Provider kann evtl. Logs geben). – Wenn Unbekannt erscheint: vmtl. Provider hat die Nummer verworfen (z.B. weil wir +49… gesendet aber Vertrag nur auf +41… Swiss trunk – dann blank).
– Maßnahmen: – Falls nur Stammnummer statt Durchwahl kommt: Beim Provider CLIP no screening beantragen oder im SBC anpassen, dass pro User Stammnummer gewollt (vielleicht war es Absicht?). – Falls unbekannt: Prüfen, ob wir Nummer im richtigen Format senden (manche Provider wollen national format bei national calls). Falls ja und er trotzdem blankt, vermutlich fehlt Berechtigung -> mit Carrier klären, ggf. schriftlich erlauben lassen. – Zwischenschritt: Test, ob mit fix gesetzter CallerID (z.B. in anynode mal statisch 1 Nummer setzen) es geht – falls ja, dann Carrier will nur bestimmte, dann anpassen via CLI Mapping im SBC für betroffene.

Playbook: Notruf fehlgeschlagen
– Mögliche Ursachen: Der Notruf 112 kam nicht durch oder ging an falsche Stelle. Ursachen können sein: Dial Plan hat aus 112 -> +112 gemacht, und Provider routet das nicht; Oder Voice Route schickte 112 an falschen SBC (z.B. UK SBC, der kennt 112 nicht); Oder SBC hat 112 als normal call behandelt aber Provider erfordert besonderen Tag/Route. Evtl. blockiert im SBC (manche machen default keine short numbers raus).
– Prüfschritte: – Teams-Ebene: Hat Teams den Call überhaupt an SBC geschickt? (In Admin logs nachschauen – vlt. hat Teams Notrufpolicy, die was anderes tat). – anynode: Sieht man einen Invite für „sip:112@…“? Falls nein, blieb in Teams hängen -> vlt. Dial Plan Problem. – Falls ja, ging er zum Provider? Was antwortete der? Z.B. SIP 404 not found (Provider kennt 112 nicht auf dem trunk?), oder 403 (Not allowed?), oder keine Antwort. – Eventuell kam er an, aber PSTN-Seite tat nichts – dann wohl Routingproblem offline.
– Maßnahmen: – Falls Teams-seitig block: in Tenant Dial Plan Notruf-Regel einfügen (keine Normalisierung). – Falls SBC bisher ignoriert: Routing-Regel in anynode bauen, dass 112 explizit gematcht und rausgeht. – Falls Provider es ablehnt: Kontakt aufnehmen – manche SIP-Trunks erfordern die Anmeldung von Notrufadressen, sonst sperren sie Notrufe. Wenn das der Fall: schnellstmöglich mit Provider regeln (viele haben ein Webportal wo man je Standort Adresse einträgt). – In Zwischenzeit: Workaround definieren – z.B. temporär 112-Anrufe an lokalen analogen Anschluss in Filiale weiterleiten wo ein Schild „Im Notfall hier drücken“ ist – das sind allerdings Notbehelfe. – Falsche Stelle: z.B. 112 ging zur Leitstelle falsche Stadt -> Implementieren ELIN-Lösung falls möglich, oder Hotline in Leitstelle anrufen und Register aktualisieren lassen (in DE ruft die Leitstelle bei Offnet oft die BNetzA Datenbank ab, die eventuell veraltet war – dann Nummernzuordnung checken).
– Und natürlich: so lange Problem besteht, Mitarbeiter informieren, was sie tun sollen (z. B. „Notrufe bitte über Handy vorerst“).

Dieses systematische Vorgehen und Vorhalten solcher Playbooks helfen dem Betriebsteam, im Ernstfall schnell zu reagieren.

Wichtige Betriebs-KPIs (Service Level Kennzahlen)

In einem laufenden Betrieb sollte man definieren, welche Kennzahlen (KPI) regelmäßig beobachtet und als Indikator für Servicequalität herangezogen werden. Hier eine Tabelle mit Beispielen:

Die Reaktionen sind beispielhaft – wichtig ist, dass Abweichungen früh erkannt und adressiert werden.

Manche KPIs kann man in einem Dashboard zusammenführen (es gibt Tools, auch Power BI mit CQD, oder PRTG + Grafana etc.). Ein wöchentliches Management-Briefing mit „Telefonie-Status“ kann auch intern das Bewusstsein für diesen Service hochhalten.

Playbooks für häufige Störungen: (Zusammenfassung aus obiger Analyse, in stichpunktartiger Form)

• Keine Audio (beide Richtungen):
• Hypothesen: Komplett blockierte RTP (Firewall Issue) oder SRTP Keys mismatch.
• Prüfen: anynode Statistik (RTP-Pakete=0?), Firewall Ports. Eventuell Test mit Bypass off.
• Maßnahme: Firewall/NAT öffnen, Config External IP fixen. Testcall danach.
• Einseitiges Audio:
• Hypothesen: NAT-Problem (eine Richtung RTP drop), Codec unilateral.
• Prüfen: Wer hört wen? anynode Packetcounter je Leg, SDP IPs.
• Maßnahme: NAT config korrigieren (Port forward, ICE config). Falls nur bei Bypass -> Bypass aus bis gelöst.
• Rufnummernanzeige fehlt/falsch:
• Hypothesen: Provider verwirft CLIP (no screening fehlt) oder SBC sendet falsches Format.
• Prüfen: anynode SIP INVITE Outbound: P-Asserted Identity Inhalt, Provider Requirements (z.B. nur national format?).
• Maßnahme: Mit Provider CLIP no screening vertraglich klären. Im SBC Format anpassen (z.B. +49->0 bei national). Falls absichtlich block (Anonym), prüfen ob Privacy-Header gesetzt -> Provider Setup.
• Nicht erreichbarer Notruf:
• Hypothesen: 112 nicht geroutet (fehlende Rule), Trunk Problem, fehlende Location config.
• Prüfen: anynode Logs ob 112 überhaupt rausging, Provider Rückmeldung (403?). Teams Emergency Policy angewendet?
• Maßnahme: Sofort alternative Notrufweg kommunizieren (z.B. Mobil), dann fix: Route für 112/110 im SBC anlegen, Provider freischalten. Location updates nachholen. Test mit Leitstelle nach Änderung.

Andere spezifische Playbooks kann man nach und nach ergänzen (z.B. „Anruf bricht nach genau 15 min ab“ -> typischer Session Timer mismatch – Timer Settings angleichen; „Falscher Name im Display bei intern“ -> Teams Kontakte check etc.). Der Betrieb wird im ersten halben Jahr ein besseres Bild bekommen, was häufig anfällt.

Wirtschaftlichkeit & Risiko

Wirtschaftlichkeitsbetrachtung

Die Einführung von Teams-Telefonie sollte nicht nur technisch, sondern auch wirtschaftlich sinnvoll sein. Man betrachtet qualitative und quantitative Faktoren:

Kostenblöcke:

• Lizenzen: Microsoft 365 Lizenzen (E5 vs E3+Phone System). Hier evtl. Mehrkosten, wenn vorher keine Telefoniekomponente lizenziert war. Pro Benutzer als monatlicher Betrag zu kalkulieren. Falls Audiokonferenzen genutzt werden, auch diese Add-On-Kosten beachten. Insgesamt können Lizenzkosten steigen, aber man spart ggf. Kosten für alte TK-Wartungsverträge.
• SBC und Infrastruktur: Falls man einen SBC betreibt, kommen Kosten für Softwarelizenz (einmalig oder Abonnement) und die Hostingkosten (Hardware, VMs, Cloud Instances). Beispiel: anynode Subscription pro Jahr X Euro für Y Sessions; Azure VM mit z.B. 50€/Monat. Dazu Zertifikatskosten (öffentliches Zert, ca. 100€ pro Jahr). Bei hardwarebasierter Lösung käme Appliance-Kauf plus Wartung hinzu.
• Carrier & Verbindungsentgelte: Telefonie selbst ist nicht kostenlos – egal ob Calling Plan oder Direct Routing. Mit Direct Routing hat man separate Carrier-Rechnung: Grundgebühr je SIP-Kanal oder Flatrates, Minutenpreise für Anrufe. Hier kann man oft sparen im Vergleich zu alten ISDN-Tarifen, aber muss kontrollieren, dass z.B. internationale Raten okay sind.
• Betriebskosten: Personalkosten für das Managen der neuen Lösung: Administratoren müssen geschult werden und Zeit aufwenden (z.B. SBC pflegen, User-Onboarding). Möglicherweise hat man ein Service-Modell (z.B. externen Partner für SBC-Betrieb), was monatlich kostet. Aber evtl. entfällt dafür z.B. der Wartungsvertrag auf die alte PBX (der auch teuer war).
• Geräte: Investitionen in neue Endgeräte (Headsets, evtl. Teams-Telefone für Konferenzräume). Diese fallen einmalig an und dann alle X Jahre Erneuerung. Hier sollte man im Budget Posten haben.

Qualitative Nutzenargumente:

• Flexibilität: Mit Teams-Telefonie kann man viel agiler reagieren – neue Mitarbeiter bekommen einfach eine Nummer zugewiesen, Standorte egal. Keine Hardwareinstallation nötig, global sofort nutzbar. Das spart indirekt Zeit und Geld (kein Techniker muss Telefondosen patchen). Auch Kapazität flexibel: kein Primärmultiplex-Anschlusslimit von 30 Kanälen – SIP-Trunk kann oft kurzfristig hochskaliert werden für Kampagne etc.
• Skalierung & Zukunftssicherheit: Cloud-Lösungen skalieren nach oben wie unten. Wenn die Firma wächst oder schrumpft, passt man Lizenzen an. Alte TK-Anlagen hatten feste Ports – teuer wenn ungenutzt. Teams skaliert linear mit OPEX, kein großer Forklift alle paar Jahre. Und neue Features (z. B. Teams Rooms, PSTN integration mit CRM) kommen per Update, man ist technologisch up-to-date.
• Integration & Produktivität: Telefonie in Teams kann mit anderen 365-Tools kombiniert werden – z. B. Click-to-Call aus Outlook, Anrufdatensätze in Dynamics CRM (via Graph API), Voicemails in Exchange mit Transkript, etc. Das erhöht die Produktivität (Mitarbeiter sparen Klicks und haben Informationen zentral). Schwer quantifizierbar, aber spürbar im Alltag.
• Mobiles Arbeiten: Durch Teams Phone benötigen Mitarbeiter unterwegs nur die App – keine Umleitung auf Privathandy oder Zweitgerät. Das senkt evtl. Mobilfunkkosten (wenn man viele Weiterleitungen hatte) und verbessert Erreichbarkeit (weniger verpasste Anrufe, weil alles auf einem Gerät).
• Wegfall redundanter Systeme: Wenn die alte PBX abgeschaltet wird, entfallen deren Stromverbrauch, Raumkosten (mancher hat große TK-Schrankanlagen). Auch Reduktion von vielen kleinen Telefonanlagen in Filialen auf einen zentralen SBC spart Wartungsaufwand und evtl. Mietleitungen.
• Verbesserter Kundenservice: Mit neuen Funktionen (Call Queues, Teams Federation etc.) kann man Kundenanrufe besser handhaben – z. B. jemanden aus dem Team dazuholen per Teams, statt „Ich rufe Sie zurück“. Das kann Kundenzufriedenheit steigern – hat zwar keinen direkten Euro-Wert, aber indirekt schon.

In der Gesamtschau sollte man einen Business-Case erstellen: Z.B. „Alt vs. Neu 5-Jahres-Kosten“ – oft sieht man, dass nach Anfangsinvest die laufenden Kosten pro Jahr vergleichbar oder günstiger sind, plus die intangible Benefits. Aber jedes Unternehmen ist anders. Wichtig ist, die Entscheider von den qualitativen Vorteilen zu überzeugen, nicht nur auf € zu schauen.

Risikoanalyse und Gegenmaßnahmen

Jedes Projekt und System birgt Risiken. Eine Risikoanalyse identifiziert diese und definiert Gegenmaßnahmen:

Häufige Risiken und entsprechende Gegensteuerungen:

• Ausfall der Internetverbindung / Cloudabhängigkeit: Bei reiner Cloud-Telefonie hängt alles am Internet. Risiko: Standort offline -> Telefonie tot (außer Mobiltelefone). Gegenmaßnahmen: zweite Internet-Leitung (Redundanz, ggf. anderer Provider), automatische 4G-Failover Router. Außerdem Userschulung: im Notfall Handy nutzen (geschrieben im Notfallplan). Möglicher Einsatz von Survivable Branch Appliance (SBA): Das ist ein lokaler mini-Server, der bei Cloud-Ausfall wenigstens interne Gespräche und Notrufe auf analog raus ermöglicht. anynode kann als SBA agieren, jedoch erfordert On-prem Registrar – bei direkter Cloudnutzung selten.
• SBC-Failure: Wenn der SBC abstürzt oder kaputt geht, keine PSTN-Calls. Gegenmaßnahmen: wie im HA-Teil – redundanter SBC (Cluster), Monitoring, regelmäßige Wartung damit nicht ungepatchte Bugs Crash verursachen.
• Qualitätsprobleme (Voice QoS): Risko, dass durch Netzwerkissues die Sprachqualität so schlecht wird, dass Benutzer frustriert sind. Gegenmaßnahmen: QoS implementieren, Überwachung (MOS-Werte alarmieren), Packet-Loss Ursachen beheben (Netzwerkverstärkung, Router-Einstellungen). Im Notfall: fallback Routen definieren, z. B. bei extremen Problemen Teams-User auf Handy umleiten temporär.
• Fehlkonfiguration / menschlicher Fehler: Ein Admin könnte aus Versehen eine Dial Plan Regel löschen und externes Telefonieren fällt aus, oder falsche Nummer portieren. Gegenmaßnahmen: Change-Management (4-Augen-Prinzip bei Konfigänderung, Pre-Prod Testen). Ebenso Backups: wenn man Mist baut, Konfiguration schnell zurückspielen.
• Toll Fraud (Missbrauch): Telefonie-Systeme sind oft Ziel von Fraud (Hacker nutzen offene VoIP-Systeme, um teure Auslandsanrufe über Ihr System zu tätigen). Direct Routing mit SIP-Trunk ist hier exponiert. Gegenmaßnahmen: SBC sicher konfigurieren (nur erlaubte IPs, strong auth), in Teams Anrufpläne so, dass z. B. exotische Auslandsvorwahlen blockiert sind wenn nicht nötig. Überwachen: plötzliches Aufkommen von vielen Anrufen außerhalb Geschäftszeiten alarmieren. Begrenzung bei Provider einrichten (z. B. max € pro Tag).
• Mitarbeiterakzeptanz & Change Risk: Manche Mitarbeiter kommen mit neuem System nicht zurecht, Produktivitätsverlust droht, oder sie nutzen Shadow IT (Handy privat) weil ihnen Teams nicht gefällt -> Risiko verfehlter ROI. Gegenmaßnahme: intensives Change-Management (Schulungen, Einbindung Key-User, Feedback Runden). Notfalls temporär hybride Lösungen zulassen (z. B. wer absolut Tischtelefon will, kann ein Teams Phone bekommen).
• Rechtliche Risiken (Notruf nicht regelkonform, Aufzeichnung etc.): Falls System nicht rechtskonform betrieben wird, drohen Strafen. Gegenmaßnahmen: Juristische Beratung einholen, Vorschriften implementieren (z. B. in DE Notruf an Anlagenanschluss -> Mythen klären, Telefondoku bereithalten). Für Aufzeichnung: klar Prozesse definieren wer wann darf.
• Integrationsausfall: Z.B. Fax-Gateway funktioniert nicht, Business-Prozess (Bestellungen via Fax) stockt. Gegen: Kritische Integrationen definieren, Redundanz (Fax fallback E-Mail service als backup) oder ganz ablösen durch modernere Methode. Testen Sie regelmäßig diese Altsysteme auch im neuen Setup.

Ein formales Risikoregister kann wie folgt geführt werden:

Risikoregister (Auszug)

Ein solches Register sollte regelmäßig geprüft und aktualisiert werden. Die Verantwortlichen sorgen dann je für „ihre“ Risiken, dass Maßnahmen umgesetzt werden. Risiko mit höchster Priorität sind natürlich Notfall und Ausfälle – dort Redundanz und Pläne. Niedriger (Kosten) muss man einfach im Blick haben.

Beispiel: Mehrstandortfirma (D/A/CH, 1.000 Mitarbeiter)

Abschließend ein konkretes Beispiel, um das Zusammenwirken der Aspekte zu veranschaulichen.

Ausgangslage:
Die ACME GmbH ist ein internationales Unternehmen mit Hauptsitz in Deutschland (München, ~600 MA), sowie Niederlassungen in Österreich (Linz, 200 MA) und der Schweiz (Zürich, 200 MA). Bisher hat jede Niederlassung eine eigene Telefonanlage (Siemens Hipath in DE, Aastra in AT, Unify in CH) und lokale ISDN/PRI-Amtsleitungen. Die Systeme sind nicht verbunden. Man will auf Teams-Telefonie umstellen, um standortübergreifend einheitlich zu kommunizieren und die alten Anlagen (teilweise End-of-Life) abzulösen. Wichtig ist, dass Notrufe in allen Ländern regelkonform funktionieren und dass man bestehende Rufnummern behält. Es gibt zudem ein zentrales Kundenservice-Team verteilt auf DE und AT – diese sollen als eine virtuelle Gruppe zusammenarbeiten (derzeit getrennte Hotline-Nummern pro Land).

Zielbild:
Alle Standorte nutzen Microsoft Teams als Telefonanlage. Direct Routing wird implementiert, mit anynode-SBCs. Um lokale Präsenz zu wahren, entscheidet man sich für pro Land einen SBC: Einen primären in München (der auch AT mitbedienen kann) und einen in Zürich für die Schweizer Rufnummern. Die deutschen und österreichischen Nummern (Vorwahlen 089 für München, 0732 für Linz) werden in einem SIP-Trunk beim deutschen Provider zusammengeführt – dieser Provider kann österreichische Nummern via SIP liefern. Die Schweizer Nummern bleiben bei Swisscom, die an den CH-SBC angeschlossen wird. Beide SBCs registrieren sich in Teams. Diese verteilte Topologie gewährleistet, dass Notrufe in CH über einen schweizer trunk gehen und in D/AT über den deutschen trunk.

Die Netzwerkinfrastruktur: München und Linz sind via MPLS verbunden und haben gemeinsames Internet-Outing in München; Zürich ist eigenständig angebunden. Alle Standorte haben Enterprise-Internet mit QoS-fähigen Routern. QoS wird standortübergreifend eingeführt (EF für Voice).

Nummernkonzept:
Man konsolidiert die Durchwahlen: In München behalten alle ihre 4-stelligen DDI (-1000 bis -1999 etwa). Linz hatte 3-stellige Durchwahlen, diese werden auf 4-stellig aufgefüllt (z.B. 210 -> 1210) um Kollisionen mit München zu vermeiden. Zürich hat 3-stellig, wird auf 4 erweitert oder belässt, da Vorwahl ohnehin anders. Im Teams Tenant trägt man alle Benutzer mit +4989… bzw. +43732… und +4144… Nummer ein. Neu wird eine einheitliche Service-Hotline eingeführt: Die deutsche Hotline +498912345-2000 soll auch von AT und CH Kunden genutzt werden; je nach Land wird in Marketing entweder die lokale oder die deutsche angegeben, aber technisch kommt alles in eine Teams-Callqueue „CustomerService“.

Notruf-Design:
– In München (HQ) gibt es mehrere Gebäude; man definiert pro Gebäude eine eigene Notfall-Adresse. Über Dynamic Emergency Calling (Standort-ID via Subnet) bekommt z.B. Gebäude A vs B unterschiedliche Location in Teams. anynode in München hat eine ELIN-Lizenz: Pro Gebäude wird eine der freien Nummern aus dem Münchner Rufnummernblock als ELIN reserviert (z.B. -9991 für Gebäude A, -9992 für B). Wenn jemand 112 wählt, ersetzt der SBC die Absendernummer mit der jeweiligen Gebäude-ELIN. Diese sind bei der Leitstelle München hinterlegt mit Adresse. Der Rückruf geht dann auch an den SBC, der auf Basis der Nummer weiß, welche Teams-User es ursprünglich war (mapping cached) – aber hier erwägt man noch, statt zum User lieber zum Empfang umzuleiten, damit im Notfall jemand rangeht. – Linz: dort kleineres Büro, nur eine Adresse. Hier könnte man auf ELIN verzichten und einfach allen Linzer Nummern die Adresse Linz zuordnen. Allerdings wäre das Kennzeichen „+43 732 12345-0“ der Absender, was die Leitstelle in Linz erkennt (die -0 ist dort Zentrale). Man entscheidet sich trotzdem, sicherheitshalber die -0 zu behalten und auch als Absender für Notruf zu nutzen (Carrier erlaubt das). So hat Linz effektiv statisch: Anrufe aus Linz kommen mit -0 bei Leitstelle Linz. – Zürich: Swisscom verlangt pro Nummer eine Registrierungsadresse. Da die Züricher DDI sowieso alle am selben Standort sind, ist dort die Firmenadresse hinterlegt. Für Mobilnutzer (die mit Züricher Nummer unterwegs sind) gilt: im Notfall sollen sie die Sicherungsmaßnahmen (Handy oder an Teamleiter melden) nutzen, da dynamic E911 in CH so nicht vorhanden. Interne Dokumentation weist darauf hin. Zusätzlich hat man im Züricher Büro analoge Nottelefone auf jeder Etage installiert (Common Area Phones mit +41441234550x Nummern), falls wer kein Handy hat.

SBC-Topologie und Hochverfügbarkeit:
In München läuft anynode als HA-Cluster auf zwei VMware-VMs (active/standby mit Floating IP). Eine VM in Linz könnte als Survivable SBC dienen, aber man entscheidet sich aus Aufwandgründen dagegen – Linz hat Failover über München via MPLS, das reicht. In Zürich ein separater anynode (single, aber auf redundantem VMware-Cluster). Sollte Zürich-SBC ausfallen, man kann Notrufe nicht einfach via DE schicken (würden falsch landen). Daher wird Swisscom SIP-Trunk redundant ausgelegt: Swisscom kann bei Ausfall des Zürcher SBC die Nummern auf einen Backup-Standort weiterleiten – man richtet testweise in München SBC die Schweizer Nummern als zweites Gateway ein, aber belässt es inaktiv bis Notfall (in Teams voice routes: CH zu CH-SBC prio1, DE-SBC prio2). So könnte im äußersten Notfall ein 112 aus CH über DE-SBC rausgehen – das würde in DE landen, aber man hat intern eine Prozedur, dass dort sofort Info weitergegeben wird. Das ist ultima ratio.

Carrier-Anbindung:
Deutscher SBC: SIP-Trunk von Telekom mit 120 Sprachkanälen, inkl. aller deutschen und österreichischen DDI (Telekom Austria ist Partner). Schweizer SBC: SIP-Trunk Swisscom mit 50 Kanälen. Notruf erfordert bei Swisscom: alle DDI sind mit Adresse im Kundencenter gepflegt.

QoS-Vorgaben und Performance:
Man hat gemessen: Max. 80 Calls in München gleichzeitig, 20 in Linz, 30 in Zürich. Das passt pro Standort <10 Mbps Audio. Die MPLS hat 100 Mbps, Internet 200 Mbps. QoS: 15% der MPLS reserviert für EF (sprich ~15 Mbps, plenty). Regelmäßige MOS Monitoring über CQD geplant.

Migrationsfahrplan:
– Pilotphase: 50 IT- und Power-User in München und 10 in Zürich wurden 2 Monate vor Gesamtumstellung auf Teams Phone umgestellt (mit temporärer Parallelrufschaltung von PBX). Feedback gesammelt – kleinere Dial Plan Anpassungen (z.B. 0 weglassen war für einige schwer, also erlaubt man führende 0). – Hauptrollout: Zuerst München Abteilung für Abteilung in 3 Wellen, je ~200 User pro Woche. Dann Linz komplett, dann Zürich. Jede Welle begleitet von vor-Ort IT. Alte Anlagen jeweils nach Welle abgeschaltet (bzw. auf Restnutzer beschränkt). Nummernportierung: DE und AT Nummern portiert an Woche 3 (wenn 60% schon Teams), CH Nummern in Woche 4. Insgesamt 2 Monate Rollout. – Training: Intensive Schulungen, vor allem da 80% vorher Tischtelefone hatten, jetzt Headset. Einige Chefs bekamen auf Wunsch ein Teams-Tischtelefon (Yealink). – Hypercare: 1 Monat nach letzter Welle war ein extra Telefoniemigration-Chat offen, wo jederzeit Fragen gestellt werden konnten, betreut von Projektteam.

Betriebskennzahlen:
Nach 3 Monaten Betrieb zieht man Bilanz: Verfügbarkeit 99.98% (keine nennenswerte Ausfälle außer 2h Microsoft-Audio-Konferenz Störung, die PSTN aber nicht betraf). MOS im Schnitt 4.3, leicht besser als mit alter TK (vermutlich weil Codec jetzt HD möglich intern). Kosten: man hat gesehen, dass die Mobilfunkkosten sanken, weil mehr über Teams per WLAN telefoniert wird. Einsparungen: Wartungsverträge alte TK (15k €/Jahr) entfallen, Telefontreiber in VMware entfallen. Neuer Posten: Microsoft Phone Lizenzen ~8€/User/Monat aber ok. Unterm Strich leicht höhere laufende Kosten, aber dafür modernisiert und global vereinheitlicht.

Zum Schluss werden noch konkrete Testfälle aufgelistet, die ACME im Rahmen der Abnahme durchgeführt hat:

Testfälle (Auswahl):

1. Internes Gespräch standortübergreifend: Teams-User in München ruft Kollegen in Zürich via Name an – Verbindung hergestellt, HD-Audio, geringer Delay. -> OK (zeigt Cloud-Transport funktioniert).
2. Externer Anruf Deutschland: Münchner User ruft eine lokale Münchner Festnetznummer (Arztpraxis). Hörbar Klingelton, Praxis hebt ab, beide verstehen sich. Absendernummer beim Angerufenen: +498912345-1234 (korrekte Durchwahl). -> OK.
3. Externer Anruf Ausland: Linzer User ruft Lieferant in Deutschland an. Call geht über deutschen trunk, kommt an, Qualität gut. Gebühren in CDR korrekt als Ausland. -> OK.
4. Eingehender Anruf auf deutsche Nummer: Kunde wählt +49 89 12345-1000 (Mitarbeiter Müller). Call landet bei Müller’s Teams-Client, klingelt, Name des Kunden (wenn im Outlook) wird angezeigt, Gespräch erfolgreich. -> OK.
5. Eingehender Anruf Schweizer Nummer: Externer ruft +41 44 6667777 (Zürich Hauptnummer). Auto Attendant der Firma geht ran mit deutscher Ansage (sollte zweisprachig sein -> Fehler entdeckt: Man entscheidet auf Schweizer Nummer eine andere Ansage zu schalten in Landessprache. Korrektur nach Test).
6. Hotline Callqueue: Kunde ruft Kundenhotline +49 89 12345-2000. Alle 5 Agents (3 in München, 2 in Linz) bekommen den Anruf gleichzeitig (parallel Ring). Linzer Agent nimmt ab, Kunde wird verbunden. Der Agent transferiert den Call intern zum Spezialisten in München – Transfer klappt, Kunde wird gehalten mit Musik, Spezialist übernimmt. -> OK.
7. Voicemail-Funktion: Anruf auf Durchwahl von Mitarbeiter, der offline ist. Nach 20s Voicemail springt an, standard Ansage. Anrufer hinterlässt Nachricht. Mitarbeiter erhält innerhalb 1 Minute eine Outlook-Mail mit Transkript und kann in Teams abhören. -> OK.
8. Faxempfang/Test: Externer sendet Fax an alte Nummer +49 89 12345-300 (nun am Faxserver via SBC). Fax kommt an Faxserver-PDF und wird dem zuständigen per Mail zugestellt. -> OK (Faxserver Integration hat also funktioniert). Sende-Fax getestet: Faxserver -> SBC -> PSTN – OK, jedoch Hinweise, dass nur niedrige Baudrate stabil war (ist akzeptabel).
9. DECT-Telefon Integration: Lagermeister mit DECT (an alter PBX) soll noch erreicht werden. Teams-User ruft seine Kurzwahl 777 – anynode leitet an PBX, DECT klingelt. -> OK. (Dieser Punkt bleibt übergangsweise bis man DECT ablöst.)
10. Notruf Deutschland, intern getestet: In München wird vom Notfallapparat (Teams Common Area Phone) die 112 gewählt, aber statt realer Leitung hat man testweise eine Konfiguration, die auf interne Empfangsgruppe geht (Testmodus). Das Telefon wählt, es klingelt beim Empfang, die zeigen innerhalb 5s Reaktion. -> OK. (Danach realer Test mit Leitstelle separat mit Management geplant).
11. Notruf Schweiz, Test mit Leitstelle: In Absprache mit Stadt Zürich wird ein Testcall von einer Teams-Nr gemacht. Notruf geht zur Leitstelle 144, der Disponent meldet sich, man erklärt Test. Er liest die Adresse vor, die deren System anzeigt – es ist korrekt die Hardturmstr. -> OK. (CH trunk übermittelte Adresse, gut. Man klärt noch, dass 144 statt 118 ging – in CH egal, 112/117/118/144 alles erreichbar).
12. Leitstellen-Rückruf: Im Anschluss ruft die Leitstelle auf die Nummer zurück, die angezeigt wurde (die Hauptnummer). Im Konzept hat man eingestellt, Rückrufe von Notruf gehen auf Empfang. Der Empfang meldet sich, kann Test bestätigen. -> OK.
13. Szenario Internetausfall: Simulation: Internetrouter in Linz deaktiviert. Linzer Kollegen werden offline in Teams (können dann logischerweise nicht telefonieren). Die Failover-Lösung: alle eingehenden Anrufe auf Linzer DDI hat der SBC München nach 5s keine Antwort so konfiguriert, dass er sie dem Auto Attendant in München gibt, der eine Ansage abspielt: „Der Teilnehmer ist momentan nicht erreichbar.“ Hier wollte man ggf. auf Mobil weiterleiten, aber mangels Mobilnummern verzichtet. -> OK (akzeptiert als Kompromiss, da Ausfall selten und kurz). Nach Routerneu -> Linz wieder registriert, alles normal.

Diese Tests decken die meisten kritischen Fälle ab. Die Ergebnisse wurden protokolliert. Wo Fehler entdeckt (Sprachansage Sprache) wurde nachgebessert.

Durch diese konkrete Übung konnten alle Beteiligten die Funktionsweise validieren und Vertrauen in das neue System aufbauen.

Fazit & Maßnahmenplan

Fazit

Die Einführung von Telefonie mit Microsoft Teams (Direct Routing) und anynode als SBC-Beispiel zeigt sich als zukunftsweisende Kommunikationslösung: Unternehmen können damit ihre verteilten Standorte einheitlich vernetzen, traditionelle Telefonanlagen konsolidieren und die Flexibilität der Cloud nutzen – ohne auf bewährte Telefonie-Standards wie lokale Rufnummern oder Integrationen verzichten zu müssen.

Der Fachartikel hat die Architekturprinzipien (von einfachen zu komplexen Szenarien), die Implementierungsdetails (Netzwerk, SBC-Konfiguration, Wählpläne) und den Betrieb (Monitoring, Troubleshooting) ausführlich beleuchtet. Zentrale Erfolgsfaktoren sind eine sorgfältige Planung (insbesondere hinsichtlich Nummerierung und Notrufen), die enge Zusammenarbeit zwischen Netzwerk-, IT- und Sicherheitsteams sowie die Einbindung der Anwender durch Schulung und Change-Management.

Teams-Telefonie bietet zahlreiche Funktionen, von Voicemail bis Konferenz, die traditionellen TK-Systemen entsprechen oder diese übertreffen. Gleichzeitig müssen besondere Themen – etwa Fax oder Alarmanlagen – individuell gelöst werden, meist durch SBC-Vermittlung oder alternative Dienste.

Im Betrieb erleichtern moderne Monitoring-Tools das Sicherstellen von Sprachqualität und Verfügbarkeit. Dennoch bleiben Risiken wie Ausfälle oder Fehlkonfigurationen, die es aktiv zu managen gilt. Mit Redundanz (hochverfügbare SBCs, duale Trunks) und klaren Prozessen (Notfallpläne, regelmäßige Tests) lässt sich das Telefoniesystem jedoch sehr robust gestalten.

In Summe befähigt der Umstieg auf Teams-Telefonie Unternehmen dazu, ihre Kommunikation in die digitale Zukunft zu führen: effizienter, standortunabhängig und integriert in die Collaboration-Plattform. Die detailreiche Ausarbeitung dieses Artikels dient als Leitfaden, um dabei technisch sauber, sicher und betriebsstabil vorzugehen. Mit dem vermittelten Wissen können Verantwortliche ein solches Projekt strukturiert angehen – von der Architekturplanung über die konkrete Umsetzung mit anynode bis hin zum laufenden Betrieb mit Monitoring und kontinuierlicher Optimierung.

30-/60-/90-Tage-Maßnahmenplan

Um ein Projekt „Teams-Telefonie mit Direct Routing“ erfolgreich umzusetzen, empfiehlt sich ein gestaffelter Ansatz über 90 Tage:

• Innerhalb der ersten 30 Tage (Planung & Vorbereitung):
• Projektteam aufstellen (UC-Experte, Netzwerk, Security, User Adoption Verantwortlicher). Kickoff mit allen Stakeholdern.
• Bestandsaufnahme der aktuellen Telefonie (Nummern, Verträge, Geräte, Integrationen) abschließen. Anforderungen der Fachbereiche sammeln (z. B. Gruppen, Warteschlangen, Sondergeräte).
• Entscheidung für PSTN-Anbindungsmodell (hier: Direct Routing mit anynode) final treffen. Grobkonzept der Zielarchitektur erstellen, inklusive SBC-Platzierung und Redundanzstrategie, und vom Management absegnen lassen.
• Kontakt mit Telefonie-Carrier aufnehmen: Angebote für SIP-Trunk einholen, Portierungsprozess anstoßen (ohne sofort zu portieren, aber vorbereiten).
• anynode Testlizenz besorgen und in Laborumgebung installieren. Bereits einen grundlegenden Connectivity-Test mit Teams in einem Test-Tenant oder Pilottendant durchführen (z. B. mit 1-2 Dummy-Nummern, um Umgebung kennenzulernen).
• Parallel: Netzwerk überprüfen – eventuell Bandbreitentests an Standorten durchführen, QoS-Konzept entwerfen und erste Konfiguration in einer Filiale pilotieren.
• Notrufkonzept entwerfen: Verantwortliche im Arbeitsschutz/Security involvieren, grobe Strategie für Notrufe pro Land festlegen. Evtl. rechtliche Beratung einholen.
• Kommunikationen: Frühankündigung ans Unternehmen („Wir modernisieren unsere Telefonie in den kommenden Monaten, es kommt MS Teams – weitere Infos folgen“), um Gerüchte zu vermeiden und Bereitschaft zu schaffen.
• Bis Tag 60 (Umsetzung & Pilotierung):
• Hardware/Software beschaffen: anynode Lizenzierung klären (Kauf oder Miete), ggf. Server/VM bereitstellen. SBC-Server aufsetzen (inkl. OS Hardening, Zertifikate beschaffen und installieren).
• Konfiguration der Teams-Telefonie im Tenant: Domains einrichten, Benutzer-Pilotgruppe auswählen, notwendigen Lizenzen zuweisen.
• anynode SBC mit Microsoft Teams verbinden (Direct Routing konfigurieren) und mit gewähltem SIP-Provider verbinden – zuerst im Testbetrieb mit wenigen Nummern. Feinabstimmung Dial Plan und Routingregeln, bis Testanrufe zuverlässig funktionieren.
• Pilotgruppe von Usern (z. B. IT oder freundliche Abteilung) auf Teams-Telefonie migrieren: deren Rufnummern entweder portieren oder weiterleiten, Endgeräte (Headsets) ausgeben, Schulung durchführen. Pilot mind. 2 Wochen laufen lassen. Feedback sammeln, Probleme debuggen (z. B. falls ein Fax nicht ankam, etc.) und Lösungen implementieren.
• Parallel: Erstellen von Endbenutzer-Dokumentation und Kurzleitfäden. Finalisieren des Schulungskonzepts für den großen Rollout (evtl. Schulungsunterlagen, Videos vorbereiten).
• Entscheidung über alte TK-Anlage treffen: ob Koexistenz oder Big-Bang-Ablösung. Falls Koexistenz: Schnittstellen (SBC zu PBX) jetzt einrichten/testen.
• Alle Integrationen testen: Fax über SBC -> funktioniert? Alarmanlagen test? Türsprechstellen mit Testcall? Probleme jetzt bereinigen.
• Notruf: Adressen in Teams Admin Center einpflegen, dynamic location (Subnets, WiFi) konfigurieren. Test-Notrufe intern (zur IT oder mit Absprache Feuerwehr wenn möglich) durchführen und Ergebnisse dokumentieren. Falls Lücken, bis Tag 90 Maßnahmen definieren (z. B. noch analoges Gerät beschaffen).
• Bis Tag 60 sollte ein detaillierter Migrationsplan je Standort fertig sein (Wer wird wann migriert, welche Nummern an welchem Tag portiert, wer informiert).
• Nach 90 Tagen (Rollout & Betriebsübergabe):
• Hauptrollout durchführen laut Plan: Rufnummernportierungen in Etappen, Benutzer in Wellen migrieren. Täglich den Fortschritt evaluieren, auf Issues schnell reagieren (täglich Stand-up Meeting im Projektteam in intensiver Rollout-Phase).
• Laufend Kommunikation an User vor jeder Welle (Erinnerung „Morgen Umstellung!“) und nach jeder Welle (Feedback-Möglichkeit bieten, z. B. Umfrage für Erfahrungen).
• Projekt-Hypercare: In den ersten 2-4 Wochen nach vollständiger Migration verstärkten Support bieten (Hotline, Floorwalker). Typische Probleme der Nutzer lösen (z. B. Soundeinstellungen justieren).
• Monitoring-System final konfigurieren und an das Operations-Team übergeben (Dashboards mit SBC-Status, QoS-Monitor im CQD).
• Abschluss der Dokumentation: „As-built“-Dokumentation der Lösung erstellen (Topologieplan, Konfig-Backups, Notfallhandbuch).
• Abschlussmeeting mit Stakeholdern: Ergebnisse präsentieren (Projektziele erreicht, z. B. X € Einsparung, Y% bessere Erreichbarkeit). Offene Punkte besprechen und in Nachprojekt überführen (z. B. „DECT-Ablösung in Phase 2“).
• Offizielle Übergabe an den IT-Betrieb: Verantwortlichkeiten klären (wer macht Moves/Add/Changes, wer meldet bei Störungen an Provider/Microsoft). Betriebsteam schulen an Admin-Tools (TAC, anynode GUI, Troubleshooting).
• Nach 90 Tagen sollte die Telefonie im stabilen Regelbetrieb sein. Das Projektteam kann aufgelöst oder für Optimierungen verkleinert weiterarbeiten.

Durch diesen 30/60/90-Tage-Plan wird sichergestellt, dass das komplexe Vorhaben in sinnvolle Etappen gegliedert ist. Jede Phase hat klare Ziele – von der Planung über Pilotierung bis zum vollständigen Rollout und Übergang in den Betrieb. Mit dem hier vermittelten Wissen und Plan können Unternehmen eine Migration zu Teams-Telefonie strukturiert angehen und erfolgreich abschließen.

Weitere Beiträge zum Thema SharePoint und Teams