Während Anwender in der heimischen Stube kaum in VoIP-Hardware investieren müssen, belastet die Internet-Telefonie Unternehmen deutlich mehr. Umso wichtiger ist eine Entscheidungshilfe zur VoIP-Hardware und passgerechten Netzwerk-Ausstattung.

Privatanwender tun sich beim Einstieg in die Internet-Telefonie leichter als Unternehmen. Am heimischen Computer-Arbeitsplatz reicht es, ein Mikrofon und einen Kopfhörer an die Soundkarte zu hängen – schon lässt sich per Softphone telefonieren. Hunderte Arbeitsplätze mit VoIP-Telefonen auszustatten, das erfordert hingegen hohe Investitionen und ein modernes Netzwerk.

Die Kombination Ethernet und IP ist mangels Echtzeitfähigkeit denkbar ungeeignet für Sprachkommunikation. VoIP rückt darum die Switches in den Brennpunkt des Telefongeschehens. Sie müssen per Priorisierung Sprachpakete vorranging behandeln. Für gute Übertragungsqualität sorgt auf Routern eine Ressourcen-Reservierung. Geeignete Pakete kommen aus der Community.

Angenehm: An VoIP-Hardware herrscht kein Mangel. Kleine Gateways verstehen sich auf die VoIP-Protokolle SIP oder H.323 und agieren als Router für Analog- oder ISDN-Telefone. Etwas größere Unternehmen greifen zu IP-TK-Anlagen, die sie an ihre bestehende TK-Infrastruktur anschließen und so sanft auf VoIP-Telefonie umstellen.

Klein-klein

Wer mit einem einzelnen Linux-Rechner die Welt von VoIP betritt, sucht nach einem einfachen und kostengünstigen Weg: Ein Softphone ersetzt das Wählfeld, ein Mikrofon und ein Kopfhörer doubeln den Telefonhörer. Die Beschallung über Boxen funktioniert zwar auch, die zu befürchtenden Echos verleiden solche Gespräche aber schnell. Die Soundkarte muss immer Vollduplex-fähig sein, also gleichzeitig Senden und Empfangen können. Genauso wichtig ist, dass auch der Linux-Treiber des Soundchips Duplex beherrscht.

Um beides festzustellen, reicht ein Testsetup mit zwei Rechnern, die über einen Hub oder ein Cross-over-Kabel miteinander verbunden sind. Alternativ ist es möglich, über Internet den Rechner eines Freundes oder einer Freundin als Peer heranziehen. Der Test im Peer-to-Peer-Modus ist sowohl mit H.323- als auch SIP-Clients möglich. Um Softwareprobleme und Codec-Inkompatibilitäten auszuschließen, sollten beiden Seiten den gleichen Client benutzen.

Headset – die einfache Alternative

So genannte Headsets kombinieren digitalen Soundchip, Mikrofon und Kopfhörer zu einem Gerät. Eine separate Soundkarte wird somit überflüssig. Doch kosten solche Headsets ab 100 Euro aufwärts. Das ist zum Ausprobieren ein bisschen viel Geld, besonders angesichts der Unsicherheit, ob die Dinger auch mit Linux funktionieren.

Zwei Varianten befinden sich auf dem Markt: Die eine nutzt USB für den Anschluss am Rechner, die andere verbindet sich kabellos per Bluetooth. In den einschlägigen Linux-Foren berichten USB-Headset-Besitzer von massiven Problemen. Die Bluetooth-Fraktion scheint zufrieden zu sein, obwohl auch sie teilweise mit USB-Dongles arbeitet.

Mit dem Blue-Z-Bluetooth-Stack[1] existiert eine Bluetooth-Implementierung, die zusammen mit einem Treiber des Alsa-Audiosystems solche Headsets ansteuert. Aktuell ist eine Version für Kernel 2.6.4 sowie Alsa 1.0.3[2]. Leider hat der Programmierer angekündigt, dass dies die letzte Version ist und er die Arbeit daran einstellt. Glücklicherweise ist jedoch das Blue-Z-Projekt sehr aktiv. Über die Mailingliste lassen sich Tipps einholen, um auch künftig ein Headset zur Mitarbeit zu überreden. Zudem führt von der Blue-Z-Website ein Link zur Liste unterstützter Bluetooth-Hardware[3], die genau aufführt, welche Bluetooth-Karten und -Dongles mit welcher Blue-Z-Version funktionieren.

