09_ngn_und_sip

Unterschiedliche Protokolle auf Schicht 1 und 2 werden durch eine gemeinsame Schicht 3 (IP) über Router miteinander verknüpft; die IP-Adresse muss daher hierarchisch Netz und Host adressieren.

IP im Kernnetz ist einfach, verbindungslos und unbestätigt (Best Effort, keine QoS-Garantie); die komplexe Ende-zu-Ende-Verbindungssteuerung und Sicherung erfolgt durch TCP in den Endgeräten (Hosts).

Tier-1: Internet Backbone Provider (IBPs) mit Hochgeschwindigkeits-Backbone; Tier-2: ISPs, die über Internet Exchange Points (IXPs wie DE-CIX) peeren; Tier-3: Access-Netze für den Kundenzugang (DSL, Mobilfunk, Glasfaser); ergänzt durch CDNs direkt am Backbone.

Um Routing-Tabellen klein zu halten (optimal sind $\ln N$ Hierarchiestufen bei $N$ Knoten), wird das Internet in ca. $100000$ Autonome Systeme (AS) unterteilt.

IGP (z. B. OSPF, Link State Routing) arbeitet innerhalb eines Autonomen Systems (AS), wo jeder Router jeden kennt; EGP (z. B. BGP) tauscht Routing-Informationen zwischen verschiedenen AS unter Berücksichtigung von "Routing Policies" über Grenzrouter aus.

Hierarchischer Aufbau von rechts nach links (Root-Zone $\rightarrow$ Top Level Domain (TLD) $\rightarrow$ Second Level Domain $\rightarrow$ Hostname, z. B. www.eit.h-ka.de.); DNS löst diesen Namen in eine IP-Adresse auf (und umgekehrt, $n:m$-Zuordnung möglich).

Als verteilte Datenbank mit disjunkten Zonen (jeweils mit primärem und sekundären Name Servern) und $13$ logischen Root-Servern (A bis M, per Anycast verteilt); ICANN verwaltet ca. $250$ TLDs, DENIC eG ist der Registrar für die TLD .de.

Auf Anfrage eines Hosts arbeitet der lokale Name Server (oft im Router) die Anfrage zonenweise iterativ von oben (Root) nach unten ab, speichert die Antwort temporär im Cache und nutzt dafür UDP auf Port $53$ (sichere Erweiterung: DNSSEC).

Migration getrennter, heterogener Netze (Telefon-Festnetz, Mobilfunk, Internet, Kabel) in ein einheitliches paketbasiertes All-IP-Kernnetz (ggf. mit MPLS) zur besseren Ressourcenauslastung, Skalierbarkeit, Mobilität und strikten Trennung von Verbindungssteuerung und Nutzdatentransport.

Im Transport-Layer übernimmt das Network Attachment Subsystem (NASS) die Zugangsverwaltung/IP-Zuweisung und das Resource and Admission Control Subsystem (RACS) die Ressourcen- und Zulassungskontrolle für QoS.

Der Call Server (Softswitch) übernimmt die Verbindungssteuerung; das SGW konvertiert die Signalisierung zu herkömmlichen Netzen (z. B. ZGS Nr. 7 / SS7 $\leftrightarrow$ SIP); das MGW wandelt die Nutzdatenströme zwischen kanal- und paketorientierten Netzen um.

Eine standardisierte NGN-Plattform (ETSI TISPAN / 3GPP) zur Bereitstellung IP-basierter Multimedia-Dienste (z. B. Triple Play, VoLTE im Evolved Packet Core ab LTE) über heterogene Zugangsnetze, gesteuert über SIP, inklusive QoS-Aushandlung (DiffServ) und AAA-Diensten.

CSCF (Call State Control Function) steuert als SIP-Server-Instanz die Sitzungen: P-CSCF (Proxy, erster Kontaktpunkt), I-CSCF (Interrogating, Anlaufpunkt für externe Netze), S-CSCF (Serving, SIP-Registrar); HSS (Home Subscriber Server) ist die zentrale Teilnehmer- und Profildatenbank inkl. AAA; AS sind Application Server für Dienste.

Gespeicherte Medien werden über RTSP (Real Time Streaming Protocol, wie eine Fernbedienung) gesteuert und meist per TCP übertragen; Live-Streaming/IPTV nutzt innerhalb von Providernetzen Multicasting (Verwaltung per IGMP) und Datentransfer mit RTP über UDP (im offenen Internet mangels Multicast-Routern oft dennoch paralleles TCP).

TCP-Mechanismen wie Sendewiederholungen (Retransmissions) bei Paketverlust und Überlaststeuerung erzeugen zu hohe und schwankende Verzögerungen (Latenz/Jitter); bei Echtzeitdiensten ist ein verworfener Rahmen besser als ein zu spät gelieferter.

