Blog

Dieser Artikel ist "Work in Progress" und wird laufend mit Empfehlungen/Best-Practices erweitert.

Annahmen

In diesem Artikel gehen wir von einem typischen Mittelstandsunternehmen aus.

Mehrere hundert Mitarbeiter an verschiedenen Standorten verfügen über schnelle Standortverbindungen und eine moderne Serverlandschaft mit VMware- oder Hyper-V-Virtualisierung.

Die Mitarbeiter sollen sich an allen Standorten anmelden können und dort die von STARFACE bereitgestellten Kommunikationsdienste nutzen.

Vorwort

Die Verfügbarkeit von Kommunikationsdiensten ist für viele Unternehmen von höchster Priorität. Mit dem Wandel der Kommunikationsnetze von TDM zu IP-basierten Next Generation Networks (NGN) und der Möglichkeit, die Kommunikationsdienste virtualisiert – in Form gewöhnlicher Serverdienste – bereitzustellen, ergeben sich neue Möglichkeiten der Hochverfügbarkeit und Skalierbarkeit.

Wurden bisher meist Aktiv/Passiv-Gerätekonfigurationen verwendet, um den Ausfall eines Primärgeräts abzusichern, stehen heute verschiedene Redundanzszenarien zur Verfügung, die die unterschiedlichen Anforderungen an Service-Level und eventuelle Wiederherstellungszeiten im Disaster Recovery-Fall abdecken.

Die Bereitstellung von Kommunikationsdiensten in Form von IT-Diensten ist deshalb nicht nur der logische Schluß aus der Konvergenz der Daten- und Kommunikationsnetze, sondern auch das Mittel der Wahl, um hohe Verfügbarkeit und einfaches bzw. einheitliches Management zu garantieren.

Ein virtualisiertes Kommunikationssystem skaliert nicht nur mit den zur Verfügung gestellten Ressourcen, sondern läßt sich auch in vorhandene Backup- oder Disaster-Recovery-Strategien integrieren: Backups, Snapshots, Replikationen, Fault Tolerance und weitere Technologien erlauben es unter Abwägung von Ressourceneinsatz und Komplexität die geforderte Verfügbarkeit zu erreichen. Dabei lassen sich bereits etablierte Strategien, Richtlinien und Notfallkonzepte unmittelbar auf den Kommunikationsdienst anwenden, was die Komplexität und damit Anwenderfehler reduziert und im Fall der Fälle eine schnelle Wiederherstellung der unternehmenskritischen Anwendung ermöglicht.


STARFACE Plattformen & STARFACE Flip

Das STARFACE Kommunikationssystem basiert auf einem CentOS Linux System, auf dem unter anderem der STARFACE Applikationsserver (auf Basis von tomcat), der HylaFax Faxserver und der CallHandler Asterisk Business Edition arbeiten.

Da es sich technisch gesehen also um ein Linux-Serversystem handelt, ist es wenig verwunderlich, dass STARFACE auch auf den typischen IT-Diensteplattformen "Appliance", "Cloud" und "VM"  betrieben wird.

Die VM-Edition enthält Integrationstreiber für VMware und Hyper-V und ist ansonsten identisch mit der auf Appliances oder in der Cloud installierten STARFACE Software.

STARFACE Flip beschreibt die Möglichkeit, jederzeit von einer Plattform auf eine andere zu wechseln. Hierfür muß lediglich eine Serverlizenz für die Zielplattform vorhanden sein. Benutzer- und Feature-Lizenzen lassen sich beliebig übertragen – ebenso wie die Konfiguration und Daten (Ruflisten, Voicemails, Faxe, etc.).


Vorteile der TK-Virtualisierung

Im folgenden Abschnitt beleuchten wir Gründe, warum es von Vorteil ist, STARFACE primär virtualisiert zu betreiben.

Qualität der eingesetzen Hardware

Es ist nicht unüblich, dass Unternehmen deutlich mehr in in Ihre IT-Landschaft bzw. Server-Infrastruktur investieren, als in die Hardware einer Telefonanlage. Die Server- und Netzwerk-Infrastruktur ist für die Bereitstellung von Geschäftsanwendungen und für die Aufrechterhaltung des Geschäftsbetriebs verantwortlich und hat daher – wenig überraschend – einen hohen Stellenwert.