Wer sich ein kabelgebundenes USB- Headset zulegen möchte, sollte sich zuerst unter[4] informieren. Die dort gebotene Liste ist zwar kurz, hilft aber Fehleinkäufe vermeiden. Einwandfrei zu funktionieren scheint das Logitech Premium Stereo USB Headset 30 (Abbildung 1). Für solche USB-Audiogeräte gibt es mit dem Kernelmodul »snd-usb-audio« einen Treiber aus dem Alsa-Projekt. Beim Open-Sound-System OSS heißt das Modul schlicht »audio«.

Abbildung 1: Logitechs USB-Headset funktioniert nach Anwenderberichten problemlos auf Linux.

Hardphones am PC

Wer lieber sein altes Analog- oder ISDN-Telefon zur VoIP-Kommunikation in Händen hält, muss es an eine spezielle Hardware anschließen, die wiederum per USB an den PC gehört. Solche Adapter rechnen die digitalen Audiosignale wie eine Soundkarte um und reichen sie an das normale Telefon durch.

Als Platzhirsch bei der H.323-Adaptern auf Linux tritt Quicknet auf, der mit der Linux-Jack-Serie[5] Gnomemeeting-Anwendern ein ganzes Portfolio anbietet. Seine Audiokarten integrieren gleich mehrere Codecs und lassen den Anschluss von analogen Telefonen oder Faxgeräten zu. Zusammen mit einem Account bei einem VoIP-Provider ist dann auch ein eigenes Gateway möglich, um Endgeräte im öffentlichen Telefonnetz zu erreichen.

Wer das Routing ins Festnetz lieber selbst erledigt, macht aus einem ausgemusterten PC ein VoIP-Gateway. Es weiß, welche Gespräche über VoIP laufen sollen und welche es über eine ISDN-Karte ins Festnetz vermitteln muss. Die PBX-Software Asterisk (siehe Artikel “Ein Stern am Telefonhimmel”) kommt mit fast allen ISDN-Karten zurecht, die der ISDN-Stack ISDN4Linux[6] unterstützt.

Andere VoIP-Gateways wie PBX4Linux benötigen zwei ISDN-Karten. Die eine arbeitet als Gegenstelle für die ISDN- Telefone im NT-Modus (Network Termination). Dazu muss sie mit dem HFC-S-Chipsatz ausgestattet sein. Als Treiber dient der neue ISDN-Stack für Kernel 2.6 M-ISDN[7]. Näheres dazu liefert die PBX4Linux-Website auf[8].

Gateways und PC-Telefonanlagen

Nicht jeder will für ein paar Anrufe im Monat ein eigenes VoIP-Gateway hochziehen. Stattdessen kann er zu Appliances greifen, die mehrere Anbieter auch für kleine Büroumgebungen oder Heimnetzwerke auf den Mark bringen. Größere Unternehmen haben die Qual der Wahl, denn um sie buhlen neben Cisco, Siemens & Co. auch viele kleinere IT-Dienstleister.

Für Heimanwender ohne Telefonanlage liefert AVM mit der Fritz! Box Fon eine Lösung, die sowohl den Einsatz von SIP-Softphones erlaubt als auch den Anschluss von Analog- oder ISDN-Telefonen (Abbildung 2,[9]). Die Box enthält zwei RJ-11-Schnittstellen, um die Telefone anzuschließen. Intern wandelt das Gateway die Signale in IP-Pakete um und schickt sie zum Provider. Dessen Gateway wiederum entscheidet, ob es den Anruf an eine SIP-Gegenstelle oder an ein Festnetz- oder Mobilfunktelefon vermitteln muss.

Abbildung 2: AVM hat mit der Fritz! Box Fon ein neues VoIP-Gateway inklusive einer Telefonanlage für kleine Büros oder Privatanwender im Programm.

