Systemvoraussetzungen

Umgebungsanforderungen im LAN (Local Area Network) im Rahmen von Cloud PBX

• LAN mit 100/1000 MBit/sec

• Eigener Port am Switch oder Router für jede beteiligte Komponente im IP-Netz

• Höchstens 50ms Verzögerung in einer Richtung (One Way Delay); höchstens 150 ms Gesamtverzögerung

• Höchstens 1% Paketverlust

• Höchstens 20 ms Jitter

• Unterstützung für Quality of Service (QoS) – IEEE802.p, DiffServ (RFC 2474) oder ToS (RFC 791)

• Höchstens 40 % Netzwerkauslastung

• Empfohlene MTU Größe 1492, bei kleineren Werten kann es zu Einschränkungen der CloudPBX Funktionen kommen.

Die eigentliche VoIP Kommunikation basiert auf zwei Protokollen. Das SIP Protokoll wird zur Signalisierung, also zum Auf- und Abbau eines Gespräches verwendet. Die eigentlichen Sprachdaten werden dann in Paketen im RTP Protokoll gesendet und empfangen. Damit Funktionen wie Halten, Weitervermittlung, aber auch die lokale Führung von Medienströmen funktionieren, darf der SIP Verkehr vom Client zum Outbound-Proxy nicht verändert werden. Andernfalls kann der Outbound-Proxy im Netz der Telekom keine Informationen über eine NAT/Masquerading Verbindung gewinnen und eine reibungslose Funktion nicht gewährleistet werden.

DNS Namensauflösung
Für eine erfolgreiche VoIP Kommunikation sollten einige Rahmenbedingungen beachtet werden, um Ausfallsicherheit sicherzustellen. Eine entscheidende Rolle spielt dabei die DNS Auflösung des Outbound Proxy. Hinter dem DNS Namen, der in den VoIP Clients als Outbound Proxy eingetragen wird, verbirgt sich ein NAPTR Eintrag nach RFC 2915. Über die bei der NAPTR Auflösung vom DNS zurückgegebenen SRV Einträge (RFC2782) wird dann das Transport Protokoll und abhängig vom genutzten Internetzugang bzw. den Einstellungen der Firma auch die Nutzung von TLS Verschlüsselung an die Clients kommuniziert. Über die dann folgende SRV Auflösung bekommt der VoIP Client mehrere DNS A-Records / IP Adressen mitgeteilt, die im Fehlerfall redundant angesprochen werden können. Alle VoIP Clients müssen also neben der DNS Auflösung nach RFC 1035 auch die RFCs für NAPTR und SRV Einträge unterstützen. Dies ist bei allen durch die Deutsche Telekom für Cloud PBX vertriebenen Geräten der Fall.
Für die DNS Auflösung ist darüber hinaus, die Nutzung des richtigen DNS Servers zu beachten. Über die DNS Antworten erhält der Client implizit Informationen zum genutzten Internetzugang und ob z.B. im Fall eines Zugangs, der nicht von der Telekom bereitgestellt wird, nur verschlüsselte Kommunikation möglich ist.
Es gibt drei mögliche Unterscheidungen:

• Nutzung eines Telekom Internetzugangs (Telekom Busines DSL Produkte, MagentaHome DSL Produkte,…)

  • Der Name des Outboundproxies muss über die Telekom DNS Server aufgelöst werden, die im Rahmen des DSL Verbindungsaufbaus (via PPPoE) von der Telekom an den Router des Kunden kommuniziert werden.

• Nutzung von symmetrischen Accessprodukten der Telekom (Business Premium Access, DeutschlandLAN Connect IP, Company Connect)

  • Der Name des Outboundproxies muss über die zugehörigen Telekom DNS Server des Accessproduktes aufgelöst werden, die im Rahmen des Vertragsabschlusses von der Telekom an den Kunden kommuniziert werden.
  • Im Gegensatz zum DeutschlandLAN Connect IP und Company Connect bietet der Business Premium Access in Verbindung mit dem Voice VLAN und dem Daten VLAN eine QoS Voice Klasse an.
• Nutzung eines Internetanschlusses, der nicht durch die Telekom bereitgestellt wird (Fremdanschluss)
  • Am Fremdaccess sollte primär der DNS Server des Fremdnetzanbieters genutzt werden.
  • Der DNS Server des Fremdnetzanbieters muss das sogenannte „ECS“ Feature unterstützen.
  • Falls die DNS-Auflösung fehlschlägt, empfehlen wir die Verwendung der BPA DNS Server.

Bandbreitenmanagement des DSL Zugangs
Telekom DSL Anschlüsse verfügen über ein Bandbreitenmanagement für Voice-Over-IP Verkehr zu Telekom Systemen. Das bedeutet, dass beim Rufaufbau geprüft wird, ob genügend freie Bandbreite für Sprachkanäle auf der DSL Leitung zur Verfügung stehen. Ist die Prüfung negativ, so wird der Rufaufbau abgelehnt. Anrufer erhalten in diesem Fall eine Fehleransage. Dies gilt sowohl bei eingehenden als auch ausgehenden Telefonaten.