In mittelständischen Unternehmen und erst recht im Enterprise-Umfeld finden sich daher typischerweise:

  • Hochverfügbare Cluster, bestehend aus mehreren Servern an unterschiedlichen Standorten
  • Markenserver mit hochwertigen und für höchste Verfügbarkeit ausgelegten elektronischen Bauteilen
  • Server-Virtualisierung mit HA-Mechanismen
  • Fehlererkennender und -korrigierender Speicher (ECC-Speicher)
  • Hochverfügbare und redundant per Multi-Pathing angebundene SANs, basierend auf Disk-Arrays in RAID-Verbünden, mit wiederum redundanten Anbindungen einzelner Hot-Swap SSDs/HDDs an unterschiedliche Host-Adapter (Dual-Port SAS) und Server-SSDs/HDDs mit erhöhter Ausfallsicherheit und geringeren Lesefehlerraten
  • Redundante und hot-swap-fähige Netzteile und Lüfter, redundante und unterbrechungsfreie Stromversorgung (USV)
  • Aktive Klimatisierung
  • Link-aggregierte Netzwerkverbindungen
  • Hochwertige Verkabelung (Klasse EA Twisted-Pair oder LWL)
  • Hardware-Monitoring und Auslastungsüberwachung
  • Backup- und Disaster-Recovery-Konzepte; Off-Site-Backups

Typische TK-Systeme sind im Gegensatz dazu meist sehr einfach gestrickt. Redundanz bedeutet hier meist, identische Hardware vorzuhalten und im Besten Fall in einem Aktiv-/Passiv-Verbund zu betreiben. In Form reiner Hardware-Investitionskosten (Endgeräte ausgenommen) liegen typische TK-Systeme deshalb oft zwischen einem Zehntel und einem Hundertstel der IT-Hardwareinvestitionen.

Bei der Bereitstellung von Kommunikationsdiensten in Form von IT-Diensten läßt sich jedoch von der Qualität und Verfügbarkeit der IT-Infrastruktur profitieren – indem die TK als virtualisierter Dienst auf dieser Infrastruktur ausgeführt wird.

Skalierbarkeit

Vor der Anschaffung eines neuen TK-Systems stellt sich in der Regel die Frage nach der Dimensionierung. Sollen 50, 100, 500 oder über 1.000 User das System nutzen? Welche Annahmen können bezüglich der gleichzeitigen Nutzung bzw. Spitzenlasten getroffen werden? Welche zusätzlichen Funktionen soll das System unter Umständen in Zukunft mit übernehmen?

Die Empfehlung "Nehmen Sie eine Größe größer, Sie wachsen schon rein", soll hier vorhandene Unsicherheiten durch Schaffung eines "Puffers" berücksichtigen.

Genau diese Überlegungen haben Unternehmensentscheider bereits bei der Dimensionierung der IT-Infrastruktur (hoffentlich) berücksichtigt, so dass in der Regel ausreichend Leistungsreserven vorhanden sind um das zu erwartende Wachstum der nächsten Jahre aufzufangen. Die TK-Virtualisierung erlaubt es, diese Leistungsreserven bei Bedarf zu nutzen. Wenn Mitarbeiterzahlen anwachsen oder weitere Standorte hinzukommen, bedeutet das für den Betrieb des TK-System in der Regel einfach nur das Zuweisen von etwas mehr Arbeitsspeicher, Storage und vielleicht eines weiteren CPU-Kerns. Das System skaliert mit den zur Verfügung gestellten Ressourcen.

Wiederherstellbarkeit

Durch die Abstraktion physikalischer Hardware sind virtualisierte Systeme prinzipiell unabhängig von der konkreten Betriebsumgebung und lassen sich ohne Weiteres auf andere Serverhardware migrieren. Der unter Umständen schwierige oder zeitaufwändige Vorgang, kompatible Austauschhardware zu beschaffen entfällt.

Auch ist die Wiederherstellbarkeit einer kompletten VM mit gängigen Backup- und Disaster-Recovery-Tools nur noch eine Frage weniger Mausklicks.