Maximal $200\,\text{ms}$ pro Richtung für sehr gute Sprachqualität, bis $300\,\text{ms}$ gut, bis $400\,\text{ms}$ akzeptabel, darüber sehr störend; um die Paketierungsverzögerung gering zu halten, nutzt man kleine Pakete mit typischerweise $20\,\text{ms}$ (manchmal $30\,\text{ms}$) Audiosamples.

Paketierungsverzögerung ($1000\,\text{Byte} = 8000\,\text{Bit}$ bei $64\,\text{kbit/s}$): $t_{\text{pack}} = 125\,\text{ms}$; Ausbreitungsverzögerung ($9200\,\text{km}$ bei $200000\,\text{km/s}$): $t_{\text{prop}} = 46\,\text{ms}$; Übertragungsdauer bei $100\,\text{Mbit/s}$: $t_{\text{trans}} = 0,08\,\text{ms}$; Summe ohne Router/Puffer $\approx 171,08\,\text{ms}$ (zeigt, warum $1\,\text{kByte}$ große Pakete bei VoIP viel zu lang dauern).

G.711 (PCM, $64\,\text{kbit/s}$, $0,125\,\text{ms}$ Verzögerung, Pflicht-Codec bei VoIP, Paketverlust bis $0,5\,\%$ gut, bis $2\,\%$ akzeptabel); G.726 (ADPCM, $32\,\text{kbit/s}$); G.723.1 (ACELP, $5,3\,\text{kbit/s}$, $37,5\,\text{ms}$ Verzögerung); GSM-FR ($13\,\text{kbit/s}$), GSM-HR ($5,6\,\text{kbit/s}$), GSM-EFR ($12,2\,\text{kbit/s}$); AMR ($4,75$ bis $12,2\,\text{kbit/s}$, UMTS/LTE); Opus (kombiniert SILK/LPC und CELT/MDCT, $6$ bis $510\,\text{kbit/s}$, extrem flexibel, open-source).

Header-Overhead ist immer $66\,\text{Byte}$ ($12\,\text{Byte}$ RTP + $8\,\text{Byte}$ UDP + $20\,\text{Byte}$ IP + $22\,\text{Byte}$ Ethernet-Header + $4\,\text{Byte}$ Trailer). Bei G.711 ($20\,\text{ms}$): $160\,\text{Byte}$ Nutzdaten + $66\,\text{Byte}$ = $226\,\text{Byte}$ (Overhead ca. $29\,\%$); bei G.723.1 ($5,33\,\text{kbit/s}$, $30\,\text{ms}$): $20\,\text{Byte}$ Nutzdaten + $66\,\text{Byte}$ = $86\,\text{Byte}$ pro $30\,\text{ms} \Rightarrow$ reale Datenrate steigt auf $22,93\,\text{kbit/s}$ (Kompromiss: kleine Pakete = geringe Verzögerung, aber riesiger relativer Overhead).

Textbasiertes (ASCII, ähnlich HTTP) Multimedia-Vermittlungsprotokoll zum Aufbau, zur QoS-/Codec-Aushandlung, Steuerung und zum Abbau von Sitzungen (2-Party, Konferenzen, Multicast) über IP; läuft meist über UDP (Port $5060$) oder verschlüsselt über TCP/TLS, reserviert selbst keine Ressourcen und überträgt keine Nutzdaten.

Ein SIP User Agent enthält beides: Der User Agent Client (UAC) initiiert SIP-Anfragen (Requests), während der User Agent Server (UAS) eingehende Anfragen entgegennimmt und beantwortet (Responses).

Die ständige SIP-URL (z. B. sip:lima@h-ka.de) ist die feste, beim Anbieter registrierte Adresse; die temporäre SIP-URL (z. B. sip:manfred@193.196.74.63) enthält die aktuelle IP-Adresse des Hosts und wird vom User Agent umgebungsabhängig generiert.

Beim Einschalten sendet der UA ein REGISTER an den Registrar Server, der das Binding zwischen ständiger und temporärer SIP-URL über ein Protokoll wie Diameter im Location Server (Datenbank, im IMS der HSS) speichert; bei einem Anruf fragt der SIP Proxy den Location Server ab, um die Anfrage an die aktuelle temporäre URL weiterzuleiten.

Ein Stateless Proxy leitet SIP-Nachrichten einfach transparent und ohne Zustandsspeicherung weiter; ein Stateful Proxy speichert den Transaktionszustand, terminiert die Transaktion nach beiden Seiten, überwacht Timeouts und ermöglicht "Forking" (gleichzeitiges Weiterleiten eines Anrufs an mehrere Endgeräte).

