Das Telefonieren per Datenpaket ist, zumindest rein technisch gesehen, zu einer Selbstverständlichkeit geworden. Auf dem Markt sind inzwischen Systeme für alle Unternehmensgrößen zu finden: von der Drei-Platz-Lösung, die ohne zentralen Server auskommt, bis zur Enterprise-Lösung für multinationale Konzerne.

Wie auch immer die Implementation aussieht, fest steht: wer sich ausschließlich auf VoIP für die Sprachkommunikation verlässt, muss dafür Sorge tragen, dass der Dienst eine mindestens ebenso hohe Verfügbarkeit hat, wie herkömmliche Telefonie. Dass die Infrastruktur, also Switche und Router, redundant ausgelegt sind, versteht sich in so einem Fall von selbst. Auch der Server mit der eigentlichen IP-Telefonanlage wird meist durch entsprechende Maßnahmen gesichert. An eine weitere Grundvoraussetzung für reibungsloses VoIP denken allerdings die wenigsten - den DHCP- und DNS-Dienst.

VoIP-Telefone sind wie jedes IP-basierte Gerät auf eine IP-Adresse angewiesen, um überhaupt mit dem Netzwerk kommunizieren zu können. In der Regel erledigen das einer oder mehrere DHCP-Server in den Netzwerksegmenten. DHCP erlaubt das zentrale Verteilen und Verwalten von IP-Adressen im Netzwerk sowie zu einem großen Teil auch die Konfiguration von Hosts durch das Verschicken von Optionslisten und Config-Dateien.

VoIP-Telefone benötigen komplexere Konfigurationen als ein PC, der in der Regel mit IP-Adresse, Netzmaske und Gateway auskommt. So werden Daten wie der nächste SIP-Proxy und der zuständige TFTP-Server per DHCP verteilt, Informationen, ohne die viele VoIP-Geräte nicht funktionsfähig sind. Ohne DHCP müssten alle Infos "fest" also, manuell vorgegeben werden, eine Aufgabe, die in größeren Netzwerken unmöglich und schon in kleineren Netzen bei jeder Änderung extrem aufwändig ist.

DHCP kurz erklärt

Jedes netzwerkfähige Gerät mit einem DHCP-Client kann Anfragen an einen DHCP-Server senden. Welche Daten zurück geliefert werden, bestimmen Client und Server gleichermaßen. Am Server müssen die Parameter konfiguriert sein, der Client einen entsprechenden Eintrag in seiner Konfiguration benötigen. Der Ablauf ist in der RFC 2131 festgelegt und standardisiert. Er beinhaltet mehrere Schritte, die über das Netzwerkprotokoll UDP abgewickelt werden.

Der Client schickt zuerst eine Discover-Nachricht aus, um den nächsten verfügbaren DHCP-Server im lokalen Netzwerksegment zu finden. DHCP-Broadcasts werden von Routern nicht weitergeleitet, es sei denn man verwendet einen DHCP-Relay-Agent. Der kennt andere DHCP-Server und schickt Anfragen weiter, wenn er glaubt, dass sie in einem anderen Segment besser aufgehoben sind. Im Discover-Paket enthalten ist die MAC-Adresse des Clients, die ihn gegenüber dem DHCP-Server eindeutig identifiziert.

Gibt es mehr als einen DHCP-Server, können mehrere Antworten auf die Discover-Nachricht zurückkommen. Deren Inhalt kann der Server vom anfragenden Netzwerkgerät abhängig machen, zum Beispiel von dessen Hersteller oder von gerätespezifischen Infos.

Das VoIP-Gerät akzeptiert entweder die erste gültige Antwort auf seine Discover-Nachricht oder wählt in Abhängigkeit des Inhalts aus, zum Beispiel weil die Lease-Time für die IP-Adresse bei dieser Nachricht am längsten ist, der Client beim Server also weniger häufig um eine Verlängerung der Lease-Zeit bitten muss. Hat sich der Client für eine Discover-Antwort entschieden, fordert er beim Server die gewählte IP-Adresse, weitere Daten sowie die erste Verlängerung der Lease-Zeit an.

Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob er als einziger im Netz diese Adresse beansprucht. Ein Administrator könnte versehentlich die gleiche IP-Adresse manuell zugewiesen und vergessen haben. In der Regel schickt der Client dazu einen ARP-Request mit der neu zugeteilten IP-Adresse aus und "horcht" ob es eine Antwort mit der gleichen IP- aber einer anderen MAC-Adresse gibt.