Vor Änderungen der Konfiguration oder Systemupdates läßt sich in Sekundenschnelle ein VM-Snapshot anlegen, der ebenso schnell wieder zurückgespielt werden kann. So verlieren Updates oder Konfigurationsänderungen ihren Schrecken. Auf physikalischer Hardware wäre für ein Downgrade nach einem Update eine aufwendige Neuinstallation notwendig.

Betriebswirtschaftliche Aspekte

Die Anschaffung physikalischer TK-Systeme bedeutet im Rahmen der Budgetplanung für die ITK-Verantwortlichen auch die Berücksichtigung möglicher Defekte, Reparaturen oder Neuanschaffungen von Hardware nach Ablauf von Garantie- und Gewährleistungszeiträumen (die in der Regel deutlich kürzer sind als die zu erwartende Nutzungsdauer; Annahme nach AfA-Tabelle: 10 Jahre). Darüber hinaus muss die Ersatzteilverfügbarkeit sichergestellt und notfalls Ersatzteile bevorratet werden.

Ein virtualisiertes System, welches prinzipiell nur noch aus Lizenzen (also aus Nutzungsrechten an einer Systemsoftware) besteht, birgt keine Risiken eines Defekts und ist in der Nutzungsdauer uneingeschränkt. Über entsprechende Updateverträge läßt sich ein System, welches gänzlich aus Software besteht, dauerhaft auf einem aktuellen Stand halten – ganz ohne alternde Hardware.

Ansonsten ergeben sich natürlich noch die ganz typischen Kostenvorteile der Virtualisierung: Einsparungen in Bezug auf die anzuschaffende TK-Hardware, Strom, Kühlung, Rackspace, Netzwerkports und geringere Personalkosten aufgrund administrativer Vorteile.


Redundanz-/HA-Konzepte

Die Bereitstellung der verschiedenen Redundanzfunktionen fällt bevorzugt in den Aufgabenbereich eines Hypervisors. Es handelt sich hierbei also nicht um besondere Funktionen des STARFACE Kommunikationssystems.

Im vorliegenden Fall gehen wir von einer zentralen STARFACE VM-Edition aus (anstatt einzelnen Anlagen an den verschiedenen Standorten), was sich aus administrativer Sicht sowie mit Blick auf die Lizenzkosten als vorteilhaft erweist. Außerdem sieht das Konzept die Ergänzung der primären VM-Edition um eine physikalische Appliance vor, um so auch einen Ausfall der Virtualisierungsinfrastruktur mit einer Wiederherstellungszeit von wenigen Minuten abzubilden.

Für die einzelnen Standorte wird angenommen, dass die zur Verfügung gestellte virtualisierte Hardware identisch ist (gleiche Art und Anzahl der virtuellen CPU-Kerne). Aus technischen Gründen ist das zwar nicht notwendig, jedoch verwendet das STARFACE Lizenzsystem zur Identifikation einer konkreten Installation eben diese CPU-Eigenschaften/Funktionen. Ändert sich der Prozessortyp oder die Anzahl der Kerne, ergibt sich für das System eine neue Hardware ID, die im STARFACE Lizenzserver zunächst neu mit der Serverlizenz verknüpft werden muß. Ein Umzug auf ein System mit identischem Prozessortyp ist für die Installation hingegen transparent.

Desweiteren wird angenommen, dass als Virtualisierungsumgebung VMware vSphere mit vCenter Server und Site Recovery Manager (SRM) in einem HA-Cluster oder Hyper-V auf Windows Server 2012 R2 (oder neuer) in einem Failover-Cluster zum Einsatz kommt.

Empfehlungen bezüglich der Virtualisierungsumgebung

Die STARFACE stellt latenzkritische Dienste zur Verfügung. Die Anforderungen an die physikalische Hardware sind zwar eher gering, dennoch sollte das System hohe IO-Raten erlauben. STARFACE Appliances enthalten SSD-Speicher, so dass die Eigenschaften dieser Speichermedien eine Grundannahme des Herstellers in Bezug auf die vom System bereitgestellten IO- und Durchsatzraten sind.

Die Virtualisierungsumgebung sollte aus einem Failover-Cluster identischer Virtualisierungshosts bestehen und ein schnelles SAN redundant anbinden. Die Netzwerkverbindungen der Hosts sollten über Link-Aggregationen redundant ausgelegt sein. Ein separates Netz mit hoher Bandbreite sollte für die Migration von VMs eingerichtet sein.