Der SBC koppelt verschiedene SIP-Netze an Betreibergrenzen, terminiert Signalisierung und Medienströme komplett (Application Layer Gateway, keine Ende-zu-Ende-Transparenz), verbirgt die Netztopologie, überwacht SLAs und löst NAT-Probleme; der AS stellt flexibel Zusatzdienste (Voicemail, Click-to-Dial, Konferenzen) bereit, getrennt von der Vermittlung.

INVITE (Anforderung eines Sitzungsaufbaus), ACK (Bestätigung des Sitzungsaufbaus beim 3-Way-Handshake), BYE (Beendigung einer Sitzung), OPTIONS (Abfrage unterstützter Dienste/Codecs eines Hosts), CANCEL (Abbruch einer noch nicht abgeschlossenen Anfrage), REGISTER (Ortsregistrierung beim Registrar-Server).

1xx Provisional Responses (vorläufige Antwort, z. B. 100 Trying, 180 Ringing), 2xx Successful (Erfolg, z. B. 200 OK), 3xx Redirection (Weiterleitung, z. B. 302 Moved temporarily), 4xx Request Failure (Client-/Anfragefehler, z. B. 403 Forbidden, 404 Not found, 407 Auth. Required), 5xx Server Failure (z. B. 500 Server internal error), 6xx Global Failure (z. B. 600 Busy everywhere).

A sendet INVITE (enthält das Medien-/Codec-Angebot als "Offer" im SDP-Body) $\rightarrow$ B antwortet optional mit 100 Trying / 180 Ringing und schließlich mit 200 OK (enthält die "Answer" im SDP-Body) $\rightarrow$ A bestätigt mit ACK; danach läuft die RTP-Session, die später mit BYE und 200 OK beendet wird.

Besteht aus Start-Line (Request- oder Status-Line), Header-Feldern (z. B. Via, To, From, Contact, Call-ID), einer Leerzeile und dem optionalen Body (mit SDP-Parametern); jeder weiterleitende Proxy fügt oben ein eigenes Via-Header-Feld hinzu, damit alle Antworten einer Transaktion exakt über dieselben Server zurückgeroutet werden.

Ein klassischer NAT-Router arbeitet nur auf Schicht 3 (IP) und 4 (TCP/UDP) und tauscht dort die privaten Adressen aus, kann aber die privaten IP-Adressen und Ports, die im Text der Applikationsschicht (im SIP-Header wie Contact/Via und im SDP-Body) stehen, nicht lesen oder anpassen, sodass Antworten und RTP-Ströme den Empfänger nicht erreichen.

1. SIP-aware NAT (Application Layer Gateway), das SIP-Pakete auswertet und umschreibt; 2. STUN (Session Traversal Utilities for NAT), womit der Client vorab einen öffentlichen STUN-Server nach seiner öffentlichen IP/Port-Kombination fragt und diese in die SIP-Nachricht einträgt; 3. TURN (Traversal Using Relays around NAT) über einen Relay-Server; 4. ICE (Interactive Connectivity Establishment) als Gesamtrahmenwerk, das alle Methoden kombiniert.

SIP-Steuerungsdaten (Control Plane) werden über SIP-Proxys geroutet, während die eigentlichen Multimedia-Nutzdaten (User Plane, z. B. G.711 über RTP/UDP) direkt zwischen den Endgeräten (SIP UAs) über IP-Router fließen und somit völlig unterschiedliche Wege durch das Netz nehmen können.

Einseitige Authentisierung nach dem Challenge-Response-Verfahren mit einem gemeinsamen Passwort (Shared Secret): Auf ein INVITE (oder REGISTER) antwortet der Proxy/Registrar mit 407 Proxy Authentication Required (bzw. 401) und einer Zufallszahl ("nonce"); der Client sendet die Anfrage erneut mit einem MD5-Hash über (username, password, nonce, ...), was gleichzeitig die Integrität sichert (im IMS/Mobilfunk wird dies durch AKA auf der USIM ersetzt).

SIPS (sips:user@host) verschlüsselt SIP-Nachrichten mittels TLS über TCP, allerdings nur Hop-by-Hop zwischen den SIP-Servern; für Ende-zu-Ende-Sicherheit des SIP-Bodys dient S/MIME; die Sprach-/Mediendaten werden in Echtzeit mit SRTP (Secure RTP, nutzt AES und SHA-1) geschützt, wobei der Schlüsselaustausch z. B. über DTLS (Datagram TLS auf UDP) erfolgt (alternativ IPsec Hop-by-Hop auf Schicht 3).