SIP - Session Initiation Protocol
Internettelefonie als Motor für SIP
Der Hype um preisgünstiges oder gar kostenloses Telefonieren via Internet hat dem VoIP-Protokoll SIP endgültig zum Durchbruch verholfen. Aktuell spielt es vor allem im Consumer- und SOHO-Bereich - also beim Telefonieren über DSL-Anschlüsse eine wichtige Rolle. Doch auch die Hersteller von IP-TK-Systemen kommen an SIP nicht mehr vorbei. Der Beitrag beschäftigt sich mit den Details dieser technischen Entwicklung und der Fortschreibung des SIP-Standards.
Dem VoIP-Protokoll SIP ging anfänglich der Ruf voraus, dass es für Entwickler einfacher zu
implementieren sei, als das etablierte aber relativ komplexe Konkurrenzprotokoll H.323. Diese
Zeiten sind wohl vorbei. Mittlerweile zählen die relevanten Standards im SIP-Umfeld mehr als 2000
Seiten, und die IETF (siehe Glossar) ist weiterhin fleißig dabei, neue Standard-RFCs im SIP-Umfeld
zu verabschieden. Dabei geht es allerdings weniger um grundlegende Themen, sondern eher um
esoterische wie neue Transport Layer, "Session Policy" oder schlichtweg um die Frage, wie ein
Mediaserver Tastendrücke einfangen und an einen Application-Server weiterleiten soll (siehe Bild
1).
Für den Endanwender ist dies kaum von Bedeutung, denn das Feature-Set, das im täglichen Leben
eine Rolle spielt, dürfte mittlerweile stabil sein. Die Hersteller im SIP-Bereich haben sich mit
den bereits existierenden Standards so arrangiert, dass die Produkte unterschiedlicher Anbieter
weitgehend zueinander kompatibel sind. In Bereichen, in denen die IETF noch keinen endgültigen
Standard gefunden hat, finden sich oft pragmatische Lösungen direkt zwischen den Herstellern. So
hat beispielsweise Broadsoft festgelegt, wie die LEDs der Telefone angesteuert werden sollen, und
wie sich vom PC aus ein Gespräch auf dem Telefon annehmen lässt.
Allerdings ist auch der SIP-Standard nicht unangefochten, und "Konkurrenz" kommt von
verschiedenen Seiten: So ist es dem Anbieter Skype (www.skype.com) gelungen, quasi über Nacht den
Markt für kostenlose Internettelefonie zu besetzen beziehungsweise diesen überhaupt zu schaffen.
Statt sich in Standardisierungsdiskussi-onen zu verlieren, haben die Skype-Techniker mit einem
eigenen Lösungsansatz Fakten geschaffen. Dass bei diesem Verfahren Gespräche teilweise über Rechner
unbeteiligter Nutzer laufen, und so Kollateralschäden bei der Wahrung der Privatsphäre in Kauf
genommen werden, scheint niemanden zu stören. Ob sich Player wie Cisco oder Microsoft auf solche
Techniken als Standard einlassen werden, dürfte für den weiteren Erfolg wichtig sein, erscheint
jedoch als fraglich.
Noch ein weiteres VoIP-Protokoll, IAX, macht derzeit kräftig Wind für einen neuen Standard. Die
IAX-Spezifikation umfasst weniger als 50 Seiten und wirbt damit, dass alles einfacher gehe. Die
Open-Source-Gemeinde um das Asterisk-Projekt (www.as terisk.org) ist begeistert und erwartet, dass
dies zu preisgünstiger VoIP-Hardware führt. Allerdings handelt es sich bei IAX um ein komplett
eigenständiges Protokoll. Käme es von einem der großen Player, wäre die Empörung sicher nicht zu
überhören. Und wie bei Skype bleibt auch bei IAX abzuwarten, ob sich die großen Markt-Player darauf
einlassen.
NAT: Problemlösung in Sicht
NAT (Network Address Translation) ist nach wie vor eines der wichtigsten Probleme bei Voice over
IP. Die Hersteller von DSL-Routern und Firewalls haben sich in den letzten Jahren vor allem mit
Protokollen wie HTTP und SMTP beschäftigt. Typisch für diese Protokolle ist, dass Akti-onen immer
vom Client initiiert werden: Eine E-Mail wird nie dem Client im LAN zugestellt, sondern dieser
prüft selbst alle paar Minuten, ob neue Post auf dem Mail-Server vorhanden ist.
Dieser Ansatz funktioniert beim Telefonieren nicht mehr. Hier muss der Server (Internet) in der
Lage sein, dem Client (LAN) direkt eine Nachricht zuzustellen. Dies geschieht heute dadurch, dass
der Client nur für eine kurze Zeit registriert wird und sich regelmäßig wieder anmelden muss. Dabei
schlägt er "Löcher" in die NAT-Tabelle, über die der Server eingehende Nachrichten schicken kann.
Der bei diesem Verfahren entstehende "Keep-alive"-Verkehr ist nicht zu unterschätzen. Für einen
Client kommen leicht 100 MByte pro Monat zusammen. Viele Betreiber nehmen lieber den zusätzlichen
Datenverkehr in Kauf, als ihren Kunden zu erklären, wie sie ihre Router konfigurieren sollen.
Ein Lösungsansatz für das NAT-Problem ist STUN (Simple Traversal of UDP over NAT). Dieser
Standard (RFC 3489) ermöglicht es Endgeräten im LAN, sich über einen externen Server sozusagen "im
Spiegel" zu betrachten und so für eine korrekte Zuordnung von öffentlicher und lokaler IP-Adresse
zu sorgen. STUN funktioniert jedoch nicht in allen Fällen: Wenn die Firewall beispielsweise so
genanntes symmetrisches NAT verwendet, ist das Endgerät aus dem Internet nur direkt vom STUN-Server
aus erreichbar, und Pakete anderen Ursprungs, etwa von IP-Telefonen werden nicht durch die Firewall
gelassen. Wenn auch STUN in vielen Umgebungen funktioniert, so bleibt der erfolgreiche Einsatz
dieses Protokolls leider Glückssache.
Eine neue Infrastrukturkomponente für Carrier, die das Problem auch für symmetrisches NAT löst,
nennt sich "Session Border Controller" (SBC). Anfangs als "übel" in der IETF verspottet, hat man
dort mittlerweile verstanden, dass leider kaum ein Weg daran vorbeiführt. Beim Einsatz des SBC
können die allermeisten Internettelefoniekunden einfach ihr IP-Telefon in Betrieb nehmen, ohne
irgendwelche Änderungen an Router oder Endgerät vornehmen zu müssen (siehe Bild 2). Neben der
Lösung des lästigen NAT-Problems ermöglicht es der SBC den Betreibern beispielsweise auch, das
Gespräch abzubrechen, wenn das Guthaben des Kunden aufgebraucht ist. Neben NAT adressiert der SBC
auch das Problem der "UDP Fragmentation", bei dem Router zu große Pakete nicht mehr korrekt
weiterleiten. Da der SBC nicht die kompletten Routing-Informationen preisgibt, sind die Pakete
normalerweise so klein, dass dieses Problem praktisch nicht mehr auftritt. Für die Betreiber hat
diese Technik noch einen interessanten Nebeneffekt: Wenn die Kunden die Routing-Informationen nicht
sehen, können sie ihren Gesprächspartner auch nicht direkt kontaktieren und dabei den Betreiber und
das damit verbundene Billing umgehen.
QoS: Noch kein Land in Sicht
Innerhalb von Unternehmensnetzen ist Quality of Service (QoS) als Voraussetzung für Voice over
IP heute eine Selbstverständlichkeit. Dies gilt auch für die entsprechenden Angebote von Carriern
und Providern für entsprechende Weitverkehrsverbindungen. Anders sieht die Situation jedoch für den
SOHO-Bereich aus, der über preisgünstige DSL-Verbindungen an Internettelefonie partizipieren will.
Zwar mag der lokale DSL-Router in der Lage sein, die Pakete, die das LAN verlassen, QoS-gerecht in
die Ausgabewarteschlangen einzusortieren. Die Gegenrichtung kontrolliert aber vor allem der
DSL-Anbieter. In Deutschland sieht es in dieser Hinsicht eher schlecht aus, denn die entsprechenden
QoS-Bits werden in der Regel ignoriert. Vielmehr gibt der Betreiber TCP-Paketen oft eine höhere
Priorität als UDP. Unglücklicherweise laufen die meisten Downloads mit TCP und können so parallel
geführte VoIP-Telefonate erheblich beeinträchtigen.
Für dieses Problem existieren derzeit zwei Lösungen. Die erste besteht darin, zu einem Provider
zu wechseln, der QoS anbietet. In Verbindung mit einem SBC kann dieser sicherstellen, dass die
Pakete richtig einsortiert werden, selbst wenn eingehende VoIP-Pakete nicht mit QoS-Bits markiert
sind. Die zweite, eher pragmatische Lösung besteht darin, einfach einen zweiten DSL-Anschluss zu
mieten und Voice und Data physikalisch zu trennen. Diese Variante funktioniert sehr gut und ist bei
geschäftlicher Nutzung auch in vielen Fällen ökonomisch sinnvoll.
Security: bekanntes Thema in neuer Variante
Mit der zunehmenden Attraktivität internetbasierender Telefonie ergeben sich hier ähnliche
Sicherheitsprobleme, wie sie aus anderen Bereichen der IP-Kommunikation hinlänglich bekannt sind:
Hierzu zählen etwa Spam, Hacker-Attacken und Abhörversuche. In Analogie zu Spam-Mails zeichnet sich
bereits eine wahre Flut an "Schrott"-Anrufen ab: Spam via Internet Telephony (SPIT). Die
Suchmaschine Google findet schon 130.000 Treffer zum Thema "Spam & SPIT". Das Prinzip ist
einfach: Wenn Telefonanrufe kostenlos sind, können "SPITler" von Rechnern irgendwo im Internet
Millionen von Telefonanrufen starten, in denen die Empfänger dann hören, dass sie eine Reise in die
Südsee gewonnen haben. Die Zieladressen sind einfach zu erhalten, indem alle Nummern, die ein
Betreiber seinen Kunden zur Verfügung stellt, ausprobiert werden.
Allerdings greifen auch hier Gegenmaßnahmen, die aus der Anti-Spam-Technik bekannt sind. Zum
einen beginnen die Betreiber, so genannte "White Lists" einzuführen. In der Regel decken sie das
Adresspotenzial kooperierender Betreiber ab. Kommt ein Anruf von dritter Seite aus dem Internet,
wird er abgewiesen. Zum anderen richten die Betreiber auch "Black Lists" ein, auf denen Kunden
landen, die SPIT verschicken. Das kann sogar automatisch passieren, wenn ein Kunde mehr
Telefonanrufe startet, als er natürlicherweise schaffen kann.
Inzwischen soll es sogar schon zu den ersten Virus-Telefonanrufen gekommen sein. Der eingehende
Ruf beinhaltet dabei ein manipuliertes Datenpaket, welches das Empfangssystem zwar nicht zum
Absturz bringt, aber über einen entsprechenden Softwarecode in einen gehorsamen Roboter verwandelt
und zum Beispiel auf Kommando zur Abhörwanze umfunktioniert. In solchen Fällen empfiehlt es sich,
sowohl den Hersteller des Endgeräts als auch den Provider zu informieren. Es existieren genügend
technische Möglichkeiten, solche Angriffe für die Zukunft auszuschließen.
Neben so genannten DoS-Attacken wie SPIT spielt die Wahrung der Privatsphäre eine wichtige
Rolle. Hierfür kommen Verfahren zum Einsatz, die schon bei HTTP spezifiziert sind. Analog zu HTTPS
heißt der "Secure"-Standard bei SIP "SIPS". Wie bei HTTPS dienen Zertifikate zur Identifikation der
Teilnehmer und sind die Basis für die Aushandlung der notwendigen Schlüssel. Entsprechend fungiert
SRTP als Ergänzung von RTP (Realtime Transport Protocol), wobei eine 128-Bit-AES-Verschlüsselung
zum Einsatz kommt. Die Schlüssel werden über SIPS ausgetauscht. Derzeit läuft noch eine
Diskussionen bezüglich der korrekten Standardformulierung. Die offenen Punkte sollten sich aber in
den nächsten Monaten klären lassen, sodass dann mit SIPS und SRTP eine saubere Verschlüsselung von
Gesprächen realisierbar ist.
Allerdings sind die erwähnten Session Border Controller bei SIPS und SRTP in der Lage, die
Gesprächsdaten zu entschlüsseln. Aus der Perspektive der Provider mag dies durchaus erwünscht sein.
Schließlich ist zu erwarten, dass Betreiber nach Aufforderung durch die Gerichte in der Lage sein
müssen, Gespräche auf bestimmten Anschlüssen mitzuhören. Dem Endkunden mag dies allerdings nicht
recht sein. Daher wurde analog zu E-Mail auch im SIP-Umfeld S/MIME definiert, das eine
End-to-End-Verschlüsselung durchführt und Betreibern keine Chance mehr gibt, Gesprächsdaten
mitzuschneiden. Es bleibt abzuwarten, inwieweit der Gesetzgeber angesichts der aktuellen
politischen Diskussionen die End-to-End-Verschlüsselung tolerieren wird. Wer aber in der Lage ist,
seinen eigenen Proxy-Server (notfalls im Ausland) zu betreiben, der wird praktisch nicht mehr
abzuhören sein.
SIP im Büro
SIP punktet derzeit vor allem im Consumer-Bereich und bei der SOHO-Anbindung. Doch auch die
VoIP-Lösungen für das Unternehmensumfeld, die bislang noch stark von proprietärer Technologie
beherrscht werden, lassen erkennen, dass SIP hier künftig eine immer wichtigere Rolle spielen wird.
Im Bereich SIP-basierender TK-Anlagen sind Fortschritte zu vermelden, die allerdings weniger auf
Neuerungen in der Standardisierung basieren, sondern vielmehr im Umgang mit den existierenden
Standards. Die Auswahl an brauchbaren Lösungen hat sich deutlich erhöht, und auch die Auswahl an
interoperablen Endgeräten ist für den Kunden erfreulich gestiegen. Es scheint sich durchzusetzen,
dass die Anwender einer IP-TK-Lösung nicht mehr alle Komponenten von einem Hersteller kaufen
müssen. Neben den Spezialisten scheinen sich jetzt auch die großen Player darauf vorzubereiten,
dass sie nicht mehr das komplette System selbst herstellen müssen. Wenn alles gut läuft, haben die
Kunden bald eine ähnliche Auswahl wie derzeit im Computergeschäft.
Weniger erfreulich ist die in vielen Fällen zugrunde liegende Kommunikationsarchitektur.
Eigentlich war es der technologische Ansatz von SIP, die Endgeräte möglichst viel direkt
miteinander aushandeln zu lassen. Im Vergleich zu einem zentralistischen Konzept hat dies den
Vorteil, dass solche Systeme viel besser skalieren, und dass beim Transport der Mediendaten
wesentlich geringere Laufzeiten entstehen. Aufgrund der hohen Komplexität scheint dieser Ansatz
jedoch praktisch gescheitert zu sein: Die meisten VoIP-Systeme verwenden die traditionelle
Topologie des klassischen TK-Nebenstellensystems und unterstützen nur direkte Verbindungen zu den
Endgeräten. Das analoge Kabel der TK-Anlage wird sozusagen durch SIP ersetzt. Die Anwender dürften
damit dennoch zufrieden sein, solange es ihr Problem löst.
Lesen Sie mehr zum Thema