Auch wenn es überflüssig scheint, es zu erwähnen: Server gehören an eine ausreichend dimensionierte Online-USV!
Die Server sollten über redundante Netzteile verfügen, von denen jedes Netzteil an einer anderen USV angebunden ist. Dem Ausfall einzelner Netzteile und auch einzelner USVs wird so begegnet.
Bei erhöhten Verfügbarkeitsanforderungen sollte eine Notstromversorgung in Form von Diesel-/Gas-/Brennstoffzellen-Generatoren bereitgehalten werden, um über die Überbrückungszeit der USVs hinaus den Betrieb sicherstellen zu können.

Die STARFACE VM sollte Bestandteil der VM-Backups sein und in regelmäßigen Intervallen gesichert werden. Das VM-Backup sollte nach Möglichkeit rückwärtsinkrementell sein, was zwar einen erhöhten Overhead beim Erstellen des Backups bedeutet, jedoch eine deutlich schnellere Wiederherstellung erlaubt.

Vor Konfigurationsänderungen sollten VM-Snapshots erstellt werden, die ein schnelles Rollback erlauben. Nach erfolgreicher Konfigurationsänderung sollten die Snapshots gelöscht werden, da diese die Performance der VM verschlechtern.

Empfehlungen bezüglich der Netzwerkinfrastruktur

Für Telefonieendgeräte sollten VLAN-fähige PoE-Switches eingesetzt werden, die eine Endgeräteerkennung über LLDP-MED ermöglichen. Für die Telefonie sollte ein eigenes VLAN eingerichtet und priorisiert werden. Telefonieendgeräte werden am Besten per LLDP-MED für das Voice-VLAN konfiguriert. Durch ein separates Voice-VLAN werden effektiv IP-Adresskonflikte mit anderen Netzwerkgeräten verhindert und die Netzwerksicherheit erhöht. STARFACE und Endgeräte sind nur noch über Routing erreichbar, was die Implementierung von Firewallregeln bzw. einer Zugriffssteuerung an den Subnetzgrenzen erlaubt.

Die PoE-Switches, Router und Firewalls sollten ebenfalls über USVs abgesichert sein, damit im Falle eines Stromausfalls die Telefonie und insbesondere die Notruffähigkeit erhalten bleibt.

Da Switches meist einen "Single Point of Failure" darstellen, bietet es sich an, auch Dienste wie DHCP für das Telefonienetz vom Core-Switch bereitstellen zu lassen (vorausgesetzt, die Switches haben diese Funktionalität). Beim Ausfall des Switches hilft ein verfügbarer DHCP-Server nicht mehr. Wird der DHCP-Dienst auf einem Switch konsolidiert, werden so zwei mögliche Fehlerquellen zu einer und die Verfügbarkeit insgesamt erhöht.


Organisatorische Maßnahmen

1. Richten Sie regelmäßige VM-Backups auf Ihrem Virtualisierungshost ein!

STARFACE Backups und VM-Backups dienen unterschiedlichen Anwendungsfällen. Während sich STARFACE Backups für die Notfallwiederherstellung auf einer anderen Plattform eignen, lassen sich mit Hilfe von VM-Backups sehr schnell crash-konsistente Wiederherstellungen auf Hypervisor-Ebene durchführen, die deutlich geringere RTOs erlauben. Da hierbei das vollständige System (inkl. Betriebssystem und eventueller Individualanpassungen) gesichert und wiederhergestellt werden kann, stellen VM-Backups in der Regel die primäre Wiederherstellungsoption dar. Außerdem entspricht der organisatorische Ablauf einer Wiederherstellung der STARFACE-Installation aus einem VM-Backup exakt der Wiederherstellung anderer virtualisierter Systeme, was Sicherheit und Effizienz durch bekannte Abläufe verspricht.

VM-Backups lassen sich parallel währende des Betriebs wiederherstellen, was sehr kurze Unterbrechungszeiten möglich macht.

Weiterer Vorteil: Aus VM-Backups lassen sich schnell virtualisierte Testumgebungen herstellen.

2. VM-Snapshots eignen sich gut als Wiederherstellungspunkt vor Konfigurationsänderungen

