![[VoIP im Netz der ADS System AG]](68-1.gif)
Abbildung 1: Die ADS Systems AG nutzt VoIP unternehmensweit mit Technik verschiedener Hersteller.
Funktioniert Voice over IP? "Im Prinzip ja, ...", würde Radio Eriwan melden. Die prinzipiellen Vorteile von Voice over IP (VoIP) gegenüber der klassischen Telefonie zeigen sich deutlich bei der Verwendung von Datenleitungen, die Firmenstandorte verbinden. Leider sind die optimalen Vorraussetzungen für VoIP meist nur im Testlabor gegeben; auf dem freien Markt findet man sie kaum. Standleitungen sind meist zu "dünn", denn unterhalb von 128 KBit denkt man besser nicht an VoIP.
Noch unangenehmer wird es, wenn eine Standleitung auf Frame-Relay (FR) basiert. Diese Technik ist denkbar ungeeignet für VoIP, denn sie ist nicht darauf ausgelegt viele kleine Pakete möglichst zuverlässig ans Ziel zu bringen, sondern eher darauf, große Datenpakete ins Netz zu pumpen und in Engpassituationen gegebenenfalls zu verwerfen. Daher wurde in die unteren FR-Schichten ein "Häcksler" eingebaut, der große Pakete zerkleinert, um Sprachdaten dazwischenschieben zu können. Herstellerübergreifend arbeiten die Verfahren (FRF.11/FRF.12) zwar akzeptabel, reichen aber alleine bei weitem nicht aus, um eine vernünftige Sprachübertragung zu gewährleisten.
Ohne eine ausgeklügelte Queueing-Technik kann man auf schmalen Leitungen nicht viel erreichen. Router-Marktführer Cisco hat mittlerweile eine sehr ansehnliche Version des Low Latency Queueing (LLQ) als Kombination von Class Based Weighted Fair Queueing (CBWFQ) und Priority Queueing (PQ) implementiert, allerdings erst in den brandneuen Releases. Die technischen Vorrausetzungen der Router-Hardware, die solch ein Release benötigt, bedeuten eine nicht zu vernachlässigende Investition für Austausch oder Aufrüstung dieser Geräte.
Ist die Netzinfrastruktur erst einmal "Voice-Ready" steht "dem Telefonieren" auch schon fast nichts mehr im Weg, das heißt: abheben – anrufen – sprechen. Nicht mehr und nicht weniger. Das muss auch reichen, so die klare Aussage des Marktführers aus San FranCISCO:
"It's not about price,
it's not about features,
it's not about reliability,
it's not about safety,
it is about changing fundamental business processes..."
Ganz so schwarz-weiß sollte man es zwar nicht sehen. Die Funktionsvielfalt einer TK-Anlage ist jedoch in einer VoIP-Umgebung derzeit nicht wiederzufinden. Momentan geht noch einiges an Komfort verloren, denn die Kopplung findet, sofern sich Router und TK-Anlage verstehen, über Q.SIG oder Euro-ISDN statt.
Q.SIG ist der größte gemeinsame Nenner, den alle Hersteller unterstützen, um TK-Anlagen zu koppeln. Es enthält mehr Funktionen als das Standard-ISDN. Dennoch ist die Funktionsvielfalt in der Praxis aber bisher auf ein "lebensnotwendiges" Minimum eingeschränkt. Prinzipiell geht es aber – wichtig für die Techniker. Und es spart Kosten – wichtig für den Chef.
Sprache über das Internet zu übertragen ist für Spielefreaks nichts Neues. Immer mehr Gameserver im Internet bieten die Möglichkeit der parallelen Sprachkommunikation beim Spielen an. Natürlich geht das nicht immer und überall mit hevorragender Sprachqualität ...
Die Anforderungen an die Qualität einer Sprachverbindung haben sich allerdings durch die Verbreitung von Handys ohnehin verändert. Die Akzeptanz einer schlechteren Verbindung ist heute viel höher als vor drei Jahren. Die Mobilität durch Handys ist den Menschen wichtiger geworden als ein rauschfreies Gespräch.
Unter Berücksichtigung dieses Trends und der positiven Entwicklung der Bandbreiten- und Verfügbarkeitsgarantien im Internet ist eine Kopplung von Sprachübertragungen im Internet keine Zukunftsmusik mehr – die ADS System AG praktiziert das bereits seit einem Jahr unternehmensweit. Zusätzlich hat sie es sich zur Aufgabe gemacht, verschiedene Hersteller und Topologien miteinander zu vereinigen (vgl. Abb. 1).
Abbildung 1: Die ADS Systems AG nutzt VoIP unternehmensweit
mit Technik verschiedener Hersteller.
Um Sprache vernünftig zu übertragen, bedarf es nicht viel, weder allzu großer Bandbreite noch prozessorstarken Routern. Das Einzige, was zählt, ist die Verzögerungszeit, denn "zu spät ist so gut wie gar nicht übertragen". Das menschliche Ohr reagiert sehr sensitiv auf Verzögerungen, Echos und fehlerhafte Signalverläufe (vgl. S. 64). Berücksichtigt man neben der Laufzeit auf der Netzwerkverbindung auch die Verzögerung durch Signalverarbeitung, Kompression und Queueing, so erhält man als Kenngröße für die maximale Verzögerungszeit auf dem Übertragungsmedium rund 60 ms – genau das bieten mittlerweise einige Internetprovider an.
Um dieser guten Nachricht aber gleich einen kleinen Dämpfer zu verpassen: Selbst wenn man eine Filiale an einem Internet Service Provider mit Quality-of-Service-Merkmalen (QoS) betreibt, so gilt dessen Garantie erst, wenn die Sprach- oder Datenpakete in seinem Netz angekommen sind. Bei einer 64-KBit-Standleitung kann das schon recht lange dauern.
Ein kleines Rechenbeispiel: In der Leitung zum Provider steckt in der Warteschlange ein Paket mit 1500 Bytes, dahinter das Sprachpaket. Bei 64 KBit/s braucht allein das 1500 Byte große Paket schon (1500 Byte × 8 ÷ 64 000) = 187 ms. Dazu kommt noch die Verzögerungszeit im Internet und dann wieder 1500 Bytes, die in der Interfacequeue des Filialrouters stecken. Man muss daher mit seiner Anbindung an das Internet auch Sorge tragen, seine Daten schnell "loszuwerden". Unproblematisch ist das meist erst bei einer 2-MBit-Standleitung.
Zur tatsächlichen Umsetzung von VoIP braucht man ein VoIP-Gateway. Dies stellt im besten Fall der Router dar, der auch den Internetanschluss realisiert. Diese Maschine koppelt man über ein spezielles Interface an 1–2 ISDN-Anschlüsse der TK-Anlage. Diese übermittelt dem Router über das D-Kanal-Protokoll die gewählte Rufnummer. Und dort bildet dann ein Rufnummernplan Telefonnummern auf IP-Adressen ab. Der Router baut zu seinem Gegenüber eine IP-Verbindung auf und signalisiert ihm über das H.323-Protokoll, dass er eine Voice-over-IP-Connection initiieren möchte. Das Ganze läuft über TCP. Ist die Sprachverbindung hergestellt, fließen nur noch UDP-Pakete mit den digitalisierten Sprachsignalen über das Netz.
Am besten setzt man noch die IP-Precedence-Bits in den UDP-Paketen auf 5, denn ein Großteil der ISP filtert diese nicht am Zugangspunkt heraus, setzt sie also nicht auf Null zurück. Manche Router im Internet behandeln Pakete mit gesetztem IP-Precedence bevorzugt, was für Sprachpakete nur von Vorteil sein kann. Aber immer daran denken: Zuviel priorisierter Traffic bedeutet "keine Priorisierung".
Eine solche Kommunikation zwischen den beiden offiziellen IP-Adressen der Router findet standardmäßig unverschlüsselt statt – dafür aber schnell. Das stellt jedoch ein Sicherheitsrisiko dar, denn der UDP-Datenstrom mit den Sprachpaketen ist abhörbar und auch ein ungewolltes Bedienen der VoIP-Gateway-Funktionen wäre möglich.
Eine gängige Methode, um Angriffe aus dem Internet zu erschweren, sind Network Address Translation (NAT) und Port Address Translation (PAT). Reine NAT ist eine statische Eins-zu-Eins-Umsetzung von internen zu externen IP-Adressen und bietet damit keinen wirklichen Schutz. PAT versteckt hinter einer offiziellen Adresse mehrere interne. Die Verbindung kann dann nur von innen nach außen aufgebaut werden, und das ist auch gut so – nur nicht bei VoIP.
Im Verbindungsaufbau H.323 (TCP #1720) werden die UDP-Ports ausgehandelt, über die nachfolgende Sprachpakete laufen. Diese liegen oberhalb von 16384, werden aber von außen nach innen aufgebaut. Bei PAT gibt es für diesen Datenstrom keine Einträge und die Firewall verwirft die Pakete. Für den Anwender sieht das so aus: Es klingelt, er hebt ab und sein Partner bekommt einen Connect, aber beide hören nichts.
Die ADS System AG verwendet zudem auch spezielle IP-Phones, die praktischerweise unabhängig von der IP-Adresse immer ihre Telefonnummer beibehalten. Die Zuordnung der IP-Adressen in einem IP-Telefonie-LAN erfolgt über DHCP. Dynamische IP-Zuweisung und statisches NAT schließen sich jedoch gegenseitig aus.
Ein Ausweg ist, mit den IP-Phones über einen Media-Termination-Point (MTP) zu kommunizieren: Alle Anrufe außerhalb der eigenen Region gehen dann an den MTP, der die UDP-Pakete repliziert, aber seine IP-Adresse als Absender einsetzt. Den Zugriff von außen auf den MTP sollte man natürlich durch Access-Listen sperren und nur den TCP-Port 1720 freischalten. Allerdings müssen alle UDP-Ports oberhalb von 16384 offen sein.
Es gibt nur wenige Geräte, die in der Lage sind, den
H.323-Strom zu dekodieren, NAT auch in höheren Layern
durchzuführen und dynamisch UDP-Ports zu öffnen. Die
Cisco PIX Firewall ist dazu in der Lage, Cisco Router – ob
mit oder ohne Firewall-Features – jedoch nicht. Die generelle
Aussage des SANS-Institute ist sogar, dass so etwas gar nicht
unterstützt wird (![[externer Link]](../../../../images/link.gif)
www.sans.org).
Um ein Minimum an Sicherheit zu erlangen, kann man den Verbindungsaufbau zwischen zwei VoIP-Gateways per Generic Routing Encapsulation (GRE, RFC 1701f) verschleiern. Damit vermeidet man immerhin ungewollte Zugriffe auf die VoIP-Gateways. Die Sprachdaten sind zwar abhörbar, laufen aber mit optimaler Verzögerungszeit durch das Netz. Ein generelles GRE-Tunneln ist jedoch nicht zu empfehlen, da dies lange nicht an die Sicherheit eines IPSEC-Tunnels herankommt, aber zusätzliche Verzögerungen bewirkt.
Um ein Maximum an Sicherheit zu erreichen, sollten alle VoIP-Komponenten innerhalb des firmeninternen LAN stehen. Zwischen verschiedenen Standorten benötigt man ein vollvermaschtes VPN. Alle Daten werden dann verschlüsselt über das VPN geschickt und auf der anderen Seite wieder ausgepackt. Mit dem Erfolg der maximalen Sicherheit, aber auch einer großen Verzögerungszeit – meistens mit inakzeptabeln Ergebnissen.
Den meisten kraftvollen IP-Goliaths an der Front zum ISP geht nämlich beim Einsatz von Verschlüsselungsmechanismen ganz schnell die Puste aus und sie werden zu kleinen Davids, da die Verfahren fast immer in Software ablaufen. Der Einsatz einer Verschlüsselungshardware unterbleibt zumeist, denn die Konstellation ISP-Router – Crypto-Box – VoIP-Gateway – PC-Netz bedeutet immensen Hardwareaufwand und entsprechende Kosten, die VoIP-Vorteile normalerweise neutralisieren. Weiterhin setzt das voraus, dass ein vollvermaschtes VPN vorliegt. Ist das nicht der Fall, muss die Sprachkommunikation über die Zentrale aufgebaut werden, was die Verzögerungszeiten verdoppelt.
An einem Kundenbeispiel der ADS System AG wird deutlich, wie einfach eine Lösung aussehen kann und wie vertrackt sie dennoch ist. Ein Call-Center soll über das Internet verteilt arbeiten. Der Benutzer wird anhand seines Telefons erkannt, unabhängig von seinem Standort und seiner IP-Adresse. Er kann sich direkt über VPN an dem Call-Center-Server anmelden und an den Sessions teilnehmen. Klingt genial einfach, funktioniert aber nur mit Klimmzügen.
![[Netzplan: Call-Center-VPN]](68-2.gif)
Abbildung 2: Call-Center-VPN mit Voice over IP
Die Tücken, die hinter dieser Installation stecken, sind kaum vorstellbar – ein paar Anhaltspunkte: Es gibt kein PPPoE auf IP-Telefonen, daher muss man immer einen IPSEC-Router zusätzlich verwenden. Es existiert kein VPN zwischen den Remote-Sites, also können sie nicht miteinander telefonieren, da sie alle Mitglied einer Region sind. Die Anzahl der Regionen ist limitiert und es ist auch nicht vorgesehen, jedes IP-Phone in eine eigene Region zu legen. Der Call-Manager müsste dann auch jedes Paket replizieren, wofür die Windows-2000-Maschine nicht ausgelegt ist, ... Ansonsten arbeitet das System jedoch nach anfänglichen Schwierigkeiten stabil und funktionell mit dem Vorteil, sein Telefon nun auch über den Webbrowser bedienen zu können.
Voice-over-IP steckt derzeit noch in den Anfängen, mit einigen Krankheiten, aber einsetzbar. VoIP per Internet ist eine Herausforderung, die Netzwerkspezialisten viel Können abfordert, um es zu ermöglichen. Dass das Internet so schnell wird, um selbst mit VPN-Verschlüsselung immer noch akzeptable Verzögerungszeiten für Sprachübertragung zu erzielen, dürfte zudem eine Vision bleiben. Heutzutage muss man jedenfalls auf Sicherheit verzichten, um überhaupt eine vernünftige Sprachqualität zu erreichen. Auch der Verlust von TK-Funktionen ist ein gerne verschwiegenes Manko oder teilweise ein als nebensächlich deklariertes Fehlen: "Wer benötigt schon Rückruf bei besetzt?"
Jens Cremer ist Leiter Support der ADS System AG
( www.ads.de).
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2001, Seite 68