Sollen im Unternehmen die Mitarbeiter intern per VoIP telefonieren und soll die TK-Anlage externe Anrufe weiterhin direkt ins Festnetz vermitteln, kommen VoIP-Gateways wie die MBOX/voice von Communiports zum Einsatz (siehe Abbildung 3,[10]. Das Gerät unterstützt H.323 für die Internet-Telefonie und bis zu acht S0-Schnittstellen für den Anschluss an die TK-Anlage.

Abbildung 3: MBOX/voice von Communiport eignet sich zum Anschluss an eine TK-Anlage und unterstützt als VoIP-Gateway den H.323-Standard.

Ebenso lassen sich G3-Faxgeräte nach T.30 betreiben und ISDN-Leistungsmerkmale wie die Caller-ID weiter nutzen. Ein Web-basiertes Interface verwaltet das Ganze. Der Hersteller hat auch mehrere VoIP-Karten für die S2M-Schnittstelle (ISDN-PRI) inklusive Linux-Treiber im Programm, die auch gleich die Kodierung übernehmen.

Für Asterisk als Software-PBX in einer VoIP-Appliance hat sich der österreichische Anbieter SIN entschieden[11]. Das System basiert auf einer Suse-Distribution und lässt sich für den Anschluss an eine TK-Anlage wahlweise mit einer BRI-Karte mit einem S0-Interface oder einem PRI-Adapter mit einer S2M-Schnittstelle für 30 B-Kanäle ausstatten. Die SIN-Appliance nutzt die Asterisk-Funktionen inklusive Voice-Mailbox und Warteschlangen gut aus. Zudem kann sie als GSM-Gateway dienen, das Anrufe ins Mobilfunknetz leitet.

Für große Unternehmen hat Siemens eine neue IP-TK-Anlage konzipiert und schwenkt zeitgleich von einem proprietären Unix auf Linux um. Laut Hersteller verkraftet die Hi-Path 8000 IP PBX bis zu 100000 SIP-fähige IP-Telefone[12]. Zwar hat Siemens das Protokoll erweitert, um eigene Telefonfunktionen zu implementieren. Die Anlage soll aber trotzdem kompatibel zu allen gängigen SIP-Telefonen sein und somit helfen, verteilte VoIP-Installationen im Rechenzentrum zu konsolidieren.

Power-over-Ethernet-Switches

Es lassen sich zwei Arten von VoIP-Hardphones unterscheiden: Die eine verleiht dem Anwender viel Bewegungsspielraum und verbinden das Handgerät per WLAN mit der Basisstation. Die andere hängt direkt am Netzwerkkabel, aus dem das Gerät auch gleich seinen Speisestrom zapft. Dieses Verfahren heißt Power-over-Ethernet (PoE), ist seit 2003 als IEEE 802.11af standardisiert und findet bei zunehmender Akzeptanz der VoIP-Telefonie auch in kleineren Consumer-Switches Anwendung.

PoE ist eine praktische Sache – falls die Infrastruktur aus Kupferkabeln besteht. Dann werden neben den Telefonen lediglich neue Switches fällig, die zu den Daten auch den Strom für die Endgeräte verteilen. Liegen aber Glasfaserkabel bis zum Schreibtisch (Fiber-to-the-Desk), ist es mit diese günstige Variante der Stromversorgung vorbei. Dann müssen entweder teure Hybridkabel verlegt werden oder jedes Telefon bekommt ein Kabelsalat-trächtiges Steckernetzteil.

Steht ein Upgrade der Infrastruktur an, sollten die IT-Verantwortlichen also prüfen, ob nicht Kupferkabel der neuesten Generation vorteilhafter wären als Lichtwellenleiter. Für Gigabit-Ethernet auf Kupfer stehen Kategorie 6 und Kategorie 7 zur Wahl. Während Kategorie 6 mit 250 MHz Bandbreite nur wenig Luft nach oben lässt, öffnet das 600-MHz-Kabel nach Kategorie 7 den Weg in die Zukunft. Mit Kategorie 8, die 1200 MHz Bandbreite erlaubt und sich für den Transport digitaler Videodaten eignet, steht ein Kandidat vor der Tür, der allerdings noch nicht standardisiert ist.

Netzwerk-Anforderungen von VoIP

VoIP in mittleren und großen Unternehmen bereitet einige Probleme: Anders als in kleinen Netzen müssen die Planer die verfügbare Bandbreite und die Priorisierung des Traffic berücksichtigen. Die Basis sollte mindestens ein geswitchtes 100-MBit/s-Ethernet sein, da bereits ein einziges Telefongespräch bis zu 160 KBit/s Bandbreite verlangt, 80 KBit/s pro Richtung.

Für eine Echtzeitanwendung wie die Telefonie muss die Übertragungsstrecke eine bestimmte Qualität haben. Einen echten Quality-of-Service (QoS) weisen jedoch nur ATM-Netze auf, die bereits beim Verbindungsaufbau alle Übertragungsstrecken-Charakteristika wie etwa Bandbreite und Verzögerung prüfen. Dabei wird jedes Gerät zwischen beiden Übertragungspunkten nach seiner Kapazität befragt. Vermag ein Gerät die geforderten Ressourcen nicht bereitzustellen, kommt die Verbindung nicht zustande.

CoS sorgt für Qualität

Die meisten LANs arbeiten nicht mit ATM, sondern mit Ethernet, das kein Quality-of-Service kennt. Es benutzt eine Best-Effort-Strategie, bei der die Daten einfach so gut wie möglich weitergeleitet werden. Um die Daten trotz Ethernet und aufgesetztem IP in Echtzeit zu übertragen, reserviert man Ressourcen und behandelt Pakete durch Priorisierung bevorzugt (siehe Kasten “Priorisierung im Ethernet”). Diese Verfahren sind unter dem Schlagwort Class-of-Service (CoS) zusammengefasst und auf den Layern 2 oder 3 implementiert. Zu beachten ist, dass alle beteiligten Komponenten mit den Serviceklassen zurechtkommen müssen.

Reservierung von Netzwerkkapazitäten

Eine bestimmte Güteklasse lässt sich mit Verfahren erreichen, die Kapazitäten im Netz ermitteln und reservieren: Das Multiprotokoll Label Switching (MPLS) ist ausschließlich auf Routern implementiert, arbeitet auf Layer 2 und ist darum unabhängig von Protokollen höherer Ebenen, etwa IP oder PPP. An MPLS-Unterstützung für Linux wird aktiv gearbeitet. Das Projekt ist jedoch immer noch im Betastadium[13].

Das MPLS-Verfahren baut einen Tunnel mit fester Bandbreite (Pipe) zwischen zwei Routern. Gelangt ein IP-Paket an den Eingang eines Tunnels (Label Switch Router, LSR), ermittelt dieser Router anhand der Zieladresse im Paket-Header zuerst, welcher Router als Nächster anzusteuern ist. Dann untersucht er, welcher Tunnel dorthin die notwendigen Übertragungseigenschaften besitzt, und verpasst dem Paket ein 20 Bit großes Label. Von nun an reist das Paket auf dem zum Label passenden Pfad (Label Switched Path, LSP). Alle anderen Pakete, die ebenfalls diesen Pfad nutzen, gehören zur selben Service-Klasse (Forwarding Equivalence Class, FEC), wodurch der Router sie mit der gleichen Priorität behandelt.

Das Resource Reservation Protocol (RSVP) ist ein alternatives Verfahren der Qualitätssicherung in großen lokalen IP-Netzwerken, das eine Route aufbaut und kontrolliert. Für Linux gibt es mehrere Implementierungen, unter anderem die Kom RSVP Engine der TU Darmstadt[14]. Mit RSVP kann ein Host die Parameter für eine Übertragung vorher anfordern. Zuerst sendet er eine Path-Nachricht an alle zwischen den beiden Endpunkten liegenden Gateways, um die Route zu etablieren.

Anschließend handeln alle beteiligten Zwischenstationen die Parameter für die Verbindung per Reservation-Request-Nachricht aus und einigen sich darauf, wie sie die erwarteten Pakete erkennen und filtern. Nach dem Ende der Übertragung schließen sich die Pfade und die Gateways geben die reservierten Ressourcen wieder frei. RSVP treibt großen Aufwand bei der Verwaltung der Protokolle, was schnell zu Skalierungsproblemen führt. Daher ist sein Einsatz auf Campus-Netzwerke beschränkt.

Mit VoIP in die Zukunft

Einige Beobachter der VoIP-Szene glauben mittlerweile, der entscheidende Schub für die Akzeptanz von Voice-over- IP würde bald von den Privatkunden ausgehen. Denn sie müssen nur wenig in Hardware investieren, um per VoIP weltweit zu telefonieren.

Unternehmen als eigentliche Zielgruppe der IP-Telefonie zögern hingegen. Sie versuchen mehrheitlich, sanft zu migrieren, und führen VoIP als Kombination aus IP-TK-Gateways und herkömmlichen TK-Anlagen ein. Das ist verständlich angesichts der enormen Anforderungen, die eine Echtzeitanwendung wie VoIP an Unternehmensnetze stellt. Dabei müssen die Ethernets zu einer Class-of-Service-Infrastruktur aufgebohrt werden, was manches IT-Budget in Zeiten knapper Kassen überfordert.