Verwenden Sie VM-Snapshots um vorKonfigurationsänderungen einen Wiederherstellungspunkt zu erzeugen. Löschen Sie die VM-Snapshots regelmäßig, sobald die Konfigurationsänderungen akzeptiert und dokumentiert sind.

Lokale Redundanz

Lokale Redundanz kann über Funktionen wie VMware Fault Tolerance (FT) erreicht werden. Hierbei wird eine identische STARFACE-Instanz synchron innerhalb des VMware-Clusters ausgeführt (Active Secondary). Der Ausfall eines physikalischen Hosts wird automatisch und unterbrechungsfrei kompensiert.


Hyper-V

Eine ähnliche Hochverfügbarkeitsfunktion für lokale Redundanz steht auch In Hyper-V-Umgebungen mit Hyper-V Live Migration zur Verfügung.

Geo-Redundanz

Bei der geografischen Redundanz, werden die Standorte in einen Hauptstandort, Sekundärstandort und vielleicht sogar einen Tertiärstandort unterteilt. Ein Sekundärstandort stellt den Betrieb des STARFACE Kommunikationssystems sicher, sollte der Primärstandort ausfallen. Der Tertiärstandort stellt den Betrieb bei Ausfall von Primär- und Sekundärstandort sicher.

Hierfür kommen die Funktionen des VMware Site Recovery Managers (SRM) zum Einsatz: Im Falle eines Ausfalls des primären Standorts, werden Replikate der STARFACE VM-Edition am sekundären oder tertiären Standort gestartet.

Ein Failover auf geo-redundanter Basis ist in der Regel nicht unterbrechungsfrei, sondern geht meist mit einem Abbruch laufender Gespräche und einem Ausfall der Telefoniefunktion im Bereich von Sekunden bis wenigen Minuten einher. Die Ausfallzeit wird hauptsächlich durch die Konvergenz des jeweils eingesetzten IP-Routingprotokolls bestimmt. Auf Router-Ebene müssen die Verbindungen der Endgeräte/Clients und Mediengateways zur sekundären oder tertiären STARFACE VM (mit identischer IP-Adresse) an einem anderen Standort geroutet werden. Bei Einsatz von OSPF mit BFD können die Konvergenzzeiten jedoch stark reduziert werden.

Wichtig ist, dass die STARFACE VMs an den weiteren Standorten mit identischer IP-Adresskonfiguration starten. Hierfür sollte ein separates Netz angelegt werden. Nur so ist sichergestellt, dass sich die Endgeräte unverzüglich nach Verfügbarwerden der Redundanz-VMs an diesen Anmelden. Die "Umschaltung" auf die Geo-Redundanzanlagen ist somit auf die Ebene des Netzwerk-Routings verlagert.


Hyper-V

Eine ähnliche Hochverfügbarkeitsfunktion für Geo-Redundanz steht auch In Hyper-V-Umgebungen mit Hyper-V Replicas zur Verfügung. Die RPO ist ab Windows Server 2012 konfigurierbar (30 Sekunden, 5 Minuten oder 15 Minuten).

Plattform-Redundanz

Gerade in Notfallszenarien kann die Möglichkeit der telefonischen Kommunikation besonders wichtig sein. Darum sollte man sich im Rahmen einer Notfallstrategie auch mit dem Ausfall der Virtualisierungsinfrastruktur und der gleichzeitigen Anforderung einer Aufrechterhaltung von Kommunikationsdiensten beschäftigen.

Der Mischbetrieb einer Kombination aus STARFACE VM-Edition und physikalischer Appliance ist genauso möglich, wie das Verschieben oder Kopieren einer Instanz in eine STARFACE Cloud. Kopiert werden hierbei lediglich die Konfiguration, Datenbankinhalte sowie Faxe und Voicemails – was in Summe nur wenige Megabyte Daten ausmacht und somit sehr schnell vonstatten geht.

Durch das Mischen der verschiedenen Plattformen (VM, Appliance, Cloud) kann man sich so gegen den möglichen Ausfall einer einzelnen Plattform (z.B. der eigenen Virtualisierungslandschaft) absichern. Die Plattform-Redundanz kann lokal oder standortübergreifend realisiert werden.