Für Anschlüsse anderer Anbieter findet keine Prüfung der Bandbreite statt und der VoIP Verkehr wird als „best-effort“ transportiert.

Lokale Medienströme
Werden firmeninterne Telefongespräche geführt, so bleiben die Medienströme, also die RTP Pakete mit den Sprachnachrichten unter bestimmten Voraussetzungen im LAN und werden nicht über den Internetzugang zur Plattform und zurückgeschickt. Dies gilt nur bei Gesprächen zwischen zwei Teilnehmern. Dreierkonferenzen oder größere Gesprächsrunden erfordern immer eine Führung der RTP Pakete zur Cloud PBX Plattform im Netz der Telekom, um hier die einzelnen Sprachkanäle zu mischen.
Damit RTP Ströme lokal im LAN geroutet werden, müssen:

• Alle Endgeräte und VoIP Clients über die selbe öffentliche IP Adresse mit der CPBX Plattform (dem Outbound Proxy) kommunizieren.
• die SIP Nachrichten (genauer die SDP Informationen) die lokalen IP Adressen der Clients enthalten. Dies ist der Normalfall, solange z.B. keine Firewall in den SIP Verkehr eingreift.
• Damit die Endgeräte auch tatsächlich untereinander RTP Pakete austauschen können, müssen die für RTP Pakete im Kapitel „Systemvoraussetzungen Firewall“ beschriebenen Verbindungen innerhalb des lokalen Netzwerkes erlaubt sein.

Während der Rufaufbauphase ist noch nicht bekannt, ob die Medienströme innerhalb des LANs oder über die Telekom Plattform geführt werden. Daher findet bei jedem Telefonat über einen Telekom DSL Anschluss eine Bandbreitenprüfung statt und es kann sein, dass Telefonate abgelehnt werden, wenn alle Sprachkanäle belegt sind. Kommt ein Gespräch mit lokalen Medienströmen zustande, wird die Bandbreitenreservierung wieder aufgehoben, so dass lokale Gespräche einen neuen Rufaufbau nicht beeinflussen.

Quality of Service (QoS)
Telefoniebezogene Daten werden innerhalb des Telekomnetzes priorisiert übertragen. Damit dies funktioniert und es insbesondere beim Übergang vom LAN ins WAN/Internet nicht zu Verzögerungen kommt, die sich auf die Sprachqualität auswirken, müssen alle am Routing der Pakete beteiligten Komponenten QoS nach RFC2474 beherrschen. Das bedeutet konkret, dass die Endgeräte folgende DSCP Bits setzen müssen:
• für SIP Nachrichten: CS6 / 48
• für RTP Nachrichten: EF / 46
Alle Router im LAN bis hin zum Router, der den Internetverkehr bearbeitet, müssen diese QoS Einstellungen interpretieren und die Paketen gemäß der jeweiligen Klasse priorisieren. Dies gilt sowohl für Pakete, die vom Endgerät zur Plattform geschickt werden, aber auch für Nachrichten, die von der Plattform zurückkommen. Für interne Gespräche sollte QoS auch beachtet werden, wenn die Medienströme lokal innerhalb des LANs bleiben.
Die von der Deutschen Telekom für CPBX vertriebenen Endgeräte (IP Telefone und Router) sind bereits alle für QoS konfiguriert. Bei Nutzung des Desktop-Clients müssen allerdings Besonderheiten beachtet werden, die im Abschnitt „Systemvoraussetungen Desktop-Client für Windows“ beschrieben sind.

Sicherheitsaspekte für Sprachdaten
Bei Nutzung eines Telekom DSL Internetzugangs werden SIP und RTP Pakete in den Grundeinstellungen unverschlüsselt zur Cloud PBX Plattform gesendet. Wahlweise kann man pro Gruppe bzw. Standort im Administrationsportal Verschlüsselung einschalten.
Bei Nutzung eines nicht von der Telekom bereitgestellten Internetzugangs, ist ausschließlich verschlüsselte SIP und RTP Kommunikation möglich.
Das Verbindungskonzept der Cloud PBX sieht im einfachsten Fall direkte Verbindungen von den Endgeräten zur Plattform vor. Darüber hinaus gibt es weitergehende Sicherheitskonzepte wie z.B. Application Layer Gateways, die beim Übergang vom LAN zum Internet eingebracht werden können und eine dynamische Freischaltung der genutzten Ports erlauben. Da diese Geräte aber in der Regel aktiv in die SIP Kommunikation eingreifen, ist eine solche Lösung stark vom genutzten Produkt abhängig und erfordert eine individuelle Beratung.

Neben SIP und RTP sprechen die Cloud PBX Clients noch eine Reihe weiterer Protokolle. Diese sind alle immer verschlüsselt. Auch für diese Protokolle sollte von der Nutzung von Proxy Servern abgesehen werden, da nicht alle eine Kommunikation über einen Proxy erlauben und es zu Einschränkungen des Funktionsumfangs kommen kann.