DHCP-Optionen

Weitere Parameter werden durch so genannte DHCP-Options zugewiesen. Das ist besonders für VoIP-Geräte interessant, da diese oft eine erheblich komplexere Konfiguration vom DHCP-Server erwarten, als ein Arbeitsrechner. Sie müssen auch Informationen wie die Adresse des SIP-Proxies wissen, über den der Rufaufbau läuft, oder sie benötigen einen gültigen TFTP-Server, von dem sie beim Start eine Konfig-Datei oder ihr komplettes Boot-Image ziehen können.

Class "bluecat-voip-device" {Match if option vendor-class-identifier = "bluecat.voip.device";#Teilnehmer fordert die Werte bestimmter Konfigurationsparameter an#1 = Angabe der Subnetzmaske des Teilnehmers#3 = Angabe einer Liste der IP-Adressen der Router im Subnetz#28 = Angabe der Übertragungsadresse des Subnetzes#43 = Angabe der herstellerspezifischen Informationen#54 = Angabe des DHCP-Server-Identifiers für DHCPOFFER/DHCPREQUEST#60 = Angabe des Klassen-Identifiers des Herstellers#67 = Angabe des Namens der Bootdatei#120 = Angabe des SIP-Servers#150 = Angabe der TFTP-Serveradresseoption dhcp-parameter-request-list 1, 3, 28, 43, 54, 58, 59, 60, 67, 120, 150;option vendor-encapsulated-options "bluecat.voip.device.opt";option bootfile-name "BLUECAT.BOOT";option option-120 172.18.210.3;option option-150 172.18.210.3;}

Um so wichtiger also, dass der DHCP-Server stabil und allzeit verfügbar bereit steht. Leider sind ausgewachsene Redundanzfunktionen kein Bestandteil der häufig genutzten Netzwerkbetriebssysteme. Es gibt zwar Workarounds wie die Adressen in anschließende Bereiche aufzuteilen und sie von jeweils einem DHCP-Server versorgen zu lassen. Doch man vergeudet dabei die Hälfte der nutzbaren Adressen und wenn man Reservierungen benötigt, also manuell fest mit einer MAC-Adresse gekoppelten IP, ist die Methode ebenfalls nicht geeignet. Bei Microsoft Betriebssystemen ist in der Regel ein Cluster die einzige sichere Lösung für redundantes DHCP.

DNS, VoIP und ENUM

Der Umgang mit Telefonnummern und Domänennamen ist ein weiterer Stolperstein auf dem Weg zur reibungslosen VoIP-Implementation. Geht es nur um Computer ist die Sache klar: ein DNS-Server setzt normal-verständliche Domänennamen wie www.beispiel.de in eine IP-Adresse um. DNS ist in fast allen Firmen, mit Ausnahmen von sehr kleinen Netzen, Grundvoraussetzung für den Datenaustausch.

Und selbst wenn es sich nicht lohnt, einen eigenen DNS-Server zu betreiben: sobald es einen Router für den Internetzugang gibt, ist auch DNS im Spiel. Der Router agiert entweder selbst als DNS-Server oder leitet Anfragen an den DNS-Server des Internet-Service-Providers weiter.

Im Fall von VoIP kommt eine weitere Komponente ins Spiel. Nicht Domänennamen sondern Telefonnummern sollen in eine IP-Adresse und einen passenden Dienst übersetzt werden. Durch eine Technologie namens ENUM kann sich nämlich hinter einer international standardisierten Telefonnummer (E.164) auch ein anderer Dienst verbergen: ein analoges Telefon, ein Handy, eine Mail-Adresse oder sogar eine Webseite.

Die Entscheidung darüber, wo ein Anruf im Endeffekt ankommt, hängt von Parametern ab, die im dazugehörigen DNS-Eintrag in Form von "Naming Authority Pointer Records" (NAPTR) hinterlegt sind. Damit lassen sich Dienste definieren, zuordnen und priorisieren. Die Applikation, von der die Kontaktanfrage, zum Beispiel ein Anruf, ausgeht, sucht sich unter der angegebenen ENUM-Nummer die richtige Zieladresse und den passenden Dienst.

ENUM, im RFC 3761 definiert, führt das Telefonnetz mit dem IP basierten Internet zusammen. Weil es sich, im Gegensatz zu den Telefonnummern, die der ITU unterstehen, um eine Internet-Ressource handelt, ist eine Top-Level Domain dafür vorgesehen: e164. ENUM-Mappings sind letztendlich nichts anderes als DNS-Einträge, auch wenn das Format gewöhnungsbedürftig ist. Die Umsetzung einer Telefonnummer in die korrespondierende ENUM-Domain läuft nach einem einfachen Muster ab:

+49 1 2345 6789 - Zunächst wird die vollständige E.164-konforme Telefonnummer festgestellt

49123456789 - Nun werden alle nicht-numerischen Zeichen entfernt

4.9.1.2.3.4.5.6.7.8.9 - Zwischen die Ziffern kommen Punkte

9.8.7.6.5.4.3.2.1.9.4 - Die Reihenfolge wird umgekehrt

Diensteauswahl

Der Vorgang läuft in den meisten ENUM-fähigen Clients automatisch ab, der Benutzer gibt nur die gewünschte Telefonnummer ein. Das Ergebnis ist ein vollständiger Domainname ("Fully Qualified Domain Name" = FQDN) der wie jeder andere Domainname verwendet werden kann. Die Unterscheidung, welcher Dienst unter diesem Domainnamen wartet, erledigen die Naming Authority Pointer Records.

Wählt der Benutzer die Nummer eines VoIP-Telefons, wird durch ENUM zunächst über das DNS-System die Nummer bis zum NAPTR-Eintrag aufgelöst. Für jede Domain können mehrere NAPTR-Einträge gesetzt werden, für jede Kommunikationsadresse eine. Die Auswertung dieser Resource Records ergibt einen oder mehrere Uniform Resource Identifier (URI), unter dem der gewünschte Service der angegebenen Domain bzw. Telefonnummer angesprochen werden kann.

NAPTR-Records liefern diese zusätzlichen Informationen auf sehr flexible Art und Weise. Es gibt Präferenzen, welcher Dienst in der Regel verwendet werden sollte, durch mehrere NAPTR-Records gleicher Priorität zu einem Namen, lässt sich sogar eine Art Lastverteilung erreichen. Der NAPTR-Record-Typ kann damit als eine Erweiterung des klassischen A-Records oder auch SRV-Records eines DNS-Eintrags angesehen werden.

Die Struktur von NAPTR-Records hingegen ist komplex. So wird auf eine Anfrage kein Domänenname zurück geliefert, sondern ein regulärer Ausdruck (regular expression), den man als erstes zerlegen muss. Ein regulärer Ausdruck ist eine Zeichenkette, die der Beschreibung von Mengen beziehungsweise Untermengen von Zeichenketten mit Hilfe bestimmter syntaktischer Regeln dient.

Letztendlich geht es darum, den Uniform Ressource Identifier (URI) aus dem regulären Ausdruck zu extrahieren. Ein URI besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. URIs werden zur Bezeichnung von Ressourcen wie Webseiten, Aufruf von Webservices aber auch E-Mail-Empfängern eingesetzt.

DNS und DHCP sind zentrale Komponenten von VoIP

Der korrekte Umgang mit ENUM, NAPTR und den dahinter verborgenen Diensten ist Aufgabe des DNS-Servers. Bei den mit dem Betriebssystem gelieferten Versionen ist dazu in der Regel keine gesonderte Konfigurationshilfe vorgesehen.

Administratoren müssen die fehlerträchtige Verwaltung von ENUM und NAPTR Einträgen mit Bordmitteln vornehmen, wenn sie überhaupt möglich sind. ENUM erfordert in jedem Fall mehr Aufwand bei der DNS-Verwaltung auf Seiten des Administrators, als bei einem reinen Daten-Netzwerk. Dazu gehört das Mappen von E.164 Nummern zu Fully Qualified Domain Names und die Verwaltung von NAPTR Ressource Records.

Zur Umsetzung der URI in einen korrekten, vom Benutzer angeforderten Dienst erfolgt eine potenziell komplexe - und damit fehlerträchtige - Ersetzung per regulärem Ausdruck. Spezialisierte Appliances bieten dafür einfache Tools und Wizards, die dem Administrator viel Arbeit abnehmen und die den Umgang mit ENUM-Zonen und NAPTR Datensätzen vereinfachen. (TecChannel/haf)