Wird eine Plattform-Redundanz der STARFACE implementiert sind für den reibungslosen Betrieb zwei Dinge zu beachten:

  1. Für die Wiederherstellung einer STARFACE-Instanz auf einer separaten Appliance oder in der Cloud ist ein möglichst aktuelles Backup des Live-Systems erforderlich. Live-Systeme sollten daher in regelmäßigen Abständen Backups auf externe und im Disaster-Fall erreichbare Medien geschrieben werden. Das Backup-Intervall wird durch die Anforderungen an die Recovery Point Objective (RPO) definiert – dem willentlich in Kauf genommenen Datenverlust (Ruflisten, Voicemails, Faxe) im Falle einer Notfallwiederherstellung.
  2. STARFACE Backups lassen sich importieren, solange auf dem importierenden System die gleiche oder eine neuere Systemversion läuft, als auf dem System, das die Backups erzeugt hat. Wird das Redundanzsystem nicht auf dem Versionsstand des Live-Systems gehalten, kann es im Falle einer Notfallwiederherstellung vorhandene Backups nicht importieren und müßte zunächst per Update oder Neuinstallation vorbereitet werden. Im Fall der Fälle hätte dies eine deutliche Verschlechterung der Recovery Time Objective (RTO) zur Folge.


Organisatorische Maßnahmen

1. Richten Sie regelmäßige Backups innerhalb der STARFACE ein!

Weiterführende Informationen unter https://knowledge.starface.de/display/wiki64/Neues+Backup+konfigurieren

2. Aktualisieren Sie bei einem Update des Live-Systems unbedingt auch Ihre Redundanzsysteme!

Halten Sie Live- und Redundanzsysteme auf dem gleichen Versionsstand!

DECT vs. WLAN

Bei der Telefonie über WLAN (nach 802.11) gibt es grundlegende Unterschiede im Vergleich zu DECT.

DECT wurde ursprünglich für die Telefonie entwickelt, WLAN für die Datenkommunikation. Hieraus ergeben sich wichtige Unterschiede in Bezug auf die Dienstgüte. DECT ist optimiert auf minimale Verzögerung und gleichbleibende Verbindungsqualität bei geringem Stromverbrauch. Bei WLAN sind diese Parameter abhängig von der Anzahl, Art und Signalstärke von WLAN-Endgeräten.

Physikalische Eigenschaften und Medienzugriff

Das 2,4GHz Band, das von WLAN nach 802.11b verwendet wird (aber auch das 5GHz Band für WLAN nach 802.11a) gehört zum ISM-Band für die Allgemeinnutzung.
Im 2,4GHz-Bereich tummeln sich neben WLAN (802.11b), Bluetooth, ZigBee, Mikrowellenherden, Radargeräten und CO2-Lasern auch Funkfernsteuerungen und allerhand weitere "Allgemeinnutzer". Physikalisch nutzbar ist ein Kanal immer nur von einem Sender/Empfänger. Die Geräte wechseln sich also ab.

Im 5GHz Band ist militärisches Radar Primärnutzer. WLAN, drahtlose Videoübertragungssysteme und andere ISM-Band-Nutzer sind Sekundärnutzer, die dafür Sorge tragen müssen, dass Primärnutzer nicht gestört werden. In 802.11a und 802.11h wurden deshalb Funktionen implementiert (DFS, TPC, ...), die dafür sorgen, dass bei Erkennung von Radar das WLAN-System einen Kanalwechsel durchführt. Da die neuen Kanäle auf Radar geprüft werden müssen, kann ein solcher Kanalwechsel durchaus bis zu mehrere Minuten dauern – während dieser Zeit ist die WLAN-Verbindung unterbrochen (Außenanbindungen/Richtfunkstrecken sind hiervon immer mal wieder betroffen). Durch das fast 300 MHz breite Band haben Kanalwechsel außerdem Auswirkungen auf die Streckendämpfung.

Das europäische DECT-Band befindet sich deutlich unterhalb des für die Allgemeinnutzung freigegeben ISM-Bands, im Bereich zwischen 1,8–1,9GHz. Hier gibt es also keine Störung durch andere ISM-Band-Nutzer.

Der WLAN-Physical Layer verwendet für den Medienzugriff CSMA/CA (Carrier Sense Multiple Access with Carrier Avoidance). Alle Nutzer verwenden den selben Kanal und versuchen Kollisionen zu vermeiden, indem sie den Kanal belauschen und zufällige Zeiträume abwarten (sog. Interframe Spacing Zeiten).
Wenn es zu Kollisionen kommt, wird ein "Backoff" gemacht und erneut eine zufällige Zeit gewartet.
Ohne auf die genauen Details einzugehen ist das Ergebnis ein Medienzugriff, der mit steigender Anzahl der Endgeräte ein immer schlechteres Zugriffsverhalten besitzt. Vor allem ist es zeitlich nicht deterministisch. Bis zum Punkt, an dem ein WLAN-Gerät zwar das Netzwerk "sieht", mit diesem aber nicht mehr kommunizieren kann.
Die verfügbare Kapazität wird bei WLAN von allen WLAN-Geräten und Mitnutzern des selben Bands beansprucht.

DECT funktioniert hier anders: Die Kapazität steht ausschließlich der Telefonie zur Verfügung. Der Medienzugriff erfolgt über ein Frequenz- und Zeitslot-Verfahren (2-dimensionale Spektrumteilung), bei dem sich zwar nur eine begrenzte aber definierte Anzahl an Geräten mit einer Basis verbinden können, weitere Geräte stören den Betrieb nicht. Die Dienstgüte ist gewahrt. Für die kalkulierte Anzahl an Geräten ist die Telefonie auf jeden Fall möglich.

Beim Aufbau von WLAN-Netzen ist darüberhinaus darauf zu achten, dass die Frequenzbereiche der benachbarten AccessPoints disjunkt sind und ausreichend große räumliche Überlappungsflächen bilden -- im europäischen 2,4 GHz Band ist da bei drei benachbarten APs Schluß.
Bei zu kleinen Überlappungsflächen gibt es Probleme beim Wechsel der Funkzelle, bei zu großen Überlappungsbereichen wird man kaum disjunkte Frequenzbereiche schaffen, was zur Sättigung des Mediums führt und die Kapazität verringert.

DECT bietet echtes Roaming und einen unterbrechungsfreien Handover, bei dem während des Handover-Vorgangs zwei parallele Links zu den Basisstationen aufgebaut werden und auf beiden Links die gleichen Sprachinformationen übertragen werden.

Außerdem erlaubt DECT echten Full-Duplex-Betrieb (durch TDD (Time Division Duplex)).

WLAN kennt keinen Full-Duplex-Betrieb. Außerdem wechselt das Gerät die Zelle, wenn die Verbindung zum ersten AP zusammenbricht oder ein besserer AP gleicher SSID vorhanden ist. Es folgt dabei ein erneuter Anmeldevorgang am neuen AP. Sobald die ersten Pakete über den neuen AP gehen bekommt das die Switching-Infrastruktur im Hintergrund mit und aktualisiert die MAC-Tables – unterbrechungsfrei geht anders.
Die IAPP-Funktion (z.B. bei Cisco oder Lancom oder nach 802.11f, welches jedoch wieder zurückgezogen wurde) sorgt außerdem nicht für ein unterbrechungsfreies Handover. Es wird nur mit Hilfe von Multicast IAPP-Packeten der Security Context zwischen APs übergeben und die Stationstabelle aktualisiert. Grund ist der 802.11-Standard (Kapitel 5.4.2.2, 802.11-2007), der zwingend vorschreibt, dass eine Station zu jeder Zeit immer mit maximal einem AP assoziiert ist. Es gibt hier also immer eine Reassoziierungs-Phase, sprich: Verbindungsabbau und Neuaufbau.
Diese gehen zwar in der Regel schnell vonstatten, das konkrete Timing hängt aber von mehreren Parametern ab: Anzahl der Clients im Netz, Geschwindigkeit des Clients, Geschwindigkeit des AP, Latenz für die Authentifizierung (u.U. Radius-Kommunikation).

Gerade bei der Sprachkommunikation per UDP gehen während der Reassoziierungs-Phase Pakete unweigerlich verloren. Bei vorhandener Verbindungssicherung (TCP) hängt es von der Zeitdauer der Reassoziierung und Größe der Dejitter-Buffer in den Endgeräten ab, ob die Verluste hörbar